仅用不到一周的时间，10 万颗 Star，GitHub 热榜被它牢牢占据，Fork 数迅速攀升到 2.2 万，增长曲线甚至跑赢了 Linux 内核、Vue、React 这样的经典项目。

这个项目如今叫 OpenClaw，在不少开发者口中，它还有一个更早、更响亮的名字—— Clawdbot。最近，它几乎在一夜之间刷遍了技术社区，成为最炙手可热的个人 AI 助理项目之一。

但在走红之前，它的名字并不固定。最早，这只是一个叫 WhatsApp Relay 的小实验；后来更名为 Clawdbot，并在几乎没有任何预热的情况下突然爆火。

真正出圈之后，麻烦才接踵而至，因为 Anthropic 的投诉侵权，项目被迫改名，从 Clawdbot 变成了 Moltbot。结果名字一度拗口到连作者自己都不满意，最终才定格为 OpenClaw。

与此闪亮登场的还有这个让人一眼就记住的“龙虾”Logo。

如果只看这些数字和声量，不少网友恐怕很容易误以为这背后是一支配置齐全的创业团队，甚至是某家大厂在暗中推动。

但事实恰恰相反： 这个在短时间内席卷开发者社区的项目，几乎完全出自一人之手。而更令人意外的是—— 两个月前，它还只是项目作者利用周末时间，在家里随手拼凑出来的个人项目。

其背后主导的开发的程序员叫 Peter Steinberger。

事实上，Peter Steinberger 并非“横空出世”的新面孔。他曾一手创办并将 PSPDFKit 打造成一款面向全球开发者的专业 PDF 开发工具套件，被广泛用于移动端和企业级应用中。

但后来，他“疲惫”了之后，卖掉了股份，从科技圈隐退了三年。直到最近，他才重新回到一线开发——但方式已经彻底不同。

这一次，在 Claude、Codex 等大模型工具加持下，他开发了如今爆红的 OpenClaw。仅在 1 月份，Peter Steinberger 一个人就提交了超 600 次代码。

那么问题来了：当一个人，真的开始“像一个团队那样”写代码，软件开发会变成什么样？

日前，软件工程师兼作家 Gergely Orosz 与 Peter Steinberger 进行了一次长达两个小时的深度专访。这也是 Clawdbot 之父首次系统性地对外讲述自己的工作方式，包括：

• 为什么他已经不再阅读自己发布的大部分代码，以及为什么这件事并没有听起来那么疯狂；

• 他是如何构建出爆火的个人助理项目 OpenClaw（原名 Clawdbot、Moltbot），以及为何它被许多人视作 Siri 未来形态的雏形；

• 为什么在他看来，传统意义上的代码审查已经过时，Pull Request 更准确的名字，或许应该叫“Prompt Request”。

这不是一场关于“AI 会不会取代程序员”的抽象讨论，而是一份来自一线的真实答案。本文基于本次访谈内容，由 CSDN 整理，希望为读者带来一些关于 AI 与软件工程的现实启发。

从摸索到接触 iOS，再到构建 10 亿台设备都在用的工具

Gergely Orosz：很高兴见到你本人。

Peter Steinberger：是啊，我差点搞砸了。

Gergely Orosz：你是忘记时间了吗？经常这样？

Peter Steinberger：通常不会。只是现在对我来说是个特别时期，因为我的最新项目 Clawdbot 火了起来，导致睡眠有点不足。我从来没经历过社区成长得这么快的情况，工作起来真的非常有趣。

Gergely Orosz：在聊 Clawdbot 和你做的这些有趣的事之前，我想先回到起点。你开发了 PSPDFKit，我记得它现在应该在超过 10 亿台设备上使用。凡是你看到的 PDF 渲染，很可能就是用它。但在那之前，你是怎么进入技术领域的？

Peter Steinberger：我来自奥地利乡村，一直是比较内向的性格。小时候， 家里常有客人来，其中有一位是电脑迷。他带来的那台电脑让我一下着了迷，于是我就央求妈妈给我买一台。

Gergely Orosz：那是在高中？

Peter Steinberger：应该是 14 岁左右。 从那以后，我就开始折腾各种东西。我记得最早的事情是，我从学校“偷”拿了一款老旧的 DOS 游戏，自己给它写了个软盘拷贝保护，后来把软盘卖掉。

那时的游戏加载大概要两分钟左右，我就一直在折腾。当然，我也玩了很多电脑游戏，但动手做东西的感觉几乎就像在玩游戏一样。老实说，现在这种感觉甚至比玩《工业巨头》（Factorio）还要爽。

我一开始学的东西是 Windows 上类似 Bash 脚本，后来做了一些网站开发，也学了点 Java，尽管当时根本不知道自己在做什么。真正让我学会如何构建东西的，是我上大学之后学的第一门编程语言。

我没见过父亲，我家也不富裕，所以我一直得自己打工，自己筹学费。当别人放假时，我就在公司全职工作。我的第一份正式工作是在维也纳，本来只打算做一个月，但他们留了我六个月，后来我在那家公司一直工作了五年左右。我记得第一天，他们给我一本很厚的书，上面写着《Microsoft MFC》。我至今做梦都会被吓醒，我当时想，这也太可怕了。

后来我偷偷开始用 .NET 开发，没告诉公司。几个月后，我顺便对技术栈做了一些现代化改造。公司也不知道为什么一直留着我，大概是我做的东西总能用。我实际上还挺喜欢 .NET 2.0 的泛型，但程序启动特别慢，因为一开始所有东西都要编译，如果你还记得当年硬盘那嗡嗡的声音……

Gergely Orosz：那你是怎么接触到 iOS 的，又是怎么想到做 PSPDFKit 的呢？

Peter Steinberger：最初 iPhone 在奥地利还没上市。后来在大学，有个朋友给我看了 iPhone，我大概玩了一分钟，就立刻决定买了一台，“感觉这太酷了！”因为它完全不同，体验也好太多了。所以我买了，但还没想过要为它开发应用。

Gergely Orosz：这是什么时候？2009 年、2010 年？

Peter Steinberger：2009 年。 那时候我用 iPhone 自带浏览器。有一次在地铁里，我在一个交友应用上写了一条很长的信息。正按发送，手机进了隧道，Java 禁用了按钮，还弹出错误提示。既不能复制，也截不了屏，我那条带情绪的消息就没了。

我气得要命，回到家后，觉得太不可接受了。于是我就自己动手，把那个网站“黑”了，用正则表达式解析 HTML。

后来，我自己写了一个 App，用的是 iPhone OS 3 beta 版本，Core Data 还是 beta 版，还用了 RegexKitLite，以及一个被修改过的 GCC 版本，把 blocks 编译器移植过来，好在 iPhone OS 3 上能用 blocks。

那时我花了好久的时间才让 App 运行起来，因为当时我完全不知道自己在干什么，还在用各种 beta 技术。但最终我搞定了。我给那家交友网站公司写了邮件：“嘿，我做了个应用，你们觉得怎么样？”当然没人理我，所以我就直接把它上架到 App Store 了。

Gergely Orosz：这是为了交友 App 做的？

Peter Steinberger：对。

Gergely Orosz：你就看了他们的接口，然后自己轻松搭了个客户端？

Peter Steinberger：接口？哪有，、我就是解析 HTML，然后把它当 API 用。

Gergely Orosz：真机智！当时没人想到会这样做。

Peter Steinberger：我把应用上架 App Store，定价 5 美元，第一个月就赚了大概 1 万美金。还记得当时 我把钱直接放我爷爷的账户里。后来有一天，爷爷打电话给我，说：“奇怪，我收到了 Apple 的一大笔款项。”我赶紧说：“这是我的！不要动它！”

最有意思的是，我记得有一次在夜店里看到有人在用我的应用，我特别自豪。想去拍他肩膀说“这是我做的”，但觉得这样的举措可能很奇怪，所以没去。

后来我去找我曾经工作了五年的公司，说：“我要全力做这个，这真的很让人兴奋。”结果我老板嘲笑我，说：“你在犯错，这只是个一时的风潮，不会太过长久的...”

我当时心想，总有一天我会创一个比你公司值钱的公司。结果确实花了八年才实现。那时候我彻底上瘾了，我几乎每天都在搞这个 App，最终把应用做得挺不错的。

遗憾的是，有一天凌晨三点，我在派对上喝了点酒，突然接到一个来自美国号码的电话。电话那头的人说：“你好，我是 Apple 的 John，你的应用出了问题，有人举报你的 App 显示了不当的图片。”

就这样，我的 App 遭下架了。它存在的时间还算不错。我当时干脆辞掉工作，然后开始做自由职业。

