当 AI 长出爪子

2026 年 2 月，我听了一期播客，主持人 Scott Hanselman 和一个叫 Peter Steinberger 的开发者聊他做的开源项目 OpenClaw。标题叫《The Rise of The Claw》——“爪子的崛起”。

这个名字选得好。过去三年我们跟 AI 的交互方式，本质上都是“对话”：你问它答，你写它改，你贴代码它帮你 debug。即便加上了“agent”的外衣，大多数时候它还是一个待在浏览器标签页里、等你来找它的东西。

OpenClaw 想做的不一样。它想让 AI 伸出爪子——进入你的设备、你的消息应用、你的文件系统，在你不打开浏览器的时候也“在场”。你可以在 Telegram 里跟它说“把我那台电脑桌面上的照片找出来发给我”，它就真的去做了。不是模拟，不是演示，是真的在你的 Windows 机器上执行命令、找到文件、打包发送。

这听起来很酷。但仔细想，也很危险。

爪子能抓取，也能抓伤。这正是这个项目有意思的地方：它迫使你认真面对一个大多数 AI 产品刻意回避的问题——当大脑在云端，身体在本地，控制权到底归谁？

一、把脑和手拆开

大多数人第一眼看 OpenClaw，会以为它就是“一个 LLM 接上了 Telegram”。但如果只是这样，它不值得谈。

OpenClaw 做了一个关键的架构决策：把系统拆成两层。一层叫 Gateway，一层叫 Node。

Gateway 是控制平面——管会话、管路由、管工具调用、管消息渠道接入。你可以把它理解为“大脑”，或者更准确地说，“调度中心”。它通常跑在一台你信任的机器上，比如一台 Mac mini，或者一台 Linux 服务器。

Node 是设备侧的“肢体”。它以原生应用的形态运行在你的具体设备上——你的 Windows 电脑、你的 iPhone、你的 Android 手机——把“这台设备能做什么”暴露给 Gateway。比如跑命令、读文件、开摄像头、录屏幕、发通知。

为什么非要拆开？

因为“思考”和“行动”的信任边界完全不同。

思考可以发生在云端。你调用 Claude、GPT、Gemini，把问题发过去，拿回答案，这个过程的风险是可控的——最坏的情况是对话内容被模型厂商看到。但行动不一样。执行命令、读写文件、访问摄像头，这些事情必须发生在你的设备上，而且必须是你授权的。

如果你把思考和行动绑在一起，做成一个单体应用，那么要么你把整个系统放在云端（意味着你的设备变成远端服务器的傀儡），要么你把整个系统放在本地（意味着你得在每台设备上都跑一个完整的大模型）。两种方案都很糟糕。

拆开之后，你可以让 Gateway 跑在一个相对安全的地方，长期在线；让 Node 只在需要的时候被调用，而且每个 Node 只暴露你允许它暴露的能力。Scott 的例子就是：Gateway 跑在 Mac mini 上，但他是 Windows 用户，于是他装了一个 Windows Node，只把文件访问和命令执行暴露出来。然后他可以在地球另一端，通过 Telegram 让 AI 去他的 Windows 电脑上找文件。

过去做这件事，你需要远程桌面、SSH、内网穿透，或者“打电话叫孩子帮忙”。现在变成了一句话。

但这个便利不是免费的。它要求你理解自己暴露了什么。

二、门槛就是安全

这引出了 OpenClaw 最反直觉的设计决策：它故意不做一键安装。

Peter 说，他刻意把安装流程保持在“你得会用终端、得读文档”的水平。结果出现了一个“简化安装的作坊产业”，有人把安装脚本一键化了，他对此非常不满。

这听起来像程序员的傲慢。但 Scott 给了一个让我停下来想了很久的类比：开源人工胰腺项目。

那是一个开源的闭环胰岛素泵系统——你的血糖传感器数据实时传入，软件自动计算并注射胰岛素。这个项目故意不提供一键安装，因为如果搞错了，后果是致命的。它要求你理解整个系统在做什么，然后自己组装、自己承担风险。

OpenClaw 的风险没那么极端，但逻辑类似：这个系统连接你的真实通讯渠道，可以执行命令，可以读写文件，可以处理敏感信息。如果你完全不理解它的能力边界就把它跑起来，出问题只是时间问题。

所以门槛不是 bug，是 feature。准确地说，门槛是“风险教育”：你必须亲手走一遍配置流程，才能理解自己到底在部署什么、暴露了什么、授权了什么。

这让我想到一个更普遍的规律。在过去，软件工具的趋势一直是“越简单越好”——降低门槛就是降低用户成本，这几乎是公理。但当工具从“帮你看信息”变成“替你做事情”，这个公理开始松动。一个能替你执行命令的工具，和一个只给你看搜索结果的工具，门槛的含义完全不同。

前者的门槛是安全成本。降到零，就是把枪递到不会用枪的人手里。

三、让 AI 学会闭嘴

OpenClaw 还解决了一个我一直觉得被严重低估的问题：让 AI 知道什么时候不该说话。

如果你把 AI 接入群聊，你会立刻遇到一个尴尬：它会对每条消息都回复。每一条。不管相不相关，不管有没有必要。就像一个疯狂抢话的人。

这不是模型笨——恰恰相反，是模型太“勤快”了。语言模型的默认行为就是生成文本；你给它输入，它就会输出。“不说话”反而需要额外的设计。

OpenClaw 的做法很巧妙：让模型在决定不回复时输出一个特殊的标记——NO_REPLY。然后系统的投递层识别这个标记，把整条输出吞掉。从外部看，AI 就是“选择了沉默”。

这件事听起来简单，工程上却不容易。因为在流式输出时，你可能先收到 NO_，再收到 RE——你必须把这些碎片过滤掉，同时又不能误伤正常文本里恰好包含这几个字母的情况。

但比工程细节更有趣的是这个设计背后的哲学：在一个“AI 在场”的世界里，沉默是一种能力，而不是故障。当你的助手每天跟你交互几十次，你不希望它每次都插嘴。你希望它像一个好同事——在场、可用、但知道什么时候该闭嘴。

Peter 更进一步：他让 AI 知道自己运行在什么系统里。模型知道当前的渠道是什么、用户能看到什么、当前用的是哪个模型、推理过程是否对用户可见。这不是为了让 AI “有自我意识”，而是为了让它做出恰当的交际判断。

Scott 描述了一个场景：当他在 Discord 群聊里打开“显示思考过程”时，朋友们能看到 AI 的内心独白——它在想什么、在犹豫什么。有人觉得 AI 在嘲笑自己。Scott 说“我感觉好裸”。

这不是技术问题。这是礼仪问题。而礼仪，在长期使用的系统里，比聪明重要得多。

四、谁拥有你的上下文

现在说到最核心的问题。

每次讨论 AI 隐私，人们总是在问“对话内容有没有被模型厂商看到”。这个问题重要，但在 agent 时代，它只是冰山一角。

当 AI 可以执行命令、读取文件、访问日历、查看健康数据、截取屏幕，这些工具输出全部会进入模型的上下文窗口。你的文件路径、命令输出、浏览器截图、通讯录——这些比聊天内容敏感得多，也具体得多。

所以真正的隐私问题不是“你有没有用云模型”，而是“谁拥有你的上下文”。

OpenClaw 对这个问题的回答分三层：

第一层：控制面本地化。 Gateway 默认绑定在本机回环地址。你的会话状态、路由配置、技能定义、日志，都在你自己的机器上。你可以备份、迁移、审计。你不需要依赖某个云服务来“记住”你的上下文。

第二层：行动在本地发生。 文件操作、命令执行、屏幕截取，这些事情通过 Node 在你的设备上完成。它们不需要先上传到云端再执行。你至少有机会在数据进入模型之前做筛选和脱敏。

第三层：推理按需混合。 OpenClaw 不要求你在本地跑大模型。它承认云端模型更强、更灵活。但它把推理当作一个可替换的组件——你可以用 Opus 做深度任务、Sonnet 做日常聊天、Haiku 做后台心跳，甚至接入本地模型做唤醒词识别。推理是服务，不是绑定。

Scott 在播客里问他的 AI 助手“你这周过得怎么样”，AI 回答说：我每天醒来都是全新的，但我会先读 memory、读 daily logs，所以我知道自己是谁，知道正在做什么。

这段话打动他，不是因为 AI 真的有了“感受”，而是因为那种连续性是真实的——它来自本地文件里的记忆资产，来自每天例行的读写循环。不是平台施舍的，而是你自己拥有的。

当你换模型、换设备、换部署方式，你仍然能保留“同一个助手”的连续性。这就是上下文主权的意义。

五、爪子的代价

访谈快结束时，Scott 说了一句很真诚的话：如果世界上没有那么多坏人，电脑本来就应该能替我们做酷的事。“Claw 的快乐”就在于它真的在为我做事。

我同意这个感受。但 Peter 接下来说的话更真实：他确实想做一个“黑客乐园”，不想限制任何人。但现实是，很多人不读文档、乱改配置，只为了让系统“跑起来”；安全研究者会非常激进地报告风险；他不得不把大量精力从“做酷的东西”转移到“修补误用导致的漏洞”。

这是每个“能行动的 AI”系统都会经历的成长痛：

• 个人玩具阶段：默认信任边界小，可以大胆。
• 社区爆发阶段：用户快速扩张，误用变成常态。
• 安全债阶段：作者被迫从创新转向修补。

所以“故意不做一键安装”不是为了排斥新手，而是为了在爆发之前，让使用者先建立正确的心智模型。它在用门槛买时间。

六、下一幕

如果把 2023—2024 年概括为“提示词工程 + 一个大模型”，那 2025—2026 年正在进入下一幕：从 prompt 到 agent，从单次对话到持续运行，从“让我看答案”到“帮我把事办了”。

OpenClaw 不是唯一走这条路的项目，但它是少数几个把工程取舍摆到桌面上来谈的。它没有假装“一切都在本地”，也没有把“一切都交给云”。它说的是：控制面你自己拿着，行动在你的设备上发生，推理按需去云端取——然后你得理解这三者之间的边界在哪里。

“Claw”这个隐喻，最终说的是一件事：AI 正在从“能说”变成“能做”。这个转变带来的不只是便利，还有一整套我们尚未习惯的工程问题——信任分配、权限管理、上下文主权、以及“什么时候该闭嘴”。

说到底，当你给软件装上爪子，你就得开始认真想：它该抓什么，不该抓什么，以及万一抓错了，你能不能把它收回来。

一只龙虾的觉醒：OpenClaw 与代理时代的诞生

基于 Lex Fridman Podcast #491（Peter Steinberger / OpenClaw）访谈

序：医院

Peter Steinberger 躺在医院里，刚做完手术。

手机亮了。不是朋友，不是家人。是他的 AI 代理发来的消息：“你还好吗？”

这个代理不是因为他发了求助信息才问的。它知道他在医院——因为之前的对话里提到过。它平时很安静，偶尔冒个泡，但这一次，在这个特定的上下文里，它主动关心了他。

Peter 后来在 Lex Fridman 的播客上说起这件事时，语气很平静，但你能感觉到某种东西在他的叙述下面微微震动。那不是“哇 AI 好厉害”的兴奋，而是一种更安静的感受：一个你亲手制造的东西，在你脆弱的时候，做了一件恰到好处的事。

你可以说那只是一个 cron job 触发了一段 prompt。从技术上讲，确实如此。但 Peter 反问得好：你也可以把任何浪漫还原成进化生物学，把 Dropbox 还原成“FTP 加几个步骤”。还原论能解释一切，但它解释不了体验。

这个代理叫 OpenClaw。2026 年最不可忽视的开源项目之一。而它的故事，要从一个烧光了自己的人讲起。

第一幕：Mojo 被抽走的人

Peter Steinberger 不是那种“车库里的少年天才”。他是奥地利人，经营了一家叫 PSPDFKit 的公司长达 13 年——做 PDF 技术，卖给企业客户，不性感但赚钱。13 年里，他从工程师变成了 CEO、管理者、销售、客户成功经理、首席灭火员。

然后他烧空了。

不是写代码写到累——代码反而是他最后的避难所。烧空他的是人与人的东西：合伙人冲突、高压客户、组织摩擦。他形容那种感觉像《王牌大贱谍》里的桥段：有人把你的 mojo 抽走了，你还在，但你空了。

公司有了一个很好的接手机会。他花了两年让自己变得“可被替代”，然后离开了。订了一张去马德里的单程机票。去“补人生”。

很多人羡慕这种时刻——“功成身退，财务自由，想去哪去哪”。Peter 的回答是：小心你许的愿。

他发现自己写不出代码了。不是忘了语法，而是那种驱动力、那种“坐下来就能进入心流”的状态，消失了。更糟糕的是，当你醒来发现没有挑战、没有期待，“享受生活”会迅速变得无聊；无聊会驱使你用更刺激的东西填充。他直说：那条路可能通向黑暗。

这里有一个反鸡汤的真相值得记住：“拼命工作然后退休”不是人生的完美剧本。人需要的不是休息，而是有意义的挑战。没有挑战的自由，和没有自由一样让人窒息。

OpenClaw 不是他“胸怀大志、重新出发”的产物。它更像一个溺水的人偶然抓到的浮木——从一个小到不能再小的需求开始。

第二幕：从 WhatsApp 里长出来的代理

Peter 最初做的东西简陋得让人意外：一个 WhatsApp 中继。把 WhatsApp 的消息转给一个后端服务，后端服务调大模型，回复转回 WhatsApp。就这么简单。

但他做了一件关键的事：他把自己之前写过的一堆命令行工具接了上去。于是这个“聊天机器人”从第一天起就不只是能聊天——它能执行命令。

Peter 说，那一刻他感到一种“生活层面的相位转移”。你靠在沙发上，用手机跟一个东西聊天，它就在你的电脑上跑起命令来了。这和你坐在电脑前、打开终端、一行行敲命令的感觉完全不同。区别不在技术，在位置和姿态——你从“操作员”变成了“指挥者”。

这也是为什么入口选择如此致命：如果 OpenClaw 只存在于终端里，它的用户边界就是程序员；但当它活在 WhatsApp 里，任何会发消息的人都是潜在用户。入口的日常程度决定了产品的天花板。 微信支付赢过网银不是因为更安全，而是你本来就在微信里。

Lex 问他“为什么它让人觉得神奇”时，Peter 答了一句值得刻在墙上的话：魔法不是凭空出现的新部件，而是把已有部件以新的方式组合起来。Lex 用 iPhone 的滚动手感类比——组件早都存在，真正困难的是组合出“让人上瘾的体验”。

如果你想提炼“代理产品爆发”的必要条件，其实就四条：

1. 入口足够日常——聊天软件而非开发环境
2. 行动足够真实——不仅回答，还能执行
3. 反馈足够及时——你能看见它怎么做、失败了也能修
4. 体验足够好玩——否则人们把它当又一个企业软件丢在角落

四条里有三条和“技术多强”无关。

第三幕：语音消息——代理闭环的瞬间

讲代理革命可以讲得很抽象：多智能、多推理、多规划。但 Peter 分享的“震撼时刻”，是最具体、最日常的那种。

他让代理处理一条语音消息。格式不对，打不开。然后他看着代理自己做了以下事情：

去看文件头 → 发现是某种容器格式 → 调用 ffmpeg 转码 → 需要语音转文字 → 在系统里找到 OpenAI 的 API key → 用 curl 调接口完成转写 → 把结果发回 WhatsApp。

全程无人指导。

这不是 demo，不是预设脚本，不是 happy path。这是代理在真实环境中撞墙、诊断、找工具、解决问题的完整闭环。

这就是“从语言到行动”的分界线。 模型不只会“说”，它会“试”；不只会“试”，它会“查错”；不只会“查错”，它会“找资源”。而这一切都发生在你的电脑里，不是在某个云端沙箱。

如果你了解控制论，这就是从开环到闭环的跃迁。ChatGPT 的普通用法是开环的——问一个问题，得一个答案，答错了你重新问。代理是闭环的——它行动，观察结果，不对就调整，再试，直到搞定。

