风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。
引子：一句让工程师不安的话
“I ship code I don’t read.”
我发布我不读的代码。
这句话出自 Peter Steinberger——OpenClaw 的创作者、PSPDFKit 创始人——在 The Pragmatic Engineer 2026 年 1 月的访谈里。采访者 Gergely Orosz 上来就抛出一个数字：Peter 一个人在 1 月做了 6600+ 次提交，提交记录看起来“像一家公司”。
这句话之所以刺耳，是因为它挑战了过去二十年里工程师最核心的安全感来源——逐行阅读、逐行理解、逐行掌控。对很多人来说，“读代码”不仅是发现 bug 的手段，更是一种心理锚点：我读过了，所以我敢发布。
但 Peter 不是在炫技式地“摆烂”。他在描述一种正在成形的新范式：当代码的大部分由 Agent 生成时，工程能力的中心会从“写代码”迁移到“设计系统 + 构造验证闭环 + 组织安全边界”。
这篇文章要做的事情，就是把他所谓的“agentic engineering（代理式工程）”拆成六个核心洞察，用跨学科的框架去验证它们，然后把它们翻译成你可以在自己项目中操作的具体流程。
一、信任迁移：从“我读过了”到“系统替我证伪了”
1.1 传统工程的信任三角
在没有强 AI 辅助之前，我们对代码质量的信心来自一个三角结构：
- 写的人是谁（经验、历史表现）
- 审的人是谁（code review 的严谨程度）
- CI/CD 是否可靠（能否阻止坏改动进入主干）
三条腿的公共支撑点是：人读代码。读代码既是发现 bug 的手段，也是工程师建立“掌控感”的仪式。
1.2 瓶颈翻转：当产出速度超过阅读速度
一旦 Agent 能在短时间内生成大量改动，“读代码”就从质量保障手段翻转为产能瓶颈。你进入一种矛盾状态：功能产出更快了，但理解能力跟不上，于是系统风险不降反升。
Peter 的回答不是“放弃质量”，而是把质量保障的支撑点从“阅读”换成“可重复的自动验证”：编译、lint、运行、测试全部由 Agent 自己跑通，直到现实同意它的输出。
1.3 Popper 的证伪主义：为什么这条路走得通
科学哲学家 Karl Popper 提出过一个改变了整个科学方法论的观点：一个理论的价值不在于你能“证实”它，而在于你能“证伪”它。 你观察一万只白天鹅也无法证明“所有天鹅都是白的”，但一只黑天鹅就能推翻它。
代码同理。你永远无法通过“阅读”来证明代码是正确的——因为你可能漏看了一行。但你可以通过设计足够好的测试来尝试“证伪”它——如果所有测试都没能让它失败，你就有合理的信心。
Peter 在访谈里给了一个直觉化的论证：为什么模型“写代码”通常比“写文章”更可靠？不是因为它更聪明，而是因为代码更容易验证——能编译、能运行、能测试，反馈回路足够短。写文章没有编译器，你只能靠“读”来判断好坏。
这就是他所谓“闭环”（close the loop）的底层逻辑：不是信任 Agent 的智力，而是信任系统的证伪能力。
1.4 一个反直觉的副产品
当你认真把“闭环”作为第一原则，你会被迫把系统设计得更可测试、更可观测、更模块化。Peter 甚至说，自己现在“不亲手写代码”反而写出了更好的代码——因为测试与文档都更到位了。过去他并不喜欢写测试和文档，现在 Agent 把这些“苦活”变成了流程的一部分。
这就是 Deming 质量管理哲学在 Agent 时代的翻版：不要在生产线末端“检验质量”（靠人读代码），而要在生产过程中“构建质量”（靠自动验证闭环）。
二、你不再是码农，你是验证系统的建筑师
2.1 角色重新定义
如果把 Peter 的工作方式浓缩成一句话：
你负责：目标、约束、品味、架构、验收标准。
Agent 负责：实现、跑通、修复、补齐测试与文档。
他在访谈和个人博客里描述了几个标志性习惯：
- 并行跑 5–10 个 Agent，保持“流状态”，减少等待带来的碎片化。
- 更偏爱 Codex 做长任务（沉默阅读大量代码后的实现），Claude Code 互动性强但频繁回问会打断节奏。
- CLI-first 的验证习惯：即便做 UI/桌面应用，也先造一个 CLI harness 把核心逻辑走通，让反馈回路变快。
- 为 Agent 设计代码库：代码结构、命名、文档组织不再只是“让人舒服”，而是“让 Agent 易读、易改、易验证”。
2.2 Boyd 的 OODA 循环：理解“速度”的本质
美国空军战略家 John Boyd 提出过著名的 OODA 循环：观察（Observe）→ 判断（Orient）→ 决策（Decide）→ 行动（Act）。Boyd 的核心洞察是：赢得空战的不是飞机更快的那个人，而是 OODA 循环更快的那个人。 你的循环速度越快，你就能越早看到对手的意图、做出调整、抢占先机。
Peter 的工作流本质上是在极致压缩 OODA 循环：
- 观察：Agent 编译/运行/测试，把结果反馈回来
- 判断：Peter 看结构与边界是否正确
- 决策：修正方向或放行
- 行动：Agent 继续下一轮实现
当你并行跑 5–10 个 Agent 时，你不是在“多线程写代码”，而是在同时转动多个 OODA 循环。6600 次提交的背后不是手速，而是循环速度。
2.3 “让 Agent 自己煮熟问题”
访谈里有一个典型案例：Peter 调试 macOS 应用时发现一个“远程 gateway 找不到”的问题，UI 调试太慢，于是让 Agent 先造一个 CLI 调试入口，复用同样的代码路径，快速迭代。Agent 用一小时左右“自己煮熟了”这个问题，还指出了 race condition 与配置错误。
这背后是一条非常通用的工程策略：
当反馈回路太慢时，先写一个让回路变快的工具。
对 Agent 尤其重要：UI、手工点击、人工复现都很慢；CLI、脚本、可重复环境才快。如果你把这条策略贯彻到底，你会得到一种“Agent 友好型”系统——每个子系统有 CLI 入口，每个 bug 能被脚本化复现，每个修复能被回归测试锁住。
三、PR 变 Prompt Request：协作对象的革命
3.1 一个深刻的语义转换
Peter 在访谈里明确说过：他更关心 PR 背后的 prompt，而不是代码本身。他把 PR（Pull Request，拉取请求）重新定义为 Prompt Request（提示请求）。
这不是文字游戏。它背后是协作对象的根本转换：
- 传统 PR：协作围绕“代码差异（diff）”展开。你看 diff，讨论 diff，审查 diff。
- Prompt Request：协作围绕“意图与验证路径”展开。你看 prompt 如何引导 Agent 得到结果，验证了什么，做了哪些权衡。
3.2 Diff 是投影，Prompt 才是过程
当代码主要由 Agent 生成时，diff 常常只是最终结果的投影——你很难从 diff 里看出做了哪些权衡，也很难看出在什么地方“引导过模型”，更难复现“如果要走另一条路，该怎么问”。
Prompt（或更广义的对话记录）反而是一种新的工程资产：它记录了意图、约束、方案演化过程，也记录了你如何让模型收敛到可用输出。
这和数学领域的一个观念不谋而合。数学家不只关心定理本身，更关心证明过程——因为过程里包含了思路、方法和可迁移的技巧。同样，在 Agent 时代，prompt 就是你的“证明过程”，它比最终的代码更有学习和复用价值。
3.3 Prompt Request 在团队里应该长什么样
OpenClaw 的贡献指南已经把这件事制度化：欢迎 AI 辅助 PR，但希望贡献者标注 AI 使用情况、说明测试程度，并附上 prompts 或 session logs。
如果你要在自己的团队引入“Prompt Request”概念，我建议要求四件事：
- 目标：要解决什么问题（对用户/业务的价值）
- 约束：兼容性、安全、性能、依赖限制
- 验收：可验证的标准（最好附测试/脚本）
- 证据：跑过哪些验证（gate 输出/截图/日志）
Prompt Request 不是“提示词比赛”，而是新的工程变更单。
四、项目改造指南：把代码库变成“Agent 可闭环”的形态
4.1 失败的根因不是模型，是代码库
很多人用 Agent 写代码失败，归因于“模型不行”。但 Peter 指出一个更常见的真因：项目形态不适合 Agent。
想象一下你是新入职的工程师，走进一个这样的代码库：命令不可预测，测试跑一次要 20 分钟，依赖不透明，文档缺失，上下文全在老员工脑子里。你也会崩溃。Agent 面对的困境完全一样——只不过它不会抱怨，只会给你一堆不靠谱的输出。
Peter 的做法是把“Agent 需要的规则”写成文件。OpenClaw 仓库里的 AGENTS.md 是一份典型的“给 Agent 的项目说明”——包括项目结构、测试命令、PR 流程注意事项。
4.2 Conway 定律的 Agent 版
1967 年，程序员 Melvin Conway 提出了一条后来以他名字命名的定律：组织设计出的系统，其结构必然是该组织沟通结构的翻版。 一个三个团队的公司会写出三模块的软件。
这条定律在 Agent 时代有一个推论：如果你的代码库是为“人与人沟通”而设计的，那 Agent 用起来一定别扭；你需要为“人与 Agent 沟通”重新设计代码库的结构。
具体怎么做？Peter 在访谈中给出了五个最小基线：
- 一键验证命令：把 lint + build + unit + integration 组合成
make gate或pnpm gate这种“单入口”。Peter 把它叫“full gate”——一条命令决定生死。 - CLI harness：核心逻辑必须能在命令行跑起来，输出可比对、可断言。这是闭环速度的命脉。
- 清晰的目录与命名：让 Agent 能通过模式识别找到入口。不要让 Agent 面对一个“只有老员工才知道 X 在哪”的代码库。
- docs/ 目录：把架构与关键约束写进去。让 Agent “读文档胜过读历史对话”。
- 可观测性：日志、错误输出、最少的 trace，让 Agent 自己定位问题而不是在黑暗中瞎猜。
你会发现：这些改造本质上也在提高“人的可维护性”。只是过去我们为了新人做，现在为了 Agent 做。逻辑完全一样。
五、工作流全景：从一个想法到合并上线
5.1 设计阶段：用对话代替规格文档
Peter 反复强调：不要把 Agent 当成一次性“提示→生成→结束”的黑箱，要把它当成一个会犯错但可以持续对话的合作者。
流程是：你抛目标 → 它给方案与 tradeoff → 你挑刺、补约束 → 它修正 plan → 直到方向对了，再一句“build”进入实现。
这里的关键不是某种“plan mode”的仪式，而是把设计阶段显式化。你要问的问题通常不是“怎么写代码”，而是：这件事的边界是什么？哪些模块必须保持稳定？性能/兼容性约束是什么？
Peter 举过一个典型例子：有人抱怨模型用了旧 API，但根因往往是“你没有明确约束目标平台版本”。模型只是在缺信息时做了默认假设。问题出在你的 prompt，不是模型的智力。
5.2 验收标准：从“感觉”转成“判定”
这一步是闭环的核心。传统工程中我们也会写 acceptance criteria，但常常偏业务语言——“页面加载要快”“交互要顺滑”。Agent 时代，最有效的验收标准要更接近可执行的验证：
- 给出输入 → 期待输出
- 给出步骤 → 期待日志/状态变化
- 给出性能指标 → 期待 benchmark 报告达标
把“评审代码”前移成“评审验收规则”——这就是 Peter 所说的“我不读代码”的真正含义。
5.3 并行执行：把等待时间变成吞吐量
Peter 同时排队跑多个 Agent（5–10 个），按任务类型分配：
- A 类（长任务/沉默执行）：大重构、全套测试、文档生成、迁移脚本。更适合 Codex 这类“愿意读很多文件、执行很久”的模式。
- B 类（短任务/高互动）：UI 微调、小 bug 修复、配置变更。更适合交互性强、响应快的模式。
- C 类（探索任务/故意模糊）：Peter 会“刻意 under-prompt”，让模型探索他没想到的路径。产出不一定直接合并，但能拓宽方案空间。
这里的难点不是技术，是人的心智负担。同时管理多个 Agent 的上下文比单线程写代码更累。分类是缓解负担的关键——你不需要同等注意力投入到每一个 Agent 上。
5.4 实现阶段：盯结构，不盯每行
当 plan 与验收标准明确后，Peter 让 Agent 执行实现，自己把注意力放在四件事上：
- 模块边界是否被破坏
- 接口是否符合预期
- 依赖是否靠谱
- 是否引入了让未来更难验证的复杂度
这就是“架构讨论替代代码评审”的含义：不是不评审，而是评审对象从“每行代码”变成了“结构与边界”。
5.5 验证阶段：本地 gate 优先
Peter 不太愿意等远端 CI——Agent 本地已经把测试跑完了。他倾向于本地验证通过就合并。
我建议把“本地 gate”做成两层：
- 快 gate（1–3 分钟）：lint、typecheck、关键 unit tests
- 慢 gate（10–30 分钟）：integration、e2e、端到端
让 Agent 默认跑快 gate；涉及关键路径时再跑慢 gate。重要的是：gate 命令必须稳定、单入口、可重复。否则闭环就会断裂。
5.6 合并与发布：线性演进，减少状态爆炸
Peter 很多项目会“直接 commit 到 main”，不喜欢把项目切成多个“并行世界”，因为那会增加认知负担。当然他也承认这有“单人作战”的前提。
可行的折中方案是：Agent 只在 feature branch 上工作，但 feature branch 只允许“短命、窄范围”，每天固定窗口做 rebase 与合并，对外发布频率提高但每次变更范围更小。
核心原则是：让心智模型尽量单一，减少状态爆炸。在多 Agent 并行时代，合并冲突与分支漂移会比过去更痛苦。
六、安全不是附加题，是闭环的一部分
6.1 “闭环 ≠ 安全”
测试能证明“功能正确”，但不一定能证明“不会泄露数据”“不会被注入”“不会越权”。当 Agent 从“只生成代码”变成“能执行命令、能读写文件、能连接消息渠道”时，风险会指数级放大。
OpenClaw 的官方 Trust 页面把风险说得很直白：AI agent 不只是“执行代码”，它会解释自然语言、做决策、调用工具；因此会面临 prompt injection、间接注入、工具滥用、身份风险等一系列新型攻击面。
6.2 Charles Perrow 的“正常事故”理论
社会学家 Charles Perrow 在研究三里岛核事故后提出了 “正常事故”理论：在足够复杂且紧耦合的系统中，事故不是异常，而是系统的固有属性。你不能通过“修某个零件”来消除它，只能通过降低耦合度、增加缓冲、建立多层防御来减少它的破坏力。
Agent 系统天然具备“复杂且紧耦合”的特征——它同时拥有语言理解、工具调用、文件读写、网络访问的能力，任何一个环节被攻击都可能导致连锁反应。
这意味着 agentic engineering 的成熟形态必须把安全也纳入闭环：不是“写完功能再加安全”，而是像测试一样，从第一天就构建进工作流。
6.3 实操建议：四层防御
借鉴 OpenClaw 的安全策略和“高可靠性组织”（High Reliability Organizations）的研究，我建议至少做到：
- 默认 deny，按需 allow：Agent 不应该默认拥有所有权限。
- 高风险动作需要确认或人工审批：支付、删除、发送敏感信息这类不可逆操作，必须有人在回路中。
- 关键工具调用要可审计：日志 + 可追溯，出了问题能回溯。
- 插件/技能要有供应链治理：扫描、签名、来源可信。OpenClaw 已经与 VirusTotal 合作对技能市场进行扫描。
七、能力迁移：未来工程师的价值锚点
7.1 从“写代码”到“让系统可验证、可演进、可控”
Peter 并没有否认“写代码”能力的价值。他只是把它重新定位：
- 过去：写代码本身就是价值。
- 现在：写代码更像中间工序；价值在于系统理解、架构判断、产品品味、验证能力。
他也谈到为什么一些资深工程师会抵触：很多人缺少“带团队后被迫放下完美主义”的经验，不习惯在代码风格不完全如愿时仍然推进目标。而这种“放下”在与 Agent 合作时反而变成关键能力。
7.2 Polanyi 的默会知识
匈牙利裔英国哲学家 Michael Polanyi 提出过一个著名概念：默会知识（tacit knowledge）——“我们知道的比我们能说出来的多。” 一个经验丰富的工程师对系统的理解，很多是结构性的、直觉性的、无法完全用语言表达的。
Peter 之所以能“少读代码也能推进”，一个关键前提是他对系统有足够深的默会知识。这种结构性理解不需要逐行阅读来维护，它是在反复与系统交互的过程中积累的。
这给新人的路线指向了三件事：
- 用 Agent 辅助你读代码、读架构、读历史决策——把 Agent 当成“无限耐心的导师”。
- 练习把需求写成可验证的 acceptance criteria——这是与 Agent 协作的核心技能。
- 练习把系统改造成“可被验证”的形态——测试、CLI、日志、脚本。
八、团队落地：你要改的不是工具，而是组织默认假设
如果你的团队想“上 AI、上 Agent”，最常见的失败路径是：把 Agent 当成更强的 autocomplete，却继续沿用旧流程。
Peter 在访谈里给出的方向，是四个“流程重构点”：
重构点一：评审对象变了
从“逐行 diff”转为“验收标准 + 关键边界”。这不是降低要求，而是把注意力重新分配到杠杆最高的地方。
重构点二：CI 角色变了
远端 CI 不再是唯一真理，本地可重复 gate 变成主战场。远端 CI 更像兜底与审计。
重构点三：文档角色变了
docs 不再是“给新人看的”，而是给 Agent 与人共同维护上下文的“共享记忆”。当你的文档足够好，Agent 在没有你口头解释的情况下也能完成“定位—修改—验证—提交”的闭环。
重构点四：安全边界必须提前
当 Agent 能执行动作时，默认安全配置、权限控制、审计与供应链扫描必须像“测试”一样成为基本功——不是事后补，是第一天就建。
结语：把现实拉进循环里
“我发布我不读的代码”这句话如果脱离上下文，听起来像鲁莽。但放回 Peter 的工作流里，它更像一个工程宣言：
我不把信任建立在阅读上，而把信任建立在闭环上。编译器、测试、脚本、日志、真实运行结果，才是我相信的东西。
如果你只把 Agent 当成“更快写代码的工具”，你会被它的幻觉与不稳定折磨。如果你把 Agent 当成“能执行但必须被验证”的劳动力，你会开始重构你的项目、你的验证体系、你的协作方式。你会发现：你不是变懒了，而是被迫变得更系统、更严格、更关注结果。
用 Popper 的话说：从“试图证实”到“反复证伪”。
用 Boyd 的话说：从“追求绝对控制”到“加速 OODA 循环”。
用 Deming 的话说：从“检验质量”到“构建质量”。
而用 Peter 自己的话说——比所有理论都朴素：
让 Agent 自己跑通，让现实来当裁判。
这可能才是“agentic engineering”最有穿透力的一点：未来的工程能力，不是把每行代码写得更漂亮，而是把系统设计得更可验证、更可控、更能快速演进。
附录：Full Gate 清单（可贴在仓库根目录）
- lint / format（无自动修复遗留）
- typecheck / build（无 warning 当 error 的隐患）
- unit tests（全过）
- integration / e2e（涉及关键路径时必跑）
- 回归样例（golden files / snapshot / screenshot）
- 更新 docs（新增配置、行为变化、边界条件）
- 安全基线（secret 扫描、依赖审计、权限最小化）