#模型时代# 代码是输出，提示词才是工作：Moltbot创始人的AI编程工作流拆解

Clawdbot爆火了之后（当然现在已经因为Anthropic投诉改名了，叫Moltbot）。创始人Peter Steinberger也集中上了一系列播客。@宝玉xp 老师分享了TBPN的一期，我再分享The Pragmatic Engineer的一期。

这期的访谈主题是Vibe Coding，节目的标题很直接："I ship code I don't read"（我发布我不读的代码）。

Peter Steinberger，作为PSPDFKit（一个被超过10亿台设备使用的PDF框架）的创始人，也是最近爆火的开源项目Moltbot的作者，卖掉股份、彻底离开科技圈之后，在2024年4月重新开始写代码。

但这一次，他的工作方式完全变了：他不再亲自写代码，而是同时指挥5-10个AI agent（能自主执行任务的AI程序）并行工作。

不自己写，但是写出来的Moltbot（原名Clawdbot）在2025年1月成为GitHub历史上增长最快的仓库，Google搜索量甚至超过了Claude Code和Codex（两个主流AI编程工具）的总和。

这期播客里，他详细拆解了自己的工作流程、对AI辅助编程的判断，以及为什么传统软件工程的很多做法正在被颠覆。

一、核心原则：闭环（Closing the Loop，让系统能自我验证）

Peter反复强调的核心概念只有一个：让AI能够自己验证自己的工作。

1、为什么AI写代码比写文章强得多？

代码可以编译、可以lint（代码静态检查）、可以执行、可以验证输出。写作没有这种天然的反馈循环。所以用AI写代码时，关键是设计系统让agent能够自己跑测试、自己确认结果。

"这就是为什么这些模型在编程上这么强，但在创意写作上往往一般——因为没有简单的方式来验证写作是否正确。"

2、他怎么做？

做Mac应用时调试很麻烦——要编译、启动、手动操作、观察结果。他的解决方案是：让agent先写一个CLI（命令行工具），调用同样的代码路径，然后agent自己跑CLI、自己调试、自己修复。"我告诉它，你去造一个调试用的CLI，调用所有相同的代码路径，然后你自己迭代修复。它就去煮了一个小时，最后告诉我——这里有个竞态条件（race condition，多个进程同时访问导致的bug），那里有个配置错误。"

最近他给Moltbot加入了多个消息平台支持（WhatsApp、Signal、iMessage、Slack、Discord、MS Teams），每个平台处理tool calling（工具调用，让AI调用外部功能的接口）的格式都有细微差异。以前他手动调试，后来想明白了：让Codex设计端到端测试，启动Docker容器（隔离的运行环境）、安装整个系统、用真实API key调用模型、让模型读图生图再检查输出。跑了很久，但它自己把所有平台的兼容问题都修好了。

3、这个原则如何影响架构决策？

"用agent写代码反而逼着你写出更好的代码，因为你必须更认真地思考架构，让系统更容易被验证。而可验证性本身就会导向更好的架构。"

他现在设计任何新功能时都会先问：agent怎么闭环？怎么让它自己验证结果？这个思考方式自动把他推向更好的系统设计。

二、工作流程：同时指挥多个agent

1、为什么用Codex而不是Claude Code？

Claude Code快，但输出经常第一次跑不通，需要反复调整。而且它会回来问澄清问题，打断你的心流（flow state，全神贯注的高效状态）。

Codex慢——一个任务可能要跑40分钟到一个小时——但它会静静地读10分钟文件，理解整个代码库的上下文，输出几乎总能直接工作。如果你只开一个终端，这种等待确实难以忍受。但如果你同时开5-10个agent并行处理不同任务，整体效率反而更高。

"Claude Code会读三个文件就自信地开始写代码，你得不断推它去读更多代码、看更大的全局。Codex会安静地读文件读10分钟，然后给你的输出几乎总是对的。"

2、他的日常是什么样的？