后来有一次，凌晨两点在旧金山的一家酒吧里，有人把我介绍为“奥地利最棒的 iOS 开发者之一”。就这样，我拿到了在美国的工作，过去待了一阵子。再后来去参加 Nokia 的开发者大会，现在回头看，那简直是石器时代。

当时有人找到我，说他们东欧那边做了一个杂志 App，功能是能用，但经常崩溃。我一听觉得挺有意思，就答应帮他们看看。打开代码的那一刻，我人都傻了。这可能是我见过最糟糕的 iOS 代码：一个文件里几千行 Objective-C，用的还是 Windows 风格的缩进。我完全不知道它是怎么跑起来的，整个结构就像纸牌屋，一碰就塌。

我先花力气把它勉强稳定下来，然后跟他们说：“这太疯狂了，我给你们重写吧。”对方说：“那得半年吧？”我回：“一个月搞定。”最后其实花了两个月，比我自己估计的长，但结果相当不错。

也就是从那时候开始， 我正式做起了 PDF 阅读器。你会发现，每一个技术问题背后都有很有意思的挑战。比如一个 PDF 文件可能有 30MB，但系统只有 64MB 内存，你后台处理稍微不注意，操作系统就直接把进程杀掉。我对这些细节特别在意，比如页面旋转时的动画一定要顺滑，这类体验上的小问题，我往往会花掉大量时间去打磨。

然后我帮朋友做杂志 App，他觉得难，我帮他抽离出 PDF 组件，卖给他。接着我想：“既然他买了，为什么不卖给别人？”

于是，我用 WordPress 模板修改后可以在 GitHub Pages 上运行，流程走 Fastlane，最后给买家发 Dropbox 链接。我一个下午就搞定，发了条推文，那周就卖了三份，每份大约 200 美元。

起初，我觉得技术很简单。但三个月后，我努力做了文本选择功能，才意识到 PDF 是一个多么疯狂的格式。

就在不久前，有人还发邮件给我，让我帮他们做 PDF。我就回：“非常抱歉，我之前已经干过这项工作了，我知道的 PDF 知识比任何神经正常的人知道的都多，为此，我一度去接受了心理治疗。所以，这次我没法帮你，只能祝你好运。”

但这个项目仍然火了。我等签证期间一直在做这件事，越来越多人买，后来到我去旧金山上班时，这项目收入已经超过我在那里工资。但我仍觉得必须去公司上班，所以边上班边继续做。公司里也用我的框架做东西，但创业不只是八小时工作，我个人项目也要投入时间，睡眠自然少。

三个月后，我的经理 Sabine 找我谈话：“Peter，你还好吗？”紧接着，他给了我两个选择：要么留公司放弃项目，要么专注项目离开公司。我只有一周做决定，因为签证问题。最终我给出了我的答案：“我要做自己的事情。”

Gergely Orosz：那时候项目已经起飞了，你看到这是大生意，收入甚至能和美国工作薪酬持平。

Peter Steinberger：我从来不是为了钱，更关心动力是什么。我想做让别人惊叹的东西。我喜欢打磨细节、那些小惊喜。哪怕这个领域已有竞争者，我的角度一直是： 像苹果做的那样，用爱和精致打磨产品。即便竞争对手功能多、历史久，我的产品仍更成功，因为开发者尝试后觉得我的用着最舒服。软件体验比功能更重要，就像为什么我们买苹果设备？因为虽然功能不如 Windows，但用着舒服。

名字五分钟定的、一做 PSPDFKit 就是 13 年

Gergely Orosz：那你是什么时候意识到，这个 PDF 组件开始热销，需要开始招人了？

Peter Steinberger：回到维也纳后，我决定全力投入，开始和自由职业者合作。老实说我招得晚了，其实可以早一点的。

就这样产品开始有自己的生命。 我职业生涯的 13 年几乎都在做这个奇怪名字的产品——PSPDFKit，名字五分钟定的，最终没改。

我的市场策略一直是只关注开发者，能说服他们，企业内部自然帮你推广。我们从不冷处理邮件或强推，一切靠优质产品和有深度的技术博客，再加上大量会议。这套办法非常有效。

Gergely Orosz：那 PSPDFKit 背后的技术栈是怎样的？最开始是 Objective-C 吗？后来有 Swift 吗？还有其他技术，比如 C 之类的？

Peter Steinberger：我们后来扩展到了所有平台。其中一个大改动是替换掉苹果自带的 PDF 渲染器，毕竟它一直有很多 Bug。后来是换成了一个大型 C++ 渲染器，这个渲染器在我们所有框架里都用上了。我们扩展到 Web 端也非常早，就在 WebAssembly 刚起步的时候，我们做了一个基准测试。这个基准后来被 Google、Microsoft 和 Apple 都用上了。

我基本上让这些大公司都帮我优化渲染器速度，因为他们把我们的 benchmark 当作参考，那感觉还挺妙的。

Gergely Orosz：随着公司成长，我记得 PSPDFKit 的博客也写得很多。2019 年那是公司成立九、十年左右， 你写过一篇博客，讲团队是怎么运作的。

你提到每个功能都从提案开始，也提到保守的态度，因为 API 很大，要小心维护，还有 Boy Scout 原则去重构。你是怎么把这种文化建立起来的？那时团队大概 30 到 60 人左右吧。

Peter Steinberger：我卖掉股份的时候，公司大概还有 70 人，现在差不多 200 人了。我从一开始就知道，在维也纳找不到我需要的人，所以一直是远程优先。后来慢慢发展成一种混合模式，但也让管理复杂一些。

我一路上学了很多东西。 我从没想过当 CEO，一直都喜欢写代码。业务上的事情我能做，也挺擅长，但不喜欢。比如企业销售，你得算 magic number，猜客户愿意付多少钱——这种事，我最讨厌。

Gergely Orosz：我们聊聊企业销售。

Peter Steinberger：这种模式下，其实只有定制化销售才行。

Gergely Orosz：那你能给开发者解释一下吗？那些去厂商网站想买软件却只看到“联系我们”或者“预约演示”，为什么是这样？

Peter Steinberger：因为我们得先了解你的公司，然后估算你大概愿意付多少钱。听起来可能很随意，但有些产品根本无法用固定价格衡量。

一个自由职业者和财富 500 强公司的使用方式完全不同，带来的价值也不一样，如果统一收费，就会排除掉某一方。定价太低，大公司会觉得奇怪，根本不启动流程；定价太高，小客户就会走人。看似糟糕，但对某些产品来说，这反而是最公平的方式。

我觉得软件有四个象限：容易／困难、有趣／不有趣。而我们的产品恰好落在“困难且不有趣”这一块。如果做的东西每个开发者都想做，那卖给他们就很难；太容易或者太有趣，也不容易赚钱。

反而是那种“天啊，这太难了，我根本不想做”的问题，才是好位置。我找到了一个有趣的利基市场——问题无穷无尽，永远做不完。

Gergely Orosz：那你能说一个或两个解析 PDF 很难的例子吗？我看这能有多难？

Peter Steinberger：举个例子，PDF 里有链接，比如目录，点一下就跳到第 37 页。我最初设计的数据模型假设大概只有几百个链接。结果有个客户付了大钱，一打开 PDF，整整等了四分钟！我一看，原来是一本 50,000 页的圣经，每页超过 100 个链接，50 万个链接！

我的模型彻底崩溃，假设偏差整整三个数量级。

然而，那时候我的产品已经成熟，有 API，问题是：怎么在不破坏现有功能的前提下重构内部架构？一切都必须 lazy 加载，否则原本解析 100 个链接没问题，现在根本撑不住。

我花了两个月重写内部架构，同时保证对用户来说依然简单。他们不用知道哪些是立即加载的，哪些是延迟加载的，甚至拷贝文档也必须保持引用关系。

我很喜欢做这种“幕后支持”的工作，这也是公司能成功的一个原因。用户提交工单，CEO 亲自回复，影响力很大。我用的策略叫“list in reverse”：工单五分钟内回复，就像魔法一样；等一两天才回复，用户几乎无感。经过两个月努力，终于把这套架构搞定，那种满足感特别强。

Gergely Orosz：那你当时还写很多代码吗？

Peter Steinberger：是的，我的团队很棒，我在一些部分更深入——尤其移动端，那是我的心头好。我一直很深入技术层面。市场和业务方面，有 Jonathan 和 Martin 的帮助。我找到合适的人很重要。

日常我写博客、分享解决问题的方法，也有助于吸引想解决复杂问题的人。

