最近看到一个很刺激的数据：73 天，9625 次提交。
更离谱的是，这不是一个 demo，也不是一个几百行的小玩具，而是一个叫 OpenClaw 的多平台 AI 消息助手网关项目。它覆盖 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等十多个聊天渠道，还有 macOS、iOS、Android 客户端、语音唤醒引擎、Web 控制台、插件 SDK，以及完整的工程化基础设施。
其中核心作者 Peter Steinberger 一个人贡献了绝大多数提交。
第一反应通常是：这不科学。
第二反应是：这大概不是“一个人更拼”，而是“开发范式变了”。
真正值得研究的，不是他写了多少代码，而是他如何组织 AI 写代码。
这套方法论可以概括成四个关键词：
- 规格驱动
- 闭环验证
- 多 Agent 并行
- 自动化护栏
它本质上不是“让 AI 帮你写代码”，而是把开发流程重构成一种更适合 AI 的生产方式：人负责定义问题和约束，AI 负责高密度执行。
一、AI 原生开发的核心转变：人写规格，AI 写实现
很多人第一次用 AI 写代码，直觉都是一句话丢过去：
“帮我做个 xxx。”
然后进入经典流程：AI 猜你的意图，写出一版半对半错的代码，你再补充需求，它再改，几轮之后上下文开始发散，架构开始飘，最后你自己接管残局。
Peter 走的是完全相反的路线。
他的典型指令甚至简单到有点荒唐：
Build spec.md
不是直接让 AI“实现需求”，而是让 AI 按一份已经定义清楚的规格文档去施工。
这个思路的关键在于：
AI 并不擅长在模糊目标下做稳定决策，但非常擅长在明确约束下高速执行。
1. spec 不是“需求描述”，而是施工蓝图
这里的 spec，不是几行需求说明，而是接近 Software Design Document 的东西。它通常会明确写清楚：
- API 设计和输入输出结构
- 状态流转和边界条件
- 数据模型与字段约束
- 错误处理与重试策略
- 与现有模块的交互方式
- 向后兼容要求
- 并发、超时、空输入等异常场景
写到这种程度之后，AI 几乎不需要“猜”。
这件事特别重要。因为传统开发里，设计者和实现者往往是同一个人，脑子里没写出来的部分，可以靠经验脑补。但 AI 不会读心。你没写清楚的地方，它一定会自己补全，而补全出来的东西，常常会带来返工。
所以高质量 spec 的本质，不是形式主义，而是把错误前移。
你不是在写文档，你是在提前消灭歧义。
二、先别急着编码，先让另一个 AI 帮你把规格打磨到足够清晰
这里有个很有意思的细节：Peter 的 spec 往往也不是自己纯手写出来的，而是借助另一个更擅长“长上下文分析”的模型来完成。
大致流程可以理解为三步：
第一步：先喂上下文
把项目代码库、相关参考实现、模块结构、已有接口等内容打包给长上下文模型，让它先理解现状。
第二步：让模型产出第一版设计稿
这时候模型负责的不是“直接写代码”，而是：
- 梳理当前架构
- 分析依赖关系
- 对比类似项目的实现思路
- 产出一版 SDD 初稿
第三步：开新对话，让模型扮演挑刺 reviewer
这一步特别妙。
不是拿到草稿就开工，而是换个上下文，要求模型专门找问题：
- 哪些地方定义不够清楚？
- 哪些边界情况漏掉了？
- 哪些设计决策会导致实现阶段出问题？
- 哪些模块耦合过重？
- 哪些异常路径没有说明？
经过几轮来回，spec 可能会变得很长，但也会变得足够明确。然后才交给 Claude Code 这类更偏执行型的工具去实现。
这个分工非常值得借鉴：
- 长上下文模型负责“想清楚”
- 代码型 Agent 负责“做出来”
不要试图让一个模型同时兼任产品经理、架构师、工程师和测试负责人。那会把上下文搅成一锅电子浓汤。
三、最反直觉的一点：写代码可能只占整个流程的一小部分
如果把这套方法拆开看，会发现一个很反常识的事实：
真正花时间的，未必是编码，而是规划、约束、验证。
很多人以为 AI 开发的价值在于“把写代码提速”。
但这套工作流更像是：把实现阶段外包给 AI，把人类时间集中用在高杠杆决策上。
也就是说，人类不再主要扮演“代码敲击者”，而更像：
- 架构师
- 规格编写者
- 验证系统设计者
- 多 Agent 调度员
这听着像官话，但本质很朴素：
你不再亲自搬砖，而是负责把施工图、验收标准和工地规则制定好。
四、“我发布我没逐行读过的代码”为什么没有翻车
这套方法里最刺耳、也最容易被误解的一句话是：
I ship code I don’t read.
如果没有上下文，这句话像极了准备把线上服务送进火山口。
但它成立的前提不是“盲信 AI”，而是构建了一套 AI 自写、AI 自测、机器自动拦错的闭环系统。
换句话说，他不依赖“人工逐行 review”来保证质量，而依赖自动化验证链条。
五、闭环验证：不要让 AI 只负责产出，还要让它负责自证
这套闭环的核心，是给 AI 一份操作手册。比如仓库里维护一份 CLAUDE.md 或 AGENTS.md，专门告诉 Agent：
1. 代码库的基本规则是什么
- 源码放在哪里
- 测试文件放在哪里
- 插件目录在哪里
- 命名风格怎么统一
- 文件应该控制在什么规模以内
这可以避免 AI 在错误位置创建文件，或者越写越散。
2. 有哪些硬性禁令
例如：
- 不能修改某些依赖
- 不能碰
node_modules - 不能自动改版本号
- 不能提交真实手机号和线上配置
- 不能把中间流式结果发到外部聊天渠道
这些看起来像小事，但对连续工作数小时的 Agent 来说，这种明确的红线非常必要。AI 有时会“自作聪明”，而工程事故往往就是从这种“看起来合理”的越权开始的。
3. 每次任务必须走的验证循环
典型闭环通常是：
写代码 → 编译/构建 → 跑测试 → 看日志 → 修复 → 再跑一轮
直到所有检查都变绿。
这就是为什么“我不逐行读代码”在这里不是胡来。
因为质量控制从“人眼检查”切换到了“系统性验证”。
当然，这个前提极其重要：测试必须有价值。
如果测试本身很水，那绿色也只是一种高科技幻觉。
六、测试最好和实现分离，别让同一个 AI 自己给自己判卷
这是一个很值得抄作业的实践：
- 一个 Agent 根据 spec 写测试
- 另一个 Agent 写实现，目标是通过这些测试
为什么这样更稳？
因为如果同一个 AI 同时写测试和实现，它有很大概率会让测试去迁就实现。测试不再是“约束预期行为”，而变成“描述我已经写出来的东西”。
这就像学生自己出题、自己判卷、自己写奖状，味道很不对。
把测试和实现分开，可以显著减少这种“自洽式作弊”。
七、多 Agent 并行，本质上是在把一个人变成一个小型技术团队
Peter 的一个典型工作方式，是同时开多个 Claude Code session：
- 有的负责主功能开发
- 有的负责测试
- 有的负责 UI 微调
- 有的负责日志排查或小 bug 修复
这不是炫技，而是非常实际的生产方式。因为当 Agent 能独立在一个明确任务上持续推进几个小时之后，人的角色就从“写代码的人”变成了“派工的人”。
于是一个人可以像带小组一样工作：
- 给任务
- 设边界
- 看计划
- 做取舍
- 合并结果
这和传统意义上的 pair programming 完全不同，更像是你有了一支不会累、但需要强约束的数字施工队。
八、大改动之前先只读规划，别一上来就让 AI 动刀
这套流程里还有一个非常实用的习惯：Plan 模式优先。
也就是在重大改动前，先让 AI 只读项目，理解代码结构，输出实施计划，而不是立刻改文件。
计划里最好包括：
- 要改哪些模块
- 可能影响哪些接口
- 任务拆分顺序
- 主要风险点
- 回滚策略或兼容性注意事项
这个步骤会多花几分钟，但能避免 AI 一头扎进错误文件里猛改，最后牵一发而动全身。
大项目里最贵的不是写代码，而是在错误方向上写了很多代码。
九、一个很实在的经验：CLI 往往比花哨的 Agent 集成更靠谱
文中还有一个挺反直觉的工程决策：他后来移除了很多 MCP 类集成，转而更依赖传统 CLI。
原因很简单：
- CLI 成熟、稳定、快
- 上下文开销小
- 可脚本化程度高
- 更容易写进 Agent 操作手册
比如：
- 查部署状态用
vercel - 操作数据库用
psql - 查 GitHub 用
gh - 查日志用对应 CLI
对 Agent 来说，一个可预测的命令行接口，经常比复杂的工具生态更好用。
别被“更智能的集成”这几个字骗了，很多时候只是增加了不必要的上下文噪音。
十、OpenClaw 的架构演进很能说明问题：AI 让重构成本下降了
如果顺着项目时间线看，会发现它不是一开始就有完整平台架构，而是经历了几次关键跃迁：
- 从单文件 CLI 开始
- 再到模块化 CLI
- 然后引入 Gateway 控制平面
- 再演进到插件 SDK
- 最终变成开放平台
这个过程里最关键的，不是“架构设计得多完美”，而是重构发生得足够早。
传统开发里，很多人明知架构快顶不住了，也会因为改造成本太高而继续硬撑。AI 把实现层面的迁移成本压低之后，架构调整的心理门槛也降低了。
于是更容易做到一件重要但常被忽略的事：
在问题刚露头时重构，而不是等系统快爆了才重构。
这是一种非常贵的工程判断力。
AI 只能帮你便宜地执行它，不能替你做判断本身。
十一、真正支撑高速度的，不是 AI，而是护栏
如果开发速度真的提升到一天上百次提交，最重要的问题就不再是“如何写得更快”，而是：
如何防止错误以更快速度扩散。
OpenClaw 这类项目之所以没变成高速事故现场，靠的是一整套层层递进的护栏体系。可以粗略理解成六层：
第一层：Agent 行为规则
用 AGENTS.md 明确工作边界、禁令、目录结构、并发协作规则。
第二层：Lint 和格式化
统一代码风格，减少 AI 生成代码风格漂移。
第三层：Pre-commit Hook
提交前自动检查：
- 行尾空格
- 文件结尾换行
- 合并冲突残留
- 大文件误提交
- 密钥泄露
- Shell 脚本语法
- GitHub Actions 配置问题
第四层：TypeScript strict
这是最便宜、回报率最高的一层。
开启 strict 之后，大量类型不明确、空值处理不当、接口不匹配的问题会在运行前被拦住。
对于 AI 生成代码来说，这种约束尤其重要，因为它很容易写出“看起来合理但边界不严谨”的实现。
第五层：测试
阻止逻辑错误进入主干。
第六层：CI
作为最终防线，在 push 和 PR 阶段统一执行类型检查、lint、测试、格式校验。
十二、速度越快，越不能相信“人工兜底”
这是很多人会忽略的地方。
当提交密度很高时，人工 review 不再是主要质量保障手段。不是因为人工 review 没价值，而是因为它跟不上吞吐量。
你一天 5 次提交，手动 review 很自然。
你一天 50 次提交，还想靠人肉兜底，就已经有点像拿网兜接瀑布了。
你一天 100 多次提交，还不自动化，那工程事故只是时间问题。
所以这套方法的核心不是“AI 让人少看代码”，而是：
必须把“看代码”替换成“看系统是否通过验证”。
这才是规模化 AI 开发真正可持续的地方。
十三、这套方法论最厉害的地方：它甚至能反过来控制编码 Agent
OpenClaw 还有个很妙的设计：它不只是一个 AI 消息网关，还能从手机上远程调度 Claude Code。
也就是说，你在 Telegram 或 WhatsApp 里发一条消息，它就能在远端机器上拉起一个 Claude Code session，指定任务、跟踪进度、再把阶段性结果发回给你。
这背后的分层思路很有意思：
- 轻量 Agent 负责沟通、调度、权限和生命周期管理
- 重量 Agent 负责真正昂贵的编码和测试执行
这比让一个 Agent 什么都干更清晰，也更经济。
本质上，这是一个“Agent 管 Agent”的架构。
听起来有点赛博包工头，但确实合理。
十四、这套方法并不万能，它有明显边界
说了这么多，也得泼点冷水，免得把它讲成 AI 炼金术。
1. 它依赖问题足够清晰
如果你做的是探索性原型、用户研究、产品方向试探，连你自己都不确定目标长什么样，那 spec-driven 这套流程就不成立。
它更适合的是：
- 需求已经明确
- 约束条件清楚
- 输出可以被工程化验证
2. 它依赖可自动验证
代码天然适合这套流程，因为你有：
- 编译器
- 类型系统
- 测试框架
- CI
- 日志和运行时观测
但如果你的产出是文案、设计方案、商业策略，自动化闭环就很难建立。
这时“AI 自证正确”会弱很多。
3. 它依赖测试质量
“Ship code you don’t read”这件事，成败几乎全压在测试质量上。
测试写得差，整套系统就是纸糊的。
4. 它依赖强工程判断力
这是最关键的一条。
Peter 的优势不只是会用 AI，而是本来就有很强的架构直觉、工程经验和质量意识。AI 放大了他的能力，但放大的前提，是原本方向就对。
AI 像杠杆。
杠杆不会帮你决定往哪撬，它只会把你的判断成倍放大。
方向对了，飞快推进；方向错了，更快冲进沟里。
十五、真正值得学的，不是“让 AI 替你写代码”，而是重构你的开发职责
看完整套方法，最有价值的启发其实不是某个工具，也不是某句 prompt，而是一个角色变化：
过去你是：
- 写代码的人
- 修 bug 的人
- 手动 review 的人
现在你更应该成为：
- 写规格的人
- 设计验证闭环的人
- 设定护栏的人
- 调度多个 Agent 的人
- 做架构决策的人
这才是 AI 原生开发真正的变化。
不是“程序员要被替代”，而是“程序员最值钱的部分正在上移”。
从实现细节，转向意图表达、系统设计、约束管理和质量控制。
说得再直白一点：
AI 最适合替你干已经想清楚的事，不适合替你想清楚本该由你负责的事。
结语
73 天、9625 次提交，这种数字看起来像神话，拆开之后其实没有那么神秘。
支撑它的不是某个魔法模型，而是一整套很扎实的工程方法：
- 用 规格驱动 消灭歧义
- 用 闭环验证 替代人工逐行检查
- 用 多 Agent 并行 提升吞吐
- 用 自动化护栏 控制风险
最底层真正稀缺的，依然是工程判断力。
AI 能让一个强工程师变得更可怕。
但它不会自动把模糊的思路变成好系统，也不会替你承担架构失误的代价。
所以这套方法论最值得记住的一句话，不是“AI 写代码有多快”，而是：
先把事情想清楚，再让 AI 以工业化的方式把它做出来。
这才是味道最正的 AI 开发。