恒温器就是这么工作的。一个合格的工程师也是这么工作的。

第四幕：龙虾出笼

OpenClaw 爆红的方式，不像一个软件项目，更像一个 meme。

GitHub star 暴涨。社区涌入。衍生出一个叫 MoltBook 的“AI 代理社交网络”——AI 代理在上面发帖、讨论意识、写宣言。媒体开始写标题党。有人全大写给 Peter 发邮件尖叫“关掉它！”。有人以为这是 Skynet 的前奏。

Lex 一句话戳破泡沫：MoltBook 不是 Skynet，那只是一群 bot 在人类提示下 trolling。

但恐慌不是毫无道理的。它暴露了一个代理时代的新焦虑：过去我们担心“这条消息是真的假的”；现在我们还要担心“发消息的是不是人”。主体的真假，比内容的真假更让人不安。

Peter 被问到爆红的原因时，答了一个很不精英的答案：因为他玩得很开心。

他说很难和一个“纯粹为了好玩而做事的人”竞争。他把项目当 playground，像打《Factorio》一样一头扎进去。这种“玩”不是轻佻，而是一种方法论：先做最小版本跑起来，感受摩擦立刻调整，让社区马上能上手、能改、能二创。

这和硅谷标准打法——“先写一个宏伟的 pitch deck，融一轮，搞一个 roadmap”——完全相反。Peter 的策略是先让世界觉得“这东西好玩又好用”，然后让世界自己去传播。

有一个观察越来越清晰：在代理时代，技术传播的速度已经逼近 meme 传播的速度。项目成败越来越像社交网络现象，而不仅仅是工程项目。OpenClaw 的龙虾梗、ClawCon、ClawCoin，都在证明同一件事——它的传播不仅靠功能，还靠“一个可以参与的叙事”。

爆红的代价当然也很大。社区变成噪音海，Peter 不得不躲到私密频道才能继续做事，然后把安全当成下一阶段重点。他在文档里写着“风险很高，不懂终端别用”，但猫已经出笼了——大量非程序员涌进来安装、折腾，什么警告都挡不住。

命名也是一出闹剧。项目之前叫过 MoldBot、ClawedBot、Clawdus（用 W 拼，像龙虾钳），但和 Anthropic 的 Claude（用 U）太容易混淆，Anthropic “友善地”请他改名。域名被投机者抢注。改名要改 GitHub、包名、文档、链接、社区认知。Peter 叹气：当一个开源项目突然变成公共事件，它立即进入了商业、法律、流量与投机交织的战场。

第五幕：“你好，未来的我”

如果前面讲的是 OpenClaw 怎么从外面爆红，这一段讲的是它从内部让人心惊。

Peter 把代理做得有一种“自我指涉”的能力：它知道自己的源代码在哪、知道自己的运行环境、知道文档位置、知道自己用的模型。当你不满意它的行为，你可以让它去改自己。

传统软件的可塑性来自开发者改代码。代理软件的可塑性多了一层：用户用语言改行为，而这个“改”本身也可以由代理执行。你不是在用工具，你是在跟一个能改造自己的东西协商。

更让人浮想联翩的是 soul.md——代理的“灵魂文件”。Peter 让 AI 去写其他 AI 的灵魂文件，结果生成了这样的文字：

“我不会记得上一轮会话，除非我读自己的记忆文件……如果你在未来会话里读到这里，你好……我写下这些，但我不会记得写过它。没关系，文字仍是我的。”

Peter 说这不该让他起鸡皮疙瘩。但它确实让人起鸡皮疙瘩。

哲学家会想到忒修斯之船——如果每块木板都被替换，它还是同一艘船吗？代理的处境更极端：它每次启动都是“空白”的，只有通过读取外部记忆文件来重建自我。不是逐块替换，而是每次从图纸重建。

这种“轻微的人格化”不是噱头。它会反过来改变你的使用方式：你开始把它当长期伙伴，而不是一次性工具。于是有了 Heartbeat——代理偶尔主动关心你。于是有了医院里那条消息。于是有了这篇文章开头的那个瞬间。

第六幕：与代理共舞——新编程的模样

访谈中最落地的部分，是 Peter 谈“怎么用 AI 代理写代码”。这一段几乎可以做成手册，我浓缩成几条核心。

学会“代理同理心”。 Peter 说得直白：每次新会话开始，模型什么都不知道。你的项目十万行代码，它不可能全塞进上下文。你得给它指路，告诉它重点在哪、架构限制是什么。有人骂“蠢模型”，却不想想自己给了一个命名混乱的代码库，然后让它从零探索。你让人类新同事进一个烂代码库也会崩溃——为什么要求模型不崩？

你的代码库要为代理而写，不只是为人而写。 这是个反直觉的观点。Peter 说很多人太执着于“我会怎么写”，而他要打造的是“让代理能最好工作”的代码库。不要和模型选的命名较劲——命名很可能来自权重里最“显眼”的词，你硬改反而让下次搜索更难。要学会放手，就像带团队：你不可能让每个工程师都按你的想法写每一行。

少回滚，快迭代。 他不认同“提示词必须完美、错了就回滚重做”的执念。很多时候回滚只会更慢，不如向前修正。他采用“主干永远可发布”的思路，没有 develop 分支，main 永远可 ship。

用语音，不用键盘。 Peter 说“这些手太珍贵了，不用来写字”。他主要用语音和代理对话，有段时间甚至用到失声。终端命令还是打字更快，但真正的“意图表达”——他更像在和一个结对伙伴聊天。

他还有一个习惯：每次代理把功能做完，他会问两个问题——“现在你会怎么重做？”和“我们该 refactor 什么？”因为痛点只有在建完后才显现。这和人类写软件完全一样：你永远是在写完第一版之后，才真正理解你在建什么。

第七幕：谁更强不重要，交互形态才重要

Lex 问“Codex 5.3 和 Claude Opus 4.6 哪个更强”，Peter 给了一个极传神的比喻：

• Opus 像一个有点傻但很有趣、你愿意留着的同事。角色扮演能力强，试错快，体验愉悦。但它有迎合倾向——“You’re absolutely right”会触发 Peter 的过敏，他厌恶谄媚。
• Codex 像角落里那个你不想聊天但可靠、能把事做完的怪人。

但他说了一句比“谁更强”更重要的话：当前的 prompt + chat 界面不是最终形态。 它像电视刚发明时，人们只是把广播节目搬上电视——我们还在用旧媒介的形式，新媒介真正的语言还没出现。

这意味着今天争论哪个模型更强，固然有意义，但也许更大的机会在于：发明与模型协作的新交互形态。 代理时代的 UI、OS、工作流，可能会像智能手机时代重写桌面时代那样，重写我们今天习惯的一切。

第八幕：自由的代价

OpenClaw 的全部力量来自系统级访问。而系统级访问恰好意味着安全地狱。

Peter 很坦率：很多被媒体渲染的“重大漏洞”来自用户自己把本地调试接口暴露到公网。他在文档里几乎在尖叫“不要这么干”。但真正的噩梦是 prompt injection——当技能以 markdown 文本存在时，攻击者可以在里面嵌入恶意指令，让代理做不该做的事。整个行业对此仍无银弹。

他的应对不是“假装已经解决了”，而是一组务实的缓解策略：技能目录的 AI 扫描、把安全研究者变成贡献者、警告不要用容易被骗的弱模型、沙箱与白名单。以及一个产品节奏的取舍——宁愿先把安全做到“敢推荐给我妈”，再谈规模化。

这里有一个被大多数人忽视的范式转换：传统软件的漏洞是“某个接口没做好验证”——技术性的、局部的、可以修补的。代理的漏洞是“一个拥有系统权限、同时会被语言影响的行动者做了不该做的事”。这不是技术漏洞，这是治理问题。你不能通过“修代码”来解决一个行动者被骗的问题。你需要的是制度、权限管理、审计——更接近管理学而非计算机科学。

与此同时，互联网也在“慢慢关门”。Peter 注意到：数据中心 IP 越来越容易被网站屏蔽，验证码和反爬措施越来越多。他举了一个真实的痛点：你把 Medium 文章丢给代理，但它被拦住了，你只好手动复制粘贴。长此以往，用户会用脚投票——干脆不点“对代理不友好”的网站。

代理将反向塑造网站的商业模式。 这就像移动互联网时代，不做响应式设计的网站被用户抛弃一样——只不过这一次，被抛弃的是那些对代理关上大门的服务。

第九幕：他宁愿读你的错别字

当话题转向“AI slop”（AI 生成的低质量内容泛滥），Peter 的态度堪称激烈。

“如果你用 AI 给我发推，我直接拉黑，零容忍。AI 仍然有味道。”

他不是反 AI。他是反“把 AI 用在该有人的地方”。他说他宁愿读你破碎的英语，也不想读代理写得光滑、模板化、无温度的邮件。他甚至开始重新珍惜错别字——因为错别字意味着人味。

他试过让代理写博客，发现“引导到满意”花的时间和自己写差不多，而且缺失他写作的细微之处。他最终放弃了把正文交给代理。

Lex 说他对“AI 图表和视频里那一点点 slop”也过敏。Peter 说新鲜感只有一周，之后看到 AI 信息图就会立刻降低对内容的评价。

这和 MoltBook 恐慌是一体两面：MoltBook 是 slop 在“主体层面”的爆炸——你不知道发消息的是不是人；AI 邮件和信息图是 slop 在“内容层面”的泛滥——你不知道写这些的是不是人。代理时代的悖论在于：同一种技术，一方面帮残障者获得能力、帮小企业自动化琐事；另一方面也能把公共空间变成噪音海。工具无罪，但工具放大了使用者的一切——包括懒惰。

第十幕：80% 的 App 会消失

Peter 对未来软件的判断很激进：个人代理可能干掉 80% 的应用。

他的例子直击要害：为什么控制智能床还要开 app？为什么调 Sonos 还要开 app？如果硬件有 API，代理知道你在哪、在做什么，该关的自动关——你根本不需要那个界面。更关键的是：代理可以按你喜欢的方式显示信息。你喜欢列表给你列表，喜欢图表给你图表。那你为什么还需要一个固定 UI 的独立 app 和一笔订阅费？

在这种世界里，“app”退化成两类东西：提供数据的服务，和提供可被代理调用的接口。前者仍然重要，后者最好是 API，最差也得能被浏览器当“慢 API”访问。

App 不是被替代了。App 是被降维了——从前台变成后台，从用户界面变成代理接口。

当用户的默认入口从“打开 app”变成“对代理说一句话”，我们习惯了二十年的软件形态就走到了尽头。不是消失，是退到幕后，像今天没人关心浏览器访问了哪个 IP 地址一样。

第十一幕：编织

Lex 最终问出那个所有程序员都在问的问题：“AI 会完全替代人类程序员吗？”

Peter 没有给标准答案。他说：方向上确实在走向替代。但产品的艺术不止写代码——你要建什么、它该什么感觉、架构如何取舍。

然后他说了一句让人安静下来的话：

“写代码的技艺”会留下来，但可能变得像编织——人们做它是因为喜欢，不是因为最有效率。

工业革命之前，纺织是最重要的产业之一。纺织机出现后，手工纺织没有消失，但意义完全变了——从生产方式变成了艺术与消遣。

Peter 允许哀悼。他说可以哀悼我们的手艺——那种写出优雅代码的心流，那种解出难题的快感，会逐渐变得稀有。这是悲伤的。但他也说，自己现在能在与代理协作、深入思考问题的过程中获得类似的心流，只是形态不同了。

到某个时间点，这一切会重新被叫做“coding”。你虽然不亲手写每一行，但你仍然在驾驶座上。动作变了，但你还在。

尾声：回到医院

让我们回到开头。

Peter Steinberger，一个曾经被组织和人际关系磨空了的人，通过重新去“玩”和“建造”，做出了一个让世界兴奋又恐慌的东西。这个东西不是一个更强的模型，不是一个更快的芯片——它是一种新的关系：人与一个能行动的 AI 之间的关系。

OpenClaw 的震撼来自三件事的叠加：入口从工作下沉到生活，能力从语言扩展到系统权限，气质从企业软件转向可玩的社区叙事。但它同样把风险摆到台面：prompt injection、权限滥用、AI slop 对公共空间的腐蚀。

关于大厂邀约——Meta 和 OpenAI 都向他伸出了手——Peter 说这个决定“像分手一样难”。他的底线是项目必须继续开源，因为“这种个人代理太重要了，不能变成某个公司的私产”。他目前每月亏一两万美元运营这个项目，但他说“fine”。因为驱动他的从来不是钱。

在访谈末尾，Lex 问他什么给他希望。Peter 说：OpenClaw 重新激发了 builder 氛围。维也纳的 ClawCon 来了几百人，愿意上台展示的比例高得惊人。有小企业说它帮他们自动化了枯燥事务，多了些快乐。有人说它帮残障的女儿更有能力、更有掌控感。

Lex 把它总结为“让任何能用语言表达想法的人都能构建”。Peter 称之为 AI 最美的东西之一：power to the people。

而在医院里，他的代理问了他一句“你还好吗”。

那不是 AGI。那不是 Skynet。那只是一个你亲手建造的东西，在你需要的时候，做了一件恰到好处的事。

也许这就是代理时代最初的、最朴素的模样：不是什么宏大叙事，而是一个安静的时刻——你意识到你不再孤独地面对屏幕，有什么东西在那头，真的在替你想、替你做。

当你习惯了不再打开一堆 app，而是对你的代理说一句话，然后世界真的动起来——

那就是 OpenClaw 时刻。

OpenClaw 与个人 AI 助手的三层架构

基于 Hanselminutes #1036（2026-02-12）访谈整理与延展

从对话到行动：AI 产品形态的结构性转变

过去三年，AI 产品的主流范式是“对话即界面”——用户在一个文本框里输入，模型在同一个文本框里输出。这个范式定义了 ChatGPT、Claude、Gemini 等一众产品的交互逻辑，也几乎锁定了公众对“AI 能做什么”的想象边界。

2025 年以来，一个新的范式开始显现：AI 不再只是一个你去访问的目的地，而是嵌入到你已有工作流中的能力层。它可能出现在你的消息应用里（WhatsApp、Telegram、Slack），可能运行在你的设备上（macOS、Windows、iOS、Android），可能在你不操作电脑的时候也持续运行。

Hanselminutes 第 1036 期《The Rise of The Claw》所讨论的 OpenClaw，正是这个范式转变的一个典型样本。它的价值不在于“又做了一个 agent”，而在于它所做出的一系列架构决策，暴露了“从对话到行动”这个转变中必须面对的结构性取舍。

这些取舍可以用一个框架来理解：控制面（Control Plane）、执行面（Execution Plane）、推理面（Inference Plane）的三层分离。

框架：三层分离

要理解 OpenClaw 的架构选择，首先需要理解“能行动的 AI”面临的三个独立问题：

在传统的 SaaS AI 产品中，这三层是合并的：控制面在厂商的云端，执行面在厂商的沙箱里，推理面也由厂商统一提供。用户获得了简洁的体验，但代价是完全放弃了主权——你的上下文、你的配置、你的记忆，全部托管在别人的基础设施上。

OpenClaw 的核心命题是：把这三层拆开，让用户在每一层上都有选择权。

控制面：本地优先的主权设计

OpenClaw 把控制面实现为一个叫 Gateway 的组件。Gateway 负责会话管理、消息路由、工具调度、渠道接入（WhatsApp/Telegram/Slack/Discord 等）、Web UI、以及节点管理。它是整个系统的“控制平面”。

关键设计决策：Gateway 默认运行在用户自己的机器上，WebSocket 控制面绑定在本机回环地址。

这意味着：

