AI 智能体与从未发生的重构

# AI 智能体与从未发生的重构 来源：https://www.rosenfeld.page/articles/programming/2026_09_02_ai_agents_and_the_refactoring_that_never_happens/ 2026年9月2日 中午12:00 每天与 AI 智能体合作，我开始注意到一个令人担忧的趋势。团队——包括曾经更懂行的经验丰富的工程师——已经悄然停止推动对系统中最棘手部分进行重写或重构。问题不在于智能体生成的代码质量。而在于一个过去几乎本能发生、如今却很少再出现的决策：停下来指出*这已变得难以管理，我们需要在继续推进之前进行重构*。 ## 人类的上下文容量有限，这塑造了我们的软件构建方式 计算机在“工作记忆”中能容纳的内容远超人类。当复杂系统向数十个方向分支，每个分支都有其自身含义，且彼此互联时，我们无法对其进行推理。我们根本无法一次性在脑海中处理这么多信息。 因此，历史上我们唯一能做的就是：将系统分解成足够小的、可以独立理解的模块，然后我们花费精力将这些模块通过同样能够理解的接口连接起来。模块化、封装、分层——这些并非审美偏好，而是对人类工作记忆容量的妥协。我们分解系统，直到每个部分都能装入一个人的脑海，因为这是一个人能够对其进行推理、安全修改并审查他人更改的唯一方式。 ## 重构本能 系统很少从一开始就令人困惑。一段代码在需求仍然简单时编写，起初读起来很清晰。然后需求发生变化。开发者为新情况增加一个分支，接着为异常再加一个，然后在这个异常之上再加一个特殊情况。经过足够多的迭代，代码最初表达的“规则”就被异常淹没了——有时需求变化如此之大，以至于代码现在*只剩下*异常，完全没有清晰的规则了。 每个经验丰富的开发者都认得这样一个时刻：你在调试一个问题，你追踪代码，然后你迷失了。分支不再构成你能在脑海中把握的图景。历史上，这种感觉是一个*信号*。一位高级工程师在系统某部分迷失方向时，会暂停并说：这已变得难以管理——在我添加任何东西之前，我需要重写或重构这部分，使其重新变得可理解。不是为了优雅，而是为了让他自己以及之后的任何人都能对其进行推理，并安全地审查未来的更改。 这种本能——“我迷失了，因此是时候重构了”——悄然成为保持长期可维护系统的最重要力量之一。它是由人类的局限性触发的：即一个人再也无法跟上代码的那个时刻。 公平地说，这种本能在 AI 智能体出现之前就已经承受压力了。截止日期、路线图以及经理们问“你为什么重写一个能用的东西？”一直与之对抗，而重构通常是最先被降低优先级的事情。多年来，当系统变得难以管理时，高级工程师们已经不再像过去那样大力抵制了。智能体并非创造了这种弱点。它们所做的，是移除了最后一个尽管存在这种弱点却仍会触发的内部触发器——人类迷失方向的切身体验。 ## AI 智能体不会迷失 问题在于。AI 智能体并非以同样的方式受制于人类的上下文限制。一个智能体可以阅读那个纠缠不清的函数，追踪每一个调用者，并理解那个会让人类彻底止步的混乱。它可以正确地添加下一个分支，以及之后的分支，在团队中没有人能完全理解的代码里自信地工作。 这听起来像一个优势，短期内确实如此。但请注意缺失了什么：智能体从未迷失，所以信号从未触发。智能体没有一种本能说“这已变得难以管理，我们应该停下来重构”。它只是不断地向堆里添加分支。除非通过其运行环境、提示词或明确的审查标准专门指示它后退一步并质疑结构，否则它会愉快地无限期地维持一个混乱，因为这种混乱*对智能体来说*不是问题。 ## 真正的风险：人类停止监管代码 失败模式不在于智能体编写了糟糕的代码。而在于自然的检查点消失了，人类开始不再注意到代码已经偏离到他们无法理解的程度。随着时间的推移，你会到达这样一个系统： - 团队中没有开发者能完全推理代码的关键部分。 - 审查变成了盖橡皮图章，因为审查者实际上无法很好地跟上变更以做出判断。 - 团队越来越*信任智能体*，恰恰是因为他们自己不再理解代码——而这与信任应有的运作方式完全相反。 在那时，你已经失去了一些重要的东西：无需作为中介的智能体就能推理自己系统的能力。并且你是逐渐失去它的，没有任何一个令人警觉的单一时刻，因为那个曾经引发警报的时刻——人类迷失方向——已被悄然从循环中移除。 ## 整洁的代码对智能体来说成本也更低 很容易将这一切框定为纯粹的原则性问题——我们*理应*理解我们自己的系统——并就此为止。但有一个务实、精打细算的理由来保持代码的组织性，即使你完全乐于让智能体完成工作，这个理由依然成立。 一个从不迷失的智能体仍然要为混乱付出代价。一段代码越纠缠、互联越多，智能体为了正确修改所需加载和保持的上下文就越多：需要读更多文件，追踪更多分支，在每次编辑上消耗更多 token。由易于推理的小型、自包含模块构建的系统不仅对人类更友好——它的运营成本也更低，因为每一次未来的变更让智能体理解起来成本更低。 这还不仅仅是成本问题。当相关逻辑无法放入一个有界、连贯的切片时，智能体更可能失去线索并产生幻觉——假设一个分支做了它实际没做的事，或者遗漏埋在三层深处的异常。保持系统在人类脑海中的那种模块化，同样也将每一次变更保留在智能体能够可靠推理的明确边界内。清晰的边界以同样的原因减少了双方的错误。 因此，保持源码井然有序并非我们牺牲智能体利益为人类做的好事。它惠及人类，它提高智能体的准确性，它降低了我们将来对该代码进行每次修改的 token 成本。我们面临风险失去的那种重构本能，从来都不仅仅关乎人类的舒适——事实证明，它在经济上也是划算的。 ## 自我监管 我认为答案不是束缚智能体。答案在于我们有意地带回那个检查点，因为它不再自然发生。我们必须持续提出智能体不会问的问题： - 我是否仍然理解这部分系统，还是我一直让智能体*代替*我理解它？ - 如果一个人必须在没有智能体的情况下调试这个，他们能跟上吗？ - 需求是否已经漂移得太远，以至于这段代码现在全是异常而没有规则——这是需要重写的典型信号吗？ - 现在是否是暂停功能开发、将这段代码重构为一个人能再次在脑海中把握的东西的时刻？ 你也可以将部分责任推给运行环境——指示你的智能体在模块增长到超出合理的尺寸或分支复杂度时进行标记，不仅提议扩展，还要提议重构，并在变更变得难以推理时明确指出。这有帮助。但最终责任仍在我们身上，因为我们需要能够理解我们的系统，而如果我们不加注意，我们正是会失去这种能力的那群人。 一个从不迷失的智能体的便利性是真实的。但“智能体仍然能理解它”并不等同于“系统是健康的”。前者关乎智能体的能力；后者关乎我们的能力。不断问自己是否到了重构的时候——因为那个曾经通过迷失来提醒你的工具，现在不再迷失了。