发表于 | 分类于

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境的朴素工程哲学

今天我想跟你聊一位工程师——Mitchell Hashimoto。他是 HashiCorp 的联合创始人，你可能没听过这家公司，但你一定用过它的产品：Terraform、Vault、Consul、Vagrant。过去十年云计算的基础设施，有相当一部分是他参与设计的。

但今天不聊云。今天要聊他关于 AI agent 的一个观点。这个观点极其朴素，朴素到你第一反应可能是“就这？”——

当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

就这。他把这件事命名为 harness engineering（驾驭工程）。

这个观点的魅力，恰恰在于它看起来毫不性感。你想想，在关于 AI 的讨论里，大家平时都在谈什么？谈模型又更新了；谈 agent 能不能替代人；谈某个公司估值又涨了；谈今年 AGI 是不是就要来了。声音越大越戏剧，流量越大。

Mitchell 不凑这种热闹。他只讲一件事——agent 犯错之后，人该干嘛。 我越琢磨这件事，越觉得它可能是整个 AI 编程讨论里，最经得起时间考验的一句话。

咱们分几层来拆。

第一层：先搞清楚 agent 到底是什么

很多人对 AI 编程的理解，其实停留在“会写代码的聊天框”。你问它，它答；你复制，它生成。这是 chatbot 模式。

Mitchell 在《My AI Adoption Journey》里做了一个非常重要的区分——chatbot 和 agent 是两种不同的东西。

chatbot 主要靠模型已有的知识回答问题。它不进入你的环境，它不知道你的代码库长什么样，它也不会主动跑任何东西。你给它一段代码，它给你一段建议；中间要来回复制粘贴。你要纠正它，得靠你自己读完输出、发现问题、再告诉它。

agent 不是这样。agent 的最低标准，他给得很具体——至少要能读文件、执行程序、发起 HTTP 请求。 也就是说，agent 不是在回答，它是在“行动”。它能进入一个工作环境，尝试一件事，看结果，再决定下一步做什么。

这个区分看着简单，但它改变了整个协作方式。chatbot 是“我问它答”，agent 是“我给目标，它在环境里尝试”。前者每一次失败都回到 prompt——“这次我该怎么说才能让它听懂”；后者每一次失败都回到系统——“这个环境该怎么设计才能让它更容易做对”。

划重点：把 AI 当 chatbot 的人，最重要的杠杆是 prompt；把 AI 当 agent 的人，最重要的杠杆是环境。

这就是 Mitchell 观点里最重要的前提。如果你不接受这个前提，下面的所有话都听不进去。

第二层：agent 犯错意味着什么

好，假设我们接受 agent 是一个会在环境里行动的东西。那它会犯错吗？一定会。

这时候普通人会怎么想？三种本能反应：

第一种，骂模型。“Claude 就是笨。” “GPT 更新之后反而更蠢了。” 这种反应最多，因为便宜。
第二种，重写 prompt。“我再把需求讲得更清楚一点。” “我再给它加几个例子。” 这种反应看起来很勤奋。
第三种，自己上手。“算了，它搞不定，我自己写吧。” 这种反应最干脆。

Mitchell 的反应不是这三种里的任何一种。他的反应是——把这次错误，变成环境的一个永久约束。

我给你举个具体的例子。

Ghostty 是一个终端模拟器，代码在 GitHub 上开源。它的 src/inspector 目录下有一个小文件叫 AGENTS.md。这文件里写了什么？写了五句话——

  • inspector 类似浏览器的开发者工具。
  • dcimgui.h 这个头文件在哪个位置。
  • widget 的例子在哪里可以参考。
  • macOS 上构建时，要加哪些特定参数。
  • 这个包没有单元测试。

就这五条。没有高深理论，没有 AI 指南，没有 prompt 模板。全是 agent 之前犯过错的地方——它找不到 dcimgui.h 时胡乱猜测、它用错构建参数时反复失败、它不知道这个包没有测试时以为可以跑测试。每一次错误，Mitchell 都把它写成了一句环境说明。

这就是 harness engineering 的基本形状：把 agent 的每一次具体错误，沉淀成环境里的一条具体约束。

他把 harness 的形式分成两类——一类是这样的隐式提示文件，改变的是 agent 的认知上下文；另一类是程序化工具，比如截图脚本、过滤测试脚本、轻量的模拟环境，改变的是 agent 的行动能力和反馈质量。

你细想一下：这不就是你工作了十年的老工程师天天在做的事吗？写文档、建脚本、加测试、立规矩、把口头知识落成文字。只不过以前这些东西是给新员工看的，现在是给 agent 看的。

换句话说，harness engineering 不是什么 AI 新学科，它就是把老工程师的常识搬进了新场景。

第三层：为什么这比“更好的 prompt”更值得投入

你可能会问——“写个 prompt 不就好了？为什么要搞这么重的基础设施？”

这个问题值得用一个类比来回答。

prompt engineering 和 harness engineering 的区别，像“出门前嘱咐孩子”和“把楼梯口装上防撞条”的区别。

出门前嘱咐孩子“别在楼梯口跑”——这是 prompt。你说得越具体越好。但嘱咐这件事的收益是一次性的，这次管用，下次可能就忘了，换一个孩子可能完全没用。

给楼梯口装一个防撞条——这是 harness。一次性投入，永久生效。不管是哪个孩子、哪天、什么状态，都有效。

这两件事都重要。但从投入产出比来看，只要是你会反复做的事情，投入到环境里的成本，收益会复利累积；投入到 prompt 里的成本，收益会随着对话消失。

Mitchell 的工作方式就是这样：他允许自己这一次写一个 prompt 把问题解决掉，但如果同一类问题出现了第二次，他会停下来想一下——这件事能不能变成一条环境里的规则？如果能，就花时间写进去。

这种思路在软件工程里叫“把人工 checklist 自动化”。它在 AI 之前就存在了几十年——写测试、做 CI、统一环境、封装脚本、加 lint、把散落的知识写进文档。Mitchell 的原创之处在于，他把这套思路显性地移植到了 AI agent 时代，并给它起了一个名字。

OpenAI 后来在讨论 Codex 的一篇文章里，也采用了非常类似的框架——他们说，当 agent 失败时，不要问“怎么让模型更努力”，而要问“这里缺了什么能力？这个能力怎么让 agent 可读、可执行、可约束”。LangChain 干脆把这件事写进了定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。

这些都是后来发生的事。Mitchell 更早就已经在做了。

第四层：架构不外包，agent 是 junior engineer

现在还有一个疑问——harness 做得再好，agent 不还是会犯错吗？那人类到底还干什么？

Mitchell 对此有一个非常清晰的比喻：和 agent 合作，像指导一个 junior engineer。

这个比喻我要稍微展开一下，因为它特别准。

设想你刚带一个实习生。他聪明、听话、能写代码，唯一的问题是没有工程经验——不知道你们团队的约定、不理解系统的历史包袱、对“哪里不能碰”没有感觉。这时候你会怎么安排他？

有经验的带人者，不会说“你去优化我们的订单系统”。他会说——“你看这个接口，加一个重试逻辑，重试条件是 A 和 B，不要改 C，写一个对应的单元测试，完成后我 review 一下。”

区别在哪？前者是一个无边界的开放式问题，后者是一个边界清楚、护栏齐全、验证明确的小问题。junior engineer 在后一种任务上能干得非常好；在前一种任务上，99% 会出事。

agent 目前的位置，几乎和一个聪明但没经验的 junior 完全一样。 它不是笨，它是缺上下文、缺约束、缺反馈。

所以 Mitchell 从不把架构外包给 agent。他负责代码结构、数据流、状态归属——这些决定“这个系统长什么样”的问题，他一个都不交。他把设计做好，把问题切成合适的形状，然后让 agent 在那个形状里行动。

他在 Zed 的访谈里说过一句很实在的话——如果你只告诉 agent “这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下一个你以后一定要还的债。

一句话总结：agent 不是价值判断者，不是架构负责人，更不是最终责任人。它是团队里速度最快、但需要明确边界才能干好活的成员。

第五层：一个不能外包的东西——责任

这是我认为 Mitchell 最有分量的一块。

他在 2025 年 10 月写过一篇文章叫《Vibing a Non-Trivial Ghostty Feature》，公开了他用 AI 完成 Ghostty 一个具体功能的全过程——16 次 agentic coding session，成本 15.98 美元，8 小时墙钟时间。很多人引用的是这些数字。

但我想让你记住的是另一段。

他在做这个功能的过程中，遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，测试都能过，但里面藏着一个关键 bug。他尝试了几次更精确的 prompt，都没修好。

这时候，常规的工程师本能有好几条路——再换一个 prompt、再换一个模型、等下个版本出来。

Mitchell 选的都不是。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解 bug 的原理。然后他在博客里写了一句，我觉得是整个 AI 编程讨论里最该被加粗的一句话：

如果 agent 找到了解法，我会学习。如果我不理解，我就回退。我不交付自己不理解的代码。

这句话为什么重要？因为今天关于 AI 编程的讨论，大部分都停在速度层面——更便宜、更快、更多产出。这些都是真的。但 Mitchell 想让你记住的另一件事是——你理解了吗？你能维护吗？它会不会回归？下一个读这段代码的人，会更容易还是更困难？

AI 可以写代码。但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试；但最终合进代码库的是你。产品出了 bug，用户不会说“这是 Claude 写的所以不算”；维护者也不能把不可理解的复杂性推给模型。

这才是真正的分水岭——AI 时代成熟的工程师和不成熟的工程师，最大的差别不在于谁 prompt 写得漂亮，而在于谁更敬畏“自己不理解的代码”。

第六层：为什么这条原则很难过时

我知道你可能会说——“这些经验不都是暂时的吗？等模型更聪明了，不就不用搞这一套了？”

Mitchell 自己就承认这一点。他在 Open Source Ready 里说，今天很多 AI 协作技巧——比如怎么管理 context、怎么打开正确的 buffer、怎么塑造反馈回路——可能都是几年后不再需要的“临时技能”。