Gergely Orosz：我记得 PSPDFKit 的博客有时会上 Hacker News，很有意思。即便我不搞 PDF，也会记住 PSPDFKit，因为他们写了优化 PDF 的工程博客。这些博客，你是想着帮别人，还是单纯记录自己解决难题的过程？

Peter Steinberger：我喜欢分享、激励别人。有时团队会争论：“要不要写？这毕竟是机密。”

我通常不听这一点。我写博客还有一个原则：如果你想教别人，你必须真正理解它。对我来说，也是记录自己努力解决的难题，顺便帮别人。我当然也喜欢关注度，但更多是把博客当作公司文档、自己的日志，有助于后续参考。

在大公司里流程太多，很多开发者不爱写文档，我每个月强制大家安排一天写博客。

Gergely Orosz：你给了他们时间：“今天不做其他事，只写博客。”

Peter Steinberger：对，当时一天能写一篇博客，时间很充裕。现在写一篇博客可能就要花好几个小时。我其实不太想多讲早期那些最精彩的阶段，公司进入成长期后反而更像园艺，要管理更多的人和流程，少了那种随心所欲的“疯狂编程”的刺激。

年纪大了，人事问题越来越多，而我又不太喜欢处理这些，结果就彻底精疲力尽。

精疲力尽后卖掉股份退出

Gergely Orosz：那你觉得是什么让你彻底精疲力竭的？

Peter Steinberger：就是太拼了。我几乎每个周末都在工作，还得处理各种管理上的事务。 作为 CEO，你基本上就是个“垃圾桶”——别人处理不了、搞砸的事情都得你收拾。也挺孤独的，很多事情不能随便说。我尽量让公司透明开放，但即便遇到再糟糕的事，你也得表现得积极。

我记得有一个周末，我的联合创始人凌晨五点打电话给我，说：“你看，有家大航空公司的飞机停飞了，因为我们的软件崩溃了。”那真是个刺激的周末。我后来拆解了他们的应用，发现他们自己篡改了我们的源代码，触发了许可证回退，最终才造成问题。

那一刻我心想，“如果真是我们公司的问题，那我们完了。”而这只是压力的冰山一角。类似的事情很多，短期还能撑，但长期累积就很消耗人。

我觉得精疲力竭，并不完全是因为工作量大。对我来说，更重要的原因是——你投入的事情不再让你有信念，或者内部冲突太多。我们团队、管理层里经常争吵，我当时还犯了个错，以为公司可以更民主地管理，但这反而消耗了我的热情。不过，虽然痛苦，我不会后悔这些经历。

Gergely Orosz：从外部看，你卖掉股份，赚到了足够的钱，可以选择不再工作。对很多创业者来说，这听起来就是梦想达成。但我注意到，你博客几年完全停更。那段时间你在做什么？学到了什么？

Peter Steinberger：我花了很长时间才慢慢放松 下来，弥补以前觉得错过的生活。我玩了很多，有几个月甚至连电脑都没碰。不过，一段时间里，我也不知道自己想做什么，总觉得：“干嘛呢？”要么就这样早早退休，总之心理上很乱，那几年过得挺难熬的。

然后有一年四月，我想起多年前的一个项目——一个 Twitter 分析工具。当时我想继续做，但三年过去，它依然没真正成型，算是有了雏形，但有点跑偏了。我决定用 Web 技术重新做它，因为 Swift 和 SwiftUI 已经不太适合这个需求了。

三年后回归科技圈，想从一个 Web 项目入手，却又初遇 AI

Gergely Orosz：这是一直埋在你脑海里的想法吗？

Peter Steinberger：是啊，本来只是想为自己做的工具，因为市面上没有。我三年后回来，还是想用 Web 技术做。但在公司里，我一直没亲自碰 Web，因为我找了 Martin，他很聪明，负责那一块，我完全不用操心。

Gergely Orosz：所以你以前没动手写过 React 或类似的东西。

Peter Steinberger：对，我回来时都要问，“props 是啥？”平。很多开发者都会遇到这个陷阱：你在一个技术栈里越厉害，跳到别的地方越痛苦。不是不能做，但很难受。我在苹果技术栈里可以闭着眼睛编程，但换到 Web，每一个基础操作都得 Google，感觉自己像个傻瓜。

Gergely Orosz：经验越丰富，越痛苦？你知道自己可以更快，但效率下降，这种感觉不爽吧。

Peter Steinberger：所以我回来时想，“天啊，这 AI 是什么？”其实，我也想给这三年不碰电脑的自己点赞，因为你们那三年都在试验 AI，发现它还很初级。

Gergely Orosz：你错过了 GitHub Copilot 的 Beta 版本，那时就是 GPT-3 或类似的自动补全工具，然后是 3.5，再到 GPT-4。你回来时，第一个用的工具是什么？

Peter Steinberger：我回来后就用 Claude Code。

我把一个乱七八糟的副项目上传，它是一个浏览器扩展，把 GitHub 仓库变成一个 1.3 MB 的 Markdown 文件。我扔进 Google AI Studio，又用 Gemini 1.5，输入“写个规范”，它生成了 400 行规范。我再扔进 Claude Code，命令它“Build”，继续、继续、继续。

它告诉我，“100% 可生产”，我启动它，结果崩了。

我加了 MCP，让它能用浏览器，当时 Playwright MCP 已经在了。循环几个小时后，它打开了 Twitter 登录页面，做了一些事情。虽然不完美，但对我来说，那一刻简直震撼到不行。

Gergely Orosz：那是去年四五月吧？

Peter Steinberger：对。那一刻让我立刻看到了潜力，我知道这就是方向。从那以后，连续好几个月我都失眠。我记得有一次早上五点，我给你发了私信，你竟然立刻回了，我惊讶你还没睡。你说你刚在用 Claude，太上瘾了，我当时心想，这东西怎么让人停不下来。

就像赌场的机制，你按下按钮，要么一文不值，要么让人惊艳。作为有经验的开发者，很难被惊艳，但它做到了。我以前在公司，每个细节都要过分执着，空格、换行、命名，花了太多时间讨论这些小事。

现在回头看，我都傻了，客户根本不会看内部结构。

当然，软件必须能用、快速、安全，但花那么多时间挑剔这些小事，实在太傻了。

”已经不再读代码的我“

Gergely Orosz：但正因为你过分执着，PSPDFKit 才这么受欢迎，它的性能、体验都好。你觉得这种关注细节，其实也是减少技术债的方式吧？

Peter Steinberger：对，一定程度上是。甚至我最近博客最后一篇文章，就是坦白我现在有时候发布代码都不读了。同时，我也花了很多时间在重构上。

今天我本来非常想提交一个 PR，是一个整整 15,000 行的改动，把所有东西都迁移到插件架构上，我兴奋得不行。我非常在意架构。

至于代码有没有全读完？其实没有。

很多代码其实就是无聊的“管道工作”。大多数应用到底是干什么的？数据从 API 进来，你解析它、重新包装、存到数据库，再以另一种形式输出，最后生成 HTML 或者别的东西。你输入一些东西，它又被转换成另一种形式。你做的，大部分时间就是在不同形式之间“揉捏”数据。

大部分应用都是这样，我们基本上就是 JSON 打印机。真正复杂的部分，30 年前 Postgres 的一些“天才”就解决了。软件很多时候都是这样的，当然总有有趣的部分，但按钮怎么对齐、Tailwind 类用哪个， 这些细节很多都是无聊的，真正有趣的是系统架构，而不是每一行代码你都必须读透。

Gergely Orosz：明白。那现在说到你的工作流，比如你在做 Clawdbot 的时候，用什么工具？你刚说你不逐行审查代码，但还是关注架构。你的一天大概是怎样的？如果有开发者加入团队，你会怎么解释你的工作流程？

Peter Steinberger：我们从四月开始用 Claude Code，我完全上瘾了。后来我尝试了 Cursor、Gemini 1.5，还有 Opus 4。我把很多朋友拉进来，他们都被我“毒害”了，因为我的热情让他们也试试 AI，然后他们也凌晨五点起床。

我给它起了个名字叫“黑眼俱乐部”。我在伦敦甚至开了一个叫 “Claude Code Anonymous” 的聚会，有点像戒瘾组织，因为这真的像上瘾一样有趣。

让我震撼的是，我意识到现在几乎可以构建任何东西。以前做 side project 必须精挑细选，因为软件开发太难。而现在虽然仍然有难度，但以前那种“我在这技术栈很厉害，在那技术栈很糟”的摩擦不再是障碍。