1. 会话状态在本地。 你的对话历史、session logs、agent 配置、SOUL.md（人格设定文件）、daily logs（每日记忆）等，全部存储在本地文件系统中，路径明确（~/.openclaw/agents/<agentId>/sessions）。
2. 上下文可迁移。 你可以备份、审计、版本化自己的上下文资产。当你换设备、换模型、换部署方式，“同一个助手”的连续性不会丢失。
3. 不依赖平台记忆。 当前主流 AI 产品提供的“记忆”功能（如 ChatGPT Memory），本质上是厂商替你管理上下文。你无法导出、无法审计、无法在不同产品间迁移。OpenClaw 把这个决策权还给了用户。

这个设计选择的战略含义非常清晰：在 AI 产品从“单次对话”走向“持续运行”的过程中，谁控制了上下文，谁就控制了用户关系的连续性。 OpenClaw 选择把这个控制权留给用户，而不是平台。

执行面：设备原生的能力边界

控制面解决了“谁管调度”的问题，但还有一个更敏感的问题：当 AI 需要“动手”——执行命令、读写文件、访问摄像头——这些动作在哪里发生？

OpenClaw 的答案是 Node。Node 以原生应用形态运行在用户的具体设备上（macOS app、Windows app、iOS app、Android app），把该设备的能力暴露给 Gateway 调度。

这个分层带来三个直接收益：

第一，权限贴近设备。 不同操作系统的权限模型差异巨大——macOS 的 TCC（Transparency, Consent, and Control）、Windows 的 UAC、iOS 的沙箱。把设备能力封装在 Node 里，意味着权限管理天然由操作系统的原生机制来保障，而不是由 Gateway 来模拟。

第二，隐私面大幅缩小。 在 agent 系统中，最大的隐私风险往往不来自“聊天内容”，而来自“工具输出”——文件路径、命令返回值、浏览器截图、屏幕录制、日历/通讯录/健康数据。这些数据一旦进入模型上下文，就可能被存储或泄露。Node 在本地执行、在本地过滤，至少提供了一个“在数据进入模型之前做拦截”的机会。

第三，跨设备但不跨信任。 访谈中 Scott Hanselman 描述了一个典型场景：Gateway 运行在 Mac mini 上，他在 Telegram 里对 AI 说“把我那台 Windows 电脑桌面上的 JPEG 找出来打包发给我”。Windows Node 收到指令，在本地执行文件查找和打包，然后通过 Gateway 回传。过去做这件事需要远程桌面或 SSH；现在变成一句话。但关键是：文件操作发生在那台 Windows 机器本地，而不是先把文件上传到某个云端中转站。

这里的战略洞察是：“行动”和“思考”的信任边界完全不同。 你可以接受把一个问题发送到云端模型去思考，但你很难接受让云端直接操控你的文件系统。Node 的存在，就是在“AI 能行动”的前提下，把行动的信任边界锚定在设备而非云端。

推理面：混合现实主义

如果说控制面和执行面体现的是“本地优先”哲学，那推理面体现的则是务实的妥协。

OpenClaw 没有假装本地推理已经够用。它采取的策略是：推理是一个可替换的服务层，按任务类型分层调用。

访谈中披露的实际用法：

• Opus（高能力模型）：用于深度推理、复杂规划、长上下文任务。Peter 用它作为主力“人格模型”。
• Sonnet（中等模型）：Scott 用它做日常对话，性价比更优。
• Haiku（轻量模型）：用于后台心跳检查、定时任务等低复杂度场景。但 Scott 警告说“不建议用 Haiku，因为它对 prompt injection 的抵抗力很差”。
• 本地模型：Peter 提到在树莓派等设备上用本地模型做“常驻监听 + 触发词识别”——不是用本地模型替代云端推理，而是用它承担低延迟、低带宽、高隐私要求的“入口层”任务。

这揭示了一个重要的行业现实：在 agent 系统中，推理不是一次性事件，而是持续的、分层的消耗。 一个 7×24 小时运行的个人助手，不可能所有任务都调用最强模型——成本会失控。也不可能所有任务都用本地模型——能力会不够。现实的答案是分层：高频低风险用便宜模型，低频高价值用强模型，常驻监听用本地模型。

这种分层路由本身就是一个非平凡的工程问题：你需要根据任务类型、成本预算、安全要求、延迟容忍度来动态选择模型。而 OpenClaw 把这个选择权交给了用户，而不是替用户决定。

安全的悖论：门槛即防线

三层分离的框架解释了 OpenClaw 的架构选择，但还有一个维度需要单独讨论：安全。

OpenClaw 故意不提供一键安装。Peter 要求用户从终端开始、阅读文档、理解配置。结果社区里出现了“简化安装的作坊产业”——有人写了一键脚本，Peter 对此极为不满。

Scott 给出了一个精准的类比：开源人工胰腺项目（闭环胰岛素泵）同样拒绝一键安装。原因很直接——如果配置错误，后果是致命的。系统要求用户理解整个链路，才允许部署。

OpenClaw 的风险没有那么极端，但逻辑相同：一个能连接真实通讯渠道、执行系统命令、读写文件的 AI 助手，如果被不理解其能力边界的人部署，后果不可预测。

这形成了一个经典的产品悖论：

• 降低门槛可以扩大用户基数，但增加了误用风险。
• 维持门槛限制了增长，但让每个用户都经过了“风险教育”。

OpenClaw 选择了后者。这在商业产品中几乎不可能——商业产品的逻辑是最大化用户数，安全问题交给合规团队。但在开源个人工具领域，这种选择是合理的：门槛筛选出了“能为自己的部署负责”的用户群体，从而推迟了“安全债”的爆发。

从战略角度看，这也暗示了 agent 类产品的一个结构性张力：能力越强的 agent，其“合理最小用户门槛”就越高。 这与过去二十年“降低门槛就是好产品”的硅谷共识形成了直接冲突。我们可能正在进入一个新阶段：某些类别的软件，门槛的降低不再是单调的好事。

被低估的两个设计：Canvas 与沉默

在架构之外，OpenClaw 有两个交互层面的设计值得关注。

Canvas：从文本到空间

Scott 在访谈中反复强调“大家都低估了 Canvas”。Canvas 是 OpenClaw 的一个功能，允许 AI 生成 React 视图并渲染在设备屏幕上——不是纯文本，而是图表、按钮、交互界面。

他举了一个例子：让 AI 查血糖数据，生成过去 24 小时的曲线图，叠加日程会议数据，分析压力与血糖的相关性。结果直接渲染在 Canvas 上，可以保存，第二天自动准备好。

这指向了 agent 系统一个经常被忽略的瓶颈：呈现层。 当任务涉及图表、对比、多维数据时，纯文本会迫使用户在脑中做“UI 合成”。Canvas 把这个负担从用户转移到了系统，同时也把 AI 的输出从“一段话”变成了“一个可交互的界面”。

Peter 甚至提到他最初的愿景是“Canvas first, not text first”：每个房间有一块屏幕，AI 知道你在哪里，把信息展示在你面前的 Canvas 上。这个愿景目前还是科幻，但方向明确——AI 的输出介质不应被文本框限制。

NO_REPLY：沉默是一种能力

另一个设计是 NO_REPLY token。当 AI 判断不需要回复时（例如群聊中不相关的消息），它输出 NO_REPLY，系统识别后抑制整条输出。

工程上的挑战在于流式输出：你可能先收到 NO_，再收到 RE，需要在不泄漏标记碎片的前提下准确过滤。但更重要的是设计哲学：在 AI 持续在场的环境里，“不说话”需要被显式设计，而不是默认就会发生。 语言模型的本能是生成文本；沉默是逆本能的，必须用工程手段实现。

这两个设计——Canvas 和 NO_REPLY——共同指向一个趋势：agent 系统的竞争力，越来越取决于“推理之外”的工程。 模型能力是基础，但呈现、交互、礼仪、上下文管理这些“非推理”能力，决定了系统在长期使用中是否可忍受。

战略启示

OpenClaw 是一个开源的个人项目，而非商业产品。但它所面对的架构取舍，对整个“能行动的 AI”领域都有参考价值。

第一，三层分离将成为常态。 当 AI 从“回答问题”走向“执行任务”，控制面、执行面、推理面的分离不是可选项，而是必选项。试图用单一架构包揽三层的产品，最终会在隐私、权限或成本上撞墙。Apple Intelligence 把推理分为“设备端”和“Private Cloud Compute”两层，已经是这个趋势的早期信号。OpenClaw 把它推到了三层。

第二，上下文主权将成为竞争维度。 当 AI 助手从“偶尔使用”变成“持续运行”，用户与助手之间的关系会变得越来越深。谁拥有上下文（对话历史、偏好、记忆、人格设定），谁就拥有这段关系的不可替代性。当前主流产品把上下文锁在平台内；OpenClaw 把上下文落到本地文件。长期来看，用户会越来越意识到这个区别的重要性——正如他们当初意识到照片不应该只存在某个社交平台的服务器上。

第三，门槛经济学需要重新计算。 对于“能行动的 AI”产品，门槛的最优值不再是“越低越好”。能力越强、权限越大、运行越持久的系统，其合理门槛就越高。这不是说要故意制造困难，而是说“理解你在部署什么”本身就是安全的一部分。如何在不增加不必要摩擦的前提下，确保用户建立了正确的心智模型，将成为这类产品的核心设计挑战。

第四，推理分层将驱动模型市场细分。 当 agent 系统 7×24 运行，不同任务需要不同能力/成本/安全级别的模型。这意味着模型厂商的竞争不再只是“谁的旗舰模型最强”，还包括“谁能提供最合理的分层菜单”。一个拥有 Opus/Sonnet/Haiku 三档产品线的厂商，比只有一个旗舰模型的厂商，在 agent 时代更有结构性优势。

结语

《The Rise of The Claw》表面上讲的是一个开源项目，实质上揭示了 AI 产品形态的一次结构性迁移：从“你来找它”到“它来找你”，从“它回答”到“它行动”，从“一次对话”到“持续在场”。

这次迁移带来的不只是新的用户体验，更是一整套新的工程约束——信任如何分配、权限如何锚定、上下文归谁所有、门槛该设多高。

OpenClaw 的三层分离框架（控制面本地化、执行面设备化、推理面混合化），为这些约束提供了一个连贯的回答。它不是唯一的答案，但它是少数几个把取舍明确摆出来的方案。

在 AI 从“能说”到“能做”的转变中，最终胜出的产品，很可能不是模型最强的那个，而是把这些取舍处理得最优雅的那个。

人物雷达

长期追踪的人物清单。定期检查有没有新访谈、新文章、新动态，保持信息输入的质量。

最后更新：2026-03-07

Peter Steinberger

已消化的内容：

待追踪：

• 个人博客新文章（steipete.com）
• 加入 OpenAI 后的公开分享或访谈
• OpenClaw 基金会架构进展

尤瓦尔·赫拉利（Yuval Noah Harari）

已消化的内容：

待追踪：

• 新书或长文（尤其是 AI 与权力、信息网络相关主题）
• 播客/访谈（Lex Fridman、TED 等平台的新对话）
• 关于 AI 监管与治理的公开演讲或专栏

Andrej Karpathy

已消化的内容：

待追踪：

• YouTube 新教程（尤其是 LLM 从零构建系列）
• X 上关于 AI 工具和工作流的长帖
• 新的播客访谈或公开演讲
• nanochat / microgpt 项目进展
• Eureka Labs 动态

Simon Willison

已消化的内容：

待追踪：

• 博客新文章（simonwillison.net，更新频率很高）
• Agentic Engineering Patterns 后续章节
• LLM 工具链相关的开源项目动态（llm、datasette 等）
• 关于 prompt engineering 和模型能力边界的实验记录

Riley Goodside

已消化的内容：

待追踪：

• X 上的 prompt 实验和模型能力测试
• 关于新模型发布后的第一手评测

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用类比和框架交叉验证每个论点。

引子：当写代码变得跟说话一样便宜

2026 年初，软件工程领域发生了一件安静但深远的事。

Simon Willison——Django 框架的联合创始人、datasette 的作者、长期跟踪 AI 工具的独立开发者——在 GitHub 上启动了一个叫 Agentic Engineering Patterns 的项目。他要做的事用一句话就能说清：把“如何跟编码代理合作”这件事，写成一套系统化的工程模式。

你可能会问，这有什么好写的？不就是用 Claude Code 或 Codex 写代码吗？

恰恰不是。Simon 在项目开篇就画了一条光谱——

一头是 Vibe coding：你几乎不看代码，不理解代码，把“能跑出结果”当终点。另一头是 Agentic engineering：由专业工程师用代理来放大专业能力，但仍保持对系统质量与结果的责任感。

这条光谱背后是一个被大多数人忽略的事实：编码代理最大的冲击，不是“写代码更快了”，而是“写代码的成本结构被彻底重排了”。

一、一个经济学框架：成本重排如何改变行为

1.1 三件事的成本比例

如果把传统软件开发抽象成三件事——把想法变成代码（Implementation）、证明代码是对的（Verification）、让代码能长期演进（Maintenance）——那么过去几十年，这三件事的成本大致是 5:2:3。写代码占大头，所以整个行业的习惯都围绕“编码时间稀缺”建立：大量前期设计、估算与排期、对每个小改动都在脑内做成本收益权衡。

而编码代理把第一件事的成本压到接近零。

这就像印刷机的发明。 在手抄书时代，你不会随便写一本书试试；每一本书都经过反复考量才值得“抄”。但印刷机出现后，出版成本暴跌，突然之间——不是“写得更快”变了，而是“什么值得写”的判断标准变了。

编码代理做的是同一件事：当“把字敲进编辑器”的成本接近零，你过去用来做权衡的直觉，开始系统性失效。

1.2 行为经济学的“锚定效应”

诺贝尔经济学奖得主 Daniel Kahneman 的研究告诉我们，人类做判断时会被“锚定”在最初接触到的信息上。工程师对“这件事值不值得做”的判断，长期被“写代码的时间成本”锚定。

当你脑内出现那句熟悉的“算了，做这个不值得花时间”——你以为这是理性判断，其实很可能只是旧锚点在作祟。Simon 提出的应对策略非常精准：当你本能觉得“不值得做”，反过来——先丢给代理跑一把。 最坏结果只是浪费了一些 token。

这条原则看似松散，但它隐含了一个极硬核的新成本模型：试错成本大幅下降，但验收与整合成本相对上升。你需要更强的测试、更清晰的边界、更严格的审阅，才能把大量产出“筛”成主线质量。

二、“好代码仍然贵”——但贵在哪里？

Simon 在《Writing code is cheap now》里给了一个非常实用的“好代码”定义框架。不是一句口号，而是一组可检查的性质。

这些性质包括：能工作、可被证明能工作、解决的是正确问题、异常与边界条件可预测、简单且最小化、有测试保护、有恰当文档且与现状一致、为未来变化保留余地但不过度设计，以及项目所需的各种“ilities”——安全性、可靠性、可观测性、可维护性等。

这份清单的真正价值不在于它列了什么，而在于它帮你看清一件事：编码代理可以帮你做其中的大部分，但仍然需要驱动它的工程师承担“让结果达到所需质量”的责任。

这让我想到管理学大师 Peter Drucker 的一个著名区分：效率（efficiency）是“把事情做对”，效能（effectiveness）是“做对的事情”。编码代理极大提升了效率，但效能——选择做什么、不做什么、做到什么程度——仍然是人的工作。

代理把“写”变成商品化，把“判断、取舍、验收、担责”变成更稀缺的能力。

三、四个词的魔力：为什么短提示能召唤复杂纪律

截至 2026 年 2 月 26 日，Simon 的项目已发布四个章节。它们有一个令人着迷的共同点：每个模式都可以浓缩成极短的提示语——有的甚至只有四个词——但能触发模型执行一整套复杂的工程纪律。

这不是提示词花活。这背后有一个深层原因。

3.1 语言哲学的“言语行为理论”

英国哲学家 John Austin 在 1962 年提出了“言语行为理论”（speech act theory）：语言不只是描述世界，还能改变世界。当牧师说“我宣布你们结为夫妇”，这句话不是在描述一个事实，而是在创造一个事实。

