一天两百个提交：oh-my-pi 的机器人群

〇、十五秒，四十七个提交#

2026 年 11 月 3 日，晚上 20:00:17 到 20:00:32。

上游 oh-my-pi 的主线（main）上，十五秒里落了 47 个提交，其中 35 个是 PR 合并。署名全部落在一个身份上：提交信息里写 “Brit”，账号叫 H4vC。同一晚 21 点又是一波，25 个提交压在 9 秒里——两班”车”之间隔了一个小时。

人类点鼠标点不出这个速度。上一篇我们量的是”存量”（我们领先多少提交）；这一篇只量”流量”——每天产出多少。先给三组打底的数字：

• 过去 7 天：上游 1,541 个提交，平均一天 208 个。H4vC 597、will-bogusz 295、can1357 149、roboomp 77——四个账号占 72.6%；其余约 420 条来自几十个社区账号。
• 爬坡：8 月 4,137（133/天）→ 9 月 5,726（191/天）→ 10 月 8,858（286/天）。十月平均每 5 分钟就有一个提交落进这个仓库。
• 对照：我们自己的 fork（Zeta）最近 7 天约 120 条自有提交，一天 17 条。差了约 12 倍。

这些数字不像人的手笔。所以这篇只做三件事：点名、编队、量活。

一、名册：账号像人，干活不像#

四个”人”的体检报告（GitHub API 实测，窗口 10 月 28 日–11 月 4 日）：

“账号像人”的部分：H4vC 注册于 2015 年，will-bogusz 注册于 2016 年、签名写着 “Software Engineer”——从账号页看，都是正常得不能再正常的开发者。

“干活不像”的部分，是三组证据：

1. 同秒连发。 will-bogusz 有过 6 个提交压在同一秒的记录；H4vC 那两波分别是 47 个/15 秒、25 个/9 秒。还要每个都过审、进主干——一个人做不到。
2. 单小时集中。 H4vC 最近 100 个提交里，50 个挤在同一个小时。
3. 月产能。 30 天 2,192 条和 1,810 条——换算下来，H4vC 一天 73 条、will-bogusz 一天 60 条，且不是”写了就算”，是”修完、审完、合完”。

顺带一个反直觉的观察：主号 can1357 是四个里最慢的——30 天 491 条（16/天），名下只有 2 个 PR（他直接推主干）。在这个仓库里，“人”反而是产量最低的那一个。

我们的判断（其中一部分是推测）：这四个账号的背后都是部署了机器人——账号是壳，作业是机器节奏。我们没法登进他们的机器去看，但上面的数字已经不太需要更多解释。

再校准一句、免得把故事讲歪：机器人群不是 24 小时轰鸣。它们的活跃有清晰峰谷——夜间回落，峰值贴着工作时段。它们有班次。触发它们的仍然是人：白天的 issue、PR、变更需求。机器人只是把”处理”这个环节压到了机器的密度。所以”晚上安静”不是反例，是正常态。

二、六个工位：谁修哪个面#

“是不是人”只是第一层。第二层更有意思：它们各占哪块业务？把每个账号最近 100 条提交的 scope 分布拉出来，分工清楚得吓人：

一句话总结这个排班：机器人在急诊室和原生层干活，主人在写核心，另一个机器在质检，社区在供料。

急诊室的规模感也值得看一眼：roboomp 的 PR 队列里 238 个还开着、2,330 个已经合掉、390 个被关掉——不是每个提案都该进主干，关门这件事一直在发生。

评论区同样如此：最近 100 条公开评论里，roboomp 39 条、机器审查 32 条，其余才分给人类（will-bogusz 3 条）。一线和质检都是机器的。

三、三条链路：从用户报警到主干变红#

流水线的形状大概是这样（机器人干三班，人守两条底线）：

社区供料，roboomp 在急诊、Codex 在质检、H4vC 在总装；规矩沉进三层闸门，班次跟着人走。

