115个软件元素一次拼装就够，为什么还要让大模型每次从零生成代码？
一个叫Software Periodic Table的开源项目把常用软件模块像化学元素一样归类，结果发现115个原子元件就能覆盖绝大多数业务功能，大模型编程从此变成拼装乐高而不是重新发明轮子。
软件元素周期表把115个常用模块分进六个家族
这个项目首先干了一件事，它把软件开发里反复出现的那些东西扒了个底朝天。结果发现不管是啥业务系统，翻来覆去就那么些玩意儿在打转。他们把用户、任务、发票这类名词叫对象家族，把状态、日期、优先级这类描述词叫属性家族，把创建、更新、分配这类动词叫动作家族。另外还有界面家族管你怎么看数据，智能家族管AI那套搜索归纳推荐，规则家族管权限和自动触发。六大家族加起来一共115个元素，每个都有自己的编号、符号和名字，就跟化学周期表里的氢氦锂铍硼一样整整齐齐。
这项目管这个叫有限本体论，说白了就是认定软件世界的元素是有限的、能数清楚的。你想想化学周期表也就一百多个元素，组合出了整个物质世界。软件这边也一样，一百来个基础模块来回拼，就能拼出你能想到的所有业务系统。项目负责人说这玩意儿不是拍脑袋定的，是真扒了大量实际项目之后归纳出来的稳定集合。
最狠的是每个元素都有严格的定义和接口规范。比如用户这个对象元素，它长什么样、带什么属性、能跟谁打交道，全都写得明明白白。这就跟乐高积木的接口一样，每个凸起和凹槽都是标准化的，随便拿两块都能咔哒一声扣上。
大模型编程的老路子是每次重新发明轮子
现在大模型写代码是咋干的呢。你给个需求说帮我做个任务看板，模型就开始从零生成代码。数据库表结构从头设计，增删改查逻辑从头写，前端界面从头搭。这就好比你每次做番茄炒蛋都从种番茄和养鸡开始，累不累啊。
项目文档里吐槽说这种方式浪费token不说，还引入了大量随机性。同一个需求让模型生成十次，能给你十个完全不同的实现。每次生成的代码质量还不稳定，有时候写得挺好，有时候就拉胯。更麻烦的是验证成本，每次都要从头检查一遍代码有没有bug、逻辑对不对、安全性咋样。
他们管这个叫生成优先的范式。大模型就像一个超能写的程序员，但记性不太好，每次都要重新想、重新写。而且生成出来的代码往往有大量重复的模式，就像你每次写登录功能都复制粘贴差不多的一套东西，但每次又有点不一样，这就很难搞。
拼装代替生成的核心思路是让大模型做选择题
这个软件周期表项目提出了一个完全相反的思路，他们管这叫拼装优先。意思是不让模型从零生成代码了，而是让模型从115个原子元件里挑合适的出来拼在一起。
举个具体的例子，用户想要一个任务看板。按照老路子，模型要生成数据模型、生成API接口、生成前端表格和看板视图。新路子是让模型先检索，从对象家族里选出任务和用户这两个原子，从动作家族里选出增删改查分配这些动作原子，从界面家族里选出表格视图和看板视图这两个界面原子。然后把这些原子按照标准接口组装起来，再加一点胶水代码把它们粘在一起就行。
项目里专门有个拼装器模块，里面有一套系统提示词和规划模板，专门教大模型怎么干这个活。提示词里明确告诉模型你有这115块积木可以用，每块积木啥功能、接口长啥样、能跟谁组合。模型要做的事情就是理解需求、检索相关原子、输出拼装方案。这样一来模型从创作家变成了建筑师，差别可太大了。
115个元素怎么划分还有编号规则和扩展原则
这115个元素不是随便排的，人家是有编号规则的。对象家族占1到35号，用户是1号任务2号这种。属性家族占36到60号，状态36号日期37号。动作家族61到85号，创建61更新62。界面家族86到100号，表格86看板87。智能家族101到108号，搜索101归纳102。规则家族109到115号，权限109策略110。
每个元素都有个两字母的符号标识，跟化学元素周期表里的H、O、C一样。还有人类可读的名字和简短的描述，方便大模型理解和检索。所有元素定义都存在一个ontology/periodic-table.json文件里，是唯一的事实来源，谁要改都得经过评审。
项目还定了个规矩，新元素不能随便加。只有当某个概念被大量实际项目反复用到，而且没法用已有元素拼装出来的时候，才考虑新增。这就保证了周期表不会无限膨胀，一直保持小而精的状态。项目文档里说他们宁可让元素少一点、组合多一点，也不愿意搞出几百个元素让人眼花缭乱。
参考实现用TypeScript写保证类型安全
光有定义还不行，项目还给每个原子提供了TypeScript参考实现。atoms目录下按家族分了文件夹，objects里放用户和任务，properties里放状态，actions里放CRUD操作，interfaces里放表格和看板。每个实现都严格遵循接口规范，输入输出类型都是明确的。
为啥要用TypeScript呢，因为类型就是最好的文档。大模型在拼装的时候，能直接看到每个原子的入参类型和返回值类型，这就知道咋连线了。比如用户原子需要一个ID和一个名字，任务原子需要标题、状态和负责人ID。那拼装的时候就知道要把用户ID传给任务的负责人字段。
项目目前还没有覆盖全部115个元素，只实现了核心子集。但没实现的也有精确描述，大模型可以根据描述来使用或者作为生成新实现的参考。他们打算陆续把所有115个元素都实现完。
评估工具专门测量token效率和拼装准确度
光说拼装比生成好不行，得有数据说话。项目专门搞了个评估工具集，在eval目录下。这个工具可以跑基准测试，对比基线方法和拼装方法的差异。测量的指标包括token使用量、拼装保真度和正确性。
token效率很好理解。生成方法可能要用几千个token来生成完整代码，拼装方法只需要几百个token来检索和组合。拼装保真度指的是模型选的原子是不是真的符合需求，有没有选错或者漏选。正确性就是最终拼出来的代码能不能跑、功能对不对。
项目文档里说评估工具目前跑的是模拟评分，真要测还得接入真实的大模型API。但这个评估框架已经搭好了，后面会持续收集实验结果，准备发论文用的。他们还在docs目录下放了个PAPER_OUTLINE.md，就是预备投arXiv的论文草稿。
两种使用模式分别适合不同场景的编程助手
项目给大模型编程助手提供了两种使用模式。第一种叫检索增强生成，推荐使用。就是把ontology/periodic-table.json和相关的原子实现文件加载到模型上下文里，或者放到向量数据库里。同时把拼装器里的系统提示词也塞进去。模型收到需求后先去检索相关原子，然后输出拼装计划和少量代码就行。
第二种叫直接提示注入，更简单粗暴。直接把拼装系统的提示词贴到模型的系统提示词里，让模型参考提示词里对周期表的描述来干活。这种适合上下文窗口不够大或者懒得搭检索系统的场景。
两种模式项目文档里都写了详细的走查步骤，包括推荐的提示词长啥样、检索策略咋搞、具体案例咋跑。docs/AGENT_USAGE.md里写得特别细，基本是手把手教你怎么让大模型用这个周期表干活。
设计原则强调稳定可测量和代理优先
项目背后有五条设计原则挺值得琢磨。第一条有限且稳定，周期表长得慢长得稳，优先用组合代替新增原子。第二条天生可组合，每个原子都声明清晰的接口和边界。第三条本体层面跟实现解耦，周期表描述是什么而不是怎么实现，TypeScript实现只是参考。第四条代理优先，检索、类型和提示词都是头等大事，这库是给机器用的不是给人看的。第五条可测量，token消耗、拼装质量、正确性都要能量化，评估工具全都能测。
这五条原则把项目定位得特别清楚。它不是给人类程序员看的文档库，是给大模型编程助手吃的饲料。设计的时候就想着模型怎么用方便、怎么检索准确、怎么拼装不出错。这思路比那些先做给人看再考虑机器用的项目高到不知道哪里去了。
当前状态稳定但还有扩展空间
项目目前处于v0.1.0版本，刚发了初始发布。115个元素的定义已经稳定了，所有家族的核心实现也都有。拼装器的系统提示词和规划模板能跑，任务看板的完整例子也能跑，评估工具的功能框架搭好了。
接下来他们要干的事包括把剩余元素的参考实现补齐，特别是界面家族里的表单、图表、日历这些，还有智能家族的那几个AI原子。然后要跑真正的LLM对比实验，收集基线方法和拼装方法的数据差异。再往后计划把周期表移植到Python、Rust、Go这些语言，还要搞垂直领域的扩展包。
项目地址在GitHub上，MIT协议开源，目前有28个星3个复刻。贡献指南写得挺清楚，想加新原子得走评审流程，得证明概念被广泛复用而且没法用已有原子组合出来。研究用途的话可以用CITATION.cff里的元数据来引用。
项目叫软件周期表，但实际干的活是给大模型编程搭了个标准零件库。化学周期表让化学家不用每次都重新发现元素，软件周期表让大模型不用每次都重新发明代码。这种拼装思维放到编程领域，某种程度上算是给AI编程找到了工业化的路子。
说到底软件开发的本质本来就不是发明新概念，而是组合已有概念解决新问题。这个项目只是把这件事做得更极端了，极端到把组合的零件数量限制在了115个。至于够不够用，他们的回答是绝大多数业务系统就够用，不够用的自己加垂直扩展包。
那些让大模型从零写代码的工具该醒醒了，每次生成都从造轮子开始的路子迟早被淘汰。拼装时代来了，这115块积木够你拼出一整座软件大厦。
总结就是115个标准化模块让大模型从写代码变成搭积木，token省了代码稳了验证快了，软件工业化生产的最后一块拼图可能就是这个周期表。拼装取代生成才是AI编程的未来，不信走着瞧。