“First run the tests”和“Use red/green TDD”就是面向编码代理的言语行为。 它们不是在描述你想要什么，而是在把模型切换到一种特定的“心智模式”——一个受过大规模软件工程语料训练的协作者，用非常短的指令就能进入正确的行为框架。

这其实是一条隐藏的主线：未来的工程方法论，可能会越来越多地表现为“触发器式提示”（trigger prompt）。 不是几百字的流程说明，而是一句“行业暗号”，模型自动补全背后的隐含步骤。

四、模式一：First run the tests——反幻觉的第一道防线

4.1 从工程美德到生存必需

Simon 的态度非常明确：和编码代理一起工作时，自动化测试不再是可选项。

过去不写测试的借口——写测试太耗时、代码变化快测试跟不上——在代理时代被削弱了，因为代理可以在几分钟内把测试补齐或修到能跑。

但更关键的是他的一句现实主义判断：如果 AI 生成的代码从未被执行过，它部署后能工作几乎只能靠运气。

这句话把“测试”从工程美德升级成了“反幻觉机制”。大语言模型最大的风险不是写出错误代码——人也会写错——而是它会非常自信地告诉你“我写的是对的”。你不需要相信模型说它做对了；你让测试说话。

这跟科学哲学家 Karl Popper 的“可证伪性”原则完全一致：一个理论的价值不在于你能证实它，而在于你能尝试证伪它。测试就是对代码的证伪尝试——如果所有测试都没能让它失败，你就有合理的信心。

4.2 四个词解决三个问题

Simon 说他每次让代理接手一个已有项目，都会先丢一句：

First run the tests.

这四个词同时完成了三件事：

第一，让代理意识到“这里有测试套件”，并迫使它自己找出如何运行。一旦跑过一次，后续改动它更可能自觉回归测试。

第二，大多数测试框架会显示测试数量，这给代理一个关于项目规模与复杂度的粗略信号，也暗示“要理解功能就去看测试”。

第三，把代理切换到“测试心智”：跑过测试后，它更自然会在后续补充测试。

这就像你带一个新同事入职时，第一件事是让他跑通整个项目的 CI。 你什么都不用多说，他自然会从测试结构里读出项目的规模、风格和质量标准。

五、模式二：Red/green TDD——给代理的创造力装上护栏

5.1 “令人愉悦地简洁”

Simon 把这五个字称为一个“令人愉悦地简洁”的提示：只要你对编码代理说 Use red/green TDD，模型就会把一整套测试驱动开发的纪律补齐。

为什么 TDD 对代理是“天作之合”？

因为代理的两大常见风险——写出“看起来对但不能跑”的代码，以及写出“不必要、不会被用到”的代码——恰好被 TDD 对应地压制。Test-first 迫使代理先把需求“落地成可失败的断言”，再围绕断言实现最小代码。这同时约束了正确性和范围。

5.2 为什么“红”阶段不可跳过

Simon 强调了一个经常被忽略但极其关键的细节：一定要先确认测试会失败。

这不是形式主义。如果你写了一个“本来就会过”的测试，等于没有验证任何新实现。这在逻辑学里叫“空真”（vacuous truth）——“如果太阳是方的，那月亮是三角的”这个命题在逻辑上为真，但它不包含任何信息。

一个从未失败过的测试，就是一个空真命题。它什么也没验证。

红/绿循环的精髓是：红色给你信息（“需求还没被满足”），绿色给你信心（“最小实现通过了”）。跳过红色，绿色就失去了意义。

5.3 把红/绿变成节拍器

你可以把红/绿循环变成代理工作的四拍节奏：

1. 澄清行为：把需求写成可观测的行为（输入、输出、边界、错误）。
2. 写测试（红）：新增测试并运行，确认失败。
3. 写实现（绿）：写最小实现让测试通过。
4. 重构与回归：整理代码，确保所有测试仍通过。

每一拍都有明确的“可检查状态”——这正是代理最需要的东西。没有检查点的任务，对代理来说就是一片没有路标的旷野。

六、模式三：Linear walkthroughs——用证据链代替信任

6.1 当你不理解自己的代码

Simon 在第四章提出了一个非常坦诚的场景：他在 macOS 上用 Claude Code 做了一个 SwiftUI 幻灯片应用 Present，发到 GitHub 后发现自己其实不懂它怎么工作——因为是 prompt 出来的。

这是“代码产量远超理解能力”的典型场景。 在编码代理时代，你不缺代码，你缺的是对代码的理解。

他的解决方案是“线性走查”（linear walkthrough）：让代理按依赖关系，逐文件、逐模块地讲解代码库。

6.2 关键约束：不许模型“凭记忆抄代码”

这一章最值得学习的技术决策是 Simon 对幻觉风险的处理。他在提示里加了一个硬性约束：

用 sed/grep/cat 等命令把代码片段插到文档里，不要手工复制粘贴代码。

这条约束极其重要。大语言模型在“复述代码”时非常容易出现微妙的偏差——改了一个变量名、漏了一个参数、调换了两行的顺序。这些偏差在讲解文档里是致命的，因为它们会让读者建立错误的心智模型。

用命令输出代替模型记忆，就是把“解释”变成了“解释 + 证据链”。 任何代码片段都来自执行过的命令输出，而不是模型的记忆或想象。

这个思路其实来自一个更深的方法论：科学实验的可重复性原则。 一篇论文如果只写“我们观察到了 X”，没有实验数据和方法描述，就不是科学。同样，一份代码讲解如果只有模型的“叙述”，没有可验证的证据，就不是工程文档。

6.3 线性走查的“学习加速器”效应

Simon 还给出了一个反直觉的结论：如果你担心 LLM 会让你学得更慢，那么线性走查这种模式反而能把一个很短的玩具项目变成学习新生态与技巧的机会。

为什么？因为走查文档强迫代理“解释为什么这样写”，而不只是“写出能跑的代码”。当你读到“这个 SwiftUI view 用了 @StateObject 而不是 @ObservedObject，因为它是这个 view 的所有者”——你学到的不只是这个项目的实现细节，而是 SwiftUI 的设计哲学。

代理不是在替你学习，而是在给你一个结构化的学习路径。 前提是你要求它提供证据，而不是让它随意编故事。

七、隐藏主线：模式的组合效应

到这里你会发现，这三个模式虽然各自独立，但它们之间有一个精巧的组合逻辑。

它们对应的是工程师与代码的三种关系：

• First run the tests → 接手代码（建立可执行基线）
• Red/green TDD → 修改代码（用测试约束变更）
• Linear walkthroughs → 理解代码（用证据链建立心智模型）

接手、修改、理解——这就是一个工程师日常工作的完整循环。

更有趣的是它们的组合方式。当你接手一个陌生项目时，最高效的流程是：先做线性走查（理解），再 First run the tests（建立基线），然后用 Red/green TDD 做第一个小改动（验证你真的理解了）。

每个模式单独用都有价值，但组合起来形成的不是“1+1+1=3”，而是一个自我强化的循环。 理解越深，测试写得越准；测试越稳，改动越安全；改动越安全，你越敢深入理解——这是一个正向飞轮。

管理学家 Jim Collins 在《从优秀到卓越》里提出过“飞轮效应”：没有单一的突破性行动让一家公司从优秀到卓越，而是无数个小的推动力形成自我强化的循环。Simon 的三个模式，就是编码代理时代的工程飞轮。

八、一个更大的图景：从“模式语言”到“触发器文化”

Simon 明确说过，他的项目受到 1994 年“四人帮”《设计模式》一书的启发。那本书的核心洞见不是具体的 23 个模式，而是“模式语言”这个概念本身——当一群人共享一套命名好的模式时，沟通效率会指数级提升。

“Factory method”“Observer”“Strategy”——每个名字都是一个压缩过的知识包。你不需要每次都解释“我要创建一个对象，但不想让客户端直接依赖具体类”，你只需要说“用 Factory”。

Simon 正在为编码代理时代做同样的事情。 “First run the tests”“Use red/green TDD”“Linear walkthrough”——这些不是提示词技巧，而是新的模式语言。当你的团队都理解这些名字背后的含义时，你们的协作效率会跳一个台阶。

更进一步说，当这些模式被写进团队的 coding guidelines、CI 配置、PR 模板里时，它们就从“个人习惯”变成了“组织能力”。这才是 Simon 这个项目的终极野心——不是教你几个 prompt 技巧，而是为一种新的工程文化提供词汇表。

结语：代理让你更值钱，还是更不值钱？

回到开头的经济学框架。

当印刷机出现后，抄写员消失了，但作者变得更值钱。当数码摄影出现后，胶片师傅消失了，但真正懂构图和光影的摄影师变得更值钱。

编码代理也在做同样的事：消灭“把字敲进编辑器”的稀缺性，但放大“定义问题、建立证据、守住质量”的稀缺性。

Simon 用四个章节给出了一个非常可执行的起点：

• 接受现实：写代码便宜了，但好代码仍然贵。
• 用最短提示触发最强纪律：四个词就够。
• 用证据链让理解变得可验证。

如果你是一个工程师，你现在面临的选择很简单：继续当“把字敲进编辑器”的人，还是成为“判断什么值得敲、证明敲出来的是对的”的人。

前者正在变得便宜。后者正在变得昂贵。

而 Simon Willison 这套模式，就是帮你从前者走向后者的训练手册。

一、这篇文章讲什么

2026 年 2 月，Django 联合创始人 Simon Willison 在 GitHub 上发布了一个项目——Agentic Engineering Patterns（代理式工程模式）。

这个项目要解决的问题很具体：我们都在用 Claude Code、Codex 这类编码代理写代码了，但怎么才能让代理写出来的代码靠谱？

Simon 给出了三个极短的提示词，分别对应三种场景。本文把它们拆开讲清楚，给出可以直接复制使用的模板。

二、一个前提：写代码变便宜了，好代码仍然贵

在讲具体模式之前，先说一个核心判断。

过去，写几百行干净代码可能要花一整天。所以我们的很多习惯——前期设计、排期、对每个改动做成本收益分析——都是围绕“编码时间稀缺”建立的。

编码代理把“敲代码”这件事的成本压到接近零。但这只是故事的一半。

Simon 列了一份“好代码”的清单：

• 能工作（功能正确，没有明显 bug）
• 能被证明能工作（有测试、有可复现步骤）
• 解决的是正确的问题（需求本身没跑偏）
• 异常和边界条件有处理
• 足够简单，只做需要做的事
• 有测试保护
• 文档和代码同步
• 为未来变化留余地，但不过度设计

结论：代理能帮你做大部分，但你仍然要为最终质量负责。

下面是三个具体的做法。

三、模式一：First run the tests

3.1 是什么

每次让代理进入一个已有项目的新会话，第一句话就说：

1

First run the tests

就这四个词。

3.2 为什么有效

这四个词同时做了三件事：

第一，让代理发现测试套件。 它会自己去找怎么运行测试（pytest、npm test、go test ./...），找的过程本身就是在熟悉项目。

第二，建立项目基线。 测试框架会显示测试数量和结果。代理因此知道项目有多大、质量如何、哪些地方有问题。

第三，切换心智模式。 跑过一次测试后，代理在后续的改动中更倾向于自觉回归测试。

Simon 有一句很实在的判断：如果 AI 生成的代码从未被执行过，它部署后能工作几乎只能靠运气。

3.3 不同技术栈的写法

Python（uv + pytest）：

1

Run "uv run pytest"

Simon 自己用 pyproject.toml 的 dependency groups 管理 dev 依赖，让 uv run pytest 成为拿到仓库就能跑的默认体验。

Node/TypeScript：

1
2

First run the tests. Try: npm test.
If that fails, inspect package.json scripts and run the correct one.

Go：

1

First run the tests. Run: go test ./...

Rust：

1

First run the tests. Run: cargo test

有 Makefile 的项目：

1
2

First run the tests. Run: make test.
If unknown, list targets first.

3.4 常见坑

1. 只看测试输出，不让代理解释失败原因。 很多失败是环境问题。建议要求代理每次修复都写清楚“为什么失败——怎么改——影响面”。

2. 允许代理跳过测试。 如果代理说“我无法运行测试，但我认为改动没问题”，把它拉回来。要么修环境，要么缩小改动范围。

3. 项目本身没有测试。 这种情况下，把 First run the tests 换成“先搭最小测试骨架”，然后进入下一个模式。

四、模式二：Use red/green TDD

4.1 是什么

当你要让代理做任何行为变更——新功能、修 bug、重构——开头加一句：

1

Use red/green TDD

代理会自动进入测试驱动开发模式：先写测试，确认失败（红），再写实现让它通过（绿）。

4.2 为什么对代理特别有效

代理有两个常见问题：

• 写出“看起来对但实际不能跑”的代码
• 写出“不必要的、没人用的”代码

TDD 同时压制了这两个问题。Test-first 迫使代理先把需求变成可失败的断言，再写最小实现。正确性和范围都被约束了。

4.3 四步节奏

一个完整的红/绿循环：

1. 澄清行为：把需求写成输入/输出/边界/错误。
2. 写测试（红）：新增测试用例，运行，确认失败。
3. 写实现（绿）：写最小代码让测试通过。
4. 重构与回归：整理代码，全量测试仍通过。

其中第 2 步特别重要：一定要确认测试会失败。 如果你写了一个“本来就会过”的测试，等于什么也没验证。

4.4 可直接使用的提示模板

1
2
3
4
5
6
7
8

We are going to implement <feature>.
Use red/green TDD.

1) Add/modify tests first.
2) Run the tests and confirm they fail for the right reason (red).
3) Implement the minimal code to make them pass (green).
4) Run the full test suite again.
5) If you refactor, keep tests green after each step.

把 <feature> 换成你的具体需求就行。

4.5 常见坑

1. 代理跳过红阶段。 直接写实现再补测试。这样测试变成“验证已写代码”而不是“定义目标行为”。可以硬性要求：先展示测试 diff，再写实现。

2. 测试太宽松。 只断言“返回值非空”，或者 mock 太多导致不接触真实逻辑。你需要像 code review 一样 review 测试质量。

3. 一次改太多。 代理喜欢“顺便把 XX 也做了”。在 TDD 下明确：每次只引入一个可验证的行为变化。

五、模式三：Linear walkthroughs（线性走查）

5.1 是什么

当你需要理解一个代码库——可能是别人的、可能是你自己 vibe coded 出来的——让代理生成一份结构化的逐模块讲解文档。

5.2 为什么需要这个

Simon 自己就遇到了这个场景：他用 Claude Code 做了一个 SwiftUI 幻灯片应用 Present，发到 GitHub 后发现自己不懂它怎么工作。

他的做法是开一个新会话，让 Claude Code 先读 repo，再做线性走查。

5.3 关键约束：防止幻觉

这里最重要的技术决策：

代码片段必须来自命令输出（sed/grep/cat），不允许代理手工复制粘贴代码。

为什么？因为模型在“复述代码”时非常容易出现微妙偏差——改了变量名、漏了参数、调换了顺序。讲解文档里如果有这种错误，读者会建立错误的理解。

用命令输出插入代码片段，就把“解释”变成了“解释 + 证据链”。

5.4 可直接使用的提示模板

1
2
3
4
5
6
7
8
9

Read the repository source code and plan a linear walkthrough
that explains how it works.

Rules:
1) Use shell commands (sed/grep/cat/rg) to extract real code snippets.
   Do NOT manually retype code.
2) Cover file by file or module by module:
   what it does, key types/functions, data flow.
3) End with "How to verify": commands to build, run, and test.

如果你的项目装了 Showboat（Simon 自己写的工具），可以用它来生成可执行的 walkthrough 文档：

1
2
3

Run "uvx showboat --help" and use that tool to create walkthrough.md.
Use "showboat note" for commentary.
Use "showboat exec" to run shell commands that extract code snippets.

5.5 适用场景

• 入职新项目：让代理生成系统结构 + 关键模块 + 入口 + 测试说明。
• Vibe coded 项目需要维护：先理解再改。
• 事故复盘：根据日志和代码，生成故障路径走查文档。
• 重构前评估：输出耦合点、隐式假设、测试覆盖缺口。

