Simon Willison 不是 AI 乐观派，他是工程纪律派

先把话挑明

我想先把一句话挑明：Simon Willison 不是 AI 乐观派，也不是 AI 悲观派，他是工程纪律派。

这话听起来像和稀泥，其实不是。今天市面上吵 AI 编程，大致三种人：一种说“模型越强程序员越闲，行业要消失了”；一种说“模型写的全是垃圾，根本不能用”；还有一种高级一点，说“我们要负责任地使用 AI”——但你追问什么叫“负责任”，对方就开始给你讲愿景了。

Simon 属于第四种，而且这种人极少。他既不站“AI 万能”也不站“AI 无能”，他做的事情非常具体：把“如何负责任地使用 AI 写代码”拆成一套可以马上写进 prompt、马上塞进 CI、马上让团队照着做的工程动作。

你打开他的 agentic engineering patterns 系列文章，会发现他根本不讨论“AI 到底懂不懂软件工程”这种形而上的问题。他在讨论“新 session 第一句话该让 agent 干什么”、“什么叫好的失败测试”、“为什么 manual testing 不能省”、“PR 里要不要附截图和命令输出”。全是脏活，没有金句，发不了朋友圈，但直接能上工。

我写过几年专栏，也见过太多在 AI 这个题目上“飘起来”的文章。Simon 的价值恰恰在于他不飘——用一个工程老手的姿态，把一个本来会被吹成神话的话题，砸回到工程层面。这种人不多，往后只会更稀缺。

下面我按自己的理解，把 Simon 这一套讲清楚。讲完之后，我会再加一些他自己没明说、但在国内团队里同样要面对的现实问题。

一、Simon 是谁，他凭什么这么讲

要看清 Simon 的判断分量，得先看他的工程履历。很多 AI“专家”在这一点上经不起查。

Simon 是 Django 的共同创造者之一。用过 Django 的人都知道，它不是玩具框架，是过去十几年承载了无数生产系统的 Web 框架。能参与设计这种东西的人，一定见过大量真实世界里的项目腐烂、协作崩盘、维护噩梦。

Simon 还是 Datasette 的作者——围绕 SQLite 和数据新闻做的一整套开源工具链。他不是写一两个工具就完了，他维护着一个工具生态。长期维护开源的人，对“代码不可维护意味着什么”有切身之痛。

再加上他在被 Eventbrite 收购之前，是 Lanyrd 的工程合伙人；被收购后，他在 Eventbrite 做到 engineering director；2002 年开始他就一直在博客上写技术文章，到现在二十多年没断过。

这一切堆起来的画像非常清楚：他不是一个“AI 产品体验官”，他是一个长期把软件真正交付到用户手里的人。

我为什么先讲这个？因为今天讨论 AI 编程的人，太多没有真正交付过一个长期被使用、被维护、被替换升级、被回滚降级、被审计排查的项目。没这种经验的人看 AI 编程，看到的是 demo；有这种经验的人看 AI 编程，看到的是责任。

Simon 看到的是后者。他几乎每一篇关于 AI 编程的文章，关键词都不是“模型”，而是“责任”、“交付”、“证据”、“审查”、“回滚”。这是一个工程老手的本能。

二、Simon 的核心判断：写代码变便宜了，交付好代码并没有变便宜

Simon 过去一年最核心的一句话：写代码变便宜了，但交付好代码并没有变免费。

这一句话有两层意思。

第一层是事实：coding agent 确实把“敲代码”的成本压到接近零。原本要花两小时写的样板，agent 十秒生成；原本要查一下午文档才能拼出来的胶水，agent 几句话搞定。这不需要争论。

第二层是判断：但所谓“好代码”的标准，并没有因此变松。Simon 专门列过一份“好代码”的清单——能工作、可被证明能工作、解决正确问题、覆盖错误路径、足够简单、有测试保护、文档恰当、可维护。这份清单里的每一条，agent 都可以帮你做一部分；但清单上的最终责任，没有任何一条可以从工程师身上挪走。

我想强调一下“没有任何一条可以挪走”这句话的分量。

我见过太多团队和个人，习惯性把责任甩给 agent。代码出 bug 了——“这是 Cursor 自动改的”；权限校验漏了——“模型默认这么写的”；接口签错了——“agent 建议用这个名字的”。这种讲法只说明一件事：你这个人不可信。

因为你是工程师。工程师的工作不是产出代码，是产出经过你证明的代码。无论亲手敲的还是 agent 生成的，无论开会决定的还是周末加班赶的，只要署你的名字提交了，那就是你的责任。跟工具无关。

Simon 有一篇文章干脆叫《Your job is to deliver code you have proven to work》。这话听着像常识，但你在国内任何一个互联网团队里坐两个礼拜，看十次代码评审就知道——这“常识”压根没被普遍接受。很多人喜欢用 AI，恰恰是因为它给了他们一个不再为代码负责的借口。 Simon 要打破的就是这个借口。

三、vibe coding 不丢人，但它不能假装是软件工程

Simon 对 vibe coding 的态度很有意思。他没有像很多老派工程师那样一谈到 vibe coding 就咬牙切齿，而是承认它在三种场景下有价值：低风险的一次性原型、新手入门、个人小工具。

这一点我同意。我自己写一些只在我电脑里跑的脚本，比如读取我自己的银行流水做汇总、给我自己的 TODO 做提醒、把昨天的会议纪要摘要一下，我也不写测试，也不重构，也不审。能跑就行。

但是问题不在 vibe coding 本身，问题在很多人把 vibe coding 当成所有 AI 辅助编程的代名词。

这就麻烦了。一个人在自己电脑上 vibe 一下没事，但他把 vibe 出来的代码丢到生产仓库里、丢到团队代码库里、丢到给客户的项目里——这就不是 vibe coding 了，这是用 vibe coding 的态度，干生产软件的活。

Simon 反复强调：vibe coding 不是 AI 辅助编程的全部。 真正负责任的 AI 辅助编程，开发者必须审查、测试、理解，并能向别人解释代码的行为。这是软件工程从来就有的标准，不是 AI 时代的新发明。

他后来用 agentic engineering 来描述与 vibe coding 相反的那一端：有经验的工程师借助 LLM 加速工作，但对交付的软件保持责任、理解和信心。这个定义对工程师很友好——不否认你用 AI，但要求你保留工程师的姿态。

Simon 在这里画出来的那条线很关键。那条线不是“用不用 AI”，是“承不承担责任”。

承担责任的人，可以放心用 AI。不承担责任的人，不用 AI 同样会出事。

很多团队的 leader 一上来就问“我们要不要禁用 AI 编程”——这个问题问错了。你应该问的是“我们的人，承担不承担自己署名提交代码的责任”。如果承担，那 AI 是放大器；如果不承担，那 AI 只是放大他们原来就有的不负责任。

四、Simon 的工程哲学：context is king

Simon 有一句反复挂在嘴边的话：“context is king”。

这话听着像废话，其实是一条很硬的工程判断：在用 LLM 写代码这件事上，最大的杠杆不是你 prompt 写得多骚，而是你给模型喂的上下文准不准、全不全、对不对。

我们这个行业过去一两年最大的认知偏差，就是把 AI 编程的核心能力误解成“prompt 工程”。各种“骚 prompt”、“魔法咒语”、“必杀提示词”在朋友圈刷屏。Simon 对此基本嗤之以鼻——他几乎从不写“如何写出最好的 prompt”，他写的是“如何把项目准备成一个适合 agent 工作的项目”。

这两个方向看起来都关心 AI，但差别很大。前者把杠杆放在那一句话上，希望靠神奇咒语让模型变聪明；后者把杠杆放在整个工程环境上——测试、Git 历史、文档、错误信息、CI、lint、preview 环境、命名风格——这些早就存在的东西，决定了模型在你项目里能做到什么水平。

Simon 说，agent 会在你已有的代码风格里继续延展。你的测试写得乱，agent 就会跟着写乱测试；你的命名风格统一，agent 就会跟着统一命名；你的错误信息详细，agent 修 bug 就修得快。你过去为人类同事建立的那一整套基础设施，在 agent 时代变成了 agent 的工作环境。

这件事意味着两件事：

第一，AI 编程不会让“工程纪律”贬值，反而会让它显著升值。一个有良好测试、良好文档、良好 CI 的项目，agent 能在里面快速、稳定、可验证地工作；一个测试残缺、文档过时、CI 形同虚设的项目，agent 只能在里面快速、不稳定、不可验证地搞破坏。

第二，“代码库即 prompt”。你的代码库本身就是给 agent 的最大一段 prompt。 agent 扫一眼代码就知道风格是什么。所以，想让 agent 帮你写好代码，第一步永远是先把你的代码库变成一个能让 agent 学到好风格的地方。

这条原则 Simon 没明说出来，但他每篇文章其实都在围绕它打转。

五、Pattern 1：First run the tests——一句话把 agent 拉进项目状态

Simon 最有代表性的 pattern 之一是“First run the tests”。

四个词，中文五个字：“先把测试跑了”。

别小看这五个字，它同时干了好几件事。

它强迫 agent 发现项目的测试套件。 怎么跑测试？pytest、npm test、还是 go test ./…？找的过程本身就是熟悉项目的过程。跑完之后，agent 对项目有 30 个测试还是 3000 个测试心里有数，还能从测试组织方式里看出模块划分和对外接口。

它给后续所有改动建立了反馈机制。 一旦 agent 知道“这个项目有测试，而且我们重视它”，后面每改一处就会自动倾向于跑一下测试。不是因为模型多聪明，是因为你给它建立了一个工作循环。

它把 agent 拉进了“以测试为入口”的协作姿态。 就像新人入职，你递给他的第一份材料是项目的 README 加跑一遍 CI——还没干活，就已经知道这个团队怎么干活的了。

它还让你提前发现问题。 如果测试本来就在挂，agent 会先报告，而不是等你“修一个不相关的 bug”之后才让 CI 翻车。

Simon 有一个值得很多团队学的能力：把一个相当复杂的工程意图，压缩成一句 agent 就能听懂的短话。

背后的机制是：前沿模型在训练数据里早就见过“先跑测试再动手”这种工程习惯。你不需要解释完整流程，只需要用业内通行的术语。“First run the tests”之于 agent，就像“先看监控”之于 SRE——它是一个工程暗号，触发的是模型已经理解的整套行为模式。

六、Pattern 2：Use red/green TDD——把“质量”压成一句 prompt

Simon 最常被引用的另一个 pattern 是“Use red/green TDD”。

red/green TDD 大家都知道：先写测试，看到红灯（失败），再写实现，看到绿灯（通过）。这是 Kent Beck 那一脉的 test-driven development。

但 Simon 这里有一个细节非常关键：他本人原来不是 test-first 的拥护者。

他在介绍自己的 Showboat 和 Rodney 工具时坦白说，整个职业生涯都对“测试优先、追求最高覆盖率”那一套有怀疑，他更喜欢“tests included”——测试和实现一起交付，但不一定先写测试。

那他为什么推荐 agent 用 red/green TDD？因为 agent 的情境完全不同。

人类做 test-first，最大的代价是心流被打断——脑子里好不容易有了一段实现思路，硬要先写测试，等于把车熄火再启动。但 agent 没有心流，agent 不觉得无聊，花两分钟写个失败测试再写实现，对人类的体验来说几乎为零。Simon 有一句话很扎心：他过去抗拒 test-first，是因为浪费的是自己的时间；让 agent 做就很好，因为浪费的是 agent 的时间。

更重要的是，TDD 对 agent 还有一个独特的价值：它防止过度实现。

agent 最大的毛病之一就是太热情。你让它写一个简单功能，它顺手给你加一个策略模式、一个工厂模式、再套一个观察者模式。这种“AI 架构师综合症”在无约束场景下几乎必然发生。

但你一旦把任务变成“让这个失败测试通过”，agent 的行为就被收紧了。它不再追求“漂亮的解决方案”，它只追求“让红灯变绿”。这中间的差距是巨大的。

Simon 的 pattern 化能力再次体现：他把“AI 时代更需要测试”这个抽象判断压缩成一句短 prompt，就能调用模型内部已经训练好的整套 TDD 知识——先确认测试失败、实现只做最小改动、绿灯之后再重构。

而且他特别提醒过一件细节：测试必须先失败。 如果你跳过红灯阶段，测试可能本来就过得了，那它就没证明任何东西，只是一个装饰品。这条提醒很多人不当回事，但实际上它是 TDD 和“凑测试覆盖率”之间唯一的分界线。

七、Pattern 3：Manual testing——自动测试不是“亲眼看见”

Simon 最有辨识度的观点之一，也是我最想替他喊一遍的，是对 manual testing 的坚持。

他在《Your job is to deliver code you have proven to work》里说得很明确：证明代码能工作要走两步，都不是可选项——手动测试和自动化测试。

把这一点拎清楚：Simon 说的是“manual testing 是必做的”，不是“如果有时间再做”。 很多人会下意识跳过这一步。

为什么必做？

因为自动测试通过，不等于软件能用。

举个我见过的例子。某团队改了一个登录接口，单元测试全绿，集成测试全绿，CI 亮着大绿灯。结果上线后用户登不进去——测试用的是 mock 数据库，真实数据库的字段名跟 fixture 里的不一样。这种事在 AI 编程时代会变多，因为 agent 特别擅长“在自己搭好的测试路径上把测试搞绿”，但不一定知道真实环境的字段怎么命名。

再比如一个 UI 组件改了样式，snapshot 测试通过（因为只验 HTML 结构），但实际打开页面发现关键按钮被 CSS 层级冲突遮住了——agent 不会“打开页面看一眼”，它只会“跑测试”。

自动测试和 manual testing 覆盖的是不同的风险。

自动测试覆盖的是“我已经知道要验证什么”——行为预期已被固化成测试用例。manual testing 覆盖的是“我还不知道有什么问题”——你打开真实系统，看到没预期到的状态、报错、UI。

这两类风险的存在性都不会因为 AI 到来就消失。事实上，AI 到来之后，第二类风险还变多了——因为 agent 修代码非常快，一天能改几十个地方，每个地方都可能引出意料之外的连锁反应。

Simon 的解法是 agentic manual testing：让 agent 像人类 QA 一样实际操作软件。

具体怎么做？

• 对 Python 库，让 agent 用 python -c 直接调用新函数，试边界情况；
• 对 JSON API，让 agent 启动开发服务器，用 curl 探索；
• 对 Web UI，让 agent 用 Playwright 或自己的 Rodney 工具打开真实浏览器，点击按钮、读取 accessibility tree、截图；
• 一旦在 manual testing 里发现问题，立刻让 agent 用 red/green TDD 把这个问题固化成永久回归测试。

这形成了一个漂亮的闭环：

manual testing 发现问题 → 写失败测试 → 修实现 → 测试通过 → 问题进入回归测试。

品一下这个闭环——它把 manual testing 和 automated testing 的对立给消解了。manual testing 成了 automated testing 的“原料厂”，每一次 manual testing 发现的问题，都被沉淀成长期的自动化资产。

这就是 Simon 的 pattern 思维：他从不停留在抽象判断，他总是把抽象判断转成可循环的工作流。

八、Pattern 4：Show your work——让 agent 留下证据

很多人对 agent 的“幻觉”有恐惧。其实在 AI 编程里，最危险的幻觉不是“代码写错了”——那跑测试就能发现。最危险的是 agent 告诉你“我测试过了，没问题”，但它其实没真测，它根据预期编造了结果。

Simon 给这个问题的解法叫 Show your work——让 agent 把它干的事情亮出来。

他做了一个工具叫 Showboat，核心机制很简单：让 agent 在测试过程中构建 Markdown 文档，记录执行了什么命令、得到了什么输出、看到了什么截图、验证了什么行为。每一项都是真实命令真实输出，不是 agent“自我陈述”。

关键不是工具的功能多复杂，而是设计原则。Simon 提过，他见过 agent 在 Markdown demo 文件里直接编辑结果，而不是真去跑命令。所以工具本身就要防作弊——exec 命令必须真正执行、把 stdout/stderr 记进文档；agent 不能“想象”一段输出然后写下来。

这背后是一个非常深刻的工程判断：在 AI 时代，code review 不再只审代码，还要审证据。

把这一点展开说。在传统 code review 里，reviewer 看的是代码本身——这一行对不对、命名规不规范、有没有边界 bug、性能行不行。但在 AI 时代，这套方法已经压不过来了：

• AI 可以在十分钟里改五十处代码——你来不及一行行看；
• AI 写的代码通常表面上很合规——它读过很多优秀代码，它知道“看起来怎样像是好代码”；
• 真正的问题往往不在代码本身，而在“这个代码到底有没有真的被执行过、真的覆盖了用户路径”。

这三条加在一起，意味着你必须把审查重心，从“代码本身”挪一部分到“行为证据”。

什么是行为证据？

• 一段真实的命令 + 真实的输出；
• 一张真实的截图 + 真实的页面状态；
• 一段真实的录屏 + 真实的交互流程；
• 一份真实的 API 请求 + 真实的响应；
• 一组真实的测试运行日志 + 真实的耗时和结果。

这些东西都是 agent 可以生成的，也是 Showboat、Rodney 这类工具的设计目的——把“我亲眼看过它运行”从主观声明变成可复核的工件。

这是 code review 在 AI 时代必须发生的最重要变化之一。 哪个团队最先把 review 的 SOP 升级到“既审代码也审证据”，哪个团队就能建起真正的质量护城河。

九、Pattern 5：让 agent 模仿好习惯——把“代码库风格”当成隐性 prompt

前面讲过“代码库即 prompt”，Simon 在实操层面把这件事落得更细。他有一条很现实的观察：LLM 会奖励优秀的工程实践。

他举过一个接地气的例子：哪怕代码库里只有一两个你喜欢的测试样式，agent 也会照着写。代码库整体高质量，agent 就按高质量方式增量；到处是脏活和反模式，agent 就继续复制脏活和反模式。

他甚至说过，不太喜欢“写 AGENTS.md 逐条告诉 agent 怎么写代码”这种思路——更高杠杆的做法是把整个项目本身做成一个好的示范。

道理很简单：显式规则的容量有限，隐性风格可以无限扩展。

你写一份 AGENTS.md，再勤奋也就几页纸。但代码库可能有几十万行——几千个测试、几百个模块、上百份文档、几年 Git 历史。这些 agent 全都能读、全都会模仿。

所以 Simon 对“agent-ready 项目”有很具体的建议，我翻译成中文 checklist：

• 能跑的自动化测试。 这是底线。一个项目如果没有 agent 能跑的测试，它本质上不能被 agent 可靠地协作。
• agent 能调用的开发服务器/调试入口。 让 agent 能用 curl 打你的 API、能用 Playwright 访问你的页面、能用 python -c 调你的函数。可调用，agent 才能闭环验证。
• lint / type check / formatter 全套。 这些是 agent 生成代码后的“边界裁判”，它们的存在让 agent 能从外部反馈里自己纠偏，而不需要每次都靠人提醒。
• assertion 失败信息要详细。 测试失败时，错误信息越具体，模型越容易修。这是一个被严重低估的细节——assert result == expected 抛出一行 AssertionError、什么上下文都没有，让人改都难，让 agent 改更难。
• 干净的测试样式 + 清晰的 fixture。 agent 会照着你已有的测试模仿。如果你已有的测试到处是重复 setup、命名混乱、断言模糊，agent 会原封不动地继承这种混乱。
• Git 历史可读。 让 agent 能看到最近的 commit message、看到改动的演进，理解“这个项目最近在做什么”。

说白了一句话：你想让 agent 写出好代码，先把你的项目变成一个让 agent 羞于写脏代码的地方。

这个原则是反向的——它要求你在 AI 到来之前，先把过去欠的工程债还掉。如果过去没有测试、没有文档、没有规范、没有 CI，AI 时代你不仅不会受益，反而会受害——agent 会以更快的速度把混乱再扩张一遍。

AI 编程时代，过去的工程债会以更高的利息被结算。 Simon 给这个判断提供了非常具体的实操路径。

十、Pattern 6：用 Git 管理 agent 的速度与风险

Simon 对 Git 的强调几乎到了“癖好”的程度。我觉得他是对的。

agent 的核心特征是快——十几分钟改几十个文件、动十几个模块。另一面是：错误也以同样的速度扩散。

人类手抖一下，最多影响一个文件；agent 手抖一下，可能跨大半个仓库。你不能靠“小心一点”来抵御这种规模化风险，必须靠工具——Git 正是这个时代最被低估的武器。

Simon 反复推荐的几个做法：

第一，新 session 用 “Review changes made today” 把 agent 拉进上下文。

这一句很短但效果惊人。让 agent 先扫今天的 commit log，它就会把“最近改了什么”作为后续动作的基础。就像新人接手任务前先看 Git log 和 PR 描述。Simon 说的没错——agent 通常非常懂 Git，log、branch、reflog、bisect 都能用。

第二，每一个 agent task 都从一个干净分支开始。

这条不是 Simon 专利，是工程常识，但在 AI 编程时代更重要。agent 改动量大且不可预测，不能让它直接动主分支。每个 task 一个分支，就是每个 task 一个隔离器——出了事可以毫不犹豫地丢弃。

第三，把高级 Git 工具下放到日常。

git bisect 是一个强大但学习曲线陡的工具——要写判定脚本、配合二分查找定位引入 bug 的 commit。过去很多人一辈子用不上几次。但 agent 能帮你写判定条件、执行二分、总结结果。bisect 从高门槛工具变成了日常工具。

更大的意义是：AI 不只能写新代码，它还能把过去那些存在但学习成本高的工具平民化。 Git、pytest、curl、Playwright、linter、CI、docker、bash——这些工具早就在那里，门槛也早就在那里。agent 没有发明新工具，但它降低了使用门槛。一个普通工程师如今能调用的工具广度，是过去十年的好几倍。

我认识一些工程师在抱怨“AI 让我的工作没价值了”。这种说法站不住脚。AI 时代真正的杠杆，不是你有什么专属技能，而是你能不能让 agent 把整套软件工程工具都开动起来。 谁能让 agent 最熟练地使用最多种工具，谁就有最大的产出杠杆。

十一、Anti-pattern 1：把未审查代码丢给别人

讲完 pattern，得讲反模式。先说 Simon 最痛恨的那一条。

Simon 反复反对的一种做法是：把 agent 生成的大量代码未经自己审查就提交 PR，让同事或开源维护者替你收拾。

他说这种行为“非常常见，也非常令人沮丧”。他甚至说，如果你提交几百甚至几千行 agent 生成的代码，却没有确认它真的能工作，你其实是在把真正的工作委派给别人。

这一刀切得很狠，我再补一刀。

这条反模式的本质不是“用了 AI”，而是逃避责任。逻辑很简单：你的同事自己也能用 agent，那你的价值在哪？在于理解问题、设计方案、约束 agent、验证结果、清理实现、补上测试、解释取舍、给 reviewer 足够上下文。如果你只是转发 agent 的输出——你不是在提高生产力，你是在制造团队成本。

我把这话说得再直接一点：用 agent 写大量代码再不审就提 PR 的人，正在系统性地伤害团队。

为什么？因为他在转嫁责任。自己不审，reviewer 就得审——而 reviewer 面对的是一段连作者都没确认过的代码，难度是正常 review 的好几倍，因为缺少上下文、不知道哪里是改动核心、不知道哪里被验证过。

更糟的是，这种 PR 会让团队 review 文化整体退化。资深工程师开始拒绝 review 这种 PR，新人因此得不到反馈，更不会成长。团队一旦把 agent 当甩锅工具，整个工程师培养机制就会崩盘。

Simon 提出的“好的 agentic engineering PR”标准很清楚：

1. 代码能工作，而且你有信心。 不是“测试好像过了”，是“我亲眼看过它跑，我知道它的边界”。
2. 改动足够小、可 review。 一个 PR 一个意图，不要把 agent 三天的输出一次提交。
3. 附带额外上下文。 上层目标、相关 issue、设计取舍——让 reviewer 知道你为什么改、改到哪步、哪些是刻意保留的。
4. agent 写的 PR 描述也要审。 让别人读你自己没读过的文字，是一种新的不礼貌。

这套标准非常适合制度化。我建议严肃团队把它刻进协作规范：AI 生成或 AI 辅助的 PR，必须附带三类证据——自动化测试结果、手动测试说明、作者对关键实现的解释。

