工厂归来

AI 如何复活软件工厂之梦，敏捷能否在其中幸存

Polity 发布 | 2026 年 7 月
作者：Alexandre Kotcherguine，Polity Vision Officer & Investor；
Kevin Riedl，Wavect GmbH Managing Partner

本文讨论软件开发方法论与组织设计，依据截至 2026 年 9 月 2 日复核的原创研究、官方记录和企业一手披露。供应商研究和基准结果均明确标注。本文不构成任何专业、法律或投资建议。

执行摘要

1968 年，Douglas McIlroy 在 NATO Conference on Software Engineering 上提出大规模生产并按目录订购软件组件。这是构建可重复软件供应链的重要工业类比。1970 与 1980 年代出现了具体的软件工厂计划；2001 年的《敏捷宣言》后来把自己定位为文档驱动、重量级开发流程的替代方案。本文认为，agentic AI 以按需生成贴合代码的新形式复活了 McIlroy 的愿景。证据仍然复杂：GitClear 2026 年的供应商研究显示可维护性信号恶化；METR 2025 年初的随机试验发现专家使用 AI 后更慢，尽管他们认为自己更快；METR 后续实验则因选择偏差和测量问题无法给出可靠的当前估计。工程纪律因此沿栈上移到规格与验证系统。Stripe 的一手披露提供了生产案例：每周合并一千多个完全由 Minions 编写的 pull request，但仍由人评审，并依赖大量工具与测试。决定性变量是治理，而不只是模型。

失败了两次的梦想

1968 年会议的组织者将其命名为 NATO Software Engineering Conference。会议报告既记录了建立软件工程学科的愿望，也记录了对其含义的分歧 (1)。McIlroy 在会上提出标准组件的系列和目录，并明确将它们与螺丝、电阻和工业子组件类比 (2)。这种类比接近 Taylor 对工作的拆分和标准化，但把 McIlroy 的提案称为「明确的 Taylor 式方案」超出了原文。Michael Cusumano 的实地研究记录了 Hitachi 自 1969 年起的 Software Works，以及 NEC、Toshiba 和 Fujitsu 自 1970 年代中期起的工厂计划 (3)。

这些计划并未建立通用的软件目录经济。Cusumano 描述的是各公司不同的工具、复用资产、标准方法、培训和质量控制组合，结果也各不相同 (3)。2001 年，《敏捷宣言》的十七位签署者寻求文档驱动、重量级开发流程的替代方案 (4)。工业化方法取得过局部收益，但没有消除对上下文、适应性和工程判断的需求。

为什么这一次不同

Agentic AI 以软件工厂从未做到的方式改变了机制。McIlroy 的组件必须先由人编写、编目、泛化和维护，别人才能订购；泛化的开销正是杀死复用的原因。编码智能体消解了这笔开销。它不是从货架上取回一个预制组件，而是按需合成一个贴合的组件，依据的是一段意图描述，针对的是眼前代码库的具体上下文。目录不再是有限且由人维护的；它实际上就是模型在你提出请求时生成所需零件的潜在能力。

这种能力不再只是推测，但基准历史需要准确表述。2023 年最初的 SWE-bench 论文在完整测试集上的最佳结果是 1.96%；SWE-bench Verified 后来才发布，因此该数字不是 Verified 分数。Anthropic 在 2026 年 2 月报告 Claude Opus 4.6 的 Verified 分数为 80.84%，官方维护者也记录了污染风险和接近上限时名次过于密集的问题 (5)。Anthropic Economic Index 在 2026 年 3 月报告约 49% 的职业曾在至少四分之一任务上使用 Claude。这是平台观察到的累计覆盖率，不是 AI 完成全部工作的比例 (6)。

旧的张力，如今可以测量

GitClear 2026 年 6 月的供应商研究分析了 2023 年至 2026 年上半年的 6.23 亿次变更。相较 2023 年，报告称跨文件函数调用下降 35%，重构移动行下降 70%，代码块重复上升 81%，单次提交内复制粘贴上升 41%，两周 churn 上升 15% (7)。这些是 GitClear 数据集中的相关性，并非 AI 影响的受控因果估计。用 Ward Cunningham 的比喻说，更快交付却推迟整合，可能形成最终拖慢交付的技术债利息 (8)。