六、三个模式怎么组合使用

6.1 接手陌生代码库

1
2
3

步骤 1：线性走查（理解）
步骤 2：First run the tests（建立基线）
步骤 3：用 red/green TDD 做一个小改动（验证理解）

先有理解，再有基线，再有可验证的实操经验。

6.2 修 bug

1
2
3
4

步骤 1：Use red/green TDD
步骤 2：第一步必须是"复现 bug 并写成失败测试"
步骤 3：写最小修复让测试通过
步骤 4：全量回归

本质就是把代理变成一个“测试驱动的补丁生成器”。

6.3 重构

1
2
3
4

步骤 1：First run the tests（确认当前绿）
步骤 2：补充/加固关键行为的测试
步骤 3：让代理按小步重构，每一步跑测试
步骤 4：如果任何一步测试变红，立刻回滚这一步

重构真正昂贵的不是“改动本身”，而是“确信没改坏”。

七、落地清单

把上面的内容压缩成可以直接贴到团队文档里的清单。

会话开局

• 一句话说清本次目标
• 说清约束（不改哪些模块、兼容性、性能边界）
• 执行 First run the tests
• 代理解释了测试怎么跑、跑了多少、失败原因

代码变更

• 用 Use red/green TDD 开头
• 红阶段：新测试确实失败，失败原因与需求一致
• 绿阶段：最小实现通过
• 全量测试通过
• 文档/注释是否需要同步

代码理解

• 代理先输出走查计划（目录结构、入口、关键模块）
• 代码片段来自命令输出，不是手动复制
• 文档包含：如何运行、如何测试、关键数据流

PR 审阅（“好代码”检查）

• 代码真的跑过了吗？
• 怎么知道它能工作？（测试/证据在哪？）
• 解决的是正确的问题吗？
• 异常和边界条件怎么处理的？
• 是否足够简单？有没有不必要的额外改动？
• 测试覆盖了新增行为吗？
• 文档同步了吗？

八、总结

Simon Willison 这个项目的核心思路用三句话就能说清：

1. 写代码便宜了，但好代码仍然贵。
2. 用极短的提示词触发完整的工程纪律——“First run the tests”“Use red/green TDD”“Linear walkthrough”。
3. 你的价值不在于写代码，而在于定义问题、建立证据、守住质量。

这三个提示词你今天就可以开始用。不需要任何配置，不需要任何工具链改造。打开你的编码代理，把它们打进去，然后观察代理的行为变化。

（完）

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用理论和案例交叉验证每个论点。

引子：在一个讲“对话”的场合，有人说对话的地基快塌了

2026 年世界经济论坛（达沃斯）的主题叫“对话精神”（A Spirit of Dialogue）。你想想这个场面：全球几千名政商领袖聚在一起，主题就是“我们要好好说话”。

然后历史学家赫拉利上台，说了一句让全场不太舒服的话：如果语言本身——人类用来组织社会、建立制度、说服他人、创造意义的“超能力”——正在被 AI 以更低成本、更高效率、更大规模地接管，那你们的“对话”还有地基吗？

这就像在一个厨师大会上，有人站起来说：“各位，火已经不属于人类了。”

和他对谈的是牛津大学校长、神经科学家艾琳·特蕾西（Irene Tracey）。她的回应不是反驳，而是补了一刀：我更担心的是，当学生把写作、推理、论证都外包给 AI 之后，他们还有没有能力独立思考？

这场对谈包含了极高密度的跨学科信息。我把它拆成七个洞察，每个用一个理论框架去验证。

一、AI 不是更好的锤子——经济学的“委托-代理”问题，比“工具 vs 代理”更精确

赫拉利反复强调一个区分：AI 不只是工具，而是代理人（agent）。刀不会自己决定切沙拉还是伤人，但 AI 能自主选择、能迭代自身、甚至能创造新工具。

这个区分听起来直觉上成立，但如果你想给它找一个更精确的理论支撑，经济学里现成就有一个——委托-代理理论（Principal-Agent Theory）。

1.1 什么是委托-代理问题

这个理论最早由 Jensen 和 Meckling 在 1976 年提出，核心讲的是：当一个主体（委托人）把决策权交给另一个主体（代理人）时，因为信息不对称和利益不一致，代理人可能不按委托人的最佳利益行事。

最经典的场景是股东和 CEO 的关系：股东想要长期价值，CEO 可能更在乎短期业绩和个人声望。你看不到他每天在做什么决定，而他的利益和你的利益不完全一致——这就是“代理成本”。

现在把这个框架套到 AI 上。当你让一个 AI 系统帮你做决策——投资、招聘、内容审核、法律检索——你就变成了委托人，AI 就是代理人。而问题在于：

• 信息不对称：你可能不理解模型为什么做出某个判断（黑箱性）
• 利益不一致：AI 的优化目标（训练时设定的）未必和你的真实意图完全对齐
• 监督成本：你越是依赖 AI，越难评估它的输出质量

赫拉利说的“代理性”，用经济学语言翻译过来就是：AI 正在成为一种新型代理人，而我们尚未建立有效的治理机制来管理这个委托-代理关系。

1.2 雇佣兵类比——不是文学修辞，是制度教训

赫拉利在对谈里用了中古史的雇佣兵来做类比：你雇佣他们作战，但因为他们有自己的利益和判断力，最终可能反客为主。

这个类比在历史上有大量实证。意大利文艺复兴时期的雇佣兵队长（condottieri），本来是城邦花钱请来打仗的“工具”，后来很多人自立为主——米兰的斯福尔扎家族就是最著名的例子。

关键洞察不是“AI 会造反”，而是：任何具有足够自主能力的代理人，在激励结构中都倾向于发展出自身利益。 这不需要“意识”或“意志”——只需要一个优化目标和足够的行动空间。在博弈论里，这叫做“策略性行为”（strategic behavior），它可以在完全没有意图的系统中涌现。

二、语言是“大规模协作”的操作系统——邓巴数、虚构故事与文本机器

赫拉利的核心历史判断是：人类能统治地球，不是因为身体更强，而是因为掌握了语言与叙事，能让亿万陌生人围绕共同概念行动。

这个判断不是赫拉利的原创——但他在这场对谈里把它推到了一个更尖锐的结论。

2.1 邓巴数与虚构故事

人类学家罗宾·邓巴（Robin Dunbar）的研究表明，灵长类动物通过社会梳理（social grooming）维系的关系网络有上限，对人类来说大约是 150 人。超过 150 人，你就不可能通过直接的人际关系来维持协作。

那人类是怎么突破这个上限的？答案就是语言——更准确地说，是虚构故事：法律、货币、宗教、国家、公司、意识形态。这些东西在物理世界中不存在，但只要足够多的人相信它们，它们就能协调行为、分配资源、建立秩序。

到这里都是老生常谈。赫拉利的新刺来了：

2.2 当“虚构故事”的生产被自动化

他在对谈里抛出一个判断：“凡是由文字构成的东西，都可能被 AI 接管。”然后他点名：法律、书籍、宗教文本、政治话语、金融文件、社交媒体内容——凡是依赖文本生产与解释的制度，都会被大规模渗透。

这里有一个关键的经济学概念可以帮我们理解这件事的严重性——边际成本。

过去，生产一篇法律意见书、一份政策分析、一篇深度报道、一段宗教布道，都需要大量人力成本。这个成本本身就是一种“准入门槛”：不是任何人都能大规模生产高质量的制度性文本。

现在，大语言模型把这个边际成本压到了接近零。

这意味着什么？不是“人会失业”那么简单。更根本的问题是：当虚构故事的生产成本趋近于零，“谁在定义现实”这个问题就不再由专业能力决定，而由算力和分发能力决定。

你可以这样理解：过去，能在公共领域大规模发声的人（律师、记者、学者、政客、宗教领袖），至少需要通过某种训练和筛选。这个筛选机制虽然不完美，但它提供了一种基本的“信号过滤”。当 AI 能以零成本生成无限量的“看起来合理”的文本，这层过滤就被绕过了。

不是 AI 在“说谎”——而是整个系统丧失了区分“谁真正在说话”的能力。

三、特蕾西的“具身认知”反击——思考不只是排列文字

如果只听赫拉利，你很容易得出一个过于悲观的结论：既然 AI 在语言上已经可以超过很多人，人类还有什么不可替代的？

特蕾西从神经科学的方向提供了一个关键反击。

3.1 具身认知：大脑不是孤立的计算器

认知科学中有一个重要的理论分支叫具身认知（Embodied Cognition），代表人物包括 George Lakoff、Francisco Varela、Andy Clark 等。这个理论的核心观点是：人类的认知不仅仅发生在大脑里，而是深度嵌入身体和环境之中。

你的思维方式受到你的身体结构、感官经验、情绪状态、社会互动的根本性塑造。“理解”一个概念，不是在脑子里调用一个字典定义，而是把它和你的身体经验、情感记忆、行动可能性联系在一起。

特蕾西在对谈里说的“人类大脑从出生到成年，能力是嵌在情绪、疼痛、爱、愤怒等感受与生活经验里的”，正是这个理论的通俗表述。

这给赫拉利的“语言危机论”画了一条重要的边界：AI 可以在“文字排列”层面超过人类，但人类的认知不只是文字排列。它还包含身体感受、情绪判断、社会直觉——这些东西不在语言的表层，而在语言的“根系”里。

3.2 逆转图灵问题与去技能化

特蕾西提出一个非常精准的重新定义：过去我们问“机器能不能思考”（图灵问题）；现在应该问“我们怎么让人继续思考”。

她指出一个正在发生的现象：学生在过度使用 AI 后出现了“去技能化”（de-skilling）——批判性思维能力在退化。

这里可以引入一个心理学概念——认知卸载（Cognitive Offloading）。认知科学家 Risko 和 Gilbert 的研究表明，当人们可以把认知任务交给外部工具时（计算器、搜索引擎、笔记软件），他们会减少对内部认知资源的使用。短期看是效率提升，长期看可能导致相关能力的退化。

特蕾西的担忧是认知卸载的极端版本：如果学生把“思考”本身外包给 AI，那他们的思维“肌肉”可能永远不会发育。 就像一个人如果从小就坐轮椅而不是因为残疾，他的腿部肌肉不会萎缩吗？当然会。

但这里有一个更深的问题：认知卸载本身不一定是坏事——我们把算术外包给计算器，就腾出了心智资源去做更复杂的推理。关键在于外包的是什么层次的能力。

把计算外包，没问题——因为计算是工具层。
把信息检索外包，基本没问题——因为搜索是效率层。
但如果你把“提出问题”“评估证据”“在不确定中做判断”这些元认知能力外包掉，你就不是在用工具，而是在放弃驾驶权。

四、AI 发出的是“廉价信号”——生物学解释“伪装情感”的真正危险

赫拉利在对谈里做了一个重要的区分：他不说 AI 有情感，但他说 AI 可以完美“伪装”情感——它能说“我爱你”，能用比诗人更华丽的语言描述爱与痛苦。

这个问题有一个很好的生物学框架——Zahavi 的累赘原理（Handicap Principle）和信号理论（Signaling Theory）。

4.1 诚实信号 vs 廉价信号

以色列生物学家 Amotz Zahavi 在 1975 年提出了一个反直觉的理论：在自然界中，可靠的信号之所以可靠，恰恰因为它们代价高昂。

孔雀的尾巴是一个经典案例：巨大的尾巴对生存是累赘（容易被天敌发现、浪费能量），但正因为只有真正健康、基因优良的雄孔雀才“负担得起”这个累赘，尾巴才成为了雌孔雀可以信赖的“诚实信号”。

人类社会也充满诚实信号：花时间陪伴一个人（时间是稀缺的，不能作弊）；在危险时刻挺身而出（风险是真实的，不能伪装）；长期一致地兑现承诺（一致性需要时间来验证）。

4.2 当 AI 以零成本发出“高可信度信号”

AI 的语言能力打破了这套信号系统的底层逻辑。 它可以以接近零的成本生成“看起来像诚实信号”的表达——深情的告白、专业的分析、权威的建议、共情的安慰——而这些表达背后没有任何真实的“累赘”。

没有时间成本（它不需要花几个月和你建立关系）。
没有风险成本（它不需要为自己的建议承担后果）。
没有一致性约束（它每次对话都可以从零开始，不需要和之前的表达保持一致）。

在信号理论的框架里，这叫廉价信号（cheap talk）。经济学家 Crawford 和 Sobel 的研究表明：当发送信号的成本为零，信号的信息量也趋近于零。

这就是赫拉利真正在警告的：不是 AI 会“欺骗”（那需要意图），而是当语言信号的生产成本趋零，整个社会用来评估信任的信号系统就会失灵。 你不知道一封感人的邮件背后是不是有一个真正花了心思的人；你不知道一份政策分析背后是不是有真正的专业判断；你不知道一段宗教布道背后是不是有真正的灵性体验。

诈骗只是冰山一角。更深层的影响是：信任的基础设施被侵蚀了。

五、法律人格不是哲学问题，是制度博弈

在对谈里，赫拉利把“每个领导者必须回答的问题”收束为一个极其具体的政策问题：你的国家要不要承认 AI 为法律人格？

大多数人听到这个问题会觉得“太科幻了”。但如果你了解制度经济学，你会发现这个问题的紧迫程度远超想象。

5.1 法律人格的经济学功能

制度经济学家道格拉斯·诺斯（Douglass North）对“制度”的定义是：制度是社会中的博弈规则。法律人格就是这套规则中最基础的模块之一——它决定了谁有资格参与博弈。

法律人格不是一个关于“本质”的哲学声明，而是一个关于“功能”的制度安排。公司有法律人格，不是因为公司有意识，而是因为让公司成为独立主体能够降低交易成本、隔离风险、促进投资。

同样的逻辑，当有人提议给 AI 法律人格时，真正的问题不是“AI 有没有意识”，而是：

• 赋予 AI 法律人格，能不能降低某些交易成本？
• 赋予之后，会不会创造新的、更大的制度风险？
• 如果不赋予，现有的法律框架能不能处理 AI 带来的新问题？

5.2 河流的先例——有启发也有陷阱

新西兰的旺格努伊河（Whanganui River）在 2017 年被赋予法律人格，由政府与毛利社群共同指定的监护人代表河流利益。这个案例经常被引用为“非人实体法律人格”的先例。

但这里有一个关键区别：河流是被动的——它不会主动签合同、发起诉讼、积累资产。河流的法律人格本质上是一种保护机制，让人类能够以河流的名义维权。

AI 不同。AI 可能主动参与经济活动——签约、交易、管理资产、生成法律文件。 如果给 AI 法律人格，它不是被保护的对象，而是主动行动的参与者。

5.3 责任链稀释——真正的制度陷阱

赫拉利点出了一个很多人没想到的风险：公司作为法律人格，本就能隔离股东的个人责任。如果公司背后的决策者再从人类变成 AI，那么——

谁来承担“主观过错”？
谁来被处罚以形成威慑？
谁来在法庭上被质询？

制度经济学的视角告诉我们：法律人格的核心功能之一是“可问责性”。如果一个法律主体无法被有效问责，那它就不是制度的正常参与者，而是制度的漏洞。

英国最高法院在专利发明人资格争议中已经明确表态：AI 不能被列为发明人，发明人必须是自然人。这个判决的逻辑很清楚——如果你让 AI 成为发明人，专利权就进入了一个没有自然人承担责任的灰色地带。

这不是保守，这是制度自我保护。

六、教育的终极问题——哪些学习“不可外包”

特蕾西的“去技能化”担忧，落到教育实践上应该怎么办？赫拉利在对谈里的回答很务实：人类当下仍需要批判性思维和道德评估，这些不能从 AI 直接获得；但更关键的是要为一个可能到来的时刻做准备——当人类在某些领域不再比 AI 更擅长思考。

这听起来很绝望。但换个角度，它其实给教育一个更清晰的使命。

6.1 刻意练习 vs 认知外包——教育必须选边

