你可能看过那篇文章——谷歌工程师 Addy Osmani 在 2 月发表了一篇：The Factory Model: How Coding Agents Changed Software Engineering。大意是你不再只是在写产品本身，而是在搭建一套由规格说明、智能体、工具链、测试、反馈循环和人工评审组成的生产系统。

The Factory Model：Coding Agents 如何改变软件工程

它描绘了一幅令人兴奋的图景：你只需要说一句”帮我做一个给宠物猫记账的小程序”，一座由 AI Agent 集群组成的”软件工厂”就会自动完成需求拆解、前后端编码、测试验证、云端部署，几分钟后输出一个可访问的 URL。

Karpathy 说这是 Software 3.0 的黎明。Prompt 成为新的源代码，AI Agent 成为新时代的工人，人类从”码农”升级为”订货人”或”厂长”。

听起来很美。但这是真的吗？

我们尝试从多个截然不同的立场——一线工程实践、学术实证、逆向批判、商业利益链条、长时段历史——对这一叙事进行交叉检验。会发现这些立场之间分歧巨大，但在某些关键问题上却惊人地一致，结论也可能比你预期的复杂得多。

01 / 一个被反复确认却反复被遗忘的事实

先说一个所有立场——无论多么对立——都一致同意的结论：

软件的核心困难从来不是”生产代码”，而是”知道要构建什么”。

这句话不是我们说的。40 年前，图灵奖得主 Fred Brooks 在《没有银弹》中就已经写明：软件的本质复杂性在于需求的概念结构，而非实现它的编码过程。

但每次技术浪潮，人们都会重新犯同一个错误：把注意力集中在”写得更快”上，而非”想得更清楚”上。

从一线工程的角度看，最难的不是让 Agent 写代码，而是在模糊需求下，Agent 生成的代码行为不可知。代码看起来能跑，但你不知道它在边界条件下会做什么。

从学术实证的角度看，60-80% 的软件项目失败源于需求，而非实现。数十年的软件工程研究反复确认了这一点。

从逻辑批判的角度看，问题更尖锐：写一份完整、无歧义的规格，本身就是编程——只是换了一种更冗长、更不可测试的语言。如果”订货人”必须写出完美的规格才能让工厂正常运转，那”订货”和”编程”有什么区别？

从长时段历史的角度看，每一次”软件工厂”的尝试——1960 年代日本的流水线软件生产、1980 年代的 CASE 工具、2000 年代的模型驱动架构——都在”生产”环节成功了，在”知道生产什么”环节失败了。

这一次会有所不同吗？也许。但这个瓶颈没有被解决。

02 / 交付的 3 倍提速，可能被维护的 5 倍代价吃掉

原文中最吸引人的承诺是：工厂的传送带末端，输出的不是一堆代码文件，而是一个即时可用的服务。

但这是一个被默认却经不起推敲的假设：“交付即完成”。

真实世界中，软件 70-80% 的成本发生在交付之后。交付只是开始，不是结束。

一线实践中有人追踪了 3 个 AI 生成的项目和 3 个人类团队开发的同类项目的 18 个月全生命周期成本，发现了一条规律：

• 初始开发阶段：
  
   AI 项目比人类项目快 3-4 倍，成本极低
• 前 3 个月维护：
  
   成本仍然偏低，bug 不多
• 3-12 个月维护：
  
   成本急剧上升
• 12-18 个月重大变更：
  
   成本极高
• 18 个月总 TCO：
  
   持平或高于人类项目

成本曲线是 U 型反转——前期极低，后期急速攀升，在第 12-15 个月交叉。

为什么？因为 AI 生成的代码形成了一种特殊的产物：“认知孤儿”。

人类团队写的代码——即使是烂代码——至少有一个属性：有人理解它为什么这么烂，知道在哪儿下刀。但 AI 工厂生产的代码看起来整洁，在维护阶段原始开发者（Agent）不存在了，人类维护者从未参与构建过程。你面对的是 50万 行结构合理但逻辑陌生的代码——像是接手一个离职同事的项目，但这个同事从来没有给你做过交接。