这样 AI 就不是隐藏在背后的“神秘生产力”，而是进入了可审查、可追责、可复盘的工程流程。

十二、Anti-pattern 2：不写测试，或者把测试当装饰

Simon 对“不写测试”的态度这一两年是越来越硬的。

他原话之一是：现在还有人用 coding agent 写代码却完全不写测试，这是非常糟糕的想法。过去不写测试的理由是维护成本，但agent 时代测试几乎免费——agent 能在几分钟里整理出一套像样的测试——再不写，纯粹就是偷懒。

但他同样警告“测试装饰化”。

什么是测试装饰化？就是测试存在的目的不是验证实现，而是让 PR 看起来专业。这种测试有几个识别特征：

• 测试用例多但覆盖路径浅；
• assert 大量用 assert result is not None、assert len(x) > 0 这种“反正不可能挂”的断言；
• 用 snapshot 替代行为断言——只验证结构形状，不验证业务规则；
• 一旦回滚实现，测试还能通过；
• 测试名都叫“test_should_work_correctly”——根本没说在测什么。

这种测试比没测试还危险——没测试至少诚实地告诉所有人“这个项目没保护”，装饰性测试却会制造假的安全感。CI 绿灯亮着，所有人觉得安心，但任何回归都会顺利溜过。

Simon 提出的标准非常具体：自动化测试要和改动一起提交，而且如果回滚实现，测试应该失败。

这句标准要狠狠写进 review checklist。reviewer 应该养成习惯：拿到 PR，先 mental rollback 一下实现——如果实现被还原，这些测试还能通过吗？ 能通过就是装饰，退回去重写。

在 agent 工作流里，TDD 能进一步防止“测试装饰化”。因为 TDD 天生要求你先看到红灯——测试如果第一刻不能挂，那你这个测试就不成立。这个机制天生防御了“agent 写一个永远不挂的测试糊弄人”这种行为。

Simon 从一个原本不喜欢 test-first 的工程师，转向接受 test-first，关键就在这一点：agent 天然倾向于写过度的、装饰性的、不真正验证行为的代码，TDD 是几乎唯一能从底层抑制这种倾向的工程纪律。

十三、Anti-pattern 3：把自动测试当作 manual testing 的替代品

前面已经讲过 manual testing 为什么不可替代，这里从反面再补一刀：agent 写测试的时候，很容易写出“覆盖自己实现路径”的测试，但漏掉真实用户路径。

打个比方。你让 agent 改购物车的优惠券逻辑，它写了实现又顺手写了测试。这些测试覆盖什么？覆盖 agent 自己想到的边界条件、自己理解的业务规则、自己写出来的代码分支。但真实用户路径是：从首页加购物车→跳转→点“使用优惠券”→选一个特定券→看到折扣金额。这条路径可能涉及前后端各五个组件、三个接口、两个数据库表。agent 的测试只能覆盖其中一两块。

测试全绿 ≠ 用户能用。

Simon 推荐的不是“更多单元测试”，而是多层验证：单元测试证明局部逻辑，集成测试证明跨模块路径，manual testing 证明真实行为，浏览器自动化证明 UI，Showboat 文档证明过程，截图录屏证明结果。不同证据覆盖不同风险，一个 PR 至少要有一两层覆盖你不熟悉的真实行为。

我最近在一个团队里推了一条规则：涉及用户可见行为的 PR，必须附带至少一个真实交互证据——一段 curl 输出、一张截图、一段 Playwright trace。不是测试结果，是真实交互。规则上线后线上事故降得很明显，原因不是工程师变聪明了，而是大家被迫把“真实运行一次”变成了 PR 的硬性步骤。

十四、Anti-pattern 4：YOLO mode 缺少安全边界

Simon 并不反对 YOLO mode——放手让 agent 跑命令、不每步都审批。他承认 YOLO mode 有很大的生产力价值，因为频繁请求人工批准会显著降低 agent 通过反复试错解决问题的能力。

但他列了很实在的风险：agent 可能做出糟糕决策、受 prompt injection 攻击；最强大的工具往往是 shell 执行，失控的 agent 什么都干得出来；错误命令可以破坏文件系统；攻击者可以通过 prompt injection 让 agent 泄露源码、环境变量、密钥；你的机器甚至可能被当作攻击代理。

我看到很多团队在这一块毫无防备——agent 直接接触生产 credential、读取真实用户数据、连接生产数据库。没出事之前看着没事，一旦出事就是灾难级的。

Simon 的解法仍然是 pattern 化：

• 想放开 agent，先放进 sandbox。 容器、虚拟机、Codespaces——别让它在你的本机直接乱跑。
• credential 最小权限。 只读数据库账号、只能访问测试桶的存储 key、只能看分析数据的 BI 账号。
• 花钱的 credential 设预算上限。 Cloud key、API key、模型调用 key——YOLO mode 加没有预算上限，等于开着一台烧钱机器。
• 尽量用 test/staging 数据。 不只为了安全，也为了让 manual testing 在受控环境里跑完。

Simon 还反对一种更隐蔽的做法：拿敏感生产数据做测试。 他建议投资 good mocking——一键创建随机用户、模拟 edge case 用户、为不同角色创建 fixture。

我们这个行业过去十几年，“用生产数据做测试”是被默许甚至鼓励的——理由是“只有真实数据才能测出真实问题”。但 agent 时代这条做法必须收紧。agent 访问粒度比人粗、受 prompt injection 影响、可以被诱导外泄数据、操作日志比人类难追溯。四条加起来，生产数据加 agent 就是高风险组合。还在这么干的团队，是在赌运气。

Simon 的姿态始终一致：不是禁止能力，是给能力套上边界。

十五、Pattern 7：Conformance-driven development——用多个实现反推出规范

Simon 还有一个我觉得很有启发的实践：conformance-driven development。

他给 Datasette 加 multipart file uploads 的时候，干了这么一件事：让 Claude 构建一个“文件上传”的测试套件，要求这套测试在多个已有框架（Go、Node.js、Django、Starlette 等）上都能跑过。然后再用这套测试去驱动 Datasette 的实现。

他自己原话是：“像是从六个已有实现反向工程出一个标准，再实现这个标准。”

这件事我觉得值得拿出来单讲。

过去写一个 conformance suite 很费时——研究多个实现、抽象共同约束、写大量用例。这种活通常是 W3C、IETF 这种标准组织在做，普通工程师没时间也没动力做。

但现在不一样。agent 能把这种活做得快得多——下载多个实现、跑一遍、抽出共同行为、写出测试套件。人类的价值在于：选择参考实现、判断哪些行为属于规范、哪些只是偶然差异。

这是 agent 时代一个非常特别的工程能力——它能把“模糊需求”转成“可执行规格”。

我把这种能力拆成几种典型用法：

1. TDD：把单个功能转成失败测试。 适合做新功能。
2. Conformance-driven：把多个现实实现转成测试套件。 适合做替代实现、做兼容层、做协议适配。
3. Manual-derived testing：把用户行为转成命令和截图。 适合做面向终端用户的产品。
4. Showboat documentation：把测试过程转成证据文档。 适合做高合规要求的项目。

这四种方式有一个共同点：都把工程师脑子里“我希望系统怎么工作”的模糊预期，转成了 agent 能执行、能验证、能复用的具体工件。

这就是 Simon 的真正贡献——不是教你怎么用 AI 写代码，是教你怎么把抽象工程经验沉淀成可调度的执行单元。

十六、Simon 的组织启示：AI 时代更需要 senior engineering

讲到这里，得说一件违反直觉但 Simon 非常坚持的判断：AI 编程时代，对 senior engineering 的需求是上升的，不是下降的。

很多人担心 AI 会让初级工程师“被掏空”——agent 能写代码，初级工程师做什么？Simon 的视角不一样。他在 Pragmatic Summit 的炉边谈话里讲过：同时驱动多个 agent 是非常耗脑的。

你需要不断切换项目、审查输出、给反馈、决定下一步、做权衡、设计验证、发现遗漏。这不是“靠 AI 偷懒”，这是要求你全力运转。

在《Vibe engineering》里，他把“会用 AI 的工程师”是怎么样的画得更清楚：

• 在研究方案；
• 在决定架构；
• 在写 specification；
• 在定义成功标准；
• 在设计 agentic loops；
• 在规划 QA；
• 在管理一群“数字实习生”；
• 在做大量 code review。

这些活，一条一条单独看，几乎都是 senior engineer 的特征。

所以在 Simon 的观察里，AI 编程不是降低了工程标准，而是提高了工程师对“管理”和“验证”的要求。一个人可以同时启动几个 agent，但瓶颈会从“你能不能写代码”转移到：

• 你能不能清楚定义任务？
• 你能不能提供足够上下文？
• 你能不能判断结果对错？
• 你能不能发现边界问题？
• 你能不能让 agent 证明它做对了？
• 你能不能把这一次的经验，沉淀成下一次可复用的 prompt、测试、脚本或文档？

这套问题，全是 senior 工程师才有能力答的。AI 让“敲键盘”贬值，但让“判断力”升值。 Simon 用一个长期工程师的视角确认了这一点，分量很重。

Simon 还提到一个我很喜欢的概念：compound engineering loop。 每次 agent session 结束后，把有效经验沉淀下来——更新 README、AGENTS.md、测试模板、工具脚本、流程文档——让下一次 agent 运行得更好。

AI 不会自己从过去的错误里学习，但你的代码库、文档、测试、工具链可以。一个团队的 agentic engineering 成熟度，就反映在这些可累积资产是不是越来越厚、越来越对、越来越能让新 agent 即用即上。

最先建起 compound engineering loop 的团队，会在新时代里拥有真正的代差。

十七、把 Simon 这套整理成一份可执行的工程清单

把 Simon 的要点压缩成可立刻上手的清单，大致八步。直接抄走用。

第一，准备环境。 项目要有可运行测试、清晰 README、开发服务器启动方式、lint/type check/format 命令、可隔离运行的 sandbox。agent 不是魔法，它需要工具和边界。

第二，让 agent 进入上下文。 先跑测试、看 Git 最近变化、读相关代码。“First run the tests”加“Review changes made today”，两句话能省很多坑。

第三，新功能用 red/green TDD。 先写失败测试，再写实现。测试必须先失败，红灯阶段不能跳过。

第四，测试通过后做 manual testing。 库函数用 python -c，API 用 curl，Web UI 用 Playwright 或浏览器自动化。自动测试不是“亲眼看见”。

第五，让 agent 留证据。 用 Showboat 或类似机制记录命令、输出、截图。把“测试过”从主观声明变成可审查材料。

第六，把发现的问题固化为测试。 manual testing 发现 bug，用 red/green TDD 写进回归测试。每一个被人类发现的问题都应该变成自动化资产。

第七，提交前自己 review。 PR 要小、可解释、有上下文、有证据。agent 写的 PR 描述也要审。

第八，复盘并沉淀。 有效的 prompt、测试模式、工具说明、失败经验写进项目，让下一次 agent 更容易做对。这就是 compound engineering loop。

这八步加起来，就是一个团队从“用 AI”升级到“用 AI 做工程”的最小路径。每条都不复杂，每条都很贵——贵在工程师改变习惯的成本。但谁先建立这套习惯，谁就有真正的杠杆。

十八、Simon 没说、但中文团队同样要面对的事

Simon 写文章面向英文工程文化，他默认 code review 的严肃性、PR 的标准粒度、开源 maintainer 的责任感这些东西不需要解释。在中文团队里，有几件事需要额外强调。

第一，KPI 和 OKR 体系不能只考核“产出代码量”。

很多公司今年已经开始用“agent 生成代码量”作为效率指标。这是危险的。一旦代码量变成考核维度，工程师就有动力把 agent 输出原样丢出去。正确的考核应该是“被证明可工作且可维护的功能数量”，不是代码行数。

第二，code review 文化要从“看代码”升级到“看证据”。

在一些组织里，code review 本来就走形式。AI 时代如果还这样，就会出大事。要主动升级 review SOP：每个 PR 附带自动化测试结果、手动测试说明、关键实现解释。让 Showboat-like 工件成为 PR 的标配。

第三，“AI 代码合规”是一个新岗位职责。

谁来确保团队提交的 agent 代码：

• 没有泄露敏感数据（agent 可能把 secrets 打到日志里）；
• 没有引入未授权依赖（agent 可能装了一个有许可证问题的库）；
• 没有违反公司架构规范（agent 可能直接绕过中台调底层）。

这些都需要专门的人或 CI 规则盯着。很多团队会发现自己缺一个“AI 编程治理岗”——它的雏形就是 Simon 说的 agentic engineering pattern owner。

第四，老工程师的“经验沉淀”职责加重。

AI 时代，老工程师最大的价值不是“自己写代码”，而是把判断、经验、品味沉淀成 agent 能用的资产——AGENTS.md、structural test、pre-commit hook、custom linter、onboarding doc。经验停在脑子里是负债，沉淀成系统资产才是真资产。 Simon 用 compound engineering loop 表达过这件事，在中文团队里需要更明确：这是老工程师的新 KPI。

第五，对实习生和初级工程师，要主动做“AI 带教”。

不要让他们直接 vibe coding——他们会以为这就是工程师的全部。要从一开始就让他们接触 agentic engineering 的纪律：先跑测试、TDD、manual testing、show your work、不丢未审 PR。让第一份工程肌肉记忆就是“用 AI 还要负责任”。

这五条的共同点是：把工程纪律从“个人习惯”上升到“组织能力”。 Simon 提供的是个人级别的 pattern，扩展成组织级别的制度，是下一步要做的功课。

结语：把 AI 编程拉回软件工程

收尾了。

Simon Willison 的独特性不在于“他说 AI 很强”或“他说 AI 很危险”——这两种声音都不缺。他真正有价值的地方是把 AI 编程从争论拉回了软件工程。

他不满足于“我们要负责任地使用 AI”这种正确但空泛的话，而是拆成了一组 patterns：

• First run the tests.
• Use red/green TDD.
• Test with curl.
• Test with Playwright.
• Look at screenshots.
• Use Showboat to leave evidence.
• Don’t file unreviewed PRs.
• Keep tests clean.
• Let the agent imitate good patterns.
• Run in a sandbox.
• Use tight credentials.

每一条都能立刻执行，都能写进团队规范，都能放进 CI、review checklist、入职培训。每一条都把抽象的工程纪律变成了可被强制执行的工程动作。

AI 编程的早期阶段是“看，模型能写代码！”。Simon 代表的是下一阶段——“这些代码怎么证明值得交付？”

这话听上去保守，其实很深——焦点从“产能”挪回了“交付”，从“我们能写多少”挪回了“我们能稳定交付多少”。经历过软件工程长期周期的人，都会本能认同这个视角。

写代码的成本下降了，但软件工程从来不只是写代码。真正稀缺的，是知道该写什么、怎样证明它工作、如何让别人安全接手、如何让系统在未来可维护。 Simon 在用一组小而具体的 pattern 一件件地教这些事。

他不教大道理，他教暗号。

下一次你打开 Cursor、Codex、Claude Code，进入新 session，记得先打这五个字：

First run the tests.

这就是 Simon 想让你养成的肌肉记忆。把这条做实，剩下的整套 agentic engineering 都会自然长出来。

至于愿不愿意做实——那是你的选择。但如果你选择不做，别说 Simon，连我都帮不了你。

工程纪律从来都不是别人能替你完成的。

从写代码到设计代码生产系统：理解 Ryan Lopopolo 的 Harness Engineering，需要回到工业革命的脉络里去

一、从一个具体的事件谈起

2026 年 2 月 11 日，OpenAI 在官方博客上发表了一篇题为《Harness engineering: leveraging Codex in an agent-first world》的文章；作者 Ryan Lopopolo 是团队成员之一。同年 4 月 7 日，他又在播客 Latent Space 接受了一场长访谈，进一步谈到了背后的方法论。

文章里描述了这样一件事：他们用大约五个月时间，从一个空仓库出发，构建并交付了一款内部 beta 产品。这个仓库最终大约有一百万行代码，约 1500 个 PR，应用逻辑、测试、CI、文档、可观测性和内部工具，全部由 Codex 这个代码生成 agent 写成；人类工程师并没有亲自手写一行业务代码。Ryan 自己估计，这相当于手写代码所需时间的十分之一。

过去三年里，关于 AI 编程的报道层出不穷，类似量级的“震撼数字”也出现过几次。但 Ryan 这件事之所以值得专门写一篇文章来谈，并不在数字本身。真正值得关注的，是他在数字背后给出的那一整套工程范式——他把它命名为 harness engineering，姑且翻译成“驾驭工程”。

我之所以对这件事感兴趣，是因为从科技史的角度看，它并不是一个孤立的小创新，而是一类我们已经反复见过的事情——一种新的生产手段出现之后，关于“什么是有价值的劳动”的定义被重新写过一次。 工业革命如此，电气化如此，集成电路如此，互联网如此。AI 编程，正在以同样的方式发生。

这篇文章想做的事，是把 Ryan 的观点放回到一个更长的技术史脉络里，再做一些必要的归纳和判断。

二、回到工业革命：生产手段更替时，发生过什么

要理解 harness engineering，先回到一段更老的故事。

十八世纪末到十九世纪初，纺织业先后出现了飞梭、珍妮纺纱机、水力织机和蒸汽动力。这些设备一个比一个能干。从产能曲线上看，每一次设备更替都意味着同一个工人能管的纱锭和织机数翻倍上升。表面上，这是一场关于“机器战胜人手”的故事。

但如果只看到这一面，就会错过更深的东西。

在工厂出现之前，纺织是一门“家庭作坊”行业。一个工匠的全部价值，集中在他的双手和经验上。机器普及之后，这一部分价值确实被压低了——纺纱本身，从一种稀缺技能变成了廉价劳动力也能做的事。但与此同时，一种过去并不存在的新岗位被催生了出来：工长（foreman）、机械师（mechanic）、工艺工程师（process engineer）和工厂经理（manager）。

这些角色做的事，并不是“自己上手纺纱”，而是设计机器的布局、维持机器的稳定、调度物料和人手、判断产出质量、规划新车间。他们的产出形态，从单件产品，变成了“一整条生产线的运转”。

事后回头看，结论很清楚：工业革命真正改变的，不是“会不会纺纱”这件事的定义，而是“什么样的劳动算高价值劳动”的定义。 一线手艺人的边际价值在下降，而设计、调度、维护这条生产线的人，他们的边际价值在上升。

电气化、汽车工业、集成电路、互联网这几次范式更替里，类似的事情一次又一次发生。每一次的细节都不同，但底层结构非常相似——当某种生产手段把人原本擅长的某一类劳动接管之后，人的价值就会向上一层迁移：从执行迁移到设计，从单件产出迁移到系统产出，从隐性手艺迁移到可复用规则。

Ryan Lopopolo 这件事，本质上是软件工程在 AI 时代经历的同一类迁移。代码生成被 agent 接管了，接下来重新被定价的，是人类如何设计这条“代码生产线”。

三、软件工程到目前为止的三个阶段

要看清楚 Ryan 的位置，可以先把过去半个世纪软件工程的演化做一个粗线条的划分。

第一个阶段是手工作坊阶段。从上世纪六十年代到八十年代，软件主要由小规模团队手工开发。一个工程师的价值，几乎全部取决于他能写出什么样的代码。彼时优秀的工程师，往往就是那种“一个人能搭出整套系统”的天才。这一时期的代表人物，是 Ken Thompson、Dennis Ritchie 这一批 Unix 先驱。

第二个阶段是工业化流水线阶段。从九十年代开始，到 2010 年代中期成熟。版本管理、持续集成、自动化测试、云计算、敏捷开发、SRE 文化，逐步把软件生产从作坊转化为流水线。这一时期，“会写代码”已经不再稀缺，真正稀缺的能力是“让一千个工程师协同工作而不出乱子”。这一时期的代表性事物，是 Google 的工程文化、亚马逊的服务化架构、Netflix 的混沌工程。

第三个阶段正在以肉眼可见的速度展开，可以叫智能编排阶段。从 2023 年大模型驱动的编程辅助开始，到今天的 agent-first 实验，软件生产的一部分关键劳动——写代码——开始由模型直接承担。Ryan 团队的实验，是这一阶段一个比较纯粹的样本。

每个阶段更替都伴随两件事：原本稀缺的能力变得不再稀缺；一种新的稀缺能力被催生出来。手工作坊阶段稀缺的是“会写”；工业化阶段稀缺的是“会协同”；智能编排阶段稀缺的是什么？这正是 Ryan 想回答的问题。

他给出的答案不是“会写更好的 prompt”，而是更深的一层：会设计让 agent 稳定工作的整套环境。 这个能力，他叫 harness engineering。

四、Ryan 的核心命题：humans steer, agents execute

Ryan 反复用一句话来概括这套范式——人类掌舵，agent 执行。

这句话本身并不复杂，复杂的是它如何被理解。

一种常见的误读是：人类只负责发指令，剩下的全部由 agent 完成。如果停在这一层，会得出“程序员要失业”的结论。但 Ryan 在文章里描述的实际工作分配，要细致得多。

他所说的“人类掌舵”，包括以下几件事——
设计 agent 工作的环境（designing environments）；
表达意图（specifying intent）；
构建反馈回路（building feedback loops）；
维护约束（maintaining constraints）；
沉淀判断（codifying judgment）。

概括起来就是：人类工程师并没有从循环里消失，他们只是从 implementation layer 迁移到了 systems layer。 仍然在做关键的判断，仍然在拍板架构，仍然在守护边界，只是不再以“在键盘上敲源代码”作为主要产出形态。

这种模式在历史上并不陌生。蒸汽机普及之后，并不是所有人都不再做体力劳动，而是“管理蒸汽机的人”成了新的高价值角色。计算机普及之后，并不是所有人都不再算账，而是“会用计算机来组织数据的人”成了新的高价值角色。AI 编程的故事，不过是同一种结构的第 N 次重演。

每一次重演中，最关键的事情从来不是“机器接管了哪一部分”，而是“人类该把自己的精力转到哪一层”。Ryan 的回答非常清楚：转到 systems layer。

五、Ryan 的方法论起点：用一个看起来不合理的约束逼出系统化

Ryan 在访谈里讲到一个细节，我认为是他整套方法论中最关键的起点：他给自己定下了一个看起来很极端的约束——完全不写任何代码。

他给出的理由很平实。如果 OpenAI 希望把 agent 部署到企业内部，那 agent 在原则上就应该能做工程师能做的事；既然他和 coding harness 已经一起工作了大半年，那他就反过来设计自己的工作方式：唯一能完成工作的途径，就是让 agent 完成工作。

这种约束可以从两个角度来理解。

工程角度看，这本质上是一种“自缚手脚”的实验设计。它封死了“我下次自己上手”的退路。每一次 agent 失败，都不再被允许归因为“我自己来更快”，而被强制归因为“系统里缺了什么”——是缺工具？缺文档？缺反馈通道？缺测试？缺 trace？缺 sandbox？缺验收标准？这种归因方式的好处显而易见：它逼着团队把所有原本依赖人类兜底的能力，逐步沉淀成 agent 可读、可执行、可验证的系统组件。

科学方法论的角度看，任何新工具的极限能力，在一个允许使用旧工具兜底的环境里是测量不准确的。要想真正知道 agent 能走多远，唯一的办法是把旧工具的退路砍掉。这一点和实验物理是相通的——在控制变量被严格设定之前，任何关于“它行不行”的判断都是不可靠的。

Ryan 不是在主张所有团队都不写代码，他的主张更深一层——只有当你真正禁止自己用老办法兜底，你才会开始严肃地构建那套使新办法可工作的系统。

历史上类似的事情发生过不止一次。福特最初推动流水线生产时，遭遇过强烈的内部阻力——很多老工人觉得“我自己慢慢做也能做好”。福特最终的做法不是说服每一个人，而是把生产组织本身改了，让旧办法在新组织里没有立足之地。生产方式的更替，常常需要这种“封死退路”的决心。

六、harness 的对象不是 prompt，而是整个生产环境

把 Ryan 的方法论推一步：他所谓的 harness engineering，对象并不是单次对话，也不是某一段 prompt，而是整个软件生产环境。