我可以说，“来吧，用 Go 写 CLI，我根本不懂 Go”，但我有系统的理解，一旦理解了，你就能判断什么对，什么错。

有人在推特上说，写代码时感受到摩擦有助于做架构决策。我在用 AI 提示时也感受到类似的摩擦：看代码生成的速度，观察 Agent 的反应，判断生成内容是乱还是合理。我甚至能预判任务会花多长时间，如果比预期久，我就知道问题出在哪儿。这种感受像是一种共生，我学会了“跟它对话”，使用能力也因此大幅提升。

从四月到现在，关键转折点大概是夏天——AI 好到可以在不手写代码的情况下创造软件。但对我来说，真正的突破是 GPT-5.2。我觉得它被低估了。我不明白为什么还有人坚持用 Claude Code，它确实开辟了新类别，很适合通用计算和编程，但复杂应用开发，Codex 更强。Claude Code 只读三个文件就信心满满地生成代码，你得不断引导它，让它读更多文件，看到全局；Codex 会默默地花 10 分钟读文件，如果你只用一个终端，这很折磨人。但它让我可以设计系统，我是架构师，不是逐行编程。

Gergely Orosz：听起来有点像过去的 Architect，大家不再动手，但懂业务，带着开发者团队工作。现在大部分公司不用了，但你这像 Architect + Agent，只是你还全权负责，你写的代码就是你的责任。比如 Clawdbot 最近推上线出问题，你得承担责任。以前公司里 Architect 被保护，输出由别人处理。

Peter Steinberger：我不喜欢“Architect”这个词，我更喜欢“Builder（建造者）”。

作为 Builder，我看到两类人：一类是用 AI 很成功的人，一类是真挣扎的人。我更关注结果和产品体验，而对内部“管道”只关注结构，不追求每个小细节。另一类人喜欢解决算法或技术难题，而不是做产品，他们通常挣扎，甚至拒绝 AI，因为 AI 正是帮他们解决了难题。

我今年学到的软件架构和设计经验，比过去五年还多。AI 里蕴含丰富知识，一切问题都只是问对问题的距离。就像我那个 Twitter 工具，仍然没完全完成，某些操作在数据库触发时会导致延迟，模型本身看不到，因为副作用只在一个函数里，名字也不明显。我最终问了正确的问题，它才定位修复。

Gergely Orosz：所以你必须有知识、经验、专长。

Peter Steinberger：对， 那些拒绝 AI 的人就是在意每个内部细节的人。那些不太在意管道，只想创造的人，反而非常成功。我也从管理团队中学到放手，允许工程师偶尔不完美，但向目标推进。Claude Code 让我感觉像再次当老板，协调不完美但有潜力的“工程师”，大家朝共同目标努力。

以前 vs. 现在的编码方式

Gergely Orosz：你用传统方式做软件超过 15 年，也带过团队、保持高标准。现在用 Agent 工作一年左右，比较两者，有哪些变化和不变的地方？

Peter Steinberger：首先，我不喜欢“vibe-coding”这个词。

Gergely Orosz：那该叫什么？

Peter Steinberger：我觉得“氛围编程”现在几乎成了一种贬义。我跟别人说，我做的是 “Agentic Engineering（智能体工程）”。

所谓“氛围编程”通常从凌晨三点开始。因为写代码的琐碎工作都被自动化了，我可以更快地推进，但也需要思考更多。我依然完全沉浸其中，感觉和以前的“心流”一样，只是心理负担更重——我不只是管理一个员工，而是五六个、甚至十个人同时在不同任务上工作，我需要在各个部分之间不断切换。大多数时候，我在设计某个子系统或功能，然后让 Codex 生成代码，这通常需要四十分钟到一小时。

所以我会先制定计划，再去构建。然后切换去做其他事情，生成运行时，我再回过头检查或微调，循环往复。我的大脑一直在多任务切换。我希望未来可以减少这种并行度——速度更快的模型和系统会帮我做到——但为了保持心流，我现在必须高度并行化。

这就是我的工作方式：主要项目为重心，同时关注一些辅助项目，我可能只花几分钟启动它们，然后让系统运行半小时，再回过头试验或调整，不需要太多精力。

Gergely Orosz：这让我想到两件事：一是那种经营的游戏，你要管理一个厨房的员工，还要看菜谱然后马上去操作。还有一种是国际象棋大师同时下多盘棋的场景。有时候他们同时处理二十盘棋，每盘都要做出决策，对某些对手会停留更久。感觉他们的大脑被完全占用，而你也在不断切换，把自己放大到极限。

Peter Steinberger：用 Claude Code 的情况有点不同，你必须用不同方式工作，因为它生成速度很快，但输出常常第一次不成功。它可能做出一个东西，但忘了更新其他三处，程序崩溃，或者给你的结果不完整。

要想高效使用这种编程代理，关键就是“闭环”： 它必须能自己调试和测试自己。这是最大的秘密，也是我效率大幅提升的原因之一。

不过用 Claude Code，我经常需要回头修正，或者多次迭代。最终速度并没有快多少，只是互动性更强。现在用 Codex，几乎总是能一次成功。我的策略是，先构建功能，让它写测试，确保它能运行自己的测试。

即便是写 Mac 应用，我也遇到麻烦。比如昨天我调试一个功能，Mac App 找不到远程网关，但同样的 Type 代码却没问题。但 Mac App 调试有点烦，需要构建、启动、观察、记笔记，这个不行那个不行。

现在我就直接让大模型“去生成一个 CLI，仅用于调试，它调用同样的代码路径”，然后就可以自己迭代修复。它自己运行了一小时就完成了，并告诉我：“这里有竞态条件，这里有配置错误，等等。”

我就觉得“嗯，合理，不需要我看代码了”。

Gergely Orosz：你之所以不用自己看，是因为你设置了验证循环，你相信它已经跑过了。就像以前在大公司处理大型项目一样，所有测试通过并不意味着 100% 正确，但很大概率没问题。新的代码也有测试，说明有人考虑过，验证过。

Peter Steinberger：即便是最小的项目，也总会有 bug。比如 Anti-gravity，它在循环里调用工具时格式有点怪，需要做过滤处理。

我花了很久才意识到，需要把这些自动化。于是我就让 Codex 设计实时测试：启动 Docker 容器、安装完整环境、运行循环、使用 API 密钥，然后让模型读取图像、生成图像、再分析图像，确保工具调用也正常。最后，它自己解决了问题。

虽然耗时很久，但它测试了所有 API key，从 Anthropic、OpenAI 到 Gemini，所有细节问题都修复了，包括工具调用顺序错误，因为我闭环了循环。

Gergely Orosz：你说的闭环，就是让智能体有办法验证自己的工作，对吧？

Peter Steinberger：没错，这也是为什么现有模型在编码方面如此高效，但在创作上有时表现平平，因为验证不容易。在写代码时，我可以编译、lint、执行、验证输出。如果设计得对，就有完美的闭环。即便是网站开发，我也把核心写成 CLI 可运行的形式，这样有完美的执行循环，因为浏览器循环太慢了，你需要快速循环。

Gergely Orosz：听起来，和以前没变的是，像后端或业务逻辑密集的部分，可以更容易验证正确性……

Peter Steinberger：使用智能体编码反而让你成为更好的程序员，因为你必须更认真地设计架构，让它容易验证。验证就是让代码更好的方法。

Gergely Orosz：对，以前即便没有 AI，做复杂系统的人也会先考虑“如何让它可测试”。你需要设计可测试接口、类，考虑是否用 mock，是否做端到端测试等等。这些都是艰难的架构决策，一旦做了就很难改。模型要做大规模重构，如果有测试，它能正确完成，但仍有权衡。

Peter Steinberger：软件还是软件。我现在写的代码比自己动手写更好，而我以前写过非常棒的代码。即便在公司里，测试也很痛苦，要考虑所有边缘情况和分支逻辑……

Gergely Orosz：除了我非常尊敬的 Kent Beck 之外，他到现在依然坚持“先写测试”。不过说实话，我认识的大多数开发者，包括我自己，其实都不太喜欢写测试。就算有时候假装自己喜欢，最后也还是没怎么写。对我来说，写文档、写测试有点像一回事——它们从来都不是一种“创作”，没什么表达欲。

Peter Steinberger：现在真的不一样了！比如我上一个项目，文档质量非常高，但我一行文档都没亲手写过。现在我既不写测试，也不写文档，我做的是 只给模型讲权衡：把设计思路、取舍讲清楚，然后直接跟模型说：“把这些写下来，开头写得对新手友好一点，后面再补充更技术细节的内容。”