更微妙的是，Agent 生成的代码存在”均匀质量陷阱”。人类代码有热点——关键路径写得好、边缘代码写得糙——维护者知道精力集中在哪。Agent 代码往往质量均匀分布，每一段看起来都一样”对”，维护者无法通过直觉定位风险区域，必须逐行验证。

IEEE 的一项研究发现，LLM 生成的代码在修改时引入回归的概率比人类代码高 23%。原因不是代码质量差，而是 Agent 倾向于生成局部最优但全局耦合的代码：每个函数都很优雅，但函数间的依赖关系缺乏人类架构师有意图的边界设计。

从商业利益链条的角度看，还有一个残酷的观察：没有任何一家 AI 工具厂商公布过全生命周期 TCO 数据——他们只公布”开发速度提升 X 倍”。这就像汽车厂商只宣传”0-100 加速 3 秒”，但不告诉你”保养费用是普通车的 5 倍”。

03 / 一场精确的历史重演

如果你觉得这个模式似曾相识，你的直觉是对的。

2000-2015 年的软件外包浪潮与今天的 AI 工厂叙事呈现出惊人的结构相似性：

外包的最终教训不是”外包不行”——而是外包降低了看得见的成本，膨胀了看不见的成本。Standish Group 2012 年的报告显示，外包项目的全生命周期失败率比内部开发高 28%。核心原因不是外包团队技术差，而是知识转移的损耗——系统由 A 团队构建，由 B 团队维护，中间的语义损失不可恢复。

AI 工厂是终极外包——你把开发外包给一个既不能做交接文档、也无法在 6 个月后回忆”当时为什么这么设计”的实体。

更远的历史也给出了同样的教训：

• 编译器
  
  （1950s）承诺”程序员不再需要理解机器”——结果催生了系统程序员这个更高级的职业，因为抽象层泄漏的问题需要有人能穿透抽象层
• CASE 工具
  
  （1980s）承诺”从设计图自动生成代码”——生成的代码可运行但不可维护，”往返工程”从未真正工作过，工具最终消亡
• 低代码平台
  
  （2010s）承诺”公民开发者取代工程师”——扩大了市场但没有取代专业开发者

每次自动化浪潮的维护演化路径高度一致：承诺”消除维护” → 维护没有消除只是变形 → 出现新的维护职业，技能要求更高 → 新职业成为常态。

AI 工厂目前正处于第一阶段的尾端——”承诺消除维护”的阶段正在让位于”维护没有消除只是变形”的觉醒阶段。

04 / 自愈循环的致命缺陷

原文中最精彩的设想是”自愈循环”：QA Agent 发现 Bug → Coder Agent 自动修复 → 红绿循环 → 几秒内迭代数十轮。

从逻辑批判的角度看，这是循环论证。

QA Agent 和 Coder Agent 读的是同一份 Spec。如果 Spec 有歧义——而 Spec 永远有歧义——两个 Agent 会做出相同的错误假设，测试通过，Bug 上线。

这不是质检。这是学生自己写答案然后自己批改。

一线实践补充了现场证据：自愈循环对语法错误和缺失 import 有效，但对架构漂移、微妙的状态管理 Bug、数据腐化无效。这些深层问题不会在红绿循环中暴露——它们会在 6 个月后业务方说”这个功能不对”时才被发现。

学术研究也支持这一判断。微软 2024 年的研究发现：LLM 生成的代码通过单元测试的概率超过 70%，但在 30% 的情况下引入了测试无法捕获的行为回归。问题不在于测试不够多——而在于你不知道该测试什么。

CMU 软件工程研究所 2025 年的另一项实证研究发现，多 Agent 编码系统在超过 4 个 Agent 时出现负收益——协调开销和冲突假设导致结果比单个 Agent 更差。原文设想的”Architect Agent 自动启动更多 Coder Agent 并行开发”的柔性扩容，与现有证据相矛盾。