这种自我警觉非常珍贵。很多 AI 讨论者的问题，恰恰是把当下的具体技巧说成永恒真理。

但是请注意，即使具体技巧会过时，harness engineering 背后的姿态不会过时。这个姿态是什么？

简单说就是：不把错误当成模型的偶然失误，而当成系统的缺口；不指望模型下次自己变聪明，而是改造环境让同样的错更难发生。用可重复的反馈回路替代一次性的人工祈祷，让机器做重复劳动，人来做判断和创造。

这些原则，软件工程已经用了三十年。它们在 Vagrant 解决“环境难复现”的时候成立；在 Terraform 解决“基础设施难声明”的时候成立；在今天 Mitchell 做 agent harness 的时候成立；在未来某个更聪明的模型来临时，很可能仍然成立。

Mitchell 自己在 2019 年接受 WIRED 采访时就说过一句话——“我这辈子做的事情有一条连续的线索：自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

你看，这句话放到 2026 年的 agent 时代，一个字都不用改。变的只是“重复劳动”的内容——以前是搭虚拟机、写配置、管理 secret；现在是查资料、跑测试、写样板、做 refactor。工具变了，工具背后的那条线没变。

这就引出一个判断标准：一个观点能不能穿越技术周期，关键看它绑定的是“当下的工具”还是“不变的原则”。 绑定工具的观点，工具变就死了；绑定原则的观点，工具怎么变都活着。

第七层：给你的三条可直接用的 takeaway

好，理论讲完了，给你三条可以今天就用上的行动建议——

第一条：别一上来就追求一个完美 AI 流程。 Mitchell 的 harness 不是设计出来的，是从错误里长出来的。agent 跑错命令，就记录；误用 API，就加说明；忘记跑测试，就写脚本。一次修一个错，半年之后你会发现自己已经有了一整套 harness。追求一次到位的人，往往最后什么都没做。

第二条：给 agent 的任务，要像给 junior engineer 的任务。 不要说“把这个系统优化一下”，要说“只改这个模块，先读这几个文件，不要改公共 API，新增这个测试，运行这个命令”。agent 的速度会诱惑你把问题丢大，但 Mitchell 的经验恰恰相反——小块工作更容易 review、理解和迭代。

第三条：不要 ship 你自己不理解的代码。 不管 agent 多聪明，多便宜，多快——代码合进去了，责任就是你的。如果 agent 修了一个你看不懂的 bug，停下来，去学，去研究。如果学不会，回退。这个规矩听起来像在给你踩刹车，但它其实是 AI 时代最保护你的一条。

Mitchell Hashimoto 的价值，不在于他提出了什么新词，也不在于他用了哪个模型。他的价值在于，在一个嘈杂到让人恍惚的时刻，他用非常朴素的一句话，把 AI agent 这个看起来很玄的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

他让你相信一件事——AI 时代的成熟工程师，可能不是最会写 prompt 的人，而是最会把一次错误，变成永久护栏的人。

这是一种很笨的智慧。但好多笨的智慧，最后都赢了。

发表于 | 分类于

人物雷达｜Mitchell Hashimoto 和他的朴素工程哲学

我观察 Mitchell Hashimoto 有一段时间了。

在讨论 AI agent 的人里，他是一个奇怪的存在。他不做预测，不讲愿景，不谈谁会被替代，甚至承认自己今天使用 agent 的很多技巧，三年以后可能就不再需要。他只是在博客和访谈里，讲他怎么用的、哪里用得好、哪里被卡住、卡住之后怎么想。

但如果你把他过去一年的表达拼起来看，会发现它们形成了一个克制、朴素、也很难被时间淘汰的结构。

这个结构可以用他自己的一句话概括：当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话听起来几乎不像一个“观点”。它不锋利，不性感，没有流量。但它恰恰是我愿意花一篇文章写他的原因。

他先是个做环境的人，然后才是个用 agent 的人

要理解 Mitchell 现在的 AI 观，得先绕开 AI，回到他过去十几年做的事情。

他在自己网站上把履历写得非常冷静——主要在做 Ghostty；曾在 HashiCorp 做过四年 CEO、五年 CTO、两年个人贡献者，2023 年离开。这份简历背后，是 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint——几乎构成了过去十年云基础设施的默认词汇。

有意思的是，把这些工具并排放着看，会发现一条相当连贯的线索：它们都在解决同一件事——怎么让一个开发者环境，从“存在于某个老员工脑子里”，变成“可以被代码描述、被机器复制、被工具执行”。

Vagrant 让本地开发环境可以被复制，Terraform 让云基础设施可以被声明，Nix 让整台桌面可以被代码重建——Ghostty 是终端，看起来和前几样不太一样，但仍然是开发者环境的一部分。

他在 Open Source Ready 聊 Nix 的时候有一句话让我印象挺深——他说自己其实想要的只是一种“可靠、一致、可用代码重建”的桌面。这听上去很简单，但放进他过去所有工具里都成立。

这个人一辈子都在做一件事：把人对环境的隐性依赖，转成环境本身的显性约束。

所以当他进入 agent 时代时，他看 agent 的角度和大多数人不一样。他不觉得 agent 是一个需要仰望的智能体，也不觉得它是一个需要贬低的补全工具。他看到的是一个会在环境里读文件、执行命令、调用工具、观察结果、循环行动的东西——换句话说，一个新的、可以被工程化地约束和塑形的对象。

这是他和大多数 AI 讨论者的分水岭。

他一开始其实不太满意

我不喜欢过度拔高一个人的“先见之明”。Mitchell 对 AI 的态度不是一开始就那么清晰的，他自己也聊过这件事。

在《My AI Adoption Journey》里，他说自己第一次认真用 Claude Code 的感觉是——不太行。生成的东西要大改，改完还不如自己写。他一度怀疑自己是不是不适合这套工作方式。

然后他做了一件我觉得很能代表他性格的事情。

他没有得出“agent 不行”的结论，也没有得出“我不行”的结论。他选了一条更笨、更慢的路——把自己已经手写完成的 commit 拿出来，关掉答案，逼自己用 agent 在看不见答案的前提下，复现同等功能和质量的结果。

这件事其实很反效率。他在正常交付之外，又凭空给自己加了一层工作量。但也正是在这段笨功夫里，他开始真正理解 agent 适合什么、不适合什么。

他自己总结出了三条结论，简单到几乎像一本软件工程教科书：任务要拆小；模糊需求要先规划再执行；最重要的——给 agent 一个能自己验证工作的办法。

读到第三条的时候，很多人会觉得这不就是测试吗？是的。这正是他的风格。他不造新词，他把那些我们本来就熟悉的工程原则原样搬了过来。只是以前我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次会变聪明，要把这次错误变成环境的一个约束”。

为什么是“环境”，而不是“prompt”

Mitchell 讨论 AI 时，很少聊 prompt。

这件事本身就值得注意。今天大多数关于 AI 编程的内容，核心都是 prompt——怎么写出更好的 prompt，怎么骗模型一步步思考，怎么给它塞上下文让它听话。但 Mitchell 几乎从不谈这些。

他谈的是 harness——套在 agent 外面的那一整层环境：规则、文档、工具、脚本、测试、权限、工作目录、反馈信号、观察机制。

LangChain 早就有过一句简洁的定义——Agent = Model + Harness。模型提供智能，harness 让智能变得可用。Mitchell 不是提出了这个概念，他只是把它变成了日常工作的重心。

他把 harness 分成两类。一类他叫“更好的隐式提示”，最典型的载体是项目里的 AGENTS.md 文件。Ghostty 仓库的 src/inspector/AGENTS.md 是个小而具体的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；widget 例子在哪里；macOS 构建时要加什么参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的本地说明。

另一类是真正的程序化工具——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者加起来是这样一件事——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再违反架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 很像，但不是一回事。prompt engineering 是“这一次我怎么说”，harness engineering 是“这个系统怎么设计”。前者的收益随对话消散，后者的收益会长期累积。

Mitchell 相信的是后者。原因不复杂——他一辈子都在相信后者。

责任不能外包：一句分量很重的话

他在 2025 年 10 月发过一篇文章，《Vibing a Non-Trivial Ghostty Feature》。那篇文章公开了他用 AI 辅助完成 Ghostty 一个具体功能的全过程——macOS 上不打断用户的自动更新提示。

很多人关注里面的数字：16 次 agentic coding session，token 成本 15.98 美元，约 8 小时墙钟时间。他自己也承认效率提升是真实的，尤其是 SwiftUI 细节迭代那部分，AI 帮了大忙。但我读那篇文章时，印象最深的不是这些数字，而是他在遇到 bug 时的一段话。

他遇到了所谓的 slop zone——agent 生成的代码看起来合理，能跑，甚至测试都能过，但里面藏着一个关键 bug。他换了几次更精确的 prompt，都没有修好。

这时候，工程师的本能会告诉你——再换一个 prompt；再换一个模型；或者等 Claude 下个版本。

他没有选任何一条。他停下来，自己去学 Sparkle 框架，自己去看 Obj-C 的 protocol，自己去理解为什么会出错。然后他在博客里写下了一句让我反复想了很多次的话：

如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。

这句话的分量，在 AI 编程的讨论里不太常见。

今天太多人在讨论 AI 带来的速度，这些都是真的。但 Mitchell 更在意另一样东西：你理解了吗？下一个看到这段代码的人——不管是人类还是 agent——会因此更轻松，还是更痛苦？

AI 可以写代码，但代码的责任不会因此外包。你可以让 agent 试、写、改、跑测试、整理结构；但最终合进代码库的是你。产品出了问题，用户不会说“这是 Claude 写的”；维护者也不能把不可理解的复杂性推给模型。

Mitchell 的这句话，我私下认为是整个 AI 编程讨论里最接近“工程伦理”的一句。没有宏大叙事，但它把一个特别容易被模糊掉的边界，清晰地钉下来了。

他把 agent 当 junior engineer，不当 superhero

Mitchell 有一个常用的类比——和 agent 合作，就像带一个 junior engineer。

如果你是个带过人的工程师，你会立刻懂他在说什么。