prompt 当然仍然重要，但它只是 harness 的一个小部件。harness 真正包括的东西，至少有以下几类——

第一类是工具。 agent 必须能启动应用、读日志、查指标、跑测试、看 UI、生成截图、提交 PR、回应 review。这一系列能力如果没有从工具层做出来，agent 就只能停留在“会写代码但看不见结果”的阶段。

第二类是文档与知识。 repo 里要有 agent 能读懂的导航、设计文档、execution plan、quality score、reliability 规则、安全姿态。这些东西是 agent 在 runtime 拿来推理的“上下文”。

第三类是约束。 不可妥协的架构边界、依赖方向、数据形状、命名约定，必须被机械化为 lint 和 structural test，而不是写在某个角落让 agent 自己去揣摩。

第四类是反馈。 trace、log、CI、review 评论、测试结果、quality score、技术债报告——这些信号必须以 agent 能消费的方式回流到 repo 里。

第五类是 workflow。 PR 的生命周期、issue 的状态机、agent 的 sandbox 权限、人类升级路径，必须有清晰的规则，让 agent 知道在每个状态下该做什么、不该做什么、什么时候必须停下来。

一句话概括：harness 是一个工程师把自己的判断、品味、经验和约束，系统化地“暴露”给 agent 的整套基础设施。 它不是替代工程师，而是让工程师的判断不再以一次性的方式被消耗，而是以可复用的方式持续生效。

这种“让人类经验沉淀进系统”的事，过去也发生过。十九世纪末出现的工业制图、工艺标准、QA 流程，本质上都是把老工匠脑子里的隐性经验转化为流水线可消费的显性规范。Ryan 在 agent 时代做的事，只是这种沉淀活动在新介质上的又一次演化。

七、瓶颈的迁移：从代码产能到人类注意力

每一次生产手段的更替，必然伴随瓶颈的迁移。

汽车工业的早期，瓶颈是“造一辆能跑的车”；中期变成了“卖出去”；成熟期又变成了“维护和服务”。一个产业的英雄人物之所以会在不同时期更换，是因为不同瓶颈所需要的能力是不一样的。

软件工程到目前为止经历过两次明显的瓶颈迁移。手工作坊阶段，瓶颈是“能不能写出来”；工业化阶段，瓶颈变成了“能不能稳定地发布”。Ryan 这次实验暴露出来的，是第三次瓶颈迁移——

当 agent 把代码产能拉高到接近无限，瓶颈跑到了“人类注意力”那里。

他在访谈里反复强调：模型工作可以并行，token 可以花，GPU 可以扩，但团队同步投入的人类注意力是稀缺的。

这句话的含义远比表面深。

过去的所有工程流程，几乎都默认了一个隐含前提：人是产能的瓶颈。所以每个 PR 都要认真审查，每个 gate 都要严格把关。这套流程在人是瓶颈的时候是合理的；但当 agent 把代码产能拉高十倍，这套流程会瞬间反过来变成最大的瓶颈。

OpenAI 文章里有一句话很值得注意：他们后来调整的 merge philosophy——短寿命 PR、阻塞 gate 较少、flaky test 后置处理——放在低吞吐环境里是不负责任的，但在高吞吐环境里常常是正确的取舍。

这并不是在主张取消 review。Ryan 真正在主张的是：当人类 review 变成瓶颈，质量控制必须前移、机械化、agent 化。 工程师不应该再花大量时间逐行检查代码，而应该把过去常见的 review 意见转化为 lint、structural test、文档规则、review agent、验收脚本。

汽车工业进入大规模生产之后，质检并没有消失，但形式从“人逐个看”变成了“统计抽样 + 工艺过程控制 + 自动化测试”。生产手段升级之后，质量控制本身也必须升级，否则它会变成新的瓶颈。 Ryan 团队的做法，正是在软件工程上完成同样的过渡。

八、AGENTS.md：从“百科全书”到“目录”

Ryan 文章里有一条经验，对所有团队都有直接借鉴意义。他们最早写过一个非常巨大的 AGENTS.md，把所有团队约定、风格偏好、注意事项都写进去。结果不出所料：上下文空间被严重挤占，所有规则都“重要”等于没有规则；文档很快腐烂，与代码不一致；几乎没有办法机械验证。

后来他们把 AGENTS.md 改成大约 100 行的“目录”——一个稳定入口，指向 repo 内更深层的 source of truth。真正的知识被搬到结构化的 docs/ 目录里：design docs、execution plans、product specs、references、quality score、reliability、security 等等。计划本身也被当作“一等公民”，与代码一起 versioned。

这种做法背后有一条很关键的原则——从 agent 视角看，运行时拿不到的知识就等于不存在。

这条原则的含义比字面要深。

Slack 里某次架构讨论达成的一致——agent 没读到，等于不存在。Google Doc 里那份 design doc——没有进入 agent 上下文，等于不存在。某位资深工程师脑子里的那些“我们就是这么干”的隐性经验——只要没写进 repo，对未来的 agent 而言就是不存在的。

这其实是文档观念的一次迁移。工业时代之前，文档的功能主要是“留给后人看”。工业化以后，文档承担起了“协同工具”的角色——是工程师之间对齐预期的方式。到了 agent 时代，文档还要承担一个新的功能：让 agent 能够行动。 文档不只是给人读的解释材料，它是 agent 的工作内存、导航图、约束集合和验收依据。

更进一步，这些文档不能只是“被写下来”。Ryan 团队还做了两件事：用专门的 lint 和 CI 检查文档健康度，以及让一个常驻的 doc-gardening agent 定期扫“文档说的”和“代码做的”是否一致，发现偏差就开 PR 修。

这把文档从“曾经写下的内容”，升级为“持续被验证的事实”。 从文学性到工程性的转变。

九、Agent legibility：当代码的首要读者不再是新员工

Ryan 提了一个很有概括力的概念：agent legibility，可以翻成“对 agent 的可读性”。

他的判断是——既然代码大部分由 agent 生成、未来的修改也将由 agent 完成，那么“对 agent 可读”必须成为代码的首要约束之一。这并不意味着“代码可以不适合人读”。Ryan 的态度其实更微妙：代码不一定要符合所有人类的审美偏好，但只要它正确、可维护、对未来 agent runs 可读，就达到标准了。

human taste 没有消失，而是被重新定义了。 它从“我喜欢这个实现长什么样”，转向“这个实现是否可验证、可维护、可被 agent 稳定理解和复用”。

这种转变会反过来影响技术选型。OpenAI 文章中有一段表述值得注意：他们偏好那种 agent 能够完整 internalize 的依赖与抽象。传统上被称为“无聊”的技术——组合性强、API 稳定、训练集中出现得多——反而更容易被 agent 建模。文章给了一个具体例子：他们没有引入一个通用的并发限制库，而是自己写了一个 helper，让它与 OpenTelemetry 集成、测试覆盖完整、运行时行为可预期。

Ryan 在访谈里把这个逻辑推得更远——他甚至认为，一个几千行的小依赖，可以让 agent 一个下午重写一遍，只保留你真正需要的部分；之后做安全审查、修 bug、做适配时，agent 能直接深入修改，而不必等 upstream patch、发布、升级。

这种主张听起来反 DRY，但他自己也很清楚地承认：内部化依赖意味着你回到零，需要重新建立信心和测试。 这不是免费的。

深一层看，当代码本身的生成成本下降，软件的价值就从“代码资产”转向“可验证的系统形状”。 过去之所以倾向复用第三方库，是因为重写很贵；Ryan 描绘的世界里，重写的边际成本下降了，但验证、可观测、边界、安全的成本依然很贵。所以“用不用第三方库”不再仅仅是“不要重复造轮子”的问题，而要追问——这个轮子对 agent 是否透明？我能不能用我自己的 harness 去约束、测试、审查、修复它？

这其实和工业史上的模块化进程是同一类问题的不同形态。福特最早造车时，几乎所有零件都自己做；后来，零件供应链高度专业化、模块化；再后来，丰田又重新提出“看板生产”，要求把过多分散的环节再次拉回到一个可控的系统里。这种“内部化与模块化之间的钟摆”，每个产业都会经历。 软件工程在 agent 时代的钟摆，正在从“什么都用第三方库”，向“重要的部分内部化以方便 agent 操控”摆动。

十、让 agent 能看见应用：可观测性的角色变化

Ryan 团队后来遇到的瓶颈，从代码产能变成了人类 QA 容量。他们的解法不是雇更多 QA，而是让 agent 自己具备 QA 能力。

具体做法分几步——
应用支持按 git worktree 启动，每一个 change 都对应一个独立实例；
把 Chrome DevTools Protocol 接入 agent runtime，给 Codex 写处理 DOM snapshot、screenshot、navigation 的 skill，让它自己去复现 bug、验证修复、推理 UI 行为；
每一个 worktree 配一套隔离的 observability stack，Codex 可以查 logs、metrics、traces，会用 LogQL、PromQL。

这套搭起来之后，“确保服务启动低于 800ms”、“这四条关键用户路径里没有 span 超过两秒”——这种 prompt 才真正变得可执行。

他们甚至让 Codex 直接 author Grafana dashboard 的 JSON，并响应 page。因为 dashboard、alert、log、code 都被 collate 在一起，告警发生时 agent 能知道是哪条日志触发了哪个 alert；如果某个 outage 没有触发 page，它还可以根据已有 dashboard 找到观测缺口并修复。

这件事的含义超出工程细节本身。过去的可观测性工具，目标受众是人类 on-call 工程师。 设计哲学是“让一个被叫醒的工程师能够在最短时间内理解系统状态”。这一时期最好的可观测性公司，是 Datadog、Grafana、Honeycomb 这些。

到了 agent 时代，受众正在悄悄变化。当最终修复也由 agent 完成时，可观测性的目标受众就从人类 on-call 变成了 agent。 这意味着——

dashboard 不一定要好看，要让 agent 能从中读出“下一步该做什么”；
log 不一定要丰富，要结构化、可被机械解析、易于压缩进上下文；
trace 不一定要可视化，要 agent 能直接消费的 tarball；
alert 不一定要带情绪，要提供因果链而不是孤立信号。

Ryan 在访谈中举了一个很有代表性的例子：他们团队里有工程师花了一个下午做了一个漂亮的 trace visualization 工具；后来发现，直接把 trace tarball 丢给 Codex 让它分析修复，反而更符合 agent-first 的路线。

可观测性的演化，正在经历一个从“给人看”到“给 agent 用”的范式转换。 它将催生一类新工具——agent-readable observability。这一类工具今天还没有标准答案，但接下来五年，它很可能会成为一个独立的细分市场。

十一、机械化的 invariants 与不被 micromanage 的 implementation

Ryan 还有一个观点，对所有正在用 agent 的团队都有方法论价值——文档本身不足以让一个完全 agent-generated 的 codebase 保持一致。 你不能只跟 agent 说“请写得优雅”，也别指望它自然遵守团队的 tacit taste。那些不可妥协的架构边界和 invariant，必须机械化。

OpenAI 那篇文章里讲了具体做法：把业务 domain 切成固定层级（大致是 Types → Config → Repo → Service → Runtime → UI），用 custom lint 和 structural test 强制依赖方向；横切关注点通过 Provider 这种显式接口进入，其他边一律禁止。

Ryan 的关键判断是——约束 invariant，不要 micromanage implementation。 比如他们要求 Codex 在边界上解析数据形状，但不指定一定要用某个库。这样 agent 既能快速产出，又不会破坏地基。

这种取舍可以从两个层面来看。

工程层面，把 invariant 机械化，意味着 agent 即使复制了不好的模式，也无法越过最关键的边界。这是一种“让坏模式无法扩散到致命位置”的设计，类似于核电站的多重防护——单点故障可以发生，但不能演化成系统性灾难。

组织层面，Ryan 在访谈里说，自己的心态像是在担任一个 500 人组织的 group tech lead——对一个 500 人组织的技术负责人来说，逐行点评每个 PR 是不合适的；更重要的是通过样本观察团队哪里卡住、哪里需要帮助、哪里已经跑得快，然后把注意力转到更高杠杆的位置。

他们的仓库有大约 500 个 NPM packages。一个七人团队搞这种结构，初看是过度架构。但 Ryan 反问得很有力：如果每个工程师驱动 10 到 50 个 agent，那这就更像一个几百人的团队。深度 decomposition、sharding、清晰接口边界——这些“大公司病”的产物，在 agent-first 团队里反而是早期 prerequisite。

这里有一个重要判断——在 agent 时代，团队的“实际规模”不能按 head count 计算，要按并发执行单元计算。 这对很多还在用旧规模观估算组织复杂度的团队，是一个值得警惕的提醒。

十二、Review 的未来：从逐行审查到“信任包”

Ryan 在 PR review 上的看法，可能是这套方法论里最容易引起争议的部分。他在 OpenAI 文章里说，人类可以 review PR，但不总是必须；随着时间推移，他们把几乎所有 review 努力推向 agent-to-agent。访谈里他说得更直接——大部分 human review 已经是 post-merge。

但他立刻补了一个限定：他们做的是 native application，不是连续部署的高可靠基础设施；发布分支与分发前的 smoke test，仍然有人类批准。

所以 Ryan 真正想说的不是“取消人类审查”，而是审查对象与信任机制要变。

让我印象最深的，是他在访谈里的一个具体设想：他希望 coding agent 在 PR 上附一个视频，展示功能在真实产品里能跑起来。这相当于把 agent 完整的工作轨迹压缩成一个 reviewer 可读的“信任包”。

类比一下——人类同事提 PR 时，我们不会要求他屏幕录制整个写代码过程；我们只要他给出足够证据，让我们相信代码可以 merge。 Ryan 把 agent 也当成 teammate 来看：不要 shoulder-surf 它的每一个动作，而要让它产出 reviewer 需要的压缩证据。

证据可以是什么？——单元测试、E2E 测试、trace、video walkthrough、log 摘要、review agent 给出的结论、CI 状态、structural check 结果、quality score、tech debt 更新。人类 review 的价值，从“逐行检查生成物”，转向了“检查验证体系是否覆盖了风险”。

这其实是审计制度演化的一个重演。早期的工业生产里，质检是“逐件查验”；后来变成了“过程审计 + 抽样 + 统计过程控制”；再后来，软件行业把它进一步发展成了 SLO、错误预算、混沌工程这一整套机制。Ryan 这件事，是同一种演化路径在 agent 时代的下一站——审计的对象从“产物”，进一步前移到“验证体系本身”。

十三、错误不是修补，而是进入“垃圾回收”系统

Ryan 没有回避一个关键问题：完全 agent autonomy 会带来新麻烦。

OpenAI 文章里说得很坦诚：Codex 会复制 repo 里已有的模式，包括不均匀或次优模式；时间一长会出现 drift。他们最早每周五花 20% 时间清理“AI slop”，但很快发现这种打地鼠模式不可扩展。

他们后来做了两件事——
第一，把 golden principles 编码进仓库，作为有观点的机械规则，目标是维持代码对未来 agent runs 的可读性和一致性。例如偏好 shared utility package、不允许 YOLO 猜数据形状、网络调用必须有 timeout。
第二，建立 recurring cleanup process，让后台 Codex 任务定期扫偏差、更新 quality score、开 targeted refactoring PR；很多可以在一分钟内 review 并 automerge。

Ryan 把这事称为 garbage collection——技术债像高利贷，最好持续小额偿还，而不是让它复利增长到痛苦爆发。

这个比喻之所以重要，是因为它把“AI slop”从一个道德议题变成了一个工程对象。Ryan 不否认 slop 的存在，他说的是：如果 agent 会复制坏模式，那就要设计一个持续回收坏模式的系统。 所谓 human taste，不是每次人类出来骂一句“这个写得丑”，而是把 taste 捕捉成原则、lint、review prompt、quality score 和后台清理任务。

丰田生产体系里有一项核心原则叫“jidoka”（自働化）——一旦在生产线上发现缺陷，就立即停下、就地解决、把根因写进流程。Ryan 的 garbage collection，本质上是软件工程在 agent 时代的 jidoka。 区别只是，机器从生产线变成了 agent，故障从机械问题变成了 slop 问题。

一个真正稳定的 agent-first 系统，不在于“不会出错”，而在于“它出的每一个错都会被吸收为系统的一段免疫力”。

十四、Symphony：从“看终端”到“让 issue tracker 成为 control plane”

Ryan 后续工作里最值得单独谈的，是 Symphony。OpenAI 在 2026 年 4 月 27 日发布了 Symphony 的相关文章，它直接继承了 harness engineering 的实验。

故事是这样的——团队在“无人手写代码”的工作流里继续推进时，下一个瓶颈出现了：context switching。每个工程师每天能稳定推 5 到 10 个 PR，但代价是不断在 tmux pane 之间切换；同时管理 3 到 5 个 Codex session 就开始痛苦：忘记哪个 session 在做什么、agent 卡住时不知道、长任务总要回头检查。相当于团队拥有了一群能力很强的 junior engineer，却不得不让 human engineer 去 micromanage 他们。

Symphony 的核心设计简单又深远——不要直接监督 agent，让 agent 从任务系统里拉活。 Linear 这类项目管理看板成为 coding agent 的 control plane；每一个 open task 对应一个 agent workspace；agent 持续运行，人类 review 结果。

这一步真正的意义在于——它把工作单位从 Codex session / PR，提升到了 ticket / deliverable。这是一次抽象层级的跃迁。

OpenAI 文章给了一个具体数字：有些团队上 Symphony 三周后 landed PRs 增加了 500%。但更深层的变化是——每个 change 的感知成本下降了。人不再亲自驱动实现，因此 speculative task 变得便宜——试一个想法、探索一个 refactor、测试一个假设，不行就丢掉。产品经理和设计师甚至可以直接向 Symphony 提 feature request，拿回一个包含真实产品视频 walkthrough 的 review packet。

早期个人电脑时代，开发者要直接面对 CLI；GUI 之后，普通人开始能够使用计算机。后端服务时代，传统部署需要工程师亲自调机器；Kubernetes 之后，部署变成了“声明状态”，调度本身被抽象掉。Symphony 在 agent 时代做的事，是把“管理 agent 的劳动”从手工进一步抽象为声明式的 ticket queue。 它解决的不是技术问题，而是“人类注意力如何不被 agent 数量淹没”的问题。

Ryan 在访谈里特别提了 Symphony 的 rework state 设计，我认为这体现了 agent-first 时代的成本观——
如果 PR 不可 merge，就把 worktree 和 PR 整个丢掉，从头再来；
然后追问“它为什么是垃圾”，先修 prompt、skill 或 guardrail，再把 ticket 重新推入 progress。

背后的判断很简单：当代码的边际成本接近零，保留错误路径不一定值得。 有时候丢弃 + 补护栏 + 重跑，比 patch 干净。这种思路在传统工程师脑子里很难一下接受，但在 token 便宜、模型够强的时代，是一种合理的取舍。

十五、从“放盒子里”到“给目标 + 上下文 + 工具”

Ryan 还有一个值得关注的演进观察：早期 agent 适合放在预定义 scaffold 或状态机里，但 reasoning model 一旦变强，过度僵硬的 scaffold 反而会限制它。

他们后来“反转”了系统——
不是先搭一个环境再把 coding agent spawn 进去，而是让 Codex 本身成为入口，再通过 skill 和 script，给 Codex 提供启动 stack、设置环境变量、查询 observability 数据的能力。

这并不意味着“取消边界”。Ryan 自己补了一句关键限定：给它 context 和 tools。
也就是说，box 不是没有，而是 box 变成了整个 harness：权限、工具、repo 结构、workflow policy、observability、CI、lint、skill、sandbox、human escalation——共同构成一个可操作的环境。

这种思路的演化也有历史对照。早期工业自动化主要靠固定流水线和死板的状态机；进入电气化和自动化的成熟期后，引入了反馈控制（feedback control），让设备能够根据实时信号自我调整。Ryan 从“硬编排”向“给 agent 目标 + 上下文 + 工具”的演进，本质上和工业自动化从开环控制走向闭环控制是同一种范式跃迁。

由此可以得出一条判断：模型能力越强，控制系统的设计就越应该向“目标 + 反馈”方向偏移，而不是向“步骤 + 步骤”方向偏移。 这是工业控制论的一条老规律，在 AI 时代被重新激活。

十六、文本是 agent 的血液

Ryan 还有一句话值得抄下来——模型 fundamentally crave text。

他们做的很多事，本质上都是在把文本注入系统让 agent 能用。比如某次缺 timeout 导致 page，他们直接在 Slack 里 @ Codex，让它不光给那个调用加 timeout，还要更新 reliability documentation，把“所有网络调用都必须有 timeout”写进规则。这样团队不只是修了一个点，而是把“什么是好”持久编码进流程知识。

他们还做了一件很有方法论意义的事：对 session log 做 skill distillation。Codex 自己的 session log 收集到 blob storage，每天跑 agent loop 分析“团队哪里做得不够好”，再把结论反馈回 repo。PR comment、failed build——这些都是信号，代表某个时刻 agent 缺上下文；这些信号要被吸收，然后塞回 repo。

这件事让 harness engineering 具备一种自改进的味道。它不是一次性配置，而是持续学习系统：agent 失败 → 失败变成文本信号 → 文本信号被分析 → 规则、skill、文档、工具更新 → 未来 agent 更少失败。这个循环越顺畅，团队的经验复利越强。

更进一步，Ryan 还说了一个反共识但合理的判断——改 agent behavior 比改 human driver behavior 便宜得多。 团队里每个人都去养成新习惯很难；但你把新习惯写进 shared skill、lint、workflow prompt 或 CI，所有 agent 立即继承，所有人间接受益。

十七、CLI-first 与 token 效率：工具的输出格式正在被重新评估

Ryan 对工具输出格式有非常具体的偏好——CLI 对 agent 友好，因为 token efficient，而且容易被改造得更 token efficient。

他举的例子很具体：构建输出常常是一大墙文本；过去 dev productivity team 会写工具把真正的异常抽出来放到顶部。给 agent 的 CLI 也应该这样——格式化命令不必输出每个已格式化文件，agent 只需要知道 formatted or not；测试输出尽量只吐失败部分。

这听起来是细节，但在 agent-first 系统里有结构性意义。人读日志可以扫一眼跳过；LLM 处理日志时，无关 token 会占 context、干扰注意力、增加成本，还可能触发错误推理。 好的 agent tooling 应该把输出压缩成“下一步行动所需信息”。

有一个有趣的历史对照：早期电报时代，因为按字数收费，电报员发明了一整套缩写、词典和专用编码，让一句话用最少的字传达。今天，给 agent 的 CLI 输出格式，正在经历类似的“信息密度优化”。 一种我们以为已经过时的工程纪律，在新介质上重新登场。

由此可以推导出一条更广的判断——未来五年，整个软件生态的接口都会逐步为 agent 优化。 日志、CLI、错误消息、lint message、dashboard、trace、PR comment、issue description，都会在原本的“人类友好”目标之外，新增一个“agent 友好”目标。这两个目标有时一致，有时分歧；分歧的部分将成为新一代工具的设计空间。

十八、Ghost Libraries：当代码便宜时，软件可以以 spec 的形式分发

Ryan 在访谈里还谈到一个很有未来感的概念——Ghost Libraries。

Symphony 的开源形式很特别。它不是先给一个完整实现，而是先给一个高保真的 spec，让 coding agent 可以在本地重新组装出来。OpenAI Symphony 文章里说，仓库第一眼看到的是一个 SPEC.md，定义问题和预期解法，而不是只给一个复杂的监督系统。

Ryan 描述他们提取 spec 的过程很有方法论意味：从内部 proprietary repo 里抽 scaffolding，开新仓库，让 Codex 参考原 repo 写 spec；再让一个与原仓库隔离的 Codex 实现 spec；再让另一个 Codex 比较实现与 upstream，更新 spec 让它更少偏离；如此循环，直到 spec 能高保真地复现系统。

这是一种非常不同的软件分发观。

换个说法：过去我们分发软件，主要分发 source code、binary、library、API。Ryan 描绘的世界里，如果 agent 足够会写代码，spec 本身就可能成为软件资产——它描述问题、边界、流程、接口、状态机、成功标准和非目标，由本地 agent 根据具体环境生成实现。