生产力的图景同样是双刃的。2025 年年中，非营利组织 METR 进行了该领域第一项关于 AI 编码辅助的随机对照试验：十六位经验丰富的开源开发者，在自己熟悉的成熟代码仓库上完成 246 项真实任务，AI 的使用被随机允许或禁止 (8)。开发者预测会提速 24%；专家经济学家和机器学习研究者的预测还要更高。测得的结果恰好相反：使用 AI 时任务平均耗时延长了 19%。比变慢更引人注目的是感知落差：即使亲历了这一切，开发者仍估计 AI 让他们提速了 20%。这是 Goodhart 的阴影出现在新场景中：每一项可见指标（提交量、pull request 数量、交付行数）都可以攀升，而真正重要的东西，即得到正确且可维护结果所需的时间，却朝相反方向移动。一个互补的担忧，实践者已开始称之为理解债（comprehension debt），点出了更深的风险：当生成速度超过理解速度，唯一能可靠评审 AI 输出的人（资深工程师）成为瓶颈，而他们漏掉的问题会进入生产环境。

第一个反对意见：信号正在变化

每个数字都是快速移动目标的快照。METR 对 2025 年末工具的实验估计，十位回归参与者提速 18%，新参与者提速 4%；但两个置信区间都包含零。METR 认为参与者选择、任务选择和计时问题使实验无法可靠估计当前效果 (10)。DORA 的结果同样复杂：2024 年每增加 25% AI 采用率，与吞吐量下降 1.5% 和稳定性下降 7.2% 相关；2025 年更高采用率同时与更高吞吐量和更高交付不稳定性相关 (11)。这些观察结果不能证明因果关系。

更新后的证据没有证明简单的「反转」。模型、工具和参与者行为改变了，测量也更困难。更好的上下文、智能体框架、评审流程和规格优先实践仍是合理且可检验的风险控制手段，但 METR 后续研究无法把它们确定为提速原因。组织应测量自身的端到端结果，包括评审时间、返工、事故和可维护性。

手艺去了哪里：沿栈上移

这个悖论的解法在于：AI 并不废除工程纪律，而是重新安置它。敏捷签署者捍卫的实践（测试先行开发、持续集成、重构、对代码健康的维护）不会因为机器来写代码而过时。它们从键击迁移到规格说明，从敲代码的动作迁移到定义、约束和验证代码的动作。这一迁移最清晰的表达，是规格驱动开发（spec-driven development）在 2025 至 2026 年间的迅速兴起。这种实践是在调用编码智能体之前，先编写一份结构化、纳入版本管理的规格说明（目标、约束、验收标准）。这样智能体拿到的是需要实现的明确意图，而不是需要揣测的模糊提示。

若要做具体工具决策，而不是阅读历史论证，我们的面向生产团队的 GitHub Spec Kit 评测分析了当前命令、局限、安全边界、成本和试点设计。

Andrej Karpathy 在 2025 年 2 月创造了「vibe coding」一词，用来描述一种刻意松散的工作流：开发者基本不再阅读代码，直接接受模型生成的变更。他的原帖把它定位为一次性周末项目的做法，而非生产方法 (12)。规格驱动开发是更结构化的一类实践。GitHub Spec Kit 把目标、约束和验收标准作为版本化输入，再由此生成计划与实现 (13)。这并不会自动保证规格正确，也不能说明所有编码工具都已采用这种方式。

人类角色随之等比例转移。agentic 工厂中的工程师花更少时间编写基础代码，花更多时间在架构、规格精确性和质量把关上：这是最完整意义上的产品所有权。实践者文献中反复出现的比喻很贴切：AI 搬运石块；金字塔仍由建筑师设计并检验。这不是工程判断的贬值，而是它的浓缩，这恰恰解释了为什么把判断抽走、指望模型来补上的组织，会遇到 GitClear 测得的重复与 churn。模型供给代码。它不供给用心。

守住敏捷：治理问题

论证在这里与关于企业 Agile 的旧论证重新汇合，因为失败方式押着同一个韵脚。最初的软件工厂移除手艺判断，并把结果称为工业化；企业 Agile 移除技术实践，保留仪式；对 AI 的粗心采用移除理解，保留速度仪表盘。每一种情形中，可见、可审计的表层被保留，承重的实质被掏空。因此，agentic 工厂并不自动等于敏捷的复兴；它是一个岔路口。走下一条路，AI 成为终极的去工程化工具：一台以工业规模生成未经评审、重复、无视上下文代码的机器，所有生产力指标一路绿灯，技术债与理解债却在底下复利累积。走下另一条路，它成为第一个能同时交付工厂吞吐量与手艺适应性的工具。

