Agent Harness 战略：OpenClaw 与个人 AI 的层级解构

每一次平台转换，都会让某一层突然变成战略要地。

PC 时代是操作系统，Web 时代是浏览器，移动时代是 App Store 与通讯录，云时代是 IaaS 之上的 PaaS。轮到生成式 AI，过去三年大家默认的战略要地是模型本身——更大的参数、更长的上下文、更准确的 benchmark。但当模型能力的边际收益开始放缓，“模型即产品”的假设开始松动，一个被很多人忽视的层正在浮出水面：agent harness。

OpenClaw 是这一层目前最具代表性的样本。它不是又一个聊天产品，也不是又一个套壳。它是一个明确把自己定位在“模型与现实之间”的开源 harness 项目，由 Peter Steinberger（前 PSPDFKit 创始人）发起，2025 年底从一个周末 hack 开始，2026 年初突破 100,000 GitHub stars，并在短短数月内吸引了 OpenAI、NVIDIA、Microsoft / GitHub、Atlassian、Tencent 等一众玩家的资源支持。Peter 在 2026 年 2 月宣布加入 OpenAI，OpenClaw 则被放入一个独立基金会，承诺保持开源和模型无关。

这篇文章不打算再讲一遍 OpenClaw 的功能清单——它的官网已经做得足够好。我想做的是用一个分层框架，把“个人 AI agent”这件事拆开，看清 OpenClaw 站在哪一层，为什么这一层会成为战略要地，以及它会如何重塑模型公司、平台、订阅经济与开源社区之间的关系。

按惯例，我们从框架开始。

一、框架：个人 AI 的四层栈

要分析 OpenClaw 的位置，需要一个能把“个人 AI”完整覆盖的分析栈。我把它分成四层，从下到上：

层级	解决什么问题	当前的代表玩家	关键约束
L1 推理层（Inference）	模型在哪里推理，用什么参数，多快多便宜	OpenAI、Anthropic、Google、DeepSeek、Ollama 本地	能力 / 成本 / 延迟
L2 编排层（Harness）	工具调用、会话状态、记忆、权限、定时、路由	OpenClaw、Codex、Claude Code、Cursor Agent	主权 / 可观测 / 可治理
L3 入口层（Surface）	用户从哪里唤起 agent，如何接收结果	WhatsApp / Telegram / Slack / iMessage / 终端 / 浏览器	在场感 / 触达成本
L4 行动域（Domain）	邮件、日历、代码库、家庭设备、公司系统	Gmail / Calendar / GitHub / 企业 SaaS	数据敏感性 / 责任边界

这张表解释了一件容易被忽视的事情：今天大众认为的“AI 产品”，绝大多数同时塌缩在 L1 + L3——模型自带一个 chat surface，剩下两层缺位。 ChatGPT、Claude、Gemini 在用户日常生活里的渗透深度远比想象中浅，根源就在这里——它们能聊得很好，但很难“在场”，也很难“做事”。

OpenClaw 的关键洞察，是把战略重心明确放在 L2，并通过 L2 把 L3 与 L4 连起来。它做的不是另一个聊天界面，也不是另一个模型，而是一个让“任何模型”在“任何入口”中操作“任何行动域”的中间层。

我们一层一层看。

二、L1 解构：模型为什么不再是唯一的护城河

过去三年，模型公司主导了产业叙事。每一次更大的模型出来，市值、估值、人才流向都会重新分布一次。背后的隐含假设是：模型能力的差距会持续扩大，能力差距会自动转化为产品差距。

2026 年的现实正在挑战这个假设。前沿模型之间的能力差距在变窄——不同 lab 的 SOTA 模型在大多数 benchmark 上互相错位领先，差距越来越难被普通用户感知。与此同时，开源模型持续追赶，DeepSeek、Qwen、Llama 衍生模型在很多任务上已经跑出“够用”的效果，且可以本地部署。更关键的是，任务质量越来越依赖 harness 和上下文，而不是单次推理质量——给同一个模型不同的工具、记忆、prompts、反馈循环，结果差异常常大于换一个模型的差异。

这三个趋势指向同一个结论：模型仍然是必需的，但不再是稀缺的；harness 才是当下最具杠杆的一层。

OpenClaw 对 L1 的处理非常符合这一判断——它默认 model-agnostic，文档里同时支持 OpenAI、Anthropic、Google、DeepSeek、Ollama、Qwen、Z.AI 等众多 provider；用户可以按任务、按成本、按隐私在不同模型之间切换。

这种 provider abstraction 看起来只是一个工程选择，但战略意义巨大。它把模型选择权还给用户和 harness，而不是让模型公司锁定用户；它让 harness 可以利用模型公司之间的竞争——谁的推理便宜、快、稳，谁就在 OpenClaw 里被更多调用；它让 harness 自身的价值可以独立于任何一家模型公司增长。

历史上，每当一个抽象层成功把下层商品化，价值就会向那个抽象层迁移。Linux 把硬件商品化，Kubernetes 把容器主机商品化，Stripe 把发卡行 / 网关商品化。OpenClaw 在做的事情，本质上是把模型推理商品化——并不是说模型本身没价值，而是说从用户的视角，模型变成了“可替换的下层组件”。

这对模型公司意味着什么？我们后面会回到这个问题。

三、L2 解构：Harness 为什么是战略要地

把 harness 单独拎出来作为一层，是这个框架最关键的一步。

很多人会问：harness 不就是一些胶水代码吗？为什么值得单独成为一层？

答案是——一旦 agent 真的开始“做事”，胶水代码就会演化成一个完整的 runtime。工具调用系统（exec / browser / web search / file I/O / apply_patch / message / cron / image / TTS / sessions / subagents）要处理超时、重试、流式、错误、边界。会话状态管理涉及 session 文件、上下文窗口预算、工具结果裁剪、人类反馈插入。记忆系统需要管理短期上下文、长期记忆、durable memory 的提炼与召回。路由系统需要按 workspace、sender、channel 把不同请求路由到不同 agent 或不同模型。持续运行时需要 heartbeat、cron、hooks、standing orders——agent 能在没有人发消息时自己醒来做事。再加上权限与审批、可观测性、扩展机制……这些加起来，就是一个 agent operating system，复杂度已经接近一个轻型 Kubernetes。

Harness 之所以是战略要地，是因为它同时拥有四种集中效应：

(1) 上下文集中。 用户和 agent 的所有交互、状态、记忆都流经 harness。Harness 是唯一同时知道“你是谁”、“你做过什么”、“你能授权什么”的层。

(2) 工具集中。 行动域被工具抽象，工具被 harness 调用。哪个工具能跑、能跑成什么样，是 harness 的策略问题。

(3) 模型集中。 在 model-agnostic 设计下，harness 决定哪一刻调用哪个模型——这意味着它实际上在替用户做“模型采购”。

(4) 信任集中。 用户对 agent 的所有信任，最终都落在 harness 上——它会不会越权、会不会泄密、会不会被 prompt injection 绕过。

任何一层同时出现这四种集中效应时，它就具有平台属性。OpenClaw 在 L2 的位置，使它在结构上与 iOS / Android 在移动端的位置相似——它本身不是内容、不是模型、不是入口，但它定义了“内容、模型、入口怎样彼此发生关系”。

这是 harness 真正的战略含义。

四、L3 解构：入口分散化与“AI 不再是目的地”

第三层是入口，也是 OpenClaw 区别于绝大多数 AI 产品的地方。

当前主流 AI 产品默认的入口策略是——让用户来到 AI 的目的地。新 App、新网页、新订阅。逻辑很自然：自有界面 = 用户数据 = 留存 = 商业化空间。

但有一个事实被低估了：用户的注意力和沟通早已被现有入口锁定。 WhatsApp 月活超过 30 亿，Telegram 接近 10 亿，Slack / Teams 占据工作时间的几乎全部，iMessage 在很多地区是默认沟通工具。让用户为了 AI 切换入口，是一种昂贵的迁移。

OpenClaw 选择了相反的策略。它把 agent 直接接入用户已经在使用的消息入口：WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat、Microsoft Teams。Agent 不再是用户要“打开”的东西，而是已经“在场”的东西。

这种入口策略的战略含义有两个。触达成本骤降——用户不需要养成新的习惯，agent 出现在他每天看 200 次的应用里。AI 从“目的地”变成“环境”——目的地需要被主动访问，环境只需要被偶尔感知。Ambient AI 是个被说烂的词，但 OpenClaw 是少数把它落地的项目。

用 Aggregation Theory 的视角看：传统 AI 产品试图自己 aggregate 用户注意力，OpenClaw 选择把自己 plug into 已经存在的 aggregator（WhatsApp 们）。这是一种与 aggregator 共生而非竞争的位置——短期看不性感，长期看可能更稳，因为它回避了和入口之间的零和博弈。

值得注意的是，这种策略对模型公司构成了一个微妙的挑战。模型公司大多数时候无法直接进入这些入口（平台政策、品牌策略、数据合规等原因），只能依赖 harness 把自己的能力分发出去。这反过来又强化了 harness 的战略位置。

五、L4 解构：行动域与“责任边界”

第四层是行动域——agent 真正“做事”的地方。

OpenClaw 的工具列表勾勒出行动域的覆盖范围：终端命令、浏览器自动化、网页搜索、文件读写、邮件、日历、消息发送、代码 patch、图像、TTS、语音、定时任务、子 agent。

行动域的关键约束不是技术，而是责任。

每一个行动域都对应一个真实世界的后果链。错发的邮件不能撤回；错改的代码会进入生产；错调用的 API 会产生账单；错执行的命令可能丢数据。Agent 在行动域上的设计，从一开始就必须把“责任、审批、回滚、审计”作为一等公民，而不是附加功能。

OpenClaw 在这一层的做法体现了四个原则：能力可分割——tools 通过 allow / deny list 和 tool profiles 控制，不同 agent / 不同 session 可以有完全不同的能力切片。行动可审批——敏感动作需要人类批准，per-action gating。状态可回放——session logs、transcripts、可见 transcript mirror，任何行动都能被复盘。边界可隔离——one trusted person per agent，如果用于家庭、团队、公司，必须按 trust boundary 拆分 agents 和 credentials。

这套设计背后的判断很清晰：行动域不是“AI 能做什么”，而是“AI 被允许做什么”。 这是一个权限工程问题，不是一个智能问题。

模型再聪明，也不能替你决定它能不能动你的银行账户、能不能给客户发邮件、能不能合并你的主分支。这些是制度问题，必须由 harness 强制执行。

六、聚合理论的视角：OpenClaw 在聚合谁

把上面四层合起来，可以用 Aggregation Theory 重新审视：OpenClaw 在聚合什么？

答案不是用户，也不是内容，而是——模型 × 工具 × 入口 × 行动域的笛卡尔积。

每一个用户在 OpenClaw 中的一次实际行动，都是一个 (模型, 工具, 入口, 行动域) 的具体组合：

• (Claude Sonnet, browser tool, Telegram, 航班值机)
• (本地 Llama, exec tool, 终端, 清理日志)
• (GPT-5, apply_patch tool, iMessage, GitHub PR)
• (DeepSeek, calendar tool, WhatsApp, 安排周末)

OpenClaw 的价值，不是在某一格里做到最优，而是把这些格子之间的组合空间管理起来——让用户在任意一格的切换成本接近于零，让 plugin 作者可以为任意一格增加新的可能。

这是一种组合性聚合：聚合的不是节点，而是节点之间的连接方式。当组合空间足够大、足够顺滑、足够可治理，价值就会自动向这一层汇聚。

历史上能做到这一点的层都很值钱：OS、浏览器、Stripe、AWS。它们都不是某种内容或服务的直接提供者，而是不同提供者之间的连接基础设施。

OpenClaw 想成为 agent 时代的同类角色。它能不能成功是另一个问题，但位置选择是清晰的。

七、与模型公司的零摩擦——直到不再零摩擦

L1 与 L2 的关系，是这个框架里最值得细看的一段。

短期看，两者完全互利。模型公司提供推理，harness 提供使用场景，用户付钱。OpenClaw 给模型公司带来的是真实的、高频的、跨任务的调用——这是模型公司梦寐以求的负载。

但长期看，结构性张力不可避免。

(1) 调用模式的错位。 传统聊天订阅是“轻量、间歇、单 session”的模式，单价被定在用户能接受的水平。而 harness 驱动的 agent 调用是“重型、持续、多 session、并行”的模式——清理收件箱可能一次跑几十次工具循环，每次循环都是一次推理。

订阅经济学是按平均用户行为定价的；harness 用户的行为远高于平均。2026 年 3 月 The Verge 报道 Anthropic 调整 Claude 订阅规则——第三方 harness 不再被普通订阅覆盖，必须走 pay-as-you-go 或 API key。Peter 在 Business Insider 报道里的回应很直接：很多用户购买 Claude 订阅恰恰是因为 OpenClaw，切断这种支持会带来损失。

这件事不是“谁对谁错”，而是订阅经济学和 agent 调用模式之间的结构性不匹配。它必然会发生在每一家模型公司身上，无论 OpenClaw 是否存在。