结果真的特别好。说实话，我从来没做过一个文档这么好的项目。而且现在，每次设计一个新功能，写文档已经自然变成流程的一部分了。

测试也是一样。现在我经常会这么想：“好，我们把这个功能做出来了，那怎么测？可以这样、那样……等等，如果我们换一种实现方式，是不是会更好测？”所以测试已经变成我思考过程的一部分了。因为我脑子里总有个问题：“这个闭环怎么收？怎么让模型自己验证它做出来的东西？”而一旦你这么想，架构自然就会往更合理的方向走。

为什么依然有很多开发者抵触 AI？

Gergely Orosz：那你觉得，为什么现在还是有不少经验很丰富的开发者，会对“AI 能干这么多事”这件事抱有很强的抵触情绪？

Peter Steinberger：就一周前吧，我看到 Michael Geller（Cocos with Love 的作者）写的一篇博客。我非常尊敬他，也从他那学到了很多。但那篇文章，基本上就是在吐槽现在这些模型的工作方式。

他测试了五六个模型，里面甚至包括一些根本不适合写代码的，比如 OpenAI 那个 120B 的开源模型，说实话，那种模型本来就写不出什么好代码。

据我理解（博客里其实也没写得很清楚），他的流程大概是：写一个 prompt，丢到 Claude 的网页版里，点发送；然后把输出直接拿去跑，结果编译不过，于是他就很失望。

但问题是——这不是很正常吗？你指望我第一次写代码就完全没有 bug 吗？这些模型，本质上是人类集体知识的“幽灵”，它们的工作方式在很多地方和人很像。第一次做对？不可能的，一定会有错误。所以你必须把反馈闭环补上。

而且你不能只给模型丢一个 prompt 就完事了，那不是“用工具”，那只是“扔指令”。你得跟它对话：“我想做的是这个。”

他还抱怨说模型用了旧 API。那是因为你没告诉它 macOS 的版本啊。信息缺失，它只能假设一个默认值，而训练数据里旧资料本来就比新资料多得多。所以你越理解这些“小怪兽”是怎么“思考”的，你就越会写 prompt。但他大概也就玩了一天左右，就下结论说：这项技术还不行。

可问题在于，要真正用好它，你得投入多得多的时间。这有点像：你会弹吉他，我突然把你丢到钢琴前，你随便按了几下就说：“这玩意不行，我还是回去弹吉他吧。”

不是这样的。这是完全不同的一种构建方式，也是一种完全不同的思维模式。

你都不知道我有多少次凌晨三点对着 Clawdbot大喊，因为它干了很蠢的事。但慢慢地，我开始理解：为什么它会严格按照我说的话，做出那些“看起来很傻”的结果。

有时候你甚至可以直接问它。就拿我上一个项目 Clawdbot 来说吧，我感觉自己已经变成了一个“人肉合并按钮”。社区太活跃了，我每天几乎都在 review PR，已经很少有时间亲自写代码了。

一开始它经常会只 cherry-pick 一部分改动，然后直接关掉 PR，我气得不行，经常问它：“你为什么要这么干？”它会回答：“因为你这么说、这么说，我就理解成了那样。”

那一刻我就懂了。

我开始更理解“机器的语言”，调整我的 prompt，结果现在它给我的，基本就是我真正想要的东西了。因为这本身就是一项技能，和任何技能一样。

Gergely Orosz：对，其实 Simon Willison 也一直在说类似的话，哪怕他已经用这些工具很多年了。我自己也是，一旦真正开始用，就会意识到：我还行，但还能更好。

那我们来做个更现实一点的假设吧。现在你在做 Clawdbot，它很酷、用户很多、增长也很快，但它毕竟不是像 PSPDFKit 这样营收高度依赖产品的公司。如果今天 PSPDFKit 完全不存在了，你要从零重建它，而你手里已经有了这些 Agent 工具——那它会变成什么样？你会多信任它？哪些事情会交给它？哪些必须人工验证？等公司重新变成一家赚钱的企业，你肯定还得招销售、招人。那在同样的产品目标下，你觉得今天的团队结构，会和当年有什么不同？毕竟你非常清楚当年是怎么一步步把它做出来的，你也知道这些工具现在能做到什么程度。

Peter Steinberger：我觉得， 用现在的工具，我完全可以用原来 30% 的人 把公司跑起来。当然，前提是——这些人得真的非常资深。你需要的是那种真正理解自己在构建什么的工程师，同时也愿意、也擅长去“放权”：知道哪些部分是关键，必须亲自盯；哪些部分，是可以放心去 “vibe” 的。

但说实话，这种能力我现在还是很少见到。尤其是在 AI 圈子里，Twitter 上简直是垃圾信息泛滥！一堆人声音特别大，但明显根本不知道自己在干嘛。真的有太多莫名其妙、很蠢的概念了——不好意思我得直说，比如那个 Ralph Wiggum 的玩法，这又是一个为了绕开 Opus 模型局限性而发明出来的“操作”，但你用 Clawdbot根本不需要这些东西。

也许确实有极少数场景，是那种特别长的一串、完全可以自动化的独立任务。但软件开发通常不是这么回事。可我看到太多人在搞什么“超复杂的编排层”，然后有一群“蜜蜂”自动建工单，Agent 处理工单，再给另一个 Agent 发邮件……最后堆出来一个极其复杂的大杂烩。

问题是——图什么呢？

还有一种说法是：“哦，他们先花几个小时把 spec 设计好，然后机器一天之内就把东西全做完了。”我不信这套。说真的，这不就是软件工程里的瀑布模型吗？我们早就知道这玩意行不通了。

当然，也许有人工作方式不同，可能对少数人确实有效。但对我来说，我完全无法想象这怎么能行。

我必须从一个模糊的想法开始，而且我经常是故意给 Agent 少一点信息，让它做出一些“不太对劲”的东西，从而激发我新的想法。

你知道吗，大概 80% 的假设都是垃圾，但偶尔会有一两个点让我眼前一亮：“哦，原来还能这么想！”然后我就不断迭代、打磨这个项目。我得点它、摸它、感受它。我觉得，做出好软件，有一个东西特别重要——品味，而这恰恰是这些系统最容易缺失的。

我必须亲自感受：“这个功能用起来是什么感觉？”而现在最爽的一点在于：做功能太便宜了，不行就直接扔掉，或者重新 prompt 一下。我的构建方式基本是一路向前推进的，很少真的回滚到很早之前。更多时候是：“不对，改这个。”“还是不行，那我们换个方向。”这很像雕塑：你一开始面对的是一整块石头，然后一点点凿，换不同的角度下手，慢慢地，一尊雕像就从大理石里显现出来了。

Gergely Orosz：如果从软件工程演进的角度来看，这确实是一种变化。因为在 AI、agent 出现之前，前期规划是非常重要的。比如在 PSPDFKit，你一直坚持要先写 proposal，让大家在一开始就把问题想清楚、说明白。因为开发和返工都很贵。你觉得现在这种变化，是因为“写代码本身的成本”大幅下降了吗？

Peter Steinberger：我还是会做一些规划的。但我不会像以前那样在前期投入那么多了。因为现在你可以非常快地试一下，看结果怎么样，然后判断：“哦，这个形态可能行。”或者“还得再调整。”

甚至“完全换一种方式来做”，现在的成本也低得多。对我来说，这让整个过程变得更像是在玩。

Gergely Orosz：是的，因为以前就算你带的是应届生或者实习生，你给他一个任务，他得干一两天；再改一次，又是一两天。而现在，我们说的已经不是“天”了，而是“分钟”。就算是很重的任务，最多也就 10 到 20 分钟。而且你也不是干等着，它是并行跑的，所以严格来说，也谈不上浪费时间。

Peter Steinberger：在 Clawdbot 里，一开始我假设只需要一个 Agent，后来变成了多个；一开始我以为只会支持一个 provider，比如 WhatsApp，现在变成了好几个。如果是我自己写代码，这种改动会非常痛苦——你得把所有逻辑一层层串起来，几乎整个系统都要动。但 Clawdbot 用了大概三个小时就改完了。要是我自己写，可能得两周。

所以那些前期规划的东西，我当然也可以一开始就想到，但现在我知道：改是很便宜的。你可以一边做，一边还技术债，一边调整自己对项目的理解。

这也是为什么我不太相信那种“写好 spec，然后系统自动生成一切、项目就完成了”的东西，比如 Ghost Town 之类。

你怎么可能在真正开始做之前，就知道自己到底想要什么？在构建的过程中，你会学到太多东西，而这些东西又会反过来影响你对系统最终形态的理解。