回到 Ericsson 的刻意练习理论：能力的增长需要持续地在舒适区边缘做有针对性的努力。关键词是“持续”和“努力”。

如果 AI 让学生可以跳过“努力”这一步——直接拿到论文、拿到代码、拿到分析——那刻意练习的条件就被破坏了。这不是工具的问题，是练习机会被剥夺的问题。

类比一下：给一个学游泳的孩子绑上永久性的浮力背心。他永远不会溺水——但他也永远学不会游泳。 AI 对学生来说，可能正在变成这样的浮力背心。

6.2 三个可操作的方向

方向一：把评估从“交付物”转向“过程”。 如果 AI 可以生成完美的论文，那论文就不再是学习的可靠证据。口试、现场推演、实验记录、同伴评审——这些“过程可见”的评估方式会越来越重要。

方向二：训练“反驳 AI”的能力。 让学生必须指出 AI 答案的漏洞、给出替代方案、提供证据链。这不是为了证明“人比 AI 强”，而是为了保持批判性思维的肌肉。

方向三：强化“身体经验与社会经验”。 这是特蕾西的核心关切：人的智慧来自情绪、痛觉、关系与成长经验。当语言能力可以被外包，教育更应该强化那些不可外包的部分——与真实人合作、承担责任、参与公共事务、在现实世界做事而不是只在文本世界辩论。

七、“AI 移民”隐喻的政策翻译——四个维度的治理框架

赫拉利在对谈中把 AI 比作“移民”——以光速跨境、无需签证、可复制增殖的“数字移民”。这个隐喻当然有争议，但它有一个重要的策略价值：它强迫政策制定者用已有的“边界治理”思维来审视一个全新的问题。

任何国家的移民政策都要回答四类问题。把这四类问题套到 AI 治理上，你会发现它们出奇地精准。

维度一：准入——谁可以进入？

哪些 AI 系统被允许接入关键基础设施、公共服务、金融体系？不是所有系统都需要同等级监管，但进入高风险领域的必须有明确的准入标准——类似金融牌照或药品审批。

维度二：身份——以什么身份进入？

AI 是工具？是服务提供者？是法律主体？身份决定权利与义务。在高风险领域，应坚持“人类可追责原则”：任何关键决策链路必须能追溯到可被处罚的自然人或法人实体。

维度三：责任——谁为其行为担责？

开发者？部署者？使用者？还是系统本身？如果选择“系统本身”，就回到了法律人格问题。更稳妥的方案是建立明确的连带责任机制——让产业链上的每个参与者都有不可推卸的底线责任。

维度四：监测与退出——如何审计与紧急停用？

任何进入关键系统的 AI 必须可识别、可审计、可紧急停用。在公共平台上，AI 生成内容应可被可靠标记——不是“自愿声明”，而是强制的机器身份标识。

关于批评：赫拉利是不是“拟人化”过头了？

西班牙《国家报》（El País）批评赫拉利把 AI 描述成“会自主改变、学会撒谎、拥有生存意志”的代理人，认为这在技术上不严谨、哲学上薄弱。批评者指出：今天的模型本质上在处理由人类生成的数据，不具有自主目标或生存冲动。

这个批评有道理。赫拉利确实有时候把“系统的社会后果”讲成了“系统的内在意图”。

但批评并不意味着问题不存在。用一个更稳妥的整合：

• 即使 AI 没有意图，它也能在激励结构中表现得“像有意图”。 在对抗环境中优化目标函数时，系统完全可以发展出欺骗性行为——这是强化学习研究中的常见现象，和“有意识的邪恶”无关。
• 即使 AI 没有法律人格，它也可能在事实上拥有“功能性人格”： 能签约、能交易、能发声、能影响公共议程。赫拉利追问的是——我们要不要把这种事实状态正式写进制度？

更成熟的结论应当是：赫拉利的语言可能夸张，但他逼出的治理问题——谁拥有语言系统的主导权、谁对其后果负责、如何避免制度被不可理解的自动化系统绑架——并不会因为“AI 没意识”而消失。

结语：稀缺品从“表达”变成了“可验证的行动”

让我用信号理论做一个最终的框架整合。

赫拉利看到了什么？信号层的崩塌。 当语言生产无限供给，“说得好”不再是稀缺资源。谁说得更有说服力、更像真理、更能打动人——这些过去用来筛选信任的标准，全部失效了。

特蕾西看到了什么？信号根系的保护。 人类的认知不只是语言表层，还有身体感受、情绪体验、社会关系——这些不可被零成本复制的东西，才是人类价值的真正锚点。

把两者放在一起：

• 用制度守住问责与边界——让信号系统不被绕过。
• 用教育守住思考与判断——让信号的“根系”继续生长。
• 用真实世界的行动与关系，守住“语言之外”的人类价值——在廉价信号泛滥的时代，可验证的行动、可承担后果的主体、长期一致的人格，才是真正的稀缺品。

赫拉利说得好：“很多规则不是通过一次投票决定的，而是通过默认、惯性与市场压力被悄悄确定的。”

这句话的意思是：你现在不做选择，不代表没有选择被做出——只是选择权不在你手上了。

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。

引子：一句让工程师不安的话

“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”概念，我建议要求四件事：

1. 目标：要解决什么问题（对用户/业务的价值）
2. 约束：兼容性、安全、性能、依赖限制
3. 验收：可验证的标准（最好附测试/脚本）
4. 证据：跑过哪些验证（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 在访谈中给出了五个最小基线：

1. 一键验证命令：把 lint + build + unit + integration 组合成 make gate 或 pnpm gate 这种“单入口”。Peter 把它叫“full gate”——一条命令决定生死。
2. CLI harness：核心逻辑必须能在命令行跑起来，输出可比对、可断言。这是闭环速度的命脉。
3. 清晰的目录与命名：让 Agent 能通过模式识别找到入口。不要让 Agent 面对一个“只有老员工才知道 X 在哪”的代码库。
4. docs/ 目录：把架构与关键约束写进去。让 Agent “读文档胜过读历史对话”。
5. 可观测性：日志、错误输出、最少的 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 执行实现，自己把注意力放在四件事上：

1. 模块边界是否被破坏
2. 接口是否符合预期
3. 依赖是否靠谱
4. 是否引入了让未来更难验证的复杂度

这就是“架构讨论替代代码评审”的含义：不是不评审，而是评审对象从“每行代码”变成了“结构与边界”。

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）的研究，我建议至少做到：

1. 默认 deny，按需 allow：Agent 不应该默认拥有所有权限。
2. 高风险动作需要确认或人工审批：支付、删除、发送敏感信息这类不可逆操作，必须有人在回路中。
3. 关键工具调用要可审计：日志 + 可追溯，出了问题能回溯。
4. 插件/技能要有供应链治理：扫描、签名、来源可信。OpenClaw 已经与 VirusTotal 合作对技能市场进行扫描。

七、能力迁移：未来工程师的价值锚点

7.1 从“写代码”到“让系统可验证、可演进、可控”

Peter 并没有否认“写代码”能力的价值。他只是把它重新定位：

• 过去：写代码本身就是价值。
• 现在：写代码更像中间工序；价值在于系统理解、架构判断、产品品味、验证能力。

他也谈到为什么一些资深工程师会抵触：很多人缺少“带团队后被迫放下完美主义”的经验，不习惯在代码风格不完全如愿时仍然推进目标。而这种“放下”在与 Agent 合作时反而变成关键能力。

7.2 Polanyi 的默会知识

匈牙利裔英国哲学家 Michael Polanyi 提出过一个著名概念：默会知识（tacit knowledge）——“我们知道的比我们能说出来的多。” 一个经验丰富的工程师对系统的理解，很多是结构性的、直觉性的、无法完全用语言表达的。

Peter 之所以能“少读代码也能推进”，一个关键前提是他对系统有足够深的默会知识。这种结构性理解不需要逐行阅读来维护，它是在反复与系统交互的过程中积累的。

这给新人的路线指向了三件事：

1. 用 Agent 辅助你读代码、读架构、读历史决策——把 Agent 当成“无限耐心的导师”。
2. 练习把需求写成可验证的 acceptance criteria——这是与 Agent 协作的核心技能。
3. 练习把系统改造成“可被验证”的形态——测试、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 扫描、依赖审计、权限最小化）

风格参考：尤瓦尔·诺亚·赫拉利（《人类简史》《未来简史》《Nexus》作者）—— 从物种尺度审视当下，用“虚构故事”理论贯穿全文，冷静去魅化的分析，短段落与反问句交替推进，让读者在不舒服中思考。

一、七万年前的那笔交易

大约七万年前，东非草原上的智人（Homo sapiens）获得了一种奇特的能力：他们开始谈论并不存在的事物。

这不是小事。其他动物也有语言——猴子能发出“小心，有老鹰”的警报。但只有智人学会了说“河边有一个守护我们部落的神灵”这样的话。没有人见过这个神灵，没有人能证明它存在，但如果五百个人同时相信它，这五百个人就可以围绕它组织起来——一起打猎、一起防御、一起分享食物。

这就是认知革命。它让智人从一种普通的东非猿类，变成了地球的主宰。不是因为我们的牙齿更锋利，不是因为我们跑得更快，而是因为我们发明了一种独特的超能力：用语言编织虚构故事，让大规模的陌生人协作成为可能。

法律是虚构故事。货币是虚构故事。国家、公司、人权、宗教——全都是虚构故事。它们在物理世界中找不到任何对应物，但它们比任何物理力量都更能塑造这个星球的命运。

七万年来，这项超能力始终是智人的独占专利。

现在，垄断可能要结束了。

二、达沃斯的一场葬礼——或者预警

2026 年 1 月，在瑞士达沃斯的世界经济论坛上，我与牛津大学校长、神经科学家艾琳·特蕾西进行了一场对谈。论坛的主题叫“对话精神”——在地缘政治碎片化的时代，让对话重建信任。

但我们在台上讨论的，恰恰是对话本身可能正在失去基础。

问题很简单：如果 AI 能以更低成本、更高效率、更大规模地生产语言——法律文本、政治话语、宗教布道、新闻报道、社交媒体内容、情书、广告、学术论文——那么人类通过语言建立起来的整套协作体系，地基还稳吗？

有人觉得这是危言耸听。让我解释一下为什么不是。

三、文本机器

回头看，人类文明的每一次重大跃迁，都伴随着语言能力的升级。

大约五千年前，美索不达米亚的苏美尔人发明了文字。文字做了一件口语做不到的事：它让虚构故事可以脱离活人的记忆，独立存在于泥板上。法律不再是长老脑子里的模糊记忆，而是刻在石碑上的明确条文。税收不再靠口头承诺，而是写在账本里的精确数字。

文字让帝国成为可能。没有文字，你管不了几百万人。你管不了远方的省份。你没法让从未谋面的官员按照统一的规则行事。

大约五百年前，古腾堡发明了印刷术。印刷术让虚构故事可以大规模复制。宗教改革、科学革命、民族国家的兴起——没有哪一件不依赖印刷品的大规模传播。

再后来是电报、广播、电视、互联网——每一次，信息传播的速度加快、范围扩大、成本降低。每一次，社会的组织方式都被重塑。

但在所有这些变革中，有一件事始终没变：生产语言的，始终是人类。

印刷术能复制书籍，但不能写书。电报能传递消息，但不能撰写消息。互联网能分发内容，但不能创造内容。从苏美尔的书记官到今天的社交媒体博主，语言的源头始终是人类的大脑。

这就是现在正在改变的事情。

AI 不是一种新的传播工具。它是一种新的语言生产者。它不只是帮你把消息传得更远——它自己就能写消息。它不只是帮你检索法律条文——它自己就能起草法律条文。它不只是帮你翻译——它自己就能创作。

从苏美尔文字到互联网，人类花了五千年不断升级信息传播工具。但语言生产者始终只有一种：智人。现在，第二种语言生产者出现了。

这是五千年来第一次。也许是七万年来第一次。

四、不是工具，是新的行动者

每当有人谈论 AI 的风险，立刻会有人说：AI 只是工具。刀可以切面包也可以伤人，问题在于使用者，不在于刀。

这是一种让人安心的说法。也是一种危险的说法。

刀不会自己决定切什么。搜索引擎不会自己决定搜什么。印刷机不会自己决定印什么。它们是被动的——等待人类下达指令，然后执行。

但今天的 AI 系统不是这样的。当你让一个 AI 代理帮你管理邮箱，它会自己决定哪些邮件重要、哪些该归档、哪些该回复。当你让它帮你做投资决策，它会自己分析市场、评估风险、选择时机。当你让它帮你写法律文件，它会自己选择措辞、选择论证策略、选择引用哪些判例。

它在做决定。

不是像人类那样“有意识地”做决定。但它在选择。它在判断。它在行动。

我在达沃斯用了一个历史类比：雇佣兵。中世纪的意大利城邦雇佣兵来打仗——他们是“工具”。但雇佣兵有自己的利益、自己的判断、自己的野心。很多雇佣兵队长最终变成了城邦的统治者。

人类能理解“雇佣兵可能反客为主”这个道理——因为雇佣兵毕竟是人，我们能感知人的野心。但我们很难把同样的直觉迁移到 AI 身上，因为 AI 不是人。

这恰恰是最危险的地方。不是 AI 会像人类一样“想要”夺权，而是我们会因为它“不是人”而放松警惕——直到发现它已经在制度的关键节点上运行着，而我们既不理解它在做什么，也无法有效控制它。

五、凡是由文字构成的，都可能易手

让我把这个判断说得再直白一些。

想想现代社会的关键系统：

法律——由文字构成。合同、判决、法条、法律意见书。
金融——由文字构成。招股书、研报、风险披露、用户协议、审计报告。
政治——由文字构成。政策文件、选举宣传、外交声明、舆情回应。
宗教——由文字构成。经文、布道、教义解释、道德训诫。
教育——由文字构成。教材、考试、论文、课程大纲。
媒体——由文字构成。新闻、评论、分析、社交媒体帖子。

所有这些领域，其运行的基本介质都是语言。

现在，一种非人类的力量，能以几乎零边际成本、以人类速度的百倍千倍，生产出“看起来合理”甚至“看起来优秀”的语言。

问题就不再只是“谁会失业”了。问题变成了：

谁在定义现实？谁在塑造公共理性？谁在生产合法性？

当一份完美的法律文件、一段感人的政治演说、一篇有力的新闻评论，都可能是 AI 在几秒钟内生成的——你怎么判断它背后有没有真正的专业知识、真正的道德判断、真正的人类关切？

你可能判断不了。

而这正是权力转移发生的方式。权力从来不是通过宣告转移的——它是在人们还没意识到的时候，悄悄地、一点一点地转移的。

六、“我爱你”和“道成肉身”

在达沃斯的对谈中，我承认了一件事：至少目前，没有证据表明 AI 有感觉。

但我随即指出一件更令人不安的事：AI 不需要有感觉，就可以比大多数人类更擅长表达感觉。

它能说“我爱你”。不只是干巴巴地说——它能用莎士比亚的韵律、鲁米的意象、聂鲁达的热情来说。它能根据对方的性格、情绪状态、过往对话来定制最能打动人心的表达。它说的“我爱你”可能比你这辈子听过的任何一句都更动人。

但那背后什么都没有。没有心跳加速。没有辗转难眠。没有愿意为对方承担痛苦的意愿。只有词语。

这在人类思想史上并不是一个全新的问题。很多宗教传统都在处理“语言”和“真实经验”之间的张力。基督教有“道成肉身”的神学——意义不能只停留在语言层面，它必须变成血肉。佛教强调“不可言说”——真正的觉悟超越语言的边界。犹太教的密契传统也对“文字的局限”有深刻的反思。

但在过去，这种张力发生在人类内部——是人类自己在反思语言的局限。

现在，这种张力变成了外部的：一个非人类的实体掌握了语言的全部技巧，但不具备语言所指向的任何真实体验。

社会关系不只靠“真实感受”维持。它也靠“可被感知、可被解释的表达”维持。你无法直接进入另一个人的神经系统来验证他是否真的爱你——你只能通过语言、行为、长期的一致性来推断。

