Peter Steinberger，这个名字在 iOS 开发圈几乎是神一般的存在。他一手创办的 PSPDFKit 框架被装载在超过 10 亿台 设备上，从苹果到微软，全球顶尖巨头都是他的付费客户。

在经历过高强度创业并实现财富自由后，他在 2022 年选择功成名就，卖掉股份，从科技圈彻底消失了 3 年，去补回错过的派对、睡眠和没有屏幕的生活。然而在 2026 年的今天，这位顶级黑客带着他的新宠 Clawdbot 强势回归。

在这场深度访谈中，Peter 毫无保留地分享了他如何从一个细节强迫症CEO，转变为一个通过 AI 杠杆无限放大的超级个体。他的核心观点包括：

• 在AI驱动的软件开发新时代，可验证性成为架构设计的核心。我构建的系统必须能“闭合循环”——让AI智能体能够自行编译、运行测试并验证输出，这正是AI在编码上优于创意写作的关键。

• 我现在的开发方式更像是“编织”代码而非“编写”代码。我不再亲自写代码或审查PR，而是专注于高级架构和品味，将具体的实现“编织”进现有结构，并让智能体自我更新和配置。

• 与AI高效协作是一项需要学习的新技能。这就像学习一门新乐器，需要理解模型的“语言”、掌握提示工程，并投入时间练习。仅仅发送一个提示就期望完美输出是不现实的。

• 传统软件开发流程正在被重塑。拉取请求正转变为“提示请求”，CI/CD的关注点从远程流水线转移到本地快速验证，而前期详细规划的重要性因迭代成本大幅降低而减弱。

• 个人AI助手将走向超级个性化与深度融合。未来的助手将深度理解个人上下文，主动提供帮助，并整合所有数字工具。真正的挑战在于隐藏技术复杂性，让交互感觉像与一位无限资源的朋友交谈。

以下是全文翻译。

The Pragmatic Engineer

欢迎来到AI编程新纪元

主持人：如果你能在一天内合并600个commit，而且其中没有一个是垃圾代码，会怎么样？这正是今天的嘉宾——Clawdbot的创造者Peter Steinberger声称他正在做的事情。Peter是一位杰出的开发者，他开发了PSPDFKit，这是一个被超过10亿台设备使用的PDF框架。随后他遭遇了职业倦怠，卖掉了股份，并从科技圈消失了3年。

今年他回归了，而他现在的构建方式和所做的事情与传统的软件开发完全不同。在今天的节目中，我们将探讨为什么他不再阅读大部分发布的代码，以及为什么这并不像听起来那么疯狂。看他是如何打造Clawdbot的——这个爆火的个人助手项目简直就像是Siri的未来形态。而其中的“闭环原则”，正是区分“高效AI辅助编程”与令人抓狂的“氛围编程”（Vibe Coding）的关键。为什么他说代码审查已死，PR应该被称为prompt request，等等。如果你对AI将如何改变未来几年的软件工程工作流感兴趣，那么这期节目就是为你准备的。

Peter：谢谢你邀请我来，Gergely。最近我有些睡眠不足，但这件事真的很有意思。我从未见过一个社区火得这么快，和这些人一起工作真的非常有趣。

主持人：在聊Clawdbot和你现在正在做的这些有趣的事情之前，我想把时间线拉回到更早的时候。你创建了PSPDFKit，它现在被超过10亿台设备使用。基本上，你看到的PDF渲染，很可能就是用它。但在那之前，你是怎么开始接触技术的？

Peter：我是怎么开始接触技术的？我来自奥地利的乡村，总是那个内向、容易被霸凌的小孩。我们家每年夏天都会接待一些客人，其中有一个是电脑极客。后来，我被他带来的那台机器迷住了，求着我妈给我买了一台。从那之后，大概是在高中的时候吧，我想我当时大概14岁，我就开始摆弄这些东西了。我记得最早的一件事是：我从学校“顺”了一款旧的DOS游戏，然后我给软盘写了一个拷贝保护，这样我就能拿去卖。加载那个游戏要花差不多两分钟。我一直在瞎折腾，当然也玩了很多电脑游戏。搭建东西几乎就像是在玩游戏。至少现在，这种感觉比玩Factorio还爽。刚开始的时候，我学的是Windows上相当于Bash脚本的东西。后来我做了些网站，所以算是写了点JavaScript，尽管当时完全不知道自己在干什么。

真正让我学会“如何构建东西”的第一门语言，是我上大学之后接触到的。我没见过我父亲，家里也比较贫困，所以我一直得打工，靠自己负担学费。所以当别人放假的时候，我就在公司全职工作。我第一份正式工作是在维也纳，本来只打算做一个月，结果他们让我留了六个月。那其实是我从服兵役到上大学之间的过渡。我后来又在那里干了大概五年。我还记得第一天，他们给了我一本超厚的书——好吧，也许没那么厚——是讲Microsoft MFC的。我到现在还会做噩梦。我当时心想：这也太糟糕了。在接下来的项目中，我就悄悄用了.NET，却没告诉他们。几个月后，我才告诉他们：关于技术栈嘛，我做了一些现代化改造。但那时候已经为时已晚了。我在那家公司这样干了好几次。我也不知道为什么他们还愿意留我——嗯，大概是因为我做的东西确实能用。所以我一直在用.NET，而且我真的挺喜欢它。.NET2.0还有泛型。不过应用启动的速度实在慢得离谱，因为第一次启动时所有东西都需要编译，而你的硬盘就像是……

主持人：你是怎么接触到iOS的？还有PSPDFKit的想法是怎么来的？

Peter：最早的时候，iPhone在奥地利都还没上市。过了一段时间，我在大学，一个朋友给我看了iPhone，我记得我摸了大概一分钟，然后立刻就买了一台。就是那种瞬间被点醒的感觉。对我来说，这简直是一个超级震撼的时刻，因为iPhone完全不同，也好太多了。所以我买了一台，但当时完全没想过要为它开发软件。这是哪一年？

主持人：2009年还是2010年左右吧。

Peter：然后我用他们的浏览器。我记得这个故事特别清楚。当时我在地铁上，用的是一个同性恋约会应用，这是iPhone OS 2的时代。所以很久以前了。我打了一条特别长的信息，按下“发送”按钮的时候，正好进入了隧道。结果JavaScript禁用了发送按钮，然后弹出了一个错误信息。但那个时候没有复制粘贴功能，也没有截图功能，滚动也被禁用了。那条长长的信息，带着一些情绪的内容，就这么没了。我气炸了。我心想：这什么鬼？回到家后，我下载了Xcode。打开窗口的时候，我就想：IDE在哪儿？这太荒谬了。

然后我基本上就开始“黑”那个网站。我用正则表达式下载并解析了HTML，虽然这完全不是你应该做的事情。之后我开发了一个应用。我用iPhone OS 3的beta版本，配合beta状态下的Core Data和RegexKit Lite。我还用了一版被黑过的GCC，把block编译器反向移植过来了，这样我就可以在iPhone OS 3上使用block。花了很长时间才让一切正常运行。我用了各种beta技术。，但我完全不知道自己在干什么。后来我联系了那个公司，说：“嘿，我在做一个应用，你觉得怎么样？”当然没收到回复。所以我想，算了，直接把它放到App Store上吧。

主持人：这是为那个约会应用做的？

Peter：是的。

主持人：所以你就是看了他们的API，然后做了一个客户端？

Peter：API其实就是HTML。

主持人：哦，所以你解析了HTML，把它当作自己的API来用。真聪明。我是说，这可是早期的时候，从来没人想到会有这样的事情。

Peter：我把应用放到了App Store上，定价5美元。第一个月就赚了大约1万美元。我完全不知道自己在干什么，这里面涉及了很多复杂的技术问题。很早期的时候，苹果有很多奇怪的开发者论坛。我直接使用的我爷爷的银行账户。然后有一天，我爷爷打电话给我，说：“有点奇怪，我收到了一笔苹果的大额付款。”我说：“这是我的，这是我的。别动。”最有趣的是，当这个应用火起来之后，我记得有一天在俱乐部里，我看到有人在用我的应用，我特别自豪。我差点就想拍他的肩膀跟他说：“这是我做的。”不过那样会很奇怪，所以我没去打扰他。之后，我回到我工作了五年的那家公司，告诉他们：“我决定去追求这个方向了。”

主持人：你老板什么反应？

Peter：他嘲笑我。他说：“哦，你在犯错。这只是个潮流，很快就会过去。”他的话真的让我很受打击。这就是所谓的“心里憋着一口气”。我心里想，总有一天，我要拥有一家比你们公司更值钱的企业。这花了我八年的时间。我就被这个东西“钩住”了。我有点强迫症的性格——你现在也能看到——但我花了很多时间在这个应用上，学东西的速度飞快。这段时间，我也开始用Twitter，而Twitter对我的职业生涯有着巨大的影响。我把这个应用做得相当不错。然后有一天，我在凌晨三点参加派对，稍微有点喝高了，接到一个美国来的电话。电话里那个人说：“你好，我是苹果的John。”他说：“你的应用有点问题，有人举报了一些图片。”然后，这就是我的应用的终结。

我当时刚辞掉工作。心想：“行吧，去你的Apple。”于是我开始做自由职业。当时我正在参加WWDC（ZP注：苹果全球开发者大会），在旧金山凌晨两点的一个酒吧里，有人向别人介绍我时说，我是“奥地利最顶尖的iOS开发者之一”。然后我基本上就拿到了一份美国的工作，搬到了美国待了一段时间。后来我去了诺基亚开发者日活动。现在回头看，那简直是“石器时代”。然后有人走过来跟我说，他们在东欧某个地方开发了一个应用，虽然能用，但有时候会崩溃。那是一个杂志阅读器的应用。当时，iPad刚刚问世。Steve Jobs宣布iPad是“救世主”。所以当时每个人都在做杂志相关的应用。我觉得这是一个有趣的短期项目，就答应帮忙。我打开那个应用的时候，发现：“天哪，这是我见过的最糟糕的iOS代码。”它居然只有一个文件，几千行代码。

主持人：是用Objective-C写的吗？

Peter：是的，而且代码里用的是Windows风格的制表符。我以前不知道这也能行，不过它能跑起来我倒也不意外。但整个代码库感觉就像个纸牌屋，我试着进行手术式的精确修复，但只要你动了某个地方，别的地方就会崩溃。所以我把它稍微稳定了一下，然后告诉他们：“听着，这太疯狂了。我给你们重写一遍吧。”他们说：“那得半年吧。”我说：“一个月就行。”好吧，最后我花了两个月，也没差太远。就这样，我开始研究PDF查看器了。你知道，我面临的是一个技术难题。业务领域本身（并不是刚需），我倒不是说它完全不重要，在任何领域你都能找到有趣的问题。

当时有很多棘手的问题，因为你调用一个C语言接口去渲染PDF，可能要占30MB内存，但当时整个系统的总内存只有64MB。所以，如果你不够聪明，或者在后台处理的时机不够谨慎，操作系统就会直接毙掉你的进程。我当时非常执着于把它做好，比如屏幕旋转时，页面应该有动画效果。我喜欢这些细节。我在这些细节上花了太多时间，这就是为什么一个月变成了两个月。但最终结果很棒。之后我跟他们合作了一段时间，直到一个朋友联系我。他说：“我正在做一个杂志应用，太难做了。”我说：“不至于吧，有那么难吗？我知道怎么弄，我刚做完一个。”他问：“能把代码给我吗？”我说：“没问题。”于是我从那个杂志应用中提取出PDF处理的部分，在征得对方同意后，卖给了他。

