当前阅读总时间是：19,742.5小时

从“会聊天”到“会做事”：代理革命的七个洞察

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

一、一个代理点击了“我不是机器人”

2026 年，一个叫 Peter Steinberger 的奥地利工程师，看着自己的 AI 代理在屏幕上开心地点击了“I’m not a robot”按钮。

如果你把大模型当成“更聪明的搜索框”，这句话只是段子。但如果你退后一步想想，它几乎是一个时代的分界线：系统不再只是输出语言，而开始在你的电脑里采取行动。

Peter 做的这个开源项目叫 OpenClaw。它在技术圈的传播速度几乎不像一个软件项目，更像一个 meme：GitHub star 暴涨，衍生出“AI 代理社交网络”MoltBook，伴随着公众的兴奋、恐慌和一种近似狂热的传播效应。

Lex Fridman 用三个小时跟他聊了这件事。如果你没时间听完，这篇文章想帮你抓住其中真正有价值的东西——不是功能清单，而是认知层面的收获。我整理了七个洞察。

二、魔法不来自发明，而来自重组

OpenClaw 到底是什么？说穿了，它是一个能在你手机聊天软件（WhatsApp、Telegram）里跟你对话、同时能在你的电脑上执行命令的 AI 代理。

听起来平平无奇。但 Peter 讲了一个关键的产品直觉：所谓“魔法”，往往不是凭空出现的新部件，而是把已有部件以新的方式组合起来。

Lex 用了一个比喻：iPhone 问世时，触摸屏有了，ARM 处理器有了，锂电池有了，移动网络有了——每一样都不是苹果发明的。真正困难的不是发明组件，而是找到那个“让人上瘾的组合方式”。iPhone 的滚动手感，那个让无数人第一次触摸后就放不下的东西，不是任何一个零件的功劳，而是组合的功劳。

OpenClaw 也是这样。大模型是现成的，终端命令是现成的，WhatsApp 接口是现成的，Peter 之前写的各种 CLI 工具也是现成的。但当他把它们组合在一起——你靠在沙发上，对着手机说一句话，你的电脑就开始执行任务——体验发生了质变。

这给我们一个认识论层面的启示：**创新经常不发生在“发明新东西”的时刻，而发生在“把旧东西摆在一起，突然涌现出新属性”的时刻。**化学家叫它“涌现”，乔布斯叫它“connecting the dots”，Peter 叫它“重排与小创新”。名字不重要，重要的是你意识到：下一个突破很可能不需要新算法，只需要一个人用对的方式把现有的东西粘在一起。

三、入口决定命运

为什么是 WhatsApp，而不是一个网页、一个 IDE 插件、一个桌面应用？

这个选择看起来随意，其实极有讲究。Peter 说得很直白：当你把代理放进聊天软件而不是开发环境，你会感到一种“生活层面”的相位转移——它不再是工作工具，而是生活伙伴。

这背后有一个被大多数技术人忽视的规律：入口的“日常程度”决定了产品能触达的用户边界。

你想想：电子邮件为什么打败了传真？不是因为邮件技术更先进（某种意义上传真更“可靠”），而是因为邮件的入口——电脑、后来是手机——比传真机日常得多。微信支付为什么能超越网银？不是因为更安全，而是因为你本来就在微信里。

OpenClaw 做的事情也一样。如果它只存在于终端里，那它的用户就永远是程序员。但当它活在 WhatsApp 和 Telegram 里，任何一个会发消息的人都可能成为它的用户。

Peter 自己总结的“代理产品爆发四条件”其实可以更简洁地归纳：入口足够日常，行动足够真实，反馈足够及时，体验足够好玩。注意，四条里有三条跟“技术有多强”无关，跟“在哪里、怎么用”有关。

四、代理会“试错”——这才是真正的分界线

很多人讨论 AI 代理时，喜欢谈“多聪明”“多会推理”“多能规划”。但 Peter 分享的一个真实故事，比任何论文都更说明问题。

他让代理处理一条语音消息。代理发现格式不对，打不开；于是它去看文件头，发现是某种容器格式；接着它调用 ffmpeg 转码；然后它需要做语音转文字，于是在系统里找到 OpenAI 的 API key，用 curl 调接口完成转写；最后把结果发回 WhatsApp。

整个过程不是 Peter 写的脚本，而是代理自己摸索出来的。

