代码通过测试以后，怎样衡量 AI 留下的维护负担
据 EARENDIL 9 月 10 日的工程讨论，AI 代码评估不应停在测试通过率，还应观察重复、冗余与复杂度集中。文章引用的 SlopCodeBench是一项此前发布的迭代开发基准，并非本周才出现的新论文。
作者：林岚｜OC 开发者生态编辑
据 EARENDIL 9 月 10 日的工程讨论，AI 代码评估不应停在测试通过率，还应观察重复、冗余与复杂度集中。文章引用的 SlopCodeBench是一项此前发布的迭代开发基准，并非本周才出现的新论文。
一句话结论：能完成当前需求，不等于容易完成下一次修改；质量指标应帮助定位问题，而不是替代人的架构判断。
测试绿了，维护者为什么仍会皱眉
设想一个工具已经支持读取文本，现在要增加压缩文件。最直接的办法可能是复制现有流程，再加一套条件分支。当前测试可以全部通过，但下次修复编码错误，就可能需要同时修改两个地方。
这不是说复用一定比复制好。过早抽象也会制造成本。问题在于，单次验收往往看不到选择对下一轮工作的影响，尤其在新需求不断出现时，早期结构会逐渐放大自己的优点或缺点。
AI 生成速度使这种积累更快显现。团队如果只把新增代码量视为产出，很容易让审查容量跟不上变化，最后既不敢删，也说不清哪些模块真正必要。
两个指标在观察什么
SlopCodeBench 使用冗余度与结构侵蚀信号：前者关注重复及规则识别出的啰嗦代码，后者关注复杂度是否集中在较大、较复杂的函数中。研究把多轮规格更新纳入流程，让 Agent 继续修改自己的旧解法。
它的价值是把“看着很乱”拆成可追踪现象。但规则识别仍有人工选择，复杂函数也不必然设计错误。解析器、状态机和业务规则本来就可能复杂，重要的是这种复杂性是否合理地被组织起来。
如果团队强迫所有函数都低于某个阈值，模型可能只是拆出更多跳转，让调用关系更难理解。指标一旦变成唯一目标，就可能把问题从统计表里移走，而不是从代码里消除。
论文的零通过率，要带上时间与定义
原始论文包含 20 个问题、93 个检查点，并报告其所测模型没有完整通过任何问题的全部阶段。这是严格的端到端条件，不等于每一步都失败，也不等于今天所有模型都无法维护代码。
EARENDIL 的讨论本身也提醒，较新的模型没有全部进入所引用测试。因此，不能把较早基准的结果直接贴给后来发布的系统，更不能把“该测量条件下表现差”写成“编程能力已经被证伪”。
相反，这类研究提供了一个值得继续复测的任务结构：给出变化中的需求，让旧代码承受下一次修改，而不是每次清空项目重新开始。
团队可以怎样把观察变成工作流
OC 建议把质量信号用于触发审查，而不是自动定罪。例如，一个小功能导致大量文件变化，值得追问修改范围是否合理；重复逻辑持续增加，值得检查公共行为是否已经分叉。
还可以要求每次变更说明“为什么这次没有复用旧实现”或“这个新抽象解决了哪一种已经存在的变化”。这比笼统要求模型“写优雅代码”更可核验，也方便后来的维护者理解当时的决定。
更重要的是保留可控的变更规模。一次巨大重写可能同时改变行为和结构，让回归原因很难定位；小步验证则让功能错误与结构调整有机会分别被检查。
不是拒绝生成，而是保住修改能力
软件的价值通常不止于某一天能运行。业务变化、依赖升级和安全修复都要求它继续被理解。若一个项目只有生成它的那次长上下文能解释，组织就已经承担了隐性风险。
因此，“人还能接手吗”应当是 AI 编程的产品指标之一。它不要求每行都由人亲写，却要求关键选择能被说明，失败能够定位，结构可以继续演化。
关键事实
- 本次新闻由工程讨论引出，引用的是既有 SlopCodeBench。
- 基准观察多轮变更，而非一次性完整规格。
- 冗余与复杂度集中是信号，不是完整质量定义。
- 旧模型测试结论不能直接覆盖后来模型。
OC 判断
测试证明了一部分行为，维护能力需要另一部分证据。把代码变更控制在可解释、可回退、可继续修改的范围，比追求一个漂亮质量分数更实用。
为什么重要
- 对开发者：观察架构债务如何跨迭代累积。
- 对团队：把审查时间纳入自动生成的真实成本。
- 对评测者：报告版本、检查点和成功定义。
评论
围绕这篇文章补充信息、提出问题或分享观察。