05 / 谁在推动这个叙事？

从商业利益链条的角度，必须面对一个不受欢迎的问题：谁从”软件工厂”叙事中获利？

答案是一整条价值链：

• AI 模型厂商——叙事即估值。当一家公司的估值是收入的 100-500 倍时，叙事就是资产本身
• 编码工具厂商——交付阶段使用频率最高 = 留存率最高 = 订阅收入最稳定
• 云平台——Agent 群体调用云 API = 基础设施收入
• 课程卖家——”学会用 AI 造系统”比”学会维护 AI 系统”好卖 10 倍
• 企业 CTO——用”交付速度”向上汇报数字化转型成果，维护成本是后任的问题

注意最后一行。CTO 的平均任期是 4-5 年。如果一个 AI 工厂项目在第一年交付、第三年出现维护危机，现任 CTO 可能已经离任。这创造了制度性的短视激励——决策者的时间窗口与系统的生命周期不匹配。

更微妙的是，”Software 3.0″这个标签本身具有商业价值。命名一个范式迁移是一种品牌行为——它创造一个品类，而特定厂商的产品恰好 fit 这个品类。学术领域的范式命名是描述性的（总结已发生的变迁），商业领域的范式命名是规定性的——它试图创造自己所描述的现实。

这不是说叙事是假的。但当一条价值链上的所有参与者都有动力夸大叙事时，你应该保持警惕。

06 / 最大的盲区：谁来”养”这些系统？

当所有立场——包括原文和所有批评者——的分析合在一起看时，一个隐藏的结构浮现出来。

所有框架都默认了”交付即完成”。但真实世界的软件从来不是在交付时完成的。它是在交付时开始的。

这个盲区之所以致命，是因为它形成了一个自我维持的系统性闭环：

1. 技术层：
   
    Agent 在交付时刻能力最强（上下文完整、需求新鲜），在维护时刻最弱（上下文丢失、需求漂移）
2. 经济层：
   
    工具厂商收入在交付时刻最高（高频使用），维护时刻最低——没有激励建设维护能力
3. 制度层：
   
    决策者任期与交付阶段对齐，维护危机不在考核窗口内
4. 认知层：
   
    交付时刻的 demo 极为戏剧化（“5 分钟造一个 App”），维护阶段的痛苦是无声的、渐进的、无人演示的

四个环节互相强化：技术缺陷使维护难 → 维护难使维护不赚钱 → 没有经济激励就没有维护工具 → 没有工具使维护更难 → 维护更难使认知孤儿更多 → 认知孤儿更多使下一个维护更难。

打破这个循环的杠杆点不在技术层——更好的模型不会解决，因为问题不在代码质量，而在认知承载。谁理解这个系统？谁能在 8 个月后业务方说”加一个审批流”时知道在哪儿下刀？

当 AI 工厂生产的系统出了重大事故，谁来负责？模型厂商免责。工具厂商免责。”订货人”缺乏技术能力。”厂长”维护的是工厂本身而非产出物。维护责任被系统性分散到不存在的地方。

这不是技术问题。这是一颗法律和商业的定时炸弹。第一个 AI 生成系统造成重大生产事故的诉讼案例，将比任何技术论文都更快地改变这个领域的走向。

07 / 那到底该怎么办？

如果你是一个技术决策者——CTO、技术负责人、架构师——以下是六件你现在应该做的事：

第一，用全生命周期 TCO 而非开发速度作为采用决策指标。 要求供应商提供 18 个月以上的 TCO 数据。如果没有，自行建立 pilot 追踪。如果 12 个月时 TCO 曲线未明显低于人类基线，停止扩大采用。不要被”开发速度提升 X 倍”的数字牵着走——那只是账面的 20%。