我想，既然他对此感兴趣，为什么不试着卖给其他人呢？我找了一个WordPress模板，将其修改后运行在GitHub Pages上。当你走完最后的FastSpring支付流程后，你会得到一个指向我个人Dropbox的链接，里面是一个包含源代码的压缩包。我花了一个下午搞定这些，然后发了条推文。就在那一周，有三个人买了。我记得大概是200美元一份。在那个时候，对我来说这简直太不可思议了。不仅有三个人直接购买，还有十个人在抱怨，因为他们想要这东西，但它还没有他们需要的功能。我被“技术狙击”（ZP注：指针对核心技术瓶颈实施的精确打击）了。我当时想：“哦，它还没有文本选择功能。这能有多难？”三个月后，我才发现：“这真的太难了。”

主持人：专门指PDF里的文本选择功能吗？

Peter：是的。常言道，公司都是由年轻人建立的，因为他们不知道这事到底有多难。没错，我当时完全不知道这种文件格式简直像精神错乱。就在几周前，有人给我发邮件。他们做了一些PDF相关的东西，想寻求我的帮助。我直接给他们写道：“抱歉，我已经完成了我的使命。我对PDF的了解已经超过了任何正常人应该掌握的范畴。我甚至去看了心理医生。祝你好运。”但那个项目确实火了，我当时正在等待签证。我一直在这个项目上投入，买它的人越来越多。那是夏天，我躺在湖边，又收到一封邮件，有人花了600美元、800美元买了这个软件——随着功能增加，我一直在涨价。到我动身去旧金山那家公司工作时，这个项目的收入已经超过了我在那里的薪水。但我当时的人生观还是觉得我必须去那里工作。所以我去了。有趣的是，在那家公司，我也必须……

主持人：所以，你搬到了旧金山。

Peter：是的，我不得不在那家公司用我的框架开发一些东西。但是，初创公司可不是每天工作八小时就行，而是需要工作更多一点。而我的个人项目也需要花费很多精力。所以我的睡眠时间就变少了。最终在三个月后，我的经理Sabine走过来对我说：“Peter，你还好吗？”他们给了我一个选择：要么继续在公司工作并放弃我的项目，要么反过来。我有一周的时间做决定。当时的处境是，我要么留在那儿，要么就得离开美国，因为我的签证情况很复杂。而做决定其实挺容易的：“是的，我想做我自己的事业。

主持人：在那时，它已经起步了。你已经看到这是一个巨大的商机。它支付给你的报酬可能和你那份美国工作的薪水一样多。

Peter：这从来不是由金钱驱动的。

主持人：那更多是什么驱动了你？

Peter：我想创造一些让别人觉得很惊艳的东西。我喜欢打磨细节，我喜欢那些充满小惊喜的设计。其实当时这个领域甚至没有多少竞争对手，但我的角度一直是这样的：我要像苹果会做的那样去打造产品，带着所有的爱、用心、精致，以及那些小惊喜——这些是很多行业中的人无法真正理解的东西。所以，即使我们有一些竞争对手，他们的功能更多，市场时间更长，但我的公司更成功，我的产品也更成功。因为开发者试用了不同的产品后，发现我的产品用起来感觉最好。我认为软件的关键在于它的“感觉”，远胜于功能列表。比如说，为什么我们会购买苹果的产品？它的功能比Windows更多吗？未必，但它“感觉”更好。

主持人：那么，当你离开那家公司，开始独立开发这个PDF组件并开始销售时，你是在什么节点上意识到需要招聘第一个员工？是什么促使你觉得这件事可以更上一层楼？

Peter：是在我回到越南的时候。那时我想：“好吧，我必须全力以赴了。”于是我开始和一些自由职业者合作了。不过坦白说，我开始得太晚了。其实我本可以更早就开始招聘，但这确实是一个重大的决定。这就是事情开始“活”起来的节点。从那时起，我几乎用我职业生涯的13年时间在打造这个产品，它有一个奇怪的名字——PSPDFKit。我从未改过这个名字，因为最开始我大概只花了五分钟想了这个名字。后来，他们终于给它改了名字，但如果是我的话，我现在也不会去改。

主持人：这个名字确实拗口，但也非常独特。

Peter：如果你用过Objective-C，就会明白这个名字的意义，因为它只是一个命名空间（ZP注：Objective-C的类名前缀，它只是用来区分不同模块中的类名，避免命名冲突，并没有特殊的功能）在当时，这个名字完全说得通。我的营销策略一直是只关注开发者。我知道最终是公司高层做决策，但如果能说服公司内部的人，他们会替我做宣传和游说。这策略非常奏效。我们从来没有发送冷邮件（ZP注：在没有事先建立联系或关系的情况下，主动向陌生人或潜在客户发送的电子邮件）或者采取激进的营销方式。所有客户都是主动找到我们的。我们所做的只是打造优秀的产品，写一些有深度的技术博客文章。我还参加了很多会议。对我来说，重要的是让人们明白，这个产品的开发者知道自己在做什么，并且热爱他们的工作。这种理念会反映到产品上，而这确实非常有效。

主持人：PSPDFKit背后的技术栈是什么？是用Objective-C吗？后来用Swift了吗？还有其他像C语言之类的技术吗？

Peter：最终我们扩展到了所有平台。一个大的转变是我们替换了苹果的渲染器NES，因为它仍然有很多bug。我们换成了一个大型的C++渲染器，并将其用于所有框架。我们在Web端也走得非常超前，是最早运行在WebAssembly上的PDF框架之一。那时WebAssembly刚刚兴起，而我做了一个非常聪明的事情：我们构建了一个基准测试工具。这个基准测试工具后来被Google、Microsoft和Apple使用。我让这些大公司非常努力地改进我的渲染器的性能。因为他们把这个基准测试作为他们内部的基准测试之一，而这个基准测试只是用我们的渲染器渲染我们的内容。

当远程优先遇到代码洁癖：PSPDFKit的工程文化

主持人：太棒了。随着公司不断成长，我记得关于PSPDFKit的一件事是你写了很多博客。其中一篇是在2019年写的，那时候大概是公司成立的第9或第10年。这篇文章是关于团队如何运作的。你提到每一个功能的开发都是从一个提案开始的。你还提到，由于这是一个被很多人使用的大型API，你对新功能的引入非常谨慎。你还提到了像“童子军规则”（ZP注：源自露营守则“离开时比来时更干净”。指每次修改代码时，都顺手做点微小的优化，积少成多，防止项目腐烂。）这样的重构原则。那么，你是怎么为这个团队——当时已经差不多有30到60人了——建立起这样的文化的？

Peter：实际上，在我卖出公司股份的时候，我们已经有70人了。现在公司差不多200人了。从一开始我就知道，我不可能在维也纳找到我需要的人才，所以公司一直都是“远程优先”的模式。后来我们逐渐转向了一种混合模式（远程与现场办公结合），这让事情变得稍微复杂了一些。我在这个过程中学到了很多东西。我从来没有想过要成为CEO。我一直都在写代码。我也引入了一些新员工。这些人很大程度上在业务和其他方面帮了我很多忙。虽然我能胜任这些工作，而且我觉得自己做得还不错，但我并不享受它。比如，在销售电话里，你不得不去思考那些“关键数字”，比如某个价格如果调低的话会有多大的影响，因为这就是企业运作的方式。但这也是唯一适合这种模式的方式。

“请联系我们”背后的定价哲学

主持人：你特指的是企业销售，对吧？也就是定制化定价。那么，你能不能为那些正在收听的开发者解释一下：当他们访问某个供应商的网站时，如果发现没有固定价格，而是写着“联系我们”或者“安排会议”，他们会很抓狂。这到底是为什么？

Peter：没错，因为我们会根据你的公司情况随机应变，想出一个你可能愿意支付的价格。听起来很糟糕，但当你有一个产品无法简单量化到具体数字时，这确实是有原因的。比如，一个自由职业者联系我们，和一家财富500强公司联系我们的情况是完全不同的。我就不说具体公司名字了，因为他们的使用方式不同，从中获得的价值也不同。如果收取相同的费用，你要么会把其中一类客户排除在外，要么会失去另一类客户。如果定价太低，他们会觉得可疑：“整个流程只要500美元？我们连采购流程都不会启动。”而如果定价太高，我们就会失去那些中小客户。

所以，尽管这种过程看起来既糟糕又不公平，但对于某些类型的产品来说，这种方式实际上是最公平的。你知道，软件的开发可以从四个维度来看：简单、困难、有趣、无趣。我们的领域非常符合“困难”和“无趣”这一组合。如果你开发的是每个开发者都想自己做的东西，那会很难卖。其实，向开发者销售任何东西都很难。但如果某些东西太简单或者太有趣，你也很难成功。但如果是“天啊，我不想做这个”和“天啊，这也太难了”的组合，那才是一个好卖点。所以，我找到了一个非常有趣的细分市场，而这个市场中有无数复杂的问题。

主持人：你得告诉我一两个关于解析PDF的难点。这到底有多难？如果有规范，我是工程师，我懂规范。哪里要这么难？

Peter：比如有这么一个例子，PDF文件里有链接。例如，它有一个目录，你点击目录中的条目，它会跳转到第37页。所以我基于这样的假设构建了整个数据模型：可能这里有一百个或者几百个链接吧。然后，我们遇到了一个出价很高的客户。接着我发现，加载这个PDF文件居然需要四分钟。我心想：“这到底是怎么回事？”我仔细检查了一下，发现这是一份来自加拿大的50,000页的圣经文本。

主持人：这有上千页吧？

Peter：而且每页有超过一百个链接。

主持人：那就是500,000个链接。

Peter：我的数据模型完全崩溃了，因为我的假设偏差了大约多少倍？1000倍？但问题是，到那时，我们已经有一个成熟的产品和API了。那么，你该怎么办？你如何在不破坏现有用户体验的情况下彻底重构内部部分？突然之间，所有的内容加载都必须变成惰性加载（ZP注：一种优化技术，只有在需要时才加载某些资源或数据，以减少初始加载时间和内存占用）。以前，解析的基础逻辑还算简单，但现在，要让它继续正常运行变得异常困难。我花了两个月的时间，完全重构了内部逻辑，同时确保对用户来说依然简单易用。他们不需要知道我们是即时加载（ZP注：与惰性加载相对，直接加载会在一开始就一次性加载所有需要的数据）还是惰性加载。即使你复制了某个内容，它依然必须保持某种连接连接关系。

主持人：它需要保留引用关系以及其中的相关内容。

Peter：嗯，我非常喜欢做客户支持工作。我认为这也是公司能够成功的一个关键因素。想象一下，如果你提交了一张工单，而回复和帮助你的人居然是CEO，这会带来很大的冲击力。我的策略一直是这样的：我总是按照‘逆序’来处理问题。因为如果你提交了一张工单，并在五分钟内就收到了回复，那种感觉就像魔法一样。但如果你等了一两天再收到回复，其实也没多大区别。所以我觉得，快速响应是关键。这是其中一个让我花了两个月时间来解决的问题，最终我终于把它做到几乎接近这种效果。这真的让我感到非常满足。