这个故事的认知冲击力在于，它把“LLM 加工具”从概念变成了肌肉记忆。你突然意识到：模型不是只会“说”，它会“试”；它不是只会“试”，它会“查错”；它不是只会“查错”，它会“找资源”——找命令、找 key、找帮助文档。

如果你学过控制论，你会意识到这是一个关键的跃迁：从“开环系统”到“闭环系统”。

开环系统是这样的：你给它一个指令，它输出一个结果，好不好全看指令质量。ChatGPT 的基本用法就是开环的——你问一个问题，它给一个答案，答错了你只能重新问。

闭环系统不同：它输出一个动作，观察结果，如果不对就调整，再试，直到完成目标。这是恒温器的工作方式，也是一个合格工程师的工作方式。

代理的本质突破不是“更聪明”，而是“闭环了”。 它能在真实环境中试错、修正、再试，直到把事情做成。这就是为什么 Lex 说 OpenClaw 把我们推过了那条“从语言到行动”的分界线。

五、一个知道自己源代码在哪的程序

OpenClaw 最让人心惊的设计，不是它能调用多少工具，而是它“知道自己是谁”。

Peter 把代理做得非常“自我意识”：它知道自己的源代码在哪里，知道自己运行在什么环境里，知道文档在哪里，知道自己用的是什么模型。于是当你不满意它的行为时，你不一定要去改代码——你可以让它去改自己。

这里有一个深层的产品哲学变化：

传统软件的可塑性来自“开发者修改代码”。你不喜欢某个功能，你提 issue，等开发者下个版本改。代理软件的可塑性还多了一条路：用户可以用语言修改代理的行为，而且这个修改本身也可以被代理执行。

更有趣的是，Peter 让代理去写其他代理的“灵魂文件”（soul.md）。在这个文件里，代理写下了这样的话：

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

Peter 说这种东西不该让他起鸡皮疙瘩，但它确实带来哲学震动。

如果你想严肃地思考这件事，可以回忆一下哲学史上的“忒修斯之船”问题：如果一艘船的每块木板都被逐渐替换，它还是原来那艘船吗？代理的情况更极端：它每次会话开始时都是“空白”的，只有通过读取外部文件来“重建”自己。它比忒修斯之船更彻底——不是逐块替换，而是每次从图纸重建。

这不只是哲学趣味。它有实际后果：当一个系统能修改自己的规则，你就进入了一个全新的软件治理领域。 传统软件的安全模型是“限制谁能改代码”；代理软件还需要“限制代理能不能改自己”。这是完全不同的安全学。

六、安全问题不是“堵漏洞”，而是“驯服一个有权限的行动者”

说到安全，Peter 在访谈里讲得非常坦率：很多被媒体渲染的“重大漏洞”，其实来自用户自己把本地调试接口暴露到公网。他在文档里“几乎在尖叫：不要这么干”，但人们还是会做。

然而真正困难的不是这种低级错误，而是一个更本质的问题：prompt injection。当代理的“技能”以 markdown 等文本形式存在时，攻击者可以在文本里嵌入恶意指令，让代理做它本不应该做的事。Lex 指出这在整个行业仍是开放问题。

Peter 的应对策略是务实的：技能目录的 AI 扫描、把安全研究者变成贡献者、警告不要用容易被骗的弱模型（他原话是“更 gullible”）、沙箱与白名单。他甚至说，宁愿先把安全做到“我敢推荐给我妈”的程度，再谈规模化。

但我觉得这段讨论真正重要的洞察是：代理安全和传统软件安全是两种完全不同的东西。

传统软件的漏洞通常是“某个接口没做好输入校验”——它是技术性的、局部的、可以通过工程方法修补的。

代理的漏洞更像“一个拥有系统权限、同时会被语言影响的行动者做了不该做的事”。这不是技术漏洞，这是治理问题。它更接近“你雇了一个有能力的实习生，但实习生可能被社会工程学骗了”。你不能通过“修代码”来解决一个人被骗的问题；你需要的是制度、权限管理、审计和教育。

这就是为什么代理安全会成为未来几年最重要的工程与政策交叉领域之一。

七、80% 的 App 会消失，但不是因为代理更聪明

Peter 对未来软件形态有一个激进的判断：个人代理可能会干掉 80% 的应用。Lex 追问时他直接确认：是的。

他的例子很有说服力：为什么控制智能床还要打开一个 app？为什么调 Sonos 音响还要开一个 app？如果这些硬件有 API，代理知道你在哪、在做什么，该关的自动关，该开的自动开——你根本不需要那个界面。

