一篇论文的数据和一个反直觉的判断SonarSource 上个月发了篇论文Does Code Cleanliness Affect Coding Agents?抛出的问题很直接代码干不干净到底影不影响 AI 编码智能体的干活效率结论先说代码越干净智能体消耗的 token 越少、回看文件的次数也少。听起来像是Clean Code 教条又赢了对吧但我看完数据之后想说的恰恰相反综合人力时间成本和 token 消耗来看代码简洁这件事在 AI 协作时代确实贬值了。不是说不重要了是说它的投资回报率变了而且变了不少。一、论文说了什么他们用最小对立对的思路——同一套架构和行为的仓库只改干净度——在 Claude Code 上跑了 660 次试验。三个核心数字指标干净侧脏侧差值Pass Rate91.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 万 token7% ≈ 省28 万 token/任务按 Claude Sonnet 4.6 定价单任务 token 成本约 $1~$27% 大概省$0.07~$0.14/任务一个团队每周花在风格 review、lint 修复、重命名争论上的时间至少 5~10 人时/周一次代码质量专项 refactor sprint2~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 blockROI 在 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注本文观点为作者个人判断不代表论文作者立场。