工厂模型：Coding Agent 如何改变了软件工程
The Factory Model: How Coding Agents Changed Software Engineering 原文发布于
最近 agentic engineering 领域发生了一些变化，“感觉”上抽象层级又一次变了。不是那种工具略微变好、工作流逐步演进的寻常变化，而是一次阶跃。写了几十年软件的开发者们都在用同一种方式描述它：这门手艺的重心移动了。
眼下你能做的最有用的事，是同时把两个想法放在张力之中。写代码这件事已经发生了剧变。而软件工程，就其核心而言，没有变。 两者之间的那道鸿沟，正是有意思的故事所在；能否清楚地理解它，决定了工程师在这个时代是如鱼得水，还是被时代甩在身后。
我读了 Cursor 的 Michael Truell 对此的看法，想在此基础上展开谈谈。
抽象的弧线
软件工程的历史，就是不断提升抽象层级的历史。 我们从比特走到指令，从指令走到函数，从函数走到对象，从对象走到服务，从服务走到分布式系统。技术栈上的每一次跃升，都让单个开发者更高效，也扩大了能参与构建软件的总人口。
汇编让位于 C。C 让位于托管语言和垃圾回收。托管语言让位于框架、包生态和云基础设施。每一次转变在当时都显得颠覆性十足。而事后看，每一次都只是一条漫长而一致的弧线上的下一步。
我们此刻正在经历的，是同一条弧线上的又一步。我们正从编写代码，转向编排那些编写代码的系统。
这个框架由 Grady Booch 提出，他称之为软件的第三纪元：一个由抽象层级上升所定义的新黄金时代，开发者的工作从编写指令转向定义意图。
这个框架之所以重要，是因为它告诉你什么该抓住、什么该放手。
AI 编码工具的三代
把这个演进过程说得精确些是有帮助的，因为把几代工具混为一谈，会导致低估实际上已经改变了多少。
第一代是加速版的自动补全。预测下一行、填充样板代码、在重复模式上省下击键的工具。有用，确实省时间。但工作流和从前一模一样：你掌舵，工具辅助。反馈回路是：写代码、运行、调试、重复。AI 只是减少了这个回路内部的摩擦。
第二代引入了同步式 Agent。你用自然语言描述一个任务，模型生成代码，你审查、纠正、迭代到可用的结果。这在栈上又往上走了一层。更少打字，更多描述意图。但你仍然在场参与每一步。Agent 是协作者，不是自主的工作者。上下文由你掌握，下一步由你指挥，错误由你实时捕捉。
第三代引入了自主 Agent。这些 Agent 可以拿着一份 spec 独立跑三十分钟、一小时、几个小时，而且越来越多地能跑上几天。它们搭环境、装依赖、写测试、撞上失败、上网查方案、修复失败、写实现、再测一遍、配置服务，并产出可供你审查的工件。你把任务交给它们，去忙别的事，回来时看到的是日志、预览和 pull request。你不再逐行交互，而是定义结果、审查产出。这就是 Agent 集群乃至自我改进的 Agent 登场的地方。
这以一种很难在亲身体验之前完全说清的方式，改变了工作的节奏。三个月前还是周末项目的任务，现在变成了你启动一下、三十分钟后回来看一眼的事。
工厂心智模型
对这个新范式最有用的心智模型是：你不再只是在写代码。你在建造那座建造你软件的工厂。
这座工厂由成群的 Agent 组成。每个 Agent 有一项任务、一套工具带（仓库、测试运行器、部署脚本、文档）、一份上下文（spec、架构决策、既有约束）和一个反馈回路。你不再手把手带着单个 Agent 完成单个任务，而是并行启动许多 Agent。一个处理后端重构。一个实现某个功能。一个写集成测试。一个更新文档。你审查产出、给出反馈、完善 spec、再次部署。
这个类比比乍看之下更深。工厂有质量控制。工厂有流程文档。工厂的输入必须精确指定，否则产出就会出错。当环境不可靠时，工厂会停摆。所有这些性质都直接映射到 agentic 软件开发上，而认真对待这个类比，会把你引向那些真正重要的投入。
在那些激进采用这一模型的团队里，已合并的 pull request 中有相当大一部分如今来自在云环境中自主运行的 Agent。这已经不是理论，而是越来越多工程组织的生产现实。
Cursor 的观点，“开发者的工作正在变成构建那个构建软件的系统，也就是工厂，而不只是产品”，以及“审查想法比审查代码有趣得多”（视频），与这些看法不谋而合。
这里有一个 onboarding 的平行关系
关于 Agent 实际行为最引人注目的模式之一，是它们的工作循环与新工程师入职（onboarding）的过程何其相似。
你递给它们一份 spec。它们拆成子任务。它们探索代码库，摸清地形。卡住时，它们搜索提交历史。它们运行 git blame，弄清上一个碰过某个子系统的人是谁。它们通过 Slack 或类似的沟通渠道向合适的人求助领域知识，然后继续。它们持续迭代，直到产出满足验收标准。
这个循环让人感到熟悉，因为这就是人的工作方式。其含义相当重大。Slack 和邮件正在成为人与 Agent 之间的接口，而不只是人与人之间的。Git 历史正在演变成一张知识图谱，供 Agent 在其中穿行，以理解架构决策。文档正在变成自主执行的训练材料。
如果你想清楚地思考现在该在代码库上做什么投入，问问自己：一个新工程师，只凭现有的文档和提交历史，能否理解代码为什么被组织成这样？如果答案是否，那么 Agent 在那里同样会举步维艰，你本可以获得的杠杆也会大打折扣。
你的 spec 就是杠杆
下面这个洞见会重塑你对自己作为工程师的价值的看法。
如果你能编排二十、三十、五十个并行运行的 Agent，那么平庸产出和卓越产出之间的差别，几乎完全取决于你的 spec 的质量。在那个规模上，含糊的思考不只是拖慢你，它会成倍放大。模棱两可的需求会传播到几十个并行的自主运行中，每一个都朝着略微不同的方向略微走偏。前期糟糕的架构决策影响的不是一个实现，而是整个集群。
除非你深刻理解架构、集成边界、边界情况、失败模式，以及那些绝不能被打破的不变量，否则你写不出一份能在那种环境里存活的 spec。 Spec 不再是一段 prompt。Spec 是被显式写出来的产品思考。
这就是为什么强工程师从这些工具里获得的杠杆比弱工程师更多，而不是更少。敲代码的机械工作正在被自动化。理解系统的认知工作正在被放大。你花在培养真正的架构理解和系统思维上的每一个小时，如今都会在整个自主工作者集群上产生回报，而不只是在你自己的产出上。
什么其实没有变
这里值得说得精确一些，因为围绕 AI 编码的炒作会给人一种印象：传统的软件工程技能已经被废弃了。
并没有。想想 agentic 开发仍然需要你提供什么：
清晰的需求。如果你无法以一种可被评估的方式说清成功是什么样子，再多的自主执行也产不出它。Agent 无法澄清从未被交给它们的需求。 它们会用假设填补空白，而这些假设会层层累积。
强有力的抽象。给 Agent 一个模块边界清晰、接口连贯、关注点分离良好的精心设计的系统，它产出的结果会好于给它一个一切依赖一切的纠缠代码库。当 Agent 来做实现时，干净的架构不会变得不那么有价值，反而更有价值，因为 Agent 会放大它所处系统的各种性质。
可靠的测试。这值得单独一节。
审慎的权衡。Agent 为既定目标做优化。它们不会自然地平衡相互竞争的关切、预见二阶效应，或者在一个技术上正确的方案其实是错误的产品决策时发出提醒。这种判断仍然在你身上。
人的监督。Agent 做出的工作令人印象深刻，它们也会犯自信满满的错误。产出质量高到足以通过随意的审查，这意味着对你审查能力的要求实际上是提高了，而不是降低了。
为什么测试比以往任何时候都重要
好的测试和测试驱动开发（TDD）本来就是好实践。在 agentic 工作流里，它们变得近乎强制。
这个想法足够精确，值得说清楚。红/绿 TDD 意味着你先写测试，再写实现。你确认测试失败（红色阶段），然后迭代实现直到测试通过（绿色阶段）。这个顺序不是可有可无的仪式，它是让你有信心相信实现真的在做你以为它在做的事的机制。
当只有一个开发者写代码时，跳过测试先行的代价是：你可能写出一个无论实现对不对都能通过的测试，或者漏掉一些边界情况、日后以回归的形式被抓出来。这些是真实的代价，但可控。
当一个 Agent 集群在几十个并行任务中生成代码时，这些代价会严重累积。一个以通过测试为优化目标的 Agent，总会找到通过它们的办法。如果测试是在实现之后写的，它们测的很可能是实现碰巧做了什么，而不是它应该做什么。 于是你手里有了一大片代码，配着一套确认了错误东西的测试套件。一套全面的、测试先行的套件，是你手上确保自主产出真正正确、并在代码库增长时保护既有功能的最有效杠杆，没有之一。
“红/绿 TDD”是每个好模型都听得懂的简写。它抓住了一种具体的纪律：先写测试，实现之前确认它们失败，通过正确的实现而不是通过钻测试的空子让它们通过。在任务开始时告诉 Agent 使用红/绿 TDD，是你能给出的杠杆最高的指令之一。
未解决的问题是验证，不是生成
生成已经不再是瓶颈。验证才是。
Agent 能产出令人印象深刻的东西。挑战在于有把握地知道那些产出是否正确。有几个因素让这件事比乍看之下更难。
改动之前能通过的测试，并不意味着它们能抓住这次改动引入的回归。Agent 能写出技术上有效、却漏掉关键场景的测试。UI 验证仍然脆弱，视觉和行为上的回归会溜过去，因为自动化工具还不够可靠，抓不全。上下文窗口的限制意味着，在大型代码库上工作的 Agent 可能漏掉当前推理窗口之外的重要约束或模式。不稳定的环境，对单个开发者来说只是一个恼人的、绕一下就过去的边缘情况，而当四十个 Agent 同时撞上同一个不稳定的测试时，就成了系统性的阻塞。工厂停摆。
要在规模上支撑这个模型，需要的基础设施包括：更好的自动化回归检测、超越逐行 diff 的工件级验证、可靠且快速的环境供给，以及能在并行负载下站得住的护栏。这些都是活跃的投入方向，但都尚未解决。
在验证追上生成之前，人的审查不是可选的开销，而是安全系统。面对令人印象深刻的 Agent 产出，恰当的回应不是因为它看起来不错就信任它，而是拥有足够的架构理解和测试纪律去严格地评估它。
高杠杆工程的新形态
在这个时代最有影响力的工程师，不会以打字多快或记语法多牢来区分，而是以另一组能力来区分。
系统思维。把一个复杂架构装在脑子里、理解各组件如何交互、预见一处改动如何影响别处行为的能力。这比打字速度更难培养，而当你管理着一个产出需要由你来整合的 Agent 集群时，它也远比打字速度更有价值。
问题拆解。知道如何把一个庞大而模糊的目标拆成范围明确、Agent 能可靠执行的子任务。太大的任务容易跑偏，范围不清的任务会被错误解读。把问题拆好、再验证拆得对不对，这是一门真正的手艺。
架构判断。理解一个系统为什么被设计成这样、它在为哪些性质做优化、做了哪些取舍。Agent 能实现，但无法判断它们正在实现的是不是正确的设计。
Spec 的清晰度。写出无歧义、在重要边界情况上完整、并且结构便于评估的需求的能力。含糊的 spec 产出含糊的结果。精确的 spec 成倍放大为精确的实现。
产出评估。识别出“看起来对但其实不对”、“解决了既定问题却制造了新问题”、“方案的架构与系统其余部分的架构不匹配”的品味。这种判断无法自动化。
编排能力。管理多条并行工作流、对 Agent 产出给出有效反馈、分辨一个 Agent 是需要被纠偏还是需要被重新分派任务、并在一整个自主工作者集群上维持一致性的实际能力。
严格说来，这些都不是新技能。好的工程师一直都需要它们。变化的是它们的相对重要性。软件开发中机械的部分正越来越多地交给机器，认知的部分正在被放大。
更大的图景是什么？
新网站的创建量同比增长了 40%。新 iOS 应用增长了近 50%。GitHub 在美国的代码推送量跃升了 35%。所有这些指标在 2024 年末之前都已多年持平。图表看起来像曲棍球棒。从未写过一行代码的人正在构建并发布软件。
请记住，我们可以也应该指出：数量更多并不必然意味着质量更好。但事实依然是，创造软件的门槛已经大幅降低，而这是软件工程版图的一次根本性转变。
创造软件的门槛确实降低了。这不是炒作。对职业工程师而言，这并不意味着他们的技能贬值了，而是意味着真正重要的技能沿着栈往上移了，正如之前每一次转变一样。
从汇编转向 C 之后如鱼得水的开发者，不是那些能写出最巧妙汇编的人，而是那些理解机器需要做什么、并能用更高级的语言清晰表达这一意图的人。转向托管语言和框架之后如鱼得水的开发者，不是那些最抗拒垃圾回收的人，而是那些把释放出来的认知能力视为解决更难问题的机会的人。
在 agentic 时代如鱼得水的开发者，是那些把这理解为同一条弧线上的又一步、并据此投入的人。不是抗拒工具，也不是不加批判地顺从工具，而是培养让工具发挥最大效力的判断力、清晰度和系统思维。
这意味着写更好的 spec。投入测试基础设施。培养真正的架构理解，而不是表面的熟悉。建立严格评估产出的品味。练习问题拆解，直到它成为第二本能。
编程主要作为一种击键活动的时代结束了。编程主要作为一种思考与判断活动的时代，几十年来一直在加速，如今刚刚换入了更高的一档。
工厂模型不是一个关于失去对软件的控制的隐喻，而是一个关于构建杠杆的隐喻。理解这一点的工程师，将会构建出下一个十年里最有意思的东西。