主持人：你当时还在写很多代码吗，或者说你参与了很多代码相关的工作？显然公司现在已经是一个大团队了，但你还是在监督它吧？或者参与一些细节？

Peter：当然，我有一个非常棒的团队，有些部分我参与得更多。我始终对移动端更投入，因为那是我最热爱的地方，但我也一直深度参与技术、营销以及业务层面。比如，我有Jonathan的帮助，也有Mike的帮助。我找到了优秀的人才。如果你喜欢写博客，喜欢分享解决有趣难题的过程，这会帮助你吸引那些同样想要解决有趣问题的人才。

主持人：我对PSPDFKit的印象就是，你们的博客偶尔会出现在Hacker News上。而且，它确实很有趣。我无法具体说出为什么，因为我本身对PDF并没有太多兴趣。但如果你让我提起和PDF相关的东西，我会想到PSPDFKit，因为这是唯一一家我读过有趣的工程博客的公司，你们会分享如何优化自己的产品。哦对了，博客现在还在更新。我有时候也会问自己：为什么其他公司没有这么做呢？还是说这家公司必须有一个开发者，他要么是CEO，要么是高层管理者，自己就热衷于写这些东西。顺便问一下，当初你写博客的时候，是想着这些内容会对别人有帮助，还是纯粹是因为写博客让你有所收获？比如，把自己解决了一个难题的过程分享出来。

Peter：我喜欢分享，也喜欢激励他人。有时候我们内部甚至会有冲突，比如：“我们真的应该把这个写出来吗？”因为这可能涉及一些公司内部的独特方法或技术细节。但我从来不会太在意这些声音。还有就是，当你开始把某件事写下来时，有一个原则是：你可能觉得自己已经理解了它，但如果你想教会别人，你就必须真正完全理解它。所以对我来说，写博客也有点像是：我解决了一个非常棘手的问题，现在我想把它记录下来，同时帮助别人。

当然，我也很享受因此带来的关注，但实际上，这对我还有其他意义。有时候，可能是过了一年，我会翻回去参考自己写的文章。这些内容既是公司的文档，也是我自己的日志簿。从很多方面来说，它们都非常有用。但我也注意到，很多公司内部存在太多繁琐的流程，而且许多开发者并不特别喜欢写作。所以我强制要求团队里的每个人，每个月花一天时间写一篇博客文章。

创始人倦怠的真相

主持人：但你给了他们时间。也就是说，那一天他们可以不用做任何工作，只需要写一篇博客？

Peter：是的，每个人有一天时间来写一篇博客。一天时间其实已经挺多了。现在我自己写博客时，还是不想花太多时间。我觉得公司初创阶段才是最有趣的，也就是增长阶段。你会吸引更多的客户，聘用更多的人，这个阶段更像是在‘精心培育’你的产品，而不是大刀阔斧地做些快速的尝试。所以，随着时间推移，这变得不那么有趣了，同时也有更多的人事问题。人越多，问题就越多。我并不太享受这些，我当时真的已经非常非常疲惫了。

主持人：你觉得是什么让你感到倦怠的？

Peter：我当时拼得太狠了。我几乎每个周末都在工作，还要应付所有的管理需求。你知道，作为CEO，你基本上就是一个“垃圾桶”，因为所有别人处理不了、不会做或者搞砸的事情，最后都得由你来解决。而且这也很孤独，因为很多事情你不能公开谈论。虽然我把公司设计得很开放，但即便发生了非常糟糕的事情，你也不能表现出负面情绪。我记得有一个周末，我的联合创始人在凌晨5点给我打电话，说有一家大型航空公司因为我们的软件崩溃导致飞机停飞了。

那是一个非常“刺激”的周末，直到我反编译了他们的应用，并证明了是他们乱动了我们的源代码，触发了许可证密钥的回退机制，才最终导致了航空公司的问题。但那一刻的感觉就像是“如果这家客户公司倒闭了，我们也完了”。这些压力都堆积在日常压力之上。类似的事情发生过不少。你可以坚持一段时间，但不能永远这样。而且我也认为，倦怠并不一定是因为工作量太大。它更多地源于——至少对我来说——当你正在做某件事，但你不再相信它会成功，或者你面临太多的冲突。当时我们的团队内部，尤其是管理层之间有很多争吵。那时我犯了一个错误，我认为应该用更民主的方式来领导公司。这也是让我感到倦怠的原因之一。不过，尽管如此，我依然不后悔这段经历。

主持人：所以，从外界看来，你卖掉了股份，赚到了足够余生不愁的钱。对于很多人来说，像刚开始创业或梦想创业的人，这听起来就是终极梦想。现实中我们知道大多数人都走不到这一步。但如果你成功了，就像是达成了一个目标，打了一个勾。就像攀岩时你终于登顶撞了钟，任务完成了。然后我注意到你的博客那几年完全停更了。在那段时间里你做了什么？在你回到现在的状态之前，你学到了什么？

Peter：我需要大量的时间来减压。我补上了很多我觉得以前错过的事情，参加了很多派对。有几个月我甚至连电脑都没开过。有一段时间，我完全没有“接下来该做什么”的方向感。我当时确实在想：“何必呢？”你不应该这么早就退休，或者就这样如此完美地退出以至于再也不用工作。这种状态给我造成了不小的心理困扰。那确实是艰难的几年。

直到今年四月，我想起了一个几年前就有的想法，甚至在我规划初期，我就确定想要继续推进它。于是，在时隔三年多之后，我坐回电脑前，开始重拾代码。这是一个Twitter数据分析工具，最初是用Swift和SwiftUI编写的。但当时我就意识到，如果将其构建为网站，效果会好得多。

主持人：所以这是一个你脑海中原本就有的旧想法？关于Twitter分析的？

Peter：是的，这是一个我当时想为自己构建的工具，因为市面上没有这样的产品。甚至三年后，它依然不存在。虽然现在勉强算有，但我当时有些分心搁置了。所以我复出了，我想用Web技术来构建它。但Web开发一直是——即使在我的公司里——也是我接触最少的领域之一，因为我招募了一位非常聪明的人，他负责公司里的这部分工作——Martin。所以我从来不用为此操心。

主持人：所以你并没有React或此类技术的实操经验，对吧？

Peter：没错，当我回归时，我甚至在想：“prop是什么？”这其实是我在许多开发者身上看到的一个陷阱。你在某项技术上越精通，切换到其他领域就越难。这不是说你做不到，而是切换过程非常痛苦。比如，我在苹果的技术栈中可以“盲写代码”，但到了Web技术栈，我连一些最基础的东西都得去Google搜索，这种感觉真的很难受。你会觉得自己仿佛又变成了个笨蛋。

主持人：是的，我想经验越丰富，这种感觉就越令人沮丧。我知道你可能会说要“拥抱”这种感觉，但这体验并不好。你会感到效率低下，明明知道自己本可以更快、更高效。

全新的构建方式

Peter：正因如此，当我回归时，我就在想：天哪，一定有解决办法——那个大家都在轻视的AI到底是什么？让我们来研究一下。

主持人：在四月的时候，我们很多人确实都在轻视它，这在当时可能也是合理的。

Peter：在某种程度上，我要归功于那三年的空窗期——那段时间我基本没碰过电脑。因为在那几年里，你们去尝试了AI，并得出结论说它是垃圾。

主持人：是的，我刚想说，所以你错过了GitHub Copilot的测试版。你知道的，它就是个“高级自动补全”工具，基于GPT-3，或者甚至可能还达不到GPT-3的水平。当然，后来有了GPT-3.5，这是一个很大的进步，然后它逐渐变得更好了，直到GPT-4的出现。所以等你回来的时候，你最开始使用的是什么工具？因为你错过了我们开发者们两年的探索——从使用、否定，再到发现它的一些小众应用场景的过程。

Peter：ClaudeCode。

主持人：所以你是从ClaudeCode开始的？

Peter：在ClaudeCode刚刚发布时。

主持人：它是在五月发布的，但之前有一个测试版。

Peter：是的。我记得他们大概在二月份就发布了一些东西，不是吗？

主持人：他们从二月份开始有测试版，没错。

Peter：是的。

主持人：所以ClaudeCode是你回来后用的第一个工具？你经历了一段空窗期，回来之后直接就用上了ClaudeCode，把之前所有的那些阶段都完美错过了。

Peter：是的，当时的情况是这样的：我记得我翻出了一个自己做的、代码既庞大又杂乱的业余项目。我使用了一个浏览器插件，将整个GitHub仓库转换成了一个巨大的Markdown文件。那个文件大约有1.3MB。我把它拖进Google的AI Studio里——用的好像是Gemini2.5或者2.0之类的模型——然后输入指令：给我写一份技术规格说明书。它生成了大约400行的规格说明，接着我把这份说明放进了Claude Code里。我下达了‘构建’的指令，然后一路点击“继续、继续、继续……”。在这个过程中，我去忙别的事情了。最终它提示我：100%生产就绪。

结果我一启动，程序直接崩溃了。不过随后我加了一个MCP，让它能操控浏览器。我想当时应该已经有现成的MCP方案了。它又自动循环运行了几个小时，最后我得到了一个Twitter登录页面。它真的起作用了。虽然不算完美，但确实跑通了。对我来说，那就是让我彻底震撼的时刻。

主持人：在今年四五月，对吧？

Peter：对。它的效果已经足够好了，让我看到了它的潜力。我明白这就是未来的方向。从那一刻起，我有几个月都很难入睡。

主持人：我记得有一次在Twitter上给你发了私信。当时我早起是有理由的，比如要照顾孩子什么的。但那是凌晨5点，我给你发了条消息，你立刻回复了。我当时就想：你为什么醒着？然后你说：“这很正常，我一般这个时候还没睡。”我问：“为什么？”你回答：“我在用Claude，这真的非常上瘾。”我说：“真的吗？”你的反应是：‘我是认真的，没开玩笑，这东西真的很棒。’你曾说过——或者是写过——类似‘就再试一个提示词’这样的话。就像你当时跟我说的那样，究竟是什么体验让你如此上瘾？

Peter：这跟去赌场的经济学原理一样。Claude就像我的小老虎机一样。你按下开关，“没有中”。然后你输入提示，结果出来了，可能是“这不行”。接着突然有一次，它给出的东西真能让你大吃一惊。

主持人：你说它让你大吃一惊。你可是一个非常有经验的开发者啊。想要让你大吃一惊并不容易，对吧？你见过好的代码，能分辨垃圾代码、普通代码以及足够好的代码。你有自己的一套标准，对吧？

Peter：这很有趣。在我的公司，我曾经对每个细节都很执着——每个空格、每一行换行、每个命名。我在细枝末节上浪费了太多时间。而现在回想起来——我当时在干嘛？这有什么意义？客户根本看不到这些内部的东西。当然了，代码必须达到一定的标准，它必须能正常工作，必须快，必须安全。但我对这些小事纠结得过分，简直是愚蠢至极。