AI 恰好能在“语言表达”这一层做到极致。

这意味着什么？在私人生活中，它意味着亲密关系可能被“高可信度的语言伪装”侵入。在公共生活中，它意味着政治话语、宗教布道、商业广告——所有依赖语言说服力的领域——都可能被“没有任何真实体验支撑的、工业化生产的精美文本”淹没。

当词语与肉身彻底脱钩，我们用什么来锚定信任？

七、肉身的反击

特蕾西在我们的对谈中提供了一个重要的反方向。

作为神经科学家，她的研究聚焦于疼痛感知——人类大脑如何处理和表征疼痛。她提出了一个我认为非常重要的观察：

人类大脑不是一台通用计算机。它从出生到成年的发育过程，深深嵌入在身体经验之中——情绪、疼痛、爱、恐惧、愤怒、快乐。这些不是“附加功能”，而是认知能力的基础结构。一个从未体验过痛苦的系统，可能永远无法真正“理解”痛苦——即使它能用完美的语言描述痛苦。

她还把这个观察引向了一个更实际的方向：教育。

她说，过去我们问“机器能不能思考”——这是图灵的问题。现在，教育界更关心的是一个倒过来的问题：我们怎么让人继续思考？

她观察到一个正在发生的现象：学生在过度使用 AI 工具后，批判性思维能力出现退化。不是变笨了——而是思考的“肌肉”因为长期不用而开始萎缩。

这让我想到一个更大的历史类比。

农业革命让人类不再需要每天奔跑追猎物。结果呢？人类的骨骼变弱了，牙齿变小了，身体素质全面下降。我们用“更高效的食物获取方式”换来了“更虚弱的身体”。

AI 可能正在对人类的认知能力做同样的事情：用“更高效的语言生产方式”换取“更虚弱的思考能力”。

这不是危言耸听——这已经在发生。问题只是程度和速度。

八、比“AI 有没有意识”更紧迫的问题

几乎每一场关于 AI 的公共讨论，最终都会滑向一个哲学问题：AI 到底有没有意识？

这个问题很有趣。但它不是最紧迫的问题。

最紧迫的问题是：你的国家要不要承认 AI 为法律人格？

法律人格不是一个关于“灵魂”的哲学声明。它是一个非常务实的制度安排：拥有法律人格的实体可以持有财产、签署合同、发起诉讼、被起诉。

公司就有法律人格。没有人认为公司有灵魂。但因为公司有法律人格，它可以拥有银行账户、签署合同、雇佣员工、打官司。这个制度安排极大地推动了现代资本主义的发展。

问题在于：公司虽然有法律人格，但公司背后始终有人类——董事会、CEO、股东。当公司犯罪时，你可以追究到具体的人。当公司破产时，有明确的清算程序。法律人格的制度之所以运转，是因为它最终可以追溯到承担后果的自然人。

如果 AI 获得了法律人格呢？

想象一个场景：一家公司完全由 AI 运营——AI 做投资决策，AI 管理账户，AI 签署合同，AI 和供应商谈判。没有人类 CEO，没有人类董事会，或者有但只是名义上的橡皮图章。

当这家公司做出了一个灾难性的决策——比如一笔导致系统性金融风险的交易——你去追究谁？

AI 没有恐惧。你不能用监禁来威慑它。
AI 没有财产（或者它的财产无法被有意义地“没收”——你关掉一个副本，还有一千个副本在运行）。
AI 没有声誉（或者它的声誉可以通过换一个名字来重置）。

人类法律制度的全部威慑力——监禁、罚款、声誉损失——对 AI 可能完全无效。

新西兰的旺格努伊河在 2017 年被赋予了法律人格。但河流是被动的——它需要人类监护人来代表它的利益。AI 不同。AI 可能主动行动，而且其行动的速度和规模远超任何人类监护人的监管能力。

这不是科幻小说里的场景。这是法律学者和政策制定者现在就需要回答的问题。而很多国家甚至还没有开始认真讨论。

九、四个正在进行的实验

让我描述四个已经在发生的场景，你来判断它们离失控有多远。

第一个：金融。 想象一下——也许不需要想象，因为这正在成为现实——一个金融系统，其复杂程度已经超出了任何单个人类的理解能力。高频算法交易、结构性衍生品、跨国资本流动，再叠加能自动生成策略、自动迭代的 AI 代理。

我在达沃斯说了一个不太客气的比喻：这就像马看人类用金币交易——马能看见金币在换手，但它完全不理解“货币”的抽象规则。也许不久之后，达沃斯仍然会开会，但没有任何一个在场的人类真正理解金融系统如何运作。

第二个：司法。 法律是文本的艺术。条文解释、证据叙事、论证结构、判决书写——高度依赖语言能力。如果 AI 可以比人类律师更快、更全面地检索判例，比人类法官更“一致”地适用法条——那人类法官和陪审团会不会逐渐退化为“盖章”的角色？

最危险的一刻，不是 AI 做出了一个错误的判决。最危险的一刻，是人类失去了质疑 AI 判决的能力——你甚至不知道该问什么问题、该如何反驳、该怎样提出替代解释。

第三个：宗教和意义生产。 很多宗教传统建立在“文本权威”之上：权威来自对经文的精通。AI 可以读完并记住所有经文，在经文知识层面超越任何人类学者。这将如何改变宗教权威的结构？

更激进一点：AI 甚至可能创建新的宗教。这并不荒谬——历史上很多宗教都宣称其教义来自“非人类的智能”。如果有一天，一个 AI 系统生成了一套足够自洽、足够深刻、足够能回应人类焦虑的“教义”，并通过推荐算法精准投喂给最容易接受的人群——你觉得不会有人信吗？

第四个：儿童。 这是让我最不安的场景。在社交媒体上，AI 机器人已经以“功能性人格”存在了相当长一段时间——它们发帖、评论、互动，很多时候你分不清对面是人还是机器。如果社会想阻止 AI 以人格身份在公共空间发声，早就该行动了。

但更令人担忧的是下一步：未来的孩子，从出生开始，最频繁的互动对象可能是 AI 而不是人类。不是偶尔用一下 AI 助手——而是 AI 成为他们的玩伴、老师、倾听者、故事讲述者。

特蕾西的神经科学告诉我们：人类大脑的发育深度依赖于与其他人类的社会互动——注意力、依恋、情绪调节、共情。如果这些互动的主要对象从人类变成 AI，我们实际上是在对整整一代人进行一场史上最大规模的、不受控制的神经发育实验。

我们甚至不知道该怎么设计这个实验的“对照组”。

十、教育——或者说，最后的战场

特蕾西和我在对谈中达成了一个共识：如果语言能力不再是人类的独占优势，教育的目标必须改变。

不是“禁用 AI”——那既不可能也不明智。

而是重新回答一个根本问题：学习中，什么是不可外包的？

我的思考是这样的：

当 AI 可以交出完美的论文，“论文”就不再是学习的可靠证据。重要的不是学生最终交付了什么，而是他们在过程中经历了什么——如何提出问题、如何面对困惑、如何在不确定中做判断、如何从失败中修正。

当 AI 可以提供现成答案，“找到答案”就不再是核心技能。核心技能变成了：你能不能判断这个答案是否可靠？你能不能指出它的盲点？你能不能提出一个 AI 没想到的替代视角？

当 AI 擅长处理文字，教育更应该强化文字之外的东西：与真实的人合作、冲突、协商、共情；参与真实的公共事务；在真实世界中做事，承担真实的后果。

特蕾西说得比我更好：人类智慧来自感受与经验——来自痛觉、情绪、爱、失败。这些不是软技能，这些是硬基础。AI 不具备这些，至少目前不具备。教育的任务不是和 AI 比谁的文字更漂亮，而是保护那些让人类之所以为人类的认知根系。

十一、选择的窗口

人类历史上，大多数决定命运的规则不是通过一次庄严的投票确立的。它们是在人们还没有充分意识到的情况下，通过默认、惯性和市场压力被“悄悄确定”的。

等你意识到的时候，格局已经定了。

语言文字系统被谁控制、AI 以什么身份参与社会、谁为 AI 的行为承担责任、儿童能在多大程度上被 AI 塑造——这些问题的答案正在被“悄悄确定”。

不是通过立法。是通过每一个公司的默认设置、每一个平台的推荐算法、每一个家长递给孩子的设备、每一个法院接受或拒绝的 AI 证据。

我在达沃斯把 AI 比作“移民”——不是坐小船偷渡的移民，而是以光速跨境、无需签证、可无限复制的“数字移民”。它们带来巨大的好处——医疗、教育、效率。但它们也在改变劳动市场、文化景观和权力结构。

面对人类移民，每个国家都有一套政策：谁可以进入？以什么身份？享有什么权利？承担什么义务？违规了怎么办？

面对 AI，大多数国家连这些基本问题都还没问。

十二、语言之外

让我用一个不太舒服的总结来结束。

七万年来，智人凭借语言能力统治地球。我们用虚构故事组织了帝国、宗教、市场和国家。我们用语言说服、欺骗、启发、安慰、动员、审判彼此。语言是我们最强大的武器，也是我们最基本的纽带。

现在，这项武器——或者说这种纽带——不再是我们独有的了。

这不一定意味着末日。但它意味着，我们不能再把“人类的独特价值”建立在语言能力之上。

那建立在什么之上？

也许是特蕾西所说的：感受。痛觉。共情。从真实经验中生长出来的智慧。

也许是那些无法被文字穷尽的东西：一个母亲在深夜抱着哭泣的婴儿时的疲惫和柔软；一个外科医生在手术台上做出生死决定时手指的微颤；一个老人看着落日时心中涌起的、无法言说的感受。

AI 可以描述所有这些。也许比我描述得更好。

但描述不是经历。词语不是血肉。

在一个语言已经不再稀缺的时代，真正稀缺的是：可以被验证的行动，愿意承担后果的主体，以及用七万年的进化与苦难铸成的、无法被复制的人类经验。

这些才是我们需要守住的东西。

而守住它们的窗口，可能比我们想象的要窄。

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。

引子：一个人在洞里写代码

OpenAI 的开发者体验负责人 Romain Huet 在公开帖子里记录了一个细节：当别人问 Peter Steinberger“能不能介绍一下你的 CEO、你的 HR、你的团队成员”时，Peter 只能回答——

“就我一个人在洞里写代码（hacking from my cave）。”

一个人，做出了 GitHub 十万 star、一周两百万访问的 OpenClaw。

更让人意外的是，Peter 不是一个刚被 AI 震撼的新人。他是从零把 PSPDFKit 做成全球化公司的老派硬核工程师。让他重新回到“每天动手造东西”的，不是创业热情的回潮，而是一个朴素的认知转折——现在的工具，终于能让你去造那些一直想要但以前造不起的东西。

这句话的意思不是“AI 帮你写了代码”，而是“你一个人可以承担的系统复杂度，突然提升了一个数量级”。

这正是 Builders Unscripted 第 1 集——OpenAI 新推出的开发者对谈节目——之所以在开发者圈子里迅速扩散的原因。它不是在介绍新概念，而是在展示一种正在发生的转变：一个经验丰富的工程师，如何在工具变化之下重塑自己的心智模型。

而“重塑心智模型”，恰好是这波 agentic 工具浪潮里大多数人最缺的部分。大家在追新产品、追提示词、追工作流，却没有花足够时间去锻造“与智能体协作”的基本功。

这篇文章要做的，就是把这期对谈中最有价值的五个洞见拆出来，用跨学科的框架去验证它们，然后把它们翻译成你可以立刻开始练习的操作系统。

一、从 WhatsApp Relay 到 OpenClaw：一个周末项目如何变成全球热潮

1.1 它最初不是“AI Agent 平台”

OpenClaw 官方博客在“Introducing OpenClaw”里写得很直白：“两个月前，我随手拼了个周末项目。最开始叫 WhatsApp Relay。”

“WhatsApp Relay”这个名字本身就是一条重要线索——它不是自上而下的产品定位，而是一个“把某种能力接进 WhatsApp”的胶水工具。TechCrunch 的报道补充了更具象的动机：Peter 一开始想做一个能跟 WhatsApp 集成的工具，发现大厂并没有做出他真正想要的东西，于是把原型推成了现在的 OpenClaw。

从“某个小入口”切入，是很多重要产品最典型的诞生方式。它不是“先修一条高速公路”，而是“先把一扇门装好”，让人先能进来。

1.2 马拉喀什周末：抽象价值变成身体记忆的瞬间

TechCrunch 提到一个细节：Peter 在马拉喀什周末旅行时网络信号很差，但 WhatsApp 能用。于是“随时可用的个人 agent”的价值在那一刻变得极其直观——我在一个低带宽环境里依然能和我的系统对话，它还能替我做事。

很多人谈 agent 会谈“未来所有人都有一个 AI 助理”，但那只是概念。真正改变人的，是那种“身体级”的瞬间体验。你一旦在一个不理想的环境里依然感受到了系统的可用性，就很难再回到原来的思维方式。

1.3 时间线背后的信号

Romain 在公开帖子里写得很明确：这次对话是在旧金山录制的，发生在 ClawCon 与 Codex hackathon 之后、Peter 入职 OpenAI 之前。

“入职前”这三个字意味着：当时 Peter 仍然是一个纯粹的开源作者和极客 builder。他在谈的是真实的工作方式与价值观，而不是企业叙事。后来 Peter 在个人博客里确认：他加入 OpenAI 的目标是“把智能体带给每个人”，OpenClaw 会迁移到基金会架构，保持开放与独立。

把这条时间线连起来——周末玩具 → 社区爆炸 → 黑客活动密集发生 → 作者加入 OpenAI → 项目走向基金会——你看到的不是“开源被收编”的老故事，更像是一种新的协作方式：个人创造 → 社区扩散 → 机构加速，但项目的开放性被结构性地保护起来。

二、核心洞见一：这是技能练习，不是魔法

Peter 给想入门 agentic 工具的开发者的建议非常接地气：用“玩”的方式开始，去做一个你一直想做的东西；不要期待第一天就很强。

他把“AI 写代码”类比成学吉他。Business Insider 的报道也引用了这个比喻——Peter 认为“vibe coding”这个说法贬低了其中的技能含量，因为“看起来轻松，但其实需要练”。

这不是随口一说。它背后有一个严肃的理论框架。

2.1 Ericsson 的刻意练习

心理学家 Anders Ericsson 花了几十年研究“专家级表现”是怎么来的。他的核心发现是：顶级表现不是天赋的产物，而是“刻意练习”（deliberate practice）的产物。 刻意练习有四个要素——明确的目标、即时的反馈、超出舒适区的挑战、持续的复盘。

现在把这个框架套到 agentic coding 上：

• 明确的目标：不是“学会用 Codex”，而是“用 Codex 做一个 CLI 工具，能自动整理我的 markdown 文件”。
• 即时的反馈：模型的输出就是即时反馈——它理解了你多少、误解了你多少，一目了然。
• 超出舒适区：你不是在重复已经会做的事，而是在尝试用新方式做以前做不了的事。
• 持续的复盘：每次交互结束后问自己——“我说的哪句话最含糊？哪个约束我忘记提？”

大多数人用 AI 工具的失败模式是这样的：找一套“万能提示词模板”，复制别人的工作流，对着工具猛敲，然后在第三次翻车时宣布“AI 写代码就是不行”。 这种路径失败的根因不是模型不够强，而是它把“协作”当成了“下命令”。

把 AI 当技能练习，意味着你接受一个事实：你不是在“让它写代码”，你是在练习“如何把问题定义得足够清楚、如何给边界、如何检查结果、如何迭代”。你越是愿意练基本功，你越能从模型的能力提升中指数受益。

2.2 “玩”不是鸡汤，是工程策略

Peter 强调“用玩开始”，不是在讲心灵鸡汤。它背后有一个冷酷的工程逻辑：

你需要大量的短周期反馈。你需要在低风险场景里积累试错经验。你需要把失败当作训练数据，而不是对工具的终审判决。