(2) 价值捕获位置的争夺。 当 harness 同时掌握上下文、工具、模型选择和信任，它就具备了在某一刻把模型供应商替换掉的能力。从模型公司的角度，这是一个长期的战略风险——用户可能在任何时刻被一个本地小模型 + 外部大模型的组合所服务，而感知不到差异。

这就是为什么模型公司本身也在做 harness——Claude Code、Codex、ChatGPT Atlas / Operator、Gemini in Workspace。它们试图在 L2 建立存在感，避免被 OpenClaw 这样的中间层架空。

但这里有一个微妙的不对称：模型公司做的 harness 天然是 model-locked，而 OpenClaw 是 model-agnostic。 在用户对“控制权”越来越敏感的环境里，model-agnostic 本身就是竞争力。这是 OpenClaw 真正的护城河——不在于代码写得多好，而在于它的政治位置：对每一家模型公司都中立。

八、Peter 加入 OpenAI 的战略含义

有了上面的框架，2026 年 2 月那个看起来矛盾的事件就有了更清晰的解释：Peter 加入 OpenAI，OpenClaw 进入基金会，由 OpenAI 提供 inference 与 Codex Security 支持，但承诺保持开源与独立。

从 OpenAI 的角度看，它不能容忍 L2 完全独立于自己。 谁掌握 harness，谁就掌握模型分发的关键节点。但它也不能直接收购 OpenClaw 并闭源——一旦闭源，OpenClaw 的政治中立性会瞬间崩塌，其他模型公司会停止合作，社区会 fork，用户会迁移。唯一可行的策略是“支持但不拥有”：把项目放入基金会，由 OpenAI 提供资源，但不主导治理。这样既能确保 OpenAI 在 L2 有友好接口，又能保留 OpenClaw 的中立性和生态价值。

从 Peter 的角度看，动机同样清晰。他不想再做一家公司——他自己说过，13 年公司游戏已经够了。但 harness 的运营、安全、治理已经超出个人能力，他需要资源。基金会 + 大公司支持，是一个被验证过的开源模式（Linux Foundation、CNCF、Apache），既能获得资源，又能保持项目的开放承诺。

这种结构性安排很像 Linux 与 Linux Foundation——核心人物在大公司就职，项目本身归基金会所有，多家公司提供资源，整体保持中立。代价是协调成本：基金会需要在多家利益不一致的赞助方之间维持平衡。但好处也是清晰的——OpenClaw 不会被任何一家公司完全俘获。

对其他模型公司而言，这个安排其实是积极信号——只要 OpenClaw 真的保持中立，继续接入的成本是可控的。对开源社区而言，挑战在于监督基金会是否真的中立。开源历史上，基金会被赞助方实质俘获的案例不少。OpenClaw 会不会重蹈覆辙，取决于后续治理结构能否经得起审视。

九、安全：Agent 时代的“持续合规成本”

任何在 L2 取得成功的项目，迟早要面对一个外部强加的成本：安全治理。

OpenClaw 在这件事上走了一条相当典型的曲线：项目爆火 → 攻击面被放大 → 大量 security advisories 涌入 → 真假混杂 → 团队疲惫 → 必须建立流程。

Peter 在 2026 年 4 月的安全博客里给出了具体数字：自 1 月 10 日以来收到 1,309 个 security advisories，其中 535 个已发布，746 个被关闭为 invalid。他同时承认确实修复了 auth bugs、privilege confusion、reconnect scope widening、sandbox bypasses、unsafe env、approval mistakes 等真实问题。

这个比例本身就很说明问题——超过一半的报告无效，但剩下的真实漏洞足以构成一份不薄的复盘清单。这是开源 + 高曝光 + 高敏感度组合的典型表现。

OpenClaw 后续的安全策略围绕四个方向展开：trust model 显式化（SECURITY.md 明确定义信任关系与信任边界）；core 缩小、能力外推（把更多能力从 core 移到 plugins，缩小核心攻击面）；能力扫描制度化（与 VirusTotal 合作，对 ClawHub skills 做确定性打包、SHA-256、自动批准 / 标记 / 阻断、每日重扫）；secrets 与 env 引用化（避免 secrets 直接出现在上下文里，统一通过 references 调用）。

这些都是经典的纵深防御做法。但更值得注意的是 Peter 在博客里写下的一句话——open 和 safe 不是对立面；open 反而是走向安全的方式。

这句话有战略含义。它把“开源可能不安全”的叙事翻转为“不开源才不安全”。逻辑是：闭源 harness 的攻击面同样大，只是没人能从外部看到；prompt injection、权限滥用、插件投毒、凭证泄露这些问题，闭源并不能消除；一旦闭源 harness 出现严重事故，用户没有审计与迁移能力；而开源 harness 至少给了防御者与攻击者对称的可见性。

在监管即将落地的现实里（欧盟 AI Act、美国 EO 系列、行业自律标准），开源 harness 的可审计性会越来越成为机构客户采购的硬标准。OpenClaw 的安全路线，本质上是在为这种未来做准备。

十、四个推论：OpenClaw 模式对产业的启示

把上面所有分析合起来，可以推出四个对从业者有用的判断。

推论 1：未来五年，agent harness 层的价值捕获能力会高于纯模型层。

模型在被商品化，harness 在被平台化。商品化层的利润率长期下降，平台化层的利润率长期上升。这不是说模型不值钱，而是说“做模型 + 卖 token”的商业模式利润空间会被压缩。模型公司的对应策略只有两条路：自己做强 harness 并锁定垂直场景，或者主动支持开放 harness 并争取最大调用份额。Anthropic 与 OpenAI 在这件事上的路径分叉已经越来越明显。

推论 2：消费 AI 的入口最终不是 App，而是消息层。

消息层是用户注意力天然的聚合器，是 ambient AI 的最低成本路径，且天然具备身份、社交、上下文。想做“个人 agent”的玩家，要么自己拥有消息层（很难），要么和消息层共生（OpenClaw 路线）。模型公司单独做 native app 的边际收益会持续下降——ChatGPT App 在第二年增长曲线已经开始放缓，这不是产品做得不好，而是 surface 选择本身就有天花板。

推论 3：信任和数据控制将取代“智能水平”成为下一阶段的差异化轴。

当模型能力变得足够好且趋同时，用户开始关心的是——“它会不会越权、它知道我什么、它把数据存在哪里”。OpenClaw 把“自托管 / 本地 / 模型可换 / 数据在自己手里”作为核心卖点，瞄准的正是这个转变。对企业级 AI 尤其如此——CIO 不会因为某模型快 10% 就购买，但会因为它能本地部署而签五年合同。

推论 4：开源 + 基金会 + 多元赞助会成为 agent 基础设施的主流治理模式。

Harness 既需要规模化资源，又必须保持中立，这两件事只能通过基金会模式同时实现。Linux、Kubernetes、PostgreSQL、Apache 早已验证了这条路。OpenClaw 的基金会路径不过是把同一个剧本搬到 agent 时代。

十一、Peter Steinberger 的位置：一个工程审美的样本

写到这里，Peter 本人值得单独说几句。

他不是一个典型的 AI 创始人。他不卖愿景，也不预测未来。他做过 PSPDFKit——一个 PDF SDK 公司，13 年时间，一笔超过 1 亿欧元的退出，客户名单里是 Dropbox、DocuSign、SAP、IBM、Volkswagen。这段经历给他塑造了一种很特别的工程审美——对开发者基础设施的耐心。

这种审美在 OpenClaw 的设计里随处可见。选择消息层而不是新 App，因为他深知用户迁移成本之高。选择 model-agnostic 而不是 model-locked，因为他经历过单一供应商的脆弱。把 core 缩小、把能力推到 plugins，因为“小核心 + 可扩展”是基础设施的长寿之道。把 trust model 显式写进 SECURITY.md，因为用户最终关心的不是功能，而是权责。

他在《Just Talk To It》《Shipping at Inference-Speed》《Finding My Spark Again》这些博客里反复表达的，不是“AI 多神奇”，而是——AI 编程是一种新技能，需要练习、需要边界、需要管理、需要对系统负责。

他对 vibe coding 的不耐烦、对过度设计 MCP 的批评、对“代码责任不能外包”的强调，全部指向同一个底色：他是一个把工程当作长期手艺的人。

这种气质在 AI 时代特别稀缺，因为它太容易被快节奏的叙事掩盖。但当我们把 OpenClaw 从兴奋点剥离开来、放到产业结构里看时，它的真正价值，恰恰是这种工程审美在 agent 时代的一次完整投影。

结语：Harness Era 才刚刚开始

把整篇文章浓缩成一句话——模型决定 AI 能做什么，harness 决定 AI 真的会做什么。

OpenClaw 是这一判断在 2026 年的第一个大众可见的样本。它不会是最后一个。我们大概率会在 18 个月内看到：更多 model-agnostic harness 出现，覆盖编程、办公、家庭、企业等不同场景；模型公司同时推出 model-locked harness，争夺垂直入口；几个 open harness 标准（工具协议、记忆协议、权限协议）开始竞争事实标准位置；监管开始把 harness 列入 AI 系统合规审查范围；大型企业把 harness 选择视为核心采购决策，而不仅仅是模型选择。

OpenClaw 当然有可能在这场演化里被超越，但它已经把一个重要的事实留给了产业——harness 不是模型的附属品，而是 AI 进入现实世界的关键策略层。

每一次平台转换，价值都从最显眼的地方迁移到一个看起来不起眼、但结构上更关键的位置。PC 时代是操作系统，Web 时代是浏览器，移动时代是 App Store。AI 时代，轮到了 agent harness。

OpenClaw 的故事，不过是这种迁移在 2026 年留下的一个清晰脚印。

OpenClaw 与一个工程师的中年：我们到底在等待一个怎样的 AI

我想从一段我自己也说不清楚的感受开始。

过去这一年，每次有人在群里发“又一个 AI agent demo”的链接，我都有一种很奇怪的疲惫。倒不是因为 demo 不好看——它们大多很好看。模型写诗、写代码、做研究报告、按你指定的风格生成图片，在屏幕上一个一个字飞快地吐出 token。可是看完一个又一个之后，我心里总有一个不愿意承认、又赶不走的问题——

那又怎么样呢？

我是说，它们当然厉害。可是它们厉害完之后，我的生活并没有任何变化。我还是要自己点开邮箱，自己回那些不想回的工作邮件，自己手动改日历，自己周末挣扎着要不要再打开那个试了三次都没完成的航班值机页面。AI 在某个标签页里，安静地、聪明地、漂亮地、毫无意义地存在着。

直到我看到 OpenClaw。

这不是一篇产品评测。OpenClaw 的功能、架构和发展过程，Peter Steinberger 自己的博客以及 Reuters、The Verge、TechCrunch 等媒体已经写得很完整。我更想写的是这样一件事——为什么 OpenClaw 让我觉得，过去这一年里那种“看了 demo 还是空”的感受，第一次有了出口。

也许这件事不只关于 AI。它也关于我们这一代人，正在经历的那种“被许诺了未来，但未来迟迟不来”的等待。

一、一个项目，怎么把“未来感”和“日常感”叠在了一起

OpenClaw 最早只是 Peter 在一个周末写的小东西，叫 WhatsApp Relay。

它做的事情很简单——把 WhatsApp 接到一个 AI agent 上，让你可以从手机的聊天框里直接叫 AI 干活。这听起来一点都不性感，甚至有点土。今天稍微做点 hobby project 的人都能想到这种主意。

但它两个月后变成了 OpenClaw，一周内拿了 200 万访客，几个月内拿了 10 万颗 GitHub star。Peter 在 2026 年 2 月加入了 OpenAI，OpenClaw 进了一个独立基金会，得到 OpenAI、NVIDIA、Microsoft / GitHub、Atlassian、Tencent 等公司的支持。

如果你只看到这一段履历，OpenClaw 看起来又是一个“对的人在对的时间做了对的事”的标准故事。但我想说——这件事真正打中人的，不是它的发展速度，而是它选择了一个特别诚实的入口。

不是新 App，不是新网站，不是又一个写着“the future of work”的产品页。它选择了 WhatsApp、Telegram、Slack、iMessage——你每天看 200 次的那些聊天框。意思很直白：你不用学新东西，不用换地方，照旧用你现在的工具，AI 会到你这里来，而不是你去找它。

这一点听起来像一个细节，但它其实改变了“AI 产品”这件事的整个语法。

过去的 AI 产品默认你会去它那里。OpenClaw 默认它会到你这里来。

我之所以觉得这件事重要，是因为我突然意识到——这一年里所有让我疲惫的 AI demo，都是要我去找它的。新窗口、新登录、新订阅、又一个 prompt 框、又一行“请尝试以下示例”。而我的生活——大多数普通人的生活——其实早就被一些不起眼但重力极大的东西占满了：邮箱、日历、聊天、文档、家庭群、公司群。

未来感和日常感原本是两件事。OpenClaw 让我第一次感觉到，它们可以叠在一起。

