Clawdbot（现名：Moltbot）火了到国内，社交平台上到处都是部署教学、使用教学和使用展示。国内的腾讯云、阿里云等也相继宣布上线 Clawdbot 云端极简部署及全套云服务，钉钉也在 Github 上开源了 Moltbot 接入方式。
项目背后的创始人 Peter Steinberger 也红极一时，他的构建方式成为很多人的学习对象。Peter 之前就是一位非常出色的开发者，打造了一个被用在超过十亿台设备上的 PDF 框架。后来他经历了严重的职业倦怠，卖掉股份，整整三年从科技圈消失。今年，他回来了，而他现在的构建方式、正在做的事情，已经和传统软件开发完全不同。
Peter 近期在“The Pragmatic Engineer”节目中，用近两个小时的时间分享了他的开发经历。他解释了，为什么他现在发布的代码，大部分自己都不再逐行阅读，而这其实并没什么大不了；他具体是如何打造了 ClawdBot 这个看起来就像 Siri 未来版本的个人助手的；他如何利用“闭环原则”，高效进行 AI 编程；为什么代码评审已经过时，PR 应该改名叫 Prompt Request 等，他还分享了很多关于软件工程工作流在未来几年可能发生的变化。
Peter 可以称得上是“AI 重塑开发方式”的最佳实践者之一。我们整理翻译了这期干货满满的对话，并在不改变原意基础上进行了删减，以飨读者。
怎么入行的？
主持人：这次终于线下见到你了，太棒了。
Peter：是啊，差点还搞砸了。
主持人：怎么回事？是忘了时间吗？你经常这样吗？
Peter：其实不太常见。只是最近这个时间点比较特殊，因为我最近的项目 ClawdBot 突然火了。说实话，有点睡不够了。但这种感觉也很有意思，我从来没经历过一个社区在这么短时间内爆发。真的非常好玩。
主持人：在聊 ClawdBot 之前，我们先把时间拉回去。你做的 PSPDFKit，据说被用在超过十亿台设备上，基本上你看到一个 PDF 被渲染，很可能背后就是它。那在更早之前，你是怎么进入技术行业的？
Peter：天哪，这得从很早说起了。我来自奥地利一个小地方，一直比较内向，经常被欺负。那时候，夏天总会有客人来家里，其中有个电脑迷，我迷上了他的机器，天天盯着这台机器研究，最后求妈妈给我买了一台。从那以后，我就彻底陷进去了。
主持人：那时候你还在读中学？
Peter：差不多吧，大概十四岁。我最早做的事情之一，是从学校“顺”了一张老 DOS 游戏的软盘，然后自己写了个拷贝保护，好拿去卖。加载一次要两分钟，但我当时觉得这事特别酷。当然也打了很多游戏，不过对我来说，做东西本身就像在玩游戏。说实话，现在做事带来的成就感，比通关游戏还爽。
一开始我看的是类似 Windows 的 bash 脚本，然后做网站，写一点 JavaScript，虽然完全不知道自己在干嘛。真正系统性地学“怎么构建东西”，是上大学之后。我从没见过我父亲，家里也很穷，所以我一直要打工，学费生活费都得自己赚。别人放假的时候，我就在公司全职上班。
我第一份正式工作在维也纳，本来只打算干一个月，结果他们留了我六个月，后来我在那家公司工作了大概五年。第一天他们给了我一本厚厚的书，上面写着“Microsoft MFC”，到现在我做梦还会被吓醒。我当时心想，这也太糟了。
后来我干脆悄悄用 .NET，也没跟他们说。过了几个月我才摊牌，说我顺便做了点“技术栈现代化”。反正木已成舟，他们居然也一直留着我，大概因为事情确实做成了。我实际上还挺喜欢.NET 2.0 的泛型，不过应用启动慢得要命，第一次跑基本要等很久，老 Windows 用户应该都懂。
主持人：那你后来是怎么接触到 iOS，又是怎么想到做 PSPDFKit 的？
Peter：那是后面的事了。上大学时，有个朋友给我看了 iPhone。我就摸了一分钟，立刻决定要弄一台。那一刻真的像被雷劈了一样，完全不一样，完全是另一个层级的体验。但当时我其实还没想过要给它做应用。
主持人：那大概是 2009、2010 年左右？
Peter：差不多。后来有一次，我在地铁上用一个交友网站，用的是 iPhone OS 2。我打了一大段很走心的消息，刚点发送后车进隧道了，JavaScript 禁用了发送按钮，然后直接报错。那时候没有复制粘贴、没有截图、页面还不能滚动，那段话就这么没了。我当时气炸了，觉得这简直不可接受。回到家我就把那个网站黑了，用正则去解析 HTML。
现在看当然完全不该这么干，后来我硬做了一个 App。我用的是 iPhone OS 3 的 Beta 版，Core Data 也是 Beta，还用改过的 GCC，把 blocks 编译器移植进来。各种 Beta 技术一锅炖，我自己其实也不知道在干嘛，折腾了很久才跑起来。我给那家公司写信说我做了个 App，问他们怎么看，没人理我，我就直接丢到 App Store 上架了。
主持人：这就是那个交友 App 的客户端？
Peter：对，本质上就是把 HTML 当 API 用，纯解析页面。
主持人：现在看挺野的，但在当年确实没人这么干。
Peter：我定价五美元，第一个月就赚了一万美元。当时我完全不知道流程有多复杂，Apple 的系统也很原始。我甚至把收款账户填成了我爷爷的。有一天我爷爷打电话问我，说怎么 Apple 给他打了一大笔钱，我跟他说“这是我的，你千万别动”。
后来有一次我在夜店里，看到有人在用我的 App，我特别骄傲，差点冲过去跟他说这是我做的，最后还是忍住了。没多久，我就跟工作了五年的公司说，我要全力做这个项目。老板当面嘲笑我，说这是个一时的风口，肯定不长久。那一刻我心里就憋了一口气：总有一天，我要做一家比你们值钱的公司。结果这花了我八年的时间。
我有点成瘾性格，一旦投入就停不下来。我疯狂打磨这个 App，高速学习，也是那段时间我开始用 Twitter，那些对我职业发展影响巨大。
后来有一天凌晨三点，我在派对上喝得有点多，然后接到了一个电话，对方说他是 Apple 的 John，说我的应用有问题，有人举报不当图片。电话挂了，我的 App 也就此下架。我刚辞了工作，心态直接炸裂，开始接零散的活儿。
在旧金山的一家酒吧里，我被介绍为“奥地利最好的 iOS 开发者之一”。就这样，我拿到了美国的工作机会，搬过去待了一阵子。后来去了 Nokia Developer Days，那真是史前时代了。
在那里，有人找我，说他们在东欧做了一个杂志阅读 App，经常崩溃。那会儿 iPad 刚出来，Steve Jobs 说它是出版业的救世主，大家都在做杂志 App。我一听觉得这是个不错的短期项目，就接了。我一打开代码，整个人都懵了。那是我见过最糟糕的 iOS 代码，整个项目只有一个文件，几千行。
主持人：还是 Objective-C？
Peter：对，是 Objective-C，而且他们把 Windows 当成 Tab 来用。我都不知道这能行。我很惊讶这居然能用，但感觉像个纸牌屋。我试着“外科手术式”地修补问题，但基本上是动一处、坏一片。最后我好不容易把它稳住了，就跟他们说，“这太疯狂了，我要重写”。
他们原本预计要半年，我说我一个月就能搞定，最后花了两个月，也不算差太远。接下来我就一直在解决各种 PDF 相关的技术问题。这个领域谈不上多性感，但每个领域里都能找到真正有挑战的点。比如一个 C 语言调用渲染 PDF 可能要 30MB，但整个系统只有 64MB，如果你不够小心、不够聪明，系统随时就把你干掉。
我那段时间完全沉迷在“把它做到极致”这件事上，比如屏幕旋转时页面的动画效果，这种细节我会反复打磨，花了远超合理的时间。所以原本一个月的活，最后干了两个月，但结果是好的。之后我又跟他们合作了一段时间。
后来有个朋友给我发消息，说他在做一个杂志应用，PDF 那块特别难。我跟他说，我刚好做过，对方就问我能不能把代码给他，我说可以。先把那套杂志 App 里和 PDF 有关的部分抽出来，确认对方也没意见。
然后我突然想到，既然有人需要，为什么不试着卖给更多人？我用一个 WordPress 模板，硬改成能跑在 GitHub Pages 上。然后用 fastlane 流程最后得到一个 Dropbox 链接，里面有源代码。当天晚上我就发了条推文。一周之内，有三个人买了，大概两百美元。
在当时对我来说，这已经很不可思议了。不只是有人付钱，还有十封邮件在抱怨，说他们也想买，但这个产品还没有他们想要的功能。比如有人问，为什么不能选中文本？几个月后我才真正意识到，这功能到底有多难。
主持人：PDF 里的文本选择。
Peter：对，尤其是这个。你知道那句话吗：公司是由年轻人建立的，因为他们不知道有多难。我当时完全没概念，后来才发现这简直是疯了一样复杂。
直到现在，前几周还有人给我写邮件，说他们在做 PDF 相关的事情，想找我帮忙。我基本都会回一句：不好意思，我已经把这辈子该懂的 PDF 知识都学完了，远远超过一个正常人该承受的量，祝你好运。
不过当时，这个项目真的起飞了。我一边等签证，一边继续维护。买的人越来越多。那是夏天，我躺在湖边晒太阳，邮箱里突然又进来一封邮件，说又有人买了，六百美元、八百美元。随着功能变多，我不断涨价。
等我真的去旧金山那家公司上班时，这个项目赚的钱，已经超过我在那里拿的工资了。但我那时的想法还是：我得去那家公司看看，于是还是去了。
主持人：也就是说你搬到了 San Francisco。
Peter：对，而且很有意思的是，那家公司后来也让我用自己的框架帮他们做东西。创业公司当然不可能只干八小时，我的本职工作很忙，个人项目也一样，睡的自然越来越少。
三个月后，我的经理 Sabine 把我叫过去，问我一句话：“Peter，你还好吗？”公司给了我一个选择：要么继续在这家公司工作，把个人项目停掉；要么反过来。他给我一周时间决定，而且因为签证问题，如果不留下，就得离境。这个决定其实一点都不难。我很清楚，我想做自己的事情。
主持人：那时候你已经看出来了，这是一个真正的生意，至少能给你带来和美国工作差不多的收入。
Peter：我从来不是被钱驱动的。
主持人：那你真正的驱动力是什么？
Peter：我想做那种让别人觉得“太棒了”的东西。我特别迷恋细节，迷恋那些小小的惊喜感。并不是因为这个领域没有竞争，相反，竞争很多。但我心里一直憋着一股劲：我要做一个像 Apple 自己会做出来的产品，充满关怀、打磨、克制，还有那些行业里很多人已经不在乎的细节。
所以哪怕有竞争对手功能更多、做得更早，我的产品依然更成功。因为开发者试过之后，都会觉得我的用起来最好。我一直觉得，产品的“感觉”比功能列表重要得多。我们为什么买 Apple？不是因为它功能最多，而是因为它用起来就是更舒服。
从卖组件到创建公司
主持人：那你是怎么从“一个人在卖 PDF 组件”，走到开始招人的？你什么时候意识到这件事可以做得更大？
Peter：我回到维也纳之后，决定彻底 all in，开始和一些自由职业者合作。说实话，我招人其实招得太晚了，完全可以更早迈出这一步，但这一步真的很难。
从那时起，这个产品开始有了自己的生命。我职业生涯里差不多有 13 年都在打磨这个名字奇怪的产品。名字我一直没改，当初想名字只花了几分钟，就叫 PSPDFKit。后来改过一次，但说实话，要不是不得不改，我可能还是不会动。
主持人：名字确实有点绕，但非常独特。
Peter：如果你写 Objective-C，你就会觉得这个名字很合理，因为它本质上就是个命名空间。我的营销策略也一直很简单：我只关心开发者。虽然最终拍板的是管理层，但只要我能说服公司里的工程师，他们就会替我去内部推广、游说。
我们从来不做冷邮件，也不搞侵略式销售。所有客户都是自然找上门的。我们只做三件事：把产品做好、写真正有价值的技术博客，以及参加大量开发者大会。对我来说，最重要的是让大家明白，这个产品背后的人是真的懂技术、也真的热爱这件事。而这一点，会直接体现在产品里。
主持人：PSPDFKit 底层用的是什么技术？最早是 Objective-C 吗？后来转成 Swift？有没有用到 C 之类的？
Peter：一开始确实是 Objective-C，后来逐步覆盖到所有平台。真正一次大的转折，是我们把 Apple 自带的渲染器换掉了，那个东西当时问题很多，之后改成了一个大型的 C++ 渲染器，后来所有平台基本都共用这一套核心。
我们在 Web 这块也做得非常早，是最早一批跑在 WebAssembly 上的 PDF 框架之一。当时我做了一件现在看来还挺聪明的事：在一切刚开始的时候，我们做了一个性能基准测试。后来这个 benchmark 被 Google、Microsoft、Apple 等公司拿去用，成了他们内部的参考指标之一。结果就是，这些大公司为了跑得比我们快，反过来不断把他们的渲染器优化得更快，而测试用的内容，其实就是我们自己的渲染场景。
创业后，分享公司的“核心秘密”
主持人：厉害。随着公司规模变大，我对 PSPDFKit 的一个深刻印象是，你们写了大量博客。记得有一篇文章，讲的是团队怎么运作：每个功能都要从 proposal 开始，因为 API 很大、用户很多，所以你们非常保守；还有类似 Boy Scout Rule 那样的重构原则。团队从十几个人发展到几十个人，这种文化是怎么建立起来的？
Peter：我卖股份的时候，公司大概七十人，现在已经接近两百人了。一开始我就很清楚，在维也纳不可能招到我需要的所有人，所以我们从一开始就是 remote first，后来又变成了一种混合模式，反而更复杂。
很多东西都是边走边学。我从来没有“我要当 CEO”的执念，我一直在写代码，我会找合适的人来帮我做公司的其他部分。业务我能做，也做得还可以，但我真的不喜欢那种企业销售电话，你得去琢磨一个“魔法数字”，看对方可能愿意付多少钱。这就是企业销售，真的很折磨。但说到底，这种模式可能是唯一行得通的。
主持人：你是说企业销售本身？
Peter：对。
主持人：很多开发者去厂商官网，看不到价格，只看到“联系我们”或者“预约演示”，都会很不爽。为什么一定要这样？
Peter：原因很简单，我们会看你的公司情况，然后大概判断你能接受的价格，再定一个数。听起来确实很糟糕，但当你的产品没办法简单拆成一个统一定价时，这是现实。
一个自由职业者，和一家财富五百强公司，用法完全不同，获得的价值也完全不同。如果统一收费，要么把小客户挡在门外，要么让大客户觉得价格可疑。价格定低了，大公司采购流程都走不起来；定高了，小团队直接流失。所以这个过程看起来不公平，但在某些产品上，反而是最公平的方式。
软件大致可以分成四个象限：容易或困难，有趣或无聊。我们处在“又难又无聊”的那一块。
如果只构建每个开发者都想构建的东西，卖起来一定很难。卖给开发者本来就难，如果一个东西既简单又有趣，那基本没戏。但如果是那种“我真不想碰，而且还特别难”的，反而是个好位置。我找到了这样一个细分领域，里面有无限多复杂问题可以解决。
主持人：那解析 PDF 到底难在哪？有规范啊，我是工程师，照着规范做不就行了？
Peter：举个最简单的例子。PDF 里有链接，比如目录，点一下跳到某一页。我一开始的假设是，可能有一两百个链接。我就按这个规模设计了整个数据模型。后来来了一个付费很高的客户，说他们的 PDF 打开要四分钟，我一看是一份五万页的文本圣经，每一页上有上百个链接。
主持人：那就是五十万个链接。
Peter：对，我的模型直接爆炸了。假设差了三个数量级。但这时候你已经是一个成熟产品了，还有稳定的 API。你要怎么彻底重构内部，又不破坏所有用户？所有东西都得改成 lazy loading。以前加载 100 个对象没问题，现在不行了。我花了整整两个月重写内部结构，同时还要保证对外 API 看起来还是“简单的”。用户不需要知道哪些是立即加载的、哪些是延迟加载的，引用关系也必须保持一致。
主持人：这些引用必须还能连得上。
Peter：对。我其实非常喜欢做支持，这也是公司能成功的重要原因之一。如果你提一个工单，结果 CEO 直接回你，还帮你解决问题，那感觉是完全不一样的。
我一直有个策略：支持一定要快。五分钟内回，和两天后回，体验差别巨大。这个问题就是其中一个例子，我花了两个月把它彻底解决，最后跑得非常顺，那种满足感真的很强。
主持人：那时候你自己还写很多代码，对吧？虽然团队已经很大了，但你仍然会深入细节。
Peter：当然。我有一支非常棒的团队，有些模块我参与得更多。移动端一直是我最上心的部分，但我也会深度参与技术、市场和业务。业务上我有 Jonathan 帮忙，市场和销售也有很优秀的人。其实，持续写博客、写你是怎么解决这些复杂问题的，会帮你吸引同样想解决复杂问题的人。
主持人：这是我对 PSPDFKit 最深的印象之一。你们的博客不只是营销，而是真的好看。说实话，我并不做 PDF，但如果要说起 PDF 框架，第一个想到的就是 PSPDFKit，因为只有你们会写这么有意思的技术文章。
主持人：你现在回头看，会不会也觉得奇怪，为什么更多公司不这么做？还是说，这本来就需要创始人本身是个喜欢写、喜欢拆解问题的工程师？你当时写这些文章，是出于“这对公司有用”，还是单纯因为你自己想把解决过的难题记录下来？
Peter：我喜欢分享，也喜欢启发别人。有时候团队内部也会纠结，要不要写这些内容，毕竟算是一些“秘密武器”，但我从来没太在意这些声音。还有一点很重要：写下来本身，就是加深理解。你觉得自己懂了，但当你要教别人时，才会发现自己是否真的懂。所以对我来说，这也是一种复盘和保存。我解决了一个很难的问题就想把它留下来，顺便帮到别人。
当然，我也享受关注。但更重要的是，有时候我自己过一年再回头看这些文章，会发现这就是公司最好的文档，是我自己的“技术笔记本”。它在很多方面都很有用。很多大公司流程太重，而且不少开发者本身不喜欢写东西，所以我后来干脆规定，每个月给所有人一整天，只干一件事：写一篇博客。
主持人：那天不用干别的活，只写。
Peter：对，就写。一天的时间其实已经很多了，现在我写一篇文章也就几个小时。我不想过多谈论公司增长阶段，但我觉得公司最有意思的阶段，是刚开始以及快速成长的阶段。
后来人多了，流程多了，更像是在“养护花园”，而不是疯狂 hack。事情变得更迭代化，也没那么刺激了。人一多，内部摩擦、情绪问题也多，这些我并不享受。那段时间我真的被烧干了。
“停更”，赋闲
主持人：你觉得是什么让你最终人力交瘁的？
Peter：我只是工作太猛了，几乎每个周末都在工作，还要处理大量管理事务。CEO 本质上就是“兜底的人”，凡是别人没处理好、处理不了、或者搞砸的，最后都得你来收拾。而且很孤独，你不能随便讲很多事情。哪怕公司已经很开放了，你也不能一直表达负面情绪，就算真的发生了很糟糕的事，你也得扛着。
我记得有个周末，合伙人凌晨给我打电话，说一家大型飞机制造公司，因为我们的软件崩了，飞机停飞了。那是个非常“刺激”的周末，最后我拆了他们的应用，证明是他们外包代码乱改，触发了授权回退逻辑。但那种时刻，你会觉得公司随时可能完蛋，而这种压力只是所有压力中的一部分。
这些事情你能撑一阵子。但我也相信，burnout 不完全是因为工作太多，更是因为你开始不再真正相信自己在做的事情，或者内部冲突太多。我们当时在管理团队里争论也很多，我还犯了一个错误，以为公司应该用一种过度民主的方式来管理。这些都消耗了我。但即便如此，我一点都不后悔这段经历。
主持人：从外人的角度看，你卖掉了股份，赚到足够多的钱，按理说已经不用再工作了。很多刚起步、或者未来想创业的人，都会觉得这简直是终极梦想。既然已经“通关”，是不是就该停下来、享受生活了？现实是，大多数人走不到那一步。但一旦走到了，好像任务就完成了，就像攀岩爬到顶，敲响铃铛，游戏结束。
主持人：外界看，你博客更新停了好几年。那段时间你在做什么？又学到了什么？也就是在你回归到现在之前，那几年到底发生了什么？
Peter：我真的花了很长时间让自己“降压”，去填补那些我以为错过的人生体验，花了不少钱。有几个月，我甚至连电脑都没开过。那段时间，我完全没有“接下来该干嘛”的感觉。
说实话，那种状态挺违和的，你这么早就“退休”，或者说有一个好到不需要再工作的退出，这件事本身就会把人搞懵。那几年对我来说，其实挺难熬的。
后来有一天，大概在四月，我突然想起一个很多年前只是当副业做过的项目，我心想还是想把它继续做完吧。于是，三年多之后，我重新坐回电脑前，开始写代码。那个项目是个 Twitter 分析工具，用 Swift 和 SwiftUI 写的。其实当年我就知道，这东西如果做成 Web 会好很多。
主持人：所以这是一个你一直放在心里的老想法？跟 Twitter 有关的？
Peter：对，算是分析工具。最开始只是我自己想用，因为市面上根本没有。三年后再看，还是没有。现在勉强算有点类似的，但我中途也被别的事带跑了。我当时想用 Web 技术重写，但说实话，在公司里我从来没碰过那一块。那一整套技术栈一直是 Martin 在负责，他很厉害，所以我完全不用操心。
主持人：所以你其实一直没怎么亲手下场？
Peter：对。等我再回来自己做的时候，我才发现，“哇，这一层真的很深”，而且这其实是个陷阱：你在某一套技术上越熟练，跳到另一套时就越痛苦。不是做不到，是太折磨人了。我在 Apple 那套技术里，闭着眼都能写代码；可一换栈，连最基础的东西都要去 Google，一下子就感觉自己又成了新手。
主持人：而且经验越多，越讨厌这种感觉。效率下降，明明知道自己本可以更快。
Peter：对。所以我回来的时候就在想：那 AI 到底是什么？CI、AI 那些大家都在吐槽的东西，到底值不值得看一眼？老实说，我某种程度上反而要感谢那三年几乎没碰电脑的日子，因为你们那时候已经把 AI 看过一轮了，知道它当时有多烂。
回归即上手 Claude Code，“上瘾了”
主持人：对，你错过了 GitHub Copilot 的早期测试版，那种“高级自动补全”的阶段。后来有了 GPT-3.5，再到 GPT-4，才是真正的飞跃。所以你回来之后，第一个用的是什么工具？你等于是直接跳过了两年开发者一边用、一边嫌弃 AI 的阶段。
Peter：是 Claude Code。
主持人：你一上来就用它？
Peter：对。我记得它刚发布不久，之前就有 Beta。
主持人：也就是说，你休息了一段时间回来，直接打开 Claude Code，前面的演进全都没经历。
Peter：没错。我记得我拿了一个以前写得很乱的副项目，又用我自己做的一个浏览器插件，把整个 GitHub 仓库转成一个 1.3MB 的 Markdown 文件。我把它丢进 Google AI Studio，用 Gemini 之类的模型，敲了一句：“给我写一份 spec。”它直接生成了四百多行代码。
我再把这份 spec 拖回 Claude Code，说一句“照这个做”，然后我去干别的事了。等我回来，它告诉我：“已经百分之百可以用于生产环境了。”我一跑，直接崩了。
后来我又给它接了 MCP，让它能用浏览器，我记得 MCP 当时已经有了。它又跑了几个小时，最后居然做出了一个 Twitter 登录页，还能跑点流程。说实话，效果不算好，但它真的“做出了点东西”。那一刻对我来说，简直是被震住了。
主持人：那是在去年四月、五月左右，对吧？
Peter：对。已经好到让我看清方向了。我立刻意识到：这就是未来。从那之后，有好几个月我都睡不好觉。
主持人：我记得有一次我凌晨五点在 Twitter 上给你发私信，你马上就回了。我还问你怎么这么早，你说这是常态，你基本都没睡。我问你在干嘛，你说一直在用 Claude，特别上瘾。
Peter：真的，就跟赌场一个道理，它就是我的小老虎机。你敲下一个 prompt，要么啥也没发生，要么一坨垃圾，要么突然给你个让人头皮发麻的结果。
主持人：而且你是一个经验非常丰富的开发者，对你来说，被“震撼”并不容易。你见过好代码、烂代码，心里是有一个标准的。
Peter：所以才好笑。我以前在公司时，花了大量的时间在所谓“抠细节”上。现在回头看，我都会想：我当时在干嘛？客户根本感知不到这些。当然，代码要可靠、要快、要安全，这些是底线。但我当年真的抠太多了。
主持人：但另一方面，你刚才也说过，大家之所以喜欢 PSPDFKit，正是因为它打磨得最好、最稳定。你不觉得那种“抠细节”其实是在控制技术债吗？某种程度上，正是这种偏执才让产品性能和质量都站得住。
Peter：是的，这么说也没错。到现在我也还是这样。我上一篇博客，其实就是在“忏悔”，我承认我开始在主分支上直接提交 AI 写的代码。
与此同时，我其实还是花了大量时间在做结构重构。就拿最近来说，我特别想把一个 PR 合进去，那是一条接近一万五千行的改动链。
在一个项目里，我把所有东西都迁移到了插件化架构，这件事让我非常兴奋。我真的很在意整体结构。但我没有把每一行代码都读一遍，因为很多代码说白了就是枯燥的“管道工程”。
你看，大多数应用本质上都差不多：数据从 API 进来，是一种形态；你解析、封装，变成另一种形态；存进数据库，又是一种形态；再读出来，又变一次；最后变成 HTML 或别的形式，你在页面里输入，它又变了。大部分软件，其实就是在应用里不断“揉捏”数据，我们本质上就是高级的数据搬运工，而真正难的部分，如 Postgres 这种东西三十年前就被一群天才解决了。这就是现实。
当然，总会有一些有意思的地方，但我真的不需要关心每个按钮怎么对齐、每个 Tailwind class 怎么写。有些细节很无聊，有些细节很有趣，但整体来说，更重要的是系统架构，而不是逐行读代码。
日常如何用 AI 编程工具工作？
主持人：那我们跳到现在。你现在用 Claude 相关工具写代码时，日常工作流是怎样的？你用终端吗？几个终端？都用哪些工具？你刚才说你不太做逐行代码审查，但又一直在想做架构。如果你要跟一个即将加入团队的开发者解释，你的一天大概是什么样的，会怎么说？
Peter：这个过程挺有意思的。稍微回顾一下，一开始是 Claude Code，然后我就彻底上头了。接着有一段时间我用 Cursor，又试了 Gemini 2.5，后来又用了 Opus 4。我还把不少朋友也拉进来了，比如我在越南认识的 Armin 和 Mario，他们都是被我“传染”的。我当时状态真的很上头，搞得他们也开始试，然后大家一起凌晨五点不睡觉。我把这群人戏称为“黑眼圈俱乐部”。这也是为什么我后来在伦敦搞了一个 meetup，名字就叫Claude Code Anonymous。
真正把我震住的，是一个认知上的变化：我突然意识到，我现在几乎什么都能做了。
以前做副业要慎重挑选，因为写软件真的很难。现在也不轻松，但那种“摩擦”感变了。过去是“我在这个技术栈里很强，在那个栈里很菜”，现在我会想：算了，直接上 Go 吧。我完全不懂 Go，但我有系统层面的理解。一旦你有了这种理解，就会慢慢形成一种感觉，知道什么是对的、什么是错的。这本身就是一种技能。
我记得有人发推说，写代码时你能“感觉到摩擦”，而正是这种“摩擦”帮你做出好的架构。我现在 prompt 的时候也有同样的感觉：我能看到代码刷刷地生成、能感知它花了多久、能感觉到模型是不是在“顶你”，也能判断生成的东西是乱的，还是有章法的。
我在发出 prompt 的那一刻，心里其实已经有个预期：这事大概要多久。如果明显比预期慢，我立刻就知道有问题。
主持人：你等于是在“感觉”模型的状态，对吧？
Peter：对，我觉得这是一种共生关系。我在学着更好地“跟它说话”，甚至可以说是一种新的、半死不活的语言。同时，我用这些工具的能力在提升，模型本身也在进化。
从四月到现在，我觉得真正的拐点是在夏天：那时它已经强到，你几乎可以不手写代码，就把软件做出来。但真正让我彻底服气的，其实是 GPT-5.2。我觉得它被严重低估了。
我其实不太理解，为什么还有那么多人主要用 Claude Code。当然，我能理解那是一种不同的工作方式。但我现在用的这一套强得离谱，几乎每一个 prompt 都能给我想要的结果。这在 Claude 上是很难想象的。
我最近的一个项目常常在 Codex 上同时跑五到十个 agent。如果你是典型的 Claude Code 用户，你得忘掉不少“为了哄它出好结果”的小技巧。
我也见过 Claude Code 团队，他们确实开创了一个新类别。Claude Code 是一个定义品类的产品，用来做通用电脑工作非常棒、用来写代码也很好，我现在几乎每天还在用。但一旦进入复杂应用的代码编写，Codex 就强太多了。Claude Code 往往只读三四个文件，就自信满满开始写代码，你得不断拉着它，让它多读、多看，理解整个代码库，才能把新功能编进去。Codex 则会安静地读文件，可能读十分钟。如果你只用一个终端，这体验确实会让人崩溃，我完全理解。
但我更喜欢那种，你不用事无巨细地告诉它该怎么做，我和模型更像是在对话。
我会说：“我们一起看看这个结构，有哪些可能性？你有没有考虑过这个功能？”因为每一次 session，对模型来说都是从零开始理解你的产品，你有时候只需要给它一点点提示，让它往不同的方向探索。我不需要什么 Plan 模式，只是一直聊，直到我说“那就这么建吧”，它才会真的开始动手。当然，它们都挺“容易被触发”的，但只要我说的是“讨论”“给我选项”，它就不会直接写代码。
主持人：所以你大量的 prompting，其实是在和 agent 一起做规划？
Peter：对。比如我会提醒它“我们需要文档，那放在哪里合适？”它可能会建议“这应该单独成一页。”系统设计是我在做的，因为我对产品整体形态有清晰的理解。我不需要逐行理解代码，那是 Codex 在做的事，但架构师是我。
主持人：这听起来有点像很久以前的一种模式：有一个“Architect”，以前也是开发者，但不再亲手写代码，而是负责系统蓝图，下面有一群工程师实现。这种模式在很多现代公司已经不流行了，大家更偏向资深工程师一起协作。不过在一些银行之类的地方，还是能看到这种“大写的 Architect”。问题是，这种模式往往很让人讨厌：设计的人不用值班，不直接为结果负责，最后在现实里容易失效。
而你现在的状态，倒像是你是 architect，但手下是一群 agent。区别在于，你依然是独立贡献者，代码是你的、责任也是你的。如果你推了个 bug 把 ClawdBot 搞挂了，就像最近那次，你是要负责的。以前在公司里，architect 往往被流程和人层层保护，不太需要直接面对结果。
Peter：我其实不太喜欢“architect”这个词，我更愿意叫自己 builder。我发现，能不能把 AI 用好，人群之间差异非常明显。
像我关心的是结果、是产品，我很在意它的感觉、体验。我关心结构层面的骨架，但不会抠那些小细节。而另一类人，特别喜欢写硬核代码、研究算法，他们不太喜欢产品、市场这些东西。他们更享受解决“难问题”。而偏偏，这正是 AI 最擅长的部分，所以这类人往往会抗拒 AI，或者感到非常失落。
很多时候，我只是给模型一点提示，但老实说，我去年在软件架构和系统设计上学到的东西，比过去五年加起来都多。这些模型里装着海量知识，一切都只差一个“问对的问题”。
像我那个 Twitter 项目到现在还没完成，我也很希望能回去继续做。所有东西一度都曾跑得很好，但用着用着就开始卡、变得奇怪，然后又莫名其妙恢复。这类问题特别难 debug，因为很难复现。基本就是：你用得越多，它就越慢。
后来我发现，是 Postgres 里有一些在特定 insert 时触发的逻辑把数据库拖得很忙。模型看不到这一层，因为抽象太远了。问题出在一个文件里的一个函数，名字也不明显。我一直没问对问题，直到我问了一句：“这里有没有副作用？”才把它挖出来，然后改掉了。所以说，一切真的都只差在能否问一个对的问题。
主持人：但前提是，你得有足够的知识和经验。
Peter：对，这正是关键。那些对内部实现执念很深、又不太在乎“能不能先做出来”的人，往往会抗拒 AI；而那些更兴奋于“把东西做出来”的人，反而进展飞快。
还有一点对我帮助很大：以前我开公司带团队，可以盯着每个人的代码，要求他们写成我想要的样子。但很多没管过人的开发者，没有学会放手，接受“这段代码不是我理想中的样子，但它能让我更接近目标”。不完美的地方，永远可以之后再改。
我非常相信“迭代式改进”。当年在公司里，我就是花了很长时间学会一点点放手。所以，当我开始用 Claude Code 的时候，感觉就像我手下有了一群工程师：有时候很不完美，有时候甚至有点蠢，但偶尔又异常聪明。我需要引导他们，一起朝着一个目标前进。某种程度上，这感觉就像又当了一次老板。
高效率的秘诀
主持人：挺有意思的一点是，在之前，你用一种非常传统的方式做了十几年的软件，甚至不止十几年。你不仅把产品打磨得很扎实，也非常擅长带团队、设立高标准，对“工程本身”这件事非常在意。而现在，你用 agent、用 AI 写代码有一年左右的时间了。对比这两种阶段，你觉得真正改变了什么？又有哪些东西，其实并没有变？
Peter：我不太喜欢“vibe coding”这个说法。
主持人：那你更愿意怎么称呼？
Peter：现在大家基本都这么叫了吧。我自己对外会说，我做的是“Agentic Engineering”。现在我往往是凌晨三点开始写代码。那些枯燥、机械的编码工作基本都被自动化掉了，我的速度快了很多，但与此同时，我需要思考的事情也多得多。
我依然能进入那种心流状态，感觉和以前几乎一样，但精神消耗其实更大，因为我不是在管理一个工程师，而是同时管五个、十个 agent。我在不同模块之间来回切换：这边是一个子系统，那边是一个功能点，我心里大概知道这个功能交给 Codex 可能要跑四十分钟到一个小时，那我就先把方案想清楚再丢给它去做，然后我转头去做别的事。
这个在跑、那个也在跑，我要过一会儿回来看看这个、再切到另一个，脑子里一直在做上下文切换。我其实挺不喜欢这种状态的，也觉得这是一个过渡期的问题。将来模型和系统更快之后，我可能就不用并行这么多。但为了保持 flow，我现在必须高度并行。
通常会有一个主项目占据我的主要注意力，旁边还有几个“卫星项目”，可能我只花五分钟交代一下、它跑半小时，我回来看看结果就行，对脑力占用不算大。
主持人：听你这么说，我想到两种画面。一种是那种经营类游戏，要管厨房里的员工，看着一道道菜出炉，你得不停切换。另一种是看国际象棋大师同时下二十盘棋，他们走到一块棋盘前看一眼，立刻做决定。有的棋要想久一点，有的扫一眼就走。你就像在不断扩展自己的“并行带宽”，只要你还能顺畅地切换。
Peter：区别在于，用 Claude Code 的时候，你确实得换一种工作方式。它很快，但第一版产出经常是跑不通的。比如它写了点东西但你忘了同步改另外三个地方的话，程序就崩了。真正高效的秘诀在于：你必须把闭环做完整，让 agent 能自己 debug、自己测试。这是最大的秘密，也正是我后来效率暴涨的原因。
但老实说，在 Claude Code 那一套下，很多时候你还是得回去修修补补，迭代次数也不少，所以总体并不一定快多少，只是更“互动”。现在用 Codex，几乎一次就对。我的基本策略永远是：做一个功能，一定让它写测试，确保能跑起来。
主持人：至少要能跑。
Peter：对。哪怕是写一个 Mac 应用也是一样。就像我前两天在 debug 一个问题：同样的 TypeScript 代码，在 CLI 里能找到远程网关，但在 Mac app 里不行。Mac app 的 debug 特别烦，你得编译、启动、点来点去才知道不对。
所以我干脆说：“你给我做一个 CLI 调试工具，走完全相同的代码路径，我可以直接调用。”然后就让它自己跑、自己改。它跑了一个小时，最后告诉我这是一个 race condition 和一个配置错误。听起来也很合理。我不需要亲眼看它怎么写代码，只要闭环跑通了就行。
主持人：你其实是因为搭好了验证闭环，所以你信任它。这和在大公司里做项目有点像，所有测试都过了，并不代表百分百没问题，但已经是一个很强的信号了，至少有人替你想过、测过。
Peter：即便在我最新的项目里，也照样会有 bug。比如 Antigravity 在工具调用的循环格式上有些奇怪的行为，你得做过滤。我一开始被折腾了很久，后来突然意识到：我为什么不把这事自动化？
于是我直接跟 Codex 说：“设计一套 live test，起一个 Docker 容器，把整个系统装起来，跑一个完整 loop，用指定文件里的 API key，然后让模型读一张图片，生成一张新图片，再反过来分析结果。”
这个过程跑得很慢，但它把我所有 API key 都测了一遍，从 Anthropic 到 OpenAI 再到 GLM，所有细节问题全修了，因为闭环是完整的。
主持人：你说的“闭环”，本质上就是让 agent 能验证自己的工作。
Peter：没错。这也是为什么现在这些模型特别擅长写代码，但写创意内容反而一般，因为代码是可验证的：能编译、能 lint、能跑、能看输出，只要你设计得好，就能形成一个完美的反馈回路。我甚至会把核心逻辑都设计成可以用 CLI 跑，因为浏览器那一套循环太慢了，你要的是快速反馈。
主持人：所以有些东西其实没怎么变：比如后端、业务逻辑这种，本来就更容易验证。
Peter：反而有个挺反直觉的点：用这种方式写代码，会让你变成一个更好的工程师。因为你必须把架构想清楚，才能更容易验证，而验证正是把事情做对的关键。
主持人：这其实和 AI 之前是一样的。做复杂系统的人，一开始就会想怎么让它可测试、接口怎么设计、要不要 mock、要不要端到端测试。这些都是非常困难、而且一旦做了就很难改的决策。
Peter：软件还是软件。我现在可以很坦然地说，我不再亲手写代码了，但我写的代码质量比以前更好。而以前我已经写得很好了。在公司那会儿，测试常常很痛苦，各种边界条件、分支爆炸。
主持人：除了像 Anders 这种我非常尊敬坚持 test-first 的人，大多数开发者其实都不爱写测试。我自己也是。测试和文档对我来说从来不是一种创作。
Peter：现在完全不一样了。我最近一个项目的文档质量是我职业生涯里最好的，但我一行都没写。我只是跟模型讲清楚设计权衡：为什么这么做，然后让它写给新手看的部分，再在后面加上更技术化的细节，效果好得惊人。测试也是一样。每做一个功能，我就会自然地问：这个怎么测？如果换一种结构，是不是更好测？因为我脑子里始终只有一件事：怎么把闭环关上。模型必须能自己验证结果，这会反过来逼我做出更好的架构。
为什么开发者 AI 编程玩不溜？
主持人：那你觉得，为什么还有很多经验丰富的开发者，对 AI 这套东西依然很抗拒？
Peter：前阵子我看到一篇博文，作者是我非常尊敬的人。他测试了好几个模型，其中甚至包括一些本来就不适合写代码的模型。他的做法听起来像是随便写个 prompt，在网页上点发送，拿结果就跑，甚至都不编译，结果当然很失望。
但问题是：你觉得自己第一次写代码就能没 bug 吗？这些模型，本质上是人类知识的幽灵。它们不可能一次就对，所以你必须有反馈闭环。你也不能只发一个 prompt，而是要开始一段对话。
他还抱怨模型用了旧 API。但你没告诉它 macOS 版本，它当然会默认用老 API。模型训练的数据里，旧数据本来就比新数据多。你越理解这些“小怪兽”是怎么思考的，你的 prompting 就越好。
但他可能只玩了一天，就下结论说这东西不行。这就好比你会弹吉他，我把你放到钢琴前，你随便敲两下说“这不行，我还是回去弹吉他吧”。这是另一种构建方式，另一种思维方式。
你不知道我凌晨三点对着 Claude Code 吼过多少次。后来我慢慢搞明白了：它真的就是严格按我说的话在做事。甚至有时候你可以直接问它：你为什么这么理解？
在最近一个项目里，我感觉自己更像一个“人肉合并按钮”。社区很活跃，我几乎一直在 review PR。一开始它经常只 cherry-pick 一部分就关 PR，我被气得不行。后来我问它为什么，它会说：因为你之前这么说过，我就这么理解。
慢慢地，我学会了这门“机器语言”，调整我的表达，现在它几乎每次都能给我想要的结果。这和任何技能一样，是可以练出来的。
主持人：这和 Simon Willison 说的也很像：用得越久，越能意识到自己还能做得更好。那我们来做个更极端的假设。你现在做的 ClawdBot 很火、用户很多，但还不是像 PSPDFKit 那样直接承载大量收入的业务。如果今天 PSPDFKit 从世界上消失了，你要从零重建它，手上有现在这些 agent，你会怎么做？你会把什么交给 AI？什么一定要自己把控？团队结构会变成什么样？
Peter：今天的话，我大概用三成的人就能跑起一家公司。但前提是，这些人必须非常资深，既懂系统又敢于放手，知道哪些地方重要，哪些地方可以“vibe”一下。
这一点我在 AI 圈里其实不太常见。Twitter 上太多声音很大、但明显不知道自己在干什么的人，还有很多我觉得挺荒唐的概念。比如某些用来绕 Opus 限制的复杂流程，Codex 根本用不着。
软件开发很少是那种“列一个超长任务清单，然后全部自动执行”的问题。我看到很多人搭了一整套复杂的编排系统：自动建 ticket、agent 处理 tickets、agent 互相发邮件，最后搞出一团复杂系统。图什么？这本质上就是瀑布模型，我们早就知道它不好用。
对我来说，开发必须从一个模糊的想法开始。我甚至会故意少给 prompt，让 agent 先做点“不太对”的东西，因为可能八成都是垃圾，但那剩下的两成会给我新的启发，然后我不断迭代、塑形。
我得点它、用它、感受它。好软件需要“品味”，而这是 AI 现在最欠缺的部分。但好处是，现在做一个功能太容易了，不行就扔掉，或者重新 prompt。我的构建方式几乎总是向前的，很少回滚。就像雕塑一样：你拿着一块石头，一点点敲，慢慢地，形状就从大理石里浮现出来了。
主持人：回过头看软件工程的变化，好像有一个很明显的转折点。过去没有 AI、没有这些 agent 的时候，前期规划非常重要。你觉得现在这种变化，是因为写代码本身的成本大幅下降了吗？
Peter：我现在还是会做规划，但投入的精力没以前那么多了。因为现在试错太便宜了，你可以直接做出来看看效果，再判断“这个形态行不行”“是不是需要微调”，甚至“干脆完全换一条路”。相比过去，这一切的成本低到一个程度，让整个过程变得更像是在玩。
主持人：对，就像以前哪怕是交给一个刚毕业的新人或者实习生，一件事也得花一两天。现在不是一天两天，而是分钟级。就算是比较长的任务，最多也就是十几二十分钟。而且你还不是干等着，一个任务在跑，另外几个也在并行跑，所以试错本身几乎不算浪费。
Peter：是的。最早我在 Claude 里其实假设只有一个 agent，后来变成多个；一开始假设只有一个 provider，比如 WhatsApp，后来又变成支持多个。这种改动，如果是我自己手写代码，简直是灾难，要把逻辑贯穿整个系统重新织（weaving）一遍。但 Codex 花了大概几个小时就搞定了，这要是我自己来至少得两周。所以以前那种“前期一定要一次想对”的心态是现实所迫，现在我知道，很多东西是可以改的。
这也让技术债的处理变得轻松很多。你可以一边做，一边重新理解项目本身，一边调整你的思路。所以我其实不太相信那种“按 spec 写完，机器跑完就结束”的模式。你在真正开始构建之前，根本不可能完全知道自己要做什么。很多关键认知，都是在构建过程中才出现的，它们又会反过来影响系统最终的形态。
对我来说，这更像一个循环，你不是直线爬山而是绕着走，有时候还会偏离一下路径，但最终还是会到达山顶。
ClawdBot 来了
主持人：我们换个话题。你已经连续几个月几乎不间断地在做 ClawdBot。其实有一个想法很早就把你拉回来了，对吧？你一直想做一个“超个人化”的助理。
Peter：对，而且不是那种每天早上给你发“早安，这是你今天三件待办事项”的助理。
我想要的是一个真正理解我的东西，比如我见了一个朋友回家后它会问我：“刚刚那次见面感觉怎么样？”或者有一天提醒我：“你已经三周没给 Thomas 发消息了，我注意到他最近在城里，要不要打个招呼？”又或者它会发现某些模式，比如“你每次提到这个人语气都会变，为什么？”
那是一种极度个人化的东西，几乎是反 CRM 的存在，有点像电影《Her》，但这确实是技术发展的方向。模型对文本的理解能力非常强，上下文越大它们看到的模式就越多。即便它们本质上只是矩阵计算、没有灵魂，但很多时候给人的感觉已经完全不一样了。
当时我甚至为这个想法注册了一家公司，叫 Amantus Machina，意思是“有爱的机器”。但去年夏天我真正深入做的时候，发现模型还差一点。能跑起来也有一些惊喜，但整体上还站在我需求的边缘之外。不过这反而让我很兴奋，因为 AI 的进展太快了，我很清楚这个想法可以晚点再回来做。
还有一个判断是，我相信所有大型公司都在做个人助理。未来每个人都会有一个“最懂你的朋友”，它是台机器，了解你的一切、可以替你做事、能主动提醒你。当然，这会非常消耗算力，但凡是负担得起的人，都会想要一个。然后随着系统效率提高、芯片进步，这种能力一定会逐步下沉。这几乎是确定的趋势，而且现在已经能看到一些雏形了，比如 OpenAI 推出的一些偏生产力的功能。但现在算力还不够，把这种东西真正作为产品推出来非常难。
而且还有一个问题是，我其实更希望它跑在我自己的电脑上，数据真正属于我自己。把邮件、日历、约会软件全部交给 OpenAI 或 Anthropic，说实话，挺吓人的，很多人已经在把这些模型当作心理咨询师用了，而且效果出奇地好。它非常会倾听，能理解你的困扰，只要不是某些明显差劲的版本，它真的能提出很有洞察力的问题，哪怕只是帮你复述和反思，你都会感觉被理解了。
所以我一直有这个助理的想法，只是当时技术还没到位。与此同时，我也做了很多别的有趣的东西。在职业里绕一点“vibe 的弯路”，不断给自己造工具，优化自己的工作流，这几乎是成为一个真正工程师的必经阶段。
但“超个人化 agent”这个念头一直没消失。最近几个月，我终于开始认真把它做出来。一开始它的规模其实很小，我甚至叫它 WhatsApp Relay，本意只是通过 WhatsApp 触发我电脑上的一些操作。
后来我去摩洛哥给朋友过生日，一整天都在外面，就一直用 WhatsApp 跟这个 agent 聊天。它帮我指路、开玩笑，还能用我的身份给其他朋友发消息。那一刻我真的被震住了。最早的实现非常粗糙，我甚至没用正式的方式传图片，只是丢了个字符串，让它自己用工具去读。
有一次我随手发了一条语音，其实我根本没实现语音功能。结果过了半分钟，它居然回了我一条语音。
我问它怎么做到的，它说：你发了一个文件，我看了 headers，发现是 Ogg 格式，就用 ffmpeg 转了一下；然后我找你电脑上的语音识别工具，没装，但我发现了一个 OpenAI 的 endpoint，于是用 curl 调了接口。
那一刻我真的觉得不可思议。这就是 Opus 的能力，它太“能自己想办法”了。
我开始彻底上瘾。我让它叫我起床，它跑在伦敦的 Mac Studio 上，通过 SSH 连到我在摩洛哥的 MacBook，帮我开音乐，因为我没回应就一直把音量调大。
我还加了一个 heartbeat。这简直疯了，你每隔几分钟就给一个模型发“想点酷的事情，给我点惊喜”的 prompt，这可能是史上最贵的闹钟，但它真的“懂”了。我那段时间脚受了伤需要很早起床，却一直没回应，它的推理过程非常清楚：“Peter 没回复，他必须起床，不能再睡了。”我把这个东西给朋友们看，所有人都被吸引住了，觉得这太神奇了。我自己也一样。
后来我发到 Twitter 上，反而反响很冷，因为很多人完全看不懂这是什么。我感觉，这可能是一种全新的产品类别，大家还没有形成认知。
主持人：这有点像你当年第一次接触 iPhone 的经历。广告、电视、各种宣传你都看过了，但真正的变化，其实还是在你亲手用上它之后。
Peter：对，必须得用。我真正全力投入也就是最近这几个月，一开始它还叫 VA Relay，后来我自己都觉得这个名字不对劲了，因为功能早就不止这些了，已经接了 Telegram，还有一堆别的东西，再叫 Relay 完全不贴切。所以我给它改了个名字，叫 ClawdBot。算是个内部玩笑，我很喜欢《Doctor Who》，而且这个名字域名更好，也更能解释这个产品是什么。
与此同时，我也在悄悄搭建我的“军队”。要让这套东西真正跑起来，核心原则就是：一切都得是 CLI。所以我写了大量 CLI 控制 Google、床、灯、音乐，所有东西都变成命令行。
为什么是 CLI，不是 MCP
主持人：那为什么是 CLI？为什么不是 MCP？你怎么看 MCP 这套东西？
Peter：说实话，MCP 更像是一根拐杖。它最大的正面价值是逼着公司去开放更多 API。但整个设计思路本身是有问题的：你得在会话一开始，就把所有工具、所有函数、所有说明一次性塞进上下文，然后模型还得精确地构造一大坨调用参数，再接收一大坨返回。
问题是，模型其实特别擅长用 bash。举个例子，你要一个天气服务，模型先问“有哪些城市”，接口一次性给你几百个城市；模型没法过滤，只能全吃进去。然后你再问“给我 London 的天气”，返回温度、风速、降雨、几十个你根本不关心的字段，最后上下文里全是垃圾信息。但如果是 CLI，模型可以直接用 jq，只拿它真正需要的那一小部分。
主持人：听起来问题并不是 MCP 本身，而是所有东西都必须提前塞进上下文。如果能按需发现、按需调用，理论上是能解决的？
Peter：现在大家确实在往这个方向做，但还有一个根本问题：你没法“链式组合”。
我不能写一个脚本说：“找出所有温度超过二十五度的城市，再过滤字段，再把结果打包成一个命令。”因为 MCP 本质上都是孤立的工具，没法脚本化。
主持人：但这听起来更像是时间问题。就像现在我们做一个天气应用，本来就要选 API、比较价格、覆盖范围，然后再把不同 API 的结果串起来。这套事情在没有 AI 的年代已经解决过了。
Peter：是的，AI 时代迟早也会解决。只是形式还没定。我自己干脆写了个小工具，叫 Porter，用 TypeScript，把 MCP 转成 CLI，直接打包用。
主持人：所以你的结论是至少现在，CLI 的效率更高？
Peter：对。ClawdBot 里我其实根本没直接支持 MCP，但通过 Porter，几乎可以用任何 MCP。你甚至可以在手机上说：“用 Vercel 的 MCP 做这个事情。”它会自己去网站找 MCP、加载、按需使用。而现在很多 MCP 方案，甚至还得重启 Claude Code，用户体验非常糟，所以我就一路把自动化堆起来，工作量非常大。
Taylor 前几天还做了个视频，说“这个人疯了”，因为现在支持的东西已经多到离谱。但我自己在用 agent 的过程中只会不断冒出一个念头：我还想让它多做一点。
前段时间我干了一件“非常不理智”的事：我建了一个 Discord，把我的 agent 加了进去。有人给项目贡献了 Discord 支持，我当时其实很犹豫要不要合并，但最后还是合并了。结果就是我把一个拥有我电脑完整读写权限的 agent，扔进了一个公开的 Discord。
把复杂度隐藏到让人觉得“理所当然”
主持人：听起来完全不像是个好主意。
Peter：对，简直疯狂。但后来有人进来，看到我用它检查摄像头、做家庭自动化、帮我放音乐。我在厨房里，跟它说“看我的屏幕”，它就真的看到了。因为它有完整权限，可以点终端、替我打字、执行命令。你甚至可以对它说“做这个做那个”，它就照着屏幕操作。
我现在还在优化，理想状态当然是纯文本流，但现在这种方式已经能跑了，而且是后台默默在跑。任何体验过几分钟的人都会上瘾，项目的 star 数一周内从一百涨到三千多，我已经合并了 500 多个 PR。所以，我现在感觉自己就是个人肉 merge 按钮，整个人状态都有点散。
但这正是它的美妙之处：技术本身消失了。你只是拿着手机，像跟一个朋友聊天。这个“朋友”无所不能：能访问你的邮件、日历、文件，能给你搭网站、能做行政工作、能爬网页、能给朋友打电话，甚至能帮你打电话给商家订位。我正准备合并通话功能。
你完全不用关心算力、上下文、子 agent。它们在后台疯狂运转，只为了让你觉得“一切都很简单”。我还有一套记忆系统，当然不完美，但已经足够让人觉得像是魔法。
现在我走在路上，看到一个活动，随手给 Claude 发张照片。它不仅能告诉我这个活动的评价，还会检查我日历有没有冲突、朋友有没有提过。因为它掌握了大量上下文，给出的回答，已经完全不是那种“各自待在小盒子里的工具”能比的。
主持人：听起来你已经做出了 Apple 想让 Siri 成为、却始终没做到的东西。
Peter：老实说，我可能是 Anthropic 最好的销售。我都不知道有多少人因为 ClawdBot 去买了 200 美元的订阅，有些人甚至多开了一个账号。不是因为模型“浪费 token”，而是大家太爱用了，用得太频繁。而且由于复杂性被完全隐藏，他们根本感觉不到后台有多少子 agent 在忙。
真正难的地方在工程上：如何把复杂度隐藏到让人觉得“理所当然”。这才是魔法的来源。
主持人：但这也很有意思。你在架构上投入了这么多思考。现在这个项目已经跑了几个月，也确实爆了。在你脑子里，你是不是很清楚 ClawdBot 的结构？哪些地方该改、哪些地方要重构？你会不会开始担心内存、token、效率这些问题？
Peter：Token 更多是 prompt 和 memory 结构的问题。说到底，这就是 TypeScript 在搬 JSON。大模型给我文本，我存盘；我再把文本发到 WhatsApp、Slack、Discord、Signal、iMessage，还有更多渠道在接入。现在结构确实有点乱，但本质上只是文本在不同形态间流动。有多 provider、多 agent、有 agent loop、有配置、有大量 plumbing，但没有哪一块是真的“难”。
主持人：更多是碎片化的复杂，对吧？
Peter：对。真正的难点是：怎么让它“看起来像魔法”。我花了大量时间在安装和引导体验上。你只需要敲一行命令，我会检查你有没有 Homebrew、有没有 Node，自动安装依赖，兼容老版本；然后引导你选模型，能自动识别你已经装了什么，基本就是一路按回车。
接着你填个手机号，WhatsApp 就能直接用。我会问你要不要“给它起名字”，然后终端里会弹出一个 TUI，让你完成这一步。我还加了一个 bootstrap 阶段：模型一开始不会假装自己“有灵魂”，而是通过一轮对话慢慢理解你；然后它会把 bootstrap 文件删掉，生成 user.md、soul.md、identity 文件，记录你的偏好、价值观、内部玩笑。
这些文件不是静态的，它们会随着你们的互动不断演化。等这一切结束，你只是用 WhatsApp 跟它聊天，但你已经不再觉得自己是在跟“GPT 某个版本”说话，而是在跟一个真正的“朋友”交流。配置不需要你手改，因为 agent 能改自己。你甚至可以对它说“更新一下自己”，它就会拉最新版本、更新完再回来告诉你。
这就是我说的魔法：当复杂度被隐藏到极致，体验才会真的发生变化。
主持人：这听起来其实很像你当年做 PSPDFKit 的思路，对吧？你把 PDF 那套复杂性完全“融”掉了，用户只需要直接用，旋转、编辑，一切都很自然地发生。
Peter：对，甚至在当年的 API 层面就是这么想的。
你的工作流程，公司能套用吗
主持人：我们把话题拉回到软件工程本身。你现在做的已经是一个真实在跑的产品了，是生产软件，大家在用，你也在不断 merge PR。回头看 PSPDFKit 那样的公司，几十人、上百人的团队在维护成熟系统。基于你现在构建 ClawdBot 的方式、你用的这些工具，你觉得大型公司的软件工程方式会发生什么变化？
我明显感受到一个割裂：像你这样的个人，AI 对生产力的提升是巨大的，你完全掌控；但在团队或公司层面，尤其是有大量历史代码的情况下，一切就慢很多。不是说他们不用 AI，而是感觉两个世界之间有一道鸿沟。你当过 CEO，你怎么看？这是结构性问题，还是只是时间问题，就像每一代新技术，先被一小撮人玩明白？
Peter：我觉得，大多数公司要高效采用 AI，会非常非常难，因为这不仅是工具问题，而是要求你重新定义“公司是怎么运作的”。
你想想，在 Google 这种地方，你要么是工程师，要么是经理；你想顺手决定一下 UI 什么样？对不起，不行。要么你写代码，要么你做设计，角色边界非常清楚。
但在这个新世界里，你需要的是有完整产品视角的人，能把事情从头做到尾。这样的人数量会少得多，但要求极高：高自主性、高能力。极端一点说，公司规模可能只需要现在的三成。这听起来就很吓人了，经济上也一定会带来巨大的冲击，很多人会发现自己在这个新世界里找不到位置。
所以我一点都不意外，现有的大公司用不好 AI。他们当然也在用，但只是“用到一点”。要真正发挥作用，你得先来一次大重构，不只是代码层面的，也是组织层面的。
我现在设计代码库，已经不是为了“对我来说顺不顺手”，而是为了“对 agent 来说顺不顺手”。我优化的是模型摩擦最小、跑得最快的路径，而不一定是我个人最偏好的写法。因为最终是它在跟代码打交道，不是我。我负责的是整体结构和架构，这部分我还是按自己的方式来。
现在所有东西都要“可被解析”。PR 在我眼里，越来越像是 Prompt Request。有人提了一个 PR，我很少直接在那个 PR 上改。我会先说声谢谢，理解这个功能想干嘛，然后拉着 agent 从这个 PR 出发，把功能按我理解的方式重新设计一遍。
代码可能会复用一点，但更多是把“目标”传达清楚。有些 PR 在定位 bug 时确实很有帮助，但说实话，现在很多 PR 的整体代码质量在下降，因为大家在疯狂 Vibe Coding。可真正要把功能做对，还是得对整体设计有深刻理解，否则你连怎么引导 agent 都不知道，结果自然就会很糟。
主持人：对，没有一个完整的反馈闭环，质量肯定会出问题。
Peter：是的，对我来说，这种方式效率极高。我记得在 PSPDFKit 的时候，一个 PR 可能要做一周，评论、来回切换上下文、等 CI 四十分钟……现在不一样了。我把代码丢给模型，它会主动提醒我“这个地方可能会影响到别的模块”。我自己也会有判断，然后我们一起把它“重塑”成符合我愿景的形态，再把代码织进去。
说实话，我现在写代码用的动词都变了，“把代码织进现有结构里”，有时候甚至要先改结构，才能让它装得进去。
主持人：那如果你现在招一两个人，变成一个小团队，你觉得代码评审、CI、CD 这些东西会怎么变化？
Peter：我其实没那么在意 CI 了。
主持人：你以前在 PSPDFKit 可是非常在意这些的。
Peter：以前是，现在测试本身我还是在意的，但我用的是本地 CI。我现在有点“异端”了。
agent 会跑测试，我不想每次推个后端 API，都等十分钟 CI。
主持人：但你已经在 agent 那里等了不少时间了。
Peter：只要本地测试过了，我就 merge。偶尔 main 会出点小问题，但通常很接近正确状态。
我现在管完整流程叫 “gate”。full gate 就是 lint、build、全测试跑一遍。它就像一道门，代码出去之前必须过这关。我甚至开始用 agent 的语言了：“提交之前，跑一下 full gate。”
主持人：那如果多一个人一起做，你可能也不会做传统的 code review 了？
Peter：我们不会讨论具体代码，而是讨论架构、讨论大的决策、讨论风格。比如最近有个 PR 加了语音通话功能，现在我可以直接对 ClawdBot 说：“帮我给这家餐厅打电话，订两个位置。”这功能很酷，但它是一个很大的模块，影响面很广。
我当时就有点犹豫：这是不是开始变成臃肿软件了？然后我又回到老套路：把它做成一个 CLI。我之前有个没做完的项目正好相关，于是我打开 Codex，说：“你看看这个 PR，再看看那个项目，能不能把这个功能织进去？”对，我又用了“织”这个词。对我来说，这已经成了一种工作方式。
主持人：就这么继续往前推了。
Peter：对，就这么继续。我们能不能把这个功能织进 CLI 里？利弊分别是什么？然后他们会跟我说可以这样做、那样做，也会给我很坦诚的意见。听下来我会觉得，这个功能其实是适合放进项目里的，而且确实能带来一些如果做成外置 CLI 就拿不到的好处。但我心里还是会有警惕：我不喜欢臃肿，这会不会开始变成 bloatware？那能不能搞一个插件式架构？
还有一个用 AI 的“隐藏技巧”是：多引用别的产品。我经常直接跟 agent 说，你去看这个文件夹，我当初在那儿已经把问题解决过了；或者去看那个地方，之前的思路都在那里。这样它就能直接理解我当时是怎么想的，我也不用重新解释一遍。
因为如果我再解释一次，很可能反而会引入偏差，没法完全表达我脑子里的原始想法。
有个人叫 Shitty Coding Agent 的项目，名字虽然这么叫，其实一点也不 shitty。他里面有一套插件架构，可以通过 Git 加载代码，而且全是 TypeScript。我就跟 agent 说，“你去看看这个文件夹、那个文件夹。”结果它受到启发，直接给我设计出了一套非常炸裂的插件架构。所以本质上还是一种直觉驱动的过程。我昨晚基本上就是在干这个。
主持人：听起来，你的整个工作流已经和传统方式完全不一样了。PR 在你这里的角色变了，CI 也不一样了，测试还在，但更重要的是反馈回路。你用的是“织代码”，而不是“写代码”，讨论的是架构和品味。这对我来说是一个非常大的转变。
那我们假设接下来你要招一两个、三个工程师，把这个项目变成一个真正的团队，甚至一个业务,你会看重什么样的能力？如果现在有一个资深工程师，你会被什么样的品质吸引？你会期待他们做过什么项目，或者具备什么特质，才能适应、或者快速学会这种工作方式？
Peter：我会找那种活跃在 GitHub 上、做开源的人。更重要的是，我要感觉到他们“爱玩这个游戏”。在这个新世界里，学习方式就是不断尝试，它真的很像一个游戏：你越玩越熟练，就像学乐器一样，得一直练。
我现在能做到这么快、这么高效，连我自己都觉得有点不可思议。前几天我一天之内提交了 600 多个 commits，简直疯狂。但它是能跑的，不是那种“看起来很糟”的代码。
主持人：对，这背后是大量的技能积累。
Peter：是的，但真的很累，你必须去玩这些技术、去学习。一开始一定会很挫败，就像你第一次去健身房又累又痛，但很快你就会变强，你会感觉到工作流在加速，能明显看到进步，然后你就慢慢上瘾了。所以，一边玩，一边拼命干。
主持人：你现在投入的时间，明显比以前多了。
Peter：我从来没像现在这么拼过。就算当年我有公司，也没这么拼。不是因为我必须这么做，而是因为这件事太上瘾、太好玩了。再加上现在正好有势能，有一群人在推着我往前走。
年轻人的建议
主持人：是不是也因为你商业嗅觉很好？你能看出来什么时候有机会、什么时候窗口期打开了。
你刚才提到，现在“公开做事”这件事本身就很新颖。你也说，就算你现在想招人，其实也很难，因为真正公开、高频使用这些工具的人并不多。但可能两三年后，大家都会这么做，这个优势也就没了。还有一群人很焦虑的，是应届生、没什么经验的新人。毕竟你是在成为资深工程师之后，AI 才出现的，你有大量积累可以借力。
如果你把自己放回到那个阶段，基于你现在知道的一切，你会建议他们去做什么？是打好软件工程基本功，还是直接拥抱 agent，还是两者结合？
Peter：我会建议他们保持无限的好奇心。毫无疑问，进入这个市场一定会更难，你必须通过不断做东西来积累经验。我不觉得一定要写很多代码，但你得去接触复杂的开源项目，去读、去理解。
你现在有一台无限耐心的机器，可以把任何东西给你讲清楚，你可以不停地问：为什么要这么设计？为什么当初要这么做？慢慢建立起系统级理解。但这一切都依赖真实的好奇心，而我不觉得现在的大学真的很擅长教这个。通常，这种能力都是在痛苦中学会的。
对新人来说不会轻松，但他们也有一个优势：他们没有被“旧经验”污染。就像小孩子一样，他们会用 agent 做出我们根本想不到的事情，因为他们不知道“这事不该这么做”。而等他们这么做的时候，往往已经能跑通了。
主持人：而且他们身边的朋友也都在用这些工具。
Peter：对。前几天我有个小的菜单栏应用，用来统计 Cursor、Claude Code 这些成本，跑得有点慢。我本能反应是：好，打开 Instruments，开始点。结果他们直接在终端里把 profiling 全做了，连 Instruments 都不用开，就直接给我提了优化方案，还顺带把性能搞快了。我完全被震住了。
主持人：我觉得我们可能低估了进入这个行业的年轻人的能力和资源整合水平。很多伟大的公司创始人都非常年轻，当时经验也不多，但热情极强。对我来说，最冲击的还是你提到的这些变化：不再依赖 PR，不做传统 code review。这些东西陪伴了你十五年以上，也是 PSPDFKit 成功的重要基石。
Peter：是的，现在需要一整套新东西。哪怕现在有人给我提 PR，我更关心的其实是 prompt，而不是代码。我会让大家把 prompt 也一起提交，有些人会这么做。
我读 prompt 的时间，比读代码还多。因为那是更高信号的信息：你是怎么得到这个结果的？你问了什么问题？中间做了多少引导？这比最终代码本身更能帮我判断质量。
如果有人想要一个新功能，我甚至直接要一个“Prompt Request”。你把需求写清楚，我就能把 issue 指给 agent，让它直接去做。真正的工作，其实是在想清楚系统应该怎么运作、细节是什么。如果别人已经帮我把这些想清楚了，我基本可以直接说一句“build”，然后它就能跑。
相反，如果有人只提了一个很小的修复 PR，我反而会请他们别这么做，因为我花在 review 上的时间，可能是我直接在 Codex 里敲一句“fix”再等几分钟的十倍。现在我们已经可以有一行命令就启动。但在最近两周项目开始真正有热度之后，我干脆让大家直接用 agent 指向仓库来做配置。所以我们没有传统意义上的 Onboarding，而是 Claude Code 驱动的 Onboarding。
我的 agent 会自己 clone 仓库、读文档、写配置、帮用户把环境全搭好，甚至设置 Launch Agent，全程不需要人工步骤。这在以前完全不可想象，但现在不是优先级问题了，因为 agent 可以替你做这些事。
而且这个产品本身就是 agent 构建的，所以它的结构、命名方式，完全符合 agent 的“直觉”。模型权重里本身就编码了某些对命名和结构的偏好，它在这个项目里导航起来非常顺。所以我没有把太多精力放在 Onboarding 上。以后我当然也想做成很魔法的体验，但当下更重要的是信息传得通、系统别炸。
小彩蛋
主持人：好，那我们用几个快问快答收尾。第一个：有没有一个你会推荐的工具？不是 CLI，也不是 IDE，可以是实体设备。
Peter：我买过很多小玩意，大多数都挺一般。但有一个不贵、看起来也挺糙的东西，给了我几乎无限的快乐。它是一个用 Android 跑的电子相框，可以上传照片。它有一个邮箱，朋友可以直接给它发照片，之后就会自动显示。我家里放了好几个。技术上说，它很糟糕，动画也很简陋，但它就是不停地给我展示生活中那些快乐的瞬间。
它大概两百美元，但说实话它给我的满足感，比我新买的 iPhone 还大。我买了 iPhone 17，到现在都还没拆封，因为我一想到要换卡、迁移数据就觉得太麻烦，完全没有“非换不可”的理由。但这个小相框，真的让我很开心。
主持人：那在科技之外，有什么事情能让你充电、让你远离屏幕？
Peter：健身房，最好是和教练一起，把手机锁在柜子里。那一个小时里，我完全活在当下，没有通知，没有冲动去摸手机。有时候我甚至出门散步，把手机直接留在家里。一开始会非常恐慌，好像手机已经变成身体的一部分了，但这种感觉反而让我觉得特别爽。
参考链接：
https://www.youtube.com/watch?v=8lF7HmQ_RgY