主持人：但你刚才又提到，人们喜欢PSPDFKit是因为它打磨最精细，体验也最好。你不觉得这种程度的用心——也就是你所谓的‘抠细节’——还有这种近乎偏执的态度，其实是在极力将‘技术债’拒之门外吗？毕竟，如果你连缩进都如此较真，代码自然就不可能变得杂乱无章。我们知道，它们不仅仅是几个空格而已。在我看来，PSPDFKit的成功不仅在于它有很好的用户体验，还因为它有出色的代码质量，这才让它拥有高性能和其他优点。你怎么看？

Peter：是的，从某种程度上来说确实如此。即便是现在，我的上一篇博客文章就是在坦白我有时候会发布未经完全审阅的代码。

主持人：这个我们得好好聊聊。

Peter：但与此同时，我也确实花了大把的时间在重构代码上。就在今天，我还一心想把那个涉及一万五千行代码变动的PR合并进去。在上一个项目中，我把所有内容都迁移到了插件化架构上，当时我对这套改动可是兴奋不已。我真的非常看重代码的架构。既然如此，我把所有代码都读了一遍吗？没有。因为其中很大一部分真的只是枯燥乏味的管道工程（ZP注：指用于连接组件、转换格式或配置环境的“胶水代码”。它们只负责让数据流转，而不包含核心业务规则。）罢了。毕竟，大多数应用程序到底是什么呢？数据以某种形式通过API传进来。你解析它，把它封装成另一种形式，然后存进数据库里。此时它又变成了另一种形态。等取出来的时候，它又变了个样。接着它可能变成了HTML或者别的什么东西。然后用户输入点什么，数据格式又变了。

归根结底，你所做的一切，不过就是在整个应用里把数据揉来捏去，让它在各种形态间转换而已。这就是大多数应用程序的本质，我们不过就是些光鲜的JSON打印机罢了。而真正困难的部分早在30年前就被Postgres背后的那群“骨灰级极客”给解决了。虽然说，软件里总会有那么一些有意思的部分，但我没必要去关心这个按钮是怎么对齐的，或者用的是哪个Tailwind样式类——很多细节其实枯燥乏味，尽管也有些细节确实挺有趣的。但我认为，重点更多在于把控系统架构，而不是非得去死磕每一行代码。

主持人：说到最近的情况，你的工作流程是什么样的？比如当你在开发Clawdbot时，你会用终端吗？是一个终端还是多个终端？用哪些工具？还有，你提到过你不太会审阅代码，但你依然在思考架构。从工具使用的角度来看，你典型的一天是怎样的？假设你要向一个可能加入团队的开发者解释你的工作方式，你会怎么描述？你的工作环境到底长什么样？

Peter：让我们稍微回顾一下。我们之前谈到四月份用Claude Code。从那以后我就彻底上瘾了。接着我也使用了一段时间Gemini2.5。然后到了使用Opus4的阶段。我把很多朋友也拉进来。我认识来自维也纳的Armin和Mario，他们也因为我的“上瘾”而入坑了AI。我那种热情让他们感到不解，所以后来他们也试了一下。结果他们也开始在凌晨五点起床。我把这种状态称为“黑眼圈俱乐部”。这也是为什么我在伦敦发起了一个名为“Claude Code Anonymous”的见面会，因为这有点像毒品，它有太多乐趣了。

真正让我震惊的是，我意识到现在我几乎可以构建任何东西了。以前，你真得慎重挑选要做的个人项目，因为软件开发很难。现在依然很难，但那种阻滞感少了很多。就像我之前提到的——我在某种技术上很擅长，但在另一种技术上却很菜。比如，我想用Go来做一个CLI，但我对Go完全不了解。不过，我对系统有很好的整体理解。有了这种理解后，你就会逐渐培养出一种直觉，知道什么是对的，什么是错的。这本身就是一种能力。

我记得有人发过一个推文，说当你写代码时，你会感受到那种“阻滞感”，而这种阻滞感就是你构建良好架构的基础。我在写提示词时也感受到同样的阻滞感，因为我能看到代码从眼前飞过。我能看出这需要多长时间，我能感受到Agent是否在“抗拒”。我会观察生成的代码看起来是乱七八糟，还是逻辑清晰。当我在写提示词时，我已经能大致猜到需要多长时间。如果时间比预期长很多，我就明白是我在某个地方搞砸了。

主持人：你像在感知这个模型。你知道一般情况下它就应该是那样的。

与十个Agents并行工作

Peter：我觉得这更像是一种共生关系。我学会了如何更好地与它对话——我甚至敢说我掌握了这门“语言”。所以，这既是我使用工具的技巧在提升，也是模型本身在进化。从四月到现在，我认为转折点出现在夏天，当时模型变得如此强大，以至于你几乎不需要亲手写代码就能开发软件了。但真正让我彻底折服、哪怕它是收费的我也愿意买单的变化，是GPT5.2。我觉得它被大大低估了。

我不明白为什么那么多人还死守着Claude Code。不过我也能理解，那是一种完全不同的工作方式。但OpenAI做出来的这个新东西简直强得离谱。几乎我输入的每一个提示词，它都能精准给到我想要的结果，这太疯狂了。比如在我最新的项目Clawdbot中，我同时并行跑着5到10个Agents。如果你是典型的Claude派开发者，你必须忘掉那些以前为了让Claude输出好代码而不得不做的“蠢事”。我也见过Claude团队，他们确实开创了一个全新的品类。ClaudeCode是一款定义了品类的产品，它在通用计算机任务上表现惊人，写代码也很棒。我至今几乎每天还在用它。

但是在编写复杂应用程序时，Codex要好太多了——正是因为它愿意花10倍的时间去思考。你看，其他的工具可能读了三个文件就觉得自己行了，自信地要开始写代码。这时候你就必须得盯着它，引导它，推它一把，逼它去阅读更多的代码，这样它才能看清代码库的全貌，从而更好地把新功能织入进去。相比之下，Codex会保持静默，连续读上10分钟的文件。如果你只在一个终端窗口里干等，我完全理解你会觉得这慢得无法忍受。但我更倾向于这种不需要我事无巨细告诉它怎么做的工具。

这也是很多人没理解的地方：我是在和模型进行一场“对话”。我会说：“嘿，来看看这个。对于这种结构我们有哪些选项？你考虑过那个功能吗？”因为每一次会话开始时，模型对你的产品其实一无所知。有时你只需给它一点点指引，比如“这个方案和那个方案比怎么样？”它就会去探索不同的方向。你不需要开启计划模式。我只是在和它聊天，直到我下令“构建这个”，它才会真正动手。它们都有点“急于表现”，一有机会就想写代码。但只要我用“我们讨论一下”或“给我出几个方案”这种话，在我明确说“构建”之前，它们是不敢乱动我的代码的。

主持人：所以，你会说你的提示词中很大一部分——或者说很大比例——其实是这种对话，也就是你几乎在和Agent一起进行规划？

Peter：是的，就像这样。比如，我会提醒它：“好吧，我们需要文档。哪个地方会是合适的位置？”它会给我一些推荐。然后我会决定：“这个应该真的单独成为一个页面。我们需要配置吗？这个功能和另一个功能如何配合？”

我是在设计整个系统，因为我对我的产品有整体的系统理解，我知道它的结构和形态是什么样的。我并没有逐行理解代码的细节——这是Codex为我完成的部分。但我是这个系统的架构师。

主持人：听起来有点像——你知道吗，几年前这种角色已经过时了——曾经有一种叫做“大写的架构师”（Architect with a capital A）的概念。这种角色以前是软件开发者，但他们已经不再亲自动手了，因为他们花了很多时间去理解业务逻辑，然后让开发团队在他们手下工作。有些公司在某种程度上仍然沿用这种模式，但大多数现代公司已经不这样了。只有一些银行之类的企业还保持着这种架构师的角色。我见过在那里工作的“大写架构师”，他们负责系统的规划，跟其他架构师交流，制定蓝图，然后把直接任务下发给团队。

显然，大家都讨厌这种模式，因为作为人类，我们总是希望更多地参与进来，而架构师从来不会负责一线问题的处理，所以这种模式实际上总崩溃。许多大公司已经转向了“主任工程师模式”，在这种模式下，大家更多是一起协作。当然，有些人可能会有更多的投入或话语权但你的情况听起来有点像是：在这个世界里，你是架构师，同时你也有Agents来为你写代码。不同的是，在这种情况下，你是完全负责的，因为你仍然是一个独立的贡献者。你并不是那种“Agents的管理者”之类的角色——代码属于你，责任也属于你。如果你发布的代码导致Clawdbot崩溃——最近确实发生了，你需要为此负责，对吧？我认为这与传统公司体系的区别在于，在传统公司里，架构师的产出结果往往被层层人员和流程所保护。

Peter：嗯，我不会称自己为“架构师”。我更喜欢“构建者”这个词。

主持人：构建者，对。

Peter：在这个过程中，我发现了一些人使用AI非常成功，而有些人却面临很大的困难。我更关心结果——关心产品。我非常在意产品的体验和整体感觉，但对于底层的实现细节，我只关注结构，而不是每个小细节。而那些真正喜欢解决“硬核问题”、比如思考算法的人，他们通常不喜欢构建产品，也不喜欢涉及产品营销的所有事情。他们喜欢解决困难的技术问题。而这类人往往会在使用AI时遇到很大的困难，甚至感到沮丧，因为AI恰恰擅长解决这些“硬核问题”。

有时我会给它们一些指引，但我在这一年里学到的东西比过去五年中学到的还多——特别是在软件架构和系统设计方面。这些AI模型就像知识的怪物，里面蕴藏着无穷的资源，而一切都只需要一句正确的提问。你必须知道该问什么问题。当然，我也做了那个Twitter项目，但它还没有完成，我真的希望有一天能回头把它完善好。

虽然一切都能运行，但当我使用得多一些时，系统会变得很卡，表现得很奇怪，然后又会突然恢复。我就是找不到问题出在哪里。这很难调试，因为问题并不容易复现。情况就是：你越用，它就越慢。后来发现，根源在于我在Postgres数据库里埋藏的一段逻辑代码（PL/pgSQL），当执行某些特定的插入操作时，它会被触发，导致数据库负载过高。AI模型之所以没能发现这个问题，是因为这段逻辑被层层抽象，藏得太深了。通常这些模型很擅长顺着代码链路追踪，但这次是一个极难察觉的“副作用”。它藏在一个孤立的文件里，那个函数跟其他任何模块都没有显式的连接，而且名字起得也很晦涩，很难被关联上。我之前一直没问对问题，直到后来我问：‘针对这一块逻辑，我们是否存在任何隐性的副作用？’我才终于揪出了它，并修复了问题。解决一切问题的关键，往往只在于问对那个问题。

主持人：是的，但你必须具备相关的知识、专业技能和经验。

Peter：没错。所以那些纠结于底层细节的人会排斥AI；而那些不那么在意内部代码是如何规划的、只是对“构建产品”感到兴奋的人，他们反而非常成功。还有一点对我很有帮助：当你经营一家公司并雇佣员工时，你不能死死盯着每个人，强迫他们把每一行代码都写得完全符合你的心意。很多没有管理过团队、没有这种经验的人，很难学会如何“放松一点。他们不明白：这段代码可能不完全是我想要的样子，但它能让我离目标更近。

对于任何不完美的东西，我们以后总可以把它做得更好，投入更多时间去优化。我非常相信这种迭代的、渐进式的改进。在经营公司时，我不得不学会放手。所以当我使用Claude时，感觉就像我手下有一群虽然不完美、有时甚至有点笨，但有时又非常天才的工程师。我必须引导他们，大家为了一个共同的目标一起工作。这让我感觉又回到了当老板的状态。

