上一篇我把 deepseek-ai/deepseek-harness 的机制拆开了：薄需求 + 三层固化上下文、stacked PR 链、CI 当评审员、脚本当合并员。
这篇回答一个更实际的问题——「一天几百个 commit」，我能复制吗？
结论先放在最前面：不能直接复制，但能抄走 5 条原则，用 2 天在自己的项目里搭出一个缩小版。 下面是完整的推理过程，每一步都有实测数字。
先把「一天几百个 commit」这个数字拆穿
我把仓库重新全量拉下来数了一遍，merge commit 的构成是这样的：
| 类型 | 数量 | 占比 |
|---|---|---|
| merge commit 总数 | 5,651 | 100% |
| “Merge pull request”（真正的 PR 落地） | 1,008 | 18% |
| “Merge branch X into Y”（栈内同步） | 4,643 | 82% |
这 4,643 个 merge 不是「审批落地」，而是 stacked PR 链的机械同步动作——把 master 合进分支、把下层分支合进上层分支。看分支名就知道：
Merge branch 'codex/simp-ui-identity-residue' into 'codex/simp-hide-concrete-agent-loop'
Merge remote-tracking branch 'origin/master' into worktree/web-multimodal-image-input所以「一天几百个 commit」的真相是：
- 真正落地的 PR 只有 约 1,000 个 / 64 天 = 16 个/天
- 其余几百个 commit 里，大部分是脚本自动制造的同步噪音，小部分是微提交（抽样 diff 中位数 +17 行）
这个数字本身没有意义。 有意义的是背后的三个引擎。
他们真正的引擎：并行 + 自动验收 + 自动合并
引擎一：并行。 几十个 agent 实例同时在各自的分支上跑。dsh-find-simplifications skill 里的原话：“Use parallel subagents… Give each agent a domain and require evidence, not guesses.” 无依赖的任务按领域水平拆给多个 subagent，有依赖的任务垂直拆成 stacked PR 链（A←B←C，每层独立过 CI）。
引擎二：自动验收。 CI 是唯一的评审员。per-file 100% 覆盖率、max-strict TypeScript、type-aware lint、跨文件重复检测——每个「能用命令表达」的规则都配了一个非零退出的命令。人不在 review 循环里。
引擎三：自动合并。 gh stack merge <stack> --yes --merge，--yes 就是自动确认。合并不经人手，CI 全绿就落。
三个引擎拼起来就是一条流水线：需求 → agent 开分支写码 → 自动开 PR → CI 自动验收 → 脚本自动合并 → 完成。人在整个循环里的唯一角色是：写需求、定门禁标准、在管道喊停时介入。
但这两个前提，你可能没有
先看他们仓库 docs/testing.md 里的一句原话：
“We are DeepSeek — do not ration real-API tests. Inference is cheap here.”
这是整套系统敢这么跑的根本前提：token 对他们趋近于零。所以他们敢让 agent 开 2,500 个 PR 试错、敢强制 per-file 100% 覆盖率、敢规划 mutation testing（故意注入 bug 看测试能不能杀死）。普通团队的 token 是要花钱的，把这些强度照搬过去，边际成本根本不划算。
第二个前提更隐蔽：这个仓库本身就是他们的产品。他们用自己做的 agent harness 开发 agent harness 本身——开发效率就是产品最好的 demo。这既是工程实践，也是营销。你没有一个「用自己产品开发自己产品」的场景，就少了那一层驱动。
所以「一天几百个 commit」不是纯工程能力的产物，是 token 免费 × 团队协作 × 产品即 demo 三者叠加的结果。
能抄走的：5 条原则
把「实现强度」剥掉，剩下的是 5 条零成本、高杠杆的原则。这些是真正值钱的部分。
1. 规则写成命令，不写成人话。
他们发现 agent 遵守「强制门禁」远比遵守「散文约定」可靠（quality-gates note 原话）。所以别在 README 里写「请注意代码风格」，写成 lint 脚本，跑不过就 merge 不了。
2. 需求给一行，上下文给一堆。
他们派活就是分支名那一行字（agent/onboarding-modal-flow），因为「怎么做、为什么、什么标准」全固化在仓库里（AGENTS.md / cookbook / 决策记录）。把项目约定沉淀成一份 AGENTS.md，让每个 AI 会话带着它跑，而不是每次 prompt 重复交代。
3. 门禁是入场券，不是通过证明。
他们用真实翻车案例证明过：100% 覆盖率 + 178 个绿测试，照样交付一个一连接就崩的产品（docs/postmortem/0001）。因为测试都手 mount 对象凑覆盖率，没走真实加载入口。所以门禁之外必须有一层语义评审——至少守住一条：测试必须走真实入口。
4. 人守边界，机器管执行。
人不需要点 merge 按钮、不需要看每个 PR。人只需要定义门禁标准 + 在管道喊停时介入。架构骨架（抽象边界、禁区）是人定的，边界内的实现是 agent 的自由。
5. 大任务拆成 stacked PR 链，而不是一把梭。
每个 PR 一个分支、独立过 CI、最后一句话整体落地。这是「并行 + 独立验证」的拆解基础。让 AI 做任务时要求它拆成小的、可独立验证的步骤。
一个 2 天搭起来的最小闭环
不用 clone 他们的仓库，在你自己的项目里就能验证这 5 条原则值不值：
第 1 步（半天）：写一份 AGENTS.md。 项目怎么跑、必须遵守的约定、质量门禁是什么。
第 2 步（半天）：配 2–3 个「非零退出的门禁」。 lint + typecheck + 关键测试，接到 CI 或 pre-commit。
第 3 步（最关键）：用 agent 干一个真任务，观察三件事。
- 它会不会先读
AGENTS.md？（不会 → 规则没进上下文） - 它交的代码门禁拦不拦得住？（拦不住 → 门禁太松）
- 它犯的错能不能固化成新规则？（每次翻车 → 补一条门禁）
这个循环跑 3–5 个任务，你就知道这套东西对你的项目值不值。
结论：别追 commit 数，追「80/20」
「一天几百个 commit」里 82% 是噪音。真正该追的目标是这一句：
让 agent 干 80% 的机械活（写代码、跑测试、开 PR），人只做 20%（定约束、review 语义、守决策边界）。
DeepSeek 能一天几百个 commit，靠的不是某种天才方法，而是三个普通引擎（并行、自动验收、自动合并）跑在免费 token 上。你没有免费 token，但你有那 5 条原则——它们不需要 DeepSeek 的规模，只需要一个愿意把「人话规则」改写成「命令门禁」的下午。
数据说明：merge commit 构成基于 git clone --filter=blob:none 全量克隆 deepseek-ai/deepseek-harness 本地实测（12,404 条提交、5,651 条 merge、1,008 条 PR 落地 merge、4,643 条栈内同步）；postmortem、skill、AGENTS.md 引用来自仓库源码。