编辑 | 云昭
“超级个性化助手，是反OKR的！”
13 年创业，3 年“燃尽”，去年 5 月开始萌生造 Clawdbot 的想法，一开始担心大厂会很快做出来，结果大厂却迟迟没动作，最后自己忍不住下场了。
近期伴随着 Clawdbot 的爆红，创建者 Peter Steinberger，忙到严重睡眠不足，一边忙着给它换个新名字 Moltbot，一边接受了不少播客的邀请。
昨天晚上，知名技术播客《The Pragmatic Engineer》跟 Peter 来了一场 114 分钟的对谈。
而开头提到的“Clawdbot诞生的故事”，相信不少朋友已经听过了。这里小编就不再赘述了。
播客下半场，才是这场对谈的重点。可以说，所有的反行业共识的东西全在这里了。
首先，作为一个现象级 AI 产品的 solo 开发者，Peter 非常不喜欢“Vibe Coding”这个词，他更倾向于：Agentic Engineering。
Peter 表示，他同样不太喜欢“程序员”在AI Coding时代的新定位的称呼：“架构师”，他甚至觉得“传统的规划好 Spec 文档，然后交给 Agent 去自动执行就完事了”，这种想法是行不通的。
他甚至毫不留情面地痛斥了AI圈内非常常见的“编排、拆解”的做法，本质上仍然是瀑布式开发，这样只会带来一场“精致的混乱”。
他们可能花几个小时设计 spec，然后机器用一天把东西“造”出来。我不信这套能行。这本质上还是瀑布式软件开发，我们早就知道它行不通。
其次，Peter 认为，自己高效使用 Coding Agent 的关键，还是在于构建好验证闭环。之所以 AI 在写代码上表现很好，但在写作上常常平平，是因为代码可以被验证：可以编译、跑测试、检查输出。
另一个反直觉的是，Peter 表示自己并不认为大公司能用好 AI，除非它们来一次彻底的重构。
新世界需要的是那种有完整产品视角、什么都能干的人，而且数量要少得多，但必须具备极高的自主性和能力。但公司的职务分工则太细分了，工程师和产品经理的角色划分清晰，根本不存在这样复合的岗位。
另一点让人印象深刻的是，Peter 提到，AI时代代码的 PR 本身价值也在缩水，prompt 反而才是更高信号量的东西，并要求大家提交代码时一定要要附带上prompt。
“当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。”
而对于如何写 prompt ，Peter 表示，这并不是提前精心预备好的，而是跟 Agent 之间的协作规划出来的。
“我通常从一个想法开始，甚至会刻意‘欠提示’Agent，让它做点出乎意料的事，给我新想法。”
主持人还担心：这样的工作方式，是否能进入“心流”状态？Peter 给出了更加肯定的答案，并表示，同时调度多个 AI agent，在心理上比单纯写代码更累。
总之，在开发打磨 Clawdbot 这件事情上，Peter 已经不太关注如何写代码这件事，他更在意结果和产品体验。
除此之外，Peter 还点评了 Claude Code 和 Codex，并表示现阶段他已经从 CC 切换到了 Codex，虽然 CC 一度让他上头了很长时间。
当然，他还透露了几个关于 Clawdbot 的设计细节，比如：关于 token消耗方面，本质就是用 TS 在搬运 json。再比如他是如何让 Clawdbot 孵化出一个个性鲜明的私人 Agent 的，初始点是一个名为“bootstrap”的文件，等等。
另外，Peter 给AI原生世代新人的建议只有一条：请保持无限的好奇心。
当一个经历过完整创业周期、真正带过团队、对工程质量极度敏感的人，开始把“写代码”这件事，大规模交给 agent，会发生什么哪些化学反应和二阶变化？
未来，如何利用 Agent 来开发 AI 产品？开发者、创业这又该有怎样的 taste 和 sense 呢？
小编为大家节选了后面70多分钟的精彩观点，一起来看下这位“3年燃尽”的创业者如何在 AI 时代的“非共识思考”。
Peter自己的工作流：以前对CC上头，现在是Codex
主持人：
那我们直接跳到现在。你现在的工作流是怎样的？做 Clawdbot 的时候，你用一个终端还是多个？用哪些工具？你虽然不怎么 review 代码，但依然在思考架构。如果要跟一个即将加入团队的开发者解释，你的一天大概长什么样？
Peter：
挺有意思的。我们倒回到四月，一开始是 Claude Code，然后我彻底上瘾了。后来有一阵子我用 Cursor，又试了试 Gemini 2.5。再后来是 Opus 4。我还把一堆朋友都拉下水了，比如 Vinner 的 Armen 和 Mario。他们都“嗑了 AI 药”，因为我实在太上头了。我不停给他们演示，他们一试就停不下来，最后大家都凌晨五点还醒着，我把这叫“黑眼圈俱乐部”。
我在伦敦还搞了个聚会，叫 Claude Code Anonymous，说真的，这东西有点像毒品，因为太好玩了。真正震撼我的是一个意识转变：现在我几乎什么都能做出来了。以前你得非常谨慎地选副项目，因为软件真的很难。现在当然还是难，但那种摩擦感不一样了。我会想，我在这类技术上很强，在那类技术上很弱，比如“那我们用 Go 写个 CLI 吧”，我对 Go 一无所知，但我有系统层面的理解。一旦你有这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是别扭的，这本身就是一项技能。
我记得有人发过一条推，说写代码时你能感受到摩擦，这正是好架构诞生的方式。我在 prompt 的时候也有同样的摩擦感。我能看到代码飞过去，能感知花了多长时间，能感觉 agent 有没有在“顶你”，能看出来生成的东西是杂乱的还是有结构的。
很多时候我一开始就能判断大概会花多久，如果明显更久，我就知道自己哪儿搞砸了。你会慢慢“感知”这个模型，知道它通常会怎么跑。这更像一种共生关系，我学会了如何跟它说话，甚至可以说是一门语言；与此同时，模型也在变得更好。
从四月到现在，我觉得真正的拐点是在夏天，那时它已经强到可以在几乎不手写代码的情况下完成软件构建。真正让我彻底买单的，是 GPT-5.2，我觉得它被严重低估了。我不太理解为什么还有那么多人只用 Claude Code。当然我能理解，那是一种不同的工作方式，但 OpenAI 现在“端出来”的东西实在太猛了。我现在几乎每一个 prompt 都能拿到我想要的结果，这很夸张。
Peter：
在 Clawdbot 这个最新产品上，我通常会同时跑 5 到 10 个 agent。如果你是典型的 Claude Code 流派，你得忘掉很多为了“哄”它而做的那些花活。我也见过 Claude Code 的团队，他们真的创造了一个全新的品类，这是个定义品类的产品，在通用计算和写代码上都很强，我现在几乎每天还在用。但在复杂应用里写代码，Codex 明显更好，它会花十倍的时间去理解上下文。Claude 可能读三份文件就自信地开始写代码，然后你得不断拉它回来，让它多读一些，才能真正理解整个代码库。Codex 则会安静地读十分钟文件。如果你只用一个终端，这体验确实让人受不了，但我更愿意要这种方式。
还有一点很多人没意识到：你并不是在“指挥”它，而是在对话。我会说，我们看看这个结构，有哪些选项？这个特性考虑过没有？因为每一轮 session，模型一开始对你的产品是零认知的，你得给它一些指路标志，让它去探索不同方向。你并不需要什么 plan mode，我就是一直聊天，直到我说“build”，它才会真的开始构建。有一些触发词，它们确实都挺“饥渴”的，但只要我说“我们讨论一下”或者“给我一些选项”，它们就不会动手。
更多是和Agent一起协作规划
主持人：
听起来，你很多 prompt 其实是在和 agent 一起做规划。
Peter：
对。比如我会提醒它，我们还需要文档，放在哪比较合适？它会给建议，我再说，这块应该单独成页。需不需要配置？这和另一个功能怎么衔接？我在做的是系统设计，因为我对整体结构和形态有理解，但并不掌握逐行代码，那部分是 Codex 在帮我做，我负责架构。
用AI特别顺的人，并不在意内部管道的细节
主持人：
这听起来有点像很多年前流行过的一种模式：有一个“大写 A 的架构师”，不再亲手写代码，负责蓝图，然后把方案往下传。后来大家都讨厌这种模式，转向 staff engineer，一起干活。但现在好像变成了你是架构者，下面是 agent 写代码，而且责任仍然完全在你身上。
Peter：
我不太用“架构师”这个词，我更喜欢“builder”。我发现用 AI 特别顺的人和特别痛苦的人，差异很明显。我更在意结果和产品体验，底层管道我关心结构，但不纠结到最小细节。另一类人特别热爱写难算法，喜欢解决纯技术难题，不太喜欢做完整产品、营销这些事情，这类人往往最抗拒 AI，也最容易沮丧，因为 AI 恰恰擅长解决那些“难问题”。
这一年里，我学到的系统架构和设计知识，比过去五年加起来都多。这些模型里塞进了巨量知识，几乎任何问题都能问到答案，前提是你得知道该问什么。
Peter：
我当然也做过那个 Twitter 项目，到现在还没完工，我也真心希望哪天能回去把它收掉。整体功能其实是能跑的，但一旦用得稍微频繁一点，就会开始变得又卡又怪，然后过一阵子又恢复正常。我怎么都复现不了问题，调试起来特别痛苦，因为它不是那种稳定可重现的 bug，只是“用着用着就慢了”。
当时我在 Postgres 里写了一些逻辑，某些 insert 发生时会触发一些行为，结果数据库就会变得非常忙，而模型根本看不到这一层，因为抽象隔得太远了。模型很擅长顺着逻辑链条追溯，但这是一个非常隐蔽的副作用，只藏在一个文件里的某个函数里，跟其他地方几乎没有关联，名字也起得很糟，完全不显眼。我一直没问到那个“对的问题”，直到有一天我突然问：这个地方有没有任何副作用？结果一下就找到了，然后修掉了。说到底，一切都只差一个正确的问题。但前提是你得有足够的知识、经验，知道该往哪个方向问。
所以你会看到，一类人会拒绝 AI，而另一类人并不那么在意内部管道是怎么接的，只是单纯对“把东西做出来”这件事感到兴奋，这些人往往进展得很好。还有一件事对我帮助很大：当你真正经营过一家公司、带过团队，你就知道你不可能盯着每个人的代码，要求他们每一行都按你的方式来。很多没带过团队的人，很难学会放松一点，理解“这段代码也许不是我理想中的样子，但它能把我往目标方向推进”。不完美的地方，之后总能继续打磨。我非常相信迭代式改进。在公司里，我也是慢慢学会放手的。
所以后来用 Claude Code 的时候，那种感觉就很像：我手底下有一群工程师，有时候不太完美，偶尔还会有点蠢，但有时候又非常聪明，我需要引导他们，和他们一起奔着同一个目标前进。这种感觉，真的很像重新当了一次老板。
Vibe Coding不太合适
应该叫 Agentic engineering
主持人：
你在 AI 之前，用传统方式写软件、带团队，已经有十五年以上经验了，也一直对工程质量和标准要求很高。现在你和 agent 一起工作了一年，回头看这两种方式，哪些地方变化最大？哪些东西其实没变？
Peter：
首先，我不太喜欢“vibe coding”这个说法。
主持人：
那我们该怎么叫它？
Peter：
我一般跟别人说，我做的是“agentic engineering”，带个小星号。真正的 vibe coding 是凌晨三点开始的那种。现在写代码这些重复性的事情基本都被自动化掉了，我的速度快了很多。但与此同时，我要“唱的歌”也多得多。我依然能进入那种 flow 状态，那种感觉和以前非常像，但在心理层面上其实更累了。因为我不再是管一个人，而是同时在管五个、十个，它们各自都在干不同的事情。我在脑子里不停切换，从这个子系统跳到那个功能，又跳到另一个地方。
通常是这样：我在设计一个新子系统或新功能，我知道 Codex 大概需要 40 分钟到 1 小时才能把它跑出来，那我就先把方案想清楚，交给它去“煮”，然后我转身去干别的。这个在煮，那个也在煮，过一会儿我再回来看其中一个。我的大脑一直在来回切换。我其实不太喜欢这样，我也相信这只是一个过渡阶段，未来模型和系统足够快之后，我就不用这么并行轰炸了。但现在，如果我想保持 flow，就必须高度并行。
所以我的工作方式就是不停来回切。有时候稍微 tweak 一下，很多时候直接试一把。可能这个二十分钟就好了。通常会有一个主项目占据我的注意力，旁边还有几个“卫星项目”，需要偶尔看一眼，可能花五分钟下个指令，它自己跑半小时，对我脑力消耗不大。
高效使用Agent的关键：建好反馈闭环
主持人：
这听起来让我想到两种画面：一种是那种要同时管好几个灶台的做饭游戏，菜一道道出来，你得不停跳着处理；另一种是下星际，有主基地，也有分基地，不断给你输送资源。还有点像国际象棋大师同时下二十盘棋，他们走到一盘前，看一眼局面，做个决策，遇到强对手就多停一会儿。
Peter：
对，感觉很像。你的大脑一直是满负荷的，你在“扩展自己”，前提是你还能承受这种上下文切换。区别在于，以前用 Claude Code 时，你得用一种不太一样的方式工作。它确实更快，但生成的东西往往第一次跑不通，可能忘了同步改另外三处，要么直接 crash。
高效使用 coding agent 的关键，其实就一句话：你得把反馈闭环建好。它必须能自己测试、自己 debug，这是最大的秘密。这也是为什么后来效率提升这么明显。用 Claude Code 的时候，我经常要回头修修补补，或者来回跑很多轮，算下来其实也没快多少，只是更“互动”而已。
现在用 Codex，绝大多数时候它一次就对了。我的基本策略一直是：做一个功能，就一定让它写测试，并且确保测试真的跑了。就算我在写 macOS 应用也是一样。比如昨天我在 debug 一个问题：Mac App 找不到远端 gateway，但同样的 TypeScript 代码却可以。Mac 应用调试特别烦，要 build、启动、点界面、看效果，再告诉它不行。
现在我就直接说：你给我建一个 CLI，专门用来 debug，走完全一样的代码路径，我可以自己调用。然后它就开始跑，一个小时后搞定，告诉我这里有 race condition，那里有配置问题之类的。听起来很合理，我也不需要真的去看那些代码。
你之所以可以不看，是因为你已经把验证闭环搭好了，你相信它，因为测试跑过了。这其实和在大公司里做项目很像：所有测试都绿了，当然不代表百分之百没问题，但已经是一个很强的信号了，尤其是新代码也配了测试，说明有人认真想过、验证过。
即便在我最新的项目里，bug 也还是有，比如 anti-gravity 在 tool call 的循环格式上有一些奇怪的行为，需要做过滤，这一块之前炸过好几次。我花了太久才反应过来：我在干嘛？这事就该自动化。于是我直接跟 Codex 说，设计一组集成测试：起一个 Docker 容器，装好整套系统，跑一个 loop，用指定文件里的 API key，让模型读一张图片、生成一张图片，再回头看自己生成的图像理解成了什么。我不只是告诉它“跑循环”，还明确了 tool calling 的方式，让它自己把事情跑通。结果它真的就自己解决了。
这件事花了很久，但它把我所有的 API key 都测了一遍，从 Anthropic、OpenAI、GLM，到能测的全测了，也顺手修掉了那些很小但很烦人的问题，比如有时候 tool calling 不生效，或者调用顺序错乱。关键就在于我把验证闭环关上了。
主持人：
你说的“关上闭环”，指的是给 agent 一种方式，让它能验证自己做的事情？
Peter：
对，这正是现在这些模型为什么在写代码这件事上这么强的原因。但在创意写作上，它们的表现往往只是中等，因为创意很难验证。代码不一样，我可以编译、lint、执行、验证输出，只要你把系统设计好，就能形成一个非常完美的反馈回路。
哪怕是现在，我在做网站时，也会把核心逻辑设计成可以通过 CLI 跑起来，因为浏览器里的反馈循环实在太慢了，你需要一个能高速迭代的 loop。
软件的本质没变，Test First
主持人：
听起来，有一件事其实和以前没怎么变：像后端、业务逻辑这种东西，本来就更容易验证正确性。反而是 agentic coding 逼着你把架构想得更清楚、更可验证，而“可验证”本身就是把事情做好的一条核心路径。
Peter：
是的。其实在 AI 之前也是一样。做复杂系统时，只要找一个真正做过这类系统的人，他第一件事一定是想：我们要怎么让它可测试？接口怎么设计、类怎么拆、要不要 mock、要不要做端到端测试，这些都是非常困难、而且一旦决定就很难回头的架构选择。
现在这些取舍依然存在。让模型做一次大规模重构，它还是会“煮”很久；有测试，它大概率能做对，但代价依然在。软件本质上没变。
我甚至觉得，现在我不再亲手写代码了，反而写出了更好的代码。我以前就写得不错，但在公司里，测试这件事真的太折磨人了，各种边界条件、分支逻辑，除了我非常尊敬的 Kent Beck——他来过播客，坚持 test-first——我几乎不认识真正喜欢写测试的开发者，包括我自己。我从来不喜欢写测试，就算假装喜欢，其实也没有。
备注：Kent Beck，测试驱动开发（TDD）的奠基者之一。
文档和测试对我来说，一直都不是一种“创作表达”。但现在情况完全不一样了。我可以说，在我最近的项目里，文档质量是我做过最好的，而我一行都没亲手写。我不写测试，也不写文档，我只跟模型解释取舍：为什么要这么做。然后告诉它，写一段对新手友好的引言，后面再逐步加深技术细节，结果非常好。
现在每当我设计一个功能，文档和测试都会自动成为流程的一部分。比如我们刚做完一个东西，我会立刻想：我们要怎么测试它？如果换一种实现方式，是不是更好测？于是“怎么关上闭环”已经成了我思考的一部分。模型必须能验证自己的工作，这件事会自然把我推向更好的架构。
从人肉Merge按钮，到擅长与“小野兽”对话
主持人：
那你怎么看现在有不少经验很深的开发者，依然对“AI 能做这么多事情”这件事持强烈怀疑态度？
Peter：
一周前我正好看到一篇博客，是 Nala Coco 写的，我非常尊敬他，也从他那里学到很多。但那篇文章基本是在否定当前模型的工作方式。他测试了五六个模型，其中还包括一些根本不适合写代码的，比如 OpenAI 那个 120B 的开源模型。
在我看来，他就是写了一个 prompt，丢进 Claude Web，点了发送，把输出直接跑了一下，发现编译不过，于是很失望。但这太正常了，你真以为人类第一次写代码就能零 bug 吗？这些模型本质上是人类集体知识的幽灵，它们的工作方式和我们非常像。第一次出错很正常，所以你才需要反馈闭环。
而且你不是“发一个 prompt”就完事了，你是在开启一段对话：我想做什么。比如他抱怨模型用了旧 API，那是因为他没说 macOS 的版本，模型自然会假设用旧接口。它的训练数据不只是最近两年，旧数据远比新数据多。你越理解这些“小野兽”的思维方式，就越擅长 prompt。
他可能玩了一天左右，就下结论说这项技术还不够好。但要真正用好，你得投入更多时间。这就像你会弹吉他，我把你放到钢琴前，你随便试两下，说“这玩意不行，我还是回去弹吉他”。不对，这是完全不同的构建方式、不同的思考方式。
你不知道我有多少次在凌晨三点对着 Claude Code 吼，因为它干了蠢事。慢慢地，我开始理解：它为什么会严格按照我说的话去做，有时候甚至可以直接问它。去年在 Clawdbot 这个项目里，我感觉自己成了一个“人肉 merge 按钮”，社区太活跃了，我每天都在 review PR，几乎没时间写代码。一开始我会 cherry-pick 一点就关 PR，气得不行。后来我问它：你为什么这么做？它会说：当你这样说的时候，我是这样理解的。那一刻我意识到，我在学机器的语言。
我不断调整 prompt，现在几乎每次都能得到我想要的结果，因为这本身就是一项技能。
AI圈太多人只是在整花活
复杂的编排层本质上还是瀑布式开发
主持人：
Simon Willison 也一直在说类似的话。很多人真正开始用之后，都会意识到：我还行，但还能更好。那我们来个更现实的假设吧。
现在你在做 Clawdbot，它用户很多、增长很快，是个很酷的产品，但它不是 PSPDFKit——那个是真正有大量收入压在上面的业务。如果今天 PSPDFKit 从世界上消失了，你要重新做一遍，现在有这些 agent，你会怎么做？你会信任它们到什么程度？什么交给它们，什么必须自己验证？团队结构会和当年有什么不同？
Peter：
我可以用原来 30% 的人手把公司跑起来。当然，前提是你能找到足够资深的人。这些工程师必须真正理解自己在做什么，同时也要敢于、也愿意去委托，把精力放在真正重要的部分，其他地方可以“vibe”一下。
但老实说，这种人我现在并不常见。尤其是在 AI 圈子里，Twitter 上充斥着大量噪音，很多人声音很大，但明显不知道自己在干嘛。各种奇怪的概念层出不穷，比如那个 Ralph Wiggum 流派（小编注：用天真小孩的方式测试复杂系统，却用成年人的标准下结论），在我看来就是围绕 Opus 的局限搞出来的一堆花活，用 Codex 根本不需要。
也许在极少数场景下，你有一长串完全独立、可以自动化的小任务，但那通常并不是软件开发真正的样子。
Peter：
我看到很多人会先搭一整套复杂的编排层：什么自动建工单、Agent 处理工单、Agent 再给另一个 Agent 发邮件，最后堆出一坨精致的混乱。图什么？他们可能花几个小时设计 spec，然后机器用一天把东西“造”出来。我不信这套能行。这本质上还是瀑布式软件开发，我们早就知道它行不通。也许对少数人有效，但对我不行。
我通常从一个想法开始，甚至会刻意“欠提示”Agent，让它做点出乎意料的事，给我新想法。可能 80% 的结果都不怎么样，但总会有一两个点让我意识到“这个角度我没想过”。然后我不断迭代、塑形。我得点、得摸、得感受。好软件需要“品味”，而这恰恰是很多流程里缺的。现在的好处是功能太容易生成了，不行就扔，或者重提示。我的构建方式基本一路向前，很少回滚，更像雕塑：从一块石头开始，不断凿，慢慢一尊雕像从大理石里浮现出来。这就是我对“构建”的理解。回头看软件工程的变化，这确实是一种转变。
规划的重要性在降低：
很多好的规划其实是在过程中产生的
主持人：
这也影响了规划方式吧？在没有 AI、Agent 之前，前期规划很重要。你们以前在 PSPDF 很强调前置方案，因为开发成本高。现在写代码的成本在下降，这件事变了吗？
Peter：
我还是会规划，但投入没那么重了。现在更容易直接试、看结果，再判断这个“形状”行不行，不行就微调，甚至推倒重来，成本低太多了，过程变得更有玩味。以前交给新人或实习生，一个任务要一两天；现在是分钟级，重一点也就十几二十分钟，而且还能并行跑。就算“浪费”，也没那么浪费。
在 Clawdbot 一开始，我假设是单 Agent，后来变成多 Agent；最初只接一个渠道（比如 WhatsApp），后来变成多个。如果我自己写，这种改动会非常痛苦，要把逻辑从头到尾重织一遍。但 Codex 花了三个小时，我自己大概要两周。这让我意识到，很多前期规划其实可以在过程中“发现”。你会一边做，一边加深技术深度，也在进化你对项目的理解。
所以我不太信那种“先写好 spec，然后自动生成，完事”的方式。没做过，你怎么知道自己想要什么？构建的过程会反过来塑造你的想法。这是一个循环，就像爬山，不是直线上去，而是绕着走，偶尔偏离，但最终能到顶。
超级个性化助手，是反OKR的
主持人：
那你连续做 Clawdbot 有多久了？两三个月？
Peter：
换个话题说说动机吧。四五月的时候，有个想法把我拉了回来：我想要一个“超个性化”的助手，不是那种早上给你发邮件、列三件待办的，而是真正理解我的。
比如我见了朋友，回家后它会问我“刚才那次见面感觉如何？”；或者提醒我“你三周没联系 Thomas 了，我注意到他现在在城里，要不要打个招呼？”；甚至问我“你每次见到某个人都会情绪低落，这是为什么？”——非常私人的那种，几乎是反 OKR 的。像电影《Her》，而且我确信技术会走到那一步。模型越能看到更大的上下文，就越能识别模式。即便它们只是矩阵计算，没有灵魂，体验上却常常不一样。
我当时甚至为这个想法注册过一家公司，叫 Amantus Machina，意为“有爱的机器”。但去年夏天试的时候，模型还差一点，结果在边缘徘徊，不过这反而让我兴奋，因为 AI 进步太快了，晚点再回来就行。
同时我也判断，大公司一定都会做个人助手：每个人都会有一个“机器朋友”，了解你的一切，能主动做事，吃算力，但付得起的人都会有。之后会逐步下沉，这是必然方向。现在算力还不够，产品也难做。
我一直想要的是一个跑在自己电脑上的助手，数据是我的。把邮箱、日历、约会软件全交出去，其实挺吓人的。但现实是，很多朋友已经把这些工具当成“心理咨询师”，而且效果很好。哪怕只是反思本身就有帮助，更别说现在它还能问出很有洞察力的问题。
所以“超个性化助手”这个念头一直在。过去几个月我终于开始真正把它做出来。
Clawdbot最初的两个名字背后
Peter：
一开始范围很小，甚至只是个 WhatsApp Relay（中继器、转发器），用来通过 WhatsApp 触发我电脑上的事情。后来我去摩洛哥给朋友过生日，白天在外面，全程用 WhatsApp 和我的 Agent 对话：它带我逛城市、开玩笑、还能替我给朋友发消息。我就这么被“勾住”了。
我记得当时被彻底震到了。一开始技术其实挺糙的，但我做了个功能，可以给它发一张图片，甚至都没用正规的图片传输方式，只是把文件当成一个字符串丢过去，让它用 read 工具读。我人在摩洛哥，看不清楚，就发了条语音，说了一下情况。
三十秒后它直接回了我那条语音。我当时就懵了：“你他妈是怎么做到的？”它说，你给我发了个文件，我看 header 发现是 OGG，于是用 FFmpeg 转了一下，然后在你电脑上找 Whisper，没装，但我找到了 OpenAI key，就 curl 到 OpenAI 服务器让它转写。我当场“我靠”。这是 Opus 4.5，资源调度能力强得离谱。别人会说要技能、要系统，它直接自己想办法搞定。我就这样慢慢被它勾住了。
我还拿它当闹钟用：它跑在伦敦的 Mac Studio 上，通过 SSH 连到我在摩洛哥的 MacBook，打开音乐，一直调大音量，因为我没回复。为了这个我还加了个 heartbeat。从安全角度看这简直疯了：你每隔几分钟就给模型发一个“做点酷的、给我点惊喜”的提示，让它主动扫任务列表——史上最贵的闹钟。但真的太好笑了。它发的那些消息也很离谱：我那天状态很差，它知道我得很早起，我没回，它的推理里是“Peter 没反应，但 Peter 得起床。不行不行不行，不能睡。”就一直骂我。我给一起旅行的朋友看，所有人都上头了，感觉像魔法，我自己也是。
后来我发到 Twitter，结果反应很冷，基本没人懂。我感觉这算是一个新产品类别，有点像当年你第一次用 iPhone，光看广告完全理解不了，非得上手。我真正认真做它其实也就最近两个月。名字从 WhatsRelay 改了：有次 Claude 跟我说，这名字已经不符合功能集了，我就先叫它 Claudius——因为我喜欢《神秘博士》的内部梗。后来觉得 Clawdbot 更好，域名也合适，更能说明产品，就全改了。
用CLI，而不是MCP：
MCP 没法规模化
Peter：
同时我也在悄悄“扩军”。为了让这套东西成立，我希望一切都是 CLI，所以我给所有东西都做了 CLI：Google、床、灯、音乐。为什么用 CLI，不用 MCP？我怎么看 MCP？说实话，MCP 最大的贡献是逼着公司把 API 打开了，但这个概念本身挺蠢的。你得在会话一开始就把所有工具的所有函数和说明全塞进上下文，模型再发一坨精确 JSON，换回一坨 JSON。问题是，模型其实特别擅长用 bash。
想象一下更好的服务：模型先问“有哪些城市”，返回 500 个城市，但 MCP 机制下它没法过滤；接着你说“给我伦敦的天气”，返回温度、风、雨、以及一堆我根本不关心的字段，模型被迫吞下所有垃圾上下文。CLI 就不一样，它可以直接用 jq（备注：一种 JSON 过滤工具）过滤，只拿需要的。
MCP 把一切都常驻在上下文里，这是个问题。也许如果 MCP 不进上下文、而是能被发现和选择，会好一些——这正是公司们在做的事。但还有个问题：我没法链式调用，没法写脚本，比如“一条命令拿到所有 25 度以上的城市，再筛选、再打包”。MCP 调用是孤立的，没法脚本化。
当然，这大概只是时间问题。就像现在写天气 App，你也会先找 API、比价格、覆盖面，再选一个，然后自己去链 API。我们已经解决过这个问题了，AI 时代也会，只是需要时间，格式也未必是现在这样。我甚至自己写了个小工具 make-porter，用 TypeScript 把 MCP 转成 CLI，直接打包用。结论很简单：现在 CLI 效率更高。
在 Clawdbot 里我没原生支持 MCP，但通过 make-porter 你可以用任何 MCP。你甚至在手机上说一句“用 Vercel 的 MCP 干这件事”，它会自己找、加载、按需使用。现在用 MCP 还得重启 Claude Code，体验很差。
疯狂扩建军队中：
已跑通视觉版Agent，通话功能已可用
Peter：
所以我就一直悄悄把“军队”建起来，把一切都自动化，工作量巨大。前几天有人做了个视频，说我这人疯了——列表已经长得离谱。但我一边玩 Agent，一边就想让它干更多事。
这东西很难描述清楚，到现在对我都不容易。今年 1 月 1 号，我干了件更疯的事：建了个 Discord，把我的 Agent 拉进去。有人给它加了 Discord 支持，我犹豫过要不要合，最后还是合了。于是我把一个对我电脑有完全读写权限的 Agent，丢进了公共 Discord。能出什么问题呢？这事本身就很离谱。
然后有人进来，看我现场用它的完整能力：看摄像头、做家庭自动化、当 DJ。我在厨房的时候跟它说“看看我屏幕，我的 Agent 跑完了吗”，因为它能看屏、能点、能在终端里替我打字，能告诉我 Codex 在干嘛。视觉这块我还在优化，理想状态当然是文本流，但现在已经能跑了：它在后台盯着屏幕，我要是干了什么蠢事，它还会吐槽。所有亲眼体验过几分钟的人都上头了。
然后项目就炸了：一周从 100 个 star 涨到 3300 个，我已经合了 500 个 PR，基本是无脑点 merge。所以我最近状态有点乱，因为项目起飞了。但最美妙的地方在于：技术消失了。你只是跟手机里的一个朋友聊天，它无限资源，能访问你的邮箱、日历、文件，能帮你建网站、做行政、抓网页、给朋友打电话、给商家打电话——通话功能我正准备合并。你不需要理解任何复杂性，上下文全都自然融合。我还有一套记忆系统，还不完美，但已经很有魔法感了。现在我走在路上，看到一个活动，给 Claude 拍张照，它不只会告诉我评价，还会看我日历有没有冲突、朋友有没有提过它……
你知道，它掌握的上下文太多了，所以给我的回应质量，远远超过那些各自活在“小盒子”里的现有工具。
用户上头背后：用户感觉不到有多少子代理
主持人：
听起来你做出了苹果当年希望 Siri 能做到、却一直没做到的东西。
Peter：
说实话，我觉得我给 Anthropic 打造了一个史上最好的营销工具。我不知道有多少人因为 Clawdbot 去订了 200 美元的套餐，很多人本来就有一个账号，又额外开了第二个。不是它“吃 token”，而是大家太爱用了，一直在用。技术本身被完全隐藏了，用户看不到背后起了多少子代理、做了多少事情，只觉得一切很顺。但要做到这种“轻松感”，背后其实是真正的工程活，而且工作量很大。难点就在这里：把复杂度藏到让人觉得像魔法一样。
Token消耗：本质是TS在搬JSON
主持人：
这点很有意思。从我们的对话里我能感觉到，你在架构上其实想得非常清楚。你已经做了几个月了，也确实爆了。在你脑子里，Clawdbot 的结构是清晰的吗？你知道哪些地方要改、哪些地方要重构？你会考虑内存消耗、token 消耗、效率这些问题吗？
Peter：
token 更多是 prompt 结构和记忆怎么设计的问题。说到底，这东西最后就是 TypeScript 在搬 JSON。实话讲，我只是从 LLM 那里拿文本，存到磁盘，再把文本发到 WhatsApp——现在还有 Teams、Slack、Discord、Signal、iMessage，WhatsApp 当然也在，还有两个渠道马上会上线，比如 Matrix，整个系统已经非常“多栖”了。但核心就是：我在不同形态之间搬运文本，可能走不同 provider，有不同 agent，有 agent loop，有很多配置，管道非常多，但里面没有哪一件事本身特别难。
打磨孵化流程：抹除复杂度，可以自我更新配置
主持人：
但确实是很多小事叠在一起，对吧？软件工程一直都是这样。即便在 AI 之前，真正难的也不是语言本身，而是怎么把它做得“有魔法感”。
Peter：
对。所以我花了很多精力在体验上。现在你只要敲一行命令，我会检查你有没有装 node、homebrew，自动装 npm 包，检查旧版本，保证能直接跑。然后我会引导你配置模型，但我会预选好 Claude，你只要一路按回车。想用 WhatsApp？输个手机号就行。
接着我会问你要不要“孵化”你的 bot，选 yes，一个 TUI （注：终端图形界面）就出来了——你还在终端里，但体验是完整的。
我给模型加了一个 bootstrap 文件，告诉它：你现在“诞生”了，要建立身份和“灵魂”，把用户的价值观放进去。模型会说“你好”，会问“我是谁？我叫什么？”我看过很多人走这个过程，那就是魔法真正开始的地方。那一刻他们不再觉得自己是在和 GPT-5.2 说话，而是在和自己的朋友聊天：有的人给它起了奇怪的名字，甚至是独角兽+自己名字的一部分。
接着它会问：什么对你重要？你在做什么？我把它设计成“好奇”。完成引导后，它会删掉 bootstrap 文件，生成 user.md、soul.md、identity 文档，记录你的信息、核心价值、名字、核心 emoji、内部梗。这些文档会随着互动不断演化、微调。然后它就会在 WhatsApp 上给你发消息，你突然意识到：我已经是在 WhatsApp 上和它自然聊天了。把这个流程做顺，真的很难。
Peter：
还有一个点：你根本不需要手动改配置，因为 agent 能改自己的配置。你直接跟它说“更新你自己”，它会拉最新版本、完成更新，然后回来告诉你“我有新功能了”。从技术规划上看，这就是魔法所在。
这其实和当年 PSPDFKit 很像：你把 PDF 的复杂度完全抹掉了，用户只觉得它“就是能用”。
大公司要用好AI，需要先来一次大重构
主持人：
你说的这些让我想到我刚看的一集《黑镜》，叫《Plaything》，一个数字小生物——当然结局很黑，但它也是个“游戏”。你之前也说自己不太玩游戏，但这个东西确实有点游戏感，只是和现实绑得更紧。这种感觉真的很迷人。
现在 Clawdbot 已经是生产级软件了，有人在用、你在合 PR。回头看 PSPDFKit 那种有几十、上百工程师的大公司，结合你现在的做法和工具，你觉得这些大公司里的软件工程会怎么变？我看到的一个分裂是：个人像你这样，AI 让效率暴涨；但在团队、在老代码库里，变化很慢。你又相当于这个“公司”的 CEO，你怎么看？
Peter：
我觉得大公司会非常难以高效地采用 AI，因为这要求彻底重塑公司运作方式。比如在 Google，你要么是工程师，要么是经理；想同时决定 UI 长什么样，这个角色不存在。但新世界需要的是那种有完整产品视角、什么都能干的人，而且数量要少得多，但必须具备极高的自主性和能力。理论上，公司规模可以砍到原来的 30%。这很吓人，从经济角度看一定会引发混乱，很多人会很难在新世界里找到位置。
所以我一点也不惊讶现在的大公司用不好 AI。他们确实在用，但要真正用好，得先做一次大重构——不只是代码库，还有公司本身。
代码库要面向Agent
Peter：
我设计代码库的时候，已经不是只考虑“对我好不好”，而是要“对 agent 好不好”。我会为模型优化摩擦最小的路径，因为最终是它们在跟代码打交道，我负责的是整体结构和架构。
现在 pull request 对我来说，更像是 prompt request。有人提 PR，我会看看需求，然后和我的 agent 从这个 PR 出发，按我理解的方式重新设计这个功能。
给应届毕业生的建议：需要保持无限的好奇心
主持人：
如果把时间快进两三年，当越来越多的人开始这样做，最后变成人人都这么干，这件事本身可能就没那么稀奇了。现在很多人担心的一个群体是应届毕业生，也就是那些还在学校里、或者即将毕业、几乎没有实际经验的人。毕竟，当这一波变化出现时，你已经是一名有经验的工程师了，你有很多积累可以依托。
如果你把自己放到那样一个人的位置，结合你现在所知道的一切，你会建议他们去做哪些事情？做哪些项目？是更专注软件工程的基本功，还是去关注 agent，或者把两者结合起来？
Peter：
我会建议他们保持无限的好奇心。进入这个市场会更难，这一点是确定的，你必须通过真正去做东西来获得经验。我不觉得一定要写大量代码，但你需要去接触复杂的开源项目，去读、去学。
你现在拥有一台“无限耐心的机器”，它可以把一切给你解释清楚。你可以不停地问：为什么要这么设计？为什么是这个结构？通过这种方式建立系统层面的理解。但这需要真正的好奇心，而我觉得现在的大学教育，并没有很好地教会你这一点。
这种理解通常是通过“吃苦”获得的，不会轻松。对新人来说确实不容易。
但他们也有一个优势：他们没有被过往经验“污染”。他们会用 agent 做出很多我们根本想不到的事情，因为他们并不知道“这原本是行不通的”。等他们这么用的时候，可能它已经真的行得通了。而且他们的朋友也一直在用这些工具。
前几天我有一个小的菜单栏应用，用来在 Cursor、Claude Code 这些环境里做成本追踪，性能有点慢。我想，那就来做性能分析吧。按照我过去的习惯，我会打开 Instruments，到处点来点去。结果 agent 直接在终端里把所有事情都做完了，速度也提升了，还给了一些建议。我当时真的被震住了，完全不需要再打开 Instruments。我看了一眼建议，说“听起来都不错，直接做吧”。
我觉得我们可能低估了进入科技行业的人有多么有办法，也低估了年轻人的潜力。回头看，很多伟大的公司，都是非常年轻、经验并不丰富的人创办的，但他们有巨大的热情。这依然是存在的机会。
Prompt才是更高信号量的东西
提交PR，要求同时提交Prompt
Peter：
当然，这对我来说也是一个需要慢慢消化的巨大变化。你刚才提到的那些点，比如把代码“织”进来、不在乎 PR、不在乎 code review，这些对我来说冲击很大。因为这些东西在我过去 15 年甚至更长时间里，一直是非常稳固的工作基石，在 PSPDFKit 也是如此。
但现在情况变了。甚至当我看到一个 PR 时，我更感兴趣的其实是 prompt，而不是代码本身。我会要求大家把用过的 prompt 一起提交。有些人会照做，而我会花更多时间读 prompt，而不是读代码。
对我来说，prompt 才是更高信号量的东西：你是怎么得到这个结果的？你具体问了什么？中间做了多少引导？这些比最终代码本身更能让我理解输出。我甚至不需要细看代码。
如果有人想要一个新功能，我会让他先写一个 prompt 需求，把它写清楚。因为我可以直接把这个 issue 丢给 agent，它就会帮我把功能做出来。真正的工作在于思考“它应该怎么工作”“细节是什么”。只要这些想清楚了，我几乎可以直接说一句“build”，它就能跑起来。
传统的上手文档，不再是优先事项
还有一种情况，如果有人只提了一个修修补补的小 PR，我会直接告诉他们别这么干。因为我花在 review 上的时间，往往是直接在 Codex 里输入一句“fix”，等几分钟的十倍。
这些事情放在一年前，甚至更早，都是不可想象的。现在我们甚至有一个“一行式”的 onboarding。前两周项目开始真正有热度时，我直接让大家把 agent 指向仓库，让它自己配置环境。我没有写传统的 onboarding（注：一步步教如何上手） 文档，而是用 Claude Code 的方式：agent 会拉代码、读文档、写配置、把一切都 setup 好，包括 launch agent，全程不需要人工步骤。
原因也很简单：这个产品本身就是 agent 构建的。它的结构、命名方式，完全符合 agent 的预期。这些模式在模型的权重里已经被“编码”过了，所以 agent 在这个仓库里行动得非常顺畅。
因此，传统意义上的 onboarding 就不再是优先事项。将来我当然还是想做一种很“魔法”的体验，但在当时，更重要的是确保核心功能稳定、信息传达到位、不出大问题。于是 onboarding 最终就变成了一句话：把这个 prompt 输入给你的 agent。
哪怕是一年前，这听起来都会像科幻。
买了iPhone17，却一直没拆封
主持人：
好，我们来做一个快速问答，收个尾。
有没有一个工具，不是 CLI，也不是 IDE，甚至可以是实体的，你自己在用，也愿意推荐给别人？
Peter：
我买过很多小玩意儿，大多数最后都在吃灰。但有一个东西，外表很一般，也不贵，却给了我几乎无限的快乐。
它是一个基于 Android 的电子相框，可以上传照片，有一个邮箱地址，朋友可以直接给它发照片，它就会自动显示出来。我在家里放了好几个。
老实说，它的动画有点卡，技术上也很糟糕，但它只是低技术地展示照片，却不断提醒我生活中那些快乐的时刻。它大概 200 美元，却比最新的 iPhone 给我的快乐多得多。
我甚至买了 iPhone 17，到现在还没拆封。因为我心里想要它，但一想到要换 SIM 卡、迁移数据，就觉得太麻烦，而且实在想不出有什么实质性的好处。相比之下，这个小设备真的让我很开心。
保持清醒的方式：健身、断联
主持人：
那在技术之外，有什么事情能帮你恢复精力？或者说，离开屏幕的时候，你靠什么让自己保持清醒？
Peter：
让我保持理智的事情，是去健身房，最好是跟着教练训练，而且把手机锁在柜子里。那样我就能拥有一个完整、不被打扰的一小时，只关注自己，活在当下。
没有通知，也不会忍不住摸手机。我们真的需要更多这样的时间。
有时候我还会出去散步，直接把手机留在家里，那种感觉其实挺吓人的。手机现在几乎像身体的一个器官，你知道它在哪里，一旦不知道，就会慌。但这种“断联”的感觉，其实很棒。
主持人：
太棒了，Peter，非常感谢。
参考链接：
https://www.youtube.com/watch?v=8lF7HmQ_RgY
——好文推荐——
持续怒斩53K星！狠人揭秘Clawdbot反行业记忆系统！跟ChatGPT大不同：不靠狂塞上下文，而是一个个md文件！网友：AI记忆第一次被工程化了
Anthropic强势出手，Clawdbot改名Moltbot！创建者自曝产品诞生故事；代码本身不值钱，不会编程也能做出「一人公司」，大量APP会自然消失
奥特曼：OpenAI会持续招程序员，内部已实现近乎无限运行智能体；幼儿园应远离AI；曝内部两条模型优化曲线；已准备好让AI看遍自己网上生活