OpenAI 的 Symphony spec 强调：它是 scheduler / runner 和 tracker reader，ticket 写入通常由 coding agent 在 workflow runtime 里完成；它不强制单一 sandbox 或 approval policy，而要求实现者明确自己的 trust and safety posture。

这一变化有两个值得注意的后果。

第一，软件变得更 adaptable。 spec 可以让 Jira、Bitbucket、Linear、GitHub 等不同环境替换具体集成，只保留更柏拉图式的抽象。

第二，工程里“实现细节”的价值在下降，“可复现的高质量规格”的价值在上升。 如果 agent 能从 spec 生成不错的实现，那么真正稀缺的就是——问题定义是否准确？边界是否清晰？验收标准是否可执行？安全姿态是否明确？观测是否足够？

这又回到 Ryan 的主线——工程师的价值从写代码转向设计可执行环境。

从更宏观的角度看，软件分发模式可能正在经历一次相变。从 source code 时代，到 binary 时代，到 SaaS 时代，再可能到“spec + agent”时代。每一次相变，都伴随着分发成本的下降和定制成本的下降。 这是一种值得长期关注的趋势。

十九、Ryan 也承认的限制：这套方法不是万金油

Ryan 的观点尽管激进，但他不盲目。OpenAI 文章在结尾很坦诚地说：他们也不知道完全 agent-generated 系统的架构一致性多年后会如何演化；也还在学人类判断在哪里最有杠杆、怎么把判断编码进去。文章的结论不是“软件工程不需要纪律”，而是纪律更多体现在 scaffolding 上，而不是代码本身——工具、抽象、反馈回路对维持代码库一致性越来越重要。

访谈里 Ryan 把任务分了象限。他认为 hard and new 的问题仍然需要人类驱动；其他象限在合适 scaffold 加 drive-to-completion 的系统下，已经大体可解。人类有限的注意力，应该放在 hardest stuff——纯白纸的问题，或者最深的 refactoring——因为这些地方的接口形状还不清楚，正是人类判断最有价值的地方。

他还提到，当前模型对某些“从零到一”的产品想法和最复杂的重构，仍然需要同步互动。原因是：如果你脑子里的东西没进到模型 context 里，模型也不知道；white space 项目常常要在 agent trajectory 中才显露出缺失信息，需要 harness 或 scaffold 把这些非功能要求、模板和框架偏好提取出来。

这一点的重要性怎么强调都不过分。它意味着——Ryan 这套方法不是要把人完全移走，而是要把人放到更难、更新、更高杠杆的问题上。 routine implementation、QA smoke、CI 修复、merge queue、文档 gardening、技术债清理、dashboard 定义、review comment 处理——这些都该逐渐交给 agent；目标选择、架构方向、产品 taste、风险边界、复杂拆解、组织约束——这些仍然需要人类强参与。

agent 时代的人机分工，并不是“AI 拿走全部”或“人类守住全部”的二选一，而是一条新的分工边界。 这条边界会随着模型能力提升而持续向上漂移，但它存在的事实不会消失。

二十、工程能力的分化：未来十年最值得关注的趋势

如果把 Ryan 这套方法论作为一个时代信号来读，它最深的含义是——工程师群体正在出现一次结构性分化。

一部分工程师会停留在“我用 Cursor / Codex / Claude Code 写代码很快”这一层。他们的生产力比不用 AI 的时候确实会高，可能高到几倍。但他们仍然在做“一次性劳动”——写代码、修 bug、review PR。这些劳动的单位价值会随着 agent 能力提升而持续下降。

另一部分工程师会转向“设计让 agent 工作得好的系统”。他们的产出单位价值会越来越高，因为他们做的每一件事——每一条 lint、每一个 structural test、每一份约束文档、每一个 verification skill——都能被复用无数次。

这两种工程师的长期杠杆率差异不是 2 倍、5 倍，而是 10 倍、100 倍。

工业革命时期的工厂里也有类似的分化：一边是“会操作机器的工人”，另一边是“会设计、维护、改造机器的工程师”。两者的工资差距最初并不明显；几十年之后就出现了量级差异。软件工程的这一次分化，速度可能要比工业革命快得多——因为 AI 的迭代速度本身比蒸汽机快得多。

在这种分化里，评价一个工程师价值的标准也会随之改变：

• 不是看他写了多少代码，而是看他让多少代码不需要再被人写。
• 不是看他修了多少 bug，而是看他让多少同类 bug 以后不会再出现。
• 不是看他参与了多少 review，而是看他把多少 review 意见转化为机械化规则。
• 不是看他知道多少隐性经验，而是看他把多少隐性经验沉淀进了 repo。

简单一句话——评价一个工程师的标准，正在从“做了什么”，变成“使什么不再需要做”。

二十一、一个总结性的判断

把 Ryan Lopopolo 这次实验的意义，放在一个比较克制的位置上来理解。

它不是软件工程的“终结”。代码生成被 agent 接管，并不意味着工程纪律的消失；恰恰相反，它意味着工程纪律的层级被进一步抬高——从代码本身，转移到代码产生、验证、合并、修复、演化的整个系统。

它不是“程序员的失业书”。相反，它把工程师推向一个更难、更复杂、更需要长期判断力的位置——从打字员，变成生产线设计者；从手艺人，变成系统架构者；从执行者，变成组织记忆的维护者。

它也不是 OpenAI 一家公司的内部花活儿。Ryan 自己也明确说，这套方法严重依赖他们仓库的具体结构、Codex 的特定工具、团队的特殊条件，不应该被假设能直接泛化到所有团队。但其中提炼出的工程原则——AGENTS.md 当目录、知识 repo-local 化、约束机械化、反馈 agent 化、错误进入 garbage collection、issue tracker 当 control plane——几乎对每一个正在严肃使用 AI 编程的团队都具有借鉴意义。

如果让我用一句话来概括 Ryan 的 Harness Engineering 观——

AI 时代的软件工程，不是让模型替你写代码，而是把你的工程判断、团队规范、产品品味和质量标准，变成一群 agent 可以持续执行的生产系统。

这件事的意义，在更长的时间尺度上看，类似于一百多年前，福特把“造一辆车”变成“造一条造车的生产线”——改变的不是产品本身，而是产生这种产品的方式。

回看历史，每一次“产生方式的改变”，都意味着一次新的财富分配和一次新的能力溢价。理解这次改变的人会站到杠杆的长端，并把过去靠手艺攒下的判断变成系统的一部分；不理解的人，会发现自己越来越像一个被流水线包围的手艺人——还在勤恳地做事，但每件事的边际价值，已经悄悄不一样了。

工业革命用了一百年完成这件事。
AI 编程时代，留给每一个工程师的窗口，可能只有十年。
窗口不会永远开着，但今天动手，依然来得及。

从写代码到设计代码生产系统：Ryan Lopopolo 的 Harness Engineering 给中文工程师的启示

最近 OpenAI 有一个工程师叫 Ryan Lopopolo，他和团队做了一件挺刺激的事：从空仓库开始，五个月时间，没有人手写一行代码，全部用 Codex 生成了一个差不多一百万行规模的内部产品仓库。1500 个 PR，应用、测试、CI、文档、可观测性、内部工具，全是 agent 写的；他自己估计相当于人手写代码的十分之一时间成本。

这件事我先看到的是 OpenAI 官方博客的那篇《Harness engineering: leveraging Codex in an agent-first world》（2026 年 2 月 11 日），后来又听了 Latent Space 在 4 月 7 日对他的长访谈。看完之后我有一个明显的感觉：这不是又一个“AI 让程序员失业”的故事，而是一份关于“AI 时代工程师该怎么重新组织自己的生产系统”的实地报告。

下面这篇文章，我想用平时跟工程师朋友聊天的口吻，把 Ryan 这套观点拆给你看，再补一些我自己对中文工程师的具体建议。如果你已经在用 Cursor、Codex、Claude Code，但总觉得“提效不够丝滑”——这篇可能正好对上。

一、先把那句最容易被误读的话说清楚：humans steer, agents execute

Ryan 在文章里反复用一句话来描述这套实验：人类掌舵，agent 执行。 中文圈很多人看到这句话，第一反应是“那不就是 AI 干活、人当甲方吗”。

这个理解不对。

我把 Ryan 的真实意思翻译一下，应该是这样：工程师还在 loop 里，只是不再坐在 implementation layer，而是上移到 systems layer。 他还在做判断、还在定优先级、还在拍架构、还在守边界，只是不再把“在键盘上敲源代码”当成主要的产出形态。

为什么这一点重要？因为它直接决定了你怎么使用 AI。如果你把“humans steer”理解成“我提个需求然后等 AI 交活”，你大概率会很失望——因为 AI 不会自动知道你的业务、你的代码风格、你的部署环境、你不想踩的那些坑。Ryan 那个团队恰恰相反：他们花了大量时间，把这些“人脑里的东西”全部翻译成 agent 能读、能执行、能验证的系统组件。

所以这个故事的副标题，与其叫“无人工程”，不如叫“无人工手写源码”。人没有走，只是从打字员的位置，挪到了 tech lead、平台 owner、QA 系统设计者这几个位置。

我的体会是：如果你想用 Ryan 这套方法的十分之一红利，先把“我作为人做什么”重新定义清楚。 你的产出不再是 diff，而是约束、反馈回路、文档、工具和可机械验证的验收标准。

二、Ryan 的起点：先给自己设一个看上去离谱的约束

Ryan 在访谈里讲了一个细节，我觉得特别值得抄作业。他给自己设的初始约束是：完全不写任何代码。

他的理由很冷静：如果 OpenAI 要把 agents 部署到企业里，那 agents 理论上就应该能做我自己能做的事；既然我和 coding harness 已经一起工作了大半年，那我就反过来设计自己的工作方式——唯一能完成工作的办法，就是让 agent 完成工作。

这个约束的妙处在哪里？妙在它封死了“我下次自己上手”这条退路。

很多人用 AI 编程之所以提不上去，就是因为退路太多。AI 写得不好怎么办？我自己改两行就行了。AI 找不到那个 bug 怎么办？我打个断点自己看一下。AI 不知道项目结构？我口头跟它解释一下。这些在单次任务里都很合理，但一旦你有这个退路，你就不会真的去补齐 agent 缺的那些系统能力。

Ryan 把这条退路砍掉之后，每一次 agent 出错都被迫升格成“环境缺陷”——不是 prompt 不够好，而是这个 repo 没有给 agent 配齐它该有的工具、上下文、文档和反馈通道。是缺一个 lint？缺一段 doc？缺一个 CLI wrapper？缺一个 trace 入口？还是 PR 的生命周期没有 agent 化？

他把这种工作起名叫 harness engineering——驾驭工程。它的对象不是 prompt，不是模型，是整个软件生产环境。

中文工程师可以怎么用：你不需要真的禁止自己写代码，但可以试一个更弱的版本——这一周，凡是 agent 能做的事，我就不自己做；它做不好的，我不直接动手改代码，先去补一条规则、一段文档或一个工具。 一个礼拜下来，你就知道你的 repo 离 agent-first 还差多远。

三、模型可以并行，token 可以扩，人类注意力才是真正的瓶颈

Ryan 在访谈里反复强调一件事：模型 trivially parallelizable——你愿意花 GPU 和 token，随时能让一群 agent 同时干活。真正稀缺的，是团队白天能同步投入的那点注意力。

这句话的含义比表面更深。

过去做软件工程，稀缺资源是工程师的写代码时间和 review 代码时间。所以我们的所有流程默认：每个 PR 都要认真看，每个改动都要严格阻塞，每个 merge gate 都要尽量保守。 这套流程在人力是瓶颈的时候没毛病。

可一旦 agent 把代码产能拉到人类 review 容量的十倍，这套流程就会瞬间反过来变成最大的瓶颈。Ryan 团队后来被迫调整了 merge philosophy：PR 的寿命变短，阻塞性的 gate 减少，flaky test 有时先合后修。OpenAI 那篇文章里有一句很实在的话：这种选择放在低吞吐环境里就是不负责任，但放在高吞吐环境里常常是正确取舍。

注意，他不是在劝大家放弃 review。他真正在说的是：当人类 review 变成瓶颈，质量控制就必须前移、机械化、agent 化。 人不应该再花大量时间逐行检查代码，而是要把过去常见的 review 意见，转成 lint、structural test、文档规则、review agent、验收脚本。这样人类的判断只需要被捕捉一次，就能在所有未来 agent 生成的代码上持续生效。

我自己在带团队和做开源时一个反复验证过的判断是：判断什么是“高级工程师”的最简单标准，是看他每次解决一个问题时，是只解决这一次，还是顺手让这一类问题再也不会出现。 Ryan 这套就是把这个标准放大到 agent 时代——agent 一犯错，你的第一反应不是骂它，而是问自己“以后怎么让这种错更难发生”。

一个简单的试金石：你在 Cursor 或 Codex 里反复跟 AI 说“别那么写”、“那个目录不要碰”、“这个字段叫 xxx 不是 yyy”——每一次都是信号。你说过两次以上的话，都该写进 AGENTS.md 或者一条 lint。

四、AGENTS.md 不是百科全书，而是一张目录页

Ryan 文章里我觉得最实操、最容易抄的一条经验是：给 Codex 一张地图，而不是一千页说明书。

他们最早试过那种“什么都往里塞”的巨型 AGENTS.md，结果如你所料：上下文被挤占、所有规则都“重要”等于没有规则、文件很快腐烂、而且没法机械验证。后来他们把 AGENTS.md 砍到大约一百行，定位从“百科全书”降级为“目录”——一个稳定入口，指向 repo 内更深的 source of truth。

真正的知识被搬到结构化的 docs/ 目录里：design docs、execution plans、product specs、references、quality score、reliability、security 等等。计划被当成一等公民——复杂工作有 execution plan，active plans、completed plans、tech debt 都跟代码一起 versioned。

我特别想强调他这套做法背后的一个底层原则：从 agent 的视角看，运行时拿不到的知识就等于不存在。

这条原则一旦你接受了，它会改变你对很多东西的态度。

Slack 上某次架构讨论达成的一致——agent 看不到，等于不存在。Google Doc 里那份 design doc——agent 没把它拉进 context，等于不存在。某位大佬脑子里“我们这里就是这么干的”的 tacit knowledge——只要他没把它写进 repo，等于不存在。code review 留下的那条意见——只要没沉淀成规则，下次另一个 PR 还会犯同样错误。

Ryan 团队为了保证这些文档真的有用，还做了两件事很值得学：

第一，用专门的 lint 和 CI 检查文档的健康度——是否最新、是否交叉链接、结构是否符合规范。
第二，有一个常驻的 doc-gardening agent——定期扫描“文档说的”和“代码做的”是否一致，发现偏差直接开 PR 修。

落地建议：别再写动辄几千行的 AGENTS.md。砍成 100 行的索引就好——项目目录怎么走、关键约束在哪、架构文档去哪、质量规则去哪、运行命令去哪、owner 去哪。剩下的内容拆到 docs/ 里，每个文件管一件事。

五、Agent legibility：代码不是只写给同事看，也要写给模型看

Ryan 提了一个我很喜欢的概念，叫 agent legibility——“对 agent 的可读性”。

他说，因为他们的仓库完全由 agent 生成，所以首要优化目标已经从“对新员工友好”，变成了“对 Codex 可读”。这听起来挺极端，但他的态度其实很微妙：代码不一定要符合人类的所有审美偏好，但只要它正确、可维护、对未来 agent runs 可读，就达标了。

换句话说，human taste 没有消失，只是被重新定义了：从“我喜欢这个实现长什么样”，变成了“这个实现是否可验证、可维护、可被 agent 稳定理解和复用”。

这个观念会反过来影响你的技术选型。OpenAI 文章说，他们偏好那些 agent 能完整 internalize 的依赖和抽象。传统上被称为“无聊”的技术——组合性强、API 稳定、训练集中出现得多——反而更容易被 agent 建模。文章举了个例子：他们没有引入一个通用的 p-limit 风格并发包，而是自己写了一个 helper，跟 OpenTelemetry 集成得好、测试覆盖完整、运行时行为可预期。

Ryan 在访谈里把这个逻辑往前推了一步——内部化依赖。他说，一个几千行的小依赖，可能可以让 agent 一个下午重写一遍，只保留你真正需要的部分；这样以后做安全审查、修 bug、做适配时，Codex 能直接深入修改，而不必等 upstream patch、发布、升级。

但他也老实承认：内部化依赖意味着你回到零，需要重新建立信心和测试。这不是免费的。

我的解读是这样：当代码本身的生成成本下降，软件的价值就从“代码资产”转向“可验证的系统形状”。 以前我们倾向于复用第三方库，是因为重写很贵；Ryan 这套世界里，重写的边际成本下降了，但验证、可观测、边界、安全的成本仍然很贵。所以“用不用第三方库”这个决策，不再只是“不要重复造轮子”，而是要问：这个轮子对 agent 是不是透明？我能不能用我自己的 harness 去约束、测试、审查、修复它？

六、让 agent 能看见应用：UI、日志、指标、trace 都要变成可操作反馈

Ryan 团队后来的代码吞吐量上去之后，很快撞到下一个瓶颈：人类 QA 跟不上。

他们的解法不是雇更多 QA，而是让 agent 自己能 QA。具体做了几件事：

• 应用支持按 git worktree 启动，每个 change 都能对应一个隔离的实例。
• 把 Chrome DevTools Protocol 接入 agent runtime，给 Codex 写处理 DOM snapshot、screenshot、navigation 的 skill，让它自己去复现 bug、验证修复、推理 UI 行为。
• 每个 worktree 配一个隔离的 observability stack，Codex 可以查 logs、metrics、traces，会用 LogQL、PromQL。

这一套搭起来之后，“确保服务启动低于 800ms”、“这四条关键用户路径里没有 span 超过两秒”——这种 prompt 才真正变得可执行。

Ryan 在访谈里讲了一个我觉得很有代表性的例子：他们让 Codex 直接生成 Grafana dashboard 的 JSON，然后发布 dashboard；Codex 也会响应 page。因为 dashboard、alert、log、code 都被 collate 在一起，告警发生时 agent 能知道是哪个 alert 被哪条 log 触发的；如果某个 outage 没有 page，它还可以根据已有 dashboard 找到观测缺口并修复。

这就是“agent-first 可观测性”的真正含义：可观测性不是给人类 on-call 看图用的，而是给 agent 闭环修复用的。

他还说了一个反直觉的观察：他们工程师有人花了一个下午做了个漂亮的 trace visualization 工具，结果后来发现，直接把 trace tarball 丢给 Codex 让它分析修复，反而更符合 agent-first 的路线。 因为最终修代码的是 Codex，而不是人类盯着图看完再去改。

留意一个信号：每次你在 chat 里给 AI 贴日志、贴报错、贴截图，说明这条反馈路径还没进 agent 的工具链。与其每次手动复制粘贴，不如花半小时写一个能直接拉日志、跑测试、截图、读 trace 的小工具。

七、不要 micromanage 实现，要机械化边界

Ryan 还有一条很硬核的观点：文档本身不足以让一个完全 agent-generated 的 codebase 保持一致。 你不能只跟 agent 说“请写得优雅”，也别指望它自然遵守团队的 tacit taste。那些不可妥协的架构边界和 invariant，必须机械化。

OpenAI 那篇文章里讲了他们怎么做的：把业务 domain 切成固定层级，用 custom lint 和 structural test 强制依赖方向。大致是 Types → Config → Repo → Service → Runtime → UI，横切关注点通过 Provider 这种显式接口进入，其他边一律禁止。

但 Ryan 的关键判断是：约束 invariant，不要 micromanage implementation。 比如他们要求 Codex 在边界上解析数据形状，但不指定一定要用某个库。这样 agent 既能快速出货，又不会破坏地基。

这种“七人团队做五百人公司架构”的做法，初看显得过度。Ryan 在访谈里直接回应过这个质疑：他们的仓库有差不多 500 个 NPM packages，按普通七人团队标准是过度分解；但如果每个工程师实际上在驱动 10 到 50 个 agent，那这就更像一个 350 人的团队了。深度 decomposition、sharding、清晰接口边界，这些“大公司病”的产物在 agent-first 团队里反而是必需品。

这里其实藏着一个对小团队特别有指导意义的判断：agent-first 团队的人数不能按 head count 计算，要按并发执行单元计算。 七个人加几十个 agent，已经是几百人协作的规模问题；命名、边界、依赖、复用、日志、测试、文档、ownership，必须提前结构化。

如果你已经开始让一个人挂 5–10 个 agent 干活，赶紧把“小团队就别搞这些虚的”这个心态收起来。你实际上已经是大团队了，只是 head count 没涨。

八、PR review 的未来：从逐行审查转向“可信任的证据包”

Ryan 对 review 的看法在中文圈应该会有点争议。他在 OpenAI 文章里说：人类可以 review PR，但不总是必须；随时间推移，他们把几乎所有 review 努力推向 agent-to-agent。访谈里他更直白：大部分 human review 已经是 post-merge。

听到这里你可能本能不舒服，但他自己也明确补了一句限定：他们做的是 native application，不是连续部署的高可靠基础设施；发布分支和分发前 smoke test，仍然有人类批准。

所以 Ryan 真正想说的不是“取消 review”，而是审查对象和信任机制要变。

他在访谈里有一句话我很喜欢：他希望 coding agent 在 PR 上附一个视频，展示功能在真实产品里能跑起来。 这相当于把 agent 完整的工作轨迹压缩成一个 reviewer 可读的“信任包”。

这个类比特别精准：人类同事提 PR 时，我们不会要求他屏幕录制整个写代码过程；我们只要他给出足够证据，让我们相信代码可以 merge。 Ryan 把 agent 也当 teammate 看：不要 shoulder-surf 它每个动作，而要让它产出 reviewer 需要的压缩证据。

证据可以是什么？——单元测试、E2E 测试、trace、video walkthrough、log 摘要、review agent 给出的结论、CI 状态、structural check 结果、quality score、tech debt 更新。人类 review 的价值，就从“逐行检查生成物”，转向了“检查验证体系是否覆盖了风险”。

下次你 review AI 写的 PR 时，别再老老实实一行行看了。换个问法：这个变更动了什么风险面？这些风险有没有被自动化覆盖？如果没有，第一件事是补覆盖，而不是用人眼去当 lint。

九、错误不是一次性修补，而是进入“垃圾回收”系统

Ryan 很清楚完全 agent autonomy 会带来新问题。OpenAI 文章里提过：Codex 会复制 repo 里已有的模式，包括不均匀或次优的模式；时间一长会 drift。他们最早每周五花 20% 时间清理“AI slop”，但很快发现这种打地鼠模式不可扩展。

后来他们做了两件事：

第一，把 golden principles 编码进仓库——这些是有观点的机械规则，目标是维持代码对未来 agent runs 的可读性和一致性。比如偏好 shared utility package、不允许 YOLO 猜数据形状、网络调用必须有 timeout 等等。
第二，建立 recurring cleanup process——后台 Codex 任务定期扫偏差、更新 quality score、开 targeted refactoring PR；很多可以在一分钟内 review 并 automerge。

Ryan 把这事叫 garbage collection。我觉得这个比喻特别到位——技术债像高利贷，最好持续小额偿还，而不是让它复利增长到痛苦爆发。

这个概念之所以重要，是因为它把“AI slop”从道德议题变成了工程对象。Ryan 不否认 slop 存在，他说的是：如果 agent 会复制坏模式，那就要设计持续回收坏模式的系统。所谓 human taste，不是每次人类出来骂一句“这个写得丑”，而是把 taste 捕捉成原则、lint、review prompt、quality score 和后台清理任务。

这一点，跟 Mitchell Hashimoto 在 2026 年 2 月那篇《Engineer the Harness》里讲的几乎是一回事——发现 agent 犯错，就工程化一个解决方案让它以后别再犯。Ryan 这边是在更大规模上展示了它怎么变成一个团队系统。

十、Symphony：让 issue tracker 成为 agent 的 control plane

Ryan 最近还有一项工作值得单独拿出来讲，叫 Symphony。OpenAI 在 2026 年 4 月 27 日发布了 Symphony 文章，虽然不是 Ryan 单独署名，但它直接继承了 harness engineering 实验：团队在“无人手写代码”的工作流里继续撞墙，下一个瓶颈是 context switching。