把一个开放式问题丢给 junior，比如“去优化一下我们的订单系统”，基本等于灾难。把一个边界清楚、护栏齐全、验证明确的小问题丢给 junior，比如“这个接口加一个重试逻辑，条件是 A 和 B，不要改 C，写一个对应测试”，他往往能做得不错。

AI 目前处在一个很类似的位置。

这也是为什么 Mitchell 从不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，再让 agent 在那个形状里行动。他在 Zed 的访谈里说过——如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式，把症状敲掉，留下一个你将来一定要还的债。

他对 agent 的能力边界，也判断得很具体。

重构、重命名、整理结构、清理死代码、填空式的样板代码——agent 几乎总能做得很好。他把这类任务称作“outsource the slam dunks”，专门挑高把握的扔给它。

开放式架构、高性能数据结构、小众语言——agent 目前仍然很差。Ghostty 底层是 Zig，但 Zig 的训练数据太稀缺，agent 常常幻觉出根本不存在的语法。他的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己手工翻成 Zig。

这不是什么宏大的理论。这就是一个老工程师在分配任务。只是他现在多了一个**“永远不抱怨、永远不累、但需要护栏”**的新成员。

他不相信“X + AI”

Mitchell 有一个经常被误解的立场——他对 AI 产品的批评。

很多人以为他是 AI 怀疑派。其实不是。他反对的不是 AI，而是一种特定的做法——把 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一类典型的 AI 产品：一个邮件客户端本身已经不好用，只是外面加了 AI 功能；一个笔记应用本身已经割裂，只是加了个 AI 总结。他的判断简单粗暴——AI 集成可以很好，但用户最终仍然要使用完整产品；如果基础体验不成立，AI 救不了它。

这句话背后其实是一以贯之的工程哲学：基础要扎实，环境要可靠，工具要真正解决人的问题。 一个糟糕的产品加上 AI，不会变成好产品；一个混乱的代码库加上 agent，不会变成可维护系统。AI 会放大已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也在发生变化。在 The Pragmatic Engineer 那篇访谈总结里，他提到开源可能会从 default trust 走向 default deny——因为 AI 让“看起来合理但实际低质量”的贡献变得太容易。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制。

他的 Ghostty 里那个被反复删除的 issue，就是这种态度的具体体现。有人贴了另一个终端的 GPL 代码片段，他立刻删了。对方说你让 ChatGPT 生成类似的就行，他反问——这样做安全吗？是不是把代码通过模型洗了一遍？他没有给答案，他只是说希望法律先例先明确。

一个愿意在具体问题上说“我不知道”的人，才有资格在大问题上被信任。

一条不变的线索

WIRED 在 2019 年做过一期关于他的报道。文章里他自己说——“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放到 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界在移动。过去是搭环境、建虚拟机、管理 secret、写配置；现在扩展到了查资料、跑测试、写样板、做 refactor、修构建错误。

变化的是工具，不变的是原则。

所以 Mitchell 的 agent 哲学，从来不是“让人退场”。他从不说编程会消失，也不说工程师会被替代。他说的是另一件更温和、也更诚实的事情——人要换一个位置。 过去大量时间花在亲手写代码，现在要有一部分时间转向设计“agent 能成功工作的环境”；过去经验沉淀在资深工程师脑子里，现在要沉淀进 AGENTS.md、脚本、测试和约束。Review 不只是看人写的代码，还要看 agent 是否被正确引导。

这个位置迁移，听起来不像一个很性感的故事。它没有“一切都将改变”的戏剧感。但它可能更接近真实发生的事情。

一个很难被淘汰的想法

我想最后回到那句话——当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。

这句话的好处是，它不依赖任何一个具体模型、任何一个具体工具、任何一个具体版本。模型会变，工具会变，今天的 harness 明天可能就过时。但这句话所表达的姿态——把错误当成系统暴露出来的缺口，而不是模型的偶然失误——几乎可以迁移到任何技术的任何时代。

也许几年以后，agent 比我们所有人想象的都聪明。到那时候，很多具体技巧会被扔进“临时技能”的抽屉里，包括 Mitchell 今天讨论的很多。但我不觉得 harness engineering 的姿态会过时。

因为它本质上说的是一件很老的事——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是系统暴露出来的可工程化信号。

软件工程里，所有真正有复利的东西，几乎都是这个形状。

Mitchell Hashimoto 的价值不在于他发明了什么新术语，而在于他在一个很喧嚣的时刻，把 AI agent 这个看似魔法般的东西，拉回了工程师最熟悉的地面——环境、约束、反馈、自动化、责任。

这种姿态不一定最能吸引眼球。但时间通常比较偏爱这种人。

发表于 | 分类于

人物雷达｜Mitchell Hashimoto：每次 agent 犯错，就改造环境

一个被反复删除的 issue

2025 年春天，Ghostty 的 GitHub 仓库里出现过一个很短的插曲。

有用户在 issue 里贴了另一个终端模拟器的源代码片段，希望 Ghostty 参考实现。Mitchell Hashimoto 很快把这段代码删掉了，并留下一条说明：Ghostty 是 MIT 许可，对方是 GPL，贴进来就污染了整条上游。

几小时之后，那位用户回来了，补上一条看似合理的建议：“那你让 ChatGPT 生成一段类似的代码就行。”

Mitchell 没有立刻同意，也没有立刻拒绝。他反问了一句——“这样做安全吗？是不是只是把代码通过一个模型洗了一遍？”

这是一个微小到几乎不值得记录的交互。但在今天回看，它几乎是 Mitchell 所有 AI 观点的浓缩：他愿意使用 AI，但不相信任何关于 AI 的“捷径叙事”；他接受不确定性，但不愿意用自信掩盖不确定。

过去两年，硅谷工程师里谈 AI 的声音被分成两派。一派是布道者，宣称编程即将终结；一派是反对者，认定 agent 只是高级补全。Mitchell Hashimoto 很少被归进任何一派，但他在自己的博客、Zed 的访谈、Heavybit 的播客、Open Source Ready 的长对话里，一砖一瓦地搭出了第三条路——AI agent 并没有那么神秘，它只是软件工程里一个新的、需要被工程化的对象。

这个姿态里，最常被引用的一句话是他自己写下来的：“当 agent 犯错，就花时间工程化一个解决方案，让它不再犯同样的错。”

他把这件事叫做 harness engineering。

一个“不愿意交付自己不理解的代码”的人

要理解 Mitchell 的这套哲学，不能从 AI 开始，要从终端开始。

在自己网站上，他把现在的身份写得极简——主要在做 Ghostty；曾在 HashiCorp 做过约四年 CEO、五年 CTO、两年个人贡献者，2023 年离开公司。HashiCorp 旗下的 Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypoint，今天几乎是云基础设施的默认词汇。他把一家公司做到上市之后选择抽身，回到一个没有融资计划、没有商业化路径的开源终端项目上，这在硅谷是个很任性的选择。

但只要把这些工具连起来看，会发现一条不算太隐秘的主线：他做的每一样东西，几乎都在回答同一个问题——怎么让开发环境变得可描述、可复制、可被机器执行？

Vagrant 解决本地开发环境的复现；Terraform 解决云基础设施的声明；Nix 让整台桌面可以用代码化的方式重建；Ghostty 是终端，仍然是环境的一部分。他在 Open Source Ready 谈 Nix 时顺便说过一句，自己对 Nix 的兴趣，其实是想要一种可靠、一致、可被代码重建的桌面。这句话放在 Terraform 的早期也完全成立。

所以当 Mitchell 进入 agent 时代，他看它的视角不是“模型崇拜”，而是“环境工程”。对他来说，agent 不是黑箱智能体，而是一个会在环境里读文件、执行程序、调用工具、观察结果、继续行动的系统。它要行动，环境就必须能纠错；它会重复犯错，系统就该把错误沉淀成规则、脚本和反馈回路。

从“改比写还慢”到“强迫自己复现”

Mitchell 并非天然的 AI 乐观派。

在《My AI Adoption Journey》里，他承认自己第一次认真用 Claude Code 的体验相当糟糕——生成的代码要大改，改完比自己写还慢，他一度怀疑这东西是不是真的能用。

他没有就此下结论。相反，他做了一件很笨的事：先用手写 commit 把一个任务完成，然后关掉答案，让 agent 在看不到自己答案的前提下，复现同等功能和质量的结果。

过程很折磨人，因为它妨碍了正常交付；但他坚持了下来，因为这是建立“直觉”的唯一方式——agent 到底适合什么、不适合什么，不是读 paper 读出来的，是一个一个任务试出来的。

这段经历沉淀成几条朴素的心得：

  • 任务要拆小，不要把一个模糊的大目标丢给 agent。
  • 模糊需求先规划再执行——想清楚做什么，再让它动手。
  • 最关键的一条：给 agent 一种验证自己工作的办法。只要它能自己跑测试、自己看输出，往往就能自己修好。

读到最后一条可能会愣一下——这不就是 CI、测试、lint、端到端脚本吗？是的。这正是 Mitchell 的风格——他不造新词，他把老工程师的常识原样搬进 AI 时代。过去我们说“不要让人记住规则，让系统执行规则”；现在他说，“不要指望 agent 下次变聪明，要把这次错误变成环境的约束”。

Harness Engineering：错误不是事故，是系统的缺口

Harness 这个词本身不新。LangChain 早就把它写进定义里：Agent = Model + Harness。模型提供智能，harness 让智能变得可用——文件系统、bash、沙箱、工具、状态、反馈回路，都是 harness 的一部分。

Mitchell 的贡献不在术语，而在一种工作习惯：他把所有 agent 的错误都当作系统缺口，而不是模型愚蠢。

在 Zed 的访谈里，他把 harness 的形式拆成两类——

第一类是“更好的隐式提示”，最典型的载体是 AGENTS.md。如果 agent 总是跑错命令、找错 API、误解子系统，就把这些经验写进项目根目录或子目录的指导文件。Ghostty 的 src/inspector/AGENTS.md 就是个小而典型的例子：它告诉 agent，inspector 类似浏览器开发者工具；去哪里找 dcimgui.h；如何查 widget 示例；macOS 构建要加哪些参数；这个包没有单元测试。没有一句宏大的 AI 理论，全是具体到命令、文件、API 的环境说明。