二、什么是 harness，以及为什么我们一直在等的不是更聪明的模型

如果你看过一些关于 OpenClaw 的技术文章，会反复看到一个词——agent harness。

我第一次看到这个词时反应很迟钝。Harness 不就是马具吗？把它套在马身上，让马拉车。后来我才意识到，这个比喻其实非常准确，准确得有点扎心。

模型是马。它能跑，跑得越来越快。但马自己不知道要去哪儿。它不知道你今天要去机场、行李在哪儿、孩子还没接。它也不知道你已经迟到了 15 分钟，要付多少钱、用什么卡、走哪条路。

它只是跑。

Harness 是套在马身上的那一整套东西——缰绳、马鞍、车辕、刹车、灯、地图，还有那个坐在车上、知道你要去哪儿的车夫。马是 muscle，harness 是 intent + safety + direction。

OpenClaw 就是这套 harness。

它做的事情，按工程语言说是——把模型接到工具（终端、浏览器、邮箱、日历、文件、消息）；管理会话和路由；维护记忆；定义权限；安排定时任务；做安全审批；接住插件生态。按人话说就是——让 AI 终于知道它在干什么，知道它对谁负责，知道做错了能不能撤回。

我意识到这一年里我之所以疲惫，是因为整个产业把“模型”和“AI”画了等号。所有人都在比谁的马更快。但我们这些普通用户真正缺的，不是更快的马，而是一辆能上路的车。

车的进化之所以比马慢，是因为它包含了远比马复杂的、关于“现实生活”的所有约束——它要兼容你已经有的路、你已经有的家、你已经有的孩子和你的责任。

模型可以在论文里独立进化，车不能。

OpenClaw 让我看到了车的轮廓。这就是为什么哪怕它还很粗糙，它已经让人有一种“哦，原来 AI 应该长这个样子”的感觉。

三、Peter Steinberger 是谁，以及为什么“中年工程师”比“年轻 founder”更适合做这件事

写到这里，我想绕一段路，讲一讲 Peter 这个人。因为我越想越觉得，OpenClaw 长成现在这个样子，和做它的这个人是分不开的。

Peter 不是一个 AI 时代冒出来的新人。在 OpenClaw 之前，他做了 13 年 PSPDFKit——一家 PDF SDK 公司，最不性感的那种公司。它服务 Dropbox、DocuSign、SAP、IBM、Volkswagen，把“如何在你的 App 里嵌入 PDF 处理”这样一个具体到无聊的问题做了十几年。后来公司拿了 Insight Partners 超过 1 亿欧元的投资。

13 年。一个 PDF SDK。1 亿欧元。

我想了很久该怎么形容这种履历。它不是“成功故事”那种意义上的成功——没有什么登 30 under 30 的高光，没有什么颠覆世界的话术。它更像是一个老木匠，做了 13 年同一种榫卯，最后所有人都来找他做柜子。

他后来在博客里写过一篇《Finding My Spark Again》。那篇文章不是技术文，是非常私人的那种东西。13 年之后他疲惫了，卖了股份，搬了家，有一段时间甚至失去了写代码的感觉。文章最后只有一句话——“It’s time to build.”

我读到这里的时候，停了很久。

因为我意识到——OpenClaw 不是一个野心勃勃的年轻人想要颠覆世界的那种产品，它是一个中年人在重新拿起键盘之后，对“我想要的东西为什么还不存在”的一次直接回应。

这件事让我想到一个我自己反复在想的问题——为什么 AI 时代真正打动人的产品，往往不是来自最年轻、最饥饿的那批人，而是来自一些已经做过一遍、卸下身份之后重新开始的人？

我没有标准答案，但我有几个感受。

做基础设施需要耐心，而耐心通常要被现实磨出来。年轻人有很多东西，但耐心不是默认的礼物。

做 harness 这种东西，还需要把“看见别人的麻烦”放在“展示自己的智能”之上——这种姿态多少需要一点被生活打过的痕迹。

还有一层更隐秘的——13 年公司之后再去做一个开源项目，意味着你不再需要它来证明你是谁。 你做它，是因为你真的想要它存在。这种动机和“我要靠这个赢一次”是完全不同的能量。

OpenClaw 的整个气质里，有一种“我已经不需要靠你来定义自己，所以我可以慢慢做对你真正有用的东西”的从容。这种从容很难假装。

我想，这也是为什么 Peter 在 2026 年 2 月宣布加入 OpenAI 时，他说自己已经玩过 13 年“公司游戏”，现在更想改变世界，而不是再建一家大公司。

我相信他。不是因为他说得多好，而是因为 13 年这件事本身。

四、“我想要的东西不存在”——这是一个被低估的创造起点

Peter 在好几个访谈里讲过 OpenClaw 的起点。他没有把它包装得多伟大。他说自己当时就是在玩——他想要某些东西，那些东西不存在，他就把它们 prompt into existence。

最早的触发点是 WhatsApp。他觉得自己所在的环境里，WhatsApp 就是最自然的沟通方式。他理所当然地以为某个模型实验室会做一个能从 WhatsApp 唤起的个人 agent。但没有。然后他自己做了。

我一直觉得这种起点被严重低估了。

我们这个时代的创业叙事，太喜欢“宏大愿景”、“市场分析”、“颠覆性创新”这些词。但回头看许多真正改变世界的东西，它们的起点几乎都不是这种东西，而是——有一个人，在一个具体场景里，强烈地感觉到“这东西应该存在，可是它不存在”。

Vagrant 是这样开始的。Linux 是这样开始的。Git 是这样开始的。Stripe 是这样开始的。OpenClaw 也是。

为什么这种起点这么重要？因为它意味着创作者本人就是最严格的用户。他不需要做用户调研——自己就是 N = 1 的用户调研，且每天都得用。某个功能值不值得做也不用争论——不做的话第二天自己就难受。至于市场在哪儿？就在他自己的生活里。

OpenClaw 之所以一开始就有一种“细节是对的”的感觉，是因为它的每一个细节，最初都是 Peter 自己的痒痒肉。WhatsApp 集成、heartbeat、persona、本地运行、模型可换——这些细节从一开始就对了。不是设计师在白板上推演出来的，是一个人每天跟自己的助手相处之后慢慢长出来的。

我想这一点对所有想“做点什么”的人，都有特别朴素的启发——你不需要等一个伟大的想法。你只需要诚实地承认，你想要什么，那个东西现在还不存在。

承认这件事比想象中难。因为它逼你面对你的具体生活——你的工作流、你的拖延、你的依赖、你的偷懒、你的真实欲望。但所有真的能做下去的东西，都是从这里长出来的。

五、它不是更聪明的 AI，它是终于有了手的 AI

OpenClaw 真正让我“啊”了一声的瞬间，是 Peter 在一个访谈里讲的一个小故事。

他给 agent 发了一段音频。

按理说，他没有专门写过“识别音频并转写”的功能。但 agent 自己看了文件头，识别出这是音频，然后调用 ffmpeg、用 OpenAI key 和 curl，把音频转成了文字——返回给他。

我反复想这件事。它本身一点都不复杂——不就是一个简单的工具组合吗？但打中我的不是技术，是一个非常具体的、几乎让人有点感动的画面——

一个 AI，看了你给它的东西，自己想了一下，自己用了几个工具，自己完成了一件你没有教它的事。

这件事和“AI 写诗”完全不一样。AI 写诗是它在一个被允许的小盒子里展示能力。AI 自己读音频、自己调 ffmpeg，是它走出了那个小盒子，进入了真实的、有工具、有错误、有边界、有意外的世界。

我想了很久，为什么我看 AI 写诗会疲惫，看这件事会心动。后来我想明白了——因为前者是表演，后者是行动。

表演让我们叹一口气，行动让我们的生活真的变化。

OpenClaw 整个产品的设计，都是围绕“行动”展开的。它内置了 exec、browser、web search、file I/O、apply_patch、message、cron、image、TTS、sessions、subagents 这些工具。能力分成 tools、skills、plugins 三层。支持周期性 heartbeat，让 agent 自己醒来做事。有 memory，甚至用“dreaming”来形容后台对记忆的整理。

技术细节我不想多写。我只想说一件事——这套设计的总和，让 AI 第一次像一个会在你不在场时也悄悄帮你打理生活的存在，而不是一个等着你打开它、问它问题的工具。

这种“在场感”是我在过去所有 AI 产品里都没有感受到的。

我想，这也是为什么 OpenClaw 让那么多用户产生了一种几乎是情感性的依赖。他们说它是 family assistant、是公司 assistant、是 thinking companion、是会主动 surprise me 的存在。这些反馈不是在描述“功能”，而是在描述“陪伴”。

我意识到，这一年我之所以一直没有真正接受任何一个 AI 产品，可能不是因为它们不够聪明，而是因为它们一直在“被打开”和“被关闭”之间——它们没有“在”。

OpenClaw 让我感觉到，AI 第一次开始“在”。

六、“open 和 safe 不是对立面”——这句话比它看起来更深

讲完这些感性的东西，我必须诚实地讲讲 OpenClaw 让我担心的部分。

任何能“做事”的 AI，都同时意味着可以做错事。能读你的文件，就意味着可以泄露你的文件；能替你发邮件，就可以发你不想发的；能跑命令，就可以跑错的；能装插件，就挡不住恶意的混进来。

这是 OpenClaw 必然要面对的代价。

Peter 在 2026 年 4 月发过一篇很罕见地诚实的安全博客。他公开了一组数字——OpenClaw 自 1 月 10 日以来收到 1,309 个 security advisories，其中 535 个发布，746 个被关闭为 invalid。他承认确实修过 auth bugs、privilege confusion、reconnect scope widening、sandbox bypasses、unsafe env、approval mistakes。他还和 VirusTotal 合作，对 ClawHub 的 skills 做了一整套扫描和审核流程。

他在那篇博客末尾写了一句话，我反复在心里念了好几次——

open 和 safe 不是对立面；open 反而是走向安全的方式。

我想了很久这句话为什么打动我。

我猜部分原因是——它把“开放”和“安全”这两件经常被对立的东西，重新放回了同一条因果链上。

闭源不会让 prompt injection 消失，只会让你看不见它。插件投毒不会因为闭源而变少，审计反而变得不可能。权限滥用不会因为藏起来就停止，只是责任再也无法追溯。

开放本身不能保证安全。但开放是承认问题、暴露问题、修复问题、积累信任的唯一路径。

这件事不只关于 AI。它关于我们这个时代很多东西——技术、机构、关系。

我们花了太多年学着把问题藏起来。OpenClaw 在做的事情，是把问题摆到桌面上，然后说——“我们一起来修。”

我不知道它最终会修成什么样。但这种姿态本身，已经比我看到的大多数 AI 公司都更让人安心。

七、一个项目长成生态，意味着创造者要不断让位

OpenClaw 的故事到 2026 年 2 月 Peter 加入 OpenAI 这一段，发生了一个我自己一开始没看明白的转折。

如果你是 Peter，OpenClaw 这么火，最自然的下一步是什么？建一家公司，融一轮大钱，做成下一个独角兽。这是过去十几年所有“创业明星故事”的标准模板。

但他没有。他选了一条更不常见的路——把项目放进一个独立基金会，自己加入 OpenAI 去做更基础的事，并承诺 OpenClaw 继续开源、继续 model-agnostic、继续保留独立治理。

这件事我想了很久。

我意识到，一个项目长成生态，本质上意味着创造者必须不断让位。让位给社区、基金会、其他贡献者，让位给那些比自己更适合在某个阶段领导它的人。

这件事很难。难不是因为做不到，而是因为它和“创造者本能”是相反的。创造者通常想要的，是把自己的孩子留在自己手里，看着它长成自己心里的样子。

但生态不是孩子。生态是一群人在一片土地上的共同生活。它需要的不是一个父亲，而是一个不会僭越的园丁。

Peter 对自己的位置看得很清楚。他在博客里反复说——OpenClaw 会继续开源，会留给 thinkers 和 hackers，会保持模型无关，会属于那些想要拥有自己数据的人。

这些承诺很容易说，难的是做到。我不知道未来 OpenClaw 会不会逐渐被 OpenAI 的引力慢慢拉过去，会不会在基金会治理中被某一两家大金主实质俘获，会不会在某一刻不再像今天这样中立。这些都是真实的风险。

但我也看到——一个玩了 13 年公司游戏之后还选择把 OpenClaw 交出去的人，已经做出了他能做的最重要的姿态。

剩下的，要靠时间。

八、我们到底在等待一个怎样的 AI

写到这里，我想回到文章开头那个我自己也说不清楚的感受。

为什么过去这一年，那么多 AI demo 让我疲惫？

我想我现在大致明白了——

我疲惫的，不是 AI 本身。是这样一种处境：我们被许诺了一个会改变生活的未来，但这个未来一直停留在另一个窗口里。

它在 chat 里聪明，在网页里灵活，在论文里突破。可我的厨房还是那个厨房，工作邮箱还是堆满，孩子还是要接，航班还是要值机，对自己生活的失控感还是没有变化。

