最近我让一个编码 agent 帮我改一处老代码。它改对了,测试全绿。但提交记录里的净增行数让我愣了一下:同样一个功能,它写了三遍。
不是写错,是写胖。
代码质量的下一道门,不是“对不对”,是“胖不胖”,而这道门只能由人守。
Earendil 9 月 10 日的工程博客(Hacker News 276 分)给出了两个能算出来的指标。一个是 Verbosity,把工具标记的冗余行和克隆行合并后除以代码总行数;一个是 Erosion,算出圈复杂度大于 10 的函数所占的体积比例。人类仓库的 verbosity 是 0.15±0.06,评测里 agent 产出的代码是 0.33±0.10;erosion 分别为 0.31±0.17 和 0.68±0.20。它写的代码,平均比人写胖一倍。
这两个数的价值不在精确,在于可比较。技术债以前是评审会上的一句感受,现在是一个能进 CI 的数。净增行数和复杂度分布,每次提交里本来就有,不需要额外成本就能取到。
我对这件事有身体记忆。去年把 AI 巡检后端重构成四层架构,我定的第一条规矩不是分层,是“业务层里不许出现框架的上下文对象”。那条规矩本质上也是一种“胖”的度量,只看依赖表,就能判断边界有没有松。区别是当时靠人盯,现在可以写进流水线。
我最近用编码 agent 做生产改造,最难受的不是它改错,是它每次都对、测试全绿,可仓库一天比一天厚。半年后没人敢动那部分代码,不是因为看不懂,是因为找不到该在哪一层改。
但有个反面提醒得说清楚。博客作者自己点明,最简单的净增行数代理有效,可这是 Goodhart 陷阱:一旦开始按它考核,它立刻失效。 所以它在 CI 里当黄灯用,不能当 KPI 用。
同一份材料引的评测 SlopCodeBench 把评测方式反过来设计:多轮指令,每轮之间清空模型上下文,更接近我们真实的迭代用法。结果是坏决策随时间累积,在“每个检查点都必须全部测试通过”的严格口径下,最先进模型的通过率是 0%。 作者注明测的是 GPT 5.6 sol xhigh 一档,未测 Fable 5.1 与 Astra。
我的判断是,这不是模型笨,是它做决策时看不到自己上一轮的动机。上下文一清,坏决策就成了既成事实,后面每一轮都在这个既成事实上继续加盖。所以我一直不相信“让 agent 自己去重构、去清理”这条路,它会把自己的历史当成外部环境。
那该靠什么?还是靠边界。约束不等于限制能力,把权限和范围收窄,agent 反而敢放开了干。 我那条“业务层不许出现框架对象”的规矩,真正的作用不是防御,是让后来每一次改动都有确定的位置可以放。
再补一个评测方法的坑。这份材料里讲,业界最常用的“让模型给代码打分”基本等于随机数,A/B 对比还会因为把方案改个名字就翻转偏好。结论很直白:度量要落到可计算的量上,不要落到另一个模型的判断上。
这件事和写文章是同一回事。AI 让产出量涨了十倍,判断力没跟着涨,结果就是内容变厚、可读性变差。写代码和写文章,最后卡在同一个地方:谁定边界,谁来剪。
claude plugin eval,可对插件跑评测套件并输出可复现的打分报告;同版本修掉一个权限规则跨配置源生效的问题。