你的AI代码越写越乱，他72小时合了14个PR每个都更好——差距只在一个机制¶

Ch01.267 你的AI代码越写越乱，他72小时合了14个PR每个都更好——差距只在一个机制¶

📊 Level ⭐⭐ | 13.7KB | entities/complexity-ratchet-garry-tan.md

Complexity Ratchet Garry Tan

"你的AI代码越写越乱，他72小时合了14个PR每个都更好——差距只在一个机制"¶

核心案例¶

Garry Tan（Y Combinator CEO，GStack 9.3万 GitHub Star，GBrain 作者）72小时：

14个 PR
29,000行代码
每一次发布比上一次测试覆盖率更高、质量更好 不是快了但变差——是又快又更好。

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

传统软件工程的二选一：快发 or 少出错。 Garry Tan 的解法：90% 测试覆盖率 + AI Agent 同时写测试 = 复杂度棘轮——一个只进不退的系统。

为什么是 90%（DRE 数据曲线）¶

Capers Jones 研究 10,000+ 软件项目缺陷移除效率（DRE）： | 覆盖率 | DRE（缺陷移除效率） | |--------|-------------------| | < 70% | ~65-75% | | 85-95% | 92-97% ← 非线性拐点 | 拐点在 ~85%：低于此线，缺陷逃逸率与覆盖率不兼容；达到此线，缺陷逃逸骤降。航空电子 DO-178C：A 级软件 MC/DC 覆盖 → 超过 99% DRE。六西格玛类比：4σ→5σ 是相变（非渐进），测试覆盖率 70%→90% 同样。

棘轮（Ratchet）三层¶

棘轮 = 只允许单向运动的机械装置。每次 AI 编程会话留下三样东西：

1. 测试¶

告诉下一个来的人什么叫"正确"——改动破坏了什么，它会大声报错。

2. 文档¶

记录不只是代码做了什么，还有当时为什么这么决定、取舍是什么。

3. 评估结果¶

给质量打分，能看出下一个版本是变好还是滑下去。效果：下一轮 Agent 面对的不是空白起点，而是有记忆的现场。它不能退化到测试套件以下（测试会失败），不能无视文档（就在眼前），不能把质量拉到评估基准以下（分数记着）。 质量地板每一轮都在上升。单向前进。

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

GBrain 是 Garry Tan 的知识系统——给 AI Agent 提供长期记忆。

"认识论提取"功能¶

横跨 28,000 页，提取"谁相信什么、置信度多少"。第一版结果：100,720 条观点，跨模型评分（GPT-5.5 + Claude）总分 6.8/10。最大问题："持有者混淆"——"AI 将在 2027 年前取代 80% 软件工程师"这句话是谁的？是写的人说的？引用别人？系统分析引擎从播客文字稿推断出来的？第一版 35% 的情况搞错这个区分。

棘轮响应¶

评估结果被记录，6 个具体失败模式被识别
第二版提示词针对性修复了全部 6 个
置信度取整规则被强制到数据库层（不再出现 0.74 假精确，0.75 才是诚实答案）
17 条测试把这份契约锁住 从此，没有任何未来版本能在不通过这 17 条测试的情况下发布。

为什么 90% 以前做不到，现在可以¶

人类撑不住那最后 20%：

写第 14 个边界情况测试时感到厌烦
周五下午五点图省事
"以后再说"心理 AI Agent 不感受努力：它不会在凌晨两点抱怨，会彻底地写完每个边界情况。但有一个重要区分：
执行成本（写测试的意愿）：→ 接近零 ✅
发现成本（知道该测试什么）：→ 没有跟着降 ⚠️

那最后 20% 之所以难，不只是因为人类懒，更是因为那些边界情况本身很难被识别——你不知道你不知道什么。Agent 可以非常勤快地测试它能想到的所有情况，但它能想到的，往往和人类工程师来自同一个分布。

TTY 终端层面测试 Agent 行为契约¶

GStack 有"交互式方案审查"功能——Agent 应该逐段问问题，而不是一次性倒出所有发现。问题：Claude Code 有时会跳过交互，直接把所有发现倒出来然后退出。 怎么测试"AI 有没有对话"？用 Bun 的 TTY 功能把 Claude Code spawn 在伪终端里： 1. 喂给特定代码库场景，触发审查技能 2. 实时监控终端输出 3. 观察 Agent 有没有在结束前发出交互式问题 4. 如果没有问任何东西——测试失败 棘轮响应三层： 1. 技能指令里的强制停止门："你必须在进入下一节前问用户"，防合理化条款 2. 反捷径条款："方案文件是交互审查的输出结果，不是它的替代品" 3. 终端层面的门槛测试：实际把 Claude Code 在受控场景里运行

这不是在测试代码。这是在测试 AI Agent 有没有遵守行为契约。在终端层面。通过字面上盯着它工作来实现。

测试是机构记忆¶

传统软件公司：机构记忆住在人脑里。知道为什么那个缓存层存在的资深工程师。那次差点摧毁数据库的迁移的架构师。人会离开，知识消失。 Agent 的上下文窗口不会离职、不会被挖走、不会遗忘。当测试套件里写着"置信度取整必须用 0.05 的步进"，文档里解释着"因为跨模型评估显示假精确会降低对分数的信任"——这份知识是持久的。任何 Agent、任何模型、任何时候都能加载这个上下文。

测试是能熬过人员流动的机构记忆。对一个单人项目来说，它们更关键——那是你唯一拥有的机构记忆。

棘轮不只对代码有效¶

任何计算机能观察到的东西都可以被棘轮：