典型工作日是不断在多个任务之间切换。他会花时间和agent对话，设计一个新子系统或功能的方案。一旦方案敲定，按下"build"，agent去执行，他立刻切换到下一个任务。然后这个在煮、那个在煮、另一个也在煮……他不断轮转，检查结果、微调、再启动新任务。

"通常有一个主项目占据我的注意力，然后有几个卫星项目也需要照顾——我可能在它们上面只花5分钟，它做半小时，然后我再试试看，不需要太多脑力。"

他说这种感觉很像玩星际争霸——你有主基地，也有分矿，你在它们之间不断切换，同时推进。

3、提示（Prompting）就是设计

他不是写完提示就按发送。他会和模型对话：这个功能有哪些实现方案？你考虑过这个边缘情况吗？这样设计和那样设计各有什么取舍？他挑战它、调整它、推回去。等他满意了方案，才说"build"。

"我不让它做什么，它就不会做什么。只要我说'let's discuss'或'give me options'，它就不会动手，直到我说build。"

他甚至会故意写模糊的提示，让agent去探索他没想到的方向。"大概80%的时候出来的东西不行，但有时候会有两个点让我眼前一亮——哦，我没想过可以这样做。"

三、代码审查和PR：旧规则正在失效

1、PR变成"Prompt Request"

Peter说他现在看PR（Pull Request，代码合并请求），更想看的是提示词而不是代码。"提示词告诉我的信息量更大——你是怎么想到这个解决方案的？你问了什么问题？做了多少引导？代码只是输出，提示词才是思考过程。"

他甚至让贡献者把提示词附在PR里。如果有人提交的只是几行小修复，他会说：不用了，我自己打"fix"让Codex跑几分钟更快。帮他省时间的方式是——把功能需求写得非常清楚，他直接把issue指给agent去实现。

2、代码审查已死？

"即使在Discord上，我们也不讨论代码。我们只讨论架构和重大决策。"

他收到PR后的典型流程是：和agent一起从PR出发，然后按照他自己的设计思路重新实现。agent很少直接复用PR里的代码，但PR帮助agent理解目标是什么。

3、CI也变了

他不等远程CI（持续集成，自动化测试流水线）。agent在本地跑测试，测试通过就合并。"我有本地CI。agent跑测试，测试通过，我就合并。是的，有时候main会稍微滑一下，但通常很快就修好。等远程CI那10分钟太久了。"

四、什么人适合这种工作方式

1、两类人的分野

Peter观察到一个明显的分界线：

适应很快的人：关心产品、关心结果、喜欢把东西做出来的人。他们可能不那么在意代码具体怎么写，但非常在意软件用起来什么感觉、能不能解决问题。

适应困难的人：真正热爱解决算法难题、享受亲手写代码的人。这恰恰是AI最擅长的部分，所以这类人会感到很痛苦，甚至抗拒AI工具。

"有些人真的很喜欢解决硬问题，比如算法——他们不喜欢产品那一套，什么营销啊用户反馈啊。他们更喜欢单纯的技术挑战。但这恰恰是AI正在接管的工作。"

2、管理经验反而是优势

Peter认为他在PSPDFKit带过70多人团队的经验，反而让他更容易和AI agent协作。带团队时你必须学会放手，接受下属写的代码不会完全符合你的风格。

"很多人没带过团队，没有这种经历——接受这不是我写的代码，但它能帮我达成目标，接下来我们可以改进它。这种迭代改进的思维方式，正是和AI协作需要的。"

3、你要理解模型怎么"想"

为什么很多资深工程师试用AI后失望离开？因为他们写一个提示、按发送、看到输出、发现不能跑、就判定"这技术不行"。

Peter的观点：你当然不会第一次就写出没bug的代码，模型也不会。你需要设置反馈循环，你需要理解它为什么做出某个选择。如果它用了旧API，可能是因为你没指定macOS版本，它默认用了训练数据里更多的旧版。

"你越理解这些小东西怎么思考，你的提示就越好。这是一种技能，和其他技能一样需要练习。"

五、Moltbot：让技术消失的个人助手

1、起源