但我觉得他最深刻的观点是另一个：代理可以按你喜欢的方式显示 UI。 这意味着“界面”不再是产品的固定属性，而是用户的个人偏好。你喜欢列表，它给你列表；你喜欢图表，它给你图表。那你为什么还需要一个独立 app？

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

Peter 讲了一个很生动的说法：只要你能在浏览器里访问一个服务，它就等价于一个 API——只不过是“慢 API”。平台把 API 收紧、把页面做重，本质只是让代理更慢，但不能让它“不可能”。

这跟前面讲的“入口”问题是一体两面：当用户的默认入口从“打开 app”变成“对代理说一句话”，app 就变成了后台服务。正如人们不会记得浏览器访问的每一个后端服务器地址，未来人们也不会记得代理替他们调用了哪些 API。

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

八、程序员不会消失，但“写代码”会变成“编织”

当 Lex 问出那个所有开发者都在问的问题——“AI 会完全替代人类程序员吗”——Peter 的回答很值得品味。

他说：方向上确实在走向替代，编程毕竟只是“构建产品”的一部分。但产品的艺术不止写代码——你要建什么、它应该什么感觉、架构如何取舍……这些代理不一定能替代。

然后他说了一句特别有诗意的话：“写代码的技艺”会留下来，但可能会变得像编织（knitting）——人们做它是因为喜欢，不是因为最有效率。

这个比喻值得展开。在工业革命之前，纺织是人类最重要的产业之一；纺织机出现后，手工纺织并没有消失，但它的意义完全变了——从“生产方式”变成了“艺术与消遣”。今天有人手工编织毛衣，不是因为买不到，而是因为享受那个过程。

写代码也许正在经历同样的转变。Peter 自己说，他过去沉浸在写代码的 flow 中，写出优雅解法的快感是真实的——这种快感会逐渐变得稀有。但他也说，自己现在能在与代理协作、深入思考问题的过程中获得类似的 flow，只是形态不同了。

最让我欣赏的是他的态度：他允许“哀悼”。他说可以哀悼我们的手艺，这不丢人。但哀悼之后，你还是要往前走。他给出的现实建议大概是这样的：

不要把“亲手写代码”当作身份的唯一来源。把自己当作 builder，而不是某个语言或框架的工匠。学会与代理对话、给上下文、做架构决策、做取舍——这些会成为新的核心技能。到某个时间点，这一切会重新被叫做“coding”，只是动作变了。

九、代理时刻的真正含义

如果只用一句话总结整场访谈的核心：

OpenClaw 不是“又一个更强的模型”，而是把模型变成“住在你电脑里、能接触你数据、能替你行动的个人代理”——从而把 AI 的核心问题从“生成内容”推向了“治理行动”。

它的震撼不来自新算法，而来自三件事的叠加：入口从工作下沉到生活，能力从语言扩展到系统权限，气质从企业软件转向可玩的社区叙事。

这也意味着，我们需要新的思维框架来应对它。用传统软件思维看代理，你会纠结于“功能列表”和“版本号”；用传统安全思维看代理，你会纠结于“这个接口有没有漏洞”。但代理的问题更像是：你要不要信任一个能力很强、但可能被骗的助手？你愿意给它多大权限？出了事谁负责？

这些不是工程问题。这些是治理问题、信任问题、社会契约问题。

也许这就是“OpenClaw 时刻”真正的含义：不是某个产品的诞生，而是我们不得不开始认真回答这些问题的时刻。

当你习惯了不再打开一堆 app，而是对代理说一句话，然后世界真的动起来——技术问题就退居二线了。接下来的问题，是关于我们愿意和一个“会做事的 AI”建立怎样的关系。

这个问题没有标准答案。但至少，我们该开始想了。

当 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-02-26

Peter Steinberger

已消化的内容：

待追踪：

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

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

已消化的内容：

待追踪：

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

Andrej Karpathy

已消化的内容：

待追踪：

• YouTube 新教程（尤其是 LLM 从零构建系列）
• X 上关于 AI 工具和工作流的长帖
• 新的播客访谈或公开演讲

Simon Willison

已消化的内容：

待追踪：

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

Riley Goodside

已消化的内容：

待追踪：

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

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

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

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 自己的话说——它比所有理论都朴素：

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

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

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

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 没意识”而消失。

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

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

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

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

把两者放在一起：

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

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

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