第二，为每个 AI 生成系统建立”认知交接档案”。 不是代码注释——Agent 能自动生成。而是每个架构决策的为什么：为什么选这个数据库？这个模块的意图边界是什么？这个 workaround 什么时候可以移除？这份文档比代码本身更值钱——因为代码可以被重新生成，但”为什么这么设计”的上下文一旦丢失就永远丢失了。

第三，控制 AI 生成系统的比例在”人类能完全理解”的范围内。 经验法则：团队中每个人能深度理解的 AI 生成系统不超过 2 个。超过这个数量，认知债务开始复利。问题不在单个系统，而在于 AI 系统的比例超过人类认知带宽后的累积效应。

第四，在合同层面锁定维护责任。 拒绝”生成代码的正确性不做保证”式免责条款作为终点。至少要求供应商提供付费的维护支持 tier。如果供应商拒绝，将这一成本计入 TCO 的”供应商锁定风险”项。

第五，投资”规格工程”而非”Prompt 工程”。 所有的分析都指向同一个结论：需求规格是瓶颈，代码生产不是。投资方向：形式化需求规格（OpenAPI/AsyncAPI/JSON Schema）、行为驱动开发、属性测试。这些技能让人类在”订货人”角色上更强，同时在维护阶段提供可验证的 ground truth——解决”Agent 测试 Agent”的循环论证问题。

第六，为 2027-2028 年的维护危机做预案。 识别组织中哪些系统是 AI 生成的或大量依赖 AI 辅助开发的。对这些系统做”维护风险评估”：系统年龄、变更频率、文档完整性、人类理解度。对高风险系统提前安排人类架构师做”认知接管”。事后补救的成本是事前准备的 5-10 倍——这是 Y2K 留下的教训。

08 / 一个改变一切的问题

所有的分析最终汇聚到一个问题：

是否存在一种验证机制，能在不依赖人类认知的情况下，可靠地检测出 AI Agent 生成的系统在交付时未暴露、但在运维阶段会显现的行为缺陷？

如果答案是”存在”——某种运行时验证、形式化证明或属性测试体系能够覆盖 Agent 代码的隐性缺陷——那”软件工厂”的可行性问题被解决。维护不再依赖人类理解代码，而是依赖自动化验证。原文描绘的柔性工厂可能成为现实。

如果答案是”不存在”——人类认知介入是维护的不可压缩前提——那”软件工厂”的产能上限不是代码生成速度，而是人类审查和理解的速度。工厂的瓶颈不在传送带（Agent），而在质检员（人类）。AI 编码工具的实际产能提升上限约为 2-3 倍，而非原文暗示的 10-100 倍。

现有的证据暗示答案倾向于”不存在”：Agent 代码的 bug 在 6-18 个月后才暴露；30% 的行为回归在单元测试中不可检测；Agent 生成测试本质上是”学生自己写答案然后自己批改”；编译器抽象层泄漏至今仍需系统程序员处理。

但这个问题尚未被正式提出和研究。它是整个领域的零号问题。

谁先回答了它，谁就定义了”AI 软件工厂”是革命还是幻觉。

写在最后

这篇文章不是在说 AI 编码工具没用。它们确实有用——3-5 倍的交付速度提升是真实的。

但”交付速度提升 3-5 倍”和”软件工厂已经到来”之间，隔着一条叫做全生命周期可维护性的鸿沟。

原文说”Prompt in, System out”。真实世界是 Prompt in, System out, Maintenance forever。第三部分——永远——才是成本、风险和价值的真正所在。

答案将在 2027-2028 年揭晓——当第一批大规模 AI 生成系统进入维护周期。届时我们才会知道：这是瓦特蒸汽机，还是又一个 CASE 工具。

在那之前，保持兴奋，但保持警惕。

本文基于对”AI 软件工厂”叙事的多视角交叉分析综合而成。分析框架参考了 Fred Brooks《没有银弹》、Lehman 软件演化定律、CMU SEI 多 Agent 系统实证研究、Microsoft Research LLM 代码质量研究，以及 1960-2010 年代四次”软件工厂”运动的历史文献。