代码越干净，AI 编程助手越省钱吗？一项最新研究给开发者的启发

过去一年，很多团队开始把 Claude Code、Codex、Cursor、各种代码 Agent 放进真实研发流程。讨论最多的问题通常是：哪个模型通过率更高？提示词怎么写？测试集怎么搭？但有一个更贴近工程现场的问题反而容易被忽略：同一个 AI 编程助手，面对“干净代码”和“脏乱代码”时，表现会不会不一样？

我今天在 Hacker News 上看到一篇 arXiv 论文《Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study》（arXiv:2605.20049）。它没有把结论写成“AI 会被坏代码打败”这种夸张标题，而是用一个更细的实验回答：代码整洁度未必显著改变任务通过率，但会明显影响 Agent 的 token 消耗和代码导航效率。这个结果对准备在团队里落地 AI 编程工具的开发者很有参考价值。

1. 研究到底问了什么问题？

传统代码质量讨论里，“可维护性”通常服务于人：代码结构清晰、命名一致、复杂度低，后续接手的人更容易读懂和修改。AI Agent 出现后，问题变成了：如果修改代码的是一个会读仓库、会调用工具、会反复查看文件的 Agent，干净代码还重要吗？

这篇研究的关键点在于控制变量。作者构造了所谓的 minimal pair（最小差异配对）：两个仓库在架构、依赖、外部行为上尽量一致，只在静态分析规则违反、认知复杂度等“代码整洁度”维度上不同。然后让同一个编码 Agent 在这些仓库上完成同类任务，并用隐藏测试检查结果。

这种设计比“随便找几个项目做对比”更有说服力，因为它尽量把模型能力、项目规模、功能差异等干扰因素压下去，只观察代码整洁度带来的影响。

2. 最值得关注的结论：通过率没明显变，但成本和路径变了

论文摘要里给出的结果很有意思：在 660 次试验中，代码整洁度没有改变 Claude Code 的任务通过率；但在干净代码上，Agent 使用的 token 少了约 7% 到 8%，文件重复访问减少了约 34%。

这意味着什么？如果只用“最终功能是否完成”衡量 AI 编程工具，你可能会得出“代码整不整洁无所谓”的结论；但如果把真实研发成本算进去，答案就不一样了。

• token 更少：意味着同等任务下推理成本、上下文占用和等待时间可能更低。
• 文件重复访问更少：说明 Agent 更容易定位关键代码，少走回头路。
• 通过率不变：说明强模型在一定范围内能“扛住”脏代码，但不是免费扛住。

对个人开发者来说，这可能只是一次调用多花几分钱、几十秒；对高频使用 AI Agent 的团队来说，这会变成可观的计算成本、排队成本和工程反馈周期。

3. 为什么干净代码会影响 Agent 的“操作足迹”？

从开发者直觉看，这并不难理解。现在的编码 Agent 并不是一次性读完整个仓库后直接生成完美补丁。它通常会经历以下过程：

1. 根据任务描述搜索相关文件；
2. 打开若干文件理解上下文；
3. 在实现、测试、配置之间来回跳转；
4. 生成修改并运行测试；
5. 失败后继续定位、修复、回看上下文。

如果代码里函数过长、职责混杂、命名不一致、异常分支分散，Agent 就更容易把上下文装错、漏掉关键条件，或者需要反复打开同一批文件确认关系。它最终也许能完成任务，但过程会更“费劲”。

反过来，干净代码相当于给 Agent 提供了更好的地图：模块边界清晰，函数名能暗示意图，测试能说明行为，复杂逻辑被拆成可理解的小块。AI 读代码的方式和人不完全一样，但它同样受信息结构影响。

4. 对团队落地 AI 编程的三个启发

启发一：不要只盯“模型排行榜”，也要治理代码库

很多团队采购或试用 AI 编程工具时，会把主要精力放在模型选择、IDE 插件、提示词模板上。这些当然重要，但如果底层代码库长期缺少重构、测试和规范，Agent 的效率很可能被仓库质量拖住。

一个实用做法是把“AI 友好型代码库”当成工程治理目标之一：降低单函数复杂度、统一命名风格、补充关键路径测试、清理废弃代码、让目录结构能反映业务边界。这些工作不只是让人舒服，也是在降低 AI 协作成本。

启发二：评估 AI Agent 时，除了通过率还要看成本指标

如果团队正在做内部评测，建议不要只记录“任务成功/失败”。可以额外记录：

• 每个任务消耗的 token 或调用费用；
• 平均完成时间；
• Agent 查看文件数量和重复查看次数；
• 失败后需要人工接管的比例；
• 补丁最终被 reviewer 要求返工的次数。

这些指标更接近真实生产力。一个通过率相同但更省 token、更少打扰人的方案，长期价值可能更高。

启发三：代码规范不是“形式主义”，而是上下文压缩

过去有些团队会觉得 lint、复杂度阈值、命名规范只是形式主义。AI 时代可以换个角度看：规范其实是在做上下文压缩。当代码遵循一致结构时，Agent 不需要把大量额外上下文塞进窗口里才能猜出意图。

这也解释了为什么“给 AI 写代码”并不等于“随便写，反正 AI 会改”。越是依赖 AI，越应该让代码库保持可读、可搜索、可测试。否则你省下的人工时间，可能会以 token、延迟、返工和不可控补丁的形式还回来。

5. 可以马上落地的一份检查清单

如果你想让自己的项目更适合 AI 编程助手，可以从下面这份轻量清单开始：

• 入口清晰：README 写清启动方式、测试方式、主要目录职责。
• 测试可运行：至少保证核心路径有自动化测试，避免 Agent 只能“盲改”。
• 函数短一点：把过长函数拆成有业务含义的小函数，减少上下文噪音。
• 命名稳定：同一业务概念不要在不同文件里换多套名字。
• 删除死代码：废弃分支、旧配置、无用工具类会误导搜索和推理。
• 错误信息具体：测试失败、异常日志越明确，Agent 越容易定位问题。
• 约定写进文档：把团队约定放进 CONTRIBUTING、docs 或项目规则文件，而不是只存在口头沟通里。

这些事情本来就是好工程实践，只是在 AI Agent 普及后，它们的收益从“方便人维护”扩展到了“方便机器协作”。

6. 一个理性的判断：别神化，也别忽视

这项研究并不等于证明“代码越干净，AI 通过率一定越高”。至少在论文描述的实验中，通过率没有显著变化。它更像是在提醒我们：AI 编程的真实成本不仅是模型能力，还包括代码库本身提供了多少有效结构。

未来模型能力继续提升后，脏代码对通过率的影响可能进一步下降；但只要 Agent 仍需要读取、搜索、定位、修改、验证，代码结构就会影响它的操作路径。工程质量不会因为 AI 出现而过时，只是评价维度多了一层。

结语

如果你正在用 AI 写代码，我建议把“代码整洁度”纳入 AI 工具落地的基础设施，而不是等项目混乱后再指望模型兜底。更干净的代码未必让 Agent 每次都更聪明，但大概率能让它少绕路、少耗上下文、少烧 token。

你在项目里使用 AI 编程助手时，有没有遇到过“代码越乱，AI 越容易反复看文件/改错位置”的情况？欢迎在评论区分享你的观察。

参考来源：arXiv:2605.20049《Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study》；Hacker News 当日讨论入口。本文为基于公开摘要与工程经验的原创解读。