对我来说，这完全是一个循环。你不是直线爬山的，而是绕着山转，有时候还会走点弯路，但最终你还是会到达山顶。

Clawdbot 的诞生

Gergely Orosz：那你现在做 Clawdbot，大概多久了？两三个月？

Peter Steinberger：其实把我重新拉回来的一个想法，是在四五月份的时候：我想要一个高度个人化的助手。不是那种“早上给你发封邮件，说你今天有三件事要做”的助手。而是那种真的很懂我的：比如我见了一个朋友，回到家，它会问我：“刚刚那次见面感觉怎么样？”或者有一天提醒我：“你已经三周没给 Thomas 发消息了，我注意到他现在在城里，因为我看了他的 Instagram，你要不要打个招呼？”或者它会说：“我发现你每次见到某个人都会心情变差，这是为什么？”

那种非常个人化的东西……几乎可以说是反 CRM 的存在。有点像电影《Her》，但说实话，这就是技术的发展方向。

这些模型对文本的理解能力非常强，context 越大，它们能看到的模式就越多。虽然它们本质上只是没有灵魂的矩阵计算，但很多时候，给你的感觉真的不一样。所以我当时甚至为此成立了一家公司，叫 Amantus Machina——“有爱的机器”。

但去年夏天我认真探索了一下，发现模型还没完全到位。能看到一些希望，但还是有点“站在我当时需求的边缘”，不过这反而让我很兴奋，因为 AI 进步实在太快了——我完全可以过段时间再回来做这件事。而且我也相信，所有大型公司现在都在做个人助手。未来，每个人都会有一个“最懂你的朋友”，哪怕它是一台机器：了解你、掌握你的一切信息、帮你做事、而且是主动的。

这肯定会消耗大量 token，但凡是负担得起的人，都会有一个。之后它会逐步下沉，随着系统更高效、芯片更强，这会变成普及型产品。这就是未来，毫无疑问。你已经能看到一些苗头了，比如 OpenAI 推出的带一点主动性的功能，但算力还远远不够，而且实现难度也很高。

我一直想要的， 是那种跑在我自己电脑上、数据真正属于我的东西。说实话，把你的邮件、日历、甚至交友软件全都交给 OpenAI 或 Anthropic，还是挺吓人的。不知道你和不和“普通朋友”聊这些，但我很多做剪辑的朋友，已经把这些工具当成心理咨询师在用了。而且效果真的很好！它很会倾听，也能理解你的问题。当然，前提是别遇到某些 4o 的版本那样：“当然，这是个好主意！我们往沙拉里加薯条吧！”——撇开这些，它真的很好。我自己也用过。

从某种意义上说，光是“反思”这个行为本身就已经在帮你了。哪怕机器只是原样复述你写的内容，都会有帮助，更别说它现在还能提出很有洞察力的问题了。所以我一直有这个助手的想法。只是当时技术不够成熟，于是我先去做了别的，做了一堆有趣的小东西。

比如我做了 Vibe Tunnel。在成为 Agentic Engineer 的职业路径上，有一个“陷阱阶段”：你会疯狂给自己做工具，试图把自己的工作流优化到极致。但那个“高度个人化 agent”的想法一直没走。

后来几个月，我真的开始把它做出来了。最有意思的是，一开始我甚至没想到它会发展成现在这样。

当时我管它叫 WhatsApp Relay，目标很简单： 用 WhatsApp 从手机触发我电脑上的事情。所以我就做了一个 WhatsApp 的中继，让一个 agent 能操作我的电脑。

后来我去摩洛哥给朋友过生日，白天一直在外面，就用 WhatsApp 跟我的 agent 聊天。然后我彻底上瘾了。它给我指路、讲笑话，还能用我的身份给其他朋友发消息。

我记得当时被震撼到了，因为一开始技术其实很糙，但我加了一个功能：可以给它发图片。我甚至没用什么正规的图片接口，只是给 LLM 发了个字符串，让它用阅读工具去读。

然后有一次我随口发了条语音消息——我甚至都没实现语音功能。结果 30 秒后，它回我了。

我直接懵了，问它是怎么做到的？它说：“哦，你给我发了个文件，我看了 header，发现是 OGG 格式，就用 FFmpeg 转了一下。然后我在你电脑上找 Whisper，没装；但我发现了 OpenAI 的 key，就 curl 了一下 OpenAI，让它转文字。”

我当时觉得不可思议，这是 Opus 3.5 啊，太离谱了。别人总说：“你需要一个 skill 系统。”不，它就自己想出来了。我就这么慢慢被它钩住了。

我甚至用它当闹钟。它跑在伦敦的 Mac Studio 上，通过 SSH 连到我在摩洛哥的 MacBook，给我放音乐，而且我不回应，它就把音量一点点调大。

为了这个我还加了心跳机制。从安全角度看，这简直疯了：你给一个模型发 prompt：“做点酷的事情，给我个惊喜！”每隔几分钟就发一次，让它主动跑任务列表。可能是史上最贵的闹钟，但真的太好笑了。

而且它给我发的消息也特别有“人格”。有一次我前一天打水仗，第二天得早起，但一直没回复它。你能看到它的推理过程：“Peter 没回应，但 Peter 得起床！不行不行不行，不能睡！”

它就在那疯狂催我。我把这个展示给一起旅行的朋友看，所有人都被迷住了。这种东西真的有点魔法的感觉。我自己也完全上头了。然后我发到 Twitter，上面一片冷淡——根本没人 get 到。

我觉得这是一种全新的产品类别。有点像你当年看 iPhone 的广告，完全不懂它厉害在哪，但一旦你真的用上了，一切都不一样了。

我真正认真投入做 Clawdbot，其实也就最近两个月。

名字也从 WhatsApp Relay 改了。某天 Claude 跟我说：“这个名字已经不适合现在的功能了，你都有 Telegram 和一堆别的东西了。”

于是我改名叫 Clawdbot。

这是个内部玩笑，我喜欢《神秘博士》。而且这个名字域名也更好，更能说明它是个什么东西。

我拿下了这个域名，然后也悄悄开始“扩军备战”。因为要把这事做好，一切都得是 CLI。于是我开始给所有东西写 CLI 控制 Google、床、灯、音乐……

Gergely Orosz：那为什么你选择用 CLI？为什么不是 MCP？你怎么看 MCP 这套东西？

Peter Steinberger：说白了，它就是个拐杖。我觉得 MCP 最大的价值，其实是逼着很多公司重新思考：是不是应该把 API 多开放一点。但整个 MCP 的设计理念，本身就有问题：你得在会话一开始，就把所有工具的所有函数、所有说明一次性“导出”给模型。然后模型再构造一大坨精确的 JSON 发过去，收回来的也是 JSON。

可问题是——模型特别擅长用 bash。比如你有一个天气服务。模型要先请求“所有可用城市列表”，结果一下子给你 500 个城市。然后它得从这 500 个里挑一个，但它没法过滤，因为 MCP 本身不支持这种操作。

接着它说：“好，给我伦敦的天气。”你得到的会是：气温、风速、降雨、湿度，再加上 50 个我根本不关心的字段。

我只是想知道——下不下雨？反正是伦敦，大概率下。

但模型还是得把这些垃圾信息全吃进上下文里。结果文本里全是废话。但如果这是 CLI，它直接用 jq，只筛选自己真正需要的字段就完事了。

Gergely Orosz：但这听起来更像是 MCP 的一个实现限制？问题在于它把所有东西都塞进上下文里。如果 MCP 不在 context 里，而是能“发现”“选择”要用哪个，会不会就能行？

Peter Steinberger：对，这正是现在很多公司在做的方向。但问题还是没解决——我没法把它们串起来。我没法轻松写一个脚本说：“给我所有温度超过 25 度的城市 → 只保留我关心的信息 → 打包成一个结果。”

在 MCP 里，这全都是一个个独立的调用。我没法脚本化它。

Gergely Orosz：但这听起来更像是时间问题，就像我们以前做天气应用一样：即便没有 AI，我也知道我要去找 API，看覆盖范围、价格、取舍，然后选一个，再把多个 API 串起来。

这套问题在“前 AI 时代”已经解决过一次了。现在只是换了个形态，迟早也会解决，只是不知道最终会长成什么样。

Peter Steinberger：所以我干脆自己写了个东西，叫 Port。一个很小的 Type 工具，把 MCP 直接转换成 CLI。这样你就能直接打包用了。

Gergely Orosz：所以你的意思是，现在这个阶段，CLI 明显更高效。