分开两条路的是治理，而其组成部分如今已被相当清楚地理解。它们包括：把规格纪律当作组织能力而非个人习惯（存活的、纳入版本控制的规格，能在任何单次智能体会话之外延续）；在智能体输出与人工验收之间设置自动化质量关卡，这样一个每周产出一千个 pull request 的智能体，即便漏洞率只有百分之一，也不会悄悄交付十个新弱点；针对新失败模式重新装备的评审工作流，因为这些失败模式是结构性、安全形态的，而不是错字形态的；以及持久、受治理的上下文（随代码库一起旅行的共享记忆、约定与约束，让智能体不再重新引入模型默认的重复）。对受监管领域（金融服务、医疗，以及 Polity 所在的链上金融基础设施）而言，这层治理不是可选的抛光，而是 agentic 吞吐量得以被接纳的前提条件。最初的工厂自上而下施加的控制、企业 Agile 作为仪式施加的控制，在这里被重新构想为嵌入开发基底本身的纪律，贴近工程师，以可执行的规格说明和自动化验证来表达，而不是工头的账簿。

对部分受监管用途，这也是法律设计问题。根据合并后的 EU Artificial Intelligence Act，第三章第 1 至 3 节自 2027 年 12 月 2 日起适用于附件 III 高风险系统，自 2028 年 8 月 2 日起适用于附件 I 产品型高风险系统。第 11、12 和 14 条要求真正落入高风险类别的系统具备技术文档、自动事件记录能力和有效人工监督 (14)。版本化规格、流水线审计轨迹和人工批准关卡可以支持这些控制，但不自动等同于法律合规。

工厂成真：一个实例

2026 年 2 月，Stripe 介绍了无人值守的一次性编码智能体 Minions。Stripe 称，每周有一千多个完全由 Minions 编写的 pull request 在人工评审后合并。其 2026 年开发者主题演讲也确认，每周有一千多个此类 pull request 经人工评审和批准后进入生产。Stripe 2025 年年报披露总交易量为 1.9 万亿美元，但这不表示每个 Minion 都接触支付关键代码 (15)。

Stripe 把结果归因于远不止模型：隔离开发环境、代码库上下文、按位置应用的规则、linting、从超过三百万项测试中选择执行的测试，以及人工评审。Minions 基于 Block 开源智能体 Goose 的分叉，但 Stripe 的平台和内部工具是公司特有的。公开资料证明高智能体吞吐量可以与确定性检查和人工批准并存，但没有公布受控对比、缺陷率或每个 pull request 的成本 (15)。

结语：有良知的工厂

McIlroy 1968 年的提案，目的地对了，路线错了。他相信工业化需要标准化的、由人编目的零件，以及管理它们的 Taylor 式装置；那条路线杀死了软件需要的敏捷和工程师供给的判断。Agentic AI 走另一条路抵达同一目的地（按需生成贴合的组件，而不是订购通用组件），并由此移除了让工厂折戟半个世纪的那个具体障碍。但它以新的形式继承了原罪。把模型当作工程文化的替代品，而不是由工程文化执掌的工具，这种诱惑与掏空字面工厂、继而掏空企业 Agile 的诱惑一模一样，如今却以远更快的速度和更大的规模唾手可得。

最强的反对意见仍然是：如果智能体最终能够定义规格、编写、测试和评审，那么「守住手艺」也许只是过渡阶段。Stripe 已证明人类不必亲手输入每个合并变更。然而，其公开系统仍依赖人工评审、确定性检查和工程师设计的基础设施。持久不变的要点不是每个 pull request 永远都要以相同方式人工检查，而是责任组织仍必须定义要构建什么、什么证据算正确、哪些失败可容忍，以及何时允许自动化批准变更。