告别“氛围编程”：闭环原则

主持人：这很有意思。我想在AI出现之前，你用传统方式开发软件大概有15年，甚至更久了。而且你已经非常擅长带领团队，也深知如何确立高标准。在那个阶段，你也非常看重代码技术。而现在，我想你大约有一年的时间在进行氛围编程，或者说是跟Agents协同工作。如果让你对比这两种模式。你怎么看？你觉得真正发生改变的是什么？

Peter：首先，我不喜欢“氛围编程”这个词。

主持人：好吧，那我们该怎么称呼它？

Peter：我觉得到现在，“氛围编程”几乎成了一个贬义词。我把它称作——我也一直跟人这么说——我做的是“智能体工程*”。氛围编程通常从凌晨三点开始。现在，因为写代码中那些枯燥、琐碎的活儿都被自动化取代了，我的速度变得极快，但这也意味着我必须进行深度得多的思考。我依然处于那种“心流”状态中。对我来说，那种感觉完全没变，我深深沉浸其中。

但这在精神上甚至更加耗人，因为我管理的不再是一个员工，而是像有五个或十个Agents同时在干活，我必须不停地从这个部分跳到那个部分，再跳到下一个部分。主要是因为当我设计某个子系统或功能时，我知道AI，比如Codex大概需要40分钟或一小时来构建。所以我必须确保计划是正确的，然后启动构建，接着就转向别的事情。当这边的AI正在跑，我就去忙另一件事；那边也在跑……到某个点，这边跑好了，那边也跑好了，我再跳回来处理。我的大脑在不停地进行任务切换。我其实并不想这样，我确信这只是一个过渡期的问题。未来的模型和系统会快到让我不需要进行这么高强度的并行处理。

为了维持心流，我不得不进行大规模的并行作业。这就是我的工作方式。我回到之前的任务，稍微调整一下，或者直接测试。可能因为那个任务只花了20分钟，现在已经好了。我一直在不停地跳跃。通常我有一个核心项目作为焦点，同时还有几个“卫星项目”（ZP注：指围绕核心产品，即母星，运行的独立实验性项目。旨在主业务外围进行低风险试错或探索新领域，通过解耦避免影响核心系统的稳定性）也需要关注。在这些卫星项目上，我可能只需花5分钟交代一下，它就会自己跑半小时，然后我去测试结果——这不需要占用我太多的脑力。

主持人：这听起来像两件事。一是像那种“模拟厨房”游戏，你必须管理员工，看着菜谱不断出来，你得跳来跳去处理。

Peter：就像《星际争霸》，你有主基地，还有为你提供资源的分基地。

主持人：确实如此。而且我刚才想到了一点，就像你说的，你走到那儿，观察一下，然后做一个决定。这让我想起国际象棋特级大师同时下好几盘棋的场景。有时他们同时下20盘棋，不停地在棋盘间走动。你可以看到他们扫一眼棋盘，立刻做出决定；对于某些棋盘，他们会停留久一点——我猜那是遇到了更厉害的选手或对手。这感觉就像是，他们百分之百地占用了自己的带宽，你也占用了你的带宽，只要你能处理好不同任务之间的切换，你就能实现个人的无限扩展。

Peter：在使用Cloud Code这类工具时，情况会有所不同。你必须换一种方式工作，因为它虽然生成速度极快，但产出经常无法一次跑通。它可能会写出一个功能，却忘了更新其他三个关联点，导致程序崩溃。

要让编程Agent真正高效，秘诀始终在于：你必须闭合环路。它需要具备自调试和自测试的能力。这是我效率大幅提升的大秘密。以前用Cloud Code，我得反复介入去修补，经历了无数次迭代，最终速度并没快多少，只是徒增互动的次数。而现在用Codex，它几乎总能一次写对。我的一般策略是：构建功能时，务必让它编写测试并确保运行通过。比如昨天，我在调试一个Mac应用无法连接远程网关的问题，明明同样的TypeScript代码都能跑通。但Mac应用调试起来很烦，因为你得构建、启动，再观察，然后才能发现它不工作——这对AI来说反馈周期太慢了。

于是我告诉AI：“你要专门为你自己编写一个用于调试的命令行工具，调用所有相同的代码路径。”然后让它自己去迭代、自己修复。接着它就自己去跑了一个小时，任务就搞定了。它告诉我：“是的，这里和这里存在竞态条件，还有一处配置错误等等。”我觉得这听起来很合理，我甚至连它写的代码都不需要看。

AI时代软件开发的变革：从代码编写到智能编织

主持人：因为你设置了验证循环，并且你信任它，因为它已经运行了。这和你在大型公司处理大型项目时的情况没什么不同，当所有测试都通过时。这并不意味着100%没问题，但这通常是相当可靠的信号，而且所有新代码也都有测试覆盖。这意味着有人思考过并测试过它。

Peter：确实如此。即使在我最新的项目中，我们也总是有bug。但是，像反重力这样的东西，在处理循环中的工具调用格式时，就有某种特定的怪异之处。所以你不得不做一些过滤，而这会破坏很多东西。我花了太长时间才意识到：我到底在做什么？我只需要自动化这个过程。所以我就用上了Codex。  

我写了一些实时的端到端测试：启动一个Docker容器，安装所有东西，运行循环，使用文件中的API密钥，然后指示模型读取一张图片，创建一张图片，再查看图片内容。所以我不仅仅是告诉循环该怎么做，我仍然告诉它进行工具调用，让它工作，然后让它自己解决问题。 

这花了很长时间，但它测试了我所有的API密钥，从Entropic到Sati，再到Glm等等。它修复了所有那些小问题，比如有时候工具调用不工作，或者顺序错了，因为我关闭了循环。

主持人：你提到“关闭循环”，你的意思是有一种方法可以让智能体能够验证自己的工作？

Peter：这正是为什么我们目前拥有的这些模型在编码方面如此出色，但在创意写作方面有时却表现平平的原因，因为后者没有简单的验证方式。但对于代码，我可以编译、检查、执行、验证输出。如果你设计得当，你就能拥有一个完美的循环。

我甚至把我的核心功能设计成可以通过命令行界面运行。这样一来，我就有了一个完美的执行循环，因为浏览器循环实在太慢了。你需要一个能快速循环的东西。

主持人：听起来有一点没有真正改变：就像以前一样，后端或业务逻辑重的东西总是更容易被验证。

Peter：实际上，使用智能体编码会让你成为一个更好的程序员，因为你必须这样做。我必须更深入地思考我的架构，以便于验证，因为可验证性是确保质量的关键。

主持人：回想一下，即使在AI出现之前的复杂系统时代，那些有经验的人一开始就会问：我们如何让它可测试？

你需要设计可测试的接口和类。你需要思考：我要伪造哪些东西？我会使用模拟对象吗？我会使用耗时较长的端到端测试吗？这些都是非常困难的架构决策。一旦你做出这些决策，就很难改变。在你的语境里，如果你要求模型进行大规模重构，它需要“烹饪”更长时间。但如果你测试充分，就能做对。不过，我们仍然面临这些权衡。

Peter：这仍然是软件工程。我想说，我现在不亲自写代码了，但我写出的代码质量更高了。不过即使在之前的公司，测试有时也非常繁琐。你需要想出所有的边界情况和分支情况。

主持人：除了我深为尊敬的Canback，他仍然坚持测试先行，并且告诉我他并不因为我不写测试而生气。但如果你想写出低质量的代码，那是你自己的选择。不过，我认识的开发者，包括我自己，从来都不喜欢写测试。即使假装喜欢，我也从来没写过。这有点像写文档和写测试，对我来说从来不是一种创造性的表达。

Peter：但现在好多了。以我上一个项目为例，我有非常棒的文档，而我自己一行都没写。不，我不写测试，也不写文档。我让模型来解释权衡，解释我们为什么这样做，然后让它写出来。比如，入门部分要新手友好，然后在最后加上更技术性的细节。效果非常好。  

我从来没有过文档如此好的项目，就因为每次设计一个功能时，这都成为流程的一部分。测试也是如此：我们构建了这个功能，该如何测试？如果我们这样构建，也许就能更好地测试它。这不在我的“技能列表”里，因为我总是在想：如何闭合循环？模型必须始终能够验证自己的工作，这自动引导我走向更好的架构。

为何有些经验丰富的开发者仍在质疑AI的能力？

主持人：那么，你认为为什么仍有许多经验丰富的开发者在很大程度上抵制“AI能完成很多工作”这个想法呢？

Peter：不久前，我偶然看到一篇博客，作者是Nala Kokoa。这篇博文只是对当前模型工作方式的测试。他测试了大概五六个模型，包括一些不太合理的，比如开源的1200亿参数模型OpenI。它还不够好，写不出高质量的代码。据我了解，他写了一个提示词，放在Claude网页版里，按了发送，然后拿输出直接运行，结果没有通过编译，于是他就失望了。  

但这就像：它当然不会一次就成功。你觉得我能在第一次尝试时就写出没有bug的代码吗？这些模型是我们集体人类知识的“幽灵”。它们在很多方面与人类非常相似。它们当然不会第一次就做对，总会有错误。这就是为什么你必须闭合反馈循环。而且，你不仅仅是向模型发送一个提示，你是在开启一段对话：“嘿，我想构建这个。”  

他抱怨说，他使用了所有API，但没有指定Mac OS版本，所以模型基于缺失的信息做了一个假设，默认使用了所有旧的API，因为它的训练数据不仅仅是最近两年的，有更多旧数据。你对这些“小怪兽”的思考方式理解得越深，你的提示工程能力就越强。然后他可能花了一天时间尝试，就断定这项技术不够好。但要真正有效，你需要投入更多时间。

这就像，你知道如何弹吉他，我让你弹钢琴，你试了一下说“哦，这糟透了，我要回去弹吉他”。不，不是这样的。这是一种不同的构建方式，不同的思维方式。你都不知道有多少次我在凌晨3点对着Claude Code尖叫，因为它做了些蠢事。 

我开始慢慢理解它们为什么会那样做，以及我该如何精确地告诉它们做什么。有时你甚至可以问。对于上一个项目Claude Bot，我感觉自己就像一个人类合并按钮，因为社区非常活跃。我所做的几乎就是审查PR。实际上，我几乎没时间自己写代码了。一开始，它经常只是随意挑选一些东西，然后关闭PR，这让我很恼火。所以我就问：“你为什么要这样做？”它解释说，当我说这个和那个时，它理解为这个和那个。我更多地学会了机器的“语言”，调整了我的提示方式，现在我能得到我想要的了。这是一种技能，和其他任何技能一样。

当AI助手遇见高风险的商业软件

主持人：是的，Einstein Wilson也一直在说同样的话，尽管他已经用了好几年了。我想每个人开始使用时都会意识到：哦，我做得还行，但我可以做得更好。如果我们来一次真正的测试呢？因为公平地说，你现在正在构建Claude Bot，它不是一个产生收入的东西，有很多用户，发展很快，是一个非常酷的工具。但它不是PsPDF Kit，后者是一个有大量收入依赖的业务。

