KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

07 · 度量与门禁：怎么知道你真的变快了 — keel 龙骨

这一章回答：所有前面的动作有没有用，怎么证明。

这一章回答：所有前面的动作有没有用，怎么证明。

前面六章讲的是做法。这一章讲的是判据——没有度量，你就只能在"感觉挺顺"和"这周好像一直在返工"之间摇摆，而这正是 METR 实验中那 16 位资深开发者的处境：他们做完任务后坚信自己快了 20%，实际慢了 19%。

为什么必须度量

三条理由，强度递增：

  1. 感知不可靠：流畅的输出会制造效率幻觉（perception gap）。AI 让你少敲了很多键，但这些省下的时间可能转移到了读代码、调 bug、解释需求上。
  2. 技术债的账单延迟到账：GitClear 对 6.23 亿次变更的统计显示，复制/重复上升、重构与旧代码维护骤降。这些变化在任何一个 PR 里都看不出来，只在系统整体体检时显形。
  3. 它决定了你该在哪投人力：如果某类任务用 AI 反而更慢，正确的做法是改流程或干脆不用，而不是继续投入感情。

一个常见的时间线：原型悬崖

很多团队的经历高度一致：

第 1~2 月：出活飞快，功能叠得停不下来
第 3~6 月：开始出现"改 A 坏 B"，review 时间上升
第 7~9 月：有新用户/真实数据，早期数据模型的缺陷集中暴露，返工成本陡增

把拐点叫原型悬崖。它不是一个技术故障，而是早期为了速度透支的架构一致性，在流量和真实数据的压力下到期兑付。GitClear 数据里"12 个月以上旧代码的维护占比下降 74%"，正是悬崖的成因：最需要被回头修的那一层，恰恰最少被回头看。

应对不是放慢速度，而是在正确的节点付费：30 分钟写清楚的 Constitution，抵得上第九个月的两周重构。

五个可观测指标（个人就能采集）

不需要复杂平台，一张表每周填一次就够：

# 指标 怎么算 恶化信号
1 返工率 同一需求对话轮次 ≥3 次才收工的比例 > 30% 说明上下文/规格有问题
2 一次通过率 首次交付就能通过全部校验（lint+构建+自测+冒烟）的比例 < 60% 说明验收标准没先建立
3 diff 规模 平均每次改动的 git diff --stat 行数与文件数 与任务复杂度不成比例地膨胀，说明范围失控
4 AI 改动占比 & 其中被推翻的比例 AI 生成的行数 / 你在 review 中删改的行数 推翻比例高说明样板文件没给够或范围没锁死
5 交付后缺陷密度 上线后 7 天内由本次改动引发的 bug 数 上升说明 happy path 之外没覆盖

填表的关键动作：每周固定时间花 10 分钟，凭命令输出和 git log 填，不要凭印象填。两个周期之后你就能看出趋势，四个周期之后你就有了"要不要继续用 AI 做这类任务"的决策依据。

如果有团队环境，可以再叠一层工程指标（DORA 风格的四个指标同样适用）：变更失败率、平均恢复时间、部署频率、交付周期。它们的好处是能横向对比"AI 介入前 vs 介入后"。

把度量变成门禁

量出来之后，下一步是让它自动把关——没有自动化的规格只是一纸空文：

层级 门禁 拦什么
提交前 pre-commit hook：lint + formatter + 敏感串扫描 风格漂移、密钥泄露
PR 时 CI：构建 + 测试 + 项目自带校验 + 覆盖率下限 语法/依赖/隐式约定破坏
PR 时 AI review：与 Spec/约定逐条比对 遗漏的边界、重复实现、与约定不一致
合并前 人工 review：业务语义、架构判断、安全 AI 做不了的判断
发布后 冒烟 + 关键指标看板 环境差异导致的事故

注意第二行里那句"项目自带校验"：这是最容易被漏掉、也是最有用的一道。 因为它编码的是你这个项目特有的、AI 绝对猜不到的约束。

什么时候应该别用 AI

这门课讲的是用好 AI，但知道什么时候不用同样重要。遇到下面四种情况，手写或先自己想清楚通常更快：

  1. 改动涉及你还没理解的模块：先读代码，而不是让 AI 替你理解。
  2. 决策本身还没定：此时 AI 会替你做一个你没意识到的假设；先用 6.2 的任务单把意图写清楚。
  3. 一次性、规模极小的改动：沟通成本大于收益，直接敲键盘更快。
  4. 需要承担责任的设计取舍：架构决策、数据模型、安全边界——AI 可以列选项，但拍板和背责的是你。

一个判断口诀：用 AI 处理"想全"和"做到"，人负责"要什么"和"对不对"。

动手：可观察结果

两周之内建成你的度量闭环：

产出 判断标准
一份周表 五个指标各一列，连续两周有数据（不是印象，是 git log / CI 输出）
一条 pre-commit 或 CI 门禁 至少覆盖 lint + 敏感串扫描，且能演示被拦住一次
一次发布后冒烟 列出首页/关键资源/后台入口三项检查，发布后 2 分钟内完成
一份基线与对比 记录干预前一周与干预一周后的指标差异

完成标志：当有人问你"用 AI 之后到底有没有更快"，你能拿出一张表和四个数字，而不是一个感觉。

故障注入

注入方式 观察
连续两周不填度量表，只凭感觉判断 之后回看 git log，看你的感觉和实际返工率差多少
关掉 CI 里的 lint 步骤一周 统计风格漂移规模，估算恢复成本
发布后不做冒烟 记录第一个发现事故的人是谁（通常不是你自己）
把一个没想清楚的需求直接丢给 AI 看它替你做了多少个你没同意的决定

自测题

  1. METR 的 perception gap 对度量实践的直接启示是什么？为什么"我觉得快了"不能作为结论？
  2. 原型悬崖的成因是什么？在你的项目里，最可能需要提前付费的是哪一处设计？
  3. 五个指标里，哪一个你目前完全拿不到数据？要拿到它，最小成本的做法是什么？
  4. 门禁金字塔里，"项目自带校验"为什么是最容易被漏掉又最有用的一道？
  5. 你最近用 AI 做的一件任务，回头看是否属于"应该别用 AI"的四类之一？

结课：这门课的自我说明

替身边界：这份材料讲的是协作方法，不替代任何具体技术栈的系统学习，也不承诺"用了就一定更快"——数据表明，方法不当反而会变慢。

它没有覆盖的：具体工具的快捷键与配置细节、多智能体并行编排的工程实现、团队级 AI 编码平台的搭建、以及法律与合规的深度议题（许可证兼容性、数据跨境、生成代码的著作权归属）。这些都需要另行专项研究。

一句话收尾：AI 编码竞赛的下一阶段，比拼的不是谁的模型更强，而是谁能给它装上约束、门禁和度量。这三样东西目前都不在模型里，只能是你搭起来的。

进入 keel 阅读