复杂度棘轮：AI编程的质量只升不降机制¶

Ch01.309 复杂度棘轮：AI编程的质量只升不降机制¶

📊 Level ⭐⭐ | 11.9KB | entities/complexity-ratchet.md

核心定位¶

复杂度棘轮（Complexity Ratchet）：Garry Tan 提出的一种让 AI 编程"只进不退"的机制。每次 AI 编程会话留下三样东西——测试 + 文档 + 评估结果——构成一份有记忆的现场，让质量地板单向上升。 核心案例：Garry Tan 72小时，14个PR，29,000行代码，每一版比上一版测试覆盖率更高、质量更好。

速度 vs 质量：五十年二选一的终结¶

传统观点	现在
快发 or 少出错	又快又更好
90% 测试覆盖率是奢侈品	AI Agent 把执行成本降到接近零
70% 是"够了"的标准	~85% 是 DRE 拐点，超过后缺陷逃逸骤降
---

90% 测试覆盖率的数据基础¶

Capers Jones 研究 10,000+ 软件项目的缺陷移除效率（DRE）：

< 70% 覆盖率：DRE ≈ 65-75%
85-95% 覆盖率：DRE ≈ 92-97% ← 非线性拐点 类比：
航空电子 DO-178C：A 级软件 MC/DC → >99% DRE
六西格玛：4σ→5σ 是相变（3.4 DPMO → 233 DPMO） 从 70% 提升到 90%，不是提升 30%，而是缺陷逃逸减少一个数量级。

棘轮三层¶

层	作用
测试	告诉下一个来的人什么叫"正确"——改动破坏了什么它会大声报错
文档	记录当时为什么这么决定、取舍是什么
评估结果	给质量打分，让你能看出下一个版本是变好还是滑下去
效果：下一轮 Agent 面对的不是空白起点，是有记忆的现场。不能退化到测试套件以下（测试会失败），不能无视文档，不能把质量拉到评估基准以下。
---

GBrain 实例：棘轮的一次完整转动¶

认识论提取功能第一版：35% 的情况搞错"持有者混淆"（谁的观点？本人说的？引用？系统推断？）棘轮响应： 1. 评估结果记录 → 识别 6 个具体失败模式 2. 提示词针对性修复全部 6 个 3. 置信度取整规则强制到数据库层（不再出现 0.74 假精确） 4. 17 条测试把这份契约锁住 从此，没有任何未来版本能在不通过这 17 条测试的情况下发布。

关键区分：执行成本 vs 发现成本¶

成本类型	AI Agent 影响
执行成本（写测试的意愿）	→ 接近零 ✅
发现成本（知道该测试什么）	→ 没有跟着降 ⚠️
> 那最后 20% 之所以难，不只是因为人类懒，更是因为那些边界情况本身很难被识别——你不知道你不知道什么。Agent 能想到的边界情况和人类工程师来自同一个分布。
---

TTY 终端行为契约测试¶

测试"AI 有没有对话"（而不是一次性倒出所有发现）： 1. 用 Bun 的 TTY 把 Claude Code spawn 在伪终端里 2. 喂给特定代码库场景，触发审查技能 3. 实时监控终端输出，观察有没有在结束前发出交互式问题 4. 如果没有 → 测试失败 棘轮响应三层：

技能指令里的强制停止门（防合理化）
反捷径条款（方案文件 ≠ 交互审查输出替代品）
终端层面门槛测试

测试是机构记忆¶

传统	棘轮时代
机构记忆在人脑里	机构记忆在测试套件里
人会离开 → 知识消失	Agent 上下文窗口不离职/不失忆
单人项目无机构记忆	测试是"唯一拥有的机构记忆"
---

棘轮不只对代码有效¶

能观察 → 能断言 → 能棘轮：

操作系统（进程树、文件系统状态、网络套接字）
终端（按键、输出、交互提示）
浏览器（页面状态、导航事件）
AI Agent（行为：说了什么、调用了什么工具、是否先询问）

已知局限¶

> 棘轮解决退化问题，但没有解决方向问题。一个只升不降的地板，前提是地板在往正确的方向升。"品味"问题没有被棘轮机制覆盖。¶

深度分析¶

1. 棘轮机制的本质是「质量承诺的可执行性」¶

棘轮之所以有效，不是因为测试本身有什么魔法，而是因为它把「质量标准」从口头承诺变成了可自动化验证的约束。没有测试套件的时候，「我们要保证代码质量」是一个愿望；有测试套件的时候，「我们不会退化到 X 以下」是一个技术事实。Garry Tan 的贡献在于把这个逻辑推到了极致：不是「希望质量变好」，而是「让质量退步变成一件技术上不可能的事，除非测试失败」。这个从「软约束」到「硬约束」的转变，是整个框架的核心。

