今年早些时候，我们 8090 团队拆解了一个大型实体的计费引擎。这个引擎包含 1800 万行 COBOL 和汇编代码，其中一些代码在我们团队部分工程师出生之前就已经开始积累了。如今已经没有人能完全理解它，但通过使用我们的软件工厂，我们在 40 天内将其逆向工程为超过 10 万条用简单英语编写的规则。完成这项工作后，我意识到为什么“软件工厂”这个词突然被其他人也广泛使用。
这个概念之所以被挪用，是因为它暗示了某种企业渴望但尚未获得的工业级可靠性。软件工厂背后有五十年的历史，其最显著的特征正是企业比以往任何时候都更需要的东西——一个能够保证产出质量的生产系统。这与人们对日益增长的工具集感到的挫败感形成了鲜明对比，这些工具赋予了个体能力，却在让整个系统变得更加混乱。
这个词的历史比大多数人想象的要悠久
1969 年，日立开设了“软件工厂”（Software Works），它是一座真正的工厂：在那里，软件在统计质量控制下生产，缺陷率按每千行代码衡量，流程标准化，管理团队对产出质量负责。随后，东芝、NEC 和富士通也纷纷效仿。在 20 世纪 70 年代和 80 年代，这些日本软件工厂交付了有史以来最可靠的代码之一。它们生产的系统运行着银行、铁路和电力基础设施长达数十年。
2004 年，两位微软架构师出版了一本名为《软件工厂》的书，主张软件应该像汽车一样建造：使用经过验证的组件，在可重复的生产线上制造，通过前期设计控制变化，而不是依靠后期的英雄式补救。美国空军如今也在运营软件工厂。Kessel Run 为国防部构建和运营任务软件，当该软件出现故障时，他们责无旁贷。
在过去的六十年里，直到这波 AI 浪潮来临之前，有一件事始终如一。工厂从来不是一种工具或生产力技巧，无论它多么出色。工厂是一个生产系统，它接收输入，产出成品，并为这些成品的质量负责。换句话说，福特从未卖给你一把扳手、一些零件，然后祝你好运。福特卖给你一辆车，如果车出了问题，福特会召回它，因为那是他们的工厂生产的。
这就是标准，我认为现代软件工厂也必须符合这一标准。
五项测试
一个软件工厂应该通过五项测试。任何一项不达标，那它就是别的什么东西。这个“别的东西”很可能是一个开发者工具，它可能很有用，但它是不同的产品，承担着不同的责任。
测试一：工厂始于业务意图。 工厂的输入是业务需求，用业务的语言表达：需求、规则、监管约束、期望的结果。如果输入相反，是工程师写给工程师的 Jira 工单，那你看到的只是一个附在现有流程上的强力工具。工厂的要点在于，客户描述产品，工厂负责搞定生产。
测试二：工厂在持续变化中保持一致性。 这是最难的一项测试，也是 AI 工具市场上几乎没有人谈论的测试，因为他们的产品让情况变得更糟。
编写新代码从来不是企业软件的瓶颈。瓶颈在于，一个真实的系统每周都会被几十个人修改。每一次修改都可能让系统分崩离析。需求偏离文档，文档偏离代码，代码偏离测试。让这种偏离累积二十年，你就会得到我在开头描述的那个计费引擎：1800 万行代码，无人能完全理解，每年以 5% 到 8% 的速度增长维护合同，以及一个无法再在不恐惧的情况下修改自己软件的团队。
现实是，代码生成加速了这种偏离。如果你的 Agent 根据未保持同步的规范生成了十倍以上的代码，你就是在以前所未有的速度制造偏离。那个 1800 万行的问题花了四十年手工构建，但如果没有治理，Agent 集群几年内就能造出同样的问题。
一个运转良好的软件工厂能让意图、规范、代码、测试和生产行为作为一个统一的治理对象保持同步。修改需求，代码随之改变；热修复代码，需求随之更新。让供应商在一个真实的系统上现场向你展示这个闭环。如果他们做不到，他们就是在销售代码生成工具。虽然有用，但那是另一回事。
测试三：工厂独立于任何特定个人运作。 一个工具的好坏取决于使用它的人。把同一个编码 Agent 交给两个工程师，你会得到截然不同的结果，取决于谁写的提示词、谁审查的差异、谁发现了错误。这种差异在一个工具中可以接受，但在一个生产系统中是不合格的。工厂应该以可预测的速度和质量进行生产，无论谁在当班，这正是日立的统计控制旨在保证的：质量是生产线的属性，而不是操作员的属性。
工厂实现这一目标的方式是让知识在系统中积累，而不是在个人身上。当新人加入时，工厂会把已经学到的一切交给他们；当有人离开时，什么东西都不会带走。大多数企业软件在这一测试上惨败。计费引擎变得难以理解的原因不是代码差，而是对代码的理解存在于人脑中，而随着时间的推移，人会变化。如果他们的知识从未被系统捕获，系统就会慢慢变成一个黑箱。
需要明确的是，这并不意味着人无关紧要，或者工厂不需要问责制。工厂总是有特定的人来为产出负责。但它绝不依赖于任何一个人是不可替代的。一个需要英雄才能运转的系统，既没有问责制，也不是工厂。它只有一个英雄，而英雄最终会去寻找新的冒险。
测试四：每个产出单元都是可追溯的。 在真正的工厂里，每个零件都有“批号”。当出现故障时，你可以沿着生产线追溯到批次、机器和班次。受监管行业对软件也有同样的要求，这也正是它们对采用 AI 编码工具最谨慎的原因。“模型写的”不是审计员能接受的答案。一个软件工厂将审计轨迹作为生产的副产品：这条规则存在是因为这个需求，由这个人批准，在这个变更中实现，由这个测试验证，在这个时间部署。来源必须内置于生产线中，这意味着事后编写的文档不算数。
测试五：有人对成品负责。 这是将软件工厂与开发者工具区分开来的测试，因为这是大多数工具供应商最不愿意满足的一项测试。
工厂交付一个它为之负责的产品。当计费引擎算错一笔索赔，交易系统产生错误数字，制造验证批准了一个有缺陷的零件时，某个特定的人要为此负责、修复问题并承担成本。我现在读过很多 AI 工具合同，知识产权部分洋洋洒洒好几页，但问责部分通常只有一句话，而那句话是说输出是按现状提供，验证是你的问题。这完全不符合工厂的标准。
我们的一位客户，一家上市的健康保险公司，将其应付索赔规则转化为确定性的预过滤器，将路由到按次付费供应商的索赔减少了 80% 以上，在四年内避免了超过 2000 万美元的损失。这样的数字只有在做事的一方对结果负责时才会出现。
什么不是工厂
用这些测试去衡量，很多自称工厂的东西其实是别的什么。
编码 Agent，无论多好，都只是工具。它们以工程任务为输入，输出代码，并将所有验证和问责责任转移给客户的工程师。称它们为集群工厂并不能改变这一点。
Agent 编排仪表板是监督工具。它们让观察 Agent 工作变得更容易。
基准测试是工具的测量工具。高分告诉你一个工具在基准任务上表现良好，但它无法告诉你，经过人类和 Agent 混合团队两年的持续修改，你的系统是否还能保持一致性。
为什么现在定义如此重要
软件的生产成本正在急剧下降。当生产成本下降时，价值将转移到那些能够保证产出的人身上。这在之前的每一次工业化进程中都发生过，现在在 AI 领域也会再次发生。
那些抓住“工厂”这个词不放的初创公司本能地理解这一点。但许多公司只是在追求工业化生产的可信度，却不愿接受当初创造这种可信度的责任。
所以，忽略演示和基准测试，向每一个软件工厂问一个问题：当系统在生产环境中崩溃时，谁会接起电话？
对于一个软件工厂来说，答案必须是“我们来接”。
