前一篇文章我做了 DeepSeek Harness（DSH）的 git 考古，拆解了它 64 天 12293 次提交背后的构建哲学——《用Agent造Agent：DeepSeek Harness的64天考古与自进化路径》。那篇是「DSH 是什么、怎么造的」。这篇是「DSH 的经验怎么用」——把那 64 天里被验证过的工程判断，提炼成普通团队可以落地的 AI 辅助开发实践。

先说清楚为什么值得这么做。DSH 不是又一个「我们用了 AI 写代码所以快」的故事。如果只是这个，Copilot 上市五年了，行业早该被颠覆。DSH 真正反常理的是：一个不到 20 人的团队，用 64 天长出一个 221 包的 agent 运行时，工程严谨度却高得不像 AI 写的——100% 测试覆盖率门、运行时断言强制不变量、设计决策可追溯到每个 commit。这不是「AI 写代码快」，是「harness 思维组织 AI 开发」。

这件事，恰恰是所有正在探索AI辅助研发（甚至是AI主导研发）的工程团队、乃至技术Leader或负责人们日日琢磨的核心命题——如何让AI提速的同时，守住工程严谨的底线；如何把AI从「脱缰的效率工具」驯化为「可控的研发协作者」。正因如此，这套从DSH 64天实战中淬炼出的方法论，绝非空泛的理论，而是值得每一支团队深思、拆解并落地的可行路径。

一、认知转变：从「用 AI 写代码」到「用 harness 组织 AI 开发」

市场上有四个比较成熟的 AI 辅助开发流派，先把它们摆清楚：

流派一：Copilot/Cursor 模式——AI 当打字员。人主导写代码，AI 补全和局部重构。这是目前最普及的模式，门槛低，但天花板也低——AI 只能在人画的圈子里做事，产出节奏受限于人的审查速度。

流派二：Claude Code/Codex 单 agent 模式——AI 当执行者。人给一个任务描述，AI 执行多步任务（改多个文件、跑测试、修 bug）。这是 Cursor Composer、Claude Code 的典型用法。天花板比流派一高，但问题是 agent 会自己跑偏，没有不变量挡着，跑几次就积累一堆边界情况。

流派三：Aider 模式——git commit 驱动。AI pair programmer，每次改动自动 commit，人通过 git history 审查。这个模式把 git 当成 AI 产出的审计层，是个好思路，但它只管「改了什么」，不管「为什么这么改」和「规则有没有被破坏」。

流派四：DSH 模式——AI 当 subagent，人定不变量，机器强制规则。这是 DSH 团队自己用的模式。人定架构和数据结构，Claude Code 和 Codex 作为 subagent 生成代码，人 review，CI 和运行时断言强制不变量。12293 次提交是这个 loop 的化石记录。

DSH 选流派四不是偶然——他们的产品本身就是 harness，自然会用 harness 思维组织自己的开发。但这个模式对普通团队也有价值，因为它的核心不是「用什么工具」，是「人做什么、机器做什么、规则在哪里强制」的分工。这个分工可以套到任何一个用 AI 写代码的团队上。

关键认知：流派一二三的问题都不是「AI 不够强」，是「人还在干 AI 该干的事，机器该强制的规则靠人记」。DSH 模式的本质，是把这三件事的分工切干净：

  • 人定不变量（架构规则、数据结构、约束）
  • agent 生成代码（在不变量约束内自由生成）
  • 机器强制规则（CI、运行时断言、lint）

下面五条原则是这个分工的具体落地。

二、DSH 给出的五条工程原则

原则一：先定数据结构，再写算法

DSH 的 commit 历史里有个反常理的时间线：6 月 10 日首提交只有 48 行文档，6 月 13 日就落地了 capability seams（能力接缝，三角色：Service Definition/Provider/Consumer），6 月 14 日才写 Code Mode（算法）。数据结构先于算法。Context 作为服务仓库 + append-only SessionEvent 作为唯一真相源这两个数据结构定完，后面 12000 次提交都是在往这棵树上挂插件。

Linus 说过，好程序员先选数据结构。AI 辅助开发把这个原则放大了——如果数据结构没定清楚就放 AI 去写，AI 会用十种不同的方式表示同一个概念，每种各带一套边界情况。后面想统一，要改的代码量比从头写还大。