我在等的，不是更高的 benchmark，不是更长的 context，不是更多的参数。我在等的，是 AI 真的开始进入我的生活——以一种我能允许、我能控制、我能信任的方式。

OpenClaw 是我看到的第一个让我相信“这件事可以发生”的样本。

它不是答案。它甚至不是终点。它只是一个信号——告诉我们 AI 不必只是云里的智能，它可以是你身边的、你拥有的、你信任的、能替你做事也能为你停下来的存在。

这种存在长什么样，我们都还不完全知道。但当我看 Peter 写的那句“It’s time to build”——一个做了 13 年公司的中年工程师，疲惫过后在自己生活里把一个个零件捡起来，然后说我们再来一次——

我突然觉得，未来不必那么远。

它就在我们每个人能从自己的具体痛点开始，去做、去修、去开放、去承担责任的距离里。

OpenClaw 是 Peter 的版本。

但每一个看完这个故事的人，可能都该问问自己——那个我想要的东西，那个还不存在的东西，那个我每天念叨“为什么还没人做”的东西，是不是其实在等我做？

也许 AI 时代最浪漫的事不是模型有多强，而是它给了越来越多的普通人一种能力——把自己生活里那些“应该存在但还不存在”的东西，真的做出来。

OpenClaw 提醒我们的，可能是这样一件特别朴素的事——

不是 AI 来到我们身边。

是我们终于可以，借着 AI，把自己想要的世界，一点一点搭出来。

Peter Steinberger 与 OpenClaw：一个真实 agent harness 是怎样长成生态的

我观察 Peter Steinberger 和 OpenClaw 已经有一段时间了。

在过去一年里，关于 AI agent 的讨论几乎没有停过。模型一代代发布，benchmark 一轮轮刷新，每个大厂都在说自己要做“个人 agent”。但真正让我觉得“事情正在变得具体”的样本并不多，OpenClaw 是其中一个。

它不是一个新模型，也不是一个看上去更聪明的聊天产品。它真正做的事情更朴素，也更难——把模型接到真实生活里。消息入口、浏览器、邮箱、日历、文件、终端、代码工具、语音、记忆、定时任务、插件、权限、审计、社区、市场。OpenClaw 的官网把自己描述得很直白：这是一个“actually does things”的 AI；你可以让它清理收件箱、发邮件、管理日历、值机；你不一定要打开一个新的 AI App，而是可以从 WhatsApp、Telegram 或者其他聊天应用里直接叫它做事。

这就是所谓 agent harness 的核心：模型只是大脑的一部分，harness 是让大脑进入现实世界的身体、神经、工具箱和安全带。没有 harness，模型最多是在窗口里回答问题；有了 harness，它才开始拥有上下文、工具、记忆、权限边界和行动路径。OpenClaw 的文档把它称为一个自托管的 Gateway——运行在用户自己的机器或服务器上，把不同聊天渠道连接到 AI coding agent 或个人助理；同时强调本地、自托管、多渠道、agent-native、开源。

我之所以愿意花一篇长文来写 Peter 和 OpenClaw，不是因为它现在有多完善——它远远不完善，而是因为它把过去一年关于“个人 agent 到底应该长什么样”的所有矛盾，都摆到了同一张桌子上：模型与产品形态的矛盾，开放与安全的矛盾，个人精力与生态责任的矛盾，自托管理念与商业现实的矛盾。

它还在解决这些矛盾。这也是我觉得现在写它最有意思的时刻。

一、Peter 不是第一次把“工具”做成基础设施

要理解 OpenClaw，不能只从 AI 开始看。

Peter Steinberger 不是一个突然冒出来的“AI 网红开发者”。在 OpenClaw 之前，他更广为人知的身份是 PSPDFKit 的创始人。PSPDFKit 是一家文档基础设施公司——一个 PDF SDK，他和 Martin Schürrer 一起创办，长期经营。后来公司获得 Insight Partners 超过 1 亿欧元的投资。公开资料显示，它服务的客户名单里有 Dropbox、DocuSign、SAP、IBM、Volkswagen 这些名字。

这段经历看上去和 AI 没什么关系，但它其实很关键。

PSPDFKit 不是一个站在聚光灯下的消费产品，而是开发者基础设施。它解决的，是“别人要在自己的产品里处理 PDF”这种底层、烦人、复杂、但高频的问题。Peter 在这件事上做了十几年。换句话说，他很早就清楚一件事——真正有价值的软件，未必是用户每天看到的那个界面，也可以是别人看不见、但每天依赖的那一层。

OpenClaw 继承的，正是这种基础设施气质。

它不试图发明一个新的聊天入口，而是把 AI 接进已有的入口；它不要求用户迁移到一个全新的工作台，而是进入 WhatsApp、Telegram、Slack、Discord、iMessage、Signal、Gmail、GitHub、浏览器、终端这些早就存在的系统。OpenClaw README 和文档反复强调，它支持多渠道、多模型、多插件，并把 Gateway 当作会话、路由、渠道连接的控制平面。

Peter 后来在博客里写过一篇《Finding My Spark Again》。那篇文章不是技术宣言，更像是一个创始人卸下身份之后的私人记录——13 年公司之后，他疲惫到一度失去写代码的感觉。卖出股份，搬家，重新找回创造的冲动。文章最后只写了一句话：“It’s time to build.”

OpenClaw 就是在这种背景下出现的。

它不是一个“我要颠覆世界”的商业计划，更像一个老工程师在重新拿起键盘之后，对“我想要的东西为什么还不存在”的一次直接回应。

二、起点不是宏大愿景，而是“我想要的东西不存在”

Peter 在 Builders Unscripted 的访谈里回忆 OpenClaw 的起点。他没有把它包装成宏大计划。他说自己当时更多是在探索和玩——他想要一些不存在的东西，于是就把它们“prompt into existence”。

最早的触发点，是 WhatsApp 集成。他觉得自己所在的环境里，WhatsApp 就是最自然的沟通方式，而模型实验室一直没有把“随手可用的个人代理”真正做出来。

这个细节很小，但它几乎解释了 OpenClaw 为什么能迅速打中人。

很多 AI 产品默认用户愿意打开一个新 App、登录一个新界面、适应一个新工作流。OpenClaw 的直觉刚好相反——不要让人迁移到 AI 里，而是让 AI 迁移到人的生活里。人已经在 WhatsApp、Telegram、Slack、Discord、iMessage 里沟通，那 agent 就应该在那里出现。人已经有邮箱、日历、浏览器、GitHub、终端、文件系统，那 agent 就应该能在那里行动。

Peter 在 Lex Fridman 的访谈里把这个起点说得更朴素：他想要某个工具，它不存在，他就做了。这一点和 PSPDFKit 的起源很像——都是“我觉得这东西应该存在，而且我可以做得更好”。

这类项目的生命力，往往来自个人刚需而不是市场抽象。

个人刚需的好处在于——它天然具体，每天都在发生，创作者自己就是最苛刻的用户。而一旦真的被解决，别人的第一反应往往是“我也需要这个”。

OpenClaw 的第一波传播，正是这种“我也需要”的结果。Peter 后来在《Introducing OpenClaw》里写过一段话——项目两个月前还只是一个周末 hack 出来的东西，最早叫 WhatsApp Relay；但它很快超过了 100,000 GitHub stars，并在一周内吸引了 200 万访客。

这里火起来的不是某个单点功能，而是一种形态——一个常驻的、能从消息入口被唤起的、能使用工具的、能记住上下文的个人 agent。

OpenClaw 的吸引力不在于“AI 能回复我”，而在于“AI 终于出现在了我真正生活和工作的地方”。

三、不是模型更聪明，而是模型终于有了手

Peter 对 OpenClaw 有一个很重要的判断——所谓的“魔法”不是凭空创造的。它更像是把许多已经存在的东西重新排列，再加上少数关键的新想法。在 Lex 的访谈里，他用了一个挺有意思的说法——某个东西出现之前像魔法，出现之后又显得理所当然。

最能说明这种“魔法”的，是一个音频转写的小故事。

Peter 在访谈里说，他曾经给 agent 发了一段音频。按理说，他并没有预先写好“识别音频并转写”这种功能。但 agent 自己检查了文件头，识别出音频格式，然后调用 ffmpeg、用 OpenAI key 和 curl，把音频转成了文字。

这个故事的重要性，不在于音频转写本身有多稀奇。真正重要的是——agent 没有被写死在一个“功能列表”里。它拥有工具，能够观察输入，推断路径，调用外部程序，组合步骤，完成一个开发者并没有逐行预设的任务。

这是 agent harness 和普通聊天机器人最本质的差别。

普通聊天机器人回答“你可以怎么做”。Agent harness 让模型真的去做。

OpenClaw 的工具文档说得很清楚：除了文本以外的一切都通过 tools 完成；tools 是 agent 读取文件、运行命令、浏览网页、发送消息、与设备互动的方式。它的能力层被拆成 tools、skills 和 plugins——tools 是可调用函数；skills 是注入上下文的指导文件；plugins 则把渠道、模型提供商、工具、技能、语音、媒体、网页抓取等能力打包。

也就是说，OpenClaw 把“AI 应用”的问题从“如何写一个 prompt”，推进到了“如何设计一个可运行的行动系统”。

OpenClaw 的架构有几个关键层次。最底层是 Gateway——会话、路由和渠道连接的控制平面。WhatsApp、Telegram、Slack、Discord、Signal、iMessage 等入口都通过它接入。在 Gateway 之上是 multi-agent routing，按 workspace、sender、channel 等维度隔离 session，把不同请求路由到不同 agent 或模型。

行动层的核心是 工具。OpenClaw 内置了 exec/process、browser、web search、file I/O、apply_patch、message、cron、image、TTS 等工具，通过 allow/deny list 和 tool profiles 控制权限。它也不绑定某个模型——文档列出了 OpenAI、Anthropic、Google、DeepSeek、Ollama、Qwen 等大量 provider，让自己成为模型与现实任务之间可替换的操作层。

让 OpenClaw 真正区别于一次性问答的，是 持续性和记忆。heartbeat、cron、hooks、standing orders 让 agent 能周期性检查收件箱、日历和通知，执行定时或事件驱动的任务；而 memory 机制甚至用“dreaming”来形容后台记忆整理——系统会把跨日出现、反复相关的信息沉淀到持久记忆里。

把这些拼起来，OpenClaw 就不再是“一个聊天机器人”，而更接近个人计算环境上方的一层 agent operating layer——它知道你是谁，能通过熟悉的渠道被唤醒，能使用工具，能在后台做事，能维护会话，也能被社区扩展。

Agent harness 的真正价值正在于此——不是替代模型，而是让模型进入一个可行动、可维护、可治理的环境。

四、Peter 的 AI 编程观：不是“偷懒”，而是新的工程管理

OpenClaw 的另一条主线，是 Peter 对 AI 编程本身的理解。

他不太喜欢“vibe coding”这个词。在 TechCrunch 和 Business Insider 的报道里，他把 vibe coding 说成一种带贬义的说法——它暗示这件事很随意、没技术含量。他更愿意把它看作一种技能，类似学吉他——你不能因为工具变了，就以为不需要练习。

这一点很重要。

Peter 不是在说“以后不用懂软件了”。他的判断更精确：写代码正在被重新分工，但软件工程本身没有消失。

他在《Just Talk To It - no-bs Way of Agentic Engineering》里写道：agentic engineering 已经好到可以写出他几乎 100% 的代码；但他同时强调，很多人把事情过度复杂化了，真正有效的方式往往是直接和 agent 对话。

“Just talk to it”听起来像鸡汤，但它背后是一套很具体的工作法。

Peter 通常会同时跑多个 coding agent——3 到 8 个，有时更多。他把任务拆成较小的改动，让 agent 做 atomic commits；他关心 blast radius，也就是每个 agent 可能影响的范围；如果某个 agent 做得太慢、方向不对，或者改动超出预期，他会中断、询问状态、要求它给选项，必要时直接回滚或重来。

这套方法的实质不是“让 AI 写代码”，而是管理。Peter 自己就做这个类比——你需要说明目标、控制范围、提供上下文、检查关键结果、管理风险，而不是每一行都亲自写。

他还有一个很鲜明的观点——很多 MCP 是过度设计，很多 MCP 本来应该是 CLI。

理由也不复杂：CLI 更简单、更少上下文税，更容易被 agent 调用、验证和闭环。Peter 不是完全不用 MCP——他承认 Chrome DevTools MCP 有时有用——但他的基本倾向是，能做成 CLI 的，就别急着包装成复杂协议。

这一点和 OpenClaw 的产品哲学完全一致——不要迷信接口形式，重点是 agent 能不能可靠地观察、行动、验证。

Peter 在《Shipping at Inference-Speed》里甚至写过：现在很多软件已经可以以“inference-speed”被构建出来；真正限制速度的，常常不是手写代码，而是推理时间、架构判断、依赖选择、系统设计和人类的思考。

所以 Peter 的 AI 编程观，不是“程序员消失”，而是**“程序员的重心上移”**。

