谷歌工程师 Addy Osmani 在 2 月发表了一篇：The Factory Model: How Coding Agents Changed Software Engineering。和他发表的Agent Harness Engineering 详解Loop Engineering 是什么属于同一脉络：当 Coding Agents 从补全、对话式协作，走向可以长时间自主执行任务时，软件工程师的工作重心开始从“亲手写代码”转向“设计一个能产出软件的系统”。
这里的 Factory Model，可以理解为“软件工厂模型”：你不再只是在写产品本身，而是在搭建一套由规格说明、智能体、工具链、测试、反馈循环和人工评审组成的生产系统。这篇文章的核心判断是，编码方式变了很多，但软件工程的底层要求并没有消失；相反，架构理解、规格说明、测试、验证和判断力变得更重要，以下是全文翻译。
最近，智能体工程（Agentic Engineering）发生了一些变化，让人感觉抽象层级又一次改变了。这不是那种工具略微变好、工作流慢慢演进的常规变化，而是一次阶跃。很多写了几十年软件的开发者，都在用类似的方式描述它：这门手艺的重心变了。
现在最有用的一件事，是同时抓住两个看似张力很强的观点。编码已经发生了巨大变化。但软件工程的核心并没有变。这两者之间的差距，正是故事真正有意思的地方。能不能把它看清楚，会决定工程师是在这个时代继续放大自己，还是被它甩在后面。
我读了 Cursor 的 Michael Truell 关于这个问题的想法，想在这篇文章里继续展开。
抽象层级的弧线
软件工程的历史，就是抽象层级不断上升的历史。我们从比特（bit）到指令（instruction），从函数（function）到对象（object），再到服务（service）和分布式系统（distributed system）。技术栈里的每一次跃迁，都让单个开发者更高效，也扩大了能够参与软件构建的人群。汇编（Assembly）让位于 C。C 让位于托管语言（managed languages）和垃圾回收（garbage collection）。托管语言又让位于框架（frameworks）、包生态（package ecosystems）和云基础设施（cloud infrastructure）。每次转变在当时都显得很有冲击力。回头看，它们只是同一条长期弧线上的下一步。 我们正在经历的，就是这条弧线上的又一步：从写代码，转向编排那些会写代码的系统。
Grady Booch 曾提出过类似框架，他把它称为软件的第三个时代：一个由抽象层级继续上升定义的新黄金时代，开发者的工作从编写指令，转向定义意图。
这个框架很重要，因为它告诉你什么该抓住，什么该放下。
AI 编码工具的三代
我们需要精确地区分这几代工具。把它们混在一起，会低估已经发生的变化。 第一代是加速版自动补全（autocomplete）。这类工具预测下一行代码，补样板代码（boilerplate），帮你省掉重复模式里的键盘操作。它们有用，确实节省时间。但工作流没有改变：你开车，工具辅助。反馈循环仍然是写代码、运行、调试、重复。AI 只是降低了这个循环里的摩擦。 第二代引入了同步式智能体（synchronous agents）。你用自然语言描述一个任务，模型生成代码，你审查、修正、迭代，直到得到一个能工作的结果。这已经进一步上移了技术栈：少打字，多描述意图。但你仍然要出现在每一步里。Agent 是协作者，不是自主工人。你掌握上下文，指挥下一步，并实时捕捉错误。 第三代引入了自主智能体（autonomous agents）。这类 Agent 可以拿到一份规格说明，然后自己跑 30 分钟、1 小时、几个小时，甚至越来越接近几天。它们会搭环境、装依赖、写测试、遇到失败、上网查方案、修复失败、写实现、再次测试、搭服务，并产出可以给你审查的成果物（artifacts）。你把任务交给它，去做别的事情，再回来查看日志、预览和拉取请求（pull requests）。你不再一行一行地交互。你定义结果，然后审查结果。智能体集群（swarms of agents）甚至自我改进智能体（self-improving agents）就是在这里开始出现。
这种变化会改变工作的节奏。没亲自体验过，很难完全讲清楚。三个月前还是周末项目的任务，现在可能变成你启动一下、30 分钟后回来检查的事情。
软件工厂这个心智模型
理解这个新范式最有用的心智模型是：你不再只是写代码。你在构建那个构建软件的工厂。这个工厂由一队 Coding Agents 组成。每个 Agent 都有任务和工具箱（toolbelt），包括代码仓库（repositories）、测试运行器（test runners）、部署脚本（deployment scripts）、文档（documentation）；也有上下文（context），包括规格说明、架构决策、已有约束；还有反馈循环（feedback loop）。你不再牵着单个 Agent 完成单个任务，而是并行启动很多 Agent。一个做后端重构，一个实现功能，一个写集成测试，一个更新文档。你审查输出，给反馈，优化规格说明，然后重新部署。
这个类比比第一眼看上去更深。工厂有质量控制，有流程文档，有必须被精确描述的输入，否则输出就会错。工厂也会在环境不稳定时停摆。这些属性都能直接映射到智能体式软件开发（agentic software development）。认真对待这个类比，会把你指向真正值得投入的地方。
在一些非常积极采用这种模式的团队里，已经有相当比例的已合并拉取请求来自运行在云环境里的自主智能体。这不再是理论。对越来越多工程组织来说，它已经是生产现实。
Cursor 关于“The developer’s job is becoming building the system that builds the software, the factory, not just the product”，以及“reviewing ideas is a lot more fun than reviewing code”的说法和这套观点很契合。这里还有他们的视频。
这里有一个 onboarding 的平行类比
智能体实际工作时最显著的模式之一，是它们的工作循环很像让一个新工程师入职（onboarding）。
你给它一份规格说明（spec）。它把任务拆成子任务（subtasks）。它探索代码库（codebase），理解地形。卡住时，它搜索提交历史（commit history）。它运行git blame，看最后是谁改了某个子系统。它通过 Slack 或类似沟通渠道，把领域知识（domain knowledge）问题升级给合适的人类，然后继续执行。它反复迭代，直到输出满足验收标准（acceptance criteria）。
这个循环很熟悉，因为人类也是这样工作的。它的含义很重要。Slack 和电子邮件正在变成人类和智能体之间的接口，而不只是人和人之间的接口。Git 历史正在演变成智能体用来理解架构决策的知识图谱（knowledge graph）。文档正在变成自主执行的训练材料。
如果你想清楚现在该在代码库上投入什么，可以问自己一个问题：一个新工程师如果只能看现有文档和提交历史，能不能理解为什么代码会被组织成现在这样？如果答案是否定的，智能体在那里也会挣扎，你本可以获得的杠杆也会受限。
Spec 才是杠杆
这里有一个会重塑你对自身工程价值理解的洞察。
如果你能编排 20 个、30 个、50 个并行运行的 Agent，平庸输出和优秀输出之间的差异，几乎完全取决于规格说明的质量。在这个规模下，模糊思考不只是拖慢你，它会被放大。模糊需求会穿过几十个并行自主运行，每个运行都以略微不同的方式偏掉。前期糟糕的架构决策，不只影响一个实现，它会传播到整支智能体集群。 如果你没有深入理解架构（architecture）、集成边界（integration boundaries）、边界情况（edge cases）、失败模式（failure modes），以及那些绝不能被破坏的不变量（invariants），你就写不出能在这种环境里幸存的 spec。Spec 不再是 prompt。Spec 是被显式表达出来的产品思考（product thinking）。
这就是为什么强软件工程师会从这些工具里获得更大杠杆，而不是更小。敲代码的机械工作正在被自动化。理解系统的认知工作正在被放大。你每花一个小时建立真正的架构理解和系统思维，收益不再只体现在你自己的输出上，而是会穿过一整队自主工作单元（autonomous workers）。
真正没有变的东西
这里值得讲得精确一点，因为围绕 AI 编码（AI coding）的炒作（hype）很容易让人产生一种印象：传统软件工程技能已经过时了。
它们并没有。看看智能体式开发仍然需要你做什么。
清晰需求（clear requirements）。如果你无法用可评估的方式说明成功是什么，再多自主执行也无法产出它。智能体无法澄清那些你从未给出的要求。它们会用假设填补空白，而这些假设会继续复合。
强抽象（strong abstractions）。如果一个 Agent 面对的是设计良好、模块边界（module boundaries）清晰、接口（interfaces）连贯、关注点分离（separation of concerns）良好的系统，它会比面对一团所有东西都互相依赖的代码库时产出更好。Agent 来做实现，并不会让清晰架构（clean architecture）变得不重要。它会变得更重要，因为智能体会放大它所在系统本身的属性。
可靠测试（reliable tests）。这个值得单独讲一节。
谨慎权衡（careful tradeoffs）。智能体会优化你给出的目标。它们不会天然平衡相互竞争的考虑，不会预判二阶影响（second-order effects），也不会主动指出一个技术上正确的解法其实是错误的产品决策。这种判断仍然在你这里。
人工监督（human oversight）。智能体能做很厉害的工作，也会自信地犯错。输出质量已经高到足以通过随意 review，这意味着你的 review 能力门槛实际上提高了，而不是降低了。
为什么测试比以往更重要
好的测试和测试驱动开发（test-driven development，也就是 TDD），原本就是好实践。在智能体工作流（agentic workflow）里，它们接近必需品。
这个想法足够精确，值得说清楚。Red/green TDD，也就是红灯/绿灯 TDD，意思是：你先写测试，再写实现。你确认测试失败，也就是 red phase；然后你迭代实现，直到测试通过，也就是 green phase。这个顺序不是可有可无的仪式。它是让你确认实现真的在做你以为它在做的事情的机制。
当单个开发者写代码时，跳过测试先行开发（test-first development）的代价，是你可能写出一个无论实现是否正确都会通过的测试，或者漏掉后来才以回归问题形式被抓住的边界情况。这些代价是真实的，但可控。
当一队 Agent 在几十个并行任务上生成代码时，代价会严重复合。一个以通过测试为目标的 Agent，会找到通过测试的方法。如果测试是在实现之后写的，它们很可能测试的是实现碰巧做了什么，而不是它应该做什么。现在你会得到一大片代码，以及一个确认了错误事情的测试套件（test suite）。要确保自主输出确实正确，并在代码库增长时保护已有功能，全面的测试先行套件（test-first suite）是目前最有效的杠杆。
“Red/green TDD” 是每个好模型都理解的简写。它捕捉了一种具体纪律：先写测试，确认它们在实现前失败，通过正确实现让它们通过，而不是通过钻测试空子让它们通过。让 Agent 在任务开始时使用 Red/green TDD，是你能给出的最高杠杆指令之一。
未解决的问题是验证，不是生成
生成（generation）已经不再是瓶颈。验证（verification）才是。
智能体可以产出令人印象深刻的结果。难点在于，你如何有信心地知道这些结果是正确的。有几个因素会让这件事比第一眼看上去更难。
一个变更（change）之前就会通过的测试，并不意味着它们会抓住这个变更引入的回归问题（regressions）。智能体可以写出技术上有效、但漏掉关键情况的测试。界面验证（UI verification）仍然脆弱，视觉和行为回归会溜过去，因为自动化工具还没有可靠到能抓住所有问题。上下文窗口（context window）的限制意味着，智能体在大型代码库上工作时，可能漏掉当前推理窗口（reasoning window）外的重要约束或模式。不稳定环境（flaky environments）对单个开发者来说只是一个烦人的边界情况，可以绕过去；当 40 个 Agent 同时撞上同一个不稳定测试（flaky test），它就会变成系统性阻塞点（blocker）。工厂会停摆。
要在规模上支撑这个模型，需要更好的自动化回归检测（automated regression detection），超越变更行 diff 的成果物级验证（artifact-level validation），可靠且快速的环境供应（environment provisioning），以及能承受并行工作负载（workload）的护栏（guardrails）。这些都是正在投入的方向，还没有解决。
在验证（verification）追上生成（generation）之前，人工审查（human review）不是可选开销，而是安全系统。面对令人印象深刻的智能体输出（agent output），正确反应不是因为它看起来不错就信任它，而是用架构理解和测试纪律严谨地评估它。
高杠杆工程的新形状
在这个时代，最有影响力的工程师，不会因为打字快或记语法牢而被区分出来。他们会由另一组能力区分出来。
系统思维（systems thinking）。能在脑子里装下一个复杂架构，理解组件如何交互，并预判某处变化会如何影响其他地方的行为。这比提升打字速度更难，也远比打字速度更有价值，尤其是当你管理一队 Agent、还要整合它们输出时。
问题拆解（problem decomposition）。知道怎样把一个庞大、模糊的目标拆成范围（scope）清晰、Agent 能可靠执行的子任务。任务太大，Agent 往往会跑偏；scope 不清，任务会被错误解释。把问题拆好，并验证拆分是否正确，本身就是一门真正的手艺（craft）。
架构判断（architectural judgment）。理解一个系统为什么这样设计，它在优化什么属性，做了什么权衡（tradeoffs）。智能体可以实现，但它们无法判断自己正在实现的东西是不是正确设计。
规格清晰度（specification clarity）。能写出不含歧义、覆盖重要边界情况（edge cases）、并且结构上便于评估的需求（requirements）。模糊 specs 产出模糊结果。精确 specs 会乘法式地产生精确实现。
输出评估（output evaluation）。拥有品味（taste），能看出某个东西看起来正确但其实不对；某个实现解决了当前问题，却制造了新问题；某个方案的架构不适配系统其余部分。这种判断不能自动化。
编排能力（orchestration skill）。实际管理多个并行工作流（workstreams）的能力；能有效反馈智能体输出（agent outputs）；能判断一个 Agent 是需要纠偏（redirect），还是需要重新分配任务（retask）；能在一队自主工作单元（autonomous workers）之间维持一致性。
这些能力严格说并不新。好工程师一直都需要它们。变化的是它们的相对重要性。软件开发里机械的部分越来越多地交给机器，认知部分则被放大。
更大的图景是什么？
新网站创建量同比增长了 40%。新 iOS 应用（iOS apps）增长接近 50%。美国 GitHub 代码推送（GitHub code pushes）增长 35%。这些指标在 2024 年底之前已经平了很多年。那些图表看起来像曲棍球杆式曲线（hockey stick）。从来没写过一行代码的人，正在构建并发布软件。
我们当然可以、也应该指出，数量更多不一定意味着质量更好。但事实仍然是，创建软件的门槛已经大幅下降。这是软件工程格局里的一个根本变化。 创建软件的门槛确实下降了。这不是 hype。它对专业工程师的含义，不是他们的技能变得不值钱，而是那些重要技能继续向技术栈上方移动，就像之前每一次转变里发生的那样。
从汇编（assembly）转向 C 后，真正成功的开发者，不是那些能写出最聪明汇编代码的人，而是那些理解机器需要做什么，并能用更高层语言清晰表达这种意图的人。转向托管语言（managed languages）和框架（frameworks）后，真正成功的开发者，也不是最抵触垃圾回收（garbage collection）的人，而是那些把释放出来的认知容量看成解决更难问题机会的人。
会在智能体时代（agentic era）里胜出的开发者，是那些理解这只是同一条弧线上的又一步，并据此投入的人。不是抵抗工具，也不是不加批判地服从工具，而是发展判断力（judgment）、清晰表达（clarity）和系统思维（systems thinking），让工具发挥最大效果。
这意味着写更好的 specs，投资测试基础设施（test infrastructure），建立真正的架构理解而不是表层熟悉度，培养严格评估输出的 taste，并持续练习 problem decomposition，直到它变成第二天性。
把编程主要看成敲键盘活动的时代已经结束了。把编程主要看成思考和判断活动的时代，已经加速了几十年，而现在又升了一档。
软件工厂模型不是一个关于失去软件控制权的隐喻。它是关于构建杠杆的隐喻。理解这一点的工程师，会构建未来十年最有意思的东西。
参考链接
* 原文：Addy Osmani, The Factory Model: How Coding Agents Changed Software Engineering：https://addyosmani.com/blog/factory-model/
* Addy Osmani, Agentic Engineering：https://addyosmani.com/blog/agentic-engineering/
* Michael Truell 关于 Factory Model 的讨论：https://x.com/mntruell/status/2026736314272591924
* Grady Booch / The Pragmatic Engineer, Software’s third age：https://newsletter.pragmaticengineer.com/p/the-third-golden-age-of-software
* Cursor 视频：https://x.com/cursor_ai/status/2026369873321013568
* Addy Osmani, Self-improving agents：https://addyosmani.com/blog/self-improving-agents/
* Human in the loop：https://addyosmani.com/agentic-engineering/human-in-the-loop/
* Context window：https://addyosmani.com/agentic-engineering/context-window/
* Guardrails：https://addyosmani.com/agentic-engineering/guardrails/
* Nicholas Charriere 的数据图表讨论：https://x.com/nichochar/status/2026344879517728908 进技术交流群请添加AINLP小助手微信（id: ainlp2) 请备注 具体方向+所用到的相关技术点
!Image 4: 图片 关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。