通用方法 · 熟练
同一个任务，它写了 200 行还是 40 行？
解决率决定能不能用，体量决定三个月后还能不能改
选模型时我们只看两件事：它解没解出来、花了多少钱。第三件事几乎没人看 —— 它为了让这个任务通过，顺手加了多少你并不需要的代码。这件事在一次性脚本上无所谓，在你要养一年的项目里就是负债：多出来的每一段都要被人读懂、被下一次改动绕过、在出问题时被怀疑。这一页把「净增编码单元」这把尺子讲清 —— 它怎么算、为什么不能只看它、以及怎么把它加进你自己的选型表。判据一句话：只在解决率相当的两三个模型之间比体量，而且必须用你自己的任务比。
方法 · 一图看懂
1
先承认尺子缺一格 — 现有基准告诉你「解出来了」与「花了多少 token」，却不惩罚「顺手多写」
2
净增，不是新增 — 净增编码单元 = 新增语法单元 − 删除语法单元；不数行数（防压行刷分），删掉要扣
3
固定外壳再比 — 同一模型换一个 agent 外壳，体量能差到 0.88×；不固定外壳，比出来的是外壳的账
4
只在解决率相当处比 — 写得多与解得多正相关（Spearman 0.33~0.60）⇒ 最省的不等于最好的
5
把它写进选型表 — 一行一个任务，三列：过没过 / 花了多少 / 净增多少；三个月后再看一次
原理 · 为什么有效
「多写的代码」不是免费的：它要在评审里被读懂、在下一次改动时被绕过、在出问题时被怀疑。基准只奖励「解出来」，模型于是学会用更多代码换更高通过率 —— 这在一次性脚本上无所谓，在你要养两年的项目里就是负债。体量之所以按语法单元而不是行数计，是因为行数可以被格式刷掉；之所以要扣减删除，是因为「重写一遍但更短」和「在外面加一层补丁」在维护上是两件完全不同的事。另一面也要说清：体量只量「多大」，不量「好不好读」 —— 项目方自己就这么声明，所以它不是质量分，只是一列你没看过的成本。
适用场景
适用：你要长期维护 AI 写的代码；同一批任务要在两三个模型之间选一个长期用；团队里已经有人抱怨「AI 改完更难读了」。不适用：一次性脚本、数据清洗、原型验证（这些场景体量几乎不影响你）；只跑一次就不再碰的自动化；你手上还没有稳定的任务集 —— 那时先攒任务，别先比体量。另外一条：⛔ 别拿榜单的第一名直接当结论 —— 榜单只用来筛出候选，最终要在你自己的任务上跑一遍。
自测 · 5 问
我说得出这次要比的是哪几个任务，而不是「哪个模型更强」这种问法
我知道「净增」扣的是删除 —— 不会把「重写变短」误判成「少干活」
我要比的两三个模型，解决率是相当的（不是一个六成一个九成五）
我知道换 agent 外壳会改变体量，所以固定外壳再比
我打算三个月后再看一次这一列，而不是选完就不管
怎么上手 · 验证步骤
三步：① 挑 5 个你自己的真实任务（有明确完成标准、最好有测试）② 三个候选模型各跑一遍，每个任务记三格：过没过 / 用了多少 token / 净增多少（没有统计工具就粗记「改了哪些文件、加了几行、删了几行」）③ 只在「都过了」的那些任务上比体量，其余任务只记不评。三步做完你会得到一张很朴素的三列表 —— 它的价值不在精确，而在你第一次把「多写」这件事放到了台面上。
自检动作：把三次的改动并排打开，逐段问一句「删掉这一段，功能会坏吗」。如果某个模型交出来的东西里，有相当一部分你答「不会坏」，那一列就没白记；如果你对三个模型的回答都是「删不掉」，说明这几个任务还没到能比体量的复杂度 —— 换更接近真实工作的任务再来一轮。