夜雨聆风基于 arXiv:2605.20049, Trivedi & Schmitt (2026), SonarSource
TL;DR
一篇 2026 年 5 月的论文用 660 次对照实验测量了代码整洁度对 AI 编程智能体（Claude Code）的影响。核心发现：
代码整洁度不影响任务通过率
但在干净代码上，AI 用的 token少 7-8%，重复访问文件的次数少 34%
结论：整洁代码不改变 AI "能不能做"，但显著影响 AI "做得多快、花多少钱"
本文从实践角度解释这些发现意味着什么，以及你应该如何调整你的 AI 辅助编程工作流。
1. 实验设计（理解它才能用对它）
1.1 最小对照对方法
论文的核心创新是实验设计。研究团队构造了"最小对照对"（minimal pairs）：同一代码仓库的两个版本，架构、依赖、外部行为完全相同，唯一的不同变量是代码整洁度。
构造方式有两条路径：
路径 A：从干净仓库退化（degrade）
原始干净仓库 → AI pipeline 故意引入坏实践 → 脏版本路径 B：从脏仓库净化（clean）
原始脏仓库 → AI pipeline 重构优化 → 干净版本两条路径各产生 3 对，共 6 对对照仓库。
1.2 整洁度的操作化定义
论文没有用"代码好不好"这种主观标准，而是用两个可量化的指标：
认知复杂度（cognitive complexity）与传统的圈复杂度（cyclomatic complexity）不同。圈复杂度只数分支数量，认知复杂度还要考虑：
嵌套深度（每多一层加一分）
逻辑运算符串联（a && b \|\| c && !d 每多一个运算符加一分）
递归调用（比普通循环更难跟踪）
控制流中断（break、continue、goto）
1.3 实验规模
2. 核心发现
2.1 通过率：无差异
在 660 次实验中，代码整洁度没有显著影响任务通过率。
这意味着：如果你的唯一目标是"功能做对了就行"，那代码质量确实不影响 AI 的结果。这个发现部分支持了 Vibe Coding 的直觉——让 AI 自己折腾，结果可能差不多。
2.2 操作足迹：显著差异
但通过率只是一个维度。论文还测量了"操作足迹"（operational footprint），发现了两个显著差异：
这两个指标的实践含义完全不同。
Token 消耗少 7-8%，换算成成本：假设你每月 AI 编程费用是 $200，代码整洁能帮你省 $14-16/月。对小团队来说是零花钱，对 50 人以上团队开始有感觉，对 200 人的工程组织是实打实的成本项。
文件重复访问少 34%，换算成时间：AI 在脏代码上要反复读同一个文件才能理解逻辑。这意味着任务执行时间更长。如果你习惯盯着 AI 的输出等它完成，脏代码让你多等的时间可能比 token 成本更让人烦躁。
2.3 一个关键警示：论文没有检查已有测试是否被破坏
论文在方法章节中明确写道：
"We do not check whether the agent broke unrelated tests already present in the repository."
这意味着：AI 在脏代码上完成任务的同时，可能破坏了代码库中其他测试——而这没有被记录。如果把这个因素加进去，脏代码上的"真实通过率"可能更低。
这是一个重要的方法论限制，在读论文结论时需要注意到。
3. 从实验到实践：这些数字在真实项目中意味着什么
论文用的是 AI 生成的"人工脏代码"和"人工干净代码"。真实项目中的代码腐烂远比实验模拟的复杂。基于论文数据和业界经验，以下是几个可以外推的指导原则。
3.1 文件大小是最直接的杠杆
论文没有专门测量文件大小，但 HN 讨论中多位工程师独立观察到了一个相关现象：大文件（>1000 行）对 AI 的导航效率影响极大。
原因很直接：AI 浏览代码的方式是"搜索 → 读片段 → 定位"，不是"通读全文"。一个 5000 行的 utils.py，AI 可能需要多次 grep + read 才能找到目标代码。拆成 5 个命名清晰的小文件后，AI 第一次搜索就能命中。
实践建议：给你的代码库设定一个文件大小上限（比如 800 行），超过就拆分。这比任何 lint 规则都更直接影响 AI 效率。
3.2 文件名是 AI 的导航系统
AI 导航代码的方式和人很像——它先搜关键词，然后打开看起来相关的文件。如果你的文件命名清晰（auth_service.py、payment_validator.py），AI 的命中率高。如果你的文件命名模糊（utils.py、helpers.py、common.py），AI 需要多轮搜索。
这就是论文中"文件重复访问少 34%"的根本原因之一：干净代码的符号（文件名、函数名、类名）本身就构成了高效的语义索引。
实践建议：给你的新代码库配一个命名约定文档（哪怕就 10 行），要求每个文件名必须让一个不了解项目的人猜出里面是什么。
3.3 死代码和废弃代码比"不规范"危害更大
论文用静态分析违规数来衡量整洁度，但 HN 讨论中有一个更有价值的区分：
静态分析违规
（命名不规范、缩进、缺少分号）→ AI 基本不受影响
死代码、冗余抽象、半成品设计模式
→ AI 严重受影响
原因：前者是"不漂亮"，后者是"误导"。AI 看到一段被废弃的旧 API 代码，可能以为它还在用，基于它构建新功能；看到一个半成品的抽象层，可能以为这就是正确的扩展方式。
实践建议：在 AI 编程的工作流里，删代码比写代码更重要。每次让 AI 完成一个任务后，增加一个"清理步骤"——让 AI 检查是否有可以安全删除的代码。
4. 实操工作流
基于以上分析，以下是四个具体的、可以立刻用到 AI 编程中的操作。
4.1 周期性重构指令
不要等代码烂了再重构。在你感觉到 AI 变慢、频繁"迷路"时，运行这条指令：
请对当前代码库做一次重构，目标：1. 拆分超过 800 行的文件2. 消除重复逻辑（但不要为了 DRY 而 DRY —— 两个函数长得像但逻辑不同时，不要合并）3. 移除未被引用的死代码4. 统一命名风格（使用项目现有的命名约定）5. 保持所有已有测试通过重构后，列出你做了哪些改动，每一项标注原因。
4.2 配置 AI 编程的 pre-commit 检查
在你的 .pre-commit-config.yaml 中增加：
repos:- repo: localhooks:- id: file-size-limitname: 文件大小检查entry: python -c ”import sys; [sys.exit(1) if len(open(f).read().split('\n')) > 800 else 0 for f in sys.argv[1:]]”language: systemfiles: \.py$- id: dead-code-checkname: 死代码检查entry: vulturelanguage: pythonfiles: \.py$args: [--min-confidence, ”80”]
vulture 是一个 Python 死代码检测工具。对于其他语言有对应的工具：
JavaScript/TypeScript → ts-prune 或 knip
Go → deadcode
Rust → cargo-udeps
关键是：把检查自动化。不要让 AI 提交的代码绕过质量检查，因为 AI 本身是熵增的——它每次提交都可能引入微小的复杂度膨胀。
4.3 建立"AI 效率信号"监控
论文的核心洞察是：整洁度影响效率，不影响结果。如果你想知道自己的代码库什么时候需要重构，可以监控以下几个信号：
如果你用的是 Claude Code 或类似工具的 API，这些数据可以从 raw log 中提取。如果你用的是 Cursor 或 Copilot 的封装 UI，目前还缺少这个维度的可观测性——这是工具层面的一个空缺。
4.4 用 AI 自己来做代码审查
HN 上有工程师分享了一个高效的组合拳：
让 AI 写完代码后，用同一个 AI 做一次 code review
Review 的 prompt 使用具体的质量标准（不要只说"review this"，要说"按 SOLID 原则 review，给出具体的重构建议"）
对 review 结果做一次人工审查（5-10 分钟），挑出真正有价值的建议
让 AI 执行这些建议
这个流程的关键在于第二步——给 AI 具体的标准。模糊的 review 指令会让 AI 给出模糊的建议，比如"这里可以更清晰"。具体的标准（"检查是否有超过 3 层嵌套的 if-else"、"检查函数是否超过 50 行"）才有可操作性。
5. 论文的局限性和未解决的问题
5.1 只测了一个工具
所有实验都在 Claude Code 上完成。不同的 AI 编程工具（Cursor、Copilot、Codex、Windsurf）有不同的代码导航策略（有的用 RAG、有的用 AST 索引、有的是全文搜索），因此结论不一定直接推广。
一个合理的外推假设：越依赖"搜索+阅读"模式导航的工具，受代码整洁度影响越大；越依赖结构化索引的工具，影响越小。但这需要额外的实验验证。
5.2 "脏代码"是合成的
论文中的脏代码是 AI 故意制造的，而非真实项目中的自然腐烂。真实的脏代码通常更隐蔽——混合了过时的业务逻辑、没有文档的历史决策、以及"不知道为什么但如果删了就会崩"的神秘依赖。这些对 AI 的迷惑性远超实验中的合成数据。
5.3 没有测量代码质量输出
如前所述，论文只检查了"任务是否通过"，没有检查 AI 是否破坏了已有测试。这是一个重要的质量盲区。后续研究如果能加上"已有测试回归率"这个维度，结论会更全面。
5.4 样本量和任务复杂度
660 次试验在学术上不算大样本。而且任务都是功能添加和 bug 修复，不涉及跨模块架构变更——而那正是 AI 在脏代码上最容易翻车的场景。
6. 关键结论
代码整洁度不是"好不好看"的问题，是"贵不贵"的问题。每 100 美元的 AI 编程费用里，大概有 7-8 美元是代码烂造成的。
优先优化"可导航性"。文件命名 > 文件大小 > 死代码清理 > lint 合规。排序依据是对 AI 效率的实际影响。
把重构嵌入 AI 工作流。不要等积累了再重构。在 AI 完成每个功能后，加一个 2-3 分钟的"清理步骤"。
AI 本身是熵增的。它写的代码自带复杂度膨胀倾向。没有人工的质量把关，AI 辅助的项目会比纯人工项目腐烂得更快。
论文的 7-8% 是下限，不是上限。真实项目的脏代码对 AI 的惩罚可能远超这个数字。把它当作"最低成本"而不是"平均成本"。
参考来源
Trivedi, P. & Schmitt, O. (2026). "Does Code Cleanliness Affect Coding Agents? A Controlled Minimal-Pair Study." arXiv:2605.20049.
Hacker News discussion thread (2026-07-05). 82 points, 43 comments.
SonarSource. "Cognitive Complexity."
Balajee RC. "Use Deterministic Guardrails for your LLM Agents."