Ryan 在访谈里说，到了 GPT-5.2 之后，每个工程师每天能稳定推 5–10 个 PR；但代价是不断在 tmux pane 之间切换，人开始疯。同时管理 3–5 个 Codex session 就开始痛苦：忘记哪个 session 在做什么、agent 卡了你不知道、复杂的长任务总是要回头检查。

Symphony 的核心设计很 elegant：不要直接监督 agent，让 agent 从任务系统里拉活。 Linear 上的每个 open task 对应一个 agent workspace；Linear 的状态本身变成了一台状态机；agent crash 或 stall 了，Symphony 自动重启；新 work 出现，Symphony 自动拾取；复杂任务可以让 agent 先分析 codebase + Slack + Notion 产出 implementation plan，再把 plan 拆成任务 DAG，未阻塞的任务自然并行。

OpenAI 文章给了一个数字：有些团队上 Symphony 三周后 landed PRs 增加了 500%。 但更深层的变化是：每个 change 的感知成本下降了。人不再亲自驱动实现，所以 speculative task 变得便宜——试一个想法、探索一个 refactor、测试一个假设，不行就丢掉。产品经理和设计师甚至可以直接向 Symphony 提 feature request，拿回一个包含真实产品视频 walkthrough 的 review packet。

Ryan 在访谈里特别提了一个 Symphony 的 rework state 设计，我觉得非常符合 agent-first 思维：如果 PR 不可 merge，就把 worktree 和 PR 整个丢掉，从头再来。然后追问“它为什么是垃圾”——先修 prompt、skill 或 guardrail，再把 ticket 重新推入 progress。

这背后是一个非常不一样的成本观：当代码便宜时，保留错误路径不一定值得。 有时丢弃、补护栏、重跑，反而比 patch 干净。这种思路在传统工程师脑子里很难一下接受，但在 token 便宜、模型够强的世界里，是合理的。

十一、不要把 agent 关进过度僵硬的盒子，要给它目标、上下文和工具

Ryan 还有一个很重要的演进判断：早期的 agent 适合放在预定义 scaffold 或状态机里；但 reasoning model 一旦变强，过度僵硬的 scaffold 反而会限制它。

他们后来“反转”了系统：不是先搭一个环境再把 coding agent spawn 进去，而是让 Codex 本身成为入口，再通过 skill 和 script 给 Codex 启动 stack、设置环境变量、查询 observability 数据的能力。

在 Symphony 那边，他们也意识到把 agent 当成状态机里的 rigid node 效果不好——模型变聪明后，能解决的问题比你试图塞给它的 box 更大。早期只让 Codex implement task 太限制；后来给它 gh CLI、读 CI logs 的 skill，让它去关掉旧 PR、拉报告、做更多事情。最终他们更倾向于给 agent 一个 objective，而不是一串严格的 transition。

但他立刻又补了一句关键限定：给它 context 和 tools。 也就是说，box 不是没有，box 变成了整个 harness：权限、工具、repo 结构、workflow policy、observability、CI、lint、skill、sandbox、human escalation——共同构成一个可操作的环境。

我看到很多团队失败的 agent workflow，都掉在两个极端里：要么把 agent 关进过窄的工具箱，期待它 magically 完成复杂任务；要么给它完全开放的环境，却没有日志、测试、边界和 policy。 Ryan 的中间道路非常清晰——不要 micromanage 每一步，但要严肃设计 agent 可见的世界。给目标，也给观测；给自由，也给 invariant；给工具，也给反馈；给上下文，也给可机械执行的验收标准。

十二、文本是 agent 的血液：把经验、失败、评论、日志都“吸回仓库”

Ryan 在访谈里有句话我觉得特别准：模型 fundamentally crave text。

他们做的很多事，本质上都是在把文本注入这个系统让 agent 能用。比如某次缺 timeout 导致 page，他们直接在 Slack 里 @ Codex，让它不光是给那个调用加 timeout，还要更新 reliability documentation，把“所有网络调用都必须有 timeout”写进规则。这样团队不只是修了一个点，而是把“什么是好”持久编码进流程知识。

他们还做了一件挺有意思的事：对 session log 做 skill distillation。Codex 自己的 session log 收集到 blob storage，每天跑 agent loop 分析“团队哪里做得不够好”，再把结论反馈回 repo。PR comment、failed build——所有这些都是信号，代表某个时刻 agent 缺上下文；这些信号要被吸收，然后塞回 repo。

这件事让 harness engineering 有了一种自改进的味道。它不是一次性配置，而是持续学习系统——agent 失败 → 失败变成文本信号 → 文本信号被分析 → 规则、skill、文档、工具更新 → 未来 agent 更少失败。这个循环越顺畅，团队的经验复利越强。

Ryan 还说了一个反共识但其实很对的观察：改 agent behavior 比改 human driver behavior 便宜得多。 团队里每个人都去养成新习惯很难；但你把新习惯写进 shared skill、lint、workflow prompt 或 CI，所有 agent 立即继承，所有人间接受益。

十三、CLI-first 与 token 效率：给 agent 的工具，要少废话、结构化、只吐失败信息

Ryan 对工具输出格式有非常具体的偏好：CLI 对 agent 友好，因为 token efficient，而且容易被改造得更 token efficient。

他举了个例子：构建输出常常是一大墙文本；过去 dev productivity team 会写工具把真正异常抽出来放到顶部。给 agent 的 CLI 也应该这样——格式化命令不必输出每个已格式化文件，agent 只要知道 formatted or not；测试输出尽量只吐失败部分。

听起来是小优化，但在 agent-first 系统里是大事。人读日志可以扫一眼跳过；LLM 处理日志时，无关 token 会占 context、干扰注意力、增加成本，还可能触发错误推理。 好的 agent tooling 应该把输出压缩成“下一步行动所需信息”。

他还提了一个相关的细节：让非文本的事物也尽量适配文本形态。讨论 agent 怎么“看” UI 时他说，agent 不是像人一样用视觉感知 layout 的——有时候 rasterize 图像 + OCR、或者把 DOM/截图/导航事件一起喂进去，模型才能更好地理解它在操作什么。

我把这点单独拎出来，是因为它给所有做工具的人指了一个明确方向：未来的软件工具不只要 human-readable，也要 agent-readable。 日志、CLI、错误消息、lint message、dashboard、trace、PR comment、issue description——都应该考虑一个问题：模型看到这一段输出后，能不能直接做出正确的下一步？

这可能是 Ryan 整套观点里最容易被低估的一点：agent-first 不只是“使用 agent 写软件”，还意味着整个软件生态的接口都要为 agent 优化。

十四、Ghost Libraries：当代码便宜时，软件可以以 spec 的形式分发

Ryan 在访谈里还谈到一个挺未来感的概念：Ghost Libraries。

Symphony 的开源形式很特别，它不是先给一个完整实现，而是先给一个高保真的 spec，让 coding agent 可以在本地重新组装出来。OpenAI 那篇 Symphony 文章里说，仓库第一眼看到的是一个 SPEC.md，定义问题和预期解法，而不是只给一个复杂的监督系统。

Ryan 描述他们提取 spec 的过程也挺有意思：从内部 proprietary repo 里抽 scaffolding，开新仓库，让 Codex 参考原 repo 写 spec；再让一个断开的 Codex 实现 spec；再让另一个 Codex 比较实现与 upstream，更新 spec 让它更少偏离；如此循环，直到 spec 能高保真地复现系统。

这是一种非常不同的软件分发观。过去我们分发软件，主要分发 source code、binary、library、API。Ryan 设想里，如果 agent 足够会写代码，spec 本身就可能成为软件资产——它描述问题、边界、流程、接口、状态机、成功标准和非目标，由本地 agent 根据具体环境生成实现。

OpenAI 的 Symphony spec 就强调：它是 scheduler / runner 和 tracker reader，ticket 写入通常由 coding agent 在 workflow runtime 里完成；它不强制单一 sandbox 或 approval policy，而要求实现者明确自己的 trust and safety posture。

这有两个我觉得很值得想一想的后果：

第一，软件变得更 adaptable。 spec 可以让 Jira、Bitbucket、Linear、GitHub 等不同环境替换具体集成，只保留更柏拉图式的抽象。

第二，工程里“实现细节”的价值在下降，“可复现的高质量规格”的价值在上升。 如果 agent 能从 spec 生成不错的实现，那么真正稀缺的是：问题定义是否准确？边界是否清晰？验收标准是否可执行？安全姿态是否明确？观测是否足够？——这又回到 Ryan 的主线：工程师的价值从写代码转向设计可执行环境。

十五、Ryan 也承认限制：hard + new、复杂重构、长期一致性，仍然要人

Ryan 的观点激进，但他不盲目。OpenAI 那篇文章在结尾很坦诚地说：他们也不知道完全 agent-generated 系统的架构一致性多年后会怎么演化；也还在学人类判断在哪里最有杠杆、怎么把判断编码进去。文章的结论不是“软件工程不需要纪律了”，而是纪律更多体现在 scaffolding 上，而不是代码本身——工具、抽象、反馈回路对维持代码库一致性越来越重要。

访谈里 Ryan 把任务分了象限。他认为 hard and new 的问题仍然需要人类驱动；其他象限在合适 scaffold + drive-to-completion 的系统下，已经大体可解。人类有限的注意力，应该放在 hardest stuff——纯白纸的问题，或者最深的 refactoring——因为这些地方的接口形状还不清楚，正是人类判断最有价值的地方。

他还提到，当前模型对某些“从零到一”的产品想法和最复杂的重构，仍然需要同步互动。原因是：如果你脑子里的东西没进到模型 context 里，模型也不知道；white space 项目常常要在 agent trajectory 中才显露出缺失信息，需要 harness 或 scaffold 把这些非功能要求、模板和框架偏好提取出来。

这里的边界感很重要。Ryan 不是要把人完全移走，他是把人放到更难、更新、更高杠杆的问题上。

反过来看普通工程师：routine implementation、QA smoke、CI 修复、文档 gardening、技术债清理、review comment 处理——这些都该逐渐交给 agent；目标选择、架构方向、产品 taste、风险边界、复杂拆解——这些仍然需要人类强参与。

十六、给中文工程师的五条可操作建议

这套实验直接照搬到普通团队风险很大。它发生在 OpenAI，token / 模型 / Codex 资源、团队能力、greenfield 条件、产品类型、风险承受能力都很特殊。Ryan 自己也承认不该泛化成“所有场景都适用的脚本”。

但你不需要复制极端形式，只需要复制工程原则。 我把它翻成五条可以这周就开始做的建议：

第一条，每次 agent 犯错，都问“如何让这个错误以后更难发生”。 答案可能是一条 AGENTS.md 入口、一个测试、一段 lint、一个 CLI wrapper、一个 PR checklist，或者一个 recurring cleanup agent。形式不重要，关键是不要原地修了就走。

第二条，把不可见的知识变成 repo-local 的知识。 只在你脑子里的约定，对 agent 不存在；只在聊天记录里的架构决策，对未来 agent 不存在；只在某次 review comment 里的判断，没被吸收成规则就不会复利。把隐性经验逼成可版本化、可链接、可验证的文本和工具。

第三条，把验证权尽量交给 agent 能调用的工具。 如果 agent 能自己跑应用、看 UI、查 log、看 trace、生成视频、重跑 CI、处理 review comment，它就能端到端完成更大任务。没有这些工具，再强的模型也会反复问人、反复猜、反复产生不可验证输出。

第四条，把 human taste 编码成边界，而不是审美抱怨。 人类有品味没问题，但在 agent-first 系统里，品味必须落成 invariant：结构化日志、schema 命名、文件大小、依赖方向、数据边界解析、可靠性要求、测试质量、文档新鲜度。否则你就会一辈子在 review 里重复那句“我们这里不这样写”。

第五条，不要 babysit agent，而是设计它不需要 babysit。 你未必要上 Symphony，但可以从最小版本开始：为每类任务准备清晰的 issue、验收标准、运行命令、测试脚本、失败输出摘要、重跑规则。让 agent 自己跑、失败、重启、提交、附证据、必要时升级给人。

结语：把判断变成系统，是 AI 时代工程师的真正护城河

Ryan Lopopolo 这套观点真正预示的，不是程序员马上失业，也不是代码不再重要，而是软件工程的重心在移动。代码越来越容易生成，真正稀缺的是：目标定义、环境设计、反馈回路、架构边界、验证机制、组织知识、风险判断。人类工程师仍然重要，但重要的方式变了。

在这个范式里，优秀工程师不再是亲自写最多代码的人，而是能让一群 agent 稳定产出高质量代码的人。他不是每次都能救火的那个人，而是能把火灾模式变成传感器、护栏和自动修复流程的人。他脑子里的隐性经验不比别人少，但他会把这些经验转化成 repo-local、agent-legible、mechanically enforced 的系统。

Ryan 自己在文章最后说得很谨慎——他们最困难的挑战已经集中在 designing environments、feedback loops 和 control systems 上，以帮助 agent 大规模构建和维护复杂可靠软件。也就是说：未来的软件工程纪律没有消失，只是从代码文本本身，转移到了代码产生、验证、合并、修复和演化的系统。

如果让我用一句话总结 Ryan 的 Harness Engineering 观给中文工程师的启示，我会这样写：

AI 时代的软件工程，不是让模型替你写代码，而是把你的工程判断、团队规范、产品品味和质量标准，变成一群 agent 可以持续执行的生产系统。

懂这件事的人，未来十年会越走越轻。不懂的人，会发现自己在跟一个永远写不完代码的 AI 比手速——这比赛你赢不了，也不该参加。

从写代码到设计代码生产系统：从 Ryan Lopopolo 的 Harness Engineering 提炼出十二个心智模型

「编辑器之外才是真正的工程。」
这是我读完 Ryan Lopopolo 那篇《Harness engineering》之后，在 flomo 里给自己留的第一句话。

最近我反复在读两份材料：一份是 Ryan Lopopolo 在 OpenAI 官方博客上发表的《Harness engineering: leveraging Codex in an agent-first world》（2026 年 2 月 11 日），另一份是 Latent Space 在 4 月 7 日对他做的长访谈。

它们讲的是同一件事：OpenAI 一个小团队用大约五个月，从空仓库开始构建了一个接近百万行规模、约 1500 个 PR 的内部产品——人类没有手写代码，全部由 Codex 完成；他自己估计大约是手写代码所需时间的十分之一。

我对这种“震撼数字”其实兴趣不大。每隔半年都会有人拿出新的数字震撼一次，听多了就麻木。让我反复回看的，是 Ryan 在数字背后展示的那套工作哲学——他几乎是在重新回答一个老问题：在一个机器可以代我执行的时代，作为一个工程师，我到底在做什么？

这篇笔记把他散落在文章和访谈里的观点，提炼成十二个心智模型。每一节先放一段他的原话或我的转述，再写我自己的理解，以及我打算怎么用。

模型 1：从 implementation layer 上移到 systems layer

「Humans steer. Agents execute.」
但这句话最容易被误读成“人类不用管了，模型自己写就行”。

读到这句话时，我第一反应不是激动，而是警觉。
因为它太顺口，太容易被一带而过。

Ryan 自己在文章里其实给了限定：团队的主要工作变成了设计环境（designing environments）、表达意图（specifying intent）、构建反馈回路（building feedback loops）。换句话说——

人没有从循环里消失，人只是从打字员的位置，挪到了系统设计者的位置。

这是我提炼的第一个心智模型：

工程师的工作层级有两层：implementation layer 和 systems layer。
在 implementation layer 上，你用键盘产出 diff。
在 systems layer 上，你产出的是约束、反馈回路、文档、工具和验收标准。
当 AI 的边际成本下降到接近零，layer 1 的产出价值会被快速稀释；layer 2 的产出价值反而会被放大。

这并不是“人不写代码”那么简单。它在悄悄改变我对自己每天时间的分配方式。

写代码两小时，等于交付一段一次性可执行的逻辑。
写一条让 agent 以后都不会再犯同类错误的规则，等于交付一段可以无限次复用的判断力。

我以前会本能觉得，前者是“在做事”，后者是“在偷懒”。读完 Ryan 之后，我开始怀疑这个判断是不是已经过时了。

模型 2：把“模型缺陷”重命名为“环境缺陷”

「Don’t say the model can’t do it. Say the environment isn’t yet specified for it.」
（这是我对 Ryan 一段话的浓缩。）

Ryan 提到，他在最初的实验里给自己设了一个看起来挺极端的约束：完全不写任何代码。

为什么要这么做？
他给自己留了一个唯一出口：如果我不能写代码，那唯一能完成工作的办法，就是让 agent 完成工作。

这个约束的真正威力在于——
它封死了“我下次自己来”的退路。

每当 agent 失败，他不能说“算了我自己改”，只能问：

• 是缺什么工具？
• 是缺什么文档？
• 是缺什么测试？
• 是缺什么 trace？
• 是缺什么 sandbox？
• 是缺什么验收标准？

这种问法的不同，会带来完全不同的产出。
“模型不行” → 等下一代模型。
“环境不行” → 你今天就有事可做。

换一种说法：

不要把 AI 的失败归因为模型缺陷。
把它归因为：你还没有把正确的能力暴露给它。

这个 reframing 看起来很微小，但它把“AI 是否能做这件事”，从一个模型能力问题，转化为一个工程师可设计的问题。

副作用：你会发现自己开始有耐心了。
当你相信“再等一代模型就好”，你会拖延。当你相信“是我没把环境配好”，你会动手。

模型 3：注意力是稀缺资源，token 不是

「Models are trivially parallelizable.
Team attention isn’t.」

这句话值得贴在每个 AI 时代团队 leader 的工位上。

Ryan 在访谈里反复提到，真正稀缺的，不再是写代码或 review 代码的时间，而是团队白天能同步投入的注意力。

这件事的含义远比表面深。
过去的工程流程，几乎全部默认了一个前提：人是瓶颈。所以每个 PR 都要认真看，每个 gate 都要严格。这套流程在人是瓶颈时是合理的；但当 agent 把代码产能拉到人类 review 容量的十倍，这套流程会在一夜之间反过来变成最大的瓶颈。

OpenAI 那篇文章里有一句让我反复琢磨的话：

这种 merge philosophy（短寿命 PR、阻塞 gate 较少、flaky test 后置处理）放在低吞吐环境里会不负责任，但在高吞吐环境里常常是正确取舍。

注意，他不是说“取消 review”。他是说：当人类 review 变成瓶颈，质量控制必须前移、机械化、agent 化。

由此引出一个判断标准：

如果你每天大量时间花在重复说同一件事——“别这么写”、“那个目录不要碰”、“这个字段叫 xxx 不是 yyy”——那不是你勤奋，那是你的 system 不够好。
真正高级的工程师，不是把这一类问题处理快的人；是把这一类问题变成“以后再也不会发生”的人。

把判断只表达一次、然后让它在未来无限次自动生效——
这就是 AI 时代的复利。

模型 4：AGENTS.md 不是手册，而是目录

一份巨型 AGENTS.md = 没有规则。
一份 100 行的 AGENTS.md + 结构化 docs/ + 机械验证 = 一个会自我更新的知识系统。

Ryan 团队最早试过那种“什么都往里塞”的巨型 AGENTS.md，结果如他所说——
上下文被挤占；所有规则都“重要”等于没有规则；文件迅速腐烂；机械验证不可能。

后来他们把 AGENTS.md 砍到 ~100 行，定位降级为目录——一个稳定入口，指向 repo 内更深层的 source of truth。真正的知识被搬到结构化的 docs/ 目录里：design docs、execution plans、product specs、references、quality score、reliability、security……

这让我想起一个说法：“Don’t have a single source of truth, have a single source of navigation.” 以前不太理解；读完 Ryan，突然通了。

他把背后的原则讲得很直接：从 agent 视角看，运行时拿不到的知识就等于不存在。

顺着这个逻辑，可以分出三层知识可见性：

1. 只在你脑子里 → 对世界不存在。
2. 写在 Slack / Google Doc / Notion → 对未来 agent 不存在。
3. 写在 repo 内可被工具访问、可被 lint 验证、可被 CI 守护 → 对 agent 真实存在。

这条模型对我个人写作也有触动：
我所有的 flomo 卡片，如果不能被自己未来的搜索找到、不能被自己未来的写作引用，它们只是数字版的“曾经想过”，不是真正的资产。

顺手补一笔：Ryan 团队甚至有个 doc-gardening agent 定期扫“文档说的”和“代码做的”是否一致，发现偏差直接开 PR 修。
这才叫让知识自己保鲜。

模型 5：Agent legibility——代码不只写给同事看，也写给模型看

「The first reader of our code is no longer a new hire. It’s Codex.」
（我对 Ryan 文章里一段意思的浓缩。）

我们这一代工程师从读《Clean Code》开始，被反复教育“代码首先是给人读的”。
现在 Ryan 提了一个新概念：agent legibility——对 agent 的可读性。

不是说代码不再要给人读，而是说——
当一个仓库的多数代码已经由 agent 生成、未来的修改也将由 agent 来做，那么“对 agent 可读”就成了首要约束之一。

Ryan 的态度其实很微妙：代码不一定要符合所有人类的审美偏好，但只要它正确、可维护、对未来 agent runs 可读，就达标。

想通这一点之后，human taste 没有消失，而是被重新定义了：
从「我喜欢这个实现长什么样」 →
变成 「这个实现是否可验证、可维护、可被 agent 稳定理解和复用」。

落到操作层面：

代码品味不再是个人审美问题，而是系统形状问题。
你的“好品味”应该可以被表达成一个 lint，一个 structural test，一份 AGENTS.md 规则；
而不是一句“我们这里不这样写”。

这一条直接改变了我评价“资深工程师”的方式。
以前我会被那种“一眼看出代码不对劲”的人折服。
现在我更佩服那种能把“为什么不对劲”提炼成 agent 也能机械检查的规则的人。

后者才是 agent 时代的核心能力。

模型 6：依赖的内部化，与“边界对 agent 是否透明”

「Sometimes it’s cheaper to let an agent rewrite a small dependency than to live with an opaque upstream library.」

Ryan 这个观点初看很激进——
他说，一个几千行的小依赖，agent 可能可以用一个下午重写一遍，只保留你真正需要的部分；以后做安全审查、修 bug、做适配时，Codex 能直接深入修改，不必等 upstream patch、发布、升级。

我第一反应是：“这不是反 DRY 吗？”
但读到下面这句话时停住了——

他没有否认重写有成本。他承认：内部化依赖意味着你回到零，需要重新建立信心和测试。

也就是说，这不是“造轮子有理”的浪漫宣言，而是一个成本结构变化后的冷静推算。
代码生成成本下降，但验证、可观测、边界、安全的成本仍然很贵。

翻译成一个决策框架：

当你在评估是否引入一个依赖，问题不再只是“它能不能省我时间”。
还要问：

• 这个依赖对 agent 是不是透明？
• 我的 harness 能不能约束、测试、审查、修复它？
• 如果它出 bug，我的 agent 能不能直接进入它内部修？
  如果三个问题里有任何一个是“否”，这个依赖在 agent 时代就不再“免费”。

这条原则也悄悄改变了我对“无聊技术”的看法。
以前我对那些组合性强、API 稳定、训练集中出现得多的“无聊技术”略带不耐。
现在我意识到——正是这种“无聊”，让 agent 更容易建模、更容易预测行为、更不容易出意外。

启示之一：写新项目时，主动选无聊技术，是一个对 agent 友好的决定。

模型 7：Agent 必须能看见应用本身

「If your agent can write code but can’t run the app, see the UI, query the logs, or read the traces — it still needs you to babysit.」

Ryan 团队代码量上去之后，撞到的下一个瓶颈是 人类 QA 跟不上。

他们的解法不是雇更多 QA，而是让 agent 自己能 QA：

• 应用支持按 git worktree 启动，每个 change 都能对应一个隔离实例。
• 把 Chrome DevTools Protocol 接入 agent runtime，给 Codex 写处理 DOM snapshot、screenshot、navigation 的 skill。
• 每个 worktree 配一个隔离的 observability stack，Codex 自己会用 LogQL、PromQL 查 logs、metrics、traces。

这一切搭起来之后，“确保服务启动低于 800ms”这种 prompt 才真正变得可执行。