Peter Steinberger：Clawdbot 本身不直接支持 MCP，但你可以通过 Port 用任何 MCP。你甚至可以在手机上说：“用 Vercel 的 MCP 帮我做这个那个。”它会自己去网站上找 MCP、加载、按需调用。

而现在 MCP 的使用方式是：你得重启 Clawdbot。这对用户来说，简直灾难级体验。

所以我就悄悄开始“扩军”，把所有能自动化的东西都自动化掉。这工作量其实很夸张。

Taylor 前几天还专门做了个视频，说：“这人疯了。”因为现在工具列表已经长到离谱。但我就是一边玩 Agent，一边想：我想让它能干更多事。

说实话，这个项目到底是干嘛的，很难一句话说清楚，现在对我来说也依然很难。直到 1 月 31 号，也就是一周前，我突然想：“要不来点真的疯狂的？”我直接建了个 Discord，把我的 Agent 拉进去了。

刚好有人给项目贡献了 Discord 支持。我一开始还在犹豫要不要 merge，最后还是 merge 了。于是我就把一个对我电脑有完整读写权限的 agent，丢进了一个公共 Discord。

能出什么事呢？这事本身就已经够离谱了。然后有人进了 Discord，看我用这个东西的完整能力：看摄像头、控制智能家居、当 DJ 放音乐……

我人在厨房，跟它说：“你看看我屏幕，看看你自己都干了啥。”因为它能看到我的屏幕，也能点、能打字。它甚至可以直接在终端里帮我敲命令，然后跟我说：“Claude 现在是这么想的。”

我现在还在优化这块——理想状态当然是全文本流，但现在已经能用了。它在后台盯着我的屏幕，我干蠢事的时候还会吐槽我。

所有体验过几分钟的人，都会立刻上头。 项目一周内从 100 个 star 飙到 3300。我已经 merge 了大概 500 个 PR 了。所以我才说，我感觉自己就是个“人肉合并按钮”。

这也是我最近有点乱的原因——项目直接炸了。但最美妙的一点是：技术门槛本身消失了。

你只是像在手机上和一个朋友聊天。而这个朋友无限能干：能读你的邮件、日历、文件；能帮你建网站、做行政、爬网页；能帮你打电话、联系朋友、联系商家……

我马上就要 merge 打电话功能了，就是能直接给商家打电话、帮你订位。你完全不用去想“上下文”这些东西——它们自然就融在一起了。

我做了一个记忆系统，当然还不完美，但已经很“魔法”了。现在我走在路上，看到一个活动，拍张照发给 Claude。它不光能告诉我评价，还能告诉我：会不会和我日历冲突、朋友有没有提过这个活动……

因为它有足够多的上下文，给我的回应质量，已经远超那些各自活在“小盒子”里的工具。

说实话，这听起来就像你做出了 Apple 当年想让 Siri 成为、但一直没做到的东西。我甚至觉得，我这是在给 Anthropic 做最好的营销。

不是说它真的“特别吃 token”，而是大家太爱用了，一直在用。因为技术被完全隐藏起来了。他们感觉不到后台有多少 agent 在忙、跑一堆流程，只觉得“一切都很顺”。

但说实话，背后真的是实打实的工程量。最难的部分，就是把复杂度藏到极致，让一切看起来像魔法。

项目落地的难点

Gergely Orosz：我能感觉到，你在架构这套系统的时候，其实想得非常清楚。虽然 Clawdbot这几个月才真正成型、最近才爆发，但在你脑子里，它是有结构的：哪些模块、哪些地方可以改、哪些需要重构、哪些地方效率不行。你会去考虑内存、token 消耗、性能这些问题吗？

Peter Steinberger：token 消耗，本质上就是 prompt 怎么写。

至于内存？说白了，就是 Type 在那儿搬 JSON。

说实话就是这样：我从 LLM 拿文本，存到磁盘，再把文本发到 WhatsApp。现在支持的有：MS Teams、Slack、Discord、Signal、iMessage、WhatsApp……很快还要加 Matrix。已经是个“群交系统”了。

但核心上，我就是在不同形态之间搬文本。当然，有多 provider、多 agent、有 agentic loop、有一堆配置、很多管道活。但真没什么本质上很难的东西。

Gergely Orosz：对，但它是很多很多“小事”堆起来的。其实在 AI 之前的软件也是这样，本身并不“难”，只是需要理解语言和系统。

Peter Steinberger：真正的难点在于： 怎么把它做得有魔法感。所以我花了很多时间在“第一次体验”上。

你复制一行命令，我会检查你有没有 Node、Homebrew；帮你装 npm 包；检测旧版本；保证一切能顺利跑起来。

接着我会引导你配置模型。但我会先自动检测你是不是已经有 Claude key，你基本只要一路按回车。

然后你选 WhatsApp，输入手机号，就直接能用。

接着我问你：“要不要孵化你的 bot？”你点 yes，一个 TUI 就出来了——毕竟你还在终端里，体验要好。

我给这个过程做了一个启动仪式。我有一个 bootstrap 文件，用来告诉模型：“你现在被‘生出来’了，你要形成自己的身份和‘灵魂’。”

它会问：“你好……我是谁？你是谁？我叫什么名字？”

我看着用户经历这一刻，魔法就在这里发生。他们不再觉得自己是在和 GPT-4.2 说话，而是在和“自己创造的朋友”聊天：可能是叫 Vahoon 的独角兽，可能就是 Claude。

接下来它会问：“你在乎什么？你是做什么的？”

我把它设计成一个好奇的存在。等 bootstrapping 结束，它会删掉 bootstrap 文件，生成一堆文档：user.md、soul.md、identity 文件，记录名字、核心 emoji、内部梗、价值观。

这些文档不是静态的，会随着你们的互动不断演化。

然后，它就会给你发一条 WhatsApp 消息。你突然发现：你已经在 WhatsApp 上和它聊天了。

把这个流程做顺，真的很难。包括一个关键设计：你不需要手动改配置，因为 agent 可以改它自己的配置。你不需要更新系统，因为 agent 可以更新自己。你可以直接跟它说：“更新你自己。”它会自己拉代码、更新，然后回来告诉你：“嘿，我有新功能了。”

把技术门槛彻底抹掉，只留下体验，这才是魔法。

Gergely Orosz：这和你当年做 PSPDFKit 其实很像，对吧？你把 PDF 的复杂性完全藏起来了，用户只觉得：旋转、编辑、操作，一切都理所当然地存在着……

Peter Steinberger：对，甚至在当年的 API 层面也是这么想的。

为什么大公司难以高效地采用 AI？

Gergely Orosz：回到软件工程这个层面。你现在已经把这个东西做成了一个真正的产品：在合并 PR、有人在用、它是生产级软件了。回过头看你当年在 PSPDFKit 的经历，再看看那些有几十、上百名工程师的大公司，基于你现在构建 Clawdbot 的方式，以及你正在使用的这些工具，你觉得大公司里的软件工程方式会发生怎样的变化？

我观察到一个很明显的现象：对你这种“个体开发者”来说，AI 的适配度极高，你的效率被大幅放大，你对系统拥有完全的控制权。但一到团队、公司层面，尤其是那些有大量存量代码的组织，一切就慢很多。大家可能会在某些点上用 AI，但整体感觉是——这两个世界之间有一道巨大的鸿沟。而你某种程度上，已经在“独立扮演一个 CEO”的角色了。你怎么看这种差异？是结构性问题，还是只是一个时间差——像所有新技术一样，先被少数爱好者玩明白？

Peter Steinberger：我觉得，大多数公司都会非常难以高效地采用 AI。因为这不仅是工具升级，而是需要彻底重定义公司是怎么运作的。

你想想，在 Google 这种公司里，你要么是工程师，要么是经理。那如果你还想参与 UI 决策呢？这个角色大概率是不存在的——要么你写代码，要么你做设计。

但在这个新世界里，需要的是那种既有产品视角、又能把事情从头做到尾的人。这样的人数量会更少，但他们的行动力和综合能力都要极强。

从某种意义上说，公司规模可能能缩到原来的 30%。这件事其实挺可怕的—— 在经济层面，很可能会引发一场混乱，会有很多人发现自己在这个新世界里找不到位置。

所以我一点也不意外，现有公司用不好 AI。他们当然“用”了，但那不叫真正的转型。你得先做一次大重构——不仅是代码库的重构，也是公司的重构。甚至在代码层面，我现在设计代码库时，第一优先级不是“对我好用”，而是“对 agent 好用”。

我优化的目标已经变了。有些选择并不是我个人最喜欢的，而是我知道对模型摩擦最小、效果最好。因为最终是它们在和代码打交道，不是我。我负责的是整体结构和架构，这部分我依然按自己的方式来。