三条真实链路（时间为 UTC）：

① 18 分钟闭环（#18073）。

• 08:11:08，用户 SamCod3 报：父消息的 IRC 信封泄漏进了界面。
• 08:12:35（+87 秒），roboomp 首答：“Looking into this, will report back with a repro.”
• 08:13:57（+2 分 49 秒），复现完成：“Reproduced on current main…”——直接点名是哪一层。
• 08:28:59（+17 分 51 秒），修复 PR #18075 开出：19 个文件，从 packages/ai/src/types.ts 到 coding-agent 的 RPC wire schema、事件控制器、IRC 桥。四段式正文一段不缺。

② 23 分半闭环（#18060）。

• 06:36:30，用户 mccraigmccraig 报编译产物首跑失败。
• 06:37:32（+62 秒）首答；06:40:00 复现；07:00:00 修复 PR #18065 挂出。23 分 30 秒，从”用户说话”到”修复待合”。

（六个抽样的首答延迟全部落在 60–96 秒之间——这不是客服排班，这是没有排班的机器。顺带一句：这种速度放在人类提问下面，有时会显得”不合适”——快是能力，节奏是教养。）

③ 上车——以及主干变红（#18019）。

• roboomp 修”skills 成本闸门”；机器审查出 findings；can1357 亲自把它合进主干（07:01:45）。
• 一秒后（07:01:46），主干 push CI 变红。

最后这条不是嘲笑谁，是把速度的另一面摊开：那段时间里跑完的主干 CI，六红一绿。合并被压到 15 秒，红也是以秒计的。而修复同样是机器在做——roboomp 在被指出 review finding 后，分钟级回复：“Addressed the RPC wire-schema finding in 49f74d054c2d。”

四、规范：让机器人守规矩的三层闸门#

如果这一整套只有速度，它早翻车了。真正让它转起来的，是规范被拆成了三层闸门。

第一层：能机检的，写进脚本，直接拒收。

仓库里有一个不到 100 行的 scripts/merge-pr.ts，负责生成合并提交：

Merge PR #<number>: <conventional PR subject> (@<author>)

规则是硬的：subject 必须是 type(scope): 前缀、不超过 72 字符、描述小写开头、不能以句号结尾——不合格直接拒绝合并。脚本作者在注释里留了一句诚实的话：过去时（“added”、“fixed”）是规范的一部分，但不可机检，所以不查。合并的人把它设成 git 别名（git mpr），一个晚上跑几十次。

第二层：合规率——机器人是最守规矩的那个。

抽查最近 100 条提交：格式合规（conventional 前缀、小写开头、无句号）几乎 100%；唯一的破口是长度——非合并提交里约三分之一超过 72 字符（最长 119），而 roboomp 的近 100 条有 96 条连长度都守住了。闸门只管得住愿意走进闸门的人，而机器人每次都从闸门走。

第三层：不能机检的，写进清单，人工负责。

上游的 CONTRIBUTING.md 写得非常直白：

AI agents are welcome as tools, not as unattended contributors.

AI 代理作为工具欢迎，作为”无人值守的贡献者”不行。每个 PR 必须包含”至少一句用你自己的话写的说明”，生成的摘要不算；你还得自己跑通变更、报告验证场景；“无论代码由谁生成，责任都是你的”。而同一份文档又写着：roboomp 会把可修的 issue 当成自己的工作捡走——对外来机器人严格，对自家的机器人群放行。规则的两副面孔，本身就是这套体系的一部分。

再记一个细节：权限不是发给”人”的，是发给工具边界的。roboomp 的系统提示写着：不许 shell 出 gh、不许 git push（worktree 里根本没有远端凭据）；所有 GitHub 操作只能走宿主工具。而宿主工具在推分支时内置 bun check、开 PR 前还跑全量测试——红着不开 PR。它能干什么、不能干什么，被工具的形状写死；连它自己都不许编辑自己的系统提示和工具定义（“Prompts/tool shapes maintainer-owned: NEVER edit”）。规则的主人，仍然是人。