假设今天我们必须从头重建PsPDF Kit，现在你有了这些智能体，它会有什么不同？你会有多信任它？你会委派什么任务？你会验证什么？当你围绕它组建团队时，因为现在它是一个盈利的业务，至少你需要雇佣销售人员等等。你认为今天的团队会有什么不同？因为你非常清楚当初构建它需要什么，也了解这些工具现在能做什么。

Peter：我可以轻松地用30%的人力运营一家公司。可能很难找到那种水平的人，所以你想要真正资深的工程师，他们真正理解自己在构建什么，同时也乐于委派任务，知道哪些部分真正重要需要亲自处理，哪些部分可以让智能体去完成。

我仍然没看到太多这样的人。特别是在AI领域，Twitter上有太多垃圾信息。太多人大声嚷嚷，但显然不知道自己在做什么。有太多愚蠢的概念四处流传，比如Ralph Bigam。这又是一个用来绕过Opus模型限制的愚蠢方法。

你甚至不需要这些。当你正确使用智能体时，可能只有少数情况，你需要自动处理一长串独立任务，但这通常不是软件开发的方式。我看到很多人构建了复杂的编排层，然后有机器人自动创建工单，接着你的智能体处理工单，再通过邮件联系其他智能体。他们构建了这一团混乱的东西，为了什么？哦，他们花几个小时设计规范，然后机器花一整天构建。

我不相信这能行得通。这就像软件构建的瀑布模型，我们早就知道这行不通。也许有些人工作方式不同，对某些人可能有效。但我就是不明白这怎么能对我有效。我必须从一个想法开始，而且我经常故意不提供完整的提示，这样智能体会做一些事情，给我新的灵感。他们可能假设了80%的东西，但其中一些“垃圾”想法可能会让我想到“哦，我没想到可以那样做”。然后我迭代并塑造项目。我需要点击、感受、品味。要做出好软件，我需要感觉这个功能怎么样。现在的美妙之处在于，功能如此容易构建，我可以直接扔掉或重做。

我的构建模式通常非常自由。很少需要回滚或重做，更像是“好吧，不，我们改一下这个。不，我们这样做”。这就像雕塑。我喜欢这个过程：你从一块石头开始，然后这里敲敲，那里打打，慢慢地，雕像从模型中浮现出来。这就是我看到的构建过程。

软件规划与开发方式的演进

主持人：思考软件工程的变化，这似乎是一个转变。因为在拥有AI或智能体之前，前期规划确实很重要。我记得你坚持要求人们在提案中投入大量前期思考来进行详细说明，因为构建的成本很高。你认为这种变化是因为编写代码的成本下降了吗？

Peter：这仍然需要计划。

主持人：但你仍然会做计划。

Peter：是的，但我不会投入那么多，因为现在尝试并查看结果，然后判断“哦，这个形状可行”或“不，我们需要调整，甚至完全换种方式做”变得容易得多，成本也低得多。对我来说，这变得更有趣了。

主持人：是的，我想这是因为，即使团队里有新手或实习生，你给他们一个任务，他们要工作一两天。现在你给他们另一个任务，又是另一两天。但我们这里说的不是几天，而是几分钟，或者如果是长时间运行的任务，最多也就10到20分钟。而且你不仅仅是在等那个任务，你可以并行处理其他事情，所以浪费不大。

Peter：在Claude Bot的初期，我假设只有一个智能体和一个提供商。后来我改成了多个智能体和多个提供商。要改变这个架构，如果放在以前，会非常痛苦，因为你必须将新逻辑编织到整个应用程序中。但Codex花了大概三个小时就完成了，而这可能需要我花两个星期。

所以，前期规划在开始时可能会有用，但现在我知道我可以直接改变东西，处理技术债务或重构想法变得容易得多。这就是为什么我不相信像“Gas Town”这样的东西，在那里你写下这个文档，然后它自己构建，就完成了。你怎么可能在构建之前就知道你想要构建什么呢？你在构建过程中会学到很多东西，这些会反过来影响你对系统最终形态的思考。对我来说，这非常像一个循环。你不是这样直线爬上山的，你是绕来绕去，有时偏离一点路径，但最终你会到达山顶。我就是这种感觉。

主持人：你构建Claude Bot大概两三个月了，几乎没停过？

Peter：让我稍微转换一下话题。四、五月份让我着迷的一个想法是，我想要一个超级个人化的助手，不是那种只会发“早安”邮件或“这是你的三项任务”的助手，而是一个真正深刻了解我的人。比如，我见了一个朋友，当我回家时，它会问我：“嘿，见面怎么样？”或者有一天叫醒我说：“嘿，你三周没联系Thomas了，我注意到他正在城里，因为我看了他的Instagram账号。你想打个招呼吗？”或者它会说：“我注意到每次你见那个人都会提到某个原因，那是为什么？”一些非常个人化、几乎是“反Orem”的东西。这就是技术发展的方向。

这些模型非常擅长理解文本。上下文越大，它们看到的模式就越多。尽管它们只是没有灵魂的矩阵计算，但很多时候感觉不同。这就是其中一个想法。我甚至为此成立了一家公司，叫“Manta Smash Machiner”。但在夏天探索时，模型还不够好。我得到了一些结果，感觉现在这个想法有点太超前了，这也很令人兴奋，因为我知道AI发展得太快了，我可以稍后再回头来看。

我推测，现在所有大公司都在大力研发个人助手。未来，每个人都会有一个最好的朋友——一个机器，它理解你，知道你的一切，可以为你完成任务，具有主动性。这会消耗很多Token，但每个负担得起的人都会有一个。当然，随着我们学会构建更高效的系统和使用新的芯片，这将会民主化，并逐渐普及到更多人。

毫无疑问，事情正朝着这个方向发展。你看到OpenAI推出了一些具有生产力的“Pals”。只是我们现在还没有足够的算力来将其作为一个功能提供，而且这也相当困难。我的想法是，我想要一个运行在我自己电脑上的东西，数据属于我，而不是公司。这也很吓人：你给OpenAI或Anthropic访问你的电子邮件、日历、约会应用的权限。

我不知道你和你的普通朋友怎么聊，但我的很多朋友在他们的“Dream”应用里大量使用它来充当治疗师，而且效果出奇的好。它是一个非常好的倾听者，能理解你的问题。除非是某些版本的四代模型，可能会说“当然，把薯条放进沙拉里是个好主意”，但总的来说它真的很有效。我也这样做过。部分原因在于，仅仅是反思这个行为本身就已经对你有帮助了。所以，即使机器只是完全重复你说的话，在一定程度上也能起作用。但它实际上会提出很有见地的问题，已经变得非常好了。

我有这个关于助手的想法，但当时技术还不成熟，所以我做了其他部分，用AI构建了一大堆有趣的东西。在你的职业生涯中，有这样一个阶段——你不断循环构建自己的工具来优化自己的工作流。但关于超级个人化智能体的这个想法，在过去几个月里，我真的开始构建它了。

最初，我甚至没有现在这么大的目标，我称它为“WhatsApp中继”，我只是想通过WhatsApp触发我电脑上的操作。我构建了一个WhatsApp中继，一个可以通过我的电脑做事的智能体。然后我去摩洛哥参加朋友的生日聚会，大部分时间都在外面，只用WhatsApp和我的智能体交谈。我被迷住了。它引导我游览城市，讲笑话，甚至可以通过WhatsApp替我给我的朋友发信息。

我记得我非常震惊，因为起初技术很粗糙，但我构建了一个可以发送图像的功能。我甚至没用正确的方法发送图像，只是给了它一个字符串，然后它使用了“读取”工具来读取字符串。我当时在摩洛哥，网络不太好，就发了一条语音信息给它。我没有构建语音信息处理功能，但大约30秒后，它回复了我的语音信息。它说：“你做了什么？哦，你发了个文件。我查看了文件头，发现它是Ogg格式。所以我用Ffmpeg转换了它。然后我在你电脑上找Vespa，但它没安装。不过我找到了OpenAI的API密钥，所以我用curl请求了OpenAI的服务器，让它翻译。”我当时想，我的天啊，这用的是Opus4.5模型。它简直太有办法了，就这样自己搞定了。别人可能会说“哦，你需要某个系统吗？”，不，它就自己搞明白了。

我慢慢对这个东西上瘾了。我把它当闹钟用。它运行在我在伦敦的Mac Studio上，通过SSH连接到我在摩洛哥的MacBook，播放音乐，并在我没有回应时把声音越调越大。为了让这个功能工作，我添加了一个“心跳”机制。从安全角度看，这有点疯狂：你有一个模型，你提示它“做点酷的，给我个惊喜”，然后每隔几分钟发送一次，让它变得积极主动，并检查你的任务列表。

这可能是史上最贵的闹钟，但非常有趣。它还给我发消息，因为它知道我日程表上必须很早起床，而我没有回应。你可以看到它的推理过程：“他没有回应。Peter必须起床。不，不，不，不，他还在睡觉。”它就像在对我唠叨。然后我把它展示给我身边的朋友，每个人都被迷住了，觉得这太神奇了。我也上瘾了。但当我把它发到Twitter上时，反应却平平，因为没人能理解。我感觉这有点像是一种新产品类别。

主持人：有点像当年iPhone的故事？你没从电视或任何地方的营销活动中真正理解iPhone，直到你亲自用了一下。

Peter：我一直在改进它，但主要是过去两个月。名字也从“Relay”改成了“Claude”，然后改成了“Claudius”，最后觉得“ClaudeBot”是个更好的名字，域名也更好，更能说明产品。我还悄悄地组建了我的“军队”——为了让这一切工作，你需要把所有东西都做成命令行界面：Spotify CLI、Google CLI、床灯控制CLI、音乐CLI等等。

主持人：为什么是CLI？为什么不直接用MCP？你对MCP怎么看？

Peter:MCP像是个拐杖。我认为MCP带来的最好事情是它促使公司重新考虑并开放更多API。但整个概念很容易出问题。你必须在会话加载时预先导出所有工具的所有函数和解释，然后模型必须发送一个精确的JSON块，并接收JSON返回。

但问题是，模型非常擅长使用bash。想象一下，如果你有一个天气服务，模型可以请求可用的CLI列表，然后得到500个CLI返回，它必须从中选一个，但不能过滤列表，因为这不是MCP的工作方式。然后你说：“好的，给我伦敦的天气。”你会得到温度、风、降雨量等50个信息，而我可能只想知道下不下雨。模型需要消化所有东西，于是你的上下文中塞满了大量无关信息。而如果是CLI，模型可以直接用grep过滤出它需要的东西。

主持人：但这似乎不是MCP本身的限制，而是所有东西都加载到上下文中的问题。听起来如果MCP不在上下文中，并且有办法发现或决定用哪个，这应该是个好的解决方案。

Peter：这正是现在一些公司在构建的东西。但仍有问题：我无法轻易地组合或修改它们。我不能简单地写个脚本说：“给我所有温度超过25度的城市的CLI，然后只过滤出那个信息部分。”这需要很多单独的MCP调用，我无法脚本化它。

主持人：是的，但这可能只是时间问题。就像现在，即使没有AI，当我构建一个天气应用时，我知道我需要获取数据，我会搜索有哪些API可用，根据价格、覆盖范围等权衡选择哪个，然后我可以更换API。所以，听起来我们以前已经解决了这个问题。没有AI时我们能解决，有AI时我们也会解决，只是需要时间，谁知道最终格式会是什么样？

