AI代码越短越好？收藏质量指标读法
AI把300行代码压成180行，就算重构成功了吗？如果只是把逻辑塞进更长的表达式，下一次修改可能更难。行数难以单独判断代码是否好维护。

Earendil在9月10日的技术文章里讨论了这个问题：功能测试能检查部分行为，却覆盖不了不必要的抽象、重复实现和设计取舍。作者认为行数变化有观察价值，也提醒，一旦只追着它优化，指标就可能失真。

文章引用的SlopCodeBench，把两种现象分开测量：冗余度看规则标记的多余代码与重复代码占总行数的比例，同一行不重复计数；结构侵蚀看复杂度是否集中在高复杂度函数中，同时考虑函数长度。后者并非简单数有多少个if。

指标没有覆盖全部业务约束和维护成本，不能代替完整验收。

我建议按下面四步读指标，例子是为了说明判断方法。

① 同时看比例和数量。
假设100行里有10行被标记，比例是10%；加入100行未被标记的代码后，比例降到5%，但原来的10行问题仍在。看到曲线下降，先问分子变小了，还是分母变大了。

② 找到具体热点。
整体复杂度变化不大，也可能某个核心函数已经塞进多种职责。让工具列出变化最大的函数，再看新增分支分别处理什么。需要核对的是业务逻辑能否被理解，而不是把分支机械拆到更多文件里。

③ 对齐前后统计口径。
固定工具版本、规则集、扫描目录和生成文件排除项。若新版多算了测试或生成代码，就不宜与旧版直接比较。把统计设置和报告一起保存。

④ 加一次真实的小扩展。
用现有需求中的一个变化检查维护难度，比如新增一种导出格式。观察要改几处、是否复制旧逻辑、原有功能是否退步。这里评估的是设计对变化的承受能力，不要为了想象中的所有需求提前造框架。

可以把验收写成一句话：“功能保持正确，重复问题有具体减少，下次改动能找到清晰入口。”指标负责指出检查位置，测试和代码阅读负责解释变化。

收藏这四步，验收AI代码时有据可查。有用点个赞。

代码质量 人工智能