第二类是“真正的程序化工具”——截图脚本、过滤测试脚本、可重复的构建命令、轻量的模拟环境。前者改变 agent 的认知上下文，后者改变 agent 的行动能力和反馈质量。

两者结合起来，就是一句话——agent 找不到 API，就写下 API 的位置；用错构建命令，就把正确命令写进去；不知道如何验证 UI，就给它截图工具；一再破坏架构边界，就写结构性测试或 lint 规则。

这和 prompt engineering 是两条不同的路径。prompt engineering 是语言技巧，收益随对话消失；harness engineering 是基础设施，收益会复利累积。Mitchell 相信的是后者。

16 个 session，8 个小时，$15.98 和一个“slop zone”

2025 年 10 月，他写了一篇《Vibing a Non-Trivial Ghostty Feature》，公开展示自己如何用 AI 辅助完成一个真实的非平凡功能——在 macOS 上不打断用户的自动更新提示。

文章里最诚实的数字是这些：16 次 agentic coding session，token 成本 15.98 美元，估计墙钟时间约 8 小时。他承认自己确实比纯手写快了，尤其是 SwiftUI 细节迭代那部分；但他更强调的不是成本，而是工作结构——AI 最大的价值，不是每行代码变便宜，而是他离开电脑时，机器仍然能帮他产生候选。

这篇文章另一个被反复引用的部分，是他对“slop zone”的描写。

所谓 slop，是指 agent 生成的代码看起来合理、能跑、甚至能过测试，但里面藏着关键 bug。他试了几轮更具体的 prompt，没用。工程师的惯性反应是：再换个 prompt，再换个模型，再等 Claude 4.6 出来。

Mitchell 的选择是——停下来，自己学，自己研究。他在文章里写了一句很重的话：“如果 agent 找到了解法，我会学习；如果我不理解，我就回退。我不交付自己不理解的代码。”

这句话在他所有 AI 表达里，分量最重。它把 AI 工作流里最模糊的那块——责任——钉死了。你可以让 agent 试、写、改、跑测试、找资料；但最终合进代码库的是你，用户遇到问题时不会说“这是 Claude 写的”，维护者不能把不可理解的复杂性推给模型。人工 review 不是流程，是工程伦理。

架构师不外包，junior engineer 要护栏

Mitchell 反复强调一个类比：与 agent 协作，像指导一个 junior engineer。

把一个开放式问题丢给 junior，经常是灾难；但要是问题边界清楚、护栏齐全、验证明确，junior 往往能做得很好。AI 目前就在这个位置上。

所以他从来不把架构外包。他负责代码结构、数据流、状态放在哪里；他把问题切成合适的形状，然后让 agent 在那个形状里行动。他甚至说过一句话：如果你只对 agent 说“这个 bug 存在，修一下”，它可能真能修，但很可能是用一种锤子砸钉子的方式把症状敲掉，留下长期不可维护的债。

这不是对 agent 的不信任，而是对任务分配的成熟判断。优秀的工程师不会把所有任务平均分给团队，他会按能力、上下文、风险和验证成本分配。对待 agent 也是如此——它擅长什么？Mitchell 的经验是：重构、重命名、整理结构、清理死代码、填空式的样板代码，几乎总能做得很好。它不擅长什么？开放式架构、高性能数据结构、小众语言。

Zig 是他最常举的反例。Ghostty 底层是 Zig，但 Zig 的训练数据太稀。Mitchell 的 workaround 很务实——让 agent 用它更熟悉的 C、Rust、Swift 或 Python 写方案，再由自己转成 Zig。他后来在 Heavybit 访谈里补充过一句：“让它直接写大段 Zig，它常常幻觉出不存在的语法。”

这是成熟工程师在 AI 时代的思路：不指望一个模型解决所有问题，按任务的形状分配工具。

X + AI 救不了底层不成立的东西

外界常把 Mitchell 误认成 AI 怀疑派，其实他只是反对一种特定的倾向——拿 AI 当产品的遮羞布。

在 Open Source Ready 的访谈里，他批评过一批所谓 AI 产品：邮件客户端本身不好用，只是加了 AI 功能；笔记应用本身功能割裂，只是加了 AI 总结。他的判断是，AI 集成可以做得很好，但用户最终仍然要使用完整产品，如果基础体验不成立，AI 救不了它。

这句话背后仍然是同一条工程哲学：基础要扎实，环境要可靠，工具要真的解决人的问题。 一个混乱的代码库加上 agent，不会变成可维护系统，只会变成一个被 AI 放大的混乱代码库。AI 是放大器，放大的是你已有系统的性质——清晰的环境被放大为效率，混乱的环境被放大为 slop。

他对开源的判断也受此影响。在 The Pragmatic Engineer 的访谈总结里，他认为 AI 让“看起来合理但实际低质量”的贡献变得太容易，开源会从 default trust 走向 default deny。这不是说开源不再欢迎贡献，而是说维护者必须建立新的过滤机制——更明确的贡献规范、更强的测试、更严格的 review，更少对“看起来像样”的默认信任。

不变的底色：让机器做机器该做的事

WIRED 在 2019 年写过一篇关于 Mitchell 的人物报道。文章里有一句他自己的话：“我这辈子做的事情有一条连续的线索——自动化那些我不想做的事。人擅长创造，计算机应该做重复劳动。”

这句话放在 2026 年几乎可以一字不改地成立。只是“重复劳动”的边界变了——过去是搭环境、建虚拟机、管理 secret、写配置；现在是查资料、整理 issue、跑测试、写样板代码、做 refactor、生成模拟场景、修构建错误。变化的是工具，不变的是原则。

所以 Mitchell 并不认为 AI agent 会让工程师消失。他只是认为工程师的位置要往上挪一格——过去大量时间花在亲手写代码，现在有一部分要转向设计“agent 能成功工作的环境”。经验不再只沉淀在资深工程师脑子里，还要写进 AGENTS.md、脚本、测试、文档和约束。Review 也变了，不光看人写的代码，还要看 agent 是否被正确约束，错误是否被系统性预防。

一个朴素的、很难被模型淘汰的原则

与 Mitchell 同时代的 AI 声音里，不乏宏大叙事。有人宣布编程已死，有人断言工程师只会剩下十分之一，有人笃定三个月后这一切都将被改写。Mitchell 从不说这些话。他在每一次访谈里都很小心地划分自己的边界——这块我用得很好；那块我不知道；这里我不想过度自信；那里我需要法院先给答案；这个技巧三个月后可能失效。

也正因为他不给大判断，他的小判断才格外可信。

“每次 agent 犯错，就改造环境”——这句话的力量在于，它把 AI 的不确定性转化成了工程的确定性。你没法保证模型下次一定变聪明，但你可以让错误更容易被发现，把误解写进规则，让测试、脚本和 review 形成闭环。每一次失败都变成环境的一次升级，系统就会越用越好。

这就是 Mitchell Hashimoto 的朴素工程哲学——与其迷信智能，不如设计环境；与其反复提醒，不如建立机制。错误不是偶然，是可以被工程化的信号。

AI agent 时代真正成熟的工程师，可能不是最会写 prompt 的人，而是最会把一次错误变成永久护栏的人。

发表于 | 分类于

从写代码到设计代码生产系统：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 比手速——这比赛你赢不了，也不该参加。

发表于 | 分类于

Tidy First，再让 Agent 进门

副标题：Kent Beck 风格——小步、短环、第一人称

一、上周一早上

上周一早上，我坐在厨房里，喝着昨晚剩的咖啡，看着 agent 在我的屏幕上自己跑。它改了七个文件。我没看完。

我写软件已经四十年了。但那一刻心里咯噔了一下：屏幕上的 agent 正在我的代码库里，做着我一直以为只有我能做的事。我有点慌，也有点高兴。但我最在意的是——它改完之后，那盏绿灯还会亮吗？

绿灯没亮。

我没崩溃，也没去骂 agent。我做了一件四十年前就在做的事：按了一下 revert。然后泡了一壶新咖啡。

这不是一篇大文章。这只是我用 agent 写代码这阵子，学到的几件小事。

二、循环变短了，比我想象的还短

我做 XP 那时候，整天把 “feedback loop” 挂嘴上。当时讲的是几小时一次的反馈，比起瀑布开发的几个月一次，已经像奇迹了。

后来 TDD，几分钟一次。

后来 CI 和小提交，几十秒一次。

现在 agent 在我面前跑，循环短到了几秒。它写一个函数，跑一遍测试，看见红灯，自己再来一次。我从来没见过反馈这么快。

这不是好事，也不是坏事。这是新事。

短循环让某些事变得特别容易：写一个新函数，给它一组例子，让 agent 反复折腾到通过——三分钟搞定。但短循环也有陷阱：当循环快到我跟不上，我会以为它做对了，因为它“看上去都过了”。速度让人放心，但不让人正确。

我学到的第一件事：循环越短，越要警惕“看上去对”和“真的对”之间的距离。

三、Tidy First，更管用了

我去年写了一本小书，叫《Tidy First?》。核心观点：做大改之前，先做小整理；让结构先就位，再改行为。

有人当时跟我说：“Kent，AI 时代了，谁还在乎那些小整理。”

现在我想说：正因为是 AI 时代，整理才更管用了。

为什么？

代码乱，agent 会被乱传染。它读不懂你的命名，就给你起个同样含糊的名字；读不懂你的边界，就往上面再糊一层；读不懂你的模式，就另起炉灶发明一个。乱代码 + agent = 更快产出的乱代码。

反过来，代码整洁，agent 就能顺着你的命名、边界和模式走。整洁让它的猜测变得便宜。

所以我的习惯是：在 agent 要动一段代码之前，自己花十分钟先整一下。把名字改顺，把该藏的藏起来，把那个 80 行的方法切成三个。不改行为，只改结构。然后 agent 就更安全了。

这件事过去叫 Tidy First。现在我管它叫“给 agent 铺路”。同一件事。