操作系统：进程树、文件系统状态、网络套接字
终端：每一次按键、每一行输出、每一个交互提示
浏览器：渲染后的页面、按钮状态、导航事件
API：结构化响应供解析验证
AI Agent：可观察的行为——它说了什么、调用了什么工具、按什么顺序做事、在行动前有没有先询问 能观察 → 能断言 → 能棘轮。

棘轮 + PR → 安全地开放贡献¶

GStack：37 名贡献者，v1.30 单次发布合并 21 个社区 PR。 GBrain：25 名贡献者，v0.31.1.1 单次 PR 落了 22 个社区修复。 棘轮让这件事变得安全：每个外部 PR 必须通过现有测试套件。新贡献者不需要理解整个系统，只需要让测试通过。

尚未解决：方向问题¶

棘轮机制解决了退化问题，但没有解决方向问题。一个只升不降的地板，前提是地板在往正确的方向升。Garry Tan 把这个叫做"品味"，然后用括号一笔带过了。

那个括号里装的东西，比这篇文章讨论的其他所有东西都更难，也更重要
测试通过 = 变好了？但也许只是对覆盖到的部分更有信心，同时让那 10% 未覆盖的地方更难被发现

核心金句¶

五十年来，90% 的测试覆盖率是奢侈品。AI Agent 把那堵墙拆了。

*

深度分析¶

本文提出了一个极具解释力的工程框架，但其逻辑链条仍有几处值得拆解。

1. DRE 数据从哪里来¶

Capers Jones 的缺陷移除效率研究（10,000+ 项目）是本文最有力的数据支撑，但原文没有给出具体出处。Jones 的工作横跨 1990-2010 年代，样本以大型企业级瀑布项目为主。DO-178C 的 99% DRE 数据来自航空电子，这是极端高可靠性领域，与典型 AI Agent 编程场景存在较大差距。将这两组数据放在同一张表里呈现，暗示它们是同类数据，可能造成误导。实际落地时，85-95% 覆盖率的非线性拐点结论是可靠的，但拐点具体在 85% 还是 90%，取决于你的代码库规模和复杂度。

2. 棘轮三层中"文档"的可操作性最弱¶

测试可以自动化检查，评估结果可以量化，唯独"文档"没有客观门槛。本文把"文档"定义为记录"当时为什么这么决定、取舍是什么"，但如果下一轮 Agent 只是写一份形式上合规的文档而不记录真正有价值的决策，棘轮的这三分之一就失效了。在 GBrain 实例中，真正锁住知识的是 17 条测试，而不是文档本身。文档在实践中最可能成为棘轮里最薄弱的环节。

3. 发现成本才是真正的瓶颈¶

本文区分了执行成本（写测试的意愿，趋于零）和发现成本（知道该测试什么，没有跟着降），但随后把发现成本问题归入"尚未解决：方向问题"一节，这个处理方式有些回避。发现成本不只是"边界情况难以识别"，更深层的问题是：AI Agent 的训练数据来自人类工程师的历史代码，因此它能想到的边界情况分布与人类工程师同构。如果测试套件里的边界情况本身就是盲区的产物，90% 覆盖率锁住的可能是一个有系统偏差的质量地板。

4. TTY 行为测试的局限¶

用 Bun TTY 监控 Agent 是否发出交互式问题，是一个非常有价值的思路——把"行为契约"变成可验证的断言。但测试框架本身是 Agent 写的，这意味着测试本身也受同样的发现成本限制：如果 Agent 不知道某种行为模式是重要的，它根本不会写测试去检查它。行为契约测试的前提是，人类（或另一个知识源）已经知道"正确的行为应该是什么样"。

5. 方向问题是真正的未解问题¶

本文在最后坦承棘轮不能解决方向问题，但将其描述为"品味"问题后一笔带过。实际上，方向问题有两层含义：第一，测试覆盖的方向由人来决定（测什么、不测什么），Agent 只能执行；第二，覆盖率到 90% 之后，未覆盖的 10% 的风险被放大，因为团队会对通过测试的部分更有信心，而这 10% 往往包含最重要的边界情况。这个悖论在传统软件工程里已有大量案例，不是理论上的担忧。¶

实践启示¶

立即可做：从 90% 覆盖率开始¶

单人项目最容易在"没有测试"和"有测试但覆盖率低"之间徘徊。如果你的代码库还没有稳定的 CI，优先把覆盖率打到 85%+。不需要从第一天就做到 90%——从 70% 到 85% 的过程已经能让你感受到缺陷逃逸率的非线性下降。DRE 数据曲线在 85% 处有拐点，这意味着投入产出比在 85-90% 区间最优。

建立锁住知识的最小测试集¶

不要试图一次性写出完美的测试套件。正确的姿势是：每次发现一个 Bug 或边界情况，立即写一条测试把它锁住。17 条测试锁住 GBrain 的置信度规则，这个数字不大，但足够防止已知错误的回归。先锁住，再扩张。

用评估结果建立质量基线¶

每发布一个版本，打一个质量分。不需要复杂的评分体系，只需要一个能跨版本对比的指标。这个分数的绝对值不重要，重要的是它能反映方向——下一个版本比上一个版本好还是差。没有基线，棘轮就失去了一维参照系。

警惕"覆盖率即质量"的幻觉¶

90% 覆盖率不等于高质量代码。覆盖率高只能证明"执行了测试的动作"，不能证明"测试覆盖了正确的动作"。定期审查你的测试套件：有没有测试是在测试一个已经失效的接口？有没有重要的边界情况完全没有被覆盖？每季度至少一次与同行（或另一个 Agent）交叉审视测试套件本身的质量。