AI 写的代码正在变得几乎不会出错，但代码库一天比一天厚。这个矛盾第一次有了可计算的答案。
代码质量的下一道门不是「对不对」，是「胖不胖」；而这道门只能由人守，agent 守不住。
事实先压成一句：Earendil 的工程博客在 2026-09-10 系统整理了代码邋遢度的度量方法（Hacker News 276 分），用两个可计算指标验证了一件事——评测里 agent 产出的代码，冗余程度和复杂度集中度约为人类仓库的两倍；而一项把上下文在多轮之间清空的评测显示，最先进模型在严格口径下的通过率是 0%。下面只讲两件事：这两个数怎么用，以及为什么不能指望 agent 自己清理。
两个指标把技术债从口味变成了数字
这套度量来自 SlopCodeBench 论文，Earendil 做了工程化整理。两个指标都是比值，可以逐次提交计算：
| 指标 | 计算方式 | 人类仓库 | Agent 产出 | 差距 |
|---|---|---|---|---|
| Verbosity（冗余占比） | 工具标记的冗余行与克隆行的并集 ÷ 代码总行数 | 0.15 ± 0.06 | 0.33 ± 0.10 | 约 2.2 倍 |
| Erosion（复杂度集中度） | 圈复杂度 > 10 的函数体积之和 ÷ 全部函数体积之和 | 0.31 ± 0.17 | 0.68 ± 0.20 | 约 2.2 倍 |
其中函数体积的算法是 mass(f) = 圈复杂度(f) × √源码行数，用乘法把「又长又绕」的函数权重放大。作者还测了自己的若干 vibe-coded 项目，verbosity 最高到 0.4、erosion 最高到 0.75，说明这不是评测环境里的偶然现象。
这两个数真正的价值不在精确，在于可比较、可追溯、可自动化。 净增行数、克隆行、圈复杂度分布，每次提交里本来就有，不需要额外标注成本。技术债以前是评审会上一句「这段有点乱」的感受，现在是一个能写进流水线的数。
我对这件事有身体记忆。去年把 AI 巡检后端从「服务之间互相发 HTTP 请求」重构成四层架构，我定的第一条规矩不是分层，是「业务层里不许出现框架的上下文对象」。那条规矩本质上就是一种「胖」的度量——只看依赖表就能判断边界有没有松。区别是当时靠人盯，现在可以写进 CI。
但有个反面提醒必须说清楚：博客作者自己点明，最简单的「净增行数」代理虽然有效，却是典型的 Goodhart 陷阱，一旦开始按它考核，它立刻失效。所以它在流水线里当黄灯用，不能当 KPI 用。
量得出来，不等于清得掉：0% 这个数字值得记住
同一份材料引的 SlopCodeBench 把评测方式反过来设计：不是开局给全部指令再跑隐藏测试，而是多轮指令，每轮之间清空模型上下文，更贴近真实的迭代用法。结果是坏决策随时间累积，在「每个检查点都必须全部测试通过」的严格口径下，最先进模型的通过率是 0%。作者注明这一档测的是 GPT 5.6 sol xhigh，尚未测 Fable 5.1 与 Astra。
我的判断是，这不是模型笨，是它做决策时看不到自己上一轮的动机。上下文一清，坏决策就成了既成事实，后面每一轮都在这个既成事实上继续加盖。所以我一直不相信「让 agent 自己去重构、去清理」这条路——它会把自己的历史当成外部环境，然后在此基础上做局部最优。
那该靠什么？还是靠边界。把权限和范围收窄，agent 反而敢放开了干，因为它不用再自己判断哪里不能碰。我那条「业务层不许出现框架对象」的规矩，真正的作用不是防御，是让后来每一次改动都有确定的位置可以放。
再补一个评测方法上的坑。这份材料讲，业界最常用的「让模型给代码打分」基本等于随机数；更讲究一点的 A/B 对比法，会因为把方案改个名字就翻转偏好（引 arXiv 2604.16790）。结论很直白：度量要落到可计算的量上，不要落到另一个模型的判断上。
工具链已经把评测和可观测性收进配置项
同一周两条产品线上的变化，方向是一致的。
Claude Code v2.1.269（2026-09-11）新增 claude plugin eval，可以对插件跑评测套件并输出可复现的打分结果（JSON + HTML 报告）；OTEL_METRICS_INCLUDE_REPOSITORY 给指标与事件打上 vcs.* 仓库维度标签；CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS 把多 agent 扇出的并发上限做成 1–256 的配置项。评测、成本归集、并发治理三件事同时从「事后看」变成「配置项」。
同版本还有一个必须复核的变更：以 ! 开头的 deny / ask 权限规则此前会跨 settings 来源生效，现在只在本源内生效，且裸 ! 取反被忽略。 如果你的权限配置依赖旧的跨源行为，升级前先复核。同批还修掉了 Bash(tee:*) 白名单越界覆盖工作目录外写入目标的问题。
把两边接起来看：度量指标（verbosity / erosion）负责发现问题，评测工具（plugin eval）负责把发现固化成分数，可观测性标签（vcs.*）负责把分数按仓库归集。没有归集，度量就只能停在一次性报告上。
今晚可以动手的三件事
- 算一次基线。 在你最活跃的仓库上取三个数：工具标记的冗余行、克隆行、圈复杂度 > 10 的函数占比，算出 verbosity 和 erosion。多数语言都有现成工具，一个晚上够。把值记下来当基线，之后看趋势。
- 给提交加一道黄灯。 单次 agent 改动的净增行数超过基线两倍时先看 diff 再决定合不合。只提醒、不拦截，避免把指标逼成 Goodhart 陷阱。
- 改一条评审项。 把评审清单从「逻辑对不对」扩一条「这段能不能更短」，并写进项目的编码规范或
CLAUDE.md。让 agent 动手前就看到这条，比事后返工便宜一个数量级。
相关阅读：上一篇：PaperCut 攻击与 agent 的边界不能写进提示词，以及AI 工程的重心从聪明转向可控。
数据说明：Verbosity 与 Erosion 的公式、以及与人类仓库的对照数值来自 Earendil 工程博客（2026-09-10）对 SlopCodeBench 论文的整理，属于第三方工程复现，非厂商自报；SlopCodeBench 的 0% 严格通过率覆盖的模型档位为 GPT 5.6 sol xhigh，作者注明未测 Fable 5.1 与 Astra；LLM-as-judge 的偏好漂移引用 arXiv 2604.16790。Claude Code 的变更内容均取自官方 release notes v2.1.269 / v2.1.270。事件状态以各官方公告为准。