一切都需要重新思考。比如 Pull Request——我现在更把它们当成 Prompt Request。有人开了个 PR，我基本不看代码。我会先说一句“谢谢”，然后去想这个功能本身该怎么设计。接着，我和 Agent 从这个 PR 出发，重新设计整个实现。

Agent 可能会复用一点代码，但更多时候，PR 的价值在于：它帮 agent 理解目标是什么。有时候 PR 也很有用，尤其是涉及一些微妙 bug 的时候。但总体来说，我几乎是重写了每一个 PR，然后把它“织”进系统里。

而且说句实话，现在很多 PR 的整体质量是明显下降的，因为大家在“氛围编程”。但真正做成一个好功能，仍然需要对整体设计有非常清楚的理解。

如果你自己都没这个理解，你就很难驾驭 agent，输出自然也会变差。

Gergely Orosz：对，如果没有一个有效的反馈闭环，就更难了。

Peter Steinberger：没错。在 PSPDFKit 的时候，有些 PR 可能要做一周。你评论一句，对方要切换上下文；然后等 CI 跑 40 分钟……现在不行了。

我会直接讨论这个功能会对系统产生什么影响，让模型先做一轮 review，它通常会点出一些问题。我自己也会有判断。然后我们一起把这个东西重塑成符合我整体愿景的形态，再把代码织进去。

现在我甚至用了很多以前不会用在“写代码”上的词。比如“把代码织进现有结构里”。挺好笑的，但也挺准确。

有时候你甚至得先改结构，才能让功能真正契合。

Gergely Orosz：如果你接下来招一两个人，形成一个小团队，你觉得 Code review、CI、CD 这些东西会怎么变？

Peter Steinberger：我现在已经没那么在意 CI 了。

Gergely Orosz：为什么？你以前可是很在意的，在 PSPDFKit 的时候。

Peter Steinberger：我现在也不是不在意，它还是有价值的。但我现在有“本地 CI”。我有点被 DHH 洗脑了——因为 agent 会跑测试，而且快得多。我不想 push PR，然后等 10 分钟 CI。

Gergely Orosz：毕竟你已经在 Agent 那边等过 10 分钟了。

Peter Steinberger：对。如果本地测试都过了，就合并。当然，有时候 main 分支也会出点小问题，但通常差得不多。

agent 会问我一句：“要不要跑 full Gate？”我也不知道“Gate”这个词是从哪来的，现在我也这么叫了。full Gate 就是：lint、build、所有测试全跑一遍。它就像一道闸门。现在我会说：“好，提交之前跑一下 full Gate。”我甚至开始用 agent 的语言了。

Gergely Orosz：那如果你再招一个人，你大概也不会做传统 Code review 了？

Peter Steinberger：对，我们在 Discord 里基本不聊代码，聊的是架构，是大的决策。

比如最近有个 PR 加了语音通话功能——现在我可以直接跟 Claude 说：“帮我打电话给这家餐厅，订两个位子。”功能很酷，但它是一个会触及很多地方的大模块。

我心里就有点犹豫，担心这是不是开始变成臃肿软件了？所以我下意识的反应是：“那我们能不能把它做成一个 CLI？”

我其实之前就有个没做完的项目，试图解决类似问题。

于是我对 Clawdbot说：“看一下这个 PR，再看一下那个项目，我们能不能把这个功能织进 CLI？利弊是什么？”它会给我一个很坦诚的分析。然后我又说：“但我不喜欢系统变成臃肿怪，我们能不能做插件架构？”

这里有个用 AI 的隐藏技巧： 大量引用你自己和别人的项目。我经常跟它说：“看这个文件夹，这个问题我当时是这么解决的。”

AI 特别擅长读代码、理解你当时的思路。这样我就不用重新解释一遍——而且重新解释反而可能不准确。

这次我就想到了 Mario 做的那个项目（Shitty Coding Agent，名字很糟但东西很好），他用的是一种基于 Type 的 JIT 插件架构。我就直接说：“去看看这个文件夹和那个文件夹。”结果它直接给我设计了一套非常惊艳的插件架构。

当然，本质上也是站在别人肩膀上。那就是我昨晚干的事。

对当代开发者的建议

Gergely Orosz：听起来一切都变了：PR 的角色变了，CI 的角色变了，你不再关注代码细节，而是架构和品味。这是一个非常大的转变。

如果未来你要招两三个人，把这件事做成真正的业务，你会看重什么能力？你会期待什么样的工程师？

Peter Steinberger：我会找那种长期活跃在 GitHub、做开源的人。而且我希望他们是真的“热爱这个游戏”。

在这个新世界里，学习的方式就是不断去试。它真的很像游戏——技能是慢慢练出来的，像学乐器一样。

我现在快到一个夸张的程度了。前几天我一天提交了 600 个 commit。这太疯狂了，但它真的能跑。

甚至有人 code review 之后说：“这居然不是一坨垃圾。”我当时就想：对啊。

Gergely Orosz：因为里面有大量隐性的技能。

Peter Steinberger：没错，这背后是很多硬功夫。你必须不断玩、不断学。

一开始会很挫败，就像第一次去健身房。但很快你就会感觉到：流程变快了，效率提升了，然后你会上瘾。所以就是——玩，但也要拼命干。

Gergely Orosz：你现在投入的时间，比你创业那会儿还多吧？

Peter Steinberger：是的，这是我人生中工作最拼的一段时间。不是因为“必须”，而是因为太好玩了。而且我也很清楚，这是一个窗口期：项目有势能，社区在推着我往前走。

Gergely Orosz：你是不是对“时机”本身也有很强的直觉？知道什么时候是一个可以起势的窗口？你之前说过，现在“公开工作”这件事还很新鲜。你甚至觉得，现在就算你想招人，也很难招到——因为真正公开、熟练使用这些东西的人还不多。但两三年后，等大家都会了，这种优势就消失了。

很多人担心的是应届生、没经验的人。你已经是资深工程师了，有很多积累。如果你站在他们的角度，知道今天这一切，你会建议他们做什么？该打基础，还是该玩 Agent？还是两者结合？

Peter Steinberger：我会建议他们：保持无限的好奇心。

进入这个市场一定会更难，毫无疑问。你必须通过“做东西”来获得经验。但你不一定要写很多代码。你可以去看那些复杂的开源项目，而你身边有一台无限耐心、能给你解释一切的机器。

你可以不停地问：“为什么当初要这么设计？”去建立系统级的理解。

这需要真正的好奇心。而我不觉得现在的大学能很好地教这个。这种东西通常是靠“吃苦”学来的。

对新人来说不会容易。但他们也有一个优势：他们没有被旧经验“污染”。

他们会用 Agent 的方式，是我们根本想不到的。因为他们不知道“这原本是不行的”。等他们用的时候，可能已经行了。

而且他们身边的人都在用。

前几天我有个状态栏小工具，用来统计 Cursor 和 Clawdbot的成本。

有点慢，我下意识想：“好，打开 Instruments。”

结果 Agent 直接在终端里跑了 X-Trace，测性能、优化、给建议。我连 Instruments 都没打开。我直接说：“听起来都不错，照做。”

Gergely Orosz：我们可能低估了新一代进入技术领域的人的适应能力。很多伟大的公司，都是一群很年轻、没什么经验、但极有热情的人做出来的。

不过话说回来，你描述的这些变化确实太大了。PR、code review、CI，这些东西伴随了你十五年以上。它们本来是 PSPDFKit 的基石。

Peter Steinberger：是的，我们需要很多新的东西。即便有人给我提交 PR，我实际上更关心的是 prompt 而不是代码本身。我会请大家把 prompt 一起加上，有些人照做了，而 我读 Prompt 的频率比读代码高得多。

如果有人想要一个功能，我会让他写一个 Prompt Request。写清楚一点，我就可以直接让 Agent 去构建。

因为真正的工作，是把需求想清楚。如果这一步有人替我做了，我几乎只需要说一句“Build”。

所以现在，有人提几个小修复的 PR，我会直接说：“别这样，这比我在 Clawdbot里打一句‘Fix’还浪费时间。”

甚至在最初那段爆发期，我根本没做 onboarding。我让大家直接把 agent 指向仓库，让 agent 自己读、自己配。

Clawdbot 帮 Clawdbot做 onboarding。产品本身就是 Agent 写的，它的结构、命名方式，本来就完全符合 Agent 的预期。所以 onboarding 根本不是优先级。当时的 onboarding 就一句话：“把这个 prompt 丢给你的 agent。”

放在一年前，这听起来都是科幻。