让我印象很深的一个细节：他们让 Codex 直接 author Grafana dashboard 的 JSON，并且让 Codex 响应 page——告警发生时它能知道是哪条日志触发的；甚至当某个 outage 没有触发 page，它还可以根据已有 dashboard / metrics / logs 找到观测缺口并修复。

这件事指向一个正在发生的变化：

可观测性的真正受众，正在变化。
过去是给人类 on-call 看图用的；
现在它要被设计成给 agent 闭环修复用的。

过去做 dashboard，目标是“让人一眼看懂”。
未来做 dashboard，目标可能是“让 agent 能稳定地从中读出下一步该做什么”。
这两件事并不总是同一个最优解。

顺手补一笔：Ryan 提到他们工程师有人花了一个下午做了一个漂亮的 trace visualization 工具——
后来发现，直接把 trace tarball 丢给 Codex 让它分析，更符合 agent-first 的路线。
这件事我反复回味。人类 UI 不一定是 AI 时代最高 ROI 的产出形态。

模型 8：约束 invariant，但不要 micromanage implementation

「Encode the invariants. Don’t dictate the implementation.」

这是我读 Ryan 文章时画了三道线的地方。

OpenAI 那篇文章里讲了他们怎么做：把业务 domain 切成固定层级，用 custom lint 和 structural test 强制依赖方向（大致是 Types → Config → Repo → Service → Runtime → UI），横切关注点通过 Provider 这种显式接口进入，其他边一律禁止。

但他们不指定 Codex 必须用某个具体库，只要求它在边界上解析数据形状。
这就是 invariant 与 implementation 的分界：

• invariant——架构边界、依赖方向、数据边界、不变量；这些是机械化的、不可妥协的。
• implementation——具体用什么库、什么结构、什么风格；这些应该尽量留给 agent 自由。

用起来很简单：

当你要约束 agent 时，先问自己：这条约束是 invariant 还是 taste？
Invariant 写成 lint 或 structural test。
Taste 写成 docs 或 review prompt。
不要把 taste 假装成 invariant，否则你会让 agent 过度受限；也不要把 invariant 留在 docs 里漂着，否则它会被忽略。

Ryan 在访谈里还有一个我特别认同的比喻：他说自己的心态像是在担任一个 500 人组织的 group tech lead——对一个 500 人组织的技术负责人来说，逐行点评每个 PR 是不合适的；更重要的是通过样本观察团队哪里卡住、哪里需要帮助、哪里已经跑得快，然后把注意力转到更高杠杆的位置。

他们的仓库有大约 500 个 NPM packages。一个七人团队搞这种结构，初看像“过度架构”。但 Ryan 反问得很好：如果每个工程师驱动 10 到 50 个 agent，那它已经不是七人团队了。

可以拿这条来 self-test 自己的组织：
你团队的人数 × 平均 agent 数 = 你真正需要的协作设计规模。
别再用“我们就几个人”为低组织化辩护——
你已经是大团队了，只是 head count 没涨。

模型 9：Review 的未来——从逐行审查到“可信任的证据包”

「Don’t shoulder-surf the agent. Make it produce a compressed packet of evidence you can trust.」

Ryan 在 review 这件事上的观点是容易引来争议的——
他在 OpenAI 文章里说：人类可以 review PR，但不总是必须；随时间推移，他们把几乎所有 review 努力推向 agent-to-agent。访谈里他说得更直接：大部分 human review 已经是 post-merge。

但他立刻补了限定：他们做的是 native application，不是连续部署的高可靠基础设施；发布分支与分发前的 smoke test，仍然有人类批准。

所以他真正想说的不是“取消 review”，而是审查对象与信任机制要变。

让我印象最深的是他在访谈里那个具体设想——
他希望 coding agent 在 PR 上附一个视频，展示功能在真实产品里能跑起来。
这相当于把 agent 完整的工作轨迹压缩成一个 reviewer 可读的“信任包”。

想想看：

人类同事提 PR 时，我们不会要求他屏幕录制整个写代码过程；我们只要他给出足够证据，让我们相信代码可以 merge。
Agent 也应当这样被对待。
你不需要 shoulder-surf 它的每一个动作，你需要的是 reviewer 的“证据包”——测试、trace、video walkthrough、log 摘要、review agent 结论、CI 状态、structural check、quality score、tech debt 更新。

这条模型直接改变了我评价“我做了多少 review”的方式。
不是逐行看了几个 PR，而是这周我把多少风险面变得可被自动验证。
前者是消耗品，后者是资产。

模型 10：错误不是“修补”，而是进入垃圾回收系统

「Tech debt is high-interest debt. Garbage collect it continuously, or it explodes.」

Ryan 没有回避一个问题：完全 agent autonomy 会带来新麻烦。
Codex 会复制 repo 里已有的模式，包括不均匀或次优模式，时间一长会 drift。他们最早每周五花 20% 时间清理“AI slop”，但很快发现这种打地鼠不可扩展。

后来做了两件事：

第一，把 golden principles 编码进仓库——有观点的机械规则，目标是维持代码对未来 agent runs 的可读性和一致性。
第二，建立 recurring cleanup process——后台 Codex 任务定期扫偏差、更新 quality score、开 targeted refactoring PR；很多可以一分钟内 review 并 automerge。

Ryan 把这事叫 garbage collection。

我特别喜欢这个比喻。因为它把“AI slop”从一个道德议题变成了一个工程对象。

他不否认 slop 存在。
他只是说——如果 agent 会复制坏模式，那就要设计持续回收坏模式的系统。
所谓 human taste，不是每次人类出来骂一句“这个写得丑”，而是把 taste 捕捉成原则、lint、review prompt、quality score 和后台清理任务。

底层逻辑是这样的：

任何长期运行的系统都会产生熵。
你不能靠“人类发现 → 人类修补”来对抗熵，因为这条路径的成本会随系统规模线性增长。
你必须有一个持续运行的 garbage collector——
在代码里、在文档里、在依赖关系里、在 review queue 里。

这个模型也适用于个人知识系统。
flomo 卡片越多，搜索的信噪比越差。
没有 garbage collection 的笔记系统，最后变成一个“装着自己曾经想过的东西的坟墓”，而不是一个能产出新洞察的工具。

模型 11：从“管理 session”到“让 issue tracker 成为 agent 的 control plane”

Symphony 不是工具，是一种 reframing：
不要监督 agent，让 agent 从任务系统里拉活。

Symphony 是 Ryan 后续工作里我最想单独拿出来讲的一项。
OpenAI 在 2026 年 4 月 27 日发了 Symphony 文章，团队在“无人手写代码”的工作流里继续撞墙——下一个瓶颈是 context switching：每个工程师每天能稳定推 5 到 10 个 PR，但代价是不断在 tmux pane 之间切换；同时管理 3 到 5 个 Codex session 就开始痛苦。

Symphony 的核心设计简单又狠：让 Linear 这类项目管理看板成为 coding agent 的 control plane——每个 open task 对应一个 agent workspace，agents 持续运行，人类 review 结果。

这一步的关键意义在于——
它把工作单位从 Codex session / PR，提升到了 ticket / deliverable。

OpenAI 文章给了一个数字：有些团队上 Symphony 三周后 landed PRs 增加了 500%。
但更深层的变化是——每个 change 的感知成本下降了。人不再亲自驱动实现，所以 speculative task 变得便宜：试一个想法、探索一个 refactor、测试一个假设，不行就丢掉。

这背后藏着一条更通用的道理：

当执行成本接近零，你最该投资的，是降低“想要尝试”的心理摩擦。
试错越便宜，洞察越多。
这是一切创造性工作的底层规律。

Ryan 在访谈里特别提了 Symphony 的 rework state 设计，很能体现 agent-first 思维：

• 如果 PR 不可 merge，就把 worktree 和 PR 整个丢掉，从头再来。
• 然后追问“它为什么是垃圾”——先修 prompt、skill 或 guardrail，再把 ticket 重新推入 progress。

这背后是一个非常不一样的成本观：
当代码便宜时，保留错误路径不一定值得。有时丢弃 + 补护栏 + 重跑，比 patch 更干净。

个人启示：
我以前对自己写过的烂草稿会舍不得删——觉得“反正花了时间”。
现在我开始接受：“写得不行，那就丢掉，并且去问‘为什么我能写出这种东西’。”
修流程比修产物更值钱。

模型 12：把 agent 放进一个有目标、有上下文、有工具的“世界”里

「Don’t put agents in a box. Give them context and tools.」
这是 Ryan 在访谈里和主持人对完话之后追加的一句关键限定。

这条模型综合了前面所有模型，是我打算放在桌面上的那条。

Ryan 自己经历了一个明显的演进：早期他们倾向于把 agent 放在预定义 scaffold 或状态机里；但 reasoning model 一旦变强，过度僵硬的 scaffold 反而会限制它。

他们后来“反转”了系统——
不是先搭一个环境再把 coding agent spawn 进去；而是让 Codex 本身成为入口，再通过 skill 和 script 给 Codex 启动 stack、设置环境变量、查询 observability 数据的能力。

但这不意味着没有边界。
边界在哪里？
边界变成了整个 harness：权限、工具、repo 结构、workflow policy、observability、CI、lint、skill、sandbox、human escalation——共同构成一个可操作的环境。

最后一条心智模型：

**失败的 agent workflow 通常掉在两个极端：
一种是把 agent 关进过窄的工具箱，期待它 magically 完成复杂任务；
另一种是给它完全开放的环境，但没有日志、测试、边界和 policy。

Ryan 的中间道路是清楚的：
不要 micromanage 每一步，但要严肃设计 agent 可见的世界。
给目标，也给观测；给自由，也给 invariant；给工具，也给反馈；给上下文，也给可机械执行的验收标准。**

我从这十二个模型里看见的一条主线

把这十二个模型放在一起看，能看见一条隐藏的主线。

它本质上是关于“判断力的可复用性”的。

工程师的判断一直存在。一个好的工程师，他的脑子里装着大量隐性知识：哪些写法看起来对但其实不行；什么场景下要小心；某个边界什么时候必须显式；某种命名约定背后的取舍；某个性能假设在生产中如何破灭。

过去这些判断都困在脑子里。
它们靠什么传承？
靠 review、靠口口相传、靠“被骂的疼痛感”、靠新人在事故里学到的教训。

这种传承是一次性的，而且高度依赖人际接触。

Ryan 这套 harness engineering 在做的事，就是把这种判断从“一次性”变成“可复用”。

• 把“我喜欢这种结构” → 变成 lint。
• 把“我们不要再写这种代码” → 变成 structural test。
• 把“这种依赖太重” → 变成 quality score 规则。
• 把“上线前一定要看这条 trace” → 变成 verification skill。
• 把“改这块前要先了解上下文” → 变成 docs 索引和 AGENTS.md 入口。
• 把“这种 PR 必须配视频” → 变成 review packet 模板。

每一条规则都是把一个工程师的判断提炼成系统的一段刻度。

判断被提炼之后，agent 就能在所有未来的相似场景中复用它。
复利就在这里发生。

这件事最深的含义是——
“工程师”这个身份的核心价值，从“执行判断”，转向了“沉淀判断”。

执行一次的判断只服务这一次。
被沉淀进系统的判断，会服务所有未来 agent runs。

这两种工作的长期杠杆率差异是指数级的。

写在最后：哪些是我打算这周就开始做的

每次读完这种“震撼级”的工程材料，我都会逼自己问一个问题——
接下来一周，我具体能做点什么？
不能落到一周内行动的“启发”，对我来说和没读过没差。

给自己列了一个最小行动清单，也分享给同样在用 Cursor / Codex / Claude Code 的你：

1. 本周内把现有的 AGENTS.md 砍到 100 行以内，剩下的拆到 docs/ 下结构化文件。
2. 每次我跟 AI 重复说同一件事超过两次——立刻停下，把它写成一条规则。
3. 本周提交的所有 PR——尝试附上一段证据（测试报告 / 截图 / 日志摘要），不要让自己或同事靠“看代码 + 信任”来 merge。
4. 挑一个我目前手动 babysit 的任务（每天都要跑一遍那种）——花两小时把它写成 skill / script / cron job，让 agent 自己拉活。
5. 每周末花 30 分钟做一次“知识 garbage collection”——把我和 agent 这一周的来回，重新提炼成 1 条新规则、1 篇 doc 修订、或 1 个 skill 改进。
6. 用一句话提醒自己：

   “我作为工程师的核心产出，是判断的可复用性，不是代码的行数。”

一个尾巴：关于“工具背后的人”

我喜欢 Ryan 这套观点的最后一个原因，是它没有走向“人类不重要”的悲观叙事。

他承认 hard and new 的问题仍然要人类驱动；他承认完全 agent-generated 系统的长期一致性还是未解；他承认这套打法依赖于他们仓库的具体结构和资源条件，不应该被假设能直接泛化到所有团队。

他真正在做的，是一件挺谦逊的事——
他在重新设计“工程师”这个职业，以便让人类的判断、品味、经验、风险感知，能够在 AI 极大放大执行力的时代，继续发挥作用，甚至发挥得更好。

我们这一代知识工作者，最大的恐慌不是工具变强，而是不知道工具变强之后，“我”还能站在哪里。
Ryan 给出了一个我愿意相信的回答——

你站在系统设计者的位置上。
你站在判断的沉淀者的位置上。
你站在让 agent 不需要 babysit 的那个人的位置上。

这听起来抽象。
但翻成具体的、给自己的提醒：

少敲键盘，多沉淀；
少救火，多设计护栏；
少在脑子里存隐性经验，多把它们写进 repo；
少要求自己跟上模型的速度，多让 agent 跟得上自己的标准。

如果让我用一句话总结这十二个心智模型——

AI 时代的工程师，不再是写最多代码的人，而是把自己的判断变成系统的人。

这句话我打算抄在 flomo 顶部，每天早上看一遍。

1

三月份阅读时间超出预期，原定目标350小时，实际达到367小时。还是那句话，自己开发的番茄冥想APP帮了大忙。

冥想目标没完成。原定目标32小时，实际只有15.2小时。目前来说，我还是没有太好的办法来改进。

接下来，我跟大家分享我一个月花一万块钱在AI工具上是一种什么样的体验。

2

今年开始，我平均每个月花在AI工具上的钱是一千多美金，也就是差不多一万块人民币。

其中，我会用200美金订阅一个最贵的ChatGPT会员，剩下的钱都是用来买Cursor的会员。

之所以花那么多钱在Cursor上，是因为我要在工作上用Claude Opus这个编程模型来写代码。一个账号200美金，基本上3到4个工作日就会被我用完。一个账号用完了，就充值一个新的账号。

用过最聪明的AI之后，我就不想用其他的AI。一项工作，最聪明的AI可以在10分钟内帮你完成，你只需要再多20分钟就能完成检查。工作完成之后，基本上没有什么遗留的问题。

稍微没那么聪明的AI，它就要花上30分钟才能干完，而且你还要花30分钟才能检查。这还没完，后面很可能会发现有遗留问题要你去处理。运气好的话，只需要2个小时就能补救；运气不好的话，可能需要整整一天，甚至更多的时间。

最强AI产生出来的效能，可以是一般AI的10倍，甚至是100倍、1000倍。

如果你的工作是可以用AI来辅助完成的，那就要大胆用，而且一定要用最聪明的AI。

3

有人说，我分不清AI的产出质量。在某些人看来，豆包和ChatGPT没什么区别。

这些人要么能力不行，对工作质量没有足够的判断能力；要么就是工作简单，就像杀鸡，用菜刀和牛刀没什么区别。

如果想让自己在AI时代的竞争中胜出，就要学会如何提升判断能力，并且要去做更复杂的工作，有区分度的工作。

我的工作是程序员，我就一定要用最强的AI才行。如果哪一天，我觉得我判断不出最强AI生成的代码和一般AI生成的代码有什么区别，那我就要有危机意识，赶紧提升自己的判断能力。

如果哪一天，我发现自己的工作内容，用最强AI帮我做，和用一般AI做没什么区别，我也要有危机意识，去争取更有挑战性的工作。

4

AI是工具，是用来放大人与人之间的差距的。这一幕，在之前多次上演。

有了印刷术，普通作家和顶尖作家的收入差距，放大了100倍。

有了电视，普通运动员和顶尖运动员的收入差距，放大了1000倍。

有了互联网，普通销售员和顶尖销售员的收入差距，放大了10000倍。

在我看来，你用AI的有效次数越多，有效消耗的token数越多，你的能力放大倍数就越大，收入也自然会随之放大。

我的直觉告诉我，要多用AI，直到量变导致质变。

5

总结今天的分享就三句话——

一，AI很厉害。最聪明的AI要比一般的AI聪明很多倍。

二，一定要用聪明的AI。如果你用不上，要么提升能力，要么换个工作。

三，AI放大人与人之间的差距。你用AI越多，消耗的token数越多，你就越有可能在竞争中胜出。

截至2026年3月31日，我一共阅读了20105.5小时。预计会在2029年11月15日，完成第三个10000小时，也就是总共30000小时的阅读目标。

四月份的阅读目标是640个番茄时间，也就是320个小时。冥想目标是30小时。

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

一个被很多人看错了的转变

2026 年 2 月，Peter Steinberger 宣布加入 OpenAI，他一手做起来的 OpenClaw 转入基金会，继续保持开放和独立。Reuters 的报道里用的词是「从一个开源 bot 变成了广受关注的个人 agent 项目」。

大多数人关注的是这条新闻本身——谁去了哪家公司，哪个项目归了谁。但我想告诉你，这些都不是这件事最有价值的部分。

真正值得学习的，是 Peter 给出的一个判断。他说：AI coding 改变的不是程序员写代码的速度，而是整个软件生产系统的结构。

这句话听起来平平无奇。但如果你慢慢咀嚼，会发现里面藏着三层含义。而这三层含义合起来，足以让我们重新思考一件事：当 AI 可以写代码了，一个程序员到底还应该训练什么。

我把我在这件事上的学习和思考，系统整理成这篇文章。不是给你一个 prompt 模板，不是给你一个工具推荐，而是给你一个框架——当软件生产从手工艺过渡到系统编排，什么能力正在升值，什么能力正在贬值。

第一层：瓶颈从“构建”变成了“同步”

先说一个容易被忽略的事实。

Peter 在 TED 2026 的表达里有一句关键话：软件里大量无聊、重复、费力的部分，AI 已经可以承担；真正的瓶颈开始从“构建”转向“同步”。他还把 OpenClaw 描述为一种个人 AI 的操作系统，而不是一个单独的应用。

大多数人对这句话的第一反应是：哦，AI 写代码更快了。

这是一个很粗糙的理解。它的真正含义是——构建这件事的单位成本在快速下降，而同步这件事的单位成本正在快速上升。

什么叫同步？你可以这么想。一个任务从被提出，到真正上线，中间要经历若干种“对齐”。需求要和实现对齐，实现要和测试对齐，测试要和设计对齐，设计要和风险对齐，风险要和上线动作对齐。如果只有一个人、一个模型、一个任务，这些对齐都是隐性的，你脑子里自动完成。但当多个 agent、多个上下文、多个分支同时工作，任何两个地方一旦不同步，整个系统就开始返工。

经济学里有一个词叫科斯的交易成本。我们可以借用一下。AI 让“构建”这部分的交易成本掉到了接近零，这就意味着瓶颈必然转移到新的地方——那个地方就是“同步”。这是一个规律，不是巧合。

所以，如果你发现你的 AI workflow 总是返工，多半不是模型不够强，而是同步机制太差。 这是我从 Peter 这句话里学到的第一层东西。

第二层：spec 不是说明书，而是控制面板

同步的起点是什么？是 spec。

在手工时代，我们对文档有一种矛盾的态度。写少了怕漏，写多了怕没人看，到最后大家心照不宣——文档主要是写给人看的说明书。

Peter 的实践让我意识到，在 AI coding 时代，requirements、design、implementation doc 的角色变了。它们不再是说明书，而是 agent 的控制面板。

这是一个很大的心智切换。你可以这么想：过去文档是被动的，agent 时代文档是主动的。过去文档的使命是“解释清楚”，agent 时代文档的使命是“约束得准”。

什么叫约束得准？就是告诉 agent 哪里可以发挥，哪里必须保守；哪里可以重构，哪里只能局部修复；哪些测试必须先写，哪些行为必须保持兼容；哪些风险必须在动手前说清楚。

这里有一个反常识的点。很多人以为 AI 写代码的主要问题是“写不出来”，其实恰恰相反，AI 最常见的问题是“长太多”。 你让它改一个函数，它顺手把整个模块重写了；你让它修一个 bug，它顺便把你的架构升级了。人类 review 的价值之一，是做减法——把 AI 长出来的多余部分砍回去。

而真正好的 spec，本质上是在 agent 动手之前就帮它做这件减法。spec 不是“写得多”，而是“约束得准”。 它的价值不在于覆盖每个细节，而在于界定可变区和禁区。

第三层：真正的效率是“收敛速度”，不是“响应速度”

讲完 spec，我们讲效率。

Peter 在《Shipping at Inference-Speed》里比较过 Codex 和 Opus。他的结论很有意思——有些模型会先花很久读代码，表面上更慢，但更可能修对；有些模型更快、更积极，但在大改动时可能漏上下文，导致后续不断“修修补补”。

这句话值得被反复读。

因为它背后藏着一个指标的切换。我们习惯用“响应时间”来衡量 AI 的效率——它多久给出第一版回答。但 Peter 告诉我们，这个指标在 agent 时代是有误导性的。

真正决定工程效率的，不是第一轮有多快，而是从任务被提出到可以放心 merge，一共走了多少轮。

我把它叫做收敛时间。收敛时间由几个指标共同决定：首次通过率、返工轮数、误改范围、为了兜底花掉的人工脑力。如果一个 agent 第一轮写得飞快，但引入了一堆隐性问题，它其实并不高效。如果另一个 agent 先慢慢读代码、先问问题、先写 plan，最后一次性通过更多测试，它反而可能更快。

这里有一个很容易被忽略的副作用：你对“快”的感受是错的。 人在体验上会把“第一回合的响应快”误认为“整件事完成得快”，就像你在餐厅总觉得上菜快的那家比较好，但最后算下来，吃完付账的时间未必更短。

所以，在评估 AI coding workflow 的时候，不要看它几秒钟给出回答，要看它几轮之内到达可 merge 状态。

第四层：你不是 programmer，你是 orchestrator

讲完了 spec 和效率，我们讲身份。

Peter 的另一个判断，我觉得更值得细品。他说 OpenClaw 的使用者并不只是工程师，还包括创业者和没有正式编程背景的人。他把这些人统称为 builders，并强调真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

我们得把这句话翻译一下。

表面上，它在说 AI 降低了编程门槛。但它真正的含义是：“会不会写代码”正在变成一个低层问题；更高层的问题是你能不能把一个模糊愿望压成一个可被执行的系统。

你可以这么想。过去程序员的核心能力有三件套：理解需求、设计结构、写出代码。其中“写出代码”是最显眼的一件，也是最花时间的一件。现在 AI 把这一件的边际成本压到了接近零。结果不是前两件也跟着贬值，而是前两件变得相对更值钱了。

更准确地说，前两件之外还多出了两件：组织上下文和验证结果。

• 组织上下文：把目标、边界、约束、已有代码、接口形状、测试预期，一起打包成一份让 agent 不会跑偏的输入。
• 验证结果：当 agent 产出一坨东西后，判断它是否真的满足 contract，是否破坏了现有行为，是否覆盖了关键路径。

把这些合起来，你的身份就变了。你不再是 programmer（程序员），你是 orchestrator（编排者）。programmer 的价值曲线会越来越平，orchestrator 的价值曲线会越来越陡。

Peter 在 TechCrunch 的采访里特别强调，他一开始也没有完整计划，很多东西是在探索中长出来的。他建议 builder 更 playful，允许自己通过一次次失败慢慢变强。这是一个很重要的提示——orchestrator 不是天生的，是练出来的。 它更像一门乐器，不是一句咒语。

第五层：带 agent 本质上是一门管理学

orchestrator 这个身份带来一个隐藏的变化。你从一个执行者，变成了一个管理者。