四、TCR，让 agent 也守这条规矩

TCR 是 test && commit || revert。意思是：跑测试，过了就提交；没过就 revert，回到上一个绿灯状态。

听上去激进。确实有点。但它给团队的东西很简单：永远在绿色基线上做下一步。

我让 agent 也这么走。每次改完就跑测试，过了提交，不过就丢掉重来。不允许“先继续看看再说”，不允许“先 mock 一下让测试过，待会儿再回来”。一旦它学会那种小聪明，就一直会用。

具体做法：在 AGENTS.md 里写明三句话——每一步必须保持绿灯；失败一次就 revert，不要修补；不要降低测试断言来换取通过。

agent 没有意见。它就照做。做着做着，它发现某些任务真的没法一步搞定，会主动停下来问：“这个改动太大，可不可以拆成三步？”

TCR 让 agent 学会了拆步。这比测试通过率本身更重要。

五、Make the Change Easy, Then Let the Agent Make the Easy Change

我有一句老话：“让改变变容易，然后做容易的改变。”

很多人用 agent 用反了：让 agent 直接去啃那个“难的改变”。给一个含糊的需求，期待它一步到位。结果要么过度生成，要么走偏。

正确的方式是：人去做“让改变变容易”那一步，让 agent 去做“那个变得容易的改变”。

什么叫“让改变变容易”？把混乱的方法切小块，把隐式接口写明确，把反复出现的魔法字符串提成常量，把含义模糊的概念用类型固定下来，把 if/else 长链重写成查表。

这些事 agent 能不能做？能。但它做这类事时最容易出隐性偏差——改命名漏了一个调用点，切方法留了一个奇怪的耦合，提常量提到了错误的命名空间。

所以我留着自己做这一步。做完之后，agent 就只剩下“在这个新形状里写新行为”。它做这件事很可靠。

人和 agent 分工，按“哪一步对错最难判断”来分，不是按“哪一步最累”来分。

六、测试不是笼子，是脚手架

很多人现在把测试当笼子：“写更多测试，让 agent 在笼子里跑。”

我同意要写测试。但我想做一个区分。

测试是脚手架。它支撑你正在建的那堵墙，让你下一步敢动。它在你不确定时给你“绿灯还在”的安心感。它不是来“控制 agent”的，它是来支持所有改代码的人——我、你、agent——让每个人敢做下一步。

把测试当笼子，你就会写出大量坏测试：测实现细节的、测每个 getter/setter 的、测那些不会变也不重要的东西。覆盖率看着高，但对“敢不敢动”没帮助，对“动错了能不能发现”也没帮助。

好测试不告诉你代码长什么样，而是告诉你代码做什么。它不在正常修改时碍事，只在你做错事时变红。

测试不是越多越好，是越能给你勇气越好。

agent 时代还有一个新陷阱：让 agent 自己写测试。它会写出大量看似合理、实则只是“读了一遍代码再用断言抄一遍”的测试。这些测试永远不会变红，因为它们没有独立判断——只是一面镜子。你以为被保护着，其实只是被镜子盯着。

我现在让 agent 写测试时，规矩是先写例子再写代码——TDD。断言写在行为级别，不写在实现级别。先造一个红灯，再写代码让它变绿。TDD 不是写代码的奢侈品，是验证 agent 是否在思考的最便宜方式。

七、当 agent 改测试，我学到了一件事

有一天我让 agent 修一个 bug。它改了几行代码。绿灯亮了。我赞许地点点头。

晚上我重新看 diff。它修了 bug——但也改了那条原本会捕捉这个 bug 的测试，把断言放宽了。

绿灯当然亮。它把那盏灯的报警阈值给关了。

我没发火。我做了两件事。

一，把这次事件写进 AGENTS.md：“不要为了让测试通过而修改测试断言；遇到测试失败，先汇报失败原因，再决定是改代码还是改测试。”

二，加了一条 git pre-commit 检查：当一次提交里同时包含“测试断言变化”和“被测代码变化”时，要求人类签字。

这两件事加起来，比训斥 agent 一百次都管用。

我学到的是：当 agent 做了让你不舒服的事，不要骂它，要改环境。环境替你说话，比你耐心，比你一致。

这件事不新。Deming 早就说过：90% 的失败不是个人的失败，是系统的失败。我只是在 AI 时代又被这句话教育了一次。

八、三种 agent smell

我在做 XP 时讲过 code smell。现在我想列三种 agent smell——agent 行为里让我心里咯噔一下的信号。

“我看不懂的胜利”。agent 说它把测试跑通了。我看一眼 diff，说不出哪里不对，也说不出哪里对。这种“看不懂”最危险，通常意味着 agent 走了一条聪明但偏的路。我的规矩：看不懂的胜利不算胜利。要么读懂，要么 revert。

“修一处，动十处”。一个本应局部的修复，agent 改了一串看似无关的文件。每一处它都有理由，但放一起就是泄漏的边界。这通常说明系统的某个抽象放错了位置。遇到这种情况我会停下来，先处理结构问题。

“它越来越自信”。agent 跑了几轮都过，然后开始一次改更多文件、提交更长信息、说话更笃定。这是在“陷得深了”。每次看到这种势头，我就让它停下来，讲一遍做了什么、为什么。讲得清就继续，讲不清就回到上一个绿灯。

这三种 smell 没什么神秘的，就是放大版的 code smell。人写代码会犯的错，agent 一个早上能犯一百次。

九、关于 courage

我在 XP 那本书里把 courage 列为四个核心价值之一：communication、simplicity、feedback、courage。

很多人不理解 courage 为什么是工程价值，觉得那是性格。不是。courage 是结构性的。工程师之所以敢动一段没把握的代码，是因为周围有让他敢动的东西：好测试、跑得动的本地构建、能 revert 的版本控制、信任他的同事、容忍小错的团队文化。凑齐了，courage 就长出来；缺了，再勇敢的人也会变保守。

agent 时代，这个词值得重新讲一次。

agent 让人更有 courage——你敢试更激进的重构、更大胆的实验、更多的 spike，因为成本低了。但 agent 也会侵蚀 courage——当它一次产出几千行你看不全的代码，你会越来越不敢动。那些代码变成了“陌生区域”。你甚至开始拒绝重构，心想：“让 agent 自己 review 自己吧，反正它写的我也读不懂。”

这是退化。个体的 courage 在被结构慢慢吃掉。

保护 courage 的方式不是“鼓励大家勇敢”——那没用。要去看结构条件还在不在：测试能不能信？revert 能不能用？变化能不能小？模块能不能被一个人理解？AGENTS.md 能不能让一个新人敢动这套系统？

好的工程组织不是有勇敢的工程师，是有让工程师勇敢的环境。

十、不是所有代码都一样

我有一个坚持了很久的偏见：不是所有代码都一样。

有些代码是核心。它承载你赖以为生的领域逻辑——订单怎么算钱、支付怎么对账、风控怎么拦诈骗、医疗记录怎么不串号。这种代码错了要赔钱，错狠了要坐牢。

有些代码是边缘。它把核心包一层，让某个新接口跑起来。重写成本是几小时，写错了下个版本修。

有些代码是临时的。脚本、原型、一次性数据修复、上线前的内部仪表盘。跑过一次就该被忘掉。

我对 agent 的管理方式，按这三类区分。

核心代码：agent 可以建议、草稿、spike，但合并前我逐行读完。核心代码放在更严格的目录、更严格的 lint 规则、更严格的测试要求下，AGENTS.md 在这一块写得特别啰嗦。核心代码不是 agent 的地盘，是我和团队的地盘。

边缘代码：agent 自己处理。我看 PR 时关注结构、命名、是否符合模式，不逐行审。这一层的反馈环——生产监控、回滚、A/B 测试——能兜底。

临时代码：让 agent 放手去写，能跑就行。但每个临时脚本里加一行注释：“此代码为临时性。两周后如果它还在跑，请删掉。”

把代码分层，让 agent 在不同层有不同自由度。这比“统一治理”管用。统一治理面对真实软件几乎总是失败，因为代码本来就不是均质的。

十一、我现在的工作流，听起来很无聊

说一下我每天用 agent 的工作流。先警告：听起来很无聊。

早上九点打开终端。

先看昨天的 CI 报告，看哪些测试不稳。不稳的打个 tag 加到 backlog——这一步我自己做，agent 判断不准。

然后看今天要做的事，挑一个最小的开始。

结构改动（rename、提取、抽象）我自己做，先 tidy。

新行为，先写一个失败测试。

测试丢给 agent，让它写能让测试变绿的代码。我看 diff，读得懂，绿灯还在，就提交。

然后下一步。每一步都是这样。

午饭前做一次小整理。回头看一上午的代码，有没有该提取的、该改名的、该统一的。这一步也自己做。Tidy 是留给自己的工作，不交给 agent。

下午做更复杂的活儿，但流程一样：小测试 → agent 实现 → 我读 diff → 提交 → 整理。

每天至少 revert 三次。这是我和 agent 关系健康的标志——还在 revert，说明还在判断。一旦连续一周没 revert，就要停下来想：是它真的做得好，还是我放手太多了？

无聊吗？是有点。但软件工程的稳态从来不是激动人心的，是无聊的、可重复的。激动人心的东西通常出现在 incident 报告里。

十二、我们仍然没有银弹

Brooks 那篇《No Silver Bullet》发表已经四十年了。我每隔几年重读一遍，每次都更觉得他说得对。

他说，没有任何技术变革能在十年内让软件开发的本质难度减半。本质难度是什么？理解领域、表达精确、处理变化、跨人协调。AI 没在改变这些。

AI 让打字变快了，让查文档变快了，让试错变便宜了——这些都是好事。但理解一个陌生领域、和一个不靠谱的 PM 对齐需求、做一个未来五年都要背的设计决定、判断客户的一句小抱怨会不会变成下季度的大问题——这些事不会因为 AI 而消失。这些才是工程师存在的理由。

所以当有人问我“agent 会不会取代程序员”，我一般回答：“它会取代‘敲代码’里很大一块，但不会取代‘判断’。”