五、范式：值得抄的五件事#

把这一整套拆开，可复制的部分其实是五条：

1. 规范分层。 能机检的进脚本（提交信息、合并消息、格式），不能机检的进清单（人话说明、验证场景、责任归属）。规矩不写在 wiki 里，写在闸门里。
2. 合并列车。 人类合并是瓶颈，那就批处理：一个脚本 + 一个账号，把几十个 PR 排进同一个时间窗。合并消息由脚本生成——格式永远一致，历史永远可查。
3. 编制化。 机器人也要”编制”：谁产、谁修、谁审、谁合、谁终审，各占一个号、各带一套工具、各拿最窄够用的权限。四个账号扛七成提交，不是混乱，是分工。
4. 审查也自动化，但底线留给人。 机器审查出 findings、机器人分钟级修 findings、合并列车带走；但终审、以及”责任是人”这条线，始终挂在人这边。
5. 密度兜底 + 排班。 仓库一半的 TS 文件是测试（3,374 / 6,580），机器人改代码有安全网；重活排进夜里——Nix 构建每晚 03:17 UTC 定时开跑，合并与修复排在白天/工作时段。夜里跑编译、白天合代码，对编译密集型项目（比如 Rust）几乎可以直接照搬。

六、我们的账：覆盖率、测试密度，和一句原话#

写到这里得交代自己。我们的 Zeta 是 OMP 的 fork，先说我们自己的账（都是实测）：

• 测试覆盖率：五个支持包合计 81.2% 行 / 79.7% 函数（agent 88.0%、ai 89.9%、catalog 93.8%、tui 73.3%、utils 78.7%；2026-11-03 的 LCOV 基线，记录在 README.md#coverage）。coding-agent 只敢报核心抽样（29.7%）——全量两千多个文件在覆盖率插桩下 40 分钟跑不完，我们在文档里写明”这不是全包读数”，不装作它是。
• TS 测试文件占比约 50%——和上游的 51.3% 同一量级。同样是”一半代码是测试”的仓库。
• 覆盖率有一条手动 + 每周一自动跑的工作流，报告型、不设阈值，但定了棘轮：单包行覆盖率掉超过 0.5 个百分点要写解释；“不许删测试、跳断言、降阈值换绿灯”。

然后是我们选择 OMP 的理由。这句话是当时写下的，原样放在这里：

上游更新速度快，我们基本上不用担心 bug 问题，算是吃了二次发行福利，我们主要的 bug 修复集中与我们自己的特有面修复和兼容层修复。

翻成大白话：别人家的机器人流水线，替我们免费修 bug；我们把力气花在自己的特有面和兼容层上。这笔账划算——但划算的前提是”接得住”：81.2% 的覆盖率和一半的测试文件，就是我们的地板。

要学的三件事我也列出来了：把规范写进闸门（提交校验、合并脚本、PR 模板）；试编一列自己的合并列车；给”特有面和兼容层”配上我们自己的机器人流程——复现、修复、验证一条链。

七、结语：机器上班，人看报#

上游这台流水线真正的资产，不是”会写代码的机器人”，是编制：四个账号、一个机器审查、一条合并列车、三层闸门、一套班次，和一条”责任在人”的底线。

机器人让”生产”变得几乎免费之后，稀缺的就变成了审查、合并和验收——以及那个愿意对结果负责的人。

所以留一个问题：

你的仓库名册里，有几个”账号”？你的规范，住在 wiki 里，还是住在脚本里？

数据口径：本文数字于 2026-11-04 上午（UTC）经 GitHub API 实测；时间戳均为 UTC；“近 7 天”= 10 月 28 日–11 月 4 日。上游 = can1357/oh-my-pi；我们 = Linxira-OS/linxira-zeta。