敏捷签署者花了二十年试图传达的教训，原封不动地适用于 agentic 时代：流程之轻，必须由其下工程之强来挣得。AI 让轻几乎免费，让强几乎可选，这正是为什么强如今必须是一个刻意的选择：编码进规格说明，由质量关卡强制执行，并由那些角色已从编写代码上升为治理代码创造的人所拥有。工厂已经归来。它是把软件工业化还是去工程化（是守住敏捷，还是仅仅自动化敏捷的毁灭），将不由模型决定。一如既往，它将由组织是否选择守住手艺来决定。

企业 Agile 的历史教导我们，一种方法变得危险，不在于它错误，而在于它的仪式比赋予它意义的手艺活得更久。agentic 工厂以更高的速度提出同一场考验：它将奖励那些把工程纪律沿栈上移的组织，并以前所未有的速度惩罚那些把打字的消失误当作工程需要消失的组织。

关于 Polity

本文属于 Polity 治理模型内部持续推进的治理与思想领导力出版项目。Polity 的核心论点是，持久结果由治理架构塑造，也就是工作、价值与义务借以形成的规则、激励和制度。agentic 软件工厂正是这个意义上的治理问题：同一种代码生成能力，取决于包裹其外的纪律，既可以工业化，也可以去工程化。Polity 为受监管数字金融建设基础设施，其治理框架旨在连接去中心化系统与机构级合规要求；如何在不牺牲保证的前提下，把自主、高吞吐量的软件生产引入受监管环境，是它直接面对的问题。

关于 Wavect

Wavect GmbH 是一家奥地利软件工程机构，为初创企业、规模化企业和大型企业构建产品导向的软件。服务涵盖全栈开发、兼职工程与产品领导、软件质量保障，以及人工智能、区块链和零知识系统的应用工作。Wavect 已为 Polity 项目提供软件开发与质量保障服务，合著者 Kevin Riedl 是公司 Managing Partner。更多信息见 https://wavect.io。

免责声明：本文仅为信息与教育目的发布，不构成专业、法律、金融或工程管理建议。研究数字已依据引用来源复核至 2026 年 9 月 2 日；部分来自样本有限的受控研究或供应商观察数据，正文已明确说明。合著者 Kevin Riedl 是 Wavect GmbH 的 Managing Partner，Wavect 为 Polity 项目提供服务。文中观点属于作者本人。

参考文献与一手来源

1. Naur, P. and Randell, B. (eds.) (1969). Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Original 1968 conference report. NATO report (reviewed 2 September 2026).
2. McIlroy, M.D. (1968). “Mass Produced Software Components”. Author-hosted text (reviewed 2 September 2026).
3. Cusumano, M.A. (1989). The Software Factory: A Historical Interpretation. Field research based on company data, site visits and manager interviews. Computer History Museum archive (reviewed 2 September 2026).
4. Agile Manifesto authors (2001). Official history; official manifesto (reviewed 2 September 2026).
5. Jimenez, C.E. et al. (2023). SWE-bench; Anthropic (2026), Claude Opus 4.6 System Card; SWE-bench public experiments. Original paper; system card; experiment records (reviewed 2 September 2026).
6. Anthropic (2026). “Anthropic Economic Index report: Learning curves”. Economic Index (reviewed 2 September 2026).
7. GitClear (2026). The Maintainability Gap: AI Code Quality in 2026. Vendor observational research covering 623 million changes. GitClear report (reviewed 2 September 2026).
8. Cunningham, W. (1992). “The WyCash Portfolio Management System”; Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Cunningham report; METR study (reviewed 2 September 2026).
9. Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR study; paper (reviewed 2 September 2026).
10. METR (2026). “We Are Changing Our Developer Productivity Experiment Design”. METR follow-up (reviewed 2 September 2026).
11. DORA (2024; 2025). Official software-delivery research. 2024 report; 2025 report; 2025 errata (reviewed 2 September 2026).
12. Karpathy, A. (2025). Original “vibe coding” post (reviewed 2 September 2026).
13. GitHub (2026). “What is Spec-Driven Development?” Spec Kit documentation (reviewed 2 September 2026).
14. European Union (2024, consolidated 27 July 2026). Regulation (EU) 2024/1689, Articles 11, 12, 14 and 113, as amended by Regulation (EU) 2026/1744. Consolidated AI Act; amending regulation (reviewed 2 September 2026).
15. Stripe (2026). Minions engineering posts, developer keynote and 2025 annual letter. Part 1; Part 2; keynote; annual letter (reviewed 2 September 2026).