团队落地：开始一个新功能前，先让人定清楚两件事——核心数据结构是什么形状，唯一真相源在哪里。这两件事定完再放 AI 写。数据结构没定就放 AI 写，等于让 AI 替你做架构决策，而 AI 做架构决策的方式是「先写一个能跑的，边界情况以后再说」。

原则二：把不变量推到运行时

DSH 有几条硬不变量：Model-visible ⟺ logged（任何到达模型的内容必须能从 session log 重建，运行时有 assert 强制）；注册必须返回 disposer（Fiber 强制收集，不是约定）；capability seam 三角色必须完整（架构规则，半个能力不算能力）。

关键在于这些不是写在文档里的「最佳实践」，是写进运行时的 assert 和 CI 硬门。192 commits/天的节奏，如果靠人记「注册要返回 disposer」「模型可见的必须记录」，三天就忘。靠人记的规则会腐烂，靠工具强制的规则才能扛住 12293 次提交。

这是 AI 辅助开发最重要的一条铁律。让 agent 生成代码可以，但不变量必须机器强制。否则就是技术债雪崩——AI 以人类无法审查的速度积累边界情况，三个月后代码没人敢动。

团队落地：把项目里最重要的几条规则找出来，问自己——这条规则是靠人记，还是靠机器强制？如果是前者，想办法推到运行时或 CI。具体做法：

  • 运行时 assert：对「必须成立」的规则，在代码里加 assert。比如「任何进入模型请求的 content 必须有对应的 session event」这种，写成 assert(logged.has(content.id))，AI 破坏规则时测试直接挂。
  • CI 硬门：对覆盖率、type check、lint 这种，设成 CI 阻塞门，不是「目标」是「入场券」。DSH 的门是 packages/*/*/src 每文件 100% 覆盖。
  • type-level 约束：能用类型系统表达的约束，别用注释。TypeScript 的 branded type、exhaustive check 都能把规则推到编译期。

原则三：消除特殊情况优于增加条件判断

DSH 的 self-modification 设计有个好品味的判断：不用结构化的 cordis_register_tool（只覆盖 tools，listeners/services/inject 每个都要再加一个工具，API 无界增长），而用单一 cordis_mount 原语——用 cordis plugin 一个词汇覆盖所有 effect，且天然支持跨 mount 组合。用最少的原语覆盖最多的场景。

这是 Linus 说的「好品味」——消除边界情况优于增加条件判断。AI 辅助开发里这条尤其重要，因为 AI 特别擅长制造特殊情况。你给它一个 if (isSpecial) 的先例，它会在下一个功能里给你造出五个 if (isSpecialCase2)。每个特殊情况都是一个未来要维护的分支。

团队落地：review AI 生成的代码时，重点不是「这段能不能跑」，是「这段有没有引入新的特殊情况」。具体看几个信号：

  • 新增的 if 分支能不能通过改数据结构消除。比如「如果是 admin 就走这条路径」——能不能把 admin 逻辑拆成独立 provider，而不是在主路径里加分支。
  • 新增的工具/函数能不能合并到已有原语。DSH 的 cordis_mount 用一个原语覆盖了 tools/listeners/services/inject 四种 effect，而不是四个工具。
  • 新增的配置项是不是在补一个设计漏洞。配置项越多，组合爆炸越大。好架构是配置项少但组合能力强。

原则四：设计 rationale 制度化

DSH 有一个 .agents/notes/ 目录，每个非平凡变更都有设计决策记录，PR 必须附带，归档后冻结不可改。这不是事后补文档，是开发流程的一部分。12293 次提交里能追溯到每个决策的 why。

这条在 AI 辅助开发里被严重低估。问题在于：AI 生成的代码，人 review 通过，但「为什么这么写」的 rationale 只存在于当时那个上下文里。三个月后有人问「这里为什么用 disposer 不用 GC」，commit message 里可能有，也可能没有，更可能是「AI 当时这么写的，我看着没问题就 merge 了」。

团队落地：建立两层 rationale 沉淀：

  • commit message 规范：DSH 严格执行 Conventional Commits，scope 必填且粒度精细。AI 生成的 commit message 普遍是多行 body 详细解释 alternatives——这是 AI 辅助代码审查的特征，要保留。别让 AI 只写「fix bug」，要求它写清楚为什么这么 fix、试过什么别的方案。
  • ADR/设计笔记：对非平凡变更（新抽象、新约束、新数据结构），要求 PR 附带一个简短的设计笔记——问题是什么、考虑了什么方案、为什么选这个。DSH 的 Agent Notes 就是这个。不需要长，三五句话说清 why 就够。归档后冻结，不可改，保证历史可追溯。