这件事对程序员心理冲击很大。因为大部分程序员选择这份工作，本来就是因为喜欢自己动手、不喜欢被别人打扰、讨厌开会。但 agent 时代让你没法逃了——你带的不是人，是 agent，但原理一模一样。

带 agent 的第一个心智升级，是放弃“必须按我的方式写”。

你看一个人类同事的代码，哪怕风格和你不一样，只要结果是对的、可维护的、能通过测试的，你就应该接受。你不能要求每一行都长得像你自己。这个道理在 agent 时代更加适用——因为一个 agent 每天能产出的代码量远超任何人类同事。如果你坚持让它“写得像你”，你会把大把时间浪费在审美上，而不是花在真正有风险的工程决策上。

更合理的标准是：这段代码是否满足 contract？有没有破坏现有行为？测试是否覆盖了关键路径？上线后是否可观测？出问题能不能快速回滚？

如果这些问题都过关，它不一定要长得像你亲手写的代码。这不是降低标准，这是改变标准。 手工时代的标准是“代码是否符合我的手感”，agent 时代的标准是“系统是否可控地收敛”。

你看，到了这一层，AI coding 已经不只是一个技术问题，它是一个管理学问题了。

第六层：安全是产品的一部分，不是补丁

讲到管理，就不得不讲边界。

Peter 加入 OpenAI 的那篇博客里有一句话值得记住：他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。

这句话表面看是套话，其实不是。它在说明一件事——当 agent 真的能替人做事，安全就不再是附属问题，而是产品本身的一部分。

Reuters 在报道 OpenClaw 流行的时候也同步提到，错误配置可能导致网络攻击和数据泄露风险。这不是危言耸听。agent 和 chatbot 最大的区别就是——chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是你的账号、你的权限、你的系统。

这意味着，以后凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

具体是哪些？最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。这些不应该是“高级选项”，它们应该是默认设施。

反过来讲，真正能长期落地的 agent，不是能力最强的 agent，而是行为可审计、权限可限制、错误可止血、影响范围可控制的 agent。 这是工程意义上的常识，但在 AI 狂热期很容易被忽略。

第七层：失败归因给系统，而不是归因给人格

讲完了外部安全，讲一讲内部心态。

如果你真的按 Peter 的方式开始做 AI coding，你会撞上一件让人泄气的事——它会失败，而且频繁失败。模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控，每一条都会让你短暂地怀疑自己。

这里有一个归因的陷阱。失败发生的时候，最快的反应是把它解释成“我不行”或者“模型不行”。这两种解释都便宜，但都不准确。

更工程化的解释是：我的 harness 还不够好，任务边界不够清楚，验证机制不够强，同步流程还有洞。

这种归因方式有两个好处。第一，它把问题从情绪层面拉回了系统层面。你不再是被自我怀疑拖住，而是被一个明确的改进方向牵引。第二，它把每一次失败转化成了系统的提升。下一次任务，你的 kickoff 模板会更准，你的测试会更早介入，你的 rollback 会更显式。

这其实就是 Peter 的那句 playful 背后的东西。play 的意思不是随便玩，而是允许失败，但让每次失败都转化成系统的增量。

这是一个非常 professional 的心态。

第八层：把你学到的东西压成一套 kickoff 模板

前面讲了七层。你可能会问，这些东西具体怎么用？

我给自己整理了一套 kickoff 模板，核心思想只有六个字——先同步，再生成。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板背后的逻辑，就是把前面七层讲的东西全都物化。第一层讲同步，所以模板先要边界；第二层讲 spec，所以模板有执行要求；第三层讲效率，所以模板要求一次性把验证标准讲清楚，减少返工；第四层讲身份，所以模板的核心是“让 agent 知道自己该做什么、不该做什么”；第五层讲管理，所以输出格式强调结论、变更、风险；第六层讲安全，所以执行要求里留了二次确认和 rollback 的位置；第七层讲归因，所以整个模板的目的是让失败有迹可循、有地方归因。

你看，它不是一个漂亮的表格，它是一套被压缩过的方法论。

结语：软件生产正在从手工艺变成系统编排

讲了这么多层，最后我想把它压成一句话。

软件生产正在从手工艺，变成系统编排。

在旧范式里，程序员的核心能力是亲手把代码写出来。在新范式里，越来越重要的能力是——定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

这是一次真正的身份迁移。它不只是一次工具升级，它改变了一个程序员要训练的肌肉。从手速肌肉，变成结构肌肉；从实现肌肉，变成验证肌肉；从独奏肌肉，变成指挥肌肉。

Peter Steinberger 的启发可以压缩成一句话：

未来最有价值的人，不是单纯写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这句话，值得你抄下来，贴在显示器边上。

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

大多数人搞错了

大多数人以为 AI 让程序员变快了。

这是错的。

Peter Steinberger 说得很清楚：瓶颈从构建变成了同步。

这是两件事。构建便宜了，同步就贵了。贵的那头，才是你该去的地方。

我花了一段时间才真的理解这句话。一旦理解了，很多事情开始变得显而易见。这篇文章就是这些“显而易见的事”。

构建便宜了

写代码曾经很贵。

不是因为键盘贵，是因为把一个想法翻译成能跑的代码，消耗脑力。现在一个好的 agent 可以十分钟替你做完。

这件事的意义不是“省了十分钟”。意义是——这十分钟里的知识，不再是你的护城河。

你可能已经感觉到了。那种“我会用这个框架”的骄傲，正在变薄。那种“我能一口气写出一个 CRUD”的自信，也开始不太值钱。这不是因为你退步了。是因为这件事本身贬值了。

承认这件事并不丢人。丢人的是不承认。

同步变贵了

把构建想象成发电厂。

过去你自己发电，自己用。现在有了便宜到可以随便开的电，你突然发现真正的问题是电网——电怎么送到对的地方，怎么不过载，怎么不着火。

这就是同步。

需求和实现要同步。实现和测试要同步。测试和设计要同步。几个 agent 的分支之间要同步。生产环境和假设要同步。

一旦有一个地方不同步，整件事开始返工。

过去这些同步成本被藏在你自己的脑袋里。现在你的脑袋不再直接参与每一行代码，它们就暴露了出来。很多人把这种暴露误认为“AI 不好用”。其实不是 AI 不好用，是同步成本一直在那里，只是你以前没看见。

如果你的 AI workflow 总是返工，多半不是模型不够强，是同步机制太差。

Spec 是控制面板

我们对 spec 一直有一种奇怪的态度。

我们觉得 spec 是写给别人看的说明书。能省就省。能糊弄就糊弄。真正重要的东西存在写代码的人脑子里。

在手工时代这种态度是有效的，因为确实有一个人的脑子装着这些东西。

在 agent 时代，这种态度是灾难性的。

因为 agent 的脑袋里什么都没有。它只有你写下来的东西。

所以 spec 不再是说明书。它是 agent 的控制面板。

好的 spec 不是写得多，是约束得准。它要告诉 agent：

哪里可以动，哪里不能动。
哪里可以重写，哪里只能修补。
哪些测试必须先写，哪些行为必须兼容。
哪些风险必须在动手前说清楚。

spec 的真正作用，是让 agent 不要乱长。

你会惊讶地发现，一个 agent 最大的危险不是它做不到，而是它做得太多。你让它改一个函数，它重写了一个模块。你让它修一个 bug，它升级了你的架构。这件事不是 agent 的错，是你没给它画好边界。

Spec 就是边界。

速度是陷阱

我们都想要快。所以我们喜欢那些上来就开始写代码的 agent。

这是一个陷阱。

Peter 比较过 Codex 和 Opus。他说有些模型会先花很久读代码，看起来慢；有些模型一上来就写，看起来快。但后者在大改动时经常漏上下文，最后不得不一直打补丁。

表面上的快，是未来的慢。

你真正要看的，不是第一轮有多快。是从任务被提出，到能放心 merge，一共走了多少轮。

我给它起了个名字：收敛时间。

收敛时间由几个东西决定——首次通过率、返工轮数、误改范围、你兜底花掉的脑力。

一个 agent 第一轮写得飞快，但引入了一堆问题，它并不快。一个 agent 慢慢读代码、先出 plan、先写测试，但一次通过，它反而是真的快。

响应时间是幻觉。收敛时间才是真的。

你要优化的单位，从 response time 换成 convergence time。

这件事一换，很多选择就反过来了。

你已经不是 programmer 了

Peter 用了一个词：builders。

他说 OpenClaw 的用户不只是工程师，也包括没有编程背景的创业者。真正的变化不是技术本身，是 access——更多人第一次有了把想法推进成现实的能力。

翻译一下：

“会不会写代码”正在变成一个低层问题。高层问题是：你有没有一个真的问题，你能不能定义目标，你能不能判断结果。

这意味着你要重新定义自己。

你不是 programmer。你是 orchestrator。

programmer 的价值曲线会越来越平。orchestrator 的价值曲线会越来越陡。

programmer 花时间把代码写出来。orchestrator 花时间让一整个系统稳定地产出结果。前者的护城河在变薄，后者的护城河在变厚。

如果你把自己定义成“会写 Java 的工程师”，你的价值会被 AI 慢慢压低。

如果你把自己定义成“能把问题组织成可被智能系统解决的人”，你的价值会被 AI 放大。

两个定义，结局完全不同。这不是抽象的哲学问题，这是一个非常具体的职业选择。

带 agent 像带团队

从 programmer 到 orchestrator，最难的部分是心理的。

你从一个执行者变成了一个管理者。

大多数程序员选择这份工作，本来就是因为讨厌当管理者。但在 agent 时代你没法逃——你带的不是人，是 agent，但道理一样。

第一件要放下的事：“它必须按我的方式写代码”。

一个人类同事的代码，如果风格和你不一样但跑得起来、通过了测试、可维护，你会接受。agent 的代码也应该用同样的标准。

不然你会把所有时间花在审美上，而不是花在风险上。

更合理的评判标准是这些问题：

• 这段代码是否满足 contract？
• 有没有破坏现有行为？
• 测试是否覆盖了关键路径？
• 上线后是否可观测？
• 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像你写的。这不是降低标准，这是切换标准。

手工时代的标准是“代码是否符合我的手感”。

agent 时代的标准是“系统是否可控地收敛”。

这是两个完全不同的事。

安全是产品，不是补丁

有一件事很多人不愿意想，所以我直接说。

agent 和 chatbot 的区别是，chatbot 只是说话，agent 会动手。它动手的时候，代表的是你的账号、你的权限、你的生产环境。

这意味着，安全不再是附属问题。安全就是产品。

Peter 在加入 OpenAI 的博客里说，让普通人用 agent 需要更多关于安全的思考。Reuters 报道过 OpenClaw 带来的安全担忧——错误配置可能导致网络攻击和数据泄露。

以后凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

最小权限。
Dry-run。
二次确认。
敏感信息隔离。
Diff trace。
Rollback。
Kill switch。

这些不是高级选项。这些是默认设施。

真正能落地的 agent，不是能力最强的 agent，而是可审计、可限制、可止血、可控制影响范围的 agent。

能力最强的 agent 在兴奋期最受欢迎。但长期活下去的，只有安全边界最完整的那一类。

失败归因给系统

你真的开始用 AI coding，你会失败。

很多次。

模型跑偏。上下文没读全。方案过度设计。测试没覆盖。改动范围失控。

每一次都让你想：是不是我不行。

停。

不是你不行。也不是模型不行。

是你的系统不行。

具体来说：

harness 不够好。
任务边界不够清楚。
验证机制不够强。
同步流程有洞。

这种归因方式的价值在于，它是工程化的。它给你下一步该改什么，而不是给你一通情绪。

每一次失败都应该变成系统的一次升级。kickoff 模板更准了。测试介入更早了。rollback 更显式了。上下文收集的顺序更合理了。

Peter 说建议 builder 更 playful，允许自己慢慢变强。play 不是随便玩。play 是允许失败，但让每次失败都换来系统的一个增量。

这个心态本身，就是一种工程技能。

一个模板

把上面这些东西压成一个你今天就能用的 kickoff 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板的核心思想只有六个字。

先同步，再生成。

不要把 agent 当一个马上开写的实习生。把它放进一个有目标、有边界、有验证、有回滚的系统里。

编排

很多年以后，人们会回头看 2026 年，说那是软件生产的一次底层翻转。

翻转的那一刻看起来很安静。没有爆炸，没有裁员公告，没有戏剧性的新闻。只是有一群人突然意识到，自己训练的肌肉不再是以前那组了。

在旧范式里，程序员的价值来自亲手把代码写出来。

在新范式里，程序员的价值来自于定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

前者叫手艺。

后者叫编排。

手艺依然有价值。但编排的价值曲线更陡。如果你想做一件长期回报递增的事，选编排。

Peter Steinberger 的启发，压缩成一句话就是——

未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这句话值得你今天就开始相信。

因为未来的竞争不在谁打字快。

而在于谁能让一整个智能系统围着他的问题稳定转起来。

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

一个一开始让我焦虑、后来让我着迷的问题

最近几个月我一直在反复想一个问题：当 AI 已经可以写代码了，程序员到底还剩什么？

这个问题一开始让我焦虑。因为我心里有一个很朴素的自我定义——我是一个会写代码的人。这个身份过去十几年里为我提供了稳定感。它是我的手艺，是我靠它养活自己的方式，也是我在面对世界时的一种底气。当这个东西的边际成本被模型一口气压到接近零，我下意识地有一种“空”的感觉。

后来我开始反向想这件事。如果只是焦虑，那就只是情绪；而情绪对我来说是信息，它指向某个我还没想清楚的问题。如果这件事真的让我不安，说明我对“程序员”的定义里，混入了一些在新范式下正在贬值的东西；而这恰好是一次把它们拆开、看清楚、再重新组装的机会。

真正帮我从情绪里捞出来的，是 Peter Steinberger 的一句话——瓶颈正在从 building 转向 syncing。我花了好几天时间反复咀嚼它，才慢慢意识到，这句话的价值不是给了我一个答案，而是重新定义了问题本身。

这篇文章就是我把这个定义重写一遍的过程。

一次重要的拆解：building 与 syncing 不是一件事

我发现，很多时候我们对一件事的焦虑，来自于我们把两件不同的事当成了一件。程序员的工作就是一个典型。

我过去习惯把“写软件”当成一个整体：从脑子里有一个想法，到代码上线运行。但 Peter 的那句话迫使我把它拆开。拆开之后你会看到两件本质非常不同的事。

一件是 building。 这是从“我知道要做什么”到“代码存在”的转化过程。写函数、写接口、补测试、连数据库，都属于这一层。这一层的特点是它是重复性的、机械的、可模式化的。也正因为可模式化，它是最容易被模型替代的。

另一件是 syncing。 这是让多个“版本的真实”保持一致的过程：需求和实现是否同步，测试和设计是否同步，实现和风险是否同步，多个 agent 的修改之间是否同步，当前代码和历史假设是否同步。这一层的特点是它不是重复性的，而是持续性的；它不产出代码，但它决定了代码有没有意义。

把这两层区分开之后，一个关键的观察冒了出来——过去我以为自己是在 building，其实我很多时间在 syncing，只是我没有意识到。 我读代码、我在脑子里对齐各种不一致、我修补文档里没写但实际存在的约束，这些都是 syncing。

这就是为什么当 building 的成本被压低之后，我反而更忙了。因为原来被埋在 building 里的 syncing 成本，现在暴露了出来，而且它没法被模型替代——至少不是线性替代。

所以我真正的问题不是“AI 抢走了我的工作”，而是“我过去对自己做的事的理解太粗糙”。一旦把工作拆成 building 和 syncing 两层，焦虑就变成了方向：我要训练的是 syncing 层的能力。

文档作为“外化的认知”：spec 是控制面板

想清楚这件事之后，我对“文档”这件事的理解也变了。

过去我把 requirements、design doc、implementation plan 当成“给人看的说明书”。这种理解有一个隐藏的假设——读这份文档的是一个有背景知识、有常识、会察言观色的人。于是我写文档的时候是偷懒的，我可以省略很多东西，因为“反正读的人自己会脑补”。

但在 agent 时代，这个假设不成立了。agent 没有我的背景知识，没有我脑子里那些没写出来的默认约束，没有“我在心里反复告诉自己不要碰的那块代码”。它只有我写下来的东西。

这逼我重新理解 spec。spec 不是说明书，spec 是我自己认知的外化。 它是我把脑子里那些隐性的默契，变成可以被一个外部系统遵守的显式约束。

这个切换一旦发生，你写 spec 的方式就变了。

过去写 spec，我关注的是“我有没有把事情讲清楚”；现在写 spec，我关注的是“我有没有把边界画清楚”。好的 spec 不是在描述事实，而是在划定可变区和禁区。

它要告诉 agent：

• 哪些地方欢迎你长出新东西，哪些地方必须保持原样；
• 哪些行为必须保持兼容，哪些接口可以动但必须迁移；
• 哪些测试必须先写，哪些 API 不能被重命名；
• 哪些风险必须在动手前说清楚，哪些动作必须等到人类确认。

一旦你开始这样写 spec，你会突然意识到一件事——写 spec 不是在服务 agent，是在服务自己。 它强迫你把脑子里那些“只可意会不可言传”的工程直觉，一项一项显式地翻出来。这个过程本身就是一种极好的思维训练。

你甚至会在写 spec 的时候发现，自己一直以为自己想清楚的事情，其实从来没有想清楚。这和刚开始学 TDD 的时候一样——测试不是写给别人看的，测试是在逼你直面自己知识里的空白区。

一个反直觉的观察：你以为的“快”，很多时候是在制造未来的“慢”

接下来我想谈的一件事，是关于效率的认知错觉。

Peter 在比较 Codex 和 Opus 的时候讲过一件很有意思的事：有些模型会先花很久读代码，表面上更慢；有些模型更快更积极，但在大改动时常常漏上下文，后面得不断“修修补补”。

这个观察之所以重要，是因为它揭示了一个很普遍的认知偏差——我们会把“第一次响应快”误认为“整件事做完得快”。

这是一种非常典型的“系统一”的偏差，它来自我们对“快”的直觉更新得太快。你在餐厅会因为上菜快而觉得这家店高效，即使结账总时间并没有缩短；你在沟通时会因为对方回复得快而觉得他效率高，即使他因此给你留下了更多返工。

在 AI coding 里，这个偏差会带来一个很具体的后果：你会系统性地偏爱那些第一轮就开始写代码的 agent，哪怕它们最终并没有更快地到达可 merge 状态。

所以我必须切换一个度量单位。我不再看“它多久给出第一版”，我改成看几个更冷的指标：

• 首次通过率：第一次交付能通过多少测试、lint、build、smoke；
• 返工轮数：从 kickoff 到可 merge，人和 agent 一共来回多少次；
• 误改范围：它有没有动了不该动的地方；
• 收敛时间：从任务被提出到可以放心合并，全局花了多少时间；
• 兜底脑力：我为了让它“不出事”，私下花了多少精神力。

这一组指标合起来，我称之为收敛时间。它才是 AI coding 真正的效率单位。响应时间只是它的一个很小的子集。

一旦你开始看收敛时间而不是响应时间，你对很多事情的判断都会反转。那些“慢吞吞先读代码、先问问题、先出 plan”的模型或流程，看起来像是在浪费时间，实际上是在用前期的同步成本换取后期的返工减免。这是一个非常经典的投资式思维——前期多付出一点理解成本，后期省下十倍的修补成本。

从这个角度讲，AI coding 的效率，不是一种速度问题，是一种利率问题。你愿意用多少前期时间，换取多少后期的稳定。

身份的重新定义：从 programmer 到 orchestrator

讲到这里，我不得不面对那个一开始让我焦虑的问题——如果最容易被 AI 取代的是 building，那“程序员”这个身份还剩什么？

Peter 给了我一个词：builders。他说 OpenClaw 的使用者并不只是工程师，还包括创业者和没有正式编程背景的人。真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

这句话有两层含义。浅的那层是：“不会写代码也能做软件了”。深的那层是——“会写代码”正在从一个门槛变成一个底层技能，它本身不再是核心竞争力。

换句话说，程序员曾经享有的那道护城河正在快速塌方。但这不意味着程序员的价值在消失，而是价值的分布发生了变化。过去价值集中在“我能写”，现在价值集中在“我能让系统稳定地写”。

我对自己的定义也因此要重写。我不再是 programmer（程序员），我是 orchestrator（编排者）。orchestrator 的工作至少包括六件事：

1. 把一个模糊的愿望压成一个可被执行的系统；
2. 为 agent 组织出它不会跑偏的上下文；
3. 定义目标、边界和不可触碰的部分；
4. 分配执行节奏和验证时机；
5. 识别 agent 产出的语义风险；
6. 把每次失败沉淀进一个越用越顺的流程。

这六件事里没有一件是靠“手速”解决的，全部都是靠“判断”。而判断这件事，是一种很难被模型短期替代的能力，因为它依赖的是长时间的经验内化和对具体情境的敏感。

所以真正让我松口气的，不是“AI 还取代不了我”，而是**“我要训练的东西从外化变成了内化”**。外化的东西（代码本身）被商品化了，内化的东西（判断、组织、边界感）反而升值了。

带 agent，本质上是带一个从不疲倦的团队

做 orchestrator，还有一个隐性的心理转变——你从一个执行者，变成了一个管理者。

很多程序员最初会抗拒这个转变，我一开始也是。因为我们选择这份工作，本来就是因为喜欢自己动手、讨厌开会、不喜欢在代码里嗅到别人留下的味道。但在 agent 时代你跑不掉——你带的不是人，是 agent，但原理几乎一样。

带 agent 的第一课，和带人一样，是放弃“必须按我的方式写”。

一个人类同事的代码，如果风格和你不一样但结果是对的、可维护的、能通过测试的，你通常会接受。但同样的代码如果是 agent 写的，人很容易就掉进一种“我为什么不自己写”的情绪里。这种情绪是有腐蚀性的——它会让你把大量时间浪费在审美上，而把真正需要判断的地方（契约、行为兼容、关键路径、回滚、可观测性）反而忽略掉。

所以我强迫自己切换标准。我不再用“像不像我写的”评价代码，而用“契约有没有被满足”评价代码。

具体是几个问题：

• 这段代码是否满足它声明的 contract？
• 有没有破坏现有行为？
• 测试是否覆盖了关键路径？
• 上线后是否可观测？
• 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像我写的。这不是在降低标准，而是在切换标准——从“手感标准”切换到“收敛标准”。

一旦你真正做出这个切换，你会发现你的产出结构也变了。你不再是一个独奏者，你是一个指挥者。 独奏者关心每一个音符的细节，指挥者关心整首曲子的结构。这是两个完全不同的能力维度。

安全不是补丁，是 agent 的产品形态本身

管理学讲完了，还有一个我必须正视的问题：安全。

Peter 加入 OpenAI 的那篇博客里说过，他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。Reuters 在报道 OpenClaw 的流行时，也特别提到错误配置可能导致网络攻击和数据泄露风险。

这两件事指向同一个结论——agent 和 chatbot 最本质的区别是，chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是你的账号、你的权限、你的生产环境。

这意味着在 AI coding 的语境下，安全不能再被理解成“事后补一层”。它必须被写进 agent 的产品形态。凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语。

具体就是——最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。这些不应该是“高级选项”，它们应该是默认设施。

我更倾向于把这件事反过来表述——一个 agent 真正值得长期托付的标准，不是它能力多强，而是它行为可审计、权限可限制、错误可止血、影响范围可控制。能力强的 agent 在兴奋期最受追捧，但能长期活下去的，一定是被写进了安全边界的那一类。

把失败归因给系统，而不是归因给人格

最后我想谈一个最容易被忽略、但对长期成长最重要的事：归因。

你真的开始用 AI coding，你会撞到一堆让人挫败的瞬间——模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控。每一次都会让你心里升起一种“我是不是不行”的质疑。

这种质疑是很正常的，但如果不处理，它会慢慢把你推到一种防御性姿态里——要么怪自己，要么怪模型。

这两种解释都便宜，但都不准确。

更工程化的解释是：我的 harness 还不够好，任务边界还不够清楚，验证机制还不够强，同步流程还有洞。

这个归因方式之所以重要，是因为它的对象是系统，不是人格。当你把问题归到系统上，你下一步就知道要改什么——改 kickoff 模板，改测试优先级，改 rollback 机制，改上下文收集的顺序。失败就不再是一个让你自我怀疑的事件，而是一个让你系统持续升级的输入。