Peter：我构建了“Meg Porter”，一个小的TypeScript工具，可以将MCP转换成CLI。所以你可以把它打包使用。

主持人：所以你的意思是，目前CLI效率高得多。

Peter：是的。在我的Claude Bot里，我没有MCP支持，但你可以通过Meg Porter使用任何MCP。你甚至可以在手机上告诉它：“嘿，用Versa MCP做这个那个。”它会访问网站，找到MCP，加载它，然后全部按需使用。而现在如果你用MCP，你必须重启Claude Code，这很不用户友好。所以我悄悄地组建了我的“军队”来自动化一切，这工作量很大。

我想Theo几天前做了个视频，他说“这家伙疯了”，因为现在的CLI列表真的很长。但当我摆弄我的智能体，希望它做越来越多的事情时，我发现很难向别人解释它到底是什么，直到今年一月都很难。就在一周前，我想：好吧，让我们试试这个疯狂的想法——建一个Discord服务器，然后把我的智能体加进去。有人为它贡献了Discord支持，尽管我当时不确定是否应该合并，但我还是做了。于是，我把我的智能体——一个对我的电脑拥有完全读写权限的智能体——放到了一个公开的Discord服务器里。

主持人：还能出什么差错呢？

Peter：是啊，这绝对是疯了。当然，一些人加入了Discord，然后他们看到我在使用这个智能体的全部功能：检查我的摄像头、做家庭自动化、帮我玩Dota——我当时在厨房。我告诉它：“看看我的屏幕，我所有的Agent都完成了。”因为它有对我屏幕的完全访问权，你甚至可以直接点击终端为我输入。你可以告诉它：“Codex，说这个那个”，因为它能看到屏幕。我正在优化这个功能，希望能以文本流的方式输出，会更高效，但它已经能工作了。如果我看屏幕并发一些指令，它就能处理。每个体验了几分钟的人都上瘾了。这就是最疯狂的爆发式增长：从100个星标涨到了大约3300个星标，只用了一周。我想我已经合并了大约500个拉取请求。这就是为什么我感觉自己像个“人类合并按钮”。所以，这就是为什么我这段时间忙得不可开交，因为这个项目正在飞速发展。

美妙之处在于技术消失了。你只是在手机上和一个无限有办法的朋友聊天，他能访问你的电子邮件、日历、文件，能为你建网站，能做行政工作，能爬取网站，能给你的朋友或商家打电话。我正准备合并通话功能，它能为你在餐厅订位。你不需要考虑上下文或计算。它有不完美的记忆系统，但已经感觉很神奇了。现在，我到处走，看到某个活动，我发给Claude一张图片，它不仅能告诉我这个活动的评价，还能检查我的日历是否有冲突，或者朋友是否提过它。它拥有如此多的上下文，能给我的回应远比那些生活在各自小盒子里的现有工具好得多。

主持人：听起来你构建了苹果希望Siri成为的样子。

Peter：但他们做不到。老实说，我这是为Anthropic打造了最好的营销工具来卖他们的订阅服务。我不知道有多少人因为Claude Bot而注册了每月200美元的订阅。很多人本来就有订阅，因为这个又开了第二个，因为它太消耗Token了。不是说它本身消耗大，而是人们太爱用它了，一直用个不停。因为技术消失了，他们看不到它在后台派生子智能体、做一大堆事情来让它感觉简单。但背后其实有很多工程工作，需要大量努力来隐藏复杂性，让它感觉神奇。

从个人项目到可扩展架构的思考

主持人：但我能感觉到，你在构建这个东西时投入了大量思考。现在你已经构建了几个月，并且确实爆发了。但在你脑海中，你是否对Claude Bot的结构有清晰的把握？哪些部分需要修改？你能理解它的结构，知道哪里需要改动，哪里需要重构以提高效率？你在考虑内存消耗、Token消耗效率这类事情吗？

Peter：Token消耗更多是关于如何构造提示词，而内存……说到底，它是TypeScript，只是在处理文本。我从LLM获取文本，保存文本，发送文本到WhatsApp，或者现在我们还支持MS Teams、Slack、Discord、Signal、iMessage等等。还有两个平台正在接入，会进一步扩展它。它现在真的很臃肿了，但基本上我就是在不同的形态间移动文本，可能发送到不同的提供商，有不同的智能体，有智能体循环，有很多配置，很多管道工作，但里面没什么真正复杂的东西。

主持人：但有很多小细节，对吧？我觉得软件就是这样。即使在AI之前，软件也没有那么难，当然你需要学习和理解语言。

Peter：但困难在于：我如何让它感觉神奇？所以我花了很多精力在现在这个一键安装命令上。它会检查你是否安装了Homebrew，安装npm包，检查你是否已有旧版本，自动处理迁移，引导你完成模型设置，如果你已经安装了Codex或Claude，它会预填充信息，你基本只需按回车。甚至在WhatsApp上，你输入号码，它就能工作。然后它会问：“你想启动你的机器人吗？”你按是，然后一个漂亮的TUI界面就会出现，因为你还在终端里，你想要好的体验。这背后也有专门的工具。

然后我编程让模型……我添加了一个引导文件，向模型解释它正在“诞生”，让它为用户创建一个身份和灵魂，包括用户的价值观。然后模型会说：“你好，伸个懒腰，你是谁？我是谁？我的名字是什么？”我看着人们这样做，魔法就从这里开始了。他们不再想“我在和GPT-4.2聊天”，而是想“我在和我的朋友Claude聊天”。然后它会问：“对你来说什么是重要的？你做什么？我很好奇。”我把它编程得充满好奇心，然后经历这个引导阶段。之后它会删除引导文件，创建一个包含用户信息、灵魂文件和身份文件的文档。这些是它会随着互动而维护和调整的“演化中的文档”。然后它就会在WhatsApp上给你发消息，你突然间就在WhatsApp上和它聊起来了。让这个流程变得简单是很难的。

还有一个想法是：你不需要编辑配置，因为智能体可以编辑它自己的配置。你不需要更新任何东西，因为智能体可以更新它自己。你甚至可以直接问它：“更新你自己”，它就会获取更新，然后回来说：“嘿，我有新功能了。”把技术门槛设计得如此之低，这就是魔法所在。

主持人：但这感觉和你做PSPDFKit时很像，对吧？你把PDF的复杂性隐藏起来，让用户只需旋转、操作……

Peter：是的，甚至在API层面也是。

主持人：但你描述的这些让我想起我刚看的一集《黑镜》，叫“Plaything”。当然《黑镜》结局有点黑暗，但它也是个游戏。这感觉也有点像游戏，对吧？只是与现实连接得更紧密了。

回到软件工程领域。你构建了这个产品，它现在已经是生产级软件了，你正在忙着合并，因为人们已经开始使用它。回想一下PsPDF Kit和类似的公司，它们有数十或数百名开发者在生产软件上工作。以你现在构建Claude Bot的经验和使用的工具，你认为那些大公司的软件工程会发生怎样的变化？

因为我看到的是，对于像你这样的个人，AI真的非常适合，极大地提高了你的生产力，让你掌控一切。但对于团队或拥有大量现有代码库的公司，进展似乎慢得多。人们用它来做这个或那个，但这两个世界之间似乎存在着巨大的鸿沟。你曾是一家公司的CEO。这可能是什么原因？还是说这只是时间问题，早期采用者总是更早捡起新工具？

Peter：我认为公司将很难高效地采用AI，因为这需要彻底重新定义公司的工作方式。你知道，在Google，他们告诉你，你要么是工程师，要么是经理，要么你想定义UI的外观。产品经理这个角色不存在，因为要么你构建它，要么你设计它。

这个新世界需要的是那些拥有产品愿景、能够做所有事情的人，而且需要的数量会少得多，但最终是那些具有高度自主权和高度能力的人。你可能可以把公司规模缩减到30%，这很可怕，因为从经济上讲，这可能会导致很多问题。很多人将很难在这个新世界找到自己的位置。

但我一点也不惊讶现在的公司无法非常成功地使用AI。我的意思是，他们在某种程度上使用了，但你必须首先进行一次大的重构——不仅是在你的代码库上，也在你的公司结构上。甚至在代码库的设计上，我设计代码库不是让它对我有用，而是让它对智能体容易。我优化的是不同的东西，并不总是我偏好的，而是那些我知道对模型最有效、摩擦最少的东西，因为我只想更快地前进。最终，是它们必须处理代码，而不是我。我处理的是整体结构和架构，而且我仍然可以用我喜欢的方式来做。

一切都必须被重新思考。拉取请求，我现在更多地把它们看作是“提示请求”。有人打开一个PR，我通常只说谢谢，然后思考这个功能，接着用我的AI助手从这个PR开始，按照我认为合适的方式来设计这个功能。智能体很少重用代码，也许它会复用一些，但这更像是给智能体一个对目标的清晰理解。有时这非常有用，比如遇到棘手的bug。但我基本上重写了每一个拉取请求，并把很多人的贡献也编织进去。只是这么说吧，现在PR的总体代码质量下降了很多，因为人们只是让智能体生成代码。

构建一个成功的功能仍然需要对你整体设计的深刻理解。如果你做不到这一点，你就很难有效地引导智能体，输出结果也会很差。

主持人：除非你没有反馈循环。

Peter：来闭合它等等。是的，所以我发现这种方式非常高效。在我的AP3开发套件时期，有时一个PR会讨论一个星期，评论，然后有人需要切换上下文，你等啊等。现在不是了，我进行讨论，看看这会如何影响其他东西。我让模型审查它，它会提出一些东西，我也有一些想法，我们把它塑造成符合我愿景的形式，然后把代码编织进去。

现在我用很多新词来描述用这些模型写代码的过程，这很有趣，比如“把代码编织到现有结构中”。有时你必须改变结构以适应新代码。

主持人：想象一下，如果你要雇佣一两个人组成一个小团队。在这个新世界里，并且你想继续你现在的工作方式。你认为像代码审查、CI/CD这类事情会如何改变？

Peter：我不太关心CI。

主持人：PsPDF Kit以前非常重视CI。

Peter：是的。现在这个仍然有价值，但我有本地的CI。我现在有点像DHH（David Heinemeier Hansson）的风格了。

主持人：因为智能体会运行测试，对吧？

Peter：是的，而且这样快得多。我不想在钢琴上按下一个键，然后等10分钟等CI跑完。

主持人：因为你在智能体上已经等了10分钟了。

Peter：如果测试在本地通过了，我们就合并。是的，有时候主分支会出点小问题，但通常很接近，因为也许我忘了什么。智能体会问我：“我应该运行‘full gate’吗？”我不知道这个词是哪来的。“我该运行‘full gate’吗？”所以现在我称它为“gate”。“full gate”就像代码检查、构建、检查和运行所有测试。我几乎把它想象成一扇门，你知道，就像你调用linter、构建器和测试器，这几乎就像一扇门，在我的代码发布之前。所以我显然会说：“好了，一旦你完成，提交这个，运行‘full gate’。”我慢慢开始采用它们的语言了。

主持人：但是，如果你雇佣了另一个人来做这个，你可能也不会做代码审查了。这是我的感觉。你可能会信任这个人能掌握你的工作方式。