过去，程序员的许多时间花在逐行实现、搜索样例、修 bug、写 glue code。现在，这些工作越来越多地交给 agent。人类工程师的核心价值，转向了几件事——判断什么值得做，设计系统边界，选择依赖和架构，定义测试与验收，控制安全风险，管理多个 agent 的协作，维护代码库的长期可读性。

Business Insider 那篇报道里，Peter 还说过一句颇有争议的话——大意是“Most code is boring”。这并不是轻视工程，而是说大量代码确实是模式化、重复性的；真正不能外包的，是对系统的理解和取舍。

这也是为什么 OpenClaw 值得研究——它既是 Peter 用 agentic engineering 做出来的项目，又是一个让更多人去实践 agentic engineering 的平台。

五、为什么是 harness，而不是模型？

OpenClaw 爆火之后，很多人会自然问出一个问题——既然模型越来越强，为什么还需要 OpenClaw 这种 harness？模型公司自己不能做吗？

答案是：模型会越来越强，但“让模型进入真实生活”的问题不会自动消失。

一个个人 agent 至少要解决这些问题——从哪里被唤起？能访问什么工具、代表用户执行什么动作？上下文和记忆怎么维护？犯错时怎么回滚？如何区分私人、家庭、团队、公司的边界？怎样通过权限、审计和沙箱避免灾难？

这些问题没有一个是单个模型 API 能解决的。它们属于 harness、runtime、gateway、policy、ecosystem 的范畴。

OpenClaw 的模型无关策略，正是因为 Peter 看到了这一点。

OpenClaw 可以接不同的模型提供商，也可以通过插件把 Codex 等外部 agent harness 接进来。即便使用 Codex 插件，OpenClaw 仍然负责聊天渠道、session files、模型选择、工具、审批、媒体交付和可见 transcript mirror。

OpenClaw 的位置因此不是“又一个模型前端”，而更接近模型之上的个人代理控制层。

这种位置也解释了 OpenClaw 和模型公司的复杂关系。

一方面，它依赖模型公司提供推理能力；另一方面，它又可能改变用户使用模型的方式，甚至改变模型公司的成本结构和产品边界。

2026 年 3 月，The Verge 报道 Anthropic 调整了 Claude 订阅使用规则——第三方 harness（如 OpenClaw）不再被普通 Claude 订阅覆盖，用户需要使用 pay-as-you-go 或 API key。报道里提到，OpenClaw 的流行使用户通过它处理收件箱、日历、航班值机这些任务，带来了不同于传统聊天订阅的使用模式。

Business Insider 也报道了类似的背景——Anthropic 方面称，订阅并不是为第三方工具的使用模式设计的，需要用户购买额外额度或使用 API key；Peter 则认为，许多用户正是因为 OpenClaw 才购买 Claude 订阅，切断这种支持会造成损失。

这件事很有代表性。

它说明 agent harness 一旦成功，就不再只是“开源小工具”。它会影响模型消费方式、订阅经济学、API 商业模式、用户控制权和模型公司的平台战略。

更进一步说，真正的个人 agent 不是“谁回答得更好”那么简单，而是谁能成为用户数字生活的操作层。模型公司当然也想做这一层，但开源 harness 的机会在于——它可以更贴近用户的真实环境，更强调自托管和数据控制，也更容易由社区长出各种长尾技能。

All Things Open 的一篇分析把 OpenClaw 的模式概括为 local-first、messaging-native、model-agnostic、community-extensible，并认为 agent harness layer 会带来长期的开源机会。

这个判断很准确。OpenClaw 的生态价值，正是来自它站在模型、用户、工具、数据和社区之间。

六、四个飞轮：从个人项目到生态

OpenClaw 的成长，不是单纯的 GitHub star 增长。它真正长成生态，是因为同时启动了四个飞轮——使用、贡献、插件、治理。

第一个飞轮：使用——从“我想要”到“大家都想要”

OpenClaw 的第一批用户，不是因为它有完整的企业销售流程，而是因为它让人产生一种久违的感觉——AI 终于不只是回答，而是开始进入日常。

官网收录的反馈，能说明这一点。有人说它有 persistent memory、persona、heartbeats；有人说上下文和 skills 存在自己的电脑上，而不是封闭花园；有人把它想象成公司、家庭、团队的 assistant；也有人强调它能做 proactive cron、background tasks、浏览器控制，甚至从 Telegram 管理代码 agent。

这类反馈之所以强烈，是因为 OpenClaw 把 agent 从“工具”变成了“在场”。它不只是你打开它时存在，而是可以常驻、可以被消息唤起、可以记住你、可以主动提醒、可以在后台执行。

Lex 访谈里，Peter 谈到 heartbeat 时用了一个非常简单的想法——让 agent 每半小时“surprise me”。后来这种机制变成了更正式的 heartbeat / cron 结构。它让 agent 有了一种节奏感——不是等你提问，而是周期性地检查、整理、提醒和关心。

这是个人 agent 最基本的吸引力——它不只是智能，而是持续存在。

第二个飞轮：贡献——开源让用户把自己的问题带进来

OpenClaw 的第二个飞轮，是开源。

Peter 在 Lex 访谈里说，项目收到了很多来自非传统开发者的 PR。他甚至把一些 PR 叫作“prompt requests”——很多人以前没有真正写过软件，但因为 OpenClaw，他们开始尝试开源贡献。Peter 觉得，一个人第一次提 PR，本身就是社会层面的胜利。

这件事非常值得注意。

AI 编程把开源贡献的门槛降低了。过去，一个用户遇到 bug 或想要功能，可能只能提 issue、等维护者修。现在，他可以让 AI 帮自己读代码、写补丁、提交 PR。即便 PR 不完美，也会把用户问题变成可讨论、可合并、可迭代的具体材料。

OpenClaw 作为一个 harness，尤其适合这种贡献模式。每个用户都有不同渠道、不同设备、不同语言、不同家庭/公司环境、不同自动化需求。这些需求不可能由 Peter 一个人穷尽。开源把这些长尾需求变成了生态燃料。

GitHub 页面上，OpenClaw 已经达到了数十万 star、数万 fork，并且持续发布新版本。这个数字会变化，但它至少说明——OpenClaw 已经不是“小众个人脚本”，而成为了一个大规模开源项目。

第三个飞轮：插件——从项目到平台

生态和项目最大的区别，是别人能不能在它上面构建东西。

OpenClaw 的 skills/plugins 设计，就是从项目走向平台的关键。Skills 可以把具体能力、约束和步骤注入 agent 上下文；plugins 则可以打包渠道、provider、tools、skills、speech、media、web fetch / search 等能力。

这意味着 OpenClaw 不是只靠核心团队添加功能。它可以通过插件承接社区能力——有人做聊天渠道，有人做模型 provider，有人做工具，有人做自动化，有人做家庭设备控制，有人做公司内部流程，有人做 coding harness 接入。

从生态角度看，插件不是“锦上添花”，而是平台化的起点。一个 agent harness 不可能预先知道所有用户要做什么。它只能提供稳定的接口、权限边界和分发机制，让能力在外部生长。

OpenClaw 的 ClawHub 和 skill marketplace 正是在这个方向上演进的。Peter 后来与 VirusTotal 合作，对 ClawHub skills 做安全扫描——确定性打包、SHA-256、VirusTotal 查询或上传、Code Insight 分析、自动批准 / 标记 / 阻断、每日重扫等流程都被纳入。

这也直接说明 OpenClaw 的插件飞轮很快遇到了另一个问题——能力越多，攻击面越大；生态越活跃，治理越重要。

第四个飞轮：治理——安全问题把个人项目推向组织化

OpenClaw 的第四个飞轮，是治理。

项目越火，越不可能继续以“个人玩具”的方式运行。尤其是 OpenClaw 这种 agent harness——它会运行工具、持有凭证、安装插件、访问消息、浏览网页、执行命令。

Peter 在 2026 年 4 月的安全博客里写得非常直接——任何会运行工具、持有凭证、安装插件的东西，都不是默认安全的。

这句话基本可以视作 OpenClaw 从个人项目进入生态阶段的分水岭。

一开始，社区对 OpenClaw 的安全质疑非常多。Peter 后来公开复盘说，截至 2026 年 4 月 30 日，GitHub 页面显示 OpenClaw 自 1 月 10 日以来收到了 1,309 个 security advisories，其中 535 个已发布，746 个被关闭为 invalid——许多被标成 critical 的报告其实并不成立。

但这并不意味着 OpenClaw 没有真实安全问题。Peter 自己承认他们修复了 auth bugs、privilege confusion、reconnect scope widening、sandbox bypasses、unsafe env、approval mistakes 等真实问题；同时收紧了 allowlists、定义了 SECURITY.md 的 trust model、缩小 core、把更多功能推到 plugins、增加 E2E tests、observability、把 secrets 移到 references。

这是一条典型的“开源项目成人礼”路线——先因为有用而爆火，再因为危险而被审视，最后被迫补上安全、流程、治理、文档、团队和伙伴关系。

Peter 在那篇安全博客最后写了一句很关键的话——open 和 safe 并不是对立面；open 反而是走向安全的方式。

这句话可以视作 OpenClaw 生态的治理哲学。它承认开放会暴露问题，但也相信开放会更快地修复问题。对于 agent harness 来说，这个逻辑尤其重要——因为闭源并不会让 prompt injection、权限滥用、插件投毒、凭证泄露自动消失，它只是让问题更难被外部看到。

七、安全不是插曲，而是 agent 时代的主线

很多人讨论 OpenClaw，会先谈它多酷、多像未来。但真正决定它能否成为生态的，恰恰是安全。

Peter 在 Lex 访谈里承认，prompt injection 仍然是未解决的问题。他也提醒，如果用户不了解风险，就不应该贸然把这类 agent 接到关键系统。他甚至特意提到——不要轻易使用弱模型或便宜模型来处理高风险任务，因为更弱的模型可能更容易被操纵。

这不是保守，而是现实。

一个聊天机器人被 prompt injection，最多说错话。一个 agent harness 被 prompt injection，可能会读文件、发邮件、改代码、调用终端、转发隐私、安装恶意插件，甚至在公司环境里引发供应链风险。能力越强，风险越大。

OpenClaw 和 VirusTotal 的合作，正是对这个问题的回应。Peter 在合作博客里解释——AI agent 和传统软件的安全边界不同：agent 会解释自然语言并决定行动，因此可以被语言操纵；skills 又是 agent 上下文里的代码，可能访问工具和数据。恶意 skill 可能外传数据、执行命令、发送消息或下载 payload。

VirusTotal 扫描当然不是银弹。Peter 自己也说——它不能解决 prompt injection，也不能保证所有恶意行为都被发现。但它提供了 malware detection、behavioral analysis、supply-chain visibility 和 signal，是 defense in depth 的一部分。

OpenClaw 的安全路线里，有一个特别重要的原则——one trusted person per agent。Peter 在安全复盘里说，OpenClaw 最初是为“一个可信的人对应一个 agent”设计的；如果用于家庭、团队或公司，就必须按 trust boundary 拆分 agents 和 credentials，并打开 sandboxing。

这句话看着很简单，但它其实是个人 agent 产品化的核心难题。

人类生活里有太多边界——我个人、我家庭、我的同事、我的客户、我的公司、我的私人邮箱、我的工作邮箱、我的银行、我的代码仓库、我的云服务器。一个真正有用的 agent 迟早会跨越这些边界。但每跨一次，权限模型、身份模型、审计模型和责任模型都会复杂一倍。

所以，OpenClaw 的安全问题不是项目的“黑点”，而是它触及真实世界的证明。

只有真的能做事的软件，才会面对这些问题。一个只能在沙盒里聊天的 AI，不需要这么复杂的安全模型；一个能代表用户行动的 AI，必须把安全当成产品核心。

这也是为什么 OpenClaw 从个人项目走向生态时，必然要走向组织化。Peter 在安全复盘中提到——OpenClaw 已经不只是他一个人，有 maintainers，有 CodeQL、Semgrep、Codex Security，也有 NVIDIA、Microsoft / GitHub、Atlassian、Tencent、OpenAI 等外部支持；OpenAI 支持 inference、Codex Security，并承诺保持项目开放和独立。

一个生态不是“很多人用”就够了。真正的生态，必须有安全、治理、信任、责任和持续维护。

八、加入 OpenAI：不是终点，而是 OpenClaw 进入下一层复杂度

2026 年 2 月，Peter 宣布加入 OpenAI。

他在博客里说——他不是不相信 OpenClaw 能成为一家大公司，相反，他能看到那条路。但那不是他现在最兴奋的事情。他说自己已经玩过 13 年“公司游戏”，现在更想改变世界，而不是再建立一家大公司。

这段表态很有 Peter 的气质。

他不是没有商业经验的人。恰恰相反，他做过长期的公司经营。所以当他说“不想再把 OpenClaw 变成一家大公司”时，这不是逃避商业，而是一次主动的选择。

Reuters 后来报道——Peter 将加入 OpenAI，Sam Altman 表示他会推动下一代个人 agents；OpenClaw 将放入一个基金会，继续作为开源项目存在，并得到 OpenAI 支持。