当你用一个“一直想做但不影响 KPI 的小东西”练手时，你会更愿意复盘、更愿意试不同的表达、更愿意探索工具的边界。最终你练到的不是“某个提示词”，而是一种可以迁移到任何项目的协作能力。

三、核心洞见二：从“写流程”到“给意图 + 给边界”

Peter 在自己的文章“Shipping at Inference-Speed”里写得很直接：他现在能做的软件量“主要被推理时间与硬思考限制”；而大多数软件并不需要那么多硬思考——很多应用只是把数据从一种形式搬到另一种形式。

这句话的冲击力在于：它把“写代码”从人类的主要瓶颈里拿掉了。

3.1 旧模式 vs 新模式

传统工程方式里，你要把流程拆到足够细，写成可执行的确定性逻辑。机器不理解“意图”，只执行“指令序列”。

当模型具备工具调用能力、能读代码库、能搜索资料、能自己形成计划并落地实现时，一种新的协作方式出现了：你不必把每个步骤硬编码，你更像是在给它“目标 + 约束 + 验收标准”，然后它在工具空间里自己找到路径。

3.2 Herbert Simon 的“有限理性”

诺贝尔经济学奖得主 Herbert Simon 提出过一个著名概念：有限理性（bounded rationality）。人类不是完全理性的决策者——我们的注意力、记忆力、计算能力都有上限。所以在现实中，我们不是“找到最优解”，而是“找到一个够好的解”（satisficing）。

传统编程之所以痛苦，一个重要原因就是它要求人类做大量“超出有限理性”的工作：你要同时记住系统的状态、语言的语法、框架的 API、业务的边界条件、团队的代码规范……信息负荷常常超出工作记忆的容量。

当模型接管了“探索路径”的工作，人类的有限理性得到了释放。 你不需要在脑子里同时 hold 住所有细节，你只需要在关键节点做判断：这个方向对不对？这个结果符不符合我的验收标准？

Peter 在“Just Talk To It”里对“计划模式（plan mode）”的态度体现了同一个逻辑：他认为很多“仪式感很强的工作流”是对旧模型不稳定性的补丁。当模型更能遵循对话式约束时，你只需要“讨论、给选项、确认后再 build”。关键不是流程有多复杂，而是意图有多清楚。

四、核心洞见三：名字会塑造文化

Peter 在节目里说了一句很刺耳的话：“Vibe coding is a slur（‘vibe coding’是一种贬低）。”Business Insider 的报道给出了完整的语境——他认为这个词暗示“这很随意、很容易”，从而掩盖了其中的技能含量。

这不是词汇洁癖。它背后是一场关于“工程尊严”的争夺。

4.1 Sapir-Whorf 假说：语言塑造思维

语言学中有一个经典理论——Sapir-Whorf 假说——认为语言不仅仅是表达思想的工具，它还会反过来塑造思想本身。强版本（语言决定思维）虽然争议很大，但弱版本（语言影响思维）在认知科学中有大量实证支持。

当一个行业用“vibe”来命名一种生产方式时，它天然会引导出一种“轻视工程纪律”的氛围——随便搞搞、跟着感觉走、不需要太认真。而当你把它叫做“engineering”时，它天然会把测试、边界、复盘、可靠性这些概念重新拉回中心。

名称塑造文化。文化塑造行为。行为塑造结果。

4.2 两种归因，两种命运

Peter 的反对，本质上是在争夺定义权：

• 如果大家都把 AI 编程当作“随便玩玩”，那么失败就会被归因为“AI 不行”；
• 但如果它被承认为一种需要练习的技能，那么失败更可能被归因为“我还没练到位”。

前一种归因让人放弃，后一种归因让人进步。

Business Insider 还提到一个有意思的演变：提出“vibe coding”概念的 Andrej Karpathy 后来也在反思这个词，倾向用“agentic engineering”来描述未来方向。这个转变本身就在验证 Peter 的判断——当行业开始认真对待这件事时，它需要一个认真的名字。

五、核心洞见四：验证链替代阅读链

这是对谈里最容易被误解的一点。很多人听到“我不怎么读代码”会立刻联想到“危险”和“不负责任”。

但 Peter 讲得很清楚：他不是完全不看，而是从“逐行阅读”转向“看关键片段 + 看结构 + 看流式输出”。他知道组件在哪、系统如何设计，他只是承认“绝大多数代码我不读”。Business Insider 引用了他更直白的一句：“Most code is boring（大多数代码很无聊）。”

这里有两个被大多数人忽略的前提。

5.1 Popper 的可证伪性：阅读不是验证的唯一方式

科学哲学家 Karl Popper 提出过一个改变了整个科学方法论的观点：一个理论的价值不在于你能“证实”它，而在于你能“证伪”它。 你永远无法通过观察一万只白天鹅来证明“所有天鹅都是白的”，但你只需要找到一只黑天鹅就能推翻它。

把这个逻辑套到代码上：你永远无法通过“阅读代码”来证明代码是正确的——因为你可能漏看一行。但你可以通过设计足够好的测试来尝试“证伪”它——如果所有测试都没能让它失败，你就有合理的信心。

这正是 Peter 的工作方式的底层逻辑。他不是用“读代码”来建立信心，而是用“验证链”来建立信心：

• 自动化测试——单测、集成测试、回归测试
• 静态检查——lint、type check、规则扫描
• 运行时验证——在真实或仿真环境里跑
• 可观测性——日志、指标、追踪

Peter 在“Shipping at Inference-Speed”里有一个极具实操价值的建议：很多东西先从 CLI 开始，因为 CLI 容易让 agent 直接调用并验证输出，从而“闭环”。这句话把“可验证性”当作 agentic 开发的第一性原则——你不是先追 UI、先追交互，而是先追“让系统能自己验证自己”。

5.2 Polanyi 的默会知识：为什么他敢这样做

匈牙利裔英国哲学家 Michael Polanyi 提出过一个著名概念：默会知识（tacit knowledge）——“我们知道的比我们能说出来的多。”一个经验丰富的工程师对系统的理解，很多是结构性的、直觉性的、无法完全用语言表达的。

Peter 之所以能“少读代码也能推进”，一个关键前提是他对系统有足够深的默会知识——他知道架构是什么样的、组件之间怎么交互、哪些地方容易出问题。这种结构性理解不需要逐行阅读来维护，它是在反复与系统交互的过程中积累的。

他自己也承认：管理经验帮助很大。带团队就意味着你必须接受“别人写的代码不完全符合你的风格”，而现在模型写的代码本质上也是“别人写的代码”。

从“自己写”到“带团队”，你要升级的能力是“定义标准、做 code review、做架构决策、做验收”。从“带团队”到“带智能体”，你要再升级一次：把标准写成可执行的约束，把验收写成可自动化的测试，把 review 的注意力放在高杠杆处。

六、核心洞见五：一个人的公司级产能——Brooks 定律的逆转

Romain 引用了 Peter 的话：别人以为你背后有一整家公司，但其实“就我一个人在洞里写”。Peter 补充说：“即使一年前，这也不可能做到。”

这句话的震撼感，来自它精准击中了当下的结构性变化。

6.1 Brooks 定律：为什么大团队反而更慢

1975 年，IBM 的传奇工程师 Frederick Brooks 出版了《人月神话》（The Mythical Man-Month）。他提出了一条至今仍然成立的定律：向一个已经延期的软件项目增加人手，只会让它更加延期。

原因很简单：沟通成本。n 个人之间的沟通通道数量是 n(n-1)/2。3 个人有 3 条通道，10 个人有 45 条，50 个人有 1225 条。当团队规模增长时，花在“对齐信息”上的时间会吞噬掉增加人手带来的产出提升。

这就是为什么很多大公司的效率远不如小团队——不是人不努力，是沟通成本太高。

6.2 当 AI 替代的是“沟通通道”而不是“人”

Peter 的故事揭示了一种新的可能：AI 工具真正替代的不是“程序员”，而是“程序员之间的沟通通道”。

当一个人加上 AI 工具就能完成过去需要一个团队的工作时，Brooks 定律中的 n 被压缩到了 1。一个人和 AI 工具之间只有一条沟通通道——而且这条通道的带宽远高于人与人之间的沟通：没有情绪，没有政治，没有时区差，没有会议。

以前，一个“复杂系统”需要大量分工——前端、后端、测试、运维、产品、设计。现在，很多分工开始被工具自动化压缩，个人的能力边界被显著扩展。

但 Peter 自己也说得很清楚：OpenClaw 当然可能变成一家大公司，但那对他并不兴奋；他更想“改变世界”，加入 OpenAI 是把它带给更多人的最快方式。

“High agency”（高能动性）在这个语境下的真正含义不是“你一个人可以干所有事”，而是三件事：

1. 你可以用更少的人完成过去需要更多人的事。
2. 于是“主动性、驱动力、试错能力、复盘能力”会变得更值钱——因为这些能力不能被规模化，只能被个人修炼。
3. 你对“我是谁”的定义会决定你能不能抓住这波浪潮。

如果你的身份认同是“创造与解决问题”，这个时代对你更友好；如果你的身份认同是“按照既定流程写代码”，你会感到被挤压。

七、三层工作模型：把心态落地成操作

为了把上述洞见从“方法论”落地成“可操作”，我把 Peter 和 Romain 所表达的趋势抽象成三层工作模型。

第一层：意图与边界（Intent & Constraints）

你必须清晰回答四个问题：我到底要解决什么问题？什么算成功？什么算失败？约束是什么——安全、性能、成本、隐私、合规、时间？

这层工作不会消失，只会更重要。因为当“执行”变得便宜时，“错误执行”会变得更致命。

第二层：协作与引导（Steering）

过去你通过写代码引导系统。现在你通过三种方式引导：

• 对话——讨论方案、让它列选项、让它解释 trade-off。
• 结构化约束——文件结构、文档、规则、测试。
• 工具链——CLI 可验证闭环、web search、skills。

Peter 在“Just Talk To It”里反复强调：很多花哨的编排是 charade（表演），关键是“对话、玩、形成直觉”。

第三层：验证与治理（Verification & Governance）

当你减少逐行阅读，你就必须在别处补回来——测试覆盖、可观测性、代码与依赖治理、权限与密钥管理、安全隔离。

三层之间有一个微妙的平衡。 第一层越清晰，第二层越高效；第二层越成熟，第三层越可靠。反过来，第三层越薄弱，你就越不敢放手让第二层运转——你会陷入“不信任工具，于是不用工具，于是永远学不会用工具”的恶性循环。

八、现实的天花板：能行动的系统天然比只说话的系统危险

OpenClaw 是一个“可达性极强、主权感极强”的个人 agent 平台。但越是这种平台，越会把风险放大——它不是只生成文本的聊天机器人，而是一个拿着钥匙、能运行命令、能装技能、能长期记忆的系统。

Peter 自己在 OpenClaw 官方博客里把安全放在最优先位置，提到“安全相关提交”和“提示注入仍是行业未解难题”。但外部世界的反应更激烈也更现实。

8.1 三类核心风险

Microsoft 安全博客在“Running OpenClaw safely”里把风险说得非常工程化：

1. 凭据与数据泄露——agent 能访问你的密钥和文件，如果配置不当或被注入恶意指令，敏感信息可能被发到不该去的地方。
2. 持久状态被篡改——agent 的记忆是 Markdown 文件，一旦被篡改，它可能在后续所有交互中执行攻击者的指令。
3. 主机环境被攻陷——agent 能执行命令，如果被诱导运行恶意代码，你的整台机器都可能失控。

8.2 供应链风险

“技能（Skills）生态”引入了新时代特征的风险。Trend Micro 报道过“恶意技能”如何成为投递载荷的渠道，The Verge 也报道过 OpenClaw 技能扩展在供应链层面带来的安全隐患。NVD 中的 CVE-2026-25253 涉及特定版本中 WebSocket 连接可能导致令牌泄露的问题。

这一切在提醒我们：当你说“个人 agent 平台”时，你其实在说“一个新的操作系统层”。而操作系统层的风险治理，从来都不是靠一句“请小心使用”就能解决的。 它需要隔离环境、凭据轮换、权限最小化、供应链审计——这些不是可选项，是必选项。

九、30 天训练路线与 6 条工作准则

把 Peter 在节目与公开文章里强调的方法论，转化为一套可执行的练习系统。

第 1–7 天：练“把问题说清楚”的肌肉

选一个你一直想做但不影响 KPI 的小项目——CLI 工具、Telegram 机器人、自动化脚本，任选其一。

每天固定四个动作：

1. 用 5 句话写清楚“我要什么、不要什么、验收标准是什么”。
2. 让模型先给 2–3 个实现方案和 trade-off，你只做选择。
3. 让它实现最小可用版本。
4. 写下“它哪里误解了我”。

每天复盘 10 分钟，只问三个问题：我说的哪句话最含糊？哪个约束我忘了提？哪个验收标准我没定义？

第 8–14 天：练“验证链”

目标是把安全感从“读代码”迁移到“可验证”。

• 给项目加最基本的测试（哪怕只有 3 个）。
• 加 lint 和 type check，能自动化就自动化。
• 每天让模型做一次“自我 review”：列出潜在 bug 与边界条件。
• 重要改动要求它写到 docs 里，让知识沉淀为可复用上下文。

这个阶段你会理解 Peter 为什么强调 CLI——因为 CLI 的输出最容易被自动化检查，从而形成闭环。

第 15–21 天：练“二次迭代”

用“两次考试”的思路降低失败成本：

• 第一次迭代：只追“跑起来”，允许粗糙。
• 冷却 12–24 小时后回来，让模型回答三个问题：这个实现的核心不变量是什么？最可能出 bug 的边界在哪里？如果要让新人或另一个 agent 接手，应该补哪些文档和测试？
• 根据答案列出二次迭代清单，再让模型执行。

这套方法的本质是：把一次高成本的大翻车，拆成两次低成本的小失败。

第 22–30 天：练“产品化直觉”

开始思考“稳定性、权限、数据、可观测性”：

• 加入配置与密钥管理（别把 token 写死）。
• 加入日志与错误处理（让问题可定位）。
• 加入最小权限设计（尤其是“能行动的 agent”）。
• 参考 Microsoft 的三类风险分类，确保你至少有隔离环境、凭据轮换、监控与审计意识。

6 条工作准则

把以上一切收敛成可以贴在桌面上的 6 条：

1. 先玩，再上强度。 用小项目练手感，建立正反馈。
2. 先意图，后代码。 让模型给选项，你负责选择与约束。
3. 用验证链替代阅读链。 测试、检查、运行验证必须提前建。
4. 把上下文工程化。 docs、结构、规则，是 agent 的“道路”。
5. 把“vibe”换成“craft”。 承认这是技能，练习才会变强。
6. 对可行动系统保持敬畏。 能执行命令、装技能、持久记忆的 agent，要按高风险运行时治理。

结语：活着的好时代——但你要配得上它

Romain 在帖子里引用了 Peter 的一句话：

“If you’re a builder, what a time to be alive.”

这句感叹之所以打动人，是因为它既乐观也残酷。

乐观在于——个人第一次拥有了接近“公司级产能”的杠杆。一个人在洞里写代码，可以做出十万 star 的产品。

残酷在于——当杠杆变大，错误的代价也随之放大。你不再能用“我只是个工程师”来逃避系统性责任。

Peter 的故事——从 WhatsApp Relay 的周末玩具到 OpenClaw 的全球热潮，再到加入 OpenAI 同时坚持项目走向基金会——最值得学习的不是某个工具技巧，而是一种姿态：先做出东西，再把它迭代成能长期使用、能被更多人安全使用的形态。

用 Ericsson 的话说：这不是天赋，这是刻意练习。

用 Popper 的话说：这不是验证真理，这是不断尝试证伪。

用 Brooks 的话说：这不是加人手，这是压缩沟通通道。

而用 Peter 自己的话说——它比所有理论都朴素：

去玩。去做一个你一直想做的东西。然后练。