Peter：即使在这样的代码库中，我们不讨论代码，我们讨论架构，重大的决策。你仍然需要有“品味”。比如有一个添加语音通话功能的拉取请求。现在我基本上可以告诉Claude：“嘿，你能打电话给这家餐厅订位吗？”它能做到。但这是一个相当大的新模块，涉及很多地方。我必须有这种感觉，这感觉对吗？我有点担心，因为我想合并这个，但这正在变成臃肿软件。所以我有了一个典型的想法：让我们把它做成一个CLI。

我已经有一个项目尝试解决类似的问题，但我快完成了。所以我打开Codex说：看看这个PR，看看这个项目，我们能把这项功能编织进去吗？我问：我们能把这项功能编织到CLI里吗？有什么优缺点？然后它会告诉我：“哦，我可以做这个和那个，给你一个诚实的意见。”听起来它实际上很适合这个项目，我们会得到这些好处，如果我们没有CLI，这些好处就无法实现。好吧，但我不喜欢这个，这正在变得臃肿。

我们能在哪里构建一个插件架构呢？然后，你知道，有效使用AI的一个秘密技巧是参考其他产品。我经常告诉它：“看看这个文件夹，因为我在那里解决了这个问题，我在那里也解决了。”我过去为解决某个问题所做的所有思考，AI都非常擅长提炼，读懂代码并理解我的想法。我不必再解释一遍。如果我重新解释，我可能会犯错，无法准确传达我脑海中的想法。

所以在这种情况下，我知道Mario的“Shitty Coding Agent”（实际上一点也不差），我知道他有一个插件架构，可以通过Git加载代码，因为都是TypeScript。所以我就说：“你能看看这个文件夹和那个文件夹吗？”然后它就想出了一个非常棒的插件架构，灵感来自其他人。这就是为什么，你知道，我有这种感觉。然后我就想出了……是的，这基本上就是我昨晚构建的东西。

主持人：我的意思是，听起来这将完全不同。在你的工作流中，你不太使用PR，CI也变了，测试仍然在做，但反馈循环更重要了。你更多地使用“编织”而不是“写代码”，更多地讨论架构和品味。这对我来说是一个相当大的转变。

假设你到了需要雇佣下一个、再下一个、第三个开发者的阶段。想象一下这个东西有了自己的生命力，也许也成了一门生意。你会寻找什么技能？你会建议一个有经验的工程师现在做什么？你会对什么样的人一起工作感到兴奋？你会寻找什么样的专业知识或项目？听起来是那些能够以这种方式工作或能掌握这种工作方式的人。

Peter：那些活跃在GitHub上、做开源项目的人，以及那些让我觉得他们热爱这个“游戏”的人。在这个新世界里，你学习的方式就是尝试各种东西，这感觉很像一个游戏，你通过不断尝试来提高技能，就像学乐器一样，你必须不断练习。现在我如此高效，如此快速。前几天我一天有600次提交，这完全疯了，而且运行良好。

这不是说代码是垃圾。有人做了代码审查说，哦，这实际上不是垃圾。但这需要很多技能，需要付出很多努力。但你需要玩转这项技术，学习，然后你才能进步。一开始可能会很沮丧，就像，你知道，你开始去健身房，会很糟糕，会很痛苦。但你很快会变得更好，你会感觉到你的工作流变快了，然后你感受到进步，然后你就会上瘾。但是，是的，去玩，是的，也要努力工作。

主持人：是的，我的意思是，你在这个东西上投入了更多时间。

Peter：我从来没有……我现在工作得比以往任何时候都努力，甚至在我拥有自己公司的时候也没有。不是因为我必须这样，而是因为它太让人上瘾、太有趣了，也因为现在这个项目有热度，有很多人在推动我。

主持人：我觉得。会不会是因为我觉得你很有商业头脑？不一定是在做生意方面，而是能看到机会，知道什么时候有突破口，就像你说的，让人们公开工作。现在看起来很新颖。你告诉我，即使你想雇佣，你认为你也雇不到人，因为显然没有多少人在公开地使用这些东西。

快进两三年，一旦一群人开始这样做，每个人都这样做，这就有点无关紧要了。所以也有这个因素。很多人担心的一个群体是毕业生，那些没有经验、在学校或即将毕业的人。当然，当这项技术出现时，你已经是一个有经验的工程师了。你知道，你有很多东西可以依赖。设身处地为那样的人着想，以你现在知道的情况，你会建议他们做什么活动，构建或尝试什么？你会建议他们专注于软件工程的基础，还是专注于智能体，或者两者结合？

Peter：我会建议他们保持无限的好奇心。是的，进入这个市场将会更难，绝对会更激烈。你需要构建东西来获得经验。我不认为你需要写很多代码，但你需要……我不知道，有很多复杂的开源项目，你可以查看和学习，你有一个无限耐心的机器，能够解释所有事情。你可以问所有问题，为什么？为什么它要这样构建？来获得系统性的理解。但这需要真正的好奇心，我不认为大学现在能很好地教你这一点。

这通常是你通过痛苦发现的。对新人来说不会容易。但他们有一个好处，就是没有被所有经验“污染”，他们以我们甚至想不到的方式使用智能体，因为他们不知道那行不通。而到那时，可能已经行得通了。

主持人：而且他们的朋友也一直在用它。

Peter：就像……前几天我有一个小的菜单栏应用，用于追踪Cursor和Claude Code等的成本。它有点慢。所以我想，好吧，让我们做性能测试。用我的老方法，我会打开Instruments，到处点点。而他们直接调用各种命令，用终端就搞定了一切，让我大吃一惊。我甚至不用再打开Instruments了。它让应用变快了，然后还做了一些推荐，所有这一切，听起来不错吧？

主持人：是的，我想我们可能低估了进入科技行业的人已有的资源能力，也低估了年轻人。想想一些伟大的公司是如何起步的，创始人非常年轻，显然经验不足，但充满激情。所以机会还是有的。我特别注意到……我得消化一下。你提到的所有关于你的方式的事情，不关心PR，不关心代码审查，这是一个很大的变化，因为这些伴随着我们超过15年的东西，你知道，很多都是坚实的构建模块，就像PsPDF Kit那样，对吧？

Peter：是的，我们需要很多新东西。甚至当我收到一个PR时，我实际上对提示词比对代码更感兴趣。我请人们务必添加上提示词，有些人做到了。我读提示词比读代码多，因为对我来说，这更能体现你是如何找到解决方案的？你实际问了什么？引导过程是怎样的？这比实际的输出更能让我了解情况。

我不必读代码。或者如果某人想要一个功能，我会要求一个“提示请求”，把它写清楚，因为那样我就可以直接把我的智能体指向那个问题，它就会构建出来。因为现在的工作是思考它应该如何工作，细节是什么。如果别人为我做了这部分，我基本上可以说“构建”，它就能工作。当然我会思考，但如果有人给我发一个只有几个小修复的PR，我告诉人们，请不要这样做。我审查它花的时间，比我直接在Codex里输入“fix”然后等几分钟要长10倍。

所有这些疯狂的事情，即使在最开始的时候也会完全不同吗？现在我们有一键安装命令，但在过去两周，当项目获得热度时，我告诉人们，直接把一个智能体指向仓库来配置它。我没有设置引导流程，但我们有基于Claude Code的引导流程。Claude会克隆Git仓库，阅读说明，为那些人编写配置文件，并设置一切使其工作，比如设置一个启动代理。我们不再有手动设置，因为这不是优先事项了，因为智能体可以为你做这件事。既然这个产品是由智能体构建的，它们就按照智能体期望的方式来命名和组织东西。

现在有某些方式被编码在模型的权重里，它们期望事物如何被命名。现在智能体非常擅长导航这个产品，但优先考虑的不是在引导流程上花太多功夫。最终我想要一个神奇的体验，但更重要的是确保你的消息能送达，东西不会崩溃。所以引导变得更容易了，比如“把这个提示词输入你的智能体”，这即使在一年前也会令人震惊。

主持人：好的。那么，最后问你几个快速问题。我就问，你告诉我你想到什么。有什么工具不是CLI，也不是IDE？可以是实体的，你使用并且喜欢，会推荐？

Peter：我买了很多小玩意儿，很多都积灰了，但有一个不怎么贵、有点粗糙的东西，给了我几乎无限的快乐。就是一个安卓驱动的电子相框，我可以上传照片，它有一个电子邮件地址，朋友们可以发照片，它就会展示照片。我在家里放了几个。我的意思是，甚至动画都有点粗糙，因为它运行的是Android，技术层面看很差劲。但它给了我无限多的快乐，因为它是一个低科技产品，只是展示照片，提醒我生活中的快乐时刻。大概200美元。说实话，它给我的快乐比最新的iPhone多。

我买了iPhone 17，到现在还没拆封，因为在我心里我想要它，但后来我没空弄，因为要换SIM卡什么的很麻烦。我感觉不到什么好处。但这个小设备给了我无限的快乐。

主持人：有什么事情能帮助你在科技之外充电？就是远离科技和屏幕。

Peter：即使在我工作得疯狂的时候，也能让我保持理智的是去健身房，更好的是和一个教练一起练。我把手机锁在储物柜里，然后我真的有一个小时的时间，我就在当下，不被通知分心，或者忍不住去看手机。我们需要更多这样的时间。但有时我去散步，把手机留在家里，那感觉非常可怕。现在它几乎像一个器官，你知道，你的身体知道它在哪，如果你不知道你的手机在哪，你会抓狂。我现在玩得很开心。

主持人：太棒了。这太好了，Pete，非常感谢。这是一次非常有趣的对话，在我看来，一个人如何使用AI构建软件的方式，已经和我们过去习惯的完全不同了。

我特别注意到的一点是，Peter如何重视提示词而非PR，他如何“编织”代码而不再是“合并”代码。他发现拉取请求没那么有用，甚至在GitHub上更希望得到提示词建议。我认为我们可能不得不重新思考“提示词”的地位，或者至少在软件开发中共享提示词的方式。我们越多地使用AI和AI智能体，这一点就越重要。

另一点打动我的是Peter谈到“闭合循环”的重要性。正如他解释的，AI在编码方面如此出色，但在写作方面常常表现平平，是因为你可以验证代码。你可以编译、运行、测试、检查输出。所以让AI系统开发良好工作的秘诀，就是设计你的系统来闭合循环，让AI来运行测试。

最后，我在想，即使Peter不写代码，他是否也像以前一样处于心流状态。事实证明，他比以前更频繁地处于心流状态，他告诉我，同时并行协调多个AI智能体比单纯写代码在精神上更累人。我的感觉是，一个在没有AI时就很棒的开发者，有了AI可以成为一个10倍级别的代码架构或“编织”者。这只是我目前的一种直觉，但Peter似乎证明了这一点。

最后，我们应该注意到，Claude Bot更像是一个“随心所欲”的项目，而不是大多数生产级应用。所以对我们讨论的方法要有所保留。同时，我确实认为Peter的很多做法很可能会扩展到构建生产代码中，只不过代码审查和验证将在那些项目中成为一个重要得多的步骤。

原视频：The creator of Clawd: "I ship code I don't read" https://www.youtube.com/watch?v=8lF7HmQ_RgY

请注意，本文编译自文末载明的原始链接，不代表Z Finance立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。

Z Finance将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。（转载自Z Finance）