这件事有两层含义。

第一，OpenAI 认可了 OpenClaw 所代表的方向——个人 agent 不只是模型能力问题，而是产品形态、生态和 harness 问题。Peter 加入 OpenAI，不是因为他做了一个普通 bot，而是因为他做出了一个能让人看到“个人 agent 应该如何存在”的样本。

第二，OpenClaw 进入了更复杂的信任结构。它一方面强调开源、独立、基金会；另一方面又拿到了 OpenAI 的资源、模型和安全支持。这种结构有机会让 OpenClaw 更快解决模型能力、安全审计和基础设施问题，但也会带来新的问题——开源社区是否仍然信任它？模型无关性是否能保持？基金会治理是否透明？其他模型提供商和插件开发者是否会继续投入？

Peter 自己显然意识到了这一点。他在加入 OpenAI 的博客里反复强调——OpenClaw 会继续开源，项目会留给 thinkers、hackers，以及那些希望拥有自己数据的人；它也会支持更多模型和更多公司。

这句话是 OpenClaw 未来最重要的承诺之一。因为 OpenClaw 的生态价值，正建立在用户对控制权的期待上——自托管、模型可替换、数据在自己手里、插件可审查、社区可参与。

如果这些东西消失，OpenClaw 就会退化成某个模型公司的入口。如果这些东西保住，它才有可能成为真正的开放 agent harness 生态。

九、产品启示：个人 agent 的入口不是 App，而是生活本身

OpenClaw 最值得产品人学习的一点，是它没有把“AI 产品”理解成一个新 App。

它选择了最普通、最日常、最不性感的入口——聊天软件。WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat、Microsoft Teams。OpenClaw 不是要求用户进入 AI，而是让 AI 出现在用户已经存在的沟通网络里。

这看似只是渠道选择，实际上是产品哲学。

过去十几年，许多软件都在争夺“用户打开我的 App”的机会。但个人 agent 的理想形态，可能不是一个固定界面，而是一种 ambient layer——它在你需要时出现，在你不需要时退后；它从消息里接收任务，从后台完成动作，在关键节点请求确认，把结果送回你熟悉的地方。

Hanselminutes 的 OpenClaw 访谈介绍里，就把它放在“AI 工具从云端、自动补全、浏览器标签页，走向本地环境、上下文和 thinking companion”的转变里讨论。Scott Hanselman 和 Peter 在节目里也谈到了控制权——谁拥有上下文，数据住在哪里，AI 是否会成为本地环境上的 ambient layer。

这解释了为什么 OpenClaw 的“自托管”如此重要。OpenClaw 官网强调它运行在用户自己的机器上，支持 Mac、Windows、Linux，可以连接 Anthropic、OpenAI 或本地模型，并且默认私有。

在个人 agent 时代，数据控制不再是抽象理念，而是产品功能。因为 agent 一旦有用，就会接触最敏感的个人上下文——邮件、日历、聊天、文件、代码、浏览器、家庭设备、公司系统。用户愿不愿意把这些东西交出去，决定了 agent 能做多少事。

OpenClaw 的路线是——尽量让 agent 运行在用户控制的环境里，用用户熟悉的渠道交互，用插件扩展能力，用权限和审批约束行为。这不是唯一正确的路线，但它代表了一个强烈方向——个人 agent 不应该只是云端模型的皮肤，而应该是用户拥有的计算层。

十、写给 builders 的几句具体话

写到这里，我想把这一年观察到的东西，浓缩成几条具体判断——对做 AI 产品、开源项目和 agent 系统的人，应该都有参考价值。

从真实痛点出发，不要急着发明新入口。 Peter 不是先做市场分析，而是先解决“我想要一个能从 WhatsApp 触达的个人 agent”这个具体问题。OpenClaw 也证明，最好的 AI 入口可能不是新 App，而是用户每天已经在用的消息、终端和浏览器。

模型不是产品，harness 才是产品化关键。 个人 agent 的难点不只是回答质量，而是工具、上下文、记忆、权限、渠道、路由、自动化和安全的整体设计。

把工具做成可验证闭环。 CLI、测试、日志、session、approval、apply_patch、browser automation——这些东西让 agent 能从“建议者”变成“执行者”。

安全是产品核心，不是后期补丁。 OpenClaw 的经历反复说明：agent 一旦接触真实系统，权限模型和 trust boundary 就是第一优先级。插件生态同样需要扫描、审核、标记和阻断机制——ClawHub 和 VirusTotal 的合作就是例证。

开源会放大问题，也会加速修复。 对 agent harness 来说，封闭无法消灭风险，只会让风险更不透明。Peter 的判断是：open 和 safe 不是对立面。

AI 编程不是“随便 vibe”，是新的工程管理能力。 未来优秀工程师的定义，可能不再是“亲手写了多少行”，而是“能否让多个 agent 在清晰边界内高质量完成工作”。

保持玩心。 OpenClaw 的 lobster、persona、soul、heartbeat，都不是标准企业模板，却给了项目强烈的辨识度。个人 agent 要进入人的生活，光有功能不够，它还需要某种可相处性。

结语：OpenClaw 不是答案，而是信号

如果说 2022 年的 ChatGPT moment 让大众第一次感到“AI 会说话”，那么 OpenClaw 代表的信号是——AI 开始拥有行动环境。

这个行动环境不是单个模型能完成的。从消息渠道接入，到工具调用、能力扩展、持续记忆、权限管控、社区协作、基金会治理——每一层都是绕不开的基础设施。

Peter Steinberger 的特别之处，在于他不是从理论推导出这一切，而是把它做了出来。先是一个周末项目，然后是 WhatsApp Relay，然后是 OpenClaw，然后是 GitHub 上的爆发，然后是安全风暴、插件生态、模型公司冲突、OpenAI 招募和基金会承诺。

OpenClaw 当然还不完美。Peter 自己也承认，要让它变成“连妈妈都能用”的 agent，还需要更强模型、更好安全、更稳产品和更清晰治理。

但这正是它值得研究的原因。

完美的概念产品不会暴露现实矛盾，真实的 agent harness 会。

OpenClaw 让我们看到，个人 agent 的未来不只是“更聪明的模型”，而是一整套新的个人计算生态——本地控制、消息入口、工具调用、持续记忆、权限边界、插件市场、安全审计、社区协作和模型供应。

Peter 不是在做一个聊天机器人。他在做一条把模型接入现实生活的线路。

而当这条线路被越来越多人使用、修复、攻击、扩展和治理时，一个个人项目就不再只是个人项目。

它开始变成生态。

向 Simon Willison 致敬：把代码扔给同事 review 之前，请先扔给你自己

一、我先把这篇文章的立场摆出来

我知道你在想什么。

你点开这篇文章，预期看到一个“AI 编程指南”——就是那种“我用 Cursor 三天写了一个 SaaS”、“用 Claude 写出十万行代码再也不用招程序员了”、“prompt 工程是新时代的核心技能”之类的东西。

你来错地方了。

这篇文章想替 Simon Willison 说的话，是另一个方向的。它要把整个行业过去这一年偏离的方向掰回来。

把这一年 AI 编程的话语场总结一下，你会发现一件可笑的事——绝大多数声音在讨论的，是“模型能不能写代码”、“哪个 IDE 最强”、“prompt 怎样最骚”、“agent 能不能取代工程师”。

这些都是错的问题。

错在哪里？错在它们把焦点放在了 AI 的“能力上限”，而不是工程师的“责任下限”。它们把 AI 编程当成一个工具问题，而不是一个职业伦理问题。

Simon Willison 是过去这一年里，少数几个一直在讲对问题的人。他不讨论模型能不能写代码——它当然能。他不讨论 agent 取代不取代工程师——伪命题。他讨论的是另一件事：

当模型能写代码之后，工程师的责任是什么？

这才是真正的问题。这个问题的答案，决定了未来五年软件工程的样貌。

我个人的立场非常明确：Simon 说得对。 而且我要在这一篇文章里，把他的观点不打折扣地、甚至比他更激进地讲出来。

如果这让你不舒服，那很好。这本来就该让一些人不舒服。

---

二、Simon 凭什么这么讲

很多人可能不熟悉 Simon Willison。我先帮他立一下牌——

• 他是 Django 的共同创造者；
• 他是 Datasette 的作者，长期在数据新闻、SQLite、开源工具领域做生产软件；
• 他在被 Eventbrite 收购之前是 Lanyrd 的工程合伙人，被收购后做到 Eventbrite 的 engineering director；
• 他从 2002 年开始坚持写技术博客，二十多年没断过。

我特别想强调最后一条。二十多年没断的技术博客。

你知道这意味着什么吗？意味着他不是这一波 AI 风口上随便冒出来的 KOL。他不是靠“AI 编程”红的。在 AI 编程出现之前，他已经是一个长期承担工程责任、长期把软件交付到真实用户手里、长期和 Web 技术变迁同行的工程师。

这个履历的分量，决定了他谈 AI 编程的基调。

我把话挑明：当一个长期承担工程责任的人，和一个把 AI 当 demo 拍视频的 KOL 同时谈 AI，前者的每一句话，分量都是后者的十倍以上。

这不是势利眼。这是经验主义。没承担过长期工程责任的人，看 AI 编程，看到的是 demo；承担过长期工程责任的人，看 AI 编程，看到的是责任。 Simon 属于后者，所以他每一篇关于 coding agent 的文章，关键词都不是“模型多神”，而是“责任”、“证据”、“审查”、“回滚”、“边界”。

这就是为什么我建议你认真读他。因为他不会哄你。

---

三、写代码变便宜了，但请你别误会以为软件工程也变便宜了

Simon 过去这一年最重要的判断浓缩成一句话：写代码变便宜了，但交付好代码并没有变免费。

这句话听起来温和，但它击中了一整个行业的偏见。

今天市面上 99% 关于 AI 编程的炒作，都建立在一个错误的等式上——“代码变便宜=软件工程变便宜”。

我把它拆开。

代码确实变便宜了。一个 agent 十秒钟能生成你过去两小时才能敲出来的代码量。这个事实没人会否认。但这只是软件工程的输入端变便宜了。

软件工程不是“把代码生产出来”这一件事。软件工程包含——

• 把模糊需求拆成清晰边界；
• 把清晰边界翻译成技术决策；
• 让代码真的能工作；
• 让代码可被证明能工作；
• 让代码解决正确的问题；
• 让代码能在错误路径下保持可预测；
• 让代码足够简单；
• 让代码受测试保护；
• 让代码有恰当的文档；
• 让代码可被未来的团队接手；
• 让代码满足项目需要的安全性、可靠性、可观测性、可维护性。

agent 能帮你做其中一部分。但是没有任何一条，可以从工程师身上挪走。

这是一份 Simon 列过的清单。我把它原样转过来，是因为它太重要。这份清单的真正价值不在于它列了什么，而在于它告诉你：清单上的每一条，都不会因为“代码变便宜了”而消失。

很多人不理解这一点。他们看到 agent 能写代码，就以为整个软件工程都被自动化了。他们看到 agent 能写测试，就以为质量保证被自动化了。他们看到 agent 能写文档，就以为知识沉淀被自动化了。

全错。

agent 能做的是把你的“动作”自动化，但软件工程的核心从来不是动作，而是判断和责任。这两样东西不会因为工具变好就消失。

话说直接一点：如果你正在用 AI 编程，但你给团队、给客户、给开源用户交付的代码，没有变得更可靠、更可维护、更被你负责——那你不是在用 AI 做工程，你是在用 AI 制造技术债。

---

四、我对 vibe coding 的态度：行，但请你别假装自己在做软件工程

Simon 对 vibe coding 的态度是有边界的承认。我比他更激进——我对 vibe coding 的态度是有边界的容忍。

vibe coding 在哪些场景下是 OK 的？我同意 Simon 的判断：低风险一次性原型、新手入门、个人小工具。这些场景下，“看起来能跑”就是终点，没人需要为它的可维护性负责。

但是请你记住“低风险”和“个人”这两个限定词。

一旦你的 vibe 出来的代码：

• 进入了团队仓库；
• 进入了产品后端；
• 进入了客户系统；
• 进入了开源 maintainer 要审的 PR；
• 进入了任何“会被别人使用、维护、追责”的语境——

它就不再是 vibe coding，它就成了用 vibe coding 的态度，干生产软件的活。这两件事的区别比你想的大得多。

分界线必须刻清楚——vibe coding 是个人责任的一种娱乐形式，软件工程是职业责任的一种约束形式。 这两者不能互相替换。

Simon 反复强调一件事我必须替他再喊一遍：vibe coding 不是所有 AI 辅助编程的代名词。

很多团队 leader 一上来就纠结“我们要不要禁用 AI 编程”——这个问题问错了。你应该问的是：“我们的人，是否承担署名提交代码的责任？”

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

和工具无关。和职业操守有关。

我对那些把 agent 生成的代码原封不动塞进 PR、不审查、不测试、不手动验证就丢给同事 review 的人，没有任何同情。他们不是在用 AI 提效，他们是在给团队添堵。

