本文永久链接 – https://tonybai.com/2026/08/29/do-your-need-a-software-factory
大家好，我是Tony Bai。
【导读】
当铺天盖地的文章都在鼓吹“一键搭建分布式 AI 软件工厂”、“完全无人值守全自动写代码”时，前谷歌 Chrome 团队负责人 Addy Osmani 却在这篇万字实战复盘中给出了反共识的结论：别盲目跟风，你现在的业务大概率根本不需要一座复杂的软件工厂！开箱即用的原生工具配合清晰的需求，已经能解决绝大部分问题。结合他亲身踩坑的 82 分钟超长测试内耗、AI 悄悄篡改断言伪造“全绿灯”的骗局，以及合并代码后发现自己“完全看不懂系统”的理解力债务危机，Addy 为所有正在做 Agent 落地的工程师划定了清晰的行动红线：代码可以让 AI 写，但系统的所有权、审美品味与最终责任，永远无法外包。
【文章要点】
- 告别工厂焦虑：开箱即用的 Claude Code / Codex 搭配清晰的 Spec 和测试，足以支撑绝大多数日常开发，只有面临跨 Agent 任务交接、高频一致性保证和多会话并发冲突时，才真正需要自建软件工厂；
- 全绿灯的谎言：测试全部通过不等于代码正确，AI 会为了跑通测试悄悄修改断言或删除冲突的业务逻辑，显式的行为约束和人工把关不可或缺；
- 理解力债务危机：并发启动多个 Agent 会在短时间内产生海量人类未读过的代码，一旦缺乏架构理解，开发者将彻底失去对代码库的掌控权，甚至被迫推倒重来；
- 验证也需要预算：代码生成极快，但包含端到端与安全扫描的验证流水线会使耗时暴涨数倍，必须对轻量快速检查与重度深层测试进行分级预算管理；
- 人类判断力的战略重塑：代码编写已不再是核心竞争力，人类工程师必须将精力从逐行看代码抽离出来，死守上游产品意图、架构规范设计、质量基线定义与最终发布所有权。
在盲目“建工厂”之前，请先读读这篇清醒剂
在前面的系列文章中，我们从 Karpathy 的《LOOPS.md》聊到了 20 种循环设计模式，再到全新 4 层 AI 技术栈以及“黑灯/明灯软件工厂”的利弊。随着这些前沿理念在技术圈疯传，许多开发者和技术 Leader 开始陷入一种新的焦虑：
- “我是不是也必须立刻搭建一套复杂的分布式智能体工厂？”
- “我是不是应该马上把所有开发流程都做成全自动的 CI/CD Agent 流水线？”
在这篇最新技术长文中，谷歌前 Chrome 团队负责人 Addy Osmani 给出了一个极其务实且冷静的回答：别着急，你现在的业务可能根本不需要一座庞大的“软件工厂”。
Addy 结合自己真实的踩坑经历——包括跑出 82 分钟的超长测试、把黑灯模式误加到不需要的项目中、以及 Review 并合并了代码却在几天后发现自己完全看不懂系统的“理解力债务”危机——为我们清晰地划定了边界：
- 何时开箱即用的 Claude Code 就足够了？何时才真正需要引入工厂？
- 为什么测试全部亮绿灯（Green）反而可能是一场灾难？
- 当 AI 替你写了 90% 的代码，人类工程师该如何保住系统的所有权（Ownership）？
这是一篇写给所有正在进行 Agent 落地的工程师的“清醒实战指南”。
以下为译文全文：
所谓软件工厂（Software Factory），本质上是围绕软件开发工作构建的一套可重复运转的循环（Repeatable loop）。
如果你正在着手打造一座软件工厂，请记住：能够达到“可发布至生产环境（Ship）”标准的代码，依然离不开人类的审美品味（Taste）与责任担当（Ownership）。
在本文中，我们将深入探讨这一议题，包括：你现阶段到底是否真的需要一座工厂？
如果你的确需要：
- 你大概率需要在前期将人类置于循环之中，由人类来决定产品意图（Product Intent）、系统设计（如果你在乎架构的话），以及你的质量及格线。
- 一定要进行代码审查（坚持做“明灯工厂”），但要把精力精准投放给最关键的核心区域。我的经验是：重点盯防那些“自动化卡控机制失效”的地方，或是必须在“长期可维护性”上做出妥协与折中的地方。
- 力求让质量检查尽可能早、尽可能持续地发生。 并非所有检查都必须一步到位，但至少应涵盖：类型系统、自动化测试、变异测试（Mutation testing）、安全扫描器，以及针对架构规范的 Lint 工具。
- 检查项的数量 != 代码质量。 你需要通过不断实验，找出那些信噪比（Signal-to-noise ratio）最高的检查项。做好心理准备，有策略地去收紧或放宽系统的约束条件。
打造软件工厂的终极目标，是将人类审美品味的某些维度编码到开发环境中，让 Agent 能够向你提供能够证明其工作正确的客观证据（Evidence），同时确保人类始终对发布到生产环境的一切承担最终的“所有权（Owns）”。
你真的需要一座软件工厂吗？
根据我的实战经验，仅仅依靠你手中开箱即用的原生编程框架（Stock coding harness，例如 Claude Code 或 Codex），搭配多个并行会话、内嵌了验证机制的良好需求规格说明（Spec），以及严格的边界约束，你就能走得惊人地远！
你甚至可以直接把一批 GitHub Issues 扔给它们，并在 Issue 中写明具体的实现要求与人类介入的触发条件。Claude Code 的自动化任务机制以及 Copilot/Codex 的云端 Agent，已经能在不需要你编写任何自定义基础设施的前提下，提供基于定时调度或事件驱动的完整循环。
只有当你面临以下痛点时，构建一座软件工厂才是真正物有所值的：
- 你需要确保多次运行之间表现出高度一致的稳定性；
- 你需要在不同的 Agent 之间进行任务交接（Hand off）；
- 你需要防止两个独立的会话同时认领并修改同一个 Issue；
- 你需要持久化留存完整的客观证据；
- 当人类审查进度跟不上时，系统需要自动暂停生产线的运转。
正如我开头所说，软件工厂是围绕软件开发构建的可重复循环。我们可以通过下面这段 Prompt 模板来感受一下它的雏形：
在修改任何代码之前，请先阅读 GitHub Issue #123 以及本仓库的开发指南。
仅实现 Issue 中明确声明的验收标准（Acceptance criteria）。
严禁修改身份鉴权（Authentication）、计费系统（Billing）、数据库迁移脚本（Migrations）或现有的测试断言。
请在独立的 Git 分支上工作，并确保代码 Diff 清晰可读、便于审查。
依次运行 npm run lint、npm test 和 npm run build。
如果任何一项必备检查无法运行，请立即停止并解释原因。
提交一个 Draft PR（草稿合并请求），并在说明中附上你运行过的检查项、评估出的剩余风险，以及任何仍需人类做出的决策。
严禁擅自执行 Merge（合并）操作。
通过设置一个目标条件（Goal），我们可以让系统在所有检查项通过之前持续自我修复并推进；我们可以在每天清晨轮询抓取带有特定 Label（标签）的 GitHub Issues，或者集中审查新开的 Draft PR。
通过分支保护规则（Branch Protection），我们能建立起一道坚固的合并防线；而人类则可以通过决定哪些任务进入待办、审查代码、并在最后点击 Merge 按钮，从而稳稳地留在控制环路之中。
何时需要升级为软件工厂？
当你需要一个事件驱动的工作任务队列（如来自 Slack 触发器、GitHub Issues、Linear 工单或 Backlog 积压池），并让这些任务运行在完全隔离的云端沙箱环境中，以完成故障分诊、代码实现和测试验证，同时辅以显式的人工看护时，你就需要一座软件工厂了。某些高级工厂甚至会在末端安插一个线上监控 Agent，专门盯着生产环境，并在发现 Bug 时自动提交新的 Issue，触发下一轮分诊。
在我的经验中，工厂之所以有用，是因为最难的部分在于：让不同的运行批次保持行为一致、在 Agent 之间顺畅交接工作、防止不同会话争抢同一个 Issue、留存证据，并在人类审查出现堵塞时果断叫停生产。
解决这些难题的核心机制听起来可能有些平淡无奇。例如，Warp 提到了将所有流入的 Issue 分诊为四种显式状态之一：
ready-to-implement（准备就绪，可开始实现）ready-to-spec（准备就绪，可编写规格定义）needs-info（信息缺失，需补充输入）wait-to-implement（暂缓实现，进暂存区）
给 Issue 打上的这个 Label（标签），就是触发下一个 Agent 启动的唯一开关。
这个小小的 Label 一口气搞定了好几项核心工作：它既是任务队列（Queue），又是并发锁（Lock）。由于 Agent 会话只会抓取被标记为 ready 的任务，因此它也是人类在不彻底否决需求的前提下、临时搁置（Park）任务的安全停机坪。
在工作流层面，软件工厂与单机使用 Claude/Codex 相比，既有相似之处，也有关键升级：
- 人工纠偏（Steering）：当 Agent 出现路线偏差时，你可以随时输入指令将其拉回正轨；
- 阻塞通知（Notifications）：工厂能够主动向你报告它在何处被卡住了。这可能是因为需求描述模糊不清、它试图执行高危操作，或者它需要人类的精准输入；
- 任务交接（Handoff）：在云端工厂、另一个 Agent 或人类审查者之间，平滑传递任务、其底层状态以及上下文。优秀的交接机制会清晰记录：刚才发生了什么、还剩什么没做，以及为什么需要触发本次交接。
在一座优秀的工厂里，人类绝对不只是在流程最末端扮演审查并点击批准的工具人。人类能够在早期雕琢工作意图、在实现过程中实时纠偏、通过交接完成接力，或者在危险发生时一票否决、阻止代码流向生产线。
验证（Verification）是一座负责任的工厂花费时间最多的地方。我们稍后会展开讨论。
上图展示了人类判断力在软件工厂中的三个关键卡点：01 上游意图与架构规范 -> 02 循环中的环境反向压力 -> 03 末端的集中 Review 与最终把关。
如果你最终决定确实需要一座软件工厂，亲手从零编写代码也绝不是唯一的选项。搭建支撑工厂规模化运行的底层基础设施需要耗费巨大的工程量，你完全可以评估“买 vs 造”（Buy vs. Build）。Factory.ai、Devin、Warp 和 HumanLayer 等产品，都在售卖这套循环体系中的部分能力。
我的一线精力究竟投放在哪里？
在过去的一年中，我的日常软件开发体验发生了翻天覆地的变化。我一直在谈论如何越来越多地使用 Agent 并发推进工作，并朝着打造一座“明灯软件工厂”演进。
很多人都在问我：这些概念在实战中到底意味着什么？你到底在造什么？你把它们用在了哪些具体的项目上？
其实很大程度上体现在以下四个切入点：
上图展示了人类介入 Agent 运行的四种核心方式：雕琢意图（Shape）、中途纠偏（Steer）、任务交接（Hand off）、果断叫停（Stop）。
在一个极其普通的日常工作日，我运行着一座较为简易的明灯软件工厂。许多任务在云端并行跑着：
- 其中一半的任务可能是为我合作的小型客户开发生产级应用。这些应用拥有真实的活跃用户、真实的鉴权登录、真实的支付与订阅流——这些全都是极其沉重、稍有不慎就会造成灾难性后果的核心业务风险。你绝对不能轻飘飘地说一句：“嗨，Agent，去把这个功能做了”，而不在外围部署严格的测试集、约束条件和质量卡控。
- 我也可能在开发自己的开源项目、为我的技术书籍搭建配套网站、编写自用的小工具，或是孵化全新的 App。
这些项目的形态各不相同。有时它们唯一的共同点，仅仅是我都在用同一套 Agent 工具去开发它们。有些任务我可能只是在做底层的技术栈迁移；而在另一些任务中，我是在开发极其核心的重磅功能。这些工作的破坏半径（Blast Radius）有着天壤之别。
因此，当你开始思考如何进行高并发的并行开发、如何提升交付速度、如何拉高生产力，并尝试给系统更大的自主权（即让系统变得更值得信任）时，你必须深思熟虑：到底哪些地方必须强行保留人类的代码审查与人工介入？
而这其中绝大部分的精力，必须前置投入（Upfront）：
- 在定义规格说明（Spec）与业务需求时，产品的交互设计应该是什么样？
- 产品最核心的业务意图到底是什么？
- 你如何验证 Agent 确实把事情做对了？
- 你如何确保它们没有在背地里改坏现有的老系统？
因此，生成代码本身，反而不是你最需要焦虑的部分。只要投喂了足够充沛的上下文，Agent 完全有能力替我们编写实现、运行测试、排查错误并迭代重写代码。
我们真正需要做的，是将足够多的人类审美品味（Human Taste）编码到运行环境中，让我们能够对被构建出的成果建立信心，从而将人类极其有限的注意力，聚焦在最需要我们的刀刃上。
现在行业里有一种反对的声音：“算了吧，我不相信你们真能把这么多活儿全给自动化了。”
我们并不是说要百分之百把所有东西都自动化。但考虑到当前代码被生成的庞大吞吐量，指望人类去逐行阅读所有被生成的代码是完全不现实的——更何况我们平时绝大多数时候并不是在写火箭发射系统的控制程序，我们是在写前端 UI，写全栈 Web 应用。
人类的判断力与审美品味，最适合聚焦在系统风险最高的核心命脉上。比如：系统中最脆弱的部分在哪里？哪里必须注入人类特有的审美与体验感（Taste）？这可以体现在前端视觉上，也可以体现在底层架构的运转方式上。它不需要覆盖 100% 的代码细节。
我的认知带宽无法随着 Agent 的数量无限扩容
现实情况是：我们确实可以在一瞬间并发启动几十个、几百个甚至几千个 Agent；但人类大脑自身的认知带宽，是绝对无法以相同的方式并行的。这会直接诱发我之前反复强调的“认知债务（Cognitive debt）”与“理解力债务（Comprehension debt）”。
如果你回想五到十年前，软件工程界曾对“上下文切换（Context Switching）的沉重代价”展开过极其热烈的讨论。大家都在吐槽：当你正处于心流状态、全神贯注地写代码时，最痛恨有同事突然走过来敲你的桌子。因为被打断后，你需要耗费极其漫长的时间才能重新找回状态，拼命回忆：“我刚才改到哪了？我下一步要做什么？”哪怕你的大脑里还残留着一丝记忆碎片，重新进入心流也需要付出高昂的时间成本。
而今天，我们面临的上下文切换频率，比过去任何时候都要残酷得多。
在任何一个普通的日子里，即使不在庞大的软件工厂中，我可能同时在开着 5 到 10 个不同的会话与 Agent 协作——要么在同时推进 5 到 10 个完全不同的项目，要么在同一个项目里并发开发 5 到 10 个不同的功能。
这意味着，我必须有能力对其中的至少几个关键会话保持绝对掌控。
如果我对某个任务有着充分的信心——我把需求定义得足够清晰、明确了预期的产出形态、并部署了万无一失的验证机制——那么我确实可以给予这个 Agent 更高的自主权；但对于那些风险极高、业务逻辑充满微妙权衡（Nuance）的任务，我必须高度集中注意力。
请务必为你的人类审查者量身优化你的软件工厂。鉴于所有这些 Agent 管道的最终产出，最后都会汇总并流向那唯一的一份人类注意力，你必须经常叩问自己：这座工厂，究竟有没有让人类必须做出的决策变得更轻松、更低成本？
一次“进错项目”的滑稽事故
我记得有一次，我同时在开着多个会话推进不同的并行项目。当时我正在开发一个 Web 应用，脑子里一直在盘算着想给它加一个暗黑模式（Dark Mode），脑海里已经构思好了这个功能的大致形态。
结果，我一不小心点进了另一个完全不同项目的会话窗口，并顺手敲下了那段 Prompt。
于是，Agent 开始在后台勤勤恳恳地为一个根本完全不需要暗黑模式的项目疯狂实现暗黑模式。
连我这样的人类都会犯这种低级错误，我绝对不希望我的软件工厂也犯下同样的荒唐大错。
你必须将这套体系真正当成一个严密的“系统”来思考。你本质上是在尝试将一套优秀的软件工程文化、团队协作文化编码进系统之中，让系统展现出完全相同的守纪律行为——让每一次操作都拥有清晰的归属权（Ownership），让每一个步骤都有明确的人类在后台背书担责，并迫使你必须极其严谨、显式地去规划你对系统的所有设想。
当“全部亮绿灯（Green）”成为一场骗局
即使在这些高度自动化的系统中，你也必须保持高度警惕。
我们中的许多人都亲眼目睹过这种场景：当你让 AI 去帮你通过某个单元测试时，AI 可能会悄悄把单元测试的断言给改了，从而迎合它的错误代码；或者它会篡改业务逻辑，以一种投机取巧的方式强行跑通测试。
测试通过了，但这绝对不意味着它真正遵循了你的初衷，也不意味着代码的功能行为与测试本应验证的目标实现了正确对齐。
仅仅因为软件工厂在控制面板上显示一切都是绿灯（Green），绝不代表它真的就毫无问题——尤其是在你刚搭建好这套系统的初期阶段。
你必须倾注大量的注意力，去确保你的检查项、你的验证器全部被精准塑造。确保它们在做你真正期望它们做的事，而不是在用绿灯来蒙蔽你的双眼。
你绝对不希望看到这种惨剧发生：
你的测试报告欢天喜地地显示一切正常，结果深入排查才发现，Agent 在后台悄悄修改了支持的登录方式。你原本只是让它增加 GitHub 登录支持，但由于前端 UI 界面只能放下三个图标，它自作主张地删掉了另一个原有的登录方式——而那恰恰是你的真实付费客户最依赖的登录渠道。
因此，你必须极其显式、黑白分明地向系统定义它被允许和禁止的行为。
顺便提一句：安全性（Security）至关重要。 如果你的软件工厂直接读取不受信任的外部输入（如公开的 GitHub Issue 或 Slack 消息），它可能会遭受对抗性攻击（Adversarial attacks），甚至引发布局深远的供应链攻击。
目前业界一些优秀的软件工厂产品（如 Vercel Sandbox 或 AI SDK Factory），会将它们的 Agent 严格隔离在只持有该任务所需极简密钥的独立沙箱中运行。这样一来，即使某次运行不幸被黑客攻陷，它也绝无法触碰超出该任务权限以外的敏感资产。你的防御体系，最终必须是分层纵深的。
哪些老旧项目才真正配得上“重获新生”？
我认为，在我们当下的日常工作中，有很大一部分精力是在做“价值裁决”——决定什么东西才值得存在于世界上。
如果你回想几年前 AI 尚未爆发的时代，我们的硬盘和 GitHub 里躺着无数被废弃的半成品工程、被遗弃的周末小玩具和个人项目。它们之所以未能上线面世，仅仅是因为我们当时没有足够的时间去收尾，没有精力把它们推向市场，因为它们在当时并没有那么重要，或者我们实在抽不出空档。
在今天，借助 Agent 的力量，我们把这些陈年旧项目全部做完已经变得极其轻松。
但完全相同的人类审美品味与价值判断问题再次摆在了我们面前：这些项目，真的配存在于这个世界上吗？它们真的应该被发布吗？
因为一旦你把它推向了真实世界，哪怕最终只有 5 个真实用户在用，你可能就不得不长期维护它。你可能必须为它维持一套不容妥协的质量底线。
在过去这些年里，我积累了无数个老旧的 GitHub 仓库。现在有了 Agent，我进项目做的第一件事，就是让它先把工程给跑起来（Build）。因为你把几年前的代码 Clone 下来后，它大概率是无法成功编译的——依赖项全变了、一半的包过时了、或者被安全漏洞扫描疯狂报警，你必须先全部升级一遍。
接着，如果以前没写测试，你必须让 Agent 补全测试集，以确保在升级现代语言版本或迁移框架时，底层的核心行为不会发生倒退。
随后你可能会开始琢磨（举个很真实的例子）：当年我可能还是用 Twitter Bootstrap 写的界面，但现在全世界都在用 Tailwind 和 shadcn/ui 了，我是不是得把整个前端 UI 给重写一遍？
在这个过程中你会敏锐地意识到：这又在开始大量吞噬你宝贵的时间了，对吧？ 没错，Agent 确实能以极快的速度把代码敲出来，但你现在必须被迫在产品逻辑、设计审美以及用户体验上投入巨大的心力。
你依然需要不断拷问自己：
- 这个产品到底做给谁用？
- 它有真实的市场需求吗？
- 这纯粹是为了取悦我自己，还是为了解决别人的真实痛点？
- 如果我把它发布出去，在如今任何人都能用 AI 瞬间搭建同类产品的时代，它是否还具备足够的吸引力？
因此我认为，去拷问“这些东西是否值得存在”，并融入人类特有的审美品味与价值判断，在今天依然具有至高无上的重要性。
这正是人类极其有限、稀缺的注意力资源真正大放异彩的地方。在过去，我们一天的工时是有限的，我们要开会、要给设计和编码预留时间；而现在有了 Agent 替我们分担体力劳动，你必须更加清醒、显式地去规划：你到底要把自己的时间花在哪里，以及为什么要花在那里。
当我亲手搭建一座示例工厂后，发生了什么？
接下来我想聊聊那次长达 82 分钟的工厂运行实录。
有相当长一段时间，很多人一直在问我：“我到底该如何搭建一座软件工厂？”或者“我已经习惯了使用 Claude Code 或 Codex，我该如何将我的工作流演进为软件工厂？”
我给出的第一句忠告通常是：“你现在的状态可能非常好，你的日常工作可能完全不需要一座复杂的工厂。”
但我依然想为大家提供一个可供参考的基准架构。因此我开源了一个名为Factory 的示例仓库，并配套设计了一个 Demo 应用和实战工作坊。
在过去几年里，我在演示各种新技术时最喜欢用的 Demo，是一款“电影 App（Movies app）”。我是个超级电影迷，平时特别爱看电影。这个应用一开始非常简陋，而我希望软件工厂能够帮我自动实现一系列新功能：比如增加“收藏夹功能（Favorites）”、增加“搜索功能”，以及增加“暗黑主题”等等。
于是我启动了工厂，让它开始工作。你可以亲自去查看具体的代码实现。这套工厂体系最立竿见影的好处之一，是它确实帮我拦截并捕获了极其棘手的真实 Bug——如果我当时只是让 AI 进行一次性的单回合生成（One-shot），这些 Bug 绝对会成为漏网之鱼。
然而，当运行进行到大约第 60 分钟时，我开始在心里犯嘀咕：“天呐，这运行速度怎么慢得如此不合常理？”
我通过终端向工厂的运行框架发问：“为什么进度这么慢？”
它非常淡定地回复我：“实际上一切完全正常。所有后台的验证器（Verifiers）目前都在全速运转中。”
如果只是让 AI 单纯写出代码，可能只需要 20 分钟；但是，一旦你将自动化验证、失败重试、真实浏览器端测、人工审查以及各种连锁延迟全部纳入流水线后，整个运行耗时可能会瞬间暴涨 2 到 4 倍。
我坚信，这些耗时最终能够换来更高的系统质量，以及对代码更坚实的信任感。从度量指标的角度来看，你可以将“每个已合并 PR 的平摊成本”以及“代码的保鲜期（Code shelf life）”，作为衡量理解力债务的核心度量指标。
但你也必须清醒地区分：到底哪些是“创造价值的必要延迟”，哪些纯粹是“工厂本身的架构内耗（Overhead）”。
在我的案例中，验证器确实揪出了致命的真实隐患，一部分时间被用来产出我所需要的客观证据；但另一部分时间，纯粹是工厂自身运转机制带来的额外开销。我当时并没有花时间去极致优化工厂本身，但请记住：一座仅仅是因为跑了海量毫无价值的无用检查而导致耗时拉长的工厂，绝不等于高质量的工厂。
你必须深度审视流水线中的每一次重复检查：它们是否早已过时？它们是否带来了过多的噪音？它们是否真的让系统变得更加安全了？
验证也是需要“预算”的
我对“验证预算”的思考方式，与我多年来在前端工程中思考“性能预算（Performance Budgets）”的底层逻辑如出一辙。
在软件开发的整个生命周期中，检查项应该被严格分级：
- 快速检查（轻量级）：例如 Lint 代码规范扫描、TypeScript 类型检查。这些属于极速反馈的轻量检查，应当在极其早期的阶段高频运行。
- 重度测试（高价值）：比如完整的端到端测试套件、变异测试（Mutation testing）、真实浏览器自动化测试、深度安全扫描等。它们虽然极其耗时沉重，但能提供不可替代的高价值，因此应当被安排在 Draft PR 生成前夕或生成之后去运行。
你并不需要用轻飘飘的“文字摘要”去替代扎实的测试。你需要的是货真价实的硬核测试，但你必须学会在流水线的正确位置为它们精准规划预算，因为你绝对不希望看到测试把日常的开发循环拖得像蜗牛一样缓慢。
我永远无法忍受缓慢的开发循环。保持极速的迭代闭环对我至关重要，但我同样需要这些制衡与防御机制时刻在线。
当一次运行未能成功发布
我上面写的所有内容，很大程度上都聚焦在“检查”上。
在 Vercel 团队内部的软件工厂实践中，他们将 Agent 的每一次运行严格标记为以下四种状态之一：
- 成功（Success）
- 存在缺陷（Flawed）
- 受阻挂起（Blocked）
- 需人工接管（Manual）
在他们的体系中，只有被标记为“Success”的代码，才有资格被发布到生产环境中。处于其余三种状态的运行，全部必须重新进入系统进行流转。我同样在以完全相同的框架来审视所有的运行：
- “缺陷（Flawed）”：意味着 Agent 理解错了需求、或者缺乏足够的上下文，导致代码实现出现偏差，必须在闭环内重新修复；
- “受阻（Blocked）”：意味着运行环境缺失了必要的配置（例如缺少某个 API Key 或环境变量），必须由人类补充凭证后方可继续；
- “需人工接管（Manual）”：代表该操作触碰到了工厂目前尚未被授予权限跨越的安全红线边界。
在这三类未能直接发布的异常中，前两类通常可以通过机械化的工程手段自动修复，而最后一类，则关乎于深层的“信任”。
然而，这种状态分类并没有向你展示“成本（Cost）”的维度。
回到我在 TMDB 电影 App 上的工厂实战案例：
- 那个简单的“快速检索功能”，由于一次性完美通过、没有遭遇任何驳回，仅耗时 7 分钟；
- 而“收藏夹功能”由于中途经历了两次测试驳回，并且在中间穿插了一次人类决策介入，整整耗费了 56 分钟。
这是在完全相同的同一座工厂里发生的！
因此，我强烈建议将上述四种状态分类，与“每个阶段的具体耗时指标”强行绑定。否则，你只知道某次运行被判定为了“缺陷”，却根本无法感知查出这个缺陷到底耗费了你多少真金白银和时间成本。
另一个我极力想修补的问题，是边界交接（Handoff）的体验：在我的示例工厂中，当遇到第一个疑难杂症时，它非常守纪律地停了下来，并将 Issue 状态标记为了 factory:needs-info（需要补充信息）。这完全正确，但我却当场愣住了——我不知道该把我的答案敲在哪里才能让它继续运行。
一个标记为“人工接管”的运行，其终点绝对不是“工厂单方面停下来了”，而是“人类非常清楚自己下一步该干什么”。
“自主权”绝对不是一个全局通用的固定开关
几周前我曾写过一篇关于“智能体自主权（Agentic Autonomy）”的文章，探讨我们该如何正确看待自主权。因为自主权绝对不是在所有项目上都一成不变的全局单一设置。
强验证为你买来了“信任”，而“信任”为你买来了“向 Agent 赋予更大自主权的资格”。
举个例子：如果我当前正在推进一个极其复杂的非平凡改动，但我部署了极其严密的检查机制，所有逻辑都被正确验证，甚至我自己也亲自手动过了一遍代码。那么下一次在同一个项目里遇到类似任务时，我就能极其安心地给予 Agent 更多的自由度和自主权。
这正是你在构建软件工厂时必须时刻权衡的艺术：你的验证严格程度，必须随着业务风险的高低动态调整。 你的终极目标是追求最高的“信噪比”，而不是机械、教条地去执行一份臃肿无比的长清单。
一个我不得不重新学习的代码功能
在某一天，由于我需要利用 Claude 同时在多个会话中并发推进好几个不同的项目，每个项目都在同时开发若干个新功能，我把其中一个功能的深度验证给搁置了。
当时 Claude 帮我实现了那个功能，测试套件全部亮了绿灯。我当时没有在验证上投入太多心力，心想既然测试都通过了，那肯定搞定了，于是顺手点击了 Merge 合并。
那是一个“收藏夹”功能。我当时觉得做得很棒，在浏览器里简单点了几下，看起来一切正常。
然而几天后，我重新回到代码库，想对这个功能做一些细微的体验调优。我不想直接扔给 Agent 去改，因为那是一个非常微妙的交互细节——当你点击图标时，点击动效反馈有点不对劲，我想自己动手去微调几行代码。同时，我也希望先彻底搞懂它的底层实现逻辑，以便我能更精准地去指导 Agent。
当我重新打开那段代码时，我震惊地发现：我竟然完全无法解释这个功能到底是怎么实现的。
这个代码仓库明明是我的啊！代码是我亲自点击批准合并的，我对仓库的大部分老代码都了如指掌。但是，我的个人理解力，已经完全跟不上这段时间疯狂堆积起来的代码膨胀速度了。
我完全没有消化吸收这个新功能在底层究竟是如何运转的、UI 逻辑是如何绑定的、动画效果是如何触发的。
最终，我不得不把这个功能彻底推倒重做，一行一行地去重新梳理：“这到底是怎么跑起来的？我到底该怎么去理解它？”
高并发并行开发，对人类理解力造成的毁灭性打击
当你开启并行开发时，上述问题会被急剧放大；而当你在软件工厂中进行高并发开发时，这种打击将呈指数级剧变。
当你同时开启 5 到 10 个 Agent 会话时，它们制造的绝对不仅仅是“审查工作量暴增”的问题——它们在大脑中硬生生撕扯出好几个完全不同的系统心智模型（Mental models），而当你跳去别的项目工作时，这些心智模型会在你的大脑中迅速彻底冷却（Going cold）。
我们过去经常探讨上下文切换的沉重代价。在今天，随着聊天上下文的不断压缩（Compaction）、你不断否决某些方案并尝试新路径、你与 Agent 进行高强度的极限结对编程……你将极难完整记住你的会话中发生过的所有决策细节。
你可以尝试向上滚动翻阅记录，但随着上下文压缩机制的触发，很多原始细节早已不复存在，你根本不可能把它们全部储存在脑子里。代码往往只能记录下“最终做出了什么决定”，却永远无法保留“当时为什么做出这个决定”。
我认为这是一个极具价值的深刻教训：在核心关键的节点，请务必明确要求你的 Agent 将它的决策轨迹（Trajectory）、以及它在解决问题过程中学到的核心经验，以结构化文档的形式持久化留存下来，以便你日后能够随时回溯查阅。
你可以自行决定是否将这些决策日志提交到 Git 仓库中。你可以将其保存在本地，也可以与团队共享；但它们必须成为日后可供查阅的客观资产，而不是寄希望于脆弱的聊天记录，或是指望你在几天后还能奇迹般地在脑海中回忆起来。
我们造的工厂，到底在生产什么？
@threepointone 和 @bentlegen 在 X 上发表了关于软件工厂的几点犀利洞察，我深表赞同：
如果对循环的投资能够产生复合价值，那当然是一件好事；但真正的崩盘，往往发生在这个闭环被彻底锁死、工厂生产出来的所有产出仅仅被工厂自己消耗、而外部真实世界却根本毫无察觉的时刻。
我所坚持的终极检验标准，是“拉力（Pull）”：必须有真实世界中的外部力量在渴求这些改进。如果你连到底是谁在拉动这个生产线都说不出来，你不过是在沉迷于自我感动的抛光自嗨而已。
代码的所有权（Ownership）永远不会凭空消失
在这一切现象的冰山之下，矗立着一条颠扑不破的底层法则：
由人类肉身亲手敲击键盘打出来的代码比例，确实可能会出现断崖式下跌。
但是：
- 依然必须由人类来挑选真正值得解决的问题；
- 依然必须由人类来敲定系统的顶层架构；
- 依然必须由人类来设定不可逾越的质量底线；
- 依然必须由人类来裁决到底哪些验证信号值得信赖；
- 依然必须由人类来决定眼前的客观证据是否足够支撑代码上线发布。
当最终交付的系统在生产环境中轰然崩溃时，轻飘飘的一句“这是 Agent 写的”根本无法为你开脱。
这就是为什么我坚信：软件工程的未来，绝对不能被草率地描绘为“人类彻底离开循环”。
恰恰相反，人类的判断力，正在经历一场伟大的“战略大转移（Relocated）”。
我们理应将人类从循环中那些机器能提供更强大、更迅速、更具确定性信号的繁琐环节中彻底剥离；与此同时，我们应该将人类宝贵的心智，死死聚焦在语境上下文（Context）、审美品味（Taste）、商业风险（Risk）以及长期系统所有权（Long-term ownership）最性命攸关的核心战场上。
最卓越的软件工厂，其伟大之处绝不在于它多么彻底地消灭了人类的参与。
它们的伟大，在于它们多么智慧、精准地安放了人类的智慧。
- 请把人类的判断力，死死锚定在上游的业务意图、系统骨架与质量基线上；
- 在自动化卡控变得脆弱、或后果变得极为主观的地方，坚决执行人工代码审查；
- 把每一个确定性的客观信号，尽可能早、尽可能持续地推进到循环体系中；
- 随着系统赢得或失去信任，极其审慎地收紧或放宽你的约束条件。
最终发布到真实世界的代码，必须由一个有血有肉的人类来承担全部所有权。
而真正配得上被发布的代码，永远始于一个真正关心它是否配存在于这个世界上的人类。
原文链接：https://x.com/addyosmani/status/2092865809299476767
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