Peter一直想要一个"超级个人助手"——不是那种每天早上发邮件说"这是你今天的三件事"的助手，而是一个真正理解你的存在。它会记住你上周和谁见了面，注意到你每次见某个朋友之后心情都不好，主动问你为什么。

2024年夏天，模型还不够好，他搁置了这个想法。但他造了一大堆CLI工具——控制Google、控制床、控制灯、控制音乐——这些成了后来Moltbot的基础设施。

2、为什么CLI而不是MCP？

MCP（Model Context Protocol，模型上下文协议，Anthropic推出的让AI调用外部工具的标准）的问题是：你必须提前把所有函数、所有工具、所有参数说明都加载进session，然后模型发送精确的JSON、拿回JSON。但模型真正擅长的是使用bash（命令行）。

用CLI的话，模型可以用grep过滤、用jq（JSON处理工具）处理JSON、把多个命令串起来。"想象一个天气服务，模型问有哪些城市，拿回500个城市。但它不能过滤这个列表，因为MCP不支持。然后它问伦敦天气，拿回温度、风速、降水、50个字段——但我只想知道会不会下雨。用CLI的话，我可以直接用jq只取我要的字段。"

3、爆发

1月1日，他做了一件"绝对疯狂的事"：把他的agent——对他的电脑有完整读写权限的agent——放进了一个公开的Discord服务器。然后人们亲眼看到他用语音让agent查摄像头、控制家居、放音乐、看屏幕判断其他agent跑完没有。

一周之内，GitHub从100星涨到3300星。"每个亲身体验几分钟的人都上瘾了。这是某种新品类，有点像你当初不理解iPhone的广告、但一摸到实物就懂了的那种感觉。"

六、对未来的判断

1、公司很难高效使用AI

"现有公司要高效使用AI，需要的不只是重构代码库，而是重构公司本身。"

现在需要的是那种有产品愿景、能同时做设计和开发的人——高自主性、高能力——但人数可以大幅减少。"如果我今天重建PSPDFKit，大概只需要30%的人。"

2、人人都会有AI朋友

"未来每个人都会有一个AI朋友——它理解你，了解你的一切，能替你做事，会主动帮你安排事情。需要大量算力，但随着技术民主化，会逐渐普及到所有人。"

3、对新人的建议

"你需要无限的好奇心。学习的方式变了——你可以问一个无限耐心的机器任何问题。你可以checkout（下载）一个复杂的开源项目，问它为什么这样设计，它会解释给你听。但你必须真的想知道。大学目前还没设置好来教这些。"

新人也有优势：他们不会被经验污染，会用老人想不到的方式使用agent——因为他们不知道"这样不行"，而到那时候可能真的行了。

总结

Peter的核心洞察是：代码正在变成输出，提示词才是工作本身。他不读自己合并的大部分代码，但他对系统架构了如指掌。他让agent自己跑测试、自己调试、自己修复，他的工作是设计反馈循环、把握产品方向、做架构决策。

这不是"vibe coding"（氛围编程，指随意让AI写代码不加验证）——他不喜欢这个词。这是一种新的技能组合：你需要系统思维、需要知道什么问题值得问、需要理解模型的思考方式、需要设计能自我验证的系统。写代码的技能变得不那么重要，但理解代码的能力反而更重要了。

核心归纳

Q1: 用AI agent写代码最重要的原则是什么？

闭环（Closing the Loop）。设计系统让agent能够自己编译、运行测试、验证输出。如果agent不能验证自己的工作，你就要花大量时间手动检查。如果它能自己验证，你只需要设定目标然后检查结果。

Q2: 什么样的人能快速适应AI辅助开发？

关心产品结果胜过实现细节的人；有过管理团队经验、学会了"放手"的人；愿意花时间理解模型思考方式的人。相反，如果你特别享受亲手解决算法难题，这条路会很痛苦。

Q3: PR和代码审查还重要吗？

PR的价值变了——看提示词比看代码更有信息量，因为提示词反映思考过程。代码审查在这种工作流里基本消失了，取而代之的是架构讨论。本地测试通过就合并，不等远程CI。