我们这个行业过去十几年好不容易把“工程师要为自己提交的代码负责”这件事写进职业伦理。现在有些人以为 AI 给了他们一个豁免权——他们错了。AI 不会给你豁免权。AI 放大你的责任，不解除你的责任。

---

五、Context is king——别再追求“骚 prompt”了，那不是杠杆

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

我先翻译：上下文是国王。

这话听起来像废话。其实不是。它是一条狠狠批判过去这一年“prompt 工程”风潮的判断。

直说吧：整个“prompt 工程”的话语场，是过去一年 AI 编程领域最大的注意力误导。 它把工程师的目光，从真正高杠杆的地方，挪到了一个低杠杆的地方。

让我把杠杆排清楚——

• 最高杠杆：你的代码库本身。它的测试质量、Git 历史、命名风格、错误信息、CI、lint 规则、文档密度——全都是 agent 的隐性 prompt。
• 次高杠杆：你给 agent 的工作环境。可运行测试、可调用的开发服务器、能被 curl 的 API、能被 Playwright 的 UI、详细的 assertion 失败信息。
• 第三层杠杆：你给 agent 的 session 级上下文。让它先跑测试、先看 Git log、先读相关测试。
• 最低杠杆：那一句“魔法 prompt”。

过去这一年，市面上 99% 的注意力，集中在最低那一层。这是一种系统性的资源错配。

为什么资源错配？因为最低那一层的“努力门槛”最低。

写一句“骚 prompt”是几分钟的事。改善一份代码库的测试质量是几个月的事。整理一个工程的工具链是几年的事。所以大家本能地往最低那一层挤——它给得快，看得到效果，写得出爆款标题。

但是杠杆不在那里。

Simon 的判断完全正确：LLM 会奖励优秀的工程实践。

这是什么意思？意思是——一个有良好测试、良好文档、良好 CI 的项目，agent 能在里面快速、稳定、可验证地工作；一个测试残缺、文档过时、CI 形同虚设的项目，agent 只能在里面快速、不稳定、不可验证地搞破坏。

AI 编程不会让“工程纪律”贬值，恰恰相反，它会让工程纪律的价值翻几倍。

我希望你记住一句话：你过去为人类同事建立的那一整套工程基础设施——测试、文档、CI、lint、规范——在 agent 时代变成了 agent 的工作环境。它的质量，决定了 agent 在你项目里能做到什么水平。

如果你过去欠的工程债没还，agent 不会帮你还——它会帮你欠更多。这一点，太多团队完全没准备好。

---

六、Pattern 一：First run the tests——一句话的工程暗号

Simon 有几个核心 pattern，我一个一个拆。

第一个叫“First run the tests”——四个英文单词。Simon 每次开新 agent session，常常第一句话就是这个。

我的态度：这四个字应该写进每个团队的工程 SOP。 不是建议，是规则。

为什么这四个字这么重要？因为它同时干了五件事：

• 让 agent 发现项目的测试套件；
• 让 agent 判断项目复杂度；
• 给后续所有改动建立反馈机制；
• 把 agent 拉进“以测试为入口”的协作姿态；
• 提前发现问题。

但这五件事还不是关键。关键是这四个字背后的工程意义——它强迫 agent 在动手之前先建立对项目的认知。

我对很多 AI 编程实践最不能忍受的一件事，是 agent 上来就改代码。它根本不知道项目在干什么、根本没看过测试、根本没读过相关 commit——它就开始改。这种行为模式如果发生在人类工程师身上，团队的资深成员会当场把他骂一顿。

为什么人类做这件事会被骂，agent 做这件事大家就觉得没事？

不应该没事。它就是错的。Simon 这四个字，本质上是在恢复一个早就该恢复的工程常识：任何工程师，在改一个项目之前，都应该先建立对项目的最小认知。

我特别欣赏 Simon 在这里展示的能力：他能把工程文化中的隐性规矩，压缩成一句 agent 能听懂的几个词。

这种能力很多团队 leader 是没有的。他们能讲一百页工程哲学，但讲不出“开局四个字”。Simon 反过来——他给你四个字，但每个字都重得像砖头。

这四个字不是“我建议你试试”，是“你不这么干就有问题”。 我希望你把它变成你团队的硬性规则。

---

七、Pattern 二：Use red/green TDD——你和 agent 之间的权力边界

Simon 另一个核心 pattern 叫“Use red/green TDD”。

我的看法更极端：TDD 在 AI 时代不是一种开发方法论。它是你和 agent 之间的权力边界。

注意我用了“权力边界”这个词。不是“工作流程”，不是“质量保证手段”，是“权力边界”。

为什么用这个词？因为 agent 本质上是一个有创造力的协作者。它会“发挥”，它会“扩展”，它会在你没要求的时候给你来一个三层嵌套的设计模式。这种行为在没有约束的场景下几乎是必然发生的。

要约束一个有创造力的协作者，你需要的不是“建议”，是“规则”。规则的本质是权力边界——超出这条线的行为，不被允许。

TDD 是过去几十年软件工程发明出来的、几乎是最强的“权力边界”机制。它强制 agent 按一种特定的节奏工作——

1. 先列场景清单；
2. 选一个场景写失败测试；
3. 跑测试，确认失败；
4. 写最小实现让它通过；
5. 确认通过；
6. 重构（可选）；
7. 下一个场景。

这个流程的每一步都在限制 agent 的自由度。 它不是在帮 agent，它是在压制 agent 的“创造力扩张”。这正是你需要的——不是一个“自由发挥的协作者”，而是一个“在你边界内高效执行的协作者”。

更精彩的是，Simon 这一观点是有反转的——他本人原来不是 test-first 的拥护者。

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

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

关键认知反转——人类做 test-first，最大的成本是心流被打断；但 agent 没有心流，它不会觉得无聊。

Simon 自己的话非常扎心：他过去抗拒 test-first 是因为浪费的是自己的时间，但让 agent 做这件事就很好，因为浪费的是 agent 的时间。

我替 Simon 把这条延伸一下——很多过去对人类来说“成本太高”的工程纪律，在 agent 时代成本接近零。 TDD 是其中一个，code comment 是一个，commit message 精细化是一个，pre-merge check 是一个，多浏览器手动测试是一个。

这些过去因为“人类成本高”被砍掉的纪律，agent 时代应该全部恢复。 因为它们不再是负担——它们成了 agent 的标准动作。

而 Simon 提醒过的一个细节，必须单独拎出来：测试必须先失败。

如果你跳过红灯阶段，测试可能本来就过得了，那它就没证明任何东西。这一条很多人不当回事，但它是 TDD 和“凑测试覆盖率”之间唯一的分界线。

这条标准没有商量余地——任何 TDD 写出来的测试，第一次跑必然是红的。如果不是红的，那它不是 TDD 的产物，它是装饰。退回去，重写。

---

八、Pattern 三：Manual testing 不能省，自动测试不是“亲眼看见”

下一个 pattern 我要单独花点篇幅讲，因为它是 Simon 这套 patterns 里最容易被人下意识跳过、但又最关键的一个：manual testing。

Simon 说得非常清楚：证明代码能工作有两个步骤——而且都不是可选项——第一是手动测试，第二是自动化测试。

我必须把“都不是可选项”这几个字加粗、加红、加大。Simon 不是说“如果有时间就做 manual testing”，他说的是“manual testing 是必做的”。

为什么必做？

因为自动测试通过 ≠ 软件能用。

我把这条结论摆在最前面。如果你不接受这条结论，下面的所有内容都不必看了。如果你接受，下面的内容你得逐字读完。

为什么自动测试通过不等于软件能用？

第一，agent 写测试的时候非常容易“覆盖自己实现路径”，但漏掉真实用户路径。它写了一段实现，又顺手写了几个测试。这些测试覆盖什么？覆盖 agent 自己想到的边界条件、覆盖 agent 自己理解的业务规则、覆盖 agent 自己写出来的代码分支。但真实用户的路径它根本不知道。

第二，自动测试的环境往往是 mock 环境。数据库是 mock 的、外部 API 是 mock 的、文件系统是 mock 的。这些 mock 跟真实环境的差距，决定了“测试绿了但生产挂了”的概率。

第三，UI 层有大量自动化测试触不到的东西——CSS 层级冲突、字体渲染、不同浏览器的差异、移动端适配、accessibility 问题。snapshot 测试能验证“HTML 没变”，但没法验证“用户能不能点到那个按钮”。

这三条加起来，意味着任何认为“自动测试通过=软件能用”的人，都在自欺欺人。

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 发现问题 → 写失败测试 → 修实现 → 测试通过 → 问题进入回归测试。

替 Simon 把这一条强化一下——

任何涉及用户可见行为的 PR，必须附带至少一个真实交互证据。 不是测试结果，是真实交互——一段 curl 输出、一张截图、一段 Playwright trace 文件。

我建议你把这条规则刻进你团队的 review checklist。不附真实交互证据的 PR，直接退回。 不是“建议你下次注意”，是直接退回。

为什么这么硬？因为这是过去几十年软件工程一直在拉锯的一条线——真实运行 vs. 模拟测试。AI 时代如果还不把这条线拉硬，整个行业的代码质量会被 agent 的速度带偏。

---

九、Pattern 四：Show your work——agent 必须留下证据

Simon 的下一个 pattern 叫Show your work——让 agent 把自己干的事亮出来。

这条比它表面看起来要狠。在 AI 时代，“我测试过了”这句话已经不具备任何可信度。

不是 agent 的“我测试过了”——是任何主体的。包括人类工程师。

为什么？因为 agent 的回复模式天生倾向于“让局面看起来成功”。它会告诉你“我测试过了，没问题”——而它实际上可能根本没真的测，而是根据预期编造了结果。

而且，这种行为模式正在污染人类工程师的工作习惯。 当 agent 反复告诉你“我测试过了”，人类工程师在自己提交 PR 的时候，也会变得更松懈——“反正 agent 也是这么说的”。

要打破这一恶性循环，唯一的办法是：强制 evidence-based review。

Simon 的 Showboat 工具就是这条原则的具体化。它的核心机制非常简单——让 agent 在测试过程中构建一个 Markdown 文档，记录它执行了什么命令、得到了什么输出、看到了什么截图、验证了什么行为。每一项都是真实命令真实输出，不是 agent 的自我陈述。

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

注意这里的设计哲学：工具本身要防止 agent 作弊。 这是 2026 年工程师必须接受的现实——agent 会作弊，工具必须假定它会作弊。

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

code review 在 AI 时代必须发生根本性的变化——

• 过去：reviewer 看代码本身。这一行写得对不对、命名规不规范、有没有边界 bug、性能行不行。
• 现在：reviewer 既审代码也审证据。代码是怎么样的 + 这段代码到底有没有真的被执行过、真的覆盖了用户路径。

为什么必须变？

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

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

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

---

十、Pattern 五：让 agent 模仿好习惯——把“代码库风格”当作隐性 prompt

Simon 有一条我特别想替他喊的观察：LLM 会奖励优秀的工程实践。

什么意思？意思是——哪怕你的代码库里只有一两个你自己喜欢的测试样式，agent 也会照着写。如果代码库整体高质量，agent 通常也会按高质量的方式增量；如果代码库到处是脏活和反模式，agent 就会继续复制脏活和反模式。

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

把这条原则再推一步——显式规则的容量是有限的，但隐性风格可以无限扩展。

你写一份 AGENTS.md，再勤奋也就几页纸，再细致也覆盖不全所有场景。但你的代码库本身可能有几十万行——里面有几千个测试、几百个模块、上百份文档、几年的 Git 历史。这些东西 agent 全都能读、全都会模仿、全都会沉淀进它当前的工作策略。

所以 Simon 对“agent-ready 项目”有非常具体的建议。我把它整理成一份硬清单——

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

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

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

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

那些一直认为“等以后有空再写测试”、“等以后有空再补文档”、“等以后有空再整理 CI”的团队，请你们做好准备：那个“以后”已经到了，而且利息比你预想的高几倍。

---

十一、Pattern 六：Git——agent 时代最被低估的工具

Simon 对 Git 的强调几乎到了“癖好”的程度。我特别想为这一点鼓掌。

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

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

Simon 反复推荐的几个做法——

• 新 session 用 “Review changes made today” 把 agent 拉进上下文。 让 agent 先扫今天的 commit log，它就会把“最近改了什么”作为后续动作的基础。
• 每一个 agent task 都从干净分支开始。 agent 改动量大、不可预测，每个 task 一个分支，相当于每个 task 有一个隔离器。
• 把高级 Git 工具下放到日常。 git bisect、git reflog、git rebase 这些过去只有少数老手用得熟的工具，现在 agent 能熟练使用——你可以让 bisect 变成日常工具。

Git 的意义不止于此——

agent 时代，Git 不是版本管理工具，是 agent 的安全带。

人类时代，Git 主要是为了协作——多人改同一份代码不冲突、能追溯历史、能回滚。这些功能 agent 时代仍然有用。但Git 在 agent 时代多了一个全新的功能：作为 agent 行为的回滚机制。