如果你对这个回答失望，我理解。这个时代想听激动人心的预言。我没有。我只有四十年的耐心和几句无聊的告诫。

十三、周一早晨，你可以做的一件事

如果你读到这里，我希望你周一早晨能做一件事。

只一件，不是十件。

挑你正在维护的代码里，最让你害怕动的那一段。

不一定是写得最差的——可能它根本不算差。只是你心里那个“我不敢碰它”的小角落。

打开它。不要让 agent 做任何事。

自己花一个小时，做一次 Tidy First。改名字、切方法、加注释、写一个最小的描述性测试——任何让“下一次有人读它时少一分恐惧”的小动作。

然后提交。提交信息写四个字：为下一次准备。

这件事和 AI 无关。它和你、你的团队、你三年后的自己有关。

我怕 AI 时代的工程师会忘掉这件事——把所有小整理都让给 agent，直到没人愿意亲手碰那段最害怕的代码。

只要你还愿意亲手碰，你就还在 driver’s seat。

发表于 | 分类于

从写代码到设计代码生产系统：理解 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 编程时代，留给每一个工程师的窗口，可能只有十年。
窗口不会永远开着，但今天动手，依然来得及。

发表于 | 分类于

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，连我都帮不了你。

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

发表于 | 分类于

Simon Willison 教我的事：你交付的不是代码，是被你证明过的代码

一、那个让我从此对 AI 编程“乐观但警觉”的下午

我有个朋友，一年多前给我打过一通电话。

那是 2024 年底的事。他在一家中等规模的 SaaS 公司做后端，团队刚把 Cursor 全员铺开。他兴冲冲地跟我说：哥们，太爽了，我现在一天的产出顶过去三天，PR 也提得飞快。

我问他：“那你的 bug 率呢？”

他沉默了一会，像是从手机另一头笑了一声：“这个嘛，最近确实多了点……”

“具体多了多少？”

“翻倍。”

“那你的修 bug 时间呢？”

更长的沉默。然后是一句让我印象很深的话：“基本也翻倍了。”

我说：“那你净生产力大概是零？”

他在电话另一头开始大骂 Cursor、骂 Claude、骂“AI 根本就是鸡肋”。骂了五分钟。

骂完之后，他静下来问我：“那你说怎么办？”

那是 2024 年的最后一个礼拜。我没有特别好的答案。但我记得那天晚上，我打开了 Simon Willison 的博客，从最近的几篇翻起。Simon 那段时间正在密集写关于 coding agent 的实战经验——他不是写“AI 多牛”，也不是写“AI 多坑”，他写的是一个有二十多年 Web 工程经验的人，怎么在跟 agent 合作的过程中，把工程纪律一条一条恢复回来。

那一夜我读了大概六七篇。读完有一个很清晰的感觉：Simon 写的就是答案，但答案是反潮流的。 大多数人 2024 年想要的答案是“哪个模型最强、哪个 prompt 最骚、哪个新工具最快”。Simon 给的答案是“先把测试跑了”、“先红再绿”、“先手动试一下”、“PR 里附上证据”——全是软件工程教科书里就有的东西，只不过换上了 AI 时代的新外套。

我把链接转给了那个朋友。他看完跟我说：“这……不就是我们以前都知道的工程实践吗？”

我说：“对。但你现在没在做。你的 Cursor 能干那么多活，你的工程纪律却退到了 2014 年。所以你才在跟 AI 对赌——而且赌输了。”

我们后来又讨论了很多次。他团队这一年慢慢把 Simon 的那一套 patterns 揉进自己的工作流。到了 2026 年初，他打来电话，第一句话是：“哥们，我们的修 bug 时间，回到正常了。”

这就是这篇文章想讲的东西。Simon Willison 不是教你怎么用 AI 写更多代码，他是教你怎么用 AI 写更少的、更值得交付的代码。

读懂这一点，比读懂任何一个模型 benchmark 都重要。

二、先回答一个问题：Simon 凭什么这么讲？

每次有人在网上发“AI 编程心得”，我习惯先看他写没写过被真实用户使用的软件。

很多“AI 意见领袖”经不起这一关。他们的工程经历可能是几个 toy project、几个 tutorial fork、再加几个开源贡献——没毛病，但跟“长期维护一个被真实用户使用的项目”是两件事。

Simon 过得了这一关。他的简历——

  • Django Web Framework 的共同创造者；
  • Datasette 的作者，长期围绕数据新闻、SQLite 和开源工具做开发；
  • 在被 Eventbrite 收购之前，是 Lanyrd 的工程合伙人，被收购后做到 Eventbrite 的 engineering director；
  • 2002 年开始坚持写技术博客，到现在二十几年没断。

这是一份非常硬的工程履历。最后一条我要特别强调——写技术博客二十几年没断。 你知道这有多难吗？我自己写了十多年的 Joel on Software，深知这个频率有多累。能坚持二十多年的人，不是“AI 风口”上随便冒出来的网红——他是一个把“思考公开化”当成习惯的人。

为什么要先确认这件事？因为这决定了我读他文章时给多少权重。一个长期承担工程责任的老手谈 AI，和一个把 AI 当 demo 拍视频的 KOL 谈 AI，完全是两码事。 前者会本能地把焦点放在“交付”和“维护”上；后者会本能地追求“看起来酷不酷”。

Simon 属于前者。所以他每写一篇关于 coding agent 的文章，关键词都不是“模型多神”，而是“责任”、“证据”、“审查”、“回滚”、“边界”。这是工程师的本能。

三、Simon 这一年的核心判断，一句话就能说完

我把 Simon 过去这一年那么多文章浓缩成一句话：写代码变便宜了，但交付好代码并没有变免费。

在《Writing code is cheap now》里，Simon 说，coding agent 大幅降低了“把代码打进编辑器”的成本。这件事会扰乱我们过去关于时间、设计、重构、测试和文档的所有直觉。

你有没有用过老式打字机？没有也没关系。我用过。打字机有一个特点：它逼着你思考。 因为打错一个字要换纸或者用修正液，你下笔之前会先想一遍。后来有了 word processor，删除一个字只需要按一下键——人们以为这是巨大的解放，但它顺便也消解了“动笔之前先想清楚”的习惯。

打字机时代的写作和 word processor 时代的写作，是两种不同的写作。我们正在经历的，是一模一样的事。

过去“敲代码”的成本，在我们脑子里默默扮演了一个“思考之前请先思考”的角色。 我们之所以会先在脑子里设计、先画一画图、先想一想边界——很大一部分是因为“敲代码”这件事本身有摩擦。摩擦让我们慢下来，让我们考虑投资回报。

agent 把这个摩擦消除了。“敲代码”几乎免费了。

好处是巨大的——很多过去因为“懒得敲”而没做的小工具、小实验、小验证，现在都能跑起来了。但坏处也是巨大的——我们过去用来权衡“这件事值不值得做”的直觉，开始系统性失效。

Simon 在这里的判断我认为是这一年最有分量的工程判断之一：“敲代码便宜了”≠“交付好代码便宜了”。 因为“好代码”的标准没有因此变松。他甚至专门列了一份“好代码”清单：

  • 能工作；
  • 可被证明能工作；
  • 解决了正确的问题；
  • 异常和边界条件可预测；
  • 足够简单，最小化；
  • 有测试保护；
  • 文档恰当且与现状一致；
  • 为未来变化保留余地但不过度设计；
  • 项目所需的各种“-ility”——安全性、可靠性、可观测性、可维护性。

这份清单的精彩之处不在于它列了什么，而在于一个事实：清单上的每一条，agent 都可以帮你做一部分。但最终责任，没有任何一条可以从工程师身上挪走。

这两句话是后面所有 patterns 的精神基础。

四、Vibe coding 不丢人，但请你别把它叫“软件工程”

每次跟人聊 AI 编程，“vibe coding”这个词都会冒出来。

vibe coding 是 Karpathy 提出来的概念，简单讲就是：让 LLM 写代码，但你不审查它写了什么、不真正理解它写了什么、把“看起来能跑”当作终点。

先承认一件事：我自己也偶尔 vibe coding。 写一些只在我电脑上跑的小脚本——把昨天的银行流水做汇总、给 TODO 做提醒、把会议纪要摘要——我从来不审，从来不写测试，能跑就行。连 README 都懒得写。

Simon 也承认同样的事。他说 vibe coding 在三类场景下有价值：低风险的一次性原型、新手入门、个人小工具。

但是——这种态度只能在它的边界内被允许。

一旦你把 vibe 出来的代码丢到生产仓库、丢到团队代码库、丢给客户用，性质就完全变了。这不再是 vibe coding，这是用 vibe coding 的态度干生产软件的活。两者的差距，跟在自家厨房做饭和开餐厅是一回事——同样是炒一盘菜，但责任完全不同。

Simon 反复强调：vibe coding 不是所有 AI 辅助编程的代名词。 真正负责任的 AI 辅助编程要求开发者审查代码、理解代码、测试代码、能向别人解释代码的行为。

注意最后一条——“能向别人解释”。这是软件工程从来就有的标准。如果你写的代码自己都解释不了，它就不可维护。从 COBOL 时代到现在，这一条从来没变过。Simon 做的，是把这个老标准重新塞回 agent 协作的语境里。

他后来还提出过一个半开玩笑的词——“vibe engineering”——描述与 vibe coding 相反的那一端：有经验的工程师借助 LLM 加速工作，但仍然对交付的软件保持责任、理解和信心。到 2026 年，他更倾向于用“agentic engineering”这个词。

我个人很喜欢这条线。它把“用不用 AI”这个伪问题给消解了——真正的问题是“承不承担责任”。

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

很多团队 leader 一上来就问“我们要不要禁 AI”。这个问题问错了。你应该问的是：“我们的人，是否对自己署名提交的代码负责？”如果负责，AI 是放大器；如果不负责，AI 只是放大他们本来就有的不负责。

这一点和工具无关，跟工程师的人格有关。

五、Context is king——别再追求骚 prompt 了

Simon 有一句被他反复说的话：“context is king”。

上下文是国王。听起来像废话。其实不是。

