一个人，一年 17 万次 GitHub 贡献：拆解 steipete 的「AI agent 车队」开发模式
一个人，过去一年在 GitHub 上留下 171,946 次贡献，单日最高 921 个 commit（约每 94 秒一次），一天 24 小时几乎没有作息波谷。这不是超人，也不是刷数据——是「一个人 + AI agent 车队」这种新开发范式在贡献图上的投影。本文用直接查 GitHub API 得到的硬数据，配上他自己开源的 OpenClaw 仓库里的真实工程机制，把这套模式拆开看清楚。
主角是 Peter Steinberger（GitHub ID steipete），开源 AI 助手（小龙虾）OpenClaw 的作者与长期主导者（BDFL）——本文引用的工程机制大多来自这个由他一手起步、如今已成长为基金会托管的大型开源项目。下面所有以「实测」标注的数字，都是我在 2026 年 7 月直接用 GitHub API 和 bare clone 统计出来的，不是二手引用；凡是来自采访和报道的说法，我都会明确标注来源，请自行判断可信度。
17 万次贡献的数字拆解
先看这一年（截至 2026-07-04）的构成（实测，GitHub GraphQL API）：
| 构成 | 数量 | 占比 |
|---|---|---|
| 私有仓库贡献 | 112,347 | 65% |
| 公开 commit | 56,503 | 33% |
| 公开 PR / review / issue | 3,012 | ~2% |
| 合计 | 171,946 | 100% |
平均每 3 分钟一次贡献，全年无休。公开部分的主力是 openclaw/openclaw——这个仓库创建仅 7 个多月，就累计了 64,066 commits / 56,290 PRs / 41,562 issues（实测）。
真正能证明「这是机器在跑」的，是数字的形状，而不是绝对值：
- 节奏超人类极限：他署名的 commit 单日峰值 921 个，相当于连续 24 小时每 94 秒提交一次。
- 时间分布「机器平」：按小时统计，凌晨 0–5 点的产量（每小时 1,300–1,900）甚至略高于白天。人类作息不可能是这个形状。
- 97% 是本地直推 main：他 32,548 个 commit 里只有 986 个走 GitHub squash merge，其余 31,551 个是在他的机器上以他的 git 身份直接 push。也就是说这些量不是「帮别人合 PR 蹭出来的」，而是运行在他账号下的 agent 生成并提交的。
- 月度曲线拐点清晰：2026 年 4 月 8,090、5 月 8,660，6 月骤降到 1,023——正好对应他加入 OpenAI、项目移交基金会的时间点。
结论很直接：GitHub 的贡献统计只认 git 身份，agent 用他的邮箱提交，就都算在他头上。17 万这个数字是真实的，只是背后是「一个人指挥的一支 AI 车队」在昼夜不停地产出。
核心范式：把自己从「写代码的人」重构成「设计系统的人」
steipete 有一句被广泛引用的话（来自他的公开表态）：
“你不该再去 prompt 你的 agent 了。你该去设计那个 prompt 你 agent 的 loop。”
据 Pragmatic Engineer 的采访（标题就叫 “I ship code I don’t read”，我发布我不读的代码），他的方法论本质是三次认知翻转：
- 从「写代码」到「写 prompt」——他把 PR 重新叫作 “prompt requests”，认为真正的产物是生成代码的 prompt，代码只是它的编译结果。
- 从「追求完美」到「放弃完美主义」——他说这项技能来自当年带 70 人团队的经验：你读不完每个人的每一行，你转而信任流程。跟 agent 车队协作是同一件事的放大版。
- 从「人是瓶颈」到「人是路由器」——他自称项目的 benevolent dictator（仁慈独裁者），在脑子里维护高层架构，把执行全部下放。
必须强调一个反直觉的事实：这不是「裸奔式 vibe coding」。恰恰相反，我读了 OpenClaw 的 AGENTS.md——那是一份宪法级的硬策略文档，用极度浓缩的电报体，把架构边界、依赖契约、存储规则（比如「运行态一律 SQLite，禁止散落 JSON 文件」）、修复的形态全部写死，给 agent 当约束。「不读代码」的前提，是「把判断标准写进规则、交给机器执行」。
需求从哪来：四口进料 → 归一队列 → 自动分诊 → 人把最后一道关
在这套模式里，人被砍掉的是「执行」，被刻意保留的恰恰是「决定做什么」。据报道，他试过把决策也自动化，结果是「产出一堆 slop（垃圾）」，所以他把人牢牢钉在需求决策这一步。需求供给是一条有结构的流水线：
四个进料口（原始需求来源）：
- ① Dogfooding（最大源）：他自己把 OpenClaw 当私人助理天天用，用中踩坑就地开 issue。实测最近 30 个 issue 里他一个人提了 9 个，是所有人里最多的。
- ② 真实用户反馈：产品有真实用户，bug 从各渠道涌入。实测近期 issue 一堆是实战问题——webchat 会话静默死掉、LAN 下消息乱序、移动端重连丢会话。
- ③ 机器自检：仓库里的
taxonomy.yaml是一份「成熟度记分卡」，把整个产品拆成几十个子系统逐个评分，系统性地暴露「哪个子系统还不达标」——这本身就在自动生成需求。 - ④ 多收件箱聚合：据其自述，一个 agent 定时把 email / Slack / GitHub / Linear 的东西拉出来汇总成待办。
归一化：这四个口进来的东西先被一个 agent 收敛成统一的 issue 队列。ISSUE_TEMPLATE/ 里的模板把外部反馈强制结构化成可入队的形状。
自动分诊：需求进队后先过一层机器分诊（由 ClawSweeper 这套 AI review 系统完成）。看真实 issue 的标签就懂了——它会自动打上 clawsweeper:queueable-fix（可排队自动修）/ fix-shape-clear（修法明确）/ needs-product-decision（要人拍板）/ P1-P2 优先级 / impact:message-loss 影响面，甚至有个稀有度评级 issue-rating: 🦞 diamond lobster。这层的作用是把「人该看的」和「机器能直接吞的」分开。
人的最后一道关：他按优先级过一遍队列，决定做不做、怎么做，然后把执行撒手交给车队。需求的执行可以全自动，需求的筛选和定义必须留人——这是整套模式的边界线。
编排与质量：5–10 个 agent 并行，靠「自验证」而非「人眼」兜底
- 并行规模：据采访，他「同时跑 5–10 个 agent，保持心流状态」。
- 硬隔离：OpenClaw 的
coding-agentskill 写死了规则——后台 worker 必须在隔离的 checkout 里跑，禁止在主工作区起并行 agent。这是并行不互相踩踏的关键（和 git worktree 是一个思路）。 - 质量兜底的核心是「用系统验证替代人眼验证」：agent 必须能自己 compile / lint / execute / verify，无人工中间步骤；本地 CI 优先（不等远程管道）；再叠一层极苛刻的机器 review——
AGENTS.md里专门有一章 ClawSweeper Review Policy，要求 review worker 读完整个AGENTS.md、禁止只看 diff，每个 PR 必须回答「这是不是最优修复而不仅是可行修复」。 - 纪律防洪水：
VISION.md规定 one PR = one issue、单 PR 上限约 5000 行、禁止一次性开一堆小 PR。并行车队最大的失控风险就是「PR/issue 洪水」，得靠纪律和自动关闭 stale issue 来治理。
顺带厘清一个常见疑问：OpenClaw 自己跟大模型对话走的是 API，不是 CLI。它依赖 @anthropic-ai/sdk、openai、@google/genai 等官方 SDK，代码里注册的是「API providers」并做统一的流式归一化，鉴权支持 API Key 或 OAuth 订阅登录。CLI（拉起 claude/codex/opencode 当后台 worker）只出现在「把重编码任务外包出去」这个特定技能里，别把两者混为一谈。
争议：同一生态里造工具的人，正在踩刹车
这套模式在 2026 年的实践光谱里处于最激进的一端。两个有分量的反对声音（均为二手来源，请自行核实）：
- Simon Willison（谨慎中间派）：据其公开表述，他给了最清晰的界定——「如果 LLM 写了每一行，但你 review 了、测试了、理解了，那不叫 vibe coding，那是把 LLM 当打字助手。」他的红线是：「给别人用的软件搞 vibe coding 是极不负责任的，别人会为你的蠢 bug 受害。」按这个定义，steipete 的做法在个人/实验项目里可接受，搬到生产就越界。
- Armin Ronacher / Mario Zechner（内部反对派，最关键）：他俩是 OpenClaw 生态里 Pi coding harness 的作者——车队内部的人。据 2026 年 5 月《华尔街日报》报道，他们警告一场 “vibe slop” 危机：企业在用近期生产力换长期麻烦——buggy 软件、宕机、安全漏洞、技术债堆积。「基础设施在崩塌，软件比以前 bug 多得多……最终会反噬。」同一生态里造工具的人都在踩刹车，是这套模式最有分量的警示。
一个几乎所有人（包括 steipete 自己）都同意的分界线：个人 / 实验项目 = 绿灯；多人协作的生产系统 = 红灯或需大幅加固。
能不能抄：五个必须同时成立的前提
这套模式能跑起来，靠的是几个条件同时成立，缺一就会退化成 vibe slop：
- 强自验证闭环：项目能被机器自动 compile / lint / test / run 判对错。没有这个，「不读代码」就是裸奔。
- 宪法级的规则文档：把架构边界、依赖契约、修复形态写死成 agent 约束（
AGENTS.md那种密度），而不是几句 README。 - 单一决策者 + 清晰愿景：BDFL 模式，避免多人协作时的方向撕裂。
- 可容忍的爆炸半径：实验 / 个人项目，翻车成本低。生产系统、他人数据、合规场景不满足。
- 重度自动化治理：自动关闭 stale、机器 review、PR 纪律，防止 issue/PR 洪水淹没系统。
一句话收束
steipete 的产量不来自「更能写代码的 AI」，而来自把人的判断标准工程化成机器能执行的规则和门禁。17 万次 commit 不是终点，而是一个信号：当验证可以自动化、规则可以写死、决策可以留人，一个人指挥一支 agent 车队，确实能干出一家公司的活。值得学的是那套「规则 + 门禁 + 决策留人」的系统设计，而不是 commit 数本身。
本文数据于 2026 年 7 月直接取自 GitHub API 与 openclaw/openclaw 公开仓库（AGENTS.md、VISION.md、taxonomy.yaml、skills、workflows 均为直接读取）；采访与报道类观点已在文中标注来源，包括 Pragmatic Engineer 的 “I ship code I don’t read”、Simon Willison 的公开表述，以及《华尔街日报》关于 “vibe slop” 的报道，建议读者自行溯源核对。