当前位置：首页 > news >正文

我以为代码整洁对 AI Agent 影响很大，结果 660 次测试告诉我错了

news 2026/7/8 1:18:10

2026-07-07

几个月前我在重构一个项目的代码结构——把一个大函数拆成几个小函数，改掉那些反模式的命名，加上类型注解。同事问我在干嘛，我说「给 AI 收拾房间，代码整洁了 AI Agent 修 bug 才找得对地方」。

这话听起来有道理对吧？

整洁的代码更容易理解，更容易修改——这个假设在人类开发者身上已经被验证过无数次了。但 AI Agent 不是人类，它不看代码「顺不顺眼」，它只看 token 序列里有没有它需要的信号。

一个很自然的假设，一个很反直觉的实验

普林斯顿大学的几位研究者（Priyansh Trivedi 等）在 5 月份发了一篇 arXiv 论文，标题就是《代码整洁会影响编码 Agent 吗？一个受控的最小对比研究》。他们做了一个非常干净的实验设计：

创建代码仓库的最小对比对——两个仓库架构相同、依赖相同、外部行为相同，但静态分析规则违规数量和认知复杂度不同。

简单说：同一套功能逻辑，一套写成了「整洁版」，另一套「混乱版」。然后让 Claude Code 在这些仓库上执行同样的任务，看通过率有没有差异。

实验包含了 6 组最小对比仓库对，覆盖 33 个任务，总共跑了 660 次测试。这个规模不小了。

我最初看到这个设计时，心里已经有答案了——整洁版肯定通过率更高。这还用测吗？

结果数据打了我一巴掌。

通过率没变，但别的地方变了

核心发现只有一句话：

**代码整洁度不会影响 Agent 的任务通过率。** 整洁版和混乱版上，Claude Code 完成任务的正确率没有统计学显著差异。

看到这个结果时我其实是有点沉默的。这不是调参能解决的问题，是整个假设错了。

但论文没有止步于此。研究者进一步分析了 Agent 的行为指标，发现了另一个维度的差异：

Token 消耗减少 7-8%：Agent 在整洁代码上完成任务消耗的 token 更少
文件回访减少 34%：Agent 在整洁代码上需要的文件回溯（重新打开和浏览）频率大幅降低
编辑序列更短：Agent 在整洁代码上需要的编辑步数更少

也就是说，整洁代码没有让 Agent 「更聪明」，但让它「更高效」。

这其实符合直觉——整洁代码的命名更一致、结构更清晰，Agent 的注意力机制能够更准确地定位需要修改的位置，不需要反复回溯上下文。但最终它能不能正确改代码，取决于它是否理解了这个 bug 的语义，跟代码长什么样关系不大。

我从工位走到茶水间接水，脑子还在算这几个数字。34% 的文件回访减少是什么概念？如果一次 Agent 会话平均需要回访 15 次文件，减少 34% 就是少了 5 次。每次文件回访大约消耗 2000-4000 token，5 次就是 1-2 万 token。按 Claude 的价格算，每次调用能省 $0.15-$0.3。

那么问题来了：花时间重构代码以降低 AI Agent 的使用成本——这笔账划算吗？

方案的逐步放弃：我是怎么从「必须重构」到「不一定」的

这个发现让我重新审视了我最近的几个工程决策。

第一个想到的方案——全面代码重构。把所有混乱代码重构成整洁的、符合静态分析规范的代码。这个方案我很快就放弃了。原因很简单：成本太高。对一个十万行级别的项目做全量 lint 清理和重构，可能需要两周的人力投入。如果收益只是 Agent 调用省 8% 的 token，ROI 完全是负数。

第二个方向——只在 Agent 会频繁访问的模块做清理。既然 Agent 在整洁代码上更高效，那我只把 Agent 经常修改的几个模块清干净就行。这个方案听起来更合理，但问题是「Agent 会频繁访问哪些模块」这件事本身在变化。你今天认为 Agent 应该改 A 模块，明天它因为上下文关联频繁跑到了 B 模块，你的清理就白做了。

第三个方向——不对代码做任何重构，直接在 Agent prompt 里加上下文约束。如果整洁代码只是让 Agent 少回访文件，那我可以直接在 prompt 里告诉 Agent「修改前先列出所有相关文件名和位置」，强制它一次性读完所有需要的内容，减少回访。但实验后发现这个方案的问题在于——Agent 的上下文窗口虽然大，但注意力是有限的，prompt 越长，关键信息的信噪比越低。

我在三个方案之间犹豫了好几天，最后选的是第四个方案——混合策略：对 Agent 经常修改的核心模块做适度的代码清理（主要是命名统一和死代码删除），不追求全量 lint 合规；同时在 CI 里加入 Agent 行为监控，跟踪每次 Agent 调用的 token 消耗和文件访问模式，当某个模块的回访率异常高时，才针对性地清理。

不完美，远不完美。最理想方案当然是先做全量代码重构再引入 Agent 辅助开发，但项目排期卡在那。这个混合策略的好处是成本可控，问题是你永远不知道「当前的回访率」到底是代码质量问题还是 Agent 模型的固有行为。