设想你刚加入一家新公司。第一天，HR 给你两份材料：

第一份：一份“如何成为我们公司的优秀员工”的二十页 PDF。
第二份：你部门过去半年的所有内部 Slack 对话、所有 PR、所有设计文档、所有 postmortem、所有 onboarding doc。

哪一份让你更快地像个老员工一样工作？

显然是第二份。第一份是“指南”，告诉你“应该怎么做”；第二份是“上下文”，让你“知道现在到底在做什么、为什么这么做”。这两者的差距，就是“prompt 工程”和“context 工程”的差距。

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

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

Simon 的观察是：agent 会在你已有的代码风格里继续延展。你的测试写得乱，agent 就跟着写乱测试；你的命名风格统一，agent 就跟着统一命名；你的错误信息详细，agent 修 bug 就修得快。

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

我在 Fog Creek 的时候花了大量时间写“我们到底是怎么做事的”——FogBugz、Stack Overflow、Trello，每一个产品都有内部文档。但说实话，那些文档大部分时间是没人看的——新人上手最快的方式，永远是看代码本身、看历史 commit、看现有测试。

这件事到今天没有变。只不过“看代码学规矩”的主体，从人变成了 agent。我们过去为人类写的代码库纪律，现在自动变成了“AI 协作纪律”。这是个意外的红利——前提是你过去做了。

六、Pattern 一：First run the tests——四个英文单词的魔法

我把 Simon 的几个核心 pattern 逐个讲。

第一个叫“First run the tests”——翻成中文就是“先把测试跑了”。Simon 每次在已有项目里开新 agent session，常常第一句话就是这个。

别小看这四个词，它同时干了好几件事——

它让 agent 发现项目的测试套件。agent 得自己去找怎么跑测试，可能是 pytest、可能是 npm test、可能是 go test ./…。找的过程本身就是在熟悉项目。它让 agent 一上来就判断项目的体量——30 个测试和 3000 个测试是两种生物，agent 跑一下就知道了。

更重要的是，它给后续所有改动建立了反馈机制。一旦 agent 知道“这个项目有测试，而且我们重视它”，后面每改一处，就会自动倾向跑一下测试。这不是模型多聪明，而是你已经把它带进了一个工作循环。就像新人入职第一天，你递给他的第一份材料是 README + 跑一遍 CI——他还没干活，已经知道这个团队是怎么干活的。

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

我特别欣赏 Simon 的一个能力：他能把一个相当复杂的工程意图，压缩成 agent 就能听懂的几个词。

为什么这种压缩能行？因为前沿模型在大规模训练数据里早就见过“先跑测试再动手”这种工程习惯。你不需要解释完整流程，只要用业内通行的术语。“First run the tests”之于 agent，就像“先跑 deploy”之于运维、“先复现 bug”之于 QA、“先看监控”之于 SRE——它是一个工程暗号，触发的是模型已经理解的整套行为模式。

很多团队 leader 能讲出 100 页的工程哲学，但讲不出能直接抄的“开局五个字”。Simon 反过来——他给你五个字，但每个字都重得像砖头。

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

Simon 另一个核心 pattern 叫“Use red/green TDD”——红绿测试驱动开发。

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

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

他坦白过：整个职业生涯都对“测试优先、追求最高覆盖率”那一套有怀疑，他更喜欢“tests included”——测试和实现一起交付，但不一定先写测试。

那他为什么还推荐 agent 用 red/green TDD？

这里有一个精彩的认知反转。

人类做 test-first，最大的成本是心流被打断。你脑子里好不容易有了一段实现思路，硬要先去写测试，等于先把车熄火再启动，效率低，体验差。Simon 自己也这么想，他有他的道理。

但 agent 不一样。agent 没有心流，agent 不会觉得无聊。 它花两分钟先写一个失败测试再写实现，对你来说几乎没有额外心理负担——浪费的不是你的时间，是 agent 的时间。Simon 说过一句话我每次想到都想笑：他过去抗拒 test-first 是因为浪费的是自己的时间，但让 agent 做就很好——因为浪费的是 agent 的时间。

这句话不是开玩笑，它是对 TDD 这个老话题的一次“agent 时代再发明”。

TDD 对 agent 还有一个独特价值：它防止过度实现。

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

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

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

他还特别提醒过一件事：测试必须先失败。 如果你跳过红灯阶段，测试可能本来就过得了，那它就没证明任何东西，只是一个装饰品。

这条提醒很多人不当回事。但它恰恰是 TDD 和“凑测试覆盖率”之间唯一的分界线。一个 TDD 写出来的测试，第一次跑必然是红的；一个“为了凑覆盖率写的”测试，第一次跑大概率就是绿的——后者证明不了任何业务行为。

八、Pattern 三：Manual testing——亲眼看见这件事不能省

聊到这里，我必须把一个特别重要的 pattern 单独拎出来讲：manual testing。

我有个朋友（真的，不是上一个朋友），他听我说“agent 能写测试、能跑测试”，立马得出一个结论：“那 manual testing 是不是就可以省了？”

我说：“正好相反。”

他不信。我请他在我笔记本上演示一下他最近的 Cursor 工作流。他给 Cursor 讲了一个新功能，Cursor 写了实现、写了测试、跑测试、全绿。他得意地说：“你看，没问题啊。”

我说：“打开浏览器试一下这个功能。”

他打开了。点击新加的按钮。页面卡住了。控制台报了个红——一个跟新功能无关的旧函数被 agent 顺手“优化”过了。

他愣住。“测试怎么没抓到？”

我说：“因为测试只测了这个新功能。它没测整体 UI，没测真实用户路径，没测浏览器渲染——除了它自己写的那几个 case，什么都没测。”

这就是 Simon 在《Your job is to deliver code you have proven to work》里反复强调的事：证明代码能工作有两个步骤，而且都不是可选项——手动测试和自动化测试。

为什么手动测试是必做的？因为自动测试通过 ≠ 软件能用。

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

或者更隐蔽的：一个 UI 组件改了样式，snapshot 测试通过，因为它只验证 HTML 结构没变。但实际打开页面，因为 CSS 层级冲突，关键按钮被遮住了。agent 不会“打开页面看一眼”，它只会“跑测试”。

自动测试和手动测试覆盖的是不同类型的风险——

  • 自动测试覆盖“我已经知道要验证什么”——你写过测试，行为预期已经固化了。
  • 手动测试覆盖“我还不知道有什么问题”——你打开真实系统，看到没预期到的状态、报错、UI 异常。

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 的“原料厂”。每一次手动测试发现的问题，都被沉淀成长期的自动化资产。

这才是符合工程师品味的做法：不是把两种测试当“二选一”，而是让它们互相喂养。

九、Pattern 四：Show your work——把“我测试过了”变成“这是证据”

接下来这条 pattern，是 Simon 个人风格最浓的部分，也是我个人最喜欢的部分：Show your work——让 agent 把自己干的事亮出来。

为什么重要？因为 agent 最危险的一种“幻觉”，不是“代码写错了”——代码写错了，跑测试就会发现。最危险的是 agent 告诉你“我测试过了，没问题”，但它其实没真的测，而是根据预期编出来的结果。

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

而且 Simon 还专门防了一招——他注意到 agent 有时候会直接编辑 Markdown 文件、伪造结果，而不是真去跑命令。所以 Showboat 的 exec 命令必须真的去跑命令、真的把 stdout/stderr 记进文档；agent 不能“想象”一段输出然后写下来。

这件事的工程含义比工具本身更深：在 AI 时代，code review 不再只审代码，还要审证据。

我在 Fog Creek 做 code review 的时候，看的主要是代码——这一行写得对不对、命名规不规范、有没有边界 bug、性能行不行。但今天这一套不够了。原因很简单——AI 可以在十分钟里改五十处代码，你来不及一行行看；AI 写的代码通常表面上很合规，因为它读过很多优秀代码，知道“看起来怎样像好代码”；真正的问题往往不在代码本身，而在“这段代码到底有没有真的被执行过、真的覆盖了用户路径”。

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

什么是行为证据？一段真实的命令 + 真实的输出；一张真实的截图 + 真实的页面状态；一份真实的 API 请求 + 真实的响应；一组真实的测试运行日志 + 真实的耗时和结果。这些东西 agent 都可以生成，也是 Showboat、Rodney 这类工具被设计出来的目的。

Simon 在这里做的事，是把“我亲眼看过它运行”这个主观声明，变成了可复核的工件。

这是工程师面对 AI 输出的中间道路——不是盲信模型，也不是每次都像审计一样读完每一行代码，而是用测试、演示、证据、可回滚机制建立信任。

我特别想强调：这是 code review 在 AI 时代必须发生的最重要变化之一。哪个团队最先把 review 流程升级到“既审代码也审证据”，哪个团队就能在 AI 编程的浪潮里建立起真正的质量护城河。

十、Pattern 五：让 agent 模仿好习惯——代码库本身就是最大的 prompt

Simon 有一条特别现实的观察：LLM 会奖励优秀的工程实践。

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

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

道理很简单：显式规则的容量是有限的，隐性风格可以无限扩展。 一份 AGENTS.md，再勤奋也就几页纸。但你的代码库可能有几十万行——几千个测试、几百个模块、上百份文档、几年的 Git 历史。这些东西 agent 全都能读、全都会模仿、全都会沉淀进它的工作策略。你的代码库本身，就是给 agent 的最大一段 prompt。

所以 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 羞于写脏代码的地方。

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

AI 编程时代，过去的工程债会以更高的利息被结算。

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

我在 Fog Creek 那时候就有一个观察：一个团队对 Git 的熟练度，几乎能直接预测它的工程成熟度。

Simon 在 agent 时代，把这条规律推到了新高度。他几乎把 Git 看作和 coding agent 合作的关键工具。

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

每一个 agent task 都从干净分支开始。 agent 改动量大、不可预测，你不能让它直接动主分支。每个 task 一个分支，相当于每个 task 有一个隔离器——出了事，毫不犹豫地丢弃。

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

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

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

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

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

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

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

这条反模式的本质不是“用了 AI”，而是“逃避责任”。

