代码重构显著降低 AI 编程的 Token 消耗

当 Agent 大规模编写软件时，设计债务并不会消失，只是换了一种形式：除了让代码更难理解，它还会增加 Agent 每次修改时需要消耗的上下文量。

Giles Edwards-Alexander 描述了一个特别值得研究的案例。他使用 Claude Code 和 Cursor 构建了一个约 15 万行代码的应用——主要使用 Rust——期间没有系统性审查生成的代码。最终，数据访问层集中到了一个多达 17,155 行的单一文件中，其中存在大量重复的 HTTP 请求构建和 JSON 序列化代码。

这项实验的假设是：现在投入 token 进行重构，可以减少实现后续变更所需的 token。

作者选定了一项具有代表性的变更，分别在每轮重构前后执行，并且每一轮都使用一个全新的 Agent。这样可以避免 Agent 在过程中逐步积累对代码的了解。在每个阶段，他都记录了代码行数、输入与输出 token 数量，以及执行时间。

最显著的成果并不是来自大规模删除代码。数据访问层最终的规模几乎没有变化，仍有 16,608 行。真正缩小的是最大的那个文件：通过提取重复逻辑，并将不同职责拆分到更小的文件中，其行数从 17,155 行降至 3,695 行。

机制比删减规模更重要

随意拆分文件并不能保证节省 token。如果拆分后，一项职责反而散落在多个位置，Agent 仍然需要打开并逐一查看所有相关文件。实验中观察到的收益，似乎取决于两点：更清晰的边界，以及每次变更所涉及的文件集合更小。

这一区别非常重要。架构不仅能降低人类在系统中定位和浏览代码的难度，还能引导 Agent 获取所需的上下文。具体来说，当重构能让人更容易判断变更究竟应该发生在哪里时，它才真正有帮助。

这会如何改变日常工作

将巨型文件视为一种信号。不是因为某条关于文件大小的审美规则，而是因为它们会迫使 Agent 读取大量无关上下文。

在委派一系列变更之前先进行重构。如果相关区域后续还会持续迭代，那么前期成本很可能得到补偿。

衡量一种反复出现的变更。选择一项具有代表性的任务，对比重构前后的 token、耗时和读取的文件数量。

不要指望 Agent 具备架构层面的自主能力。在这份案例中，无论是选择重构方案，还是实际实施多项重构，Agent 都需要人类提供指导。

这一结论存在局限

这只是一次单独的实验，所涉及的应用仍处于 greenfield 阶段，并且由一个人维护。由于工具无法提供可靠的实时测量，token 数量也是根据字符数估算得出的。此外，重构本身的总成本并未被单独统计：作者只是估计，全部规划与执行工作消耗的 token 上限为 500 万。

即便存在这些限制，这项实验仍提出了一个具体论点：在 AI 辅助开发中，优秀的重构不仅是对未来可维护性的一次押注。它可能从下一项任务开始，就减少 Agent 为高质量完成工作而必须加载的上下文。

来源：改编并评论自 Giles Edwards-Alexander 的《The Economic Benefit of Refactoring》，该文于 2026 年 7 月 30 日发表于 MartinFowler.com。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。