这才是真正的 playful 心态。不是随便玩，是允许失败、但让每一次失败都转化成系统的一次小增量。

我把这些压成一套 kickoff 模板

讲了这么多，我最后把它压成一套我每次任务都会用的 kickoff 模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这个模板最核心的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。

写在最后：从手艺人到编排者

我开头说这件事让我焦虑。走到这里，我发现焦虑已经被重构成了方向。

过去我定义自己是一个“会写代码的人”，这个定义在新范式里会越来越薄。新的定义对我更友好，也更有意思——我是一个能把问题组织成可被智能系统解决的人。

这个定义的好处是，它不依赖任何一个具体的模型、任何一个具体的工具、任何一个具体的流行语。它依赖的是我对问题的判断力、对边界的敏感度、对系统的设计感。

这些东西不会被下一代模型废掉。它们反而会因为模型更强而更显得稀缺。

Peter Steinberger 最重要的启发，对我来说不是他提供的某个工具，而是一个非常朴素的心智切换——

软件生产正在从手工艺变成系统编排。未来最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

这件事值得我重新练。

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

一、一次小型的范式迁移

2026 年 2 月，Peter Steinberger 宣布加入 OpenAI。他做的 OpenClaw 转入基金会，继续保持开放和独立。Reuters 报道这件事的时候，用的一句话是——OpenClaw 已经从一个开源 bot 变成了广受关注的个人 agent 项目。

如果只是从人事新闻的角度去看，这件事并不特别。在技术圈里，个人项目被大公司收编、作者加入平台公司的例子每年都有。但如果把它放在一个更长的时间尺度上去看，它其实是一次小型的范式迁移的缩影。

过去三十年的软件史，大致可以分成三个阶段。

第一个阶段是手工作坊阶段。一个人、一台电脑、一份源代码。软件的价值几乎全部来自个体手艺。第二个阶段是工业化流水线阶段。版本管理、持续集成、自动化测试、云服务，把手艺人的劳动标准化、分工化、规模化。而现在我们正在进入第三个阶段——智能编排阶段。在这一阶段，代码不再主要由人写，而是由多个智能体在人的指挥下产出，人的角色从“生产者”变成“调度者”和“裁判”。

Peter Steinberger 加入 OpenAI 之所以值得记录，不是因为它改变了一个人的职业轨迹，而是因为它恰好落在这次范式迁移的节点上。他在 TED 2026 的表达里说过一句很关键的话——软件里大量无聊、重复、费力的部分，AI 已经可以承担；真正的瓶颈开始从“构建”转向“同步”。他还把 OpenClaw 描述为一种个人 AI 的操作系统，而不是一个单独的应用。

这句话如果放在 1995 年会很超前，放在 2015 年会很激进，放在 2026 年，只是一个工程师对时代的冷静陈述。

这篇文章要做的事情，就是把 Peter 的这个判断，放回到它所属的历史脉络里，然后拆成几个可操作的层面，供我们自己在日常工作中使用。

二、从“构建”到“同步”——瓶颈的转移

任何一个长周期产业的发展，总是在不断经历瓶颈的转移。

汽车工业刚起步的时候，瓶颈是怎么造出一辆可靠的车，那一代的英雄是福特。等到造车这件事本身被流水线解决之后，瓶颈转移到了怎么把车高效地送到消费者手里，于是出现了现代意义上的经销商网络和市场体系。再到后来，瓶颈又转移到了怎么让车持续产生数据、服务、金融价值，于是有了今天的智能汽车。

软件产业的演化路径和这个非常像。

在手工作坊阶段，软件的瓶颈是“能不能写出来”。会写代码本身就是一种稀缺能力。那一代的英雄，是那些一个人做出令人惊叹产品的独立开发者。

在工业化流水线阶段，瓶颈变成“能不能稳定地发出来”。这催生了 CI/CD、SRE、平台工程这一整套工程文化。那一代的英雄，是那些让一千个工程师的协同变得有秩序的人。

而到了智能编排阶段，Peter 告诉我们，瓶颈再一次转移了，这次是从“构建”转到了“同步”。

要理解这件事，我们得先做一个区分。“构建”是把一个想法翻译成能跑的代码的过程；“同步”是让多方面的真实保持一致的过程——需求和实现要一致，测试和设计要一致，多个 agent 的修改要一致，生产环境和假设要一致。

在手工阶段，这两件事的成本都压在一个人的脑子里。在工业化阶段，构建被流程化了一部分，但同步主要靠文档和会议。而到了智能编排阶段，构建的成本被模型迅速压低，同步的成本反而第一次以清晰的形式暴露出来。

这就是为什么很多人在使用 AI coding 时，会感到一种奇怪的疲惫——不是写代码更累了，而是对齐这件事在他们身上变得更重了。这不是 AI 的问题，这是瓶颈迁移之后，重力场的位置变了。

识别瓶颈所在，并把自己的注意力搬到新瓶颈上，是任何一次范式迁移里最关键的事。

三、身份的重新洗牌——从 programmer 到 builder

历史上，每次生产方式的变革，都会伴随一次身份的重新洗牌。

工业革命的时候，手工匠人的一部分技能贬值了，但一种新的角色诞生了——工程师。会计变成了财务，账房先生变成了 CFO。计算机革命的时候，打字员贬值了，程序员兴起了。而每一次这样的身份重组，总有一批人因为及时重写自我定义而受益，也总有一批人因为没能及时重写而被动地被甩下。

Peter 在他的工作里用了一个很值得留意的词——builders。他说 OpenClaw 的用户并不只是工程师，还包括创业者和没有正式编程背景的人。真正的变化不只是技术本身，而是 access——更多人第一次拥有了把想法推进成现实的能力。

这句话如果换成历史语言，大致是这个意思——“写代码”这项技能的门槛，正在从一个职业门槛，下降到一个底层工具门槛。就像 Excel 在 90 年代曾经是会计师的专业技能，后来变成所有白领的通用技能一样。

对传统程序员来说，这个趋势既是威胁也是机会。

威胁在于，“会写代码”不再是一张长期有效的饭票。护城河在变薄。

机会在于，需要被解决的问题，比以前多得多。因为 access 的扩散意味着更多人开始有能力把自己的想法产品化，而这些想法的落地都需要真正懂得如何把问题结构化的人。

所以合理的自我重写，不是把自己定义成“会写某种语言的工程师”，而是把自己定义成“能把一个模糊问题组织成可被智能系统解决的方案的人”。

用更古典的语言讲，这是从匠人到工程总监的身份跃迁。匠人的价值来自手艺，工程总监的价值来自结构。前者的价值曲线会越来越平，后者的价值曲线会越来越陡。

四、文档的重新定价——spec 是控制面板

每一次范式迁移，也会让一些原本被低估的事物，重新被定价。

在手工作坊阶段，文档是一件经常被省略的事。原因很简单，关键信息全部装在写代码的人脑子里，文档是锦上添花。到了工业化流水线阶段，文档的重要性上升了，因为协作的范围变大了，但它依然是“给人看的说明书”——是协作的附属物。

到了智能编排阶段，Peter 的实践让我们看到一件更深的事——文档的性质变了，它不再是附属物，而是控制面板。

这件事怎么理解呢？我们可以类比一下工业时代。一家工厂的图纸、工艺标准、QA 流程，在外人看来只是“说明文件”，但实际上它们是工厂这台机器的控制系统。工人依据它操作，机器依据它运转，质检依据它判断。没有这套图纸，工厂寸步难行。

agent 时代的 spec 大致是同一个角色。它不是给阅读者的消遣，而是给执行者的指令。

这意味着我们在写 requirements、design、implementation plan 的时候，标准要升级。

过去标准是“写清楚”，现在标准是“约束得准”。
过去重点是覆盖细节，现在重点是划定可变区与禁区。
过去目的是帮人理解项目，现在目的是防止 agent 乱长。

更具体地说，好的 spec 要能告诉 agent：哪里可以发挥，哪里必须保守；哪里可以重构，哪里只能局部修复；哪些测试必须先写，哪些行为必须兼容；哪些风险必须在动手前说清楚。

你会发现，这样写出来的 spec 不再是一份“项目备忘录”，它更像是一张施工图。而施工图的价值，和备忘录的价值，根本不是同一个量级。

五、效率的新度量——收敛时间

瓶颈变了，身份变了，文档变了，度量效率的方式自然也要变。

在工业时代，衡量工厂效率的指标从最早的“单件工时”演化到“整条产线的节拍”，再演化到“从订单到交付的总周期”。每一次度量单位的升级，都是一次工厂经营者认知的升级。

软件行业也在经历类似的事。

过去我们习惯用“响应时间”衡量 AI 的效率——模型多久给出第一版回答。Peter 在《Shipping at Inference-Speed》里做过一个对我很有启发的比较——有些模型先花很久读代码，表面上更慢，但更可能修对；有些模型更快、更积极，但在大改动时常漏上下文，之后不断修修补补。

这句话里藏着一个指标切换。

真正决定工程效率的，不是第一轮有多快，而是从任务被提出，到可以放心合并，一共走了几轮。

这个“几轮”才是新度量。我把它叫做收敛时间。它由几个子指标共同决定：首次通过率、返工轮数、误改范围、从 kickoff 到可 merge 的总时间、人为兜底花掉的脑力。

一旦度量单位从响应时间换成收敛时间，整个评估体系就会翻转。那些“上来就写”的 agent，在响应时间上赢；但在收敛时间上经常输。那些“先读代码、先出 plan、先写测试”的流程，看起来慢，却常常是真正快的。

这就像工业时代那个经典教训——局部最优未必是全局最优，第一工序提速反而可能拖慢整条产线。

所以经营一个 AI coding workflow，和经营一条产线在原理上没什么不同。你得盯着总吞吐，而不是盯着某一台机器的快慢。

六、管理学的回归——带 agent 像带团队

智能编排阶段还有一个耐人寻味的现象——工程师重新被管理学需要了。

过去几十年，很多程序员选择这份工作，正是因为讨厌管理、讨厌会议、希望专注于自己动手。但 agent 时代让这种逃避变得不可能。

原因很简单：你不再只是执行者。你手下（严格说是你身边）站着一批可以自主行动的智能体。你要决定它们做什么、不做什么、以什么顺序做、在哪里停下来让你看一眼。这件事和管理一个小团队在结构上没有本质区别。

带 agent 的第一课，和带人一样——放弃“它必须按我的方式写”。

过去我们 review 一个人类同事的代码，只要行为正确、契约满足、测试覆盖、可维护、可回滚，就会接受哪怕风格不那么顺眼的写法。同样的宽容度，需要被迁移到 agent 上。

如果你总是要求 agent 写得“像你亲手写的”，你的时间会被消耗在审美和习惯上，而不是消耗在真正有风险的工程决策上。这是一种不经济的工作方式。

更合理的 review 清单是这些问题：

• 是否满足 contract？
• 有没有破坏现有行为？
• 测试是否覆盖了关键路径？
• 上线后是否可观测？
• 出问题能不能快速回滚？

如果这些问题都过关，它不必长得像你写的。这不是降低标准，而是迁移标准。从“手感标准”迁移到“收敛标准”。

这种迁移其实很符合管理学的常识。一个好的团队领导，从来不会要求每个下属写出一模一样的代码，他要求的是一个可以持续产生正确结果的团队。

七、安全不再是附属——agent 时代的工程伦理

每一次生产力的跃迁，都会伴随新的风险类别的出现。

工业革命带来了职业安全问题，于是有了现代劳动法；汽车工业带来了交通事故，于是有了交通规则；互联网带来了数据泄露，于是有了隐私保护。而智能编排阶段带来的，是一种新的风险类别——能动手的智能体带来的风险。

Peter 在加入 OpenAI 的博客里说得很克制——他下一步想做的是让普通人也能使用的 agent，但这需要更多关于安全的思考，以及接触最新模型和研究。Reuters 在报道 OpenClaw 流行时也提到，错误配置可能导致网络攻击和数据泄露风险。

这两段话合起来，其实在讲同一件事——agent 和 chatbot 最本质的区别是，chatbot 只是说话，agent 会动手。当它动手的时候，它代表的是使用者的账号、权限、生产环境。

这意味着在 AI coding 的语境下，安全不能再被理解成“事后补一层”。它必须被写进 agent 的产品形态本身。

工程上，这意味着若干条默认设施：

• 最小权限；
• Dry-run；
• 二次确认；
• 敏感信息隔离；
• Diff trace；
• Rollback；
• Kill switch。

这些在 AI 狂热期很容易被当成“高级选项”而被跳过。但从更长的时间尺度上看，一个 agent 真正值得托付的标准，不是它能力多强，而是它是否可审计、可限制、可止血、可控制影响范围。

能力最强的那一类 agent 常常在兴奋期最受追捧。但能穿越周期、长期留在产业里的，一定是那些把安全当成产品内置部件的。

八、归因的工程化——失败要归给系统

最后还有一件事，是每一次范式迁移里，个体最难做好的功课——如何解释失败。

智能编排阶段的 AI coding，会有大量的失败。模型跑偏、上下文没读全、方案过度设计、测试没覆盖、改动范围失控，这些都会发生，而且不会完全消失。

在这种情况下，一个工程师对失败的解释方式，决定了他能不能在新范式里持续变强。

两个最便宜的解释都不好。一个是“我不行”，一个是“模型不行”。前者把问题归到人格，后者把问题归到工具。两者的共同缺陷是——它们都不能指向下一步该改什么。

更工程化的解释是：我的 harness 还不够好，任务边界还不够清楚，验证机制还不够强，同步流程还有洞。

这种归因的好处在于，每一次失败都会变成系统的一次小升级。kickoff 模板更准一点，测试介入更早一点，rollback 更显式一点，上下文收集更合理一点。久而久之，你的整个工作系统会开始呈现出复利效应。

Peter 建议 builder 更 playful，允许自己通过探索慢慢变强。playful 这个词不是“随便玩”，它的工程学含义是——允许失败，但要求每次失败都能被系统吸收。这是一种非常专业的心态。

九、新工匠的工作台——一套 kickoff 模板

讲了这么多历史脉络，最后我想把它凝结成一个可以马上使用的工具——一份 kickoff 模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这套模板背后的思想只有六个字：先同步，再生成。不要把 agent 当成一个马上开写的实习生，而要把它放进一个有目标、有边界、有验证、有回滚的执行系统里。

它不是一张漂亮的表格。它是新工匠的工作台。

十、结语：软件生产的三段论

把前面九节放在一起，我想给出一个简单的三段论。

第一段：软件的瓶颈，从“能不能写出来”到“能不能稳定地发出来”，再到“能不能把多个智能体的工作可控地同步起来”。

第二段：每一次瓶颈的转移，都会伴随身份的重新洗牌、文档的重新定价、效率的重新度量、安全的重新定位、管理学的重新回归。

第三段：在这三段历史的末端，最有价值的人，不是写代码最快的人，而是最会把问题组织成可执行、可验证、可收敛系统的人。

从 Peter Steinberger 身上，我学到的最重要的一课就是这件事。它不是某个工具，不是某个模型，不是某个 prompt，而是一次非常干净的历史观察——

软件生产正在从手工艺，变成系统编排。而每一个想在下一段历史里有位置的工程师，都需要重新认领自己在这条时间线上的位置。

从写代码到编排系统：我从 Peter Steinberger 身上学到的 AI Coding 方法论

起点

Peter Steinberger 加入了 OpenAI。OpenClaw 转入基金会。

这不是新闻。这是信号。

信号是——软件的瓶颈已经换了位置，而大多数人还在旧瓶颈上卷。

下面是我从这件事里抽出来的所有箴言。每一条都可以单独读，也可以合起来读。

第一条：瓶颈换了位置

AI coding 的瓶颈不是生成，是同步。

过去，你的时间花在“把想法变成代码”。
现在，模型替你花掉这段时间。
结果是，你的时间必须花在“让多个版本的真实保持一致”。

同步的对象包括：需求和实现、实现和测试、测试和设计、多个 agent 的分支、生产环境和假设。

构建便宜了，同步就贵了。
贵的地方，才是你该去的地方。

第二条：返工不是模型的问题

你发现 AI 总在返工。你怪模型。

错了。

如果你的 workflow 总在返工，多半不是模型不够强，是同步机制太差。

返工是成本溢出的信号。成本溢出的那一层，就是你该修的那一层。

第三条：你不是 programmer，你是 orchestrator

会写代码，曾经是一张长期饭票。

现在不是了。

“会不会写代码”正在变成一个底层问题。
“能不能把问题组织成可被智能系统解决的系统”，才是高层问题。

低层问题会被模型越做越便宜。
高层问题会因为模型变强而越来越贵。

把自己定义在哪一层，决定了你十年后的价格。

第四条：Builder 这个词

Peter 用了一个词：builders。

Builder 不是程序员。
Builder 是那些有问题要解决、并且能动手让结果落地的人。

这个世界缺的从来不是写代码的人，缺的是能把一个模糊愿望压成可执行系统的人。

Builder 不一定会写代码，但 builder 一定懂得如何组织问题。
会写代码的人如果不会组织问题，就会被便宜的替代品追上。

第五条：Spec 是控制面板，不是说明书

文档过去是写给人看的。

现在不是了。

Spec 是 agent 的控制面板。
好的 spec 不是写得多，是约束得准。

它告诉 agent 哪里可以发挥、哪里必须保守；哪里可以重构、哪里只能局部修复；哪些测试必须先写、哪些行为必须保持兼容。

spec 的真正价值是——让 agent 不要乱长。

一个 agent 最大的危险不是它做不到，而是它做得太多。
你不约束它，它就给你长出一个你不需要的系统。

第六条：响应时间是幻觉

你喜欢那些“上来就写”的 agent。

你被骗了。

响应时间是幻觉。收敛时间才是真的。

收敛时间 = 从任务被提出，到可以放心 merge，一共走了多少轮。

它的内部参数包括：首次通过率、返工轮数、误改范围、你兜底花掉的脑力。

一个 agent 第一轮飞快但引入一堆问题——它不快。
一个 agent 先读代码、先问问题、先出 plan，最后一次通过——它才真快。

你要优化的单位，从 response time 换成 convergence time。

这件事一换，很多选择会反过来。

第七条：前期慢一点是一种投资

慢慢读代码、先写 plan、先写测试——
这些不是拖延。

这是用前期的同步成本，换取后期的返工减免。

效率这件事，本质是一种利率问题。
你愿意用多少前期时间，换取多少后期的稳定。

愿意前付、眼界拉长的人，永远赢愿意即时满足的人。

第八条：带 agent 和带团队是一回事

从 programmer 到 orchestrator，心态变了。

你从执行者变成了管理者。

带 agent 的第一课和带人一样——放弃“它必须按我的方式写”。

契约满足、行为兼容、关键路径有测试覆盖、可观测、可回滚——
如果这些都过关，它不必长得像你亲手写的。

手工时代的标准是“代码是否符合我的手感”。
agent 时代的标准是“系统是否可控地收敛”。

这不是降低标准，是切换标准。

第九条：审美有价值，但不是首要价值

你会忍不住要求 agent“写得像你”。

这种冲动很自然。
但它是一种陷阱。

如果你把时间花在审美上，你就没时间花在风险上。

审美无限优化，边际收益递减。
风险一旦失控，会直接清零。

在 agent 时代，时间要先分配给可能让你清零的地方，再分配给让你舒服的地方。

第十条：安全是产品，不是补丁

chatbot 只是说话。
agent 会动手。

动手的时候，它代表的是你的账号、权限、生产环境。

这意味着——安全不再是附属问题。安全就是产品。

凡是让 agent 改代码、动配置、连生产、调外部 API，都必须默认加一层安全原语：
最小权限、dry-run、二次确认、敏感信息隔离、diff trace、rollback、kill switch。

这些不是“高级选项”。
它们是默认设施。

第十一条：强不如稳

兴奋期里，大家追“能力最强的 agent”。

周期长了，你会发现——

真正长期被托付的 agent，不是能力最强的，而是行为可审计、权限可限制、错误可止血、影响范围可控制的。

强在短期赢注意力，稳在长期赢信任。
信任才是复利。

第十二条：失败归因给系统，不归因给人格

你会失败，很多次。

模型跑偏。
上下文没读全。
方案过度设计。
测试没覆盖。
改动范围失控。

每一次都让你想：我是不是不行。

停。

不是你不行，也不是模型不行。是你的系统不行。

harness 不够好。
任务边界不够清楚。
验证机制不够强。
同步流程有洞。

这种归因方式的价值在于——它给你下一步该改什么。
自我怀疑给不了这个。

第十三条：每次失败都要换来系统的一次小增量

Peter 说 builder 要更 playful。

playful 不是“随便玩”。

playful 是允许失败，但要求每次失败都能被系统吸收成增量。

kickoff 模板更准了。
测试介入更早了。
rollback 更显式了。
上下文收集更合理了。

复利就是这么来的。
不做这件事的人，每一次失败都是一次纯损失。
做这件事的人，每一次失败都是一次未来的利息。

第十四条：能力是在探索里长出来的

Peter 在 TechCrunch 的采访里说，他一开始也没有完整计划，很多东西是在探索中长出来的。

所以：

不要期待自己第一天就是专家。
AI coding 是一门乐器，不是一句咒语。

咒语靠记忆。
乐器靠练习。
你要练的是手感、节奏、判断力，不是某一句 prompt。

第十五条：先同步，再生成

这是全部箴言里最重要的一条。

先同步，再生成。

不要把 agent 当成一个马上开写的实习生。
把它放进一个有目标、有边界、有验证、有回滚的系统里。

把这六个字刻进流程，你就已经拉开了和大多数 AI coding 使用者的差距。

第十六条：Kickoff 模板

把前面十五条压成一张表：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

任务挡位：
- 探索 / 设计 / 实现 / 修复 / 上线

任务目标：
- 这次必须完成什么
- 成功之后，用户或系统会看到什么变化

明确边界：
- 这次不做什么
- 哪些文件、接口、表结构、状态机禁止擅自扩展
- 哪些行为必须保持兼容

执行要求：
- 先读哪些上下文
- 是否必须先出 plan
- 是否必须先写测试
- 哪些动作需要二次确认后再执行

验证标准：
- 必须通过哪些测试、lint、build、smoke
- 必须提供哪些 diff、日志、风险说明
- 是否需要 rollback plan 或 feature flag

输出格式：
- 先给结论
- 再给变更点
- 再给风险点
- 最后给验证证据

这不是表格。
这是一套被压缩过的方法论。

第十七条：两种价值曲线

两种自我定义，两条未来曲线。

“我是一个会写代码的工程师”——这条曲线的斜率会越来越平。
“我是一个能把问题组织成可被智能系统解决的人”——这条曲线的斜率会越来越陡。

选哪一条，决定了你五年后的定价。

第十八条：新价值公式

用一个公式收尾：

价值 = 问题定义力 × 上下文组织力 × 边界设置力 × 验证严格度 × 风险控制力 × 流程沉淀力

这六个变量全部是乘法关系。
任何一项趋近零，整体趋近零。

过去，公式里可能只有一项是“写代码速度”。
现在，写代码速度已经不再是独立变量了——它被模型吸收进了环境常数。
你要训练的是其他六项。

过去训练的是手速。现在训练的是结构感。

第十九条：新范式的一句话

把这篇文章压缩成一句话，就是这一句——

软件生产正在从手工艺，变成系统编排。

旧范式里，程序员的价值来自亲手写代码。
新范式里，价值来自定义问题、组织上下文、设置约束、分配执行、验证结果、控制风险、沉淀流程。

前者的护城河在塌方。
后者的护城河在隆起。

第二十条：结束语

Peter Steinberger 给我的全部启发，能抄到笔记本上的，只有两行。

未来最有价值的人，不是写代码最快的人，
而是最会把问题组织成可执行、可验证、可收敛系统的人。

这两行不是结论，是起点。

从今天开始，每一次任务——先想边界，再想步骤；先想验证，再想实现；先想回滚，再想上线；先想“如何让智能系统稳定产出”，再想“我要自己动手做什么”。

你就已经在训练一条在未来十年复利最高的肌肉了。

剩下的，交给时间。