2. 「执行成本降了，发现成本没降」是整个框架最诚实的警告¶

原文花了相当篇幅讨论 Agent 能降低写测试的意愿成本（写 14 个边界情况测试不累、不抱怨），但同时坦率承认：Agent 的「发现能力」来自和人类工程师相同的分布。这意味着棘轮可以锁住「已知的边界」，但无法捕捉「未知的未知」。这个区分对工程实践有重要含义：90% 覆盖率不是银弹，覆盖率数字背后的「行为契约」才是真正有价值的部分。那些能写出高影响力测试用例的人（知道测什么），和只会填覆盖率数字的人（测什么都行），在 AI 时代差距会更大，而不是更小。

3. TTY 行为契约测试是「可观测 AI」的最简实现¶

Garry Tan 用 Bun 的 TTY 把 Claude Code 放进伪终端、监控是否发出交互式问题——这个设计的聪明之处在于：它不试图理解 AI 内部推理过程，而是在行为层面做契约验证。这是一个极其实用的工程哲学：与其问「AI 是怎么想的」，不如问「AI 做没做它应该做的事」。这类行为契约测试的思路可以扩展到任何 AI Agent 场景：不是测试 AI 的输出质量（那需要人工评判），而是测试 AI 有没有遵守它被要求遵守的特定行为模式。

4. 棘轮的局限——「方向」问题——是真正难的问题¶

框架诚实地承认棘轮不解决方向问题，只解决退化问题。这个坦承值得认真对待——「品味」（知道什么值得做、什么架构是好的）是一种难以形式化的判断力。它需要的是领域知识、对用户需求的理解、以及对系统长期演化的直觉。棘轮可以保证你不退步，但无法告诉你往哪个方向走是值得的。这个问题在 AI 时代反而更尖锐了：当执行成本趋近于零，「做什么」和「不做什么」的判断力成了唯一的稀缺资源。

5. 「机构记忆」从人脑迁移到测试套件，是一场知识管理的范式转移¶

传统软件公司的知识管理依赖「人」：资深工程师知道为什么那样设计，技术负责人记得那次差点崩掉的生产事故。棘轮框架提出了一个激进的主张：在 AI-Native 开发中，测试套件取代人脑成为机构记忆的载体。这不只是工具的替代，而是知识留存机制的结构性变化——知识的有效性不再依赖人员的连续性，知识的更新速度不再依赖组织记忆的传递效率。这个转变对团队建设和知识管理有深远影响。¶

实践启示¶

对于个人开发者/独立工程师¶

从今天开始写测试，哪怕是「dirty test」：棘轮的前提是有测试可守。不需要完美，不需要覆盖所有边界——从「给最核心的函数写一个会失败的测试」开始。
把每次 AI 会话的教训写成测试：当 Claude Code 帮你修了一个 bug，围绕这个 bug 写一条测试。修完 bug 不写测试 = 白修了。
建立会话模板，减少每次从零推导的架构漂移：在开始每次代码会话前，给 Claude 提供架构上下文（CLAUDE.md），让棘轮的「记忆层」真正生效。

对于工程团队¶

把「行为契约」纳入 Code Review 标准：不只是看代码能不能跑，还要看有没有为这个改动写对应的测试、测试有没有真正捕捉契约变化。
引入 TTY/终端层面的行为测试：对于 AI Agent 相关的功能（代码审查、自动测试生成、文档生成），传统的输出验证不够，需要行为层面的契约测试——不只是测「输出了什么」，还要测「有没有以正确的方式互动」。
警惕覆盖率作为虚荣指标：覆盖率数字好看不等于质量好。要看「哪些行为被测试覆盖了，哪些没有」，而不是总分。

对于 AI/ML 工程实践¶

把 AI 生成的每一次错误修复，都变成一条有记忆的测试：这是棘轮转动的最小单位。不要只修复错误，要让错误变成「未来再犯不可能」的测试用例。
区分「执行成本」和「发现成本」：在评估 AI 编程工具的价值时，不要只看「写代码快了」，更要看「有没有帮助我发现我不知道的边界情况」。这是真正的高价值区。
构建「品味层」——AI 棘轮覆盖不到的地方：建立架构评审机制、代码设计讨论，让团队在「做什么」的问题上保持一致的判断标准。这需要人来做，AI 帮不了。

对于组织/管理层¶

知识管理要从「人治」转向「测试治」：把「问 Dave」变成「看测试套件」。这需要投资文档文化和测试基础设施，短期内看起来是负担，长期是唯一可持续的知识沉淀方式。
重新定义「代码所有权」：在棘轮框架下，代码不只是「谁写的」，而是「谁测试了」。一个贡献者最重要的价值不是写了多少代码，而是为多少系统行为建立了不可绕过的契约。