前两天我写了《Clawdbot刷屏AI圈，我为什么劝你别急着用》，讲的是风险。
这篇讲的是：那到底该怎么用？
先说说我的感受。
过去这一年，我每天都在用Claude Code写代码。用得越多，越能感受到一种说不清的”摩擦感”——有时候AI特别顺手，有时候又莫名其妙地卡壳；有时候一次就对，有时候来回修补三四轮。
我知道问题出在我身上，但一直说不清楚到底是哪里不对。
直到我听完Peter Steinberger这114分钟的访谈。
他用了一个词：摩擦（friction）。
“写代码时你能感受到摩擦，这正是好架构诞生的方式。我在 prompt 的时候也有同样的摩擦感。我能看到代码飞过去，能感知花了多长时间，能感觉 agent 有没有在’顶你’，能看出来生成的东西是杂乱的还是有结构的。”
终于有人把我模糊的感受清晰地说出来了。
这不是玄学，这是可以被理解、被优化的工程问题。
感谢Peter，让我终于明白2026年AI Agent工程化该怎么做。
1月29日晚，知名技术播客《The Pragmatic Engineer》跟OpenClaw创始人Peter Steinberger进行了114分钟的深度对谈。
📌 项目名称演变： 这个项目经历了快速改名——2025年末首发时叫 Clawdbot，2026年1月27日因Anthropic商标请求改名为 Moltbot（”Clawd”与”Claude”过于相似），1月30日又更名为 OpenClaw，强调其开源社区属性。目前官方仓库已超过 10.8万 Stars。
Peter不是普通开发者。他创办的PSPDFKit是iOS开发圈的知名PDF框架，2021年获得约€1亿战略投资。13年创业，3年”燃尽”，去年5月开始做这个项目，一开始担心大厂会很快做出来，结果大厂迟迟没动作，最后自己忍不住下场了。
播客前半段是项目诞生的故事。后半段才是重点——Peter毫无保留地分享了他使用AI Agent的实战经验。
我从这114分钟里提炼出了5个可以直接应用的核心洞察。
洞察一：验证闭环是唯一的秘密
这是整场对话中最有价值的技术洞察。
“高效使用 coding agent 的关键，其实就一句话：你得把反馈闭环建好。它必须能自己测试、自己 debug，这是最大的秘密。”
高效使用 Coding Agent 的关键：让 AI 能自己测试、自己 debug
Peter解释了一个很多人困惑的问题：
为什么AI在写代码上表现很好，但在写作上常常平平？
答案很简单：代码可以被验证——可以编译、跑测试、检查输出。而创意写作很难验证。
他举了一个真实案例：
“昨天我在 debug 一个问题：Mac App 找不到远端 gateway，但同样的 TypeScript 代码却可以。Mac 应用调试特别烦——要 build、启动、点界面、看效果，再告诉它不行。”
“现在我直接说：你给我建一个 CLI，专门用来 debug，走完全一样的代码路径。然后它就开始跑，一个小时后搞定，告诉我这里有 race condition，那里有配置问题。”
关键操作：
| 传统方式 | Peter的方式 |
|---|---|
| 手动调试Mac应用 | 让Agent建一个CLI来debug |
| 反馈周期：分钟级 | 反馈周期：秒级 |
| 人工判断对错 | Agent自己验证 |
“哪怕是现在，我在做网站时，也会把核心逻辑设计成可以通过 CLI 跑起来，因为浏览器里的反馈循环实在太慢了，你需要一个能高速迭代的 loop。”
这个洞察的实操价值：
在给Agent布置任务时，先想清楚它怎么验证自己做对了。如果没有验证机制，Agent的输出质量会大打折扣。
洞察二：不是指挥，是对话
很多人把AI当成一个”执行命令的机器”。Peter的用法完全不同。
“你并不是在’指挥’它，而是在对话。”
他的工作流程是这样的：
“我会说，我们看看这个结构，有哪些选项？这个特性考虑过没有？因为每一轮 session，模型一开始对你的产品是零认知的，你得给它一些指路标志，让它去探索不同方向。”
关键技巧：刻意”欠提示”
这是一个反直觉的做法：
“我通常从一个想法开始，甚至会刻意’欠提示’ Agent，让它做点出乎意料的事，给我新想法。可能 80% 的结果都不怎么样，但总会有一两个点让我意识到’这个角度我没想过’。”
对话 vs 指挥：
| 指挥模式 | 对话模式 |
|---|---|
| “帮我写一个用户登录功能” | “我们聊聊用户认证，有哪些选项？” |
| 期待一次性输出正确结果 | 期待获得新想法，然后迭代 |
| Agent是执行者 | Agent是协作者 |
“你并不需要什么 plan mode，我就是一直聊天，直到我说’build’，它才会真的开始构建。有一些触发词，它们确实都挺’饥渴’的，但只要我说’我们讨论一下’或者’给我一些选项’，它们就不会动手。”
这个洞察的实操价值：
下次用AI时，试试不要一上来就发指令。先跟它”聊聊”，让它帮你探索选项。你会发现它能给你意想不到的视角。
洞察三：像星际争霸一样并行调度
Peter的日常工作状态：同时跑5到10个Agent。
Peter 的工作方式：同时调度多个 AI Agent，在心理上比单纯写代码更累
“我不再是管一个人，而是同时在管五个、十个，它们各自都在干不同的事情。我在脑子里不停切换，从这个子系统跳到那个功能，又跳到另一个地方。”
他的工作节奏：
- 设计一个新子系统或新功能
- 知道 Codex 大概需要 40 分钟到 1 小时才能跑出来
- 把方案想清楚，交给它去”煮”
- 转身去干别的任务
- 过一会儿回来看结果
“这个在煮，那个也在煮，过一会儿我再回来看其中一个。”
他用了两个比喻：
比喻一：星际争霸
“有主基地，也有分基地，不断给你输送资源。”
比喻二：国际象棋大师同时下二十盘棋
“走到一盘前，看一眼局面，做个决策，遇到强对手就多停一会儿。”
但这并不轻松：
“这其实更累。在心理层面上比单纯写代码更累。因为你的大脑一直是满负荷的，你在’扩展自己’。”
这个洞察的实操价值：
如果你的Agent任务需要等待（比如Codex跑复杂任务要40分钟），不要干等。开多个终端，同时跑多个任务。你的角色从”写代码的人”变成”调度多个Agent的人”。
洞察四：Claude Code vs Codex——真实对比
Peter从Claude Code的重度用户变成了Codex的重度用户。他的对比非常具体：
“一开始是 Claude Code，然后我彻底上瘾了。但现在在复杂应用里写代码，Codex 明显更好。”
| 对比维度 | Claude Code | Codex (OpenAI) |
|---|---|---|
| 上下文理解 | 可能读三份文件就自信开始写代码 | 会安静地读十分钟文件 |
| 首次成功率 | 第一次跑往往不通，需要来回修补 | 绝大多数时候一次就对 |
| 工作节奏 | 快速反馈，更”互动” | 更慢，但结果更稳 |
| 适用场景 | 通用计算、快速原型 | 复杂应用、大型代码库 |
Claude Code的问题：
“用 Claude Code 的时候，你得用一种不太一样的方式工作。它确实更快，但生成的东西往往第一次跑不通，可能忘了同步改另外三处，要么直接 crash。”
Codex的优势：
“Codex 会花十倍的时间去理解上下文。如果你只用一个终端，这体验确实让人受不了，但我更愿意要这种方式——因为我可以同时跑多个。”
Peter的选择逻辑：
“现在用 Codex，绝大多数时候它一次就对了。”
这个洞察的实操价值：
- 快速原型、探索性任务 → Claude Code
- 复杂应用、需要理解大型代码库 → Codex
- 关键： 如果选Codex，一定要同时开多个任务，否则等待时间太痛苦
洞察五：Prompt比代码更有价值
这是一个让很多传统开发者不舒服的观点：
“当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。”
AI 时代代码的 PR 本身价值在缩水，Prompt 反而才是更高信号量的东西
Peter现在要求所有提交代码的人必须附带prompt：
“有些人会照做，而我会花更多时间读 prompt，而不是读代码。”
“对我来说，prompt 才是更高信号量的东西：你是怎么得到这个结果的？你具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。”
对提需求方式的改变：
“如果有人想要一个新功能，我会让他先写一个 prompt 需求，把它写清楚。因为我可以直接把这个 issue 丢给 agent，它就会帮我把功能做出来。”
好的Prompt不是预先设计的：
很多人以为Peter有精心设计的Prompt模板。事实正好相反：
“这并不是提前精心预备好的，而是跟 Agent 之间的协作规划出来的。”
这个洞察的实操价值：
- 开始记录你的Prompt，它比代码更有复用价值
- 提需求时，先想清楚怎么跟Agent描述，而不是怎么写代码
- PR review时，关注”这个结果是怎么得到的”，而不只是”代码对不对”
两个反行业共识的观点
除了上面5个实操洞察，Peter还抛出了两个让人印象深刻的”反共识”观点：
反共识一：瀑布式 + AI = 精致的混乱
“我看到很多人会先搭一整套复杂的编排层：什么自动建工单、Agent 处理工单、Agent 再给另一个 Agent 发邮件，最后堆出一坨精致的混乱。图什么？”
他直接批评了AI圈常见的”先设计spec，再让Agent执行”的做法：
“他们可能花几个小时设计 spec，然后机器用一天把东西’造’出来。我不信这套能行。这本质上还是瀑布式软件开发，我们早就知道它行不通。”
他的替代方案：像雕塑一样构建
“从一块石头开始，不断凿，慢慢一尊雕像从大理石里浮现出来。这就是我对’构建’的理解。”
反共识二：大公司要用好AI，需要先来一次大重构
新世界需要的是那种有完整产品视角、什么都能干的人——而大公司往往不存在这样的角色
“我觉得大公司会非常难以高效地采用 AI，因为这要求彻底重塑公司运作方式。”
“比如在 Google，你要么是工程师，要么是经理；想同时决定 UI 长什么样，这个角色不存在。但新世界需要的是那种有完整产品视角、什么都能干的人，而且数量要少得多。”
“理论上，公司规模可以砍到原来的 30%。”
核心要点速查表
| 洞察 | 一句话总结 | 实操行动 |
|---|---|---|
| 验证闭环 | 让Agent能自己验证对错 | 布置任务前，先想清楚验证机制 |
| 对话而非指挥 | 刻意”欠提示”获取新想法 | 先聊选项，再说build |
| 并行调度 | 像星际争霸一样管理多个Agent | 开多个终端，同时跑多个任务 |
| 工具选择 | CC快但需修补，Codex慢但准 | 复杂任务用Codex，快速原型用CC |
| Prompt > Code | Prompt才是高信号量的东西 | 开始记录和复用你的Prompt |
写在最后
上周我写Clawdbot的风险，有人问：”那到底该怎么用AI Agent？”
Peter的这场114分钟访谈，给出了一个经过实战检验的答案：
不是把AI当成一个执行命令的工具，而是把它当成一个可以对话的协作者。
不是追求一次性输出完美结果，而是建立验证闭环，让它自己迭代。
不是一个任务一个任务地串行执行，而是像调度一支团队一样并行管理。
这需要一种心智模型的转变。正如Peter所说：
“这一年里，我学到的系统架构和设计知识，比过去五年加起来都多。这些模型里塞进了巨量知识，几乎任何问题都能问到答案，前提是你得知道该问什么。”
前提是你得知道该问什么。
这可能是整场访谈最重要的一句话。
预告： 受Peter的启发，我正在用Codex并行调度的方式开发一个自己日常急需的工具——Voice Real-time Translation（实时语音翻译）。从验证闭环的设计到并行任务的调度，我会在后续文章中分享完整的开发过程和踩坑经验。敬请期待。
本文部分内容整理自 The Pragmatic Engineer 播客对 Peter Steinberger 的专访（2026年1月29日）。
参考链接：https://www.youtube.com/watch?v=8lF7HmQ_RgY
相关阅读
Moltbot 系列
- Clawdbot刷屏AI圈，我为什么劝你别急着用 - 安全风险深度分析
AI Agent 系列
- 通用AGI工具已经到来 - Claude Code 深度分析
- 你觉得AI不行？也许是你的’使用姿势’还停在2023年 - AI 使用姿势演进
联系方式
如果你对 AI Agent 实战经验有问题或想法：
- 邮箱：[email protected]
- 微信：winnielove2020
- 博客：https://junxinzhang.com
特别欢迎讨论：
- 你是怎么构建验证闭环的？
- Claude Code vs Codex，你的选择是什么？
- 并行调度多个Agent的实际体验
- Prompt的复用和管理方法
关注我，后续分享更多 AI Agent 认知、洞察以及使用方式。
知道该问什么，比知道怎么问更重要。
Clawdbot刷屏AI圈，我为什么劝你别急着用