审查变贵，重写变廉：AI 代码生成时代的经济学重构

背景

随着大型语言模型（LLMs）在软件开发中的渗透率日益提高，开发者与 AI 的协作模式正在发生微妙但深刻的变化。传统观念中，人们常误以为 LLMs “懒惰”或倾向于走捷径，但事实恰恰相反。当模型具备解决某个问题的完整知识时，它倾向于提供详尽的实现方案，而非引用现成的库或采用更简洁的路径。

这种“过度工程化”的倾向导致了一个新的工作流困境：AI 生成的代码虽然在技术上是正确的，但往往过于复杂。这迫使开发者在代码审查（Code Review）阶段投入大量精力去评估、争论或接受这些不必要的复杂性。与此同时，利用 AI 进行代码简化或重构的成本却大幅下降。这种“审查昂贵、重写廉价”的经济学转变，正在重塑开发者的工作负载分配和决策逻辑。

核心内容

大型语言模型（LLMs）并非懒惰，也不会因为简单的解决方案看起来“足够好”就偷工减料。如果模型知道如何彻底解决一个问题，它就会提供彻底的解决方案。

LLMs 默认倾向于“自建”而非“购买”（即倾向于从头编写代码而非调用现有库）。这并非因为模型不知道现有的库——事实上，它经常提及它们——而是因为对于 LLM 而言，编写两百行实现代码的认知努力，与编写两行 import 语句的认知努力是相同的。模型缺乏一种本能去选择最短路径；对模型来说，最短的路径就是完整地实现它。

这种特性使得审查 AI 生成的代码变得昂贵。开发者阅读的代码在技术上虽然正确，但往往过度设计。开发者必须决定是否接受这种复杂性，或者提出反对意见。做出这一决定需要时间，在审查评论中阐述理由也需要时间。由于这种情况反复出现，开发者不得不进行重复的对话和争论。

另一方面，重写代码现在变得廉价。如果开发者（无论是在自己的工作中还是在别人的 PR 中）发现代码比必要的更复杂，他们可以直接要求 AI 进行简化、使用库、或者砍掉尚未需要的功能。重写的周转速度通常更快。创造问题的模型，也是解决问题最快的方式。

经济学逻辑已经改变：审查现在是昂贵的步骤，而重写则不是。

作者的工作负载因此发生了重组。现在，作者在前期规划上花费更多时间，决定哪些功能应该存在、使用哪些库、以及真正的范围是什么，因为这是在设计阶段阻止复杂性产生的最佳时机。随后，作者进行实施，部署到测试环境，查看现有代码，识别出哪些部分不需要存在，或者可以将一百行代码缩减为十行。最后，作者执行重写。

如果审查过程中发现某些部分过于复杂，稍后重写它不再像过去那样被视为“沉没成本”。这改变了作者提出反对意见的激进程度。标记问题并迭代的成本降低了，而让问题通过的成本保持不变。

关键要点

• LLMs 的认知偏差：LLMs 没有“偷懒”或寻找最短路径的本能。编写完整实现的认知成本与调用库的认知成本相同，因此模型倾向于提供详尽但可能过度复杂的代码。
• 审查成本上升：由于 AI 生成的代码往往过度工程化，开发者需要在审查阶段花费大量时间评估复杂性、进行争论或决定接受与否，导致审查过程变得昂贵且重复。
• 重写成本下降：利用同一模型进行代码简化、重构或移除冗余功能变得非常快速且低成本。创造问题的工具也是修复问题最快的工具。
• 工作流前置：开发者应将更多精力投入到前期的规划和范围界定中，从源头遏制复杂性的产生，而不是在代码生成后试图修补。
• 决策逻辑转变：由于重写的边际成本极低，开发者在代码审查中可以更激进地提出反对意见。标记问题并迭代的重置成本低于过去，使得“先通过再优化”的策略在经济上变得可行。

意义与影响

这一现象标志着软件工程实践从“预防错误”向“容忍并快速修正”的范式转移。

1. 代码审查角色的重新定义：传统的代码审查侧重于发现逻辑错误和风格问题，而在 AI 辅助编程时代，审查的重点转向了架构决策、范围控制以及对“过度工程”的识别。审查者不仅是质量的守门员，更是复杂性的过滤器。
2. 敏捷性的提升：当重写变得廉价时，开发团队可以更快速地迭代。如果某个实现方案过于复杂，团队不必陷入漫长的重构讨论，可以直接生成新版本。这种低摩擦的迭代循环可能加速产品的开发周期。
3. 对“最佳实践”的挑战：传统编程强调 DRY（Don't Repeat Yourself）和 KISS（Keep It Simple, Stupid）原则，但在 AI 生成代码的场景下，这些原则的执行责任从“编写时”转移到了“审查后”。开发者可能需要接受“先写出复杂代码，再快速简化”的新常态。
4. 技能需求的演变：开发者需要更强的前期架构设计能力和范围界定能力，以在代码生成前确立边界。同时，熟练运用 LLM 进行迭代式重构将成为一项核心技能，而非仅仅是辅助技能。

总之，AI 并没有让编程变得更容易，而是改变了编程的经济结构。开发者必须适应这种“审查贵、重写廉”的新现实，通过前置规划和快速迭代来管理由此产生的复杂性。