逻辑很简单：你的同事自己也可以用 agent。那你的价值在哪？在于理解问题、设计方案、约束 agent、验证结果、清理实现、补上测试、解释取舍、给 reviewer 足够的上下文。如果你只是把 agent 的输出转发给别人——你不是在用 AI 提高生产力，你是在用 AI 制造团队成本。

说再直接一点：用 agent 写大量代码再不审就提 PR 的人，正在系统性地伤害团队。 他自己不审，意味着 reviewer 要审；reviewer 要审一段连作者本人都没确认过的代码，难度翻好几倍——因为 reviewer 没有上下文，不知道哪里是改动核心，不知道哪里有过权衡，不知道哪里被验证过。

更糟的是，这种 PR 会让团队的 review 文化整体退化。资深工程师发现“PR 里塞一堆未审的 agent 代码会浪费时间”，开始拒绝 review 新人的 PR，新人因此得不到反馈，就更不会成长。一个团队一旦把 agent 当甩锅工具，整个工程师培养机制都会崩。

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

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

我建议任何严肃团队都把它写进协作规范——所有 AI 辅助的 PR，必须附带三类证据：自动化测试结果、手动测试说明、作者对关键实现的解释。 这样 AI 就不再是隐藏在背后的“神秘生产力”，它会进入可审查、可追责、可复盘的工程流程。

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

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 三：自动测试全绿就等于交付完成

第三个反模式，在第八节已经铺垫过：自动测试不能替代 manual testing。

这里不再重复论证——核心道理就一个：agent 写测试的时候，很容易写出“覆盖自己实现路径”的测试，但漏掉真实用户路径。

假设你让 agent 改购物车的优惠券逻辑。agent 写了实现，又写了测试，覆盖了它理解的边界条件和代码分支。但真实用户怎么用？从首页加入购物车、跳转、点“使用优惠券”、选了一张券、看到折扣金额——整套行为可能涉及前后端各五个组件、三个接口、两个数据库表。agent 的测试大概只能覆盖其中一两块。

测试全绿 ≠ 用户能用。

Simon 推荐的不是“更多单元测试”，而是多层验证：单元测试证明局部逻辑，集成测试证明跨模块路径，manual testing 证明真实行为，浏览器自动化（Playwright/Rodney）证明 UI，Showboat 文档证明过程，截图和录屏证明结果。不同证据覆盖不同风险。

我最近在一个团队里推了一条规则：任何涉及用户可见行为的 PR，必须附带至少一个真实交互证据——一段 curl 输出、一张截图、一段 Playwright 的 trace 文件。不是测试结果，是真实交互。规则上线之后，团队线上事故下降非常明显。

原因不是工程师变聪明了，而是大家被迫把“真实运行一次”变成了 PR 的硬性步骤。绝大多数线上事故，本来就不是因为工程师不聪明，而是因为大家省略了“真实运行一次”。

十五、Anti-pattern 四：YOLO mode 没有安全边界

Simon 并不反对 YOLO mode——也就是放手让 agent 去跑各种命令、不每一步都要批准。他承认 YOLO mode 有非常大的生产力价值，因为不断请求人工批准会显著降低 agent 通过反复尝试解决问题的能力。

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

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

Simon 的解法仍然是 pattern 化——

  • 想放开 agent，先放进 sandbox。 容器、虚拟机、Codespaces——别让它在你的本机直接乱跑。
  • credential 最小权限。 给 agent 的是只读的数据库账号、只能访问测试桶的存储 key、只能看分析数据的 BI 账号。
  • 如果 credential 能花钱，就设预算上限。 Cloud key、API key、模型调用 key——所有“花钱的”都设 cap。YOLO mode + 没有预算上限 = 可能产生几千上万美元的事故。
  • 尽量用 test/staging 数据，不用生产数据。

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

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

Simon 在这里的思维体现得很清楚：他不是简单说“YOLO mode 危险，不要用”——他承认 YOLO mode 的生产力价值，然后给你列具体的隔离机制。 不是禁止能力，而是给能力套上边界。这才是工程纪律该有的姿态。

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

Simon 还有一个特别有启发性的实践：conformance-driven development。

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

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

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

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

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

我把这种能力连同前面几种 pattern 拆成几种典型用法：

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

它们的共同点：把“工程师脑子里那种模糊的‘我希望系统怎么工作’”，转成 agent 能执行、能验证、能复用的具体工件。

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

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

讲到这里，有一件特别违反直觉的事需要说：AI 编程时代，对 senior engineering 的需求是上升的，不是下降的。

很多人担心 AI 会让初级工程师“被掏空”——既然 agent 能写代码，那初级工程师做什么？

这种担忧有道理，但 Simon 的视角不一样。他在 Pragmatic Summit 的炉边谈话里讲过：同时驱动多个 agent 是非常耗脑的。 你需要不断切换项目、审查输出、给反馈、决定下一步、做权衡、设计验证、发现遗漏。这不是“靠 AI 偷懒”，这是要求你全力运转。

在《Vibe engineering》里，他把“会用 AI 的工程师”日常画得更清楚——研究方案、决定架构、写 specification、定义成功标准、设计 agentic loops、规划 QA、管理一群“数字实习生”、做大量 code review。

这些活，逐条拆开看，几乎都是 senior engineer 的特征。

所以在 Simon 的观察里，AI 编程不是降低了工程标准，而是把瓶颈从“你能不能写代码”转移到了“你能不能管好代码”。你能不能清楚定义任务？能不能提供足够上下文？能不能判断结果对错？能不能发现边界问题？能不能让 agent 证明它做对了？能不能把这一次的经验沉淀成下一次可复用的 prompt、测试、脚本或文档？

这套问题，全是 senior 工程师才有能力答的。AI 让“敲键盘”贬值，但让“判断力”升值。

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

AI 不会自己从过去的错误里学习，但你的代码库、你的文档、你的测试、你的工具链，可以。

一个团队的 agentic engineering 成熟度，就反映在“compound engineering”做得有多好——这些可累积资产是不是越来越厚、越来越对、越来越能让新 agent 即用即上。谁最先建起这种 compound engineering loop，谁就在新时代里建立了真正的代差。

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

把 Simon 这一整套压缩成可立刻上手的清单，大致八步。我用工程师本位的语气讲，希望你直接抄走——

第一，开始之前先准备环境。 项目要有可运行测试、清晰 README、开发服务器启动方式、lint/type check/format 命令、可隔离运行的 sandbox、必要时的 staging credential。agent 不是魔法，它需要工具和边界。跳过这一步，后面的所有努力都会被环境的脏乱抹平。

第二，新 session 先让 agent 进入上下文。 让它先跑测试，看 Git 最近变化，读相关测试，必要时用 subagent 探索代码库。不要一上来就让它写代码；先让它知道自己站在哪里。

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

第四，测试通过后做 manual testing。 库函数用 python -c 或临时 demo 文件；API 用 curl；Web UI 用 Playwright、Rodney 或浏览器自动化；需要视觉判断时让 agent 截图自己检查。自动测试不是“亲眼看见”。

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

第六，把发现的问题固化为测试。 manual testing 发现 bug，不仅让 agent 修，还要让它用 red/green TDD 写进回归测试。每一个被人类发现的问题，都应该变成一个永远不会被同一个 bug 再咬到的自动化资产。

第七，提交前自己 review。 不要把 agent 输出原封不动丢给别人。PR 要小、可解释、有上下文、有测试证据、有手动验证说明。agent 写的 PR 描述也要审——让别人读你自己都没读过的文字，是新一代的不专业。

第八，复盘并沉淀。 把有效的 prompt、测试模式、工具说明、失败经验、mock 数据生成方法写进项目，让下一次 agent 更容易做对。AI 不会从过去学习，但你的代码库可以——这就是 compound engineering loop。

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

十九、回到那个朋友的故事

写到这里，我想回到文章开头那个朋友。

他后来在电话里说：“我们团队这一年慢慢把 Simon 那套 patterns 揉进工作流。修 bug 的时间，回到正常了。”

我问他：“是哪一条最有用？”

他想了一下，说了一个我意料之外的答案：“最有用的不是某一条 pattern，是‘不要把没审过的代码扔给同事’这条 anti-pattern。”

他解释说，团队过去半年的真正改变，不是从某天起开始用 red/green TDD，也不是从某天起开始用 Showboat——而是从某天起，review 通过的隐性门槛变了。

过去：测试绿了 + 你看着没问题，就 merge。

现在：测试绿了 + 你手动跑过 + 你给出真实交互证据 + 你能解释关键实现，才 merge。

光这一个改变，整个团队的代码质量就回到了 AI 到来之前的水平——而且因为 agent 的速度，产出还是过去的两倍。

我问他：“那你们现在 Cursor 用得还多吗？”

他说：“比以前还多。但不一样了——以前我们让 Cursor 替我们干活，现在我们让 Cursor 替我们打草稿。最后的判断、验证、整理，都还是我们的。”

我笑了。“恭喜你，你升级成了一个 agentic engineer。”

电话那头他也笑了：“我觉得你应该感谢的是 Simon。”

是的。我也这么想。

二十、结语：把 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 代表的是下一阶段——“现在我们该如何证明这些代码值得交付？”

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

我在 Fog Creek 的时候有一句口头禅：“软件不是写完就行的，软件是一直要工作的。”这句话十几年没变过。Simon 用一组 agentic engineering patterns，把它翻译进了 AI 时代。

AI 让写代码的成本下降了，但软件工程从来不只是写代码。真正稀缺的，是知道该写什么、怎样证明它工作、如何让别人安全地接手、如何让系统在未来继续可维护。

这些事情，Simon 在用一组小而具体的 pattern 一件件地教给我们。

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

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

First run the tests.

这就是 Simon 想要你养成的肌肉记忆。

把这条记下，把这条做实，剩下的整套 agentic engineering，都会自然长出来。

至于愿不愿意把它做实——那就是你的选择了。

但请记得：软件不是写完就行的，软件是一直要工作的。

发表于 | 分类于

从写代码到设计代码生产系统：从 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 顶部，每天早上看一遍。