这层的价值在 bus factor 低的时候尤其大。AI 杠杆让小团队能产出大团队的代码量，但也让单点故障的影响被放大——核心成员离开，AI 生成代码的「为什么这么写」全在 commit message 和设计笔记里，没人接得住就真的接不住了。

原则五：release 是策划出来的事件

DSH 的 8 月 13 日不是「代码写完了发出去」。npm registry 时间戳记录了那 12 小时：UTC 09:50 协议从 BSD-3-Clause 切到 MIT，主版本号 0.0.1 → 0.1.0；12:29 把 publishConfig.access 从 restricted 切到 public，正式公开。中间还插了 self-modification UI、cordis 4.0.1 vendor、landlock-run 0.1.1、论文上传。同一天 DeepSeek-V4-Pro 正式版发布，用 DSH 跑 Terminal-Bench 拿 87.9 分。北京时间 20:30 的官方公告时刻，恰好就是 UTC 12:29 的 npm 公开时刻。

这是策划出来的事件，不是「代码写完了发出去」。协议切换、主版本号跳变、公开发布、论文上传、模型发布同步，是一个协同。release 本身是一种工程。

团队落地：即使是内部 release，也要把「发版本」当工程做，而不是「代码合并到 main 就算发布」。具体：

  • release 前定一个 checklist：协议确认、版本号规则、依赖锁定、文档同步、changelog 审查。
  • release 和外部事件协同：如果有配套的 demo、博客、公告，确保时间点对齐。DSH 的 npm 公开时刻和官方公告时刻对齐不是巧合。
  • release 后复盘：哪些决策是 release 前才定的（DSH 的 TUI→Web UI 是开源前 9 天才定），这些「最后时刻判断」是不是应该更早做。

三、落地实践：搭一条 AI 辅助开发流水线

把上面五条原则落成一条可复制的流水线。分五层，从底往上。

第一层：工具链

DSH 的工具链组合是：Claude Code + Codex 作为 subagent（通过 hooks 桥接进开发流程），Oxlint 做 lint，knip 检测 unused code，.jscpd.json 检测克隆代码，lefthook 管 worktree-local hooks，7 个 vitest 配置（单元/e2e/snapshot/web/stress/perf/shared）。

普通团队不需要这么重，但组合逻辑是一样的——一个生成层（AI agent）+ 一个强制层（lint/type/test）+ 一个审计层（git history + 设计笔记）。最小组合：

  • 生成层：Claude Code 或 Codex 或 Cursor，选一个。DSH 用 Codex 当 subagent 的原因是它能多文件改动 + 执行命令，适合做「给人一个大任务」的流派四。如果团队还在流派一，Cursor 足够。
  • 强制层：至少 TypeScript strict + ESLint + 一个测试框架。CI 里设成阻塞门。
  • 审计层：Conventional Commits + ADR。这层最便宜，但最容易被忽略。

第二层：不变量强制

这是 DSH 模式的核心。从便宜到贵，三级强制：

编译期（最便宜）：TypeScript strict mode，能推到类型系统的约束别用注释。比如「注册必须返回 disposer」可以用类型 Register<T> = (x: T) => () => void 表达，没返回值的注册过不了编译。

CI 门（中等成本）：覆盖率门、lint 门、type check 门、clone 检测门。DSH 的门是 100% 覆盖率，普通团队可以先设 80% 然后逐步提。关键是设成阻塞门，不是「目标」。

运行时 assert（最贵但最强）：对「必须成立」的规则，在代码里加 assert。DSH 的 Model-visible ⟺ logged 就是运行时 assert——新增模型可见输入必须新增 session event，否则 assert 失败。这层的威力在于它能抓到编译期和 CI 抓不到的运行时违规，代价是会影响性能，要选择性加。

第三层：决策记录

两层：

  • commit message：要求 Conventional Commits，scope 必填。AI 生成的 commit message 如果只写「fix bug」，打回去重写——要求它写清楚为什么这么 fix、试过什么方案。DSH 的 commit message 普遍是多行 body 解释 alternatives，这是 AI 辅助代码审查的特征，要保留。
  • ADR/Agent Notes：对非平凡变更（新抽象、新约束、新数据结构），要求 PR 附带简短设计笔记——问题、方案、为什么选这个。归档冻结。不需要长，三五句话说清 why。

