一篇论文的数据，和一个反直觉的判断
SonarSource 上个月发了篇论文 Does Code Cleanliness Affect Coding Agents? ，抛出的问题很直接：代码干不干净，到底影不影响 AI 编码智能体的干活效率？
结论先说：代码越干净，智能体消耗的 token 越少、回看文件的次数也少。听起来像是"Clean Code 教条又赢了"对吧？
但我看完数据之后，想说的恰恰相反：综合人力时间成本和 token 消耗来看，代码简洁这件事，在 AI 协作时代确实贬值了。 不是说不重要了，是说它的投资回报率变了，而且变了不少。
一、论文说了什么
他们用"最小对立对"的思路------同一套架构和行为的仓库，只改干净度------在 Claude Code 上跑了 660 次试验。三个核心数字：
| 指标 | 干净侧 | 脏侧 | 差值 |
|---|---|---|---|
| Pass Rate | 91.3% | 92.1% | −0.9pp（基本没差） |
| 输入 Token | 基准 | +7.1% | −7.1% |
| 输出 Token | 基准 | +8.5% | −8.5% |
| 推理字符数 | 基准 | +11.1% | −11.1% |
| 会话轮次 | 基准 | +7% | −7% |
| 文件回看次数 | 显著更少 | 频繁回头 | −34% ★ 最大效应 |
三个发现拆开看：
- 能不能干完？ 0.9 个百分点的差距基本是噪声。干净代码不提升正确性。
- 干活的代价？ 干净侧输入 token 少 7%、输出少 8.5%、文件回看少 34%。文件回看降幅最大，被解读为智能体对改动的不确定性降低了。
- 任务类型有影响？ 跨模块改动（multi-module）效应最强；但那些被重构成一堆小方法的认知热点（cognitive-hotspot）反而 token 差不多------因为重构把复杂度重新分配到了更多方法里，总阅读量没真正降下来。
一个很诚实的方差警告： 同一个任务跑 10 次，token 用量能差 2.5 倍 ；72% 的任务组内比值超过 2×。27 个真实任务里只有 16 个干净侧更省 token，还有 11 个反而更费 。按任务看 input token 差值范围从 −47% 到 +44%，中位数 −4.5%。所以那个"−7%"是几百次试验池化后的均值，不是每次都能兑现的承诺。
二、我的判断：简洁性为什么贬值了
核心论点：代码干净度的收益（token 省 ~7%）远小于维持它的代价（人力时间 + 流程摩擦）。在 AI 参与编码的场景下，这笔账的 ROI 已经不如从前了。
1. 正确性不变 = AI 不挑食
这是最硬的数据。把 200 行 god method 拆成 10 个小函数、变量名从 xfm_q2 改成 normalize_query、删掉死代码------AI 干同一件事的成功概率几乎不提高（91.3% vs 92.1%）。
"为了以后好维护所以现在要写干净代码"这个经典论据里，"以后的维护者可能是 AI"这个分支基本被砍掉了。
2. 7% 的 token 节省，值多少？
算一笔粗糙但方向正确的账：
- SWE-bench 上单任务平均约 400 万 token，7% ≈ 省 28 万 token/任务
- 按 Claude Sonnet 4.6 定价，单任务 token 成本约 1 2，7% 大概省 0.07 0.14/任务
- 一个团队每周花在风格 review、lint 修复、重命名争论上的时间：至少 5~10 人时/周
- 一次"代码质量专项" refactor sprint：2~5 人天
就算你每天让 agent 跑 50 个任务，一年省的 token 钱也就几千美元；维持"干净"的人力成本，一年轻松十几万到几十万人民币。数量级不对等。
3. 方差大到你不该依赖它
前面说了，同一任务 10 次差 2.5 倍，27 个任务里 11 个反而是脏侧更省。你不能指望"把代码弄干净就能稳定省 token"------它更像统计趋势，不是每次兑现的承诺。
4. 认知热点任务的"中性"结果
把大方法拆成多个小方法，智能体反而要读更多文件才能拼出全貌。复杂度没被消除，只是被重新分配了。 很多我们以为的"代码改进"（过度拆方法），对人类更易读，对 AI 未必------它的上下文窗口有限，分散的信息反而增加拼接成本。
5. 维护干净代码的真实成本清单
- PR 审查中的风格争论------"这里该拆两个方法""命名不够语义化"，每次 10~30 分钟
- Lint / 静态分析告警修复------有些真问题，很多只是风格偏好
- Refactor sprint------通常占 sprint 容量 10~20%
- 新人上手成本------规范越多工具链越重，新人越容易被打回
- 团队共识成本------"什么算干净、什么级别值得 block merge"，这些讨论本身就是开销
这些都是持续性、复利、常被隐性化的成本。而它的回报，在 AI 时代主要是省约 7% token 和减少文件回看。
三、不是让你去写垃圾代码
我说的是"没那么重要了"，不是"不重要了"。几个地方干净代码依然值钱：
- 人类还要读的代码------团队有新人要看代码理解业务，可读性仍是第一优先级
- 跨模块导航------论文里 multi-module 效应最强，说明架构层面的清晰对 AI 确有助益（这是"模块边界"级，不是"变量命名"级）
- 长期自增强效应未知------论文没测"干净代码会不会引导智能体产出更干净代码"，如果是正反馈循环，长期价值可能比单任务 7% 大得多，但目前是 open question
所以我建议的是务实分级，不是一刀切：
| 等级 | 做什么 | 理由 |
|---|---|---|
| 必须做 | 模块边界清晰、公共 API 有文档、无死代码、无安全漏洞 | 人和 AI 都受益，出错成本高 |
| 值得做 | 关键路径方法控长度、避免深层嵌套、有意义命名 | 对人类可读性和 AI 多模块导航都有帮助 |
| 可以放 | 变量命名完美主义、过度拆小方法、严格 lint 规则集、纯风格类 PR block | ROI 在 AI 时代已下降，投入产出不成比例 |
四、总结
这篇论文给我最大的启发，是它提供了一个量化框架，让我们重新审视一个被默认接受太久的假设。
Clean Code 作为工程文化有价值。但当你的协作伙伴从纯人类变成人 + AI 的混合体，这个价值的权重需要重新计算。论文数据很诚实：pass rate 不变、token 省 7%、方差巨大。把这些数字放进真实的工程经济学模型，过去那种"不惜一切代价保持代码整洁"的策略，在今天已经不是最优解了。
与其在变量命名和方法行数上较劲，不如把精力放在模块划分、API 设计、测试覆盖这些人和 AI 都真正受益的地方。至于那些纯粹的风格洁癖------
放下吧，时代变了。
原文
《Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study》 Priyansh Trivedi, Olivier Schmitt
注：本文观点为作者个人判断，不代表论文作者立场。