OpenClaw 创造者的 AI 编程工作法：部署自己没读过的代码，单人 6600 次提交

一句话结论

OpenClaw（原名 Clawdbot）创造者 Peter Steinberger 一个人在 2026 年 1 月提交了超过 6600 次——他公开的核心工作法是”部署自己没读过的代码”：不逐行审查 AI 产出，而是设计让 agent 能自己编译、测试、验证的闭环系统，把人的精力全部押在规划与架构上。

OpenClaw 是 2026 年初 GitHub 涨星最快的项目，Google 搜索量一度超过 Claude Code 与 Codex 之和。The Pragmatic Engineer 主理人 Gergely Orosz 在伦敦与 Peter 深谈近两小时，总结出十条可复制的工程方法。

他的背景决定了这套方法

Peter 不是 AI 时代才冒出来的新锐：他创立的 PSPDFKit 做成了一家全球开发者工具公司，带过 70 多人的团队，然后休息三年，回来重新写代码——这次把 LLM 和 AI agent 放在工作流正中央。

他对自己的定位很清醒：

“从提交记录看，这像是一家公司在干活。但不是。这是一个人坐在家里找乐子。”

主持人的观察是：Peter 更像一个软件架构师——高层结构始终在他脑子里，深度关心架构、技术债、可扩展性和模块化。OpenClaw 成功的原因之一正是它的可扩展性：Peter 花大量精力让给机器人加新能力变容易，同时充当项目”仁慈独裁者”，确保方向与风格统一。

十条工作法逐条拆解

1. 管理开发团队教会你放下完美主义

在 PSPDFKit 带 70+ 人时，Peter 被迫接受”代码不会永远符合我的个人偏好”。这个肌肉直接迁移到与 AI agent 协作：不纠结 AI 产出的风格细节，只看闭环结果。

2. 闭环：AI agent 必须能验证自己的产出

这是整套方法的地基。Peter 设计系统时确保 agent 能自己编译、lint、执行、校验输出——agent 发现自己的错误并修复，人不需要当审查员。

3. Pull request 已死，“prompt request” 万岁

Peter 现在把 PR 看作 “prompt requests”：他更关心生成代码的那条提示词，而不是代码本身。无独有偶，Craft Docs 的架构师（Gergely 的弟弟 Balint）也用同样的逻辑——几乎拒绝所有外部 PR，但把 PR 的核心想法当作 prompt 留待日后自己实现。

4. 代码评审死了，架构讨论接替它

即使在 Discord 里，Peter 与核心贡献者也不聊代码，只聊架构和大决策。审查的对象从”这几行对不对”升级为”这个结构对不对”。

5. 同时跑 5-10 个 agent，保持心流

Peter 会排队多个 agent 并行做不同功能。他是重度规划者：花出人意料长的时间与 agent 来回打磨计划——挑战它、修改它、推倒重来。计划满意后才踢一脚启动，然后转向下一个。工具选择也服从这个模式：他偏好 Codex，因为 Codex 适合长时间自主运行；Claude Code 会中途回来问澄清问题，在计划已经打磨完备的前提下这反而成干扰。

6. 故意”欠提示”，探索意外解法

Peter 有时刻意给模糊的提示，让 AI 探索他没想到的方向。这是反直觉的一条：提示词工程的常见建议是精确、给上下文、给约束，但当你已经建立了自动验证闭环，模糊提示的下行风险被闭环兜住，上行空间是发现你自己想不到的方案。

7. 本地 CI 打败远程 CI

agent 直接在本地跑测试，而不是等远程 CI 流水线 10 分钟。理由很直接：agent 可以立刻拿到测试结果自我修正，远程 CI 的反馈延迟会打断 agent 的自我纠错循环。

8. 大部分代码是无聊的数据搬运

Peter 认为应用代码的主体只是”把数据搓成不同形状”，不值得投入 obsessive 的注意力——精力应该花在系统设计上。

9. 享受解题的工程师会被 AI 折磨，享受交付的工程师会起飞

Peter 观察到：热爱算法谜题的工程师在”AI 原生”转型中最挣扎；热爱把产品推向市场的人则如鱼得水。

10. 软件工程没有死，恰恰相反

Gergely 的总结：Peter 是”AI 时代依然成立的软件工程”的活证据——架构、技术债、模块化这些经典判断力的价值被放大了，被替代的只是打字环节。

Peter 自己的解释更彻底：

“我一直把代码当作把脑子里的东西弄出来的必要工具。代码从来不是我的快乐来源——触碰软件才是。以前心流状态下一口气写一两千行没问题，但即使那时我也被打字速度卡住：我想得比打得快。所以现在我极度开心——原型和迭代终于能跟上思考速度了。“

使用这套方法的前提

主持人明确提醒了适用边界：Peter 在做一个实验性、快速迭代的项目，“move fast and break things”是这类项目唯一能成功的路。把他的做法直接照搬到航空、医疗或金融生产系统上并不合适——但”设计能自我验证的系统”这个方向本身，对所有用 AI 写代码的团队都成立。

这套方法的本质可以压缩成一句：人负责方向和结构，机器负责实现和验证，闭环系统替代人工审查。

原文信息

• 原文标题：The creator of Clawd: “I ship code I don’t read”
• 作者：Gergely Orosz（@GergelyOrosz），The Pragmatic Engineer 主理人
• 发布日期：2026-01-28 原文地址：https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code

阅读原文

原文链接：https://www.jxxy.net/ai/articles/openclaw-creator-ship-code-unread/