这层的成本极低（就是要求人写几句话），但价值在三个月后显现——当有人问「这里为什么这么设计」，答案在 git history 里，不在某个离职的人脑子里。

第四层：review

AI 生成的代码必须人 review，但 review 的重点要变。传统 review 看「这段代码能不能跑」「有没有 bug」。AI 辅助开发里，AI 写的代码普遍能跑（它跑过测试了），bug 也在测试覆盖范围内。review 的重点应该是：

  • 有没有引入新的特殊情况（原则三）
  • 有没有破坏已有不变量（原则二）
  • commit message 和设计笔记有没有说清 why（原则四）

这是「审计层 review」而非「纠错层 review」。DSH 的 PR 几乎全是内部 review 流程产物——2521 个 PR、19 个贡献者，这个 PR 数量说明 review 是高频活动，但 review 的颗粒度是「设计决策」而非「代码 bug」。

第五层：release 协同

如原则五所述，把 release 当工程做。最小做法：release 前过 checklist，release 后复盘哪些是最后时刻判断。

四、反思：AI 辅助开发的三个失败模式

DSH 的 12293 次提交也是反面教材。它揭示的失败模式比成功模式更值得普通团队警惕。

失败模式一：没有不变量强制的 AI 代码会腐烂

192 commits/天，如果靠人记规则——「注册要返回 disposer」「模型可见的必须记录」「capability seam 要三角色完整」——三天就忘。没有 CI 门、没有运行时 assert、没有 type-level 约束，AI 生成的代码会以人类无法审查的速度积累边界情况。三个月后代码没人敢动，每次改动都引入新 bug。

解法：原则二——把不变量推到运行时。最便宜的一步是开 TypeScript strict mode 和 ESLint 阻塞门，最贵但最强的是运行时 assert。团队至少要做到编译期 + CI 门这两级。

失败模式二：commit 数量 ≠ 质量

日均 192 次提交如果没有 100% 覆盖率门、7 个 vitest 配置、type-equiv 防漂移、knip 检测 unused code、.jscpd.json 检测克隆，会变成什么？一堆能跑但没人敢动的代码。AI 特别擅长写「看起来对」的代码——变量名合理、逻辑自洽、测试通过，但引入了新的特殊情况或破坏了已有不变量。

解法：commit 数量不是 KPI，commit 的可追溯性才是。DSH 的 Agent Notes 制度让每个非平凡变更都有决策记录。普通团队不需要这么重，但至少要求 commit message 说清 why，非平凡变更附带设计笔记。

失败模式三：AI 杠杆放大单点风险

DSH 的 bus factor 实际值是 1-2——崔添翼单人占 42.6% 的提交，npm 发布权只有两人。AI 杠杆让一个小团队能产出大团队的代码量，但也让单点故障的影响被放大。核心成员离开，AI 生成代码的「为什么这么写」全在 commit message 和 Agent Notes 里，没人接得住就真的接不住了。

解法：这层没有银弹。DSH 的解法是 Agent Notes 制度化，把设计 rationale 沉淀成可追溯的资产——这是治标。治本需要降低集中度，但 AI 杠杆天然让集中度升高（用得好的人产出更多）。现实的做法是：保证至少两个人能 review 每个核心模块的变更，轮换 review 责任，别让一个人成为单点。

五、团队推广：从个人到团队的四级阶梯

不是所有团队都能一上来就搞 DSH 模式。下面是一个渐进推广的阶梯，从便宜到贵。

Level 0：建立项目规则文件

成本：几小时。效果：立竿见影。

在仓库根目录建 AGENTS.md 和 CLAUDE.md，写清楚项目的几条硬规则——数据结构约定、不变量、commit 规范、测试要求。这是给 AI agent 看的「项目宪法」。DSH 首提交就建立了这两个文件——项目第一天就建立了 agent 协议的入口。

没有这一层，AI agent 每次都在猜你的项目规则，猜错了你就得手动纠正。有了这一层，AI agent 至少能在规则内生成代码。

最小内容：

  • 项目用什么语言、什么框架
  • 有哪些不变量（比如「所有 async 函数必须显式处理 error」）
  • commit message 规范
  • 测试在哪里、怎么跑

Level 1：建立 CI 不变量门

成本：一两天。效果：阻止 AI 生成的代码破坏规则。

在 CI 里设阻塞门：TypeScript strict + ESLint + 测试覆盖率门 + type check。DSH 的门是 100% 覆盖率，普通团队可以先设 80% 然后逐步提。关键是设成阻塞门——CI 不过不准 merge。