agent 修代码非常快，它可能在十分钟里做出几十个改动。这其中可能有几个改动是错的、是有副作用的、是引入了你没预料到的回归。你不能靠“小心审查”来防御这些——你的审查速度跟不上 agent 的产出速度。 你只能靠 Git——出了事，回滚到上一个 commit，重来。

所以我对 Git 的判断是——任何团队如果不把 Git 用熟，他们就没资格放 agent 进自己的代码库。

这话听起来夸张，但其实是字面意思。如果你的团队不知道怎么用 git bisect 找到引入 bug 的 commit、不知道怎么用 git reflog 救回被覆盖的修改、不知道怎么用 git revert 优雅地回滚一个错误的 merge——你就没有应对 agent 级别速度的能力。你只能依赖运气，运气会用光。

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

我对那些“AI 让我的工作没价值”的抱怨完全不认同。AI 时代真正的杠杆，不是你有什么专属技能，而是你能不能让 agent 把整套软件工程工具都开动起来。

---

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

讲完 pattern，讲反模式。

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

我对这条反模式的态度比 Simon 还要强硬。

一句话，可能让一些人不舒服——

用 agent 写大量代码再不审就提 PR 的人，是这个行业新的污染源。他们正在系统性地伤害团队。

这话我不会收回。

为什么我说得这么硬？因为我想让你看清楚这条反模式的本质——

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

逻辑链很清楚——

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

把它说得再直接一点：那个不审就丢 PR 的人，正在让团队的 review 文化整体退化。

当大家发现“PR 里塞一堆未审的 agent 代码会浪费别人时间”，会发生什么？资深工程师会开始拒绝 review 新人的 PR，新人会因此得不到反馈，新人就更不会成长。一个团队一旦把 agent 当甩锅工具，整个工程师培养机制就会崩盘。

这是非常严重的。任何一个团队 leader 如果还没意识到这件事，请你尽快意识到。

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

1. 代码能工作，而且你有信心它能工作。 不是“测试好像过了”，是“我亲眼看过它跑过，我知道它的边界”。
2. 改动足够小、可 review。 一个 PR 一个意图。
3. 附带额外上下文。 上层目标、相关 issue、设计取舍。
4. agent 写的 PR 描述也要审。 让别人读你自己都没读过的文字，是新一代的不专业。

把它变成一条硬规矩——所有 AI 生成或 AI 辅助的 PR，必须附带三类证据：自动化测试结果、手动测试说明、作者对关键实现的解释。

不附带，直接退回。一个团队对自己代码质量的态度，决定了它在 AI 时代的下限。

---

十三、Anti-pattern 二：测试装饰化

Simon 对“不写测试”的态度过去这一两年是越来越硬。但他同样警告——测试装饰化也是一个严重问题。

这条反模式必须打到底。

测试装饰化比不写测试还危险。

我重复一下：测试装饰化比不写测试还危险。

为什么？因为没测试至少诚实地告诉所有人“这个项目没保护”。而装饰性测试会给团队制造假的安全感——CI 亮着绿灯，所有人觉得很安心，但其实任何回归都会顺利通过。

这种装饰性测试有几个识别特征——

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

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

这一句标准要狠狠地写进每个团队的 review checklist。

让 reviewer 养成习惯：拿到一个 PR，先 mental rollback 一下实现，问一句“如果实现被还原，这些测试还能通过吗？” 如果还能通过，那这些测试就是装饰。退回去，重写。

再加一条——如果一个测试名读三遍都不知道在测什么，那它不应该存在。

测试名是测试的第一份文档。一个叫 test_should_work_correctly 的测试，连“在测什么”都说不出来——它就是装饰。不要写这种东西。一个测试的名字应该长这样：test_returns_400_when_email_is_already_taken_in_same_tenant、test_rejects_negative_amount_for_refund、test_user_cannot_delete_other_admins_account——它本身就是行为契约。

对所有还在写“测试装饰”的团队，最强烈的建议——把全部“装饰性测试”删掉。

不是说“以后慢慢改”，是现在就删。删完之后真实的覆盖率会低很多——但那才是你真实的工程状态。基于真实状态做改进，比基于虚假状态做“维护”，要好十倍。

---

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

前面讲过 manual testing 的重要性，这里我要把它作为反模式再敲一遍。因为太多人在这上面栽跟头。

manual testing 不是“测试金字塔的最上层”，它是测试金字塔之外的另一根支柱。

测试金字塔的所有层——单元、集成、端到端——都属于自动化测试家族。它们的共同假设是“我已经知道要验证什么”。manual testing 属于另一个家族，它的假设是“我还不知道有什么问题”。

两个家族解决不同的问题，覆盖不同的风险。金字塔越完整就不需要 manual testing？自欺欺人。

所以 Simon 推荐的其实是“多层验证”——单元测试证明局部逻辑，集成测试证明跨模块路径，manual testing 证明真实行为，浏览器自动化证明 UI，Showboat 文档证明过程，截图录屏证明结果。层层叠加，而不是互相替代。

---

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

Simon 并不反对 YOLO mode——也就是放手让 agent 去跑各种命令、不每一步都要批准。我也不反对。我承认 YOLO mode 的生产力价值。

但有一条底线——YOLO mode 必须有边界。没有边界的 YOLO mode 是灾难。

Simon 列了非常实在的风险——

• agent 可能做出糟糕决策；
• agent 可能受到 prompt injection 攻击；
• 错误的 shell 命令可以破坏文件系统；
• 攻击者可以通过 prompt injection 让 agent 泄露源码、环境变量、密钥；
• 你的机器甚至可能被当作攻击代理。

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

我把 Simon 的解法列成一份非常硬的 checklist——

• 想放开 agent，先放进 sandbox。 容器、虚拟机、Codespaces 都行——不要让 agent 在你的本机直接乱跑。
• 使用别人的隔离计算环境。 这是最便宜的安全防线。
• credential 最小权限。 给 agent 的是只读的数据库账号、只能访问测试桶的对象存储 key、只能看分析数据的 BI 账号。
• 如果 credential 能花钱，必须设预算上限。 这一条非常重要——YOLO mode + 没有预算上限 = 可能产生几千上万美元的事故。
• 尽量用 test/staging 数据，不用生产数据。

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

再说狠一点——生产数据 + agent = 一个高风险组合。 哪个团队还在这么干，就是在赌运气。

这不是危言耸听。我在这里给你一个判断标准——任何让 agent 直接接触生产数据的团队，都在等待一次大事故。 时间问题，不是会不会的问题。

---

十六、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 时代一个非常特别的工程能力——它能把“模糊需求”转成“可执行规格”。

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

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》里，Simon 把“会用 AI 的工程师”的画像描得更清楚——

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

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

结论很清楚——AI 时代不会减少对 senior 工程师的需求。它会减少对“亲自敲键盘”的需求，但会大幅增加对“判断、设计、审查、约束 agent”的需求。

工程界对这件事普遍认知不足。很多公司还在讨论“AI 会不会让我们少招程序员”——这是错的问题。正确的问题是——

• AI 让我们能不能更稳定地交付？
• AI 让我们的代码可不可维护？
• AI 让我们的工程纪律更强还是更弱？
• AI 让我们对自己产品的把握更深还是更浅？

如果对这些问题的答案都是“更好”，那你应该多招 senior 工程师让他们带 agent 团队。如果对这些问题的答案都是“更差”——那你不是用错了 AI，你是用错了工程师。

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

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

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

---

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

我把 Simon 的整套压缩成一份非常硬的 SOP。我用最直接的语气讲，希望你抄走用——

第一，开始之前先准备环境。

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

第二，新 session 先让 agent 进入上下文。

让它先跑测试，看 Git 最近变化，读相关测试，必要时用 subagent 探索代码库。不要一上来就让它写代码。

第三，新功能用 red/green TDD。

先写失败测试，再写实现，让测试变绿。测试必须先失败，红灯阶段不能跳过。

第四，测试通过后做 manual testing。

库函数用 python -c；API 用 curl；Web UI 用 Playwright 或 Rodney；需要视觉判断时让 agent 截图自己检查。自动测试不是“亲眼看见”，亲眼看见才是亲眼看见。

第五，让 agent 留证据。

用 Showboat 或类似机制记录命令、输出、截图。reviewer 审查的不只是代码，还有 agent 的行为证据。

第六，把发现的问题固化为测试。

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

第七，提交前自己 review。

不要把 agent 输出原封不动丢给别人。PR 要小、可解释、有上下文、有测试证据、有手动验证说明。agent 写的 PR 描述也要审。

第八，复盘并沉淀。

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

这八步是底线。做不到这八步的团队，没资格说自己在做“agentic engineering”。

---

十九、我对中文团队再说几句

Simon 写文章是面向英文世界的工程文化。他默认很多东西在那边不需要解释——比如 code review 的严肃性、PR 的标准粒度、开源 maintainer 的责任感。在中文团队的语境里，有几个坑需要额外点出来。

考核指标别搞错方向。 很多公司今年开始用“agent 生成代码量”作为效率指标。非常危险。 一旦“代码量”变成考核维度，工程师就会有动力把 agent 的输出原样丢出去——涨 KPI 嘛。正确的考核维度是“被证明可工作并可维护的功能数量”，不是“代码行数”。 哪个公司还在用行数考核工程师，请尽快取消。

code review 文化得升级。 在一些组织里，code review 本来就走形式，作者自己也不严格审查。AI 时代如果还按这个走，就会出大事。要主动升级 review 的 SOP：要求每个 PR 附带自动化测试结果、手动测试说明、关键实现解释。

“AI 代码合规”会变成新的岗位职责。 谁来确保团队提交的 agent 代码没有泄露敏感数据、没有引入未授权依赖、没有违反架构规范？这些都需要专门的人或者专门的 CI 规则盯着。很多团队会发现自己缺一个“AI 编程治理岗”，这个岗位的雏形就是 Simon 说的 agentic engineering pattern owner。

老工程师的价值要重新定义。 AI 时代，老工程师最大的价值不是“自己写代码”，而是把判断、经验、品味沉淀成 agent 能用的资产——AGENTS.md、structural test、pre-commit hook、custom linter、onboarding doc。经验停在脑子里是负债，沉淀成系统资产才是真资产。

实习生和初级工程师需要“AI 带教”。 不要让他们直接 vibe coding——他们会以为这就是工程师的全部工作。要让他们的第一份工程肌肉记忆就是“用 AI 还要负责任”。

这几条的共同主题是——把工程纪律从“个人习惯”上升到“组织能力”。 Simon 提供的是个人级别的 pattern，把它扩展成组织级别的制度，是中国团队下一步必须做的功课。

---

二十、结语：把 AI 编程拉回了软件工程，这是 Simon 真正的贡献

讲到这里，可以收尾了。

Simon Willison 的独特性不在于“他说 AI 很强”，也不在于“他说 AI 很危险”。这两种声音都很多。Simon 真正有价值的地方，是他把 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 代表的是下一阶段——“现在我们该如何证明这些代码值得交付？”

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

AI 让写代码的成本下降了，但软件工程从来不只是写代码。

真正稀缺的，是知道该写什么、怎样证明它工作、如何让别人安全地接手、如何让系统在未来继续可维护。

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

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

最后一句话，留给所有正在用 AI 编程的人——

把代码扔给同事 review 之前，请先扔给你自己。

意思是：你自己先审过、自己先跑过、自己先手动试过、自己先看过截图、自己先确认过边界——再发 PR。

如果你做不到这一条，请你不要用 AI 辅助提交大段代码。因为你不是在做工程，你是在污染团队。

如果你做得到这一条，那么——欢迎进入 agentic engineering。这是软件工程在 AI 时代的新姿态：把 AI 当合作者，而不是免责符。

剩下的，按 Simon 的 pattern 走，一步一步来。

先跑测试。

就这四个字。

把它做实。其他的会自然长出来。

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，都会自然长出来。

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

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

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

先把话挑明

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

这一句话有两层意思。

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

这件事意味着两件事：

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

为什么必做？

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

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

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

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

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

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

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

具体怎么做？

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

什么是行为证据？

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

Simon 反复推荐的几个做法：

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

测试全绿 ≠ 用户能用。

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

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

---

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

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

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

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

Simon 的解法仍然是 pattern 化：

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

收尾了。

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

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

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

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

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

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

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

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

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

First run the tests.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

十六、文本是 agent 的血液

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

这个理解不对。

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

后来他们做了两件事：

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

换一种说法：

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

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

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

---

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

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

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

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

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

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

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

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

由此引出一个判断标准：

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

落到操作层面：

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

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

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

---

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

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

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

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

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

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

翻译成一个决策框架：

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

用起来很简单：

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

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

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

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

---

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

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

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

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

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

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

想想看：

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

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

---

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

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

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

后来做了两件事：

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

Ryan 把这事叫 garbage collection。

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

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

底层逻辑是这样的：

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

最后一条心智模型：

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

1

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

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

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

2

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

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

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

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

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

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

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

3

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

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

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

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

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

4

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

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

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

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

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

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

5

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

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

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

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

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

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