代码是输出，提示词才是工作：拆解 Moltbot 创始人的 AI 编程“异端”工作流
Peter Steinberger 做了一件很多程序员不敢想的事。他公开说：
“I ship code I don’t read.”“我发布我不读的代码。”
他说这句话之前，已经用 13 年把 PSPDFKit 做到覆盖超过 10 亿台设备使用的 PDF 框架，还带过一个 70 多人的工程团队。
2024 年 4 月，他回到一线开始“写代码”。但你现在看到的 Moltbot 代码，大部分不是他写的。
他做的事情只有两件：
- 指挥同时运行的 5 到 10 个 AI Agent
结果非常直接。
Moltbot 在 2026 年 1 月成为 GitHub 历史上增长最快的仓库
后续在公开发布后的短时间内冲到数万乃至十万级 star，在单日增量上创下历史纪录，单日曾突破一万七千星
Google Trends 上的搜索热度一度超过 Claude Code 和 Codex 的总和
如果你现在还在把“用 AI 写代码”当成一个小工具问题，这套工作流会完全改变你的认知。
接下来我们按三个问题来拆解：
一、从“写代码”到“设计闭环”：AI 编程的核心转移
Peter 把自己的工作浓缩成一个词：闭环（Closing the Loop）。
你用 AI 写代码时，有两种做法：
- 把模型当成可以自我验证的执行体，设计一个闭环系统，让它自己写、自己跑、自己改
他选的是第二种。
1. AI 为什么更适合写代码，而不是写文章
你每天用 AI 写文案，感觉它“差点意思”。
但你让它写一个脚本、一个业务接口，效果往往更稳定。
原因很具体：
写文章没有这种“对/错”的物理标准。
你只能靠主观感觉。
Peter 的判断很直接：
“模型在编程上这么强，在创意写作上却一般，因为没有简单方式验证写作是否正确。”
所以如果你想把 AI 真正接入开发，第一件事不是“让它写得更好”，而是：给它构造一个能自我验证的环境。
2. 闭环在他那里的具体长什么样
他不是停在“理念”层面，而是把“闭环”做到非常具体。
案例一：Mac 应用调试
传统做法：
他觉得太慢。
他的做法是让 Agent 先写一个 CLI 调试工具。
操作顺序是：
- 这个 CLI 调用和 Mac UI 相同的代码路径
一个小时之后，Agent 给出结论：
你只需要看结论和补丁。
整个调试循环都在 Agent 内部闭环完成。
案例二：多平台消息支持
Moltbot 后来接了多个平台：
每个平台的工具调用格式都不一样。以前他自己一个平台一个平台地调试。
后来他换了思路，把完整闭环交给 Codex：
跑了很久，但 Agent 自己把全部兼容性问题修完了。
这不是“让 AI 写一点代码”而是：让 AI 拿着一个可重复的实验环境，自行迭代到通过所有验收条件。
3. 闭环如何反向塑造架构
Peter 现在设计任何新功能，只问两个问题：
你可以自己对照一下现在的日常开发。
你是不是会先想：
而他脑子里的优先级是：
他有一句话很关键：
“用 Agent 写代码逼着你写出更好的代码，因为你必须更认真地思考架构，让系统更容易被验证。”
在这套模式里，可验证性直接变成了架构设计的中心约束。
你如果想让 Agent 真正“放手干活”，你就会自然往这些方向改：
你不再只为“人类同事”设计系统，也为“Agent 同事”设计系统。
二、多 Agent 并行：真正的生产力来自“指挥”，不是“代写”
很多人在用 AI 写代码时一个常见体验是：
“模型写得还行，但是调起来很烦，很打断节奏。”
Peter 的解决方案，有两层：
- 工具选择：他更偏向 Codex 而不是 Claude Code
- 工作流设计：他永远不等单个 Agent“跑完”，而是多线程指挥
1. Codex 和 Claude Code 的差别，在他眼里非常清楚
他对两个工具的评价很具体：
如果你只开一个终端，等 Codex 跑 40 分钟，体验确实很差。
所以关键不在“谁快”，而在你怎么组织自己的时间。
2. 他的日常，接近一个 RTS 指挥官
他自己形容，这种感觉很像玩星际争霸。
他的节奏是这样的：
- 他马上切到另一个窗口，对第二个 Agent 做同样的事情
- 同一时间，可能有 5 到 10 个 Agent 在“煮”不同任务
对你来说，最关键的启发是：
你不需要节省模型的时间，你需要节省的是你自己的注意力。
你不必盯着一个 Agent 的所有操作细节。你只需要：
3. 提示词不是“命令”，而是完整的产品设计对话
他的提示词习惯，也和很多人完全不同。
他不会“写一个长 prompt 按发送”。他的模式更接近产品设计评审：
他明确说：
“我不让它做什么，它就不会做什么。只要我说 ‘let’s discuss’ 或 ‘give me options’，它就不会动手。”
更有意思的一点是，他会故意写模糊的提示。
目的不是偷懒，而是看模型能不能提出他没有想到的设计方向。
他大概的“命中率观感”是：
这部分对你的直接启发很清晰：
- 你要擅长问“还有别的方案吗”“这种做法在什么场景会坏掉”
你和模型的关系，更像一个资深架构师和一个超快实习生。
三、PR、代码审查和 CI：老规则在快速失效
在 Peter 的世界里，PR 已经不再是代码 diff 的容器。
他直接给 PR 换了全称：Prompt Request。
1. 他看 PR，看什么
他说他现在看 PR，最关心的只有两样东西：
原因很简单：
所以他会要求贡献者在 PR 里附上：
如果只是一个小修复，他甚至会拒收：
“不用了，我自己打一行 ‘fix’，让 Codex 跑几分钟更快。”
你真正能帮他的，是：
- 把功能需求写成可以直接喂给 Agent 的 issue
那样他只需把 issue 丢给 Agent 就能跑起来。
2. “代码审查”这个传统流程，在这里几乎消失
在他的 Discord 社区里，你很难看到传统意义上的“代码讨论”。
他们只讨论：
PR 里的代码，本质上只是一个“当前快照”，还会被 Agent 重写。
他的常规做法是：
- 最终合并的是 Agent 基于 PR 意图输出的新代码
这样的结果是：
3. CI 从云端回到本地，由 Agent 完整跑通
他不等远程 CI。
流程非常简单：
他承认：
这种做法的前提是：
如果你现在的项目：
那你在 AI 时代会非常痛苦。
因为你所有“安全感”都建立在自己肉眼看过代码上。
Peter 已经把“安全感”迁移到了：
你可以据此回看自己的团队流程：哪一部分已经过时。
四、谁会在这波 AI 开发浪潮里快速上手
Peter 观察到一个很现实的分野。
1. 适应很快的一类人
特点很清楚：
他们看 AI Agent 的方式是：
这些人往往在：
2. 适应很难的一类人
也很典型：
遗憾的是：
“他们最喜欢的，正好是 AI 最擅长接管的部分。”
当一个模型可以在几分钟内刷完你需要一小时思考的算法题，你原来构建自我价值感的那一块，会被正面撞击。
如果你不愿意把注意力往“产品、架构、系统级闭环”迁移，这条路确实会很痛。
3. 管理经验，反而成了技术优势
这点很少有人意识到。
Peter 的核心经验在于，他带过一个 70 多人的工程团队。他已经习惯了这样一种心态：
他强调：
“很多人没带过团队，没有这种经历。接受这不是我写的代码，但它能帮我达成目标，接下来我们可以改进它。”
你如果做过团队管理，现在需要做的只是：
- 把“1 对 N 人”替换成“1 对 N 工具进程”
团队经验会帮你快速接受以下事实：
- 你和 Agent 的关系，更像“组长和新人”而不是“IDE 和插件”
4. 新人反而有一手“经验优势”
对刚入行的一代来说，反而有一个天然优势：
Peter 的建议很直接：
- 你现在可以随便 checkout 一个复杂的开源项目
但前提是：
你“真的想知道”。
如果你只是把模型当成“作业代写工具”，你会错失它作为“无限耐心老师”的那一面。
五、Moltbot 的真正野心：让“操作技术”从你的视野里消失
很多人把 Moltbot 当成“很强的本地 AI 助手项目”。Peter 背后的愿景其实更激进。
1. 他想做的，不是一个“效率工具”
他对白日梦里的“超级个人助手”描述得很细。
- 它能操作你所有数字世界里的事：邮件、日程、家居、摄像头、音乐
2024 年夏天，他判断当时的模型水平还不够支撑这个愿景。
他先做了另一件事：把所有东西 CLI 化。
包括：
这些 CLI 后来统统成为 Moltbot 的“肌肉”。
2. 他为什么坚持用 CLI，而不是 MCP
你可能已经在别的地方看到 MCP（Model Context Protocol）。
它的设计思想是：
- 模型根据 schema 发出严格格式的 JSON 调用
Peter 不喜欢这种方式，原因很工程师：
他观察到一个更简单的事实：
模型天然很会用 bash。
用 CLI 的好处很直接：
一个他常用的例子是天气查询：
- MCP 模式下，你拿到 500 个城市列表，却没法自己过一遍筛选
这件事的深层含义是：
他不是在围着模型改世界，而是在改造世界去适配模型最擅长的交互方式。
3. 真正让 Moltbot 起飞的，是一次“公开暴露内循环”的实验
2026 年 1 月 1 日，他做了一件在很多安全工程师眼里近乎疯狂的事情：
任何人都能在里面看到：
短短一周时间，Moltbot 的 GitHub star 从 100 涨到 3300。之后又在多次媒体曝光后冲上几万乃至近十万。
很多人现场体验几分钟之后，都会产生一个共识：
这不再是“一个工具”，而是一个新物种。
这也是为什么 Moltbot 会在 GitHub 上创下极短时间冲到数万 star 的纪录，并在多篇分析文章里被称为“史上增长最快的开源 AI 项目”。
六、你现在可以怎么实操地改变自己的工作流
把上面的内容压缩成对你有用的行动指南，可以归纳成四个方面。
1. 从今天开始，刻意练习“闭环思维”
下次你要做一个功能，可以先问自己三件事：
你可以先从小处开始：
- 让 Agent 写 CLI，而不是直接改你的 UI 代码
只要你做到“让 Agent 能自己证伪自己”，你就已经迈进这套工作流了。
2. 重新设计你和模型的对话方式
你可以做一个简单的约定：
- 把 build 视为一个单独的阶段，而不是顺手的一句话
多问三类问题：
- 如果我要让另一个 Agent 在这上面扩展，最好的抽象边界在哪里
你在做的事，是把“提示词工程”升级成“系统设计”。
3. 把 PR 写成 Prompt Request
你可以在自己的团队里试着做三个调整：
- 用一段文字清楚写出“问题是什么”“你怎么和模型对话”
- 在 code review 里减少命名、格式争论，更多讨论架构和边界
你的目标是：
- 让未来的你或 Agent 可以复用这条路径，而不是只看一堆 diff
4. 有意识地从“写代码”转向“设计系统”
在这套世界观里，价值权重出现了明显变化：
如果你现在还完全沉迷在“我一定要手写每个算法”的爽感里，很可能会在未来几年里越来越难受。
你可以保留对“手写代码”的热爱，但最好把它从“谋生技能”升级为“个人爱好”。谋生这块，越快把自己训练成一个擅长指挥 Agent 的“系统设计师”，你越安全。
一点思考：代码是输出，提示词才是工作
Peter 已经用自己的实践给出一个很清晰的未来图景：
对你来说，现在最现实的一步，就是在自己的项目里选一个小功能，按照“闭环优先”的原则重新设计一次开发流程。
当你第一次看到一个 Agent：
你就会明白，他说“我发布我不读的代码”，不是一句玩笑。
而是一种你也可以学会的新工作方式👇：