没有这一层，AI 生成的代码会慢慢破坏规则——今天漏一个 type error，明天漏一个边界情况，三个月后代码没人敢动。有了这一层，AI 破坏规则时 CI 直接挂，逼着它（和人）修。

Level 2：建立决策记录制度

成本：要求每个人每次 PR 多写几句话。效果：三个月后显现。

要求 Conventional Commits，scope 必填，commit message 说清 why。对非平凡变更（新抽象、新约束、新数据结构），要求 PR 附带简短设计笔记——问题、方案、为什么选这个。归档冻结。

没有这一层，AI 生成代码的 rationale 只存在于当时那个上下文里。三个月后有人问「这里为什么这么设计」，答案在某个人脑子里，那个人离职就没了。有了这一层，答案在 git history 里。

Level 3：建立 release 协同

成本：一次 release 的策划时间。效果：避免「代码写完了但发不出去」或「发出去了但配套没跟上」。

release 前过 checklist（协议、版本号、依赖锁定、文档同步、changelog），release 后复盘哪些是最后时刻判断。如果有配套 demo、博客、公告，确保时间点对齐。

没有这一层，release 是「代码合并到 main 就算发布」，容易出协议没确认、依赖没锁、文档没同步的问题。有了这一层，release 本身是一种工程。

四个 Level 可以分阶段推进。Level 0 和 1 是任何用 AI 写代码的团队都应该做的，成本极低。Level 2 和 3 是想认真做 AI 辅助开发的团队应该做的，成本中等但回报长期。

六、成熟流派对比：选哪个

把四个流派放一起对比，帮团队选。

维度 Copilot/Cursor Claude Code/Codex 单 agent Aider DSH 模式
人做什么 主导写代码，AI 补全 给任务描述，review 给指令，审 git history 定不变量，review 设计决策
AI 做什么 补全、局部重构 多步执行 改代码+commit 生成代码（subagent）
规则在哪强制 人脑 人脑 + lint git history CI + 运行时 assert
产出节奏 受限于人 中 中 高（192/天）
适用场景 任何项目 中等复杂度 个人项目 复杂系统、长期维护
天花板 低 中 中 高
门槛 极低 低 低 中（需要搭强制层）

DSH 模式的门槛比其他三个高——要搭 CI 门、运行时 assert、决策记录制度。但它的天花板也最高，因为人只在最该花时间的地方（定不变量、审设计决策）花时间，其余交给 agent 和机器。

选型建议：如果项目简单、短期、不需要长期维护，流派一够用。如果项目中等复杂度、有长期维护需求，流派二或三。如果项目是复杂系统、要长期维护、团队对工程严谨度有要求，值得投入搭流派四的强制层——这个投入的前期成本是搭 CI 门和写 AGENTS.md，后续的回报是 AI 产出质量和可维护性。

七、结论：Harness 不是工具，是组织方式

回到开头。DSH 的 64 天 12293 次提交，真正值得学的不是「他们用了 Codex」或「他们日均 192 commits」。这些是表面。真正值得学的是他们把 AI 辅助开发当作一个 harness engineering 问题来解——人定不变量，agent 生成代码，机器强制规则。

这个范式的好处是：人只在最该花时间的地方花时间（定架构、审设计决策），其余交给 agent 和机器。AI 生成代码可以，但不变量必须机器强制，否则就是技术债雪崩。commit 数量不是 KPI，commit 的可追溯性才是。AI 杠杆放大单点风险，解法是把设计 rationale 沉淀成可追溯的资产。

DSH 给的是一个可行性证明：这套范式在 64 天里扛住了 12293 次提交，产出了一个 221 包的 agent 运行时，工程严谨度没有因为 AI 辅助而下降。这不是理论，是被验证过的工程实践。

普通团队不需要一上来就搞 DSH 全套。从 Level 0（AGENTS.md）和 Level 1（CI 门）开始，成本极低，效果立竿见影。等团队习惯了再上 Level 2（决策记录）和 Level 3（release 协同）。关键不是用什么工具，是分工切干净——人定不变量，agent 生成代码，机器强制规则。这是 harness 思维组织 AI 开发的本质。

64 天 12293 次提交不是人类被替代的证据，是人类学会用 agent 造 agent 的化石。这件事的意义，可能比任何一个具体产品都更长远。

参考