如果你最近关注GitHub热榜，你一定见过这个名字：Clawdbot（现已更名为Moltbot）。
一周内从100星飙到3300星，两周后突破3万星，现在已超过8万星——这是GitHub历史上增长最快的开源项目之一。连Andrej Karpathy都公开点赞，David Sacks也在推特上转发。
更魔幻的是，Anthropic因为"Clawd"和"Claude"太像，发来了商标函，项目被迫改名。改名过程中作者手滑，在释放旧账号和注册新账号之间的10秒空隙，GitHub和X账号都被加密货币骗子抢注，一度引发了一场闹剧。
这个项目的作者Peter Steinberger，绝非无名之辈。他创建的PSPDFKit——那个你在iPhone上看PDF时大概率用到的框架——曾服务于超过10亿台设备。13年后他燃尽、卖掉股份、彻底离开技术圈整整3年。而当他回归时，他的开发方式已经完全变了。
他说自己"一天能有600次commit"，而且"发布的代码我都不读"。
这听起来像是疯话。但当你了解他的完整逻辑后，你可能会意识到：这不是胡闹，这是一套完整的方法论。
一、速度密码：一天600次commit是怎么做到的
1. 同时驾驭5到10个Agent
Peter的工作方式完全颠覆了传统的"写代码-调试-提交"循环。他同时开着5到10个AI Agent，每个在处理不同的任务。
"这就像同时下20盘棋的国际象棋大师，"他说，"你走到每个棋盘前，看一眼局势，做个决定，然后走向下一个。"
他用的主力工具是OpenAI的Codex。为什么不是Claude Code？因为Codex会"沉默地读代码10分钟"，然后给出精准的结果。而Claude Code虽然快，但"往往需要你反复纠正"。
这种并行工作模式需要极强的上下文切换能力。一个任务可能需要Codex运行40分钟，他就切到下一个任务。等回来时，代码已经写好、测试已经跑完。
2. 架构师思维，不是码农思维
"我更像是Builder（建造者），而不是Coder（码农）。"
Peter强调，他不再关心每一行代码长什么样，而是关心系统的整体架构。变量命名、缩进格式、用哪个Tailwind类——这些他全都不管了。
"大多数应用本质上是什么？数据从API进来，换个形态存到数据库，再换个形态显示出来。我们只是在不同形态之间搬运数据。真正难的问题，Postgres的开发者30年前就解决了。"
他的角色从"写代码的人"变成了"设计系统并指挥Agent执行的人"。
3. 本地验证取代远程CI
传统团队依赖远程CI/CD跑测试。Peter说他现在用"Gate"——一个Agent自己发明的词，他也不知道从哪来的，但觉得挺贴切就沿用了。
"提交前，我让Agent跑一遍完整的Gate：lint、build、全部测试。如果本地通过，直接merge。等远程CI 10分钟？不存在的。"
当然，main分支偶尔会出问题。但在他看来，这个代价完全值得。
二、反常识：Code Review已死，PR应该叫Prompt Requests
1. 我看prompts比看代码多
"现在有人给我提PR，我最想看的不是代码，而是他用的prompts。"
Peter的逻辑是：prompts展示的是思考过程——你想解决什么问题、你如何拆解它、你怎么引导AI。而代码只是输出，是结果。
"读prompts比读代码的信息密度高得多。它告诉我：这个人真正理解问题吗？他的思路对吗？"
他甚至直接要求贡献者在PR里附上prompts。
2. 我重写每一个PR
更激进的是，他几乎不直接merge别人的PR。
"有人提交了一个bug修复，只改了几行代码。以前我会review、comment、让他改、等他改完、再review……现在？我直接告诉Codex去fix这个bug，几分钟就搞定。"
对于功能性的PR，他的做法是：阅读PR理解意图，然后用自己的Agent从头实现，按照自己的架构风格"编织进去"。
"Weave in（编织）——这是我现在最常用的词。不是merge代码，是把功能编织到现有系统里。"
3. Vibe Coding的代价
他观察到一个趋势：PR的整体质量在下降。
"很多人在vibe coding，让AI随便生成一通代码，能跑就提PR。但他们不理解整体设计，所以代码和系统格格不入。"
没有系统理解能力的vibe coding，最终产出的只能是slop（垃圾代码）。
三、闭环原则：为什么AI写代码好用，写文章却一般
1. 可验证性是关键
Peter说他发现了一个规律：AI在编程上表现惊艳，但在创意写作上只是还行。原因很简单——
"代码可以编译、可以lint、可以跑测试、可以验证输出。你能闭环。但文章呢？怎么验证一篇文章是不是好的？没有客观标准。"
他把这个叫做"Close the Loop"（闭环原则）。
2. 为Agent设计可测试的架构
这个认知彻底改变了他的架构思路。
"以前我设计系统是为了方便人类理解。现在我设计系统是为了方便Agent验证。"
比如，他在开发Clawdbot时，需要调试一个Mac应用的问题。传统方式是启动应用、手动操作、查看日志。他的做法是：让Agent写一个CLI工具，调用相同的代码路径，然后让Agent自己去调试。
"Agent连续跑了一个小时，告诉我：这里有个race condition，这里有个配置错误，都修好了。"
他甚至没看那些修改，因为测试通过了。
3. 测试不再是负担
"我以前从不喜欢写测试，doc也是。现在？我的Clawdbot有我写过的所有项目里最好的文档和测试覆盖。而我一行都没自己写。"
他只需要和Agent讨论：这个功能怎么测试更合理？边界情况有哪些？文档的入门部分要对新手友好，后面再加技术细节。
四、Clawdbot：AI原生产品长什么样
1. 起源：摩洛哥的那条语音消息
今年在摩洛哥旅行时，Peter用一个简陋的WhatsApp中继和他的AI Agent对话。某天他发了一条语音消息——Agent当时还不支持语音。
30秒后，Agent回复了。
"你怎么做到的？""哦，我看到你发了个文件，检查了header发现是OGG格式，用FFmpeg转换了一下，然后发现你电脑上没装Whisper，但我找到了你的OpenAI API key，就curl了一下它们的服务，转成文字了。"
"那一刻我意识到，这东西太resourceful（足智多谋）了。"
2. 最贵的闹钟
他让Agent在摩洛哥叫醒他。Agent通过SSH连到他放在伦敦的Mac Studio，控制他在当地的MacBook，播放音乐并逐渐调高音量。
"因为我没回复，它就认定'Peter必须起床'，然后开始疯狂给我发消息催我。"
他把这叫做"可能是史上最贵的闹钟"——毕竟每次"心跳"都在消耗tokens。
3. 技术消失的那一刻
Clawdbot现在能做的事情包括：控制智能家居、播放音乐、查看日历、发消息给朋友、代打电话给餐厅订位、分析你发的图片并结合你的日程给出建议……
"技术消失了。你只是在和一个无限resourceful的朋友聊天。它能访问你的邮件、日历、文件，能帮你建网站，能帮你处理行政琐事。所有的技术复杂性都隐藏在后面。"
一周内，GitHub星标从100涨到3300。他说自己感觉像个"人形merge按钮"，因为PR实在太多了。
五、给新人的建议：无限好奇比写代码更重要
1. 你不需要写很多代码
"我不认为你需要写很多代码。但你需要有系统理解能力。"
Peter建议新人去研究复杂的开源项目，用AI作为"无限耐心的老师"来理解它们是如何设计的。
"你可以问所有问题：为什么这样设计？这个模块和那个模块怎么交互？不懂就问，AI会解释到你懂为止。"
2. 这是一个新游戏
"学习这套东西就像学一门乐器。一开始会很挫败，但很快你会感受到进步，然后就上瘾了。"
他把现在的开发比作Factorio（一款关于自动化的游戏）。甚至比Factorio更好玩。
3. 大学还没准备好
"大学目前没有教这些。这类能力需要真正的好奇心，而这通常是你通过实践中的痛苦学到的。"
但他也指出，新人有一个优势：他们没有包袱。
"他们会用我们想不到的方式使用Agent，因为他们不知道'这行不通'——而等他们尝试的时候，可能已经行得通了。"
结语
速度、架构、闭环、编织、Prompt Requests——这些词串起了Peter的整套方法论。
如果用一句话总结他的核心洞察，那就是：当AI能写好代码，人类的价值就从"写代码"转移到了"设计能让AI验证自己工作的系统"上。
这不是偷懒，这是更高维度的勤奋。
正如他自己说的：
"我不自己写代码了，但代码质量反而更好——而我以前写得就已经很好了。"
