AI 生成代码的维护陷阱：团队在六个月后才发现的真相
这种规律在 2023 年和 2024 年采用编程智能体的团队中几乎普遍存在。第一个月，效率翻倍。第三个月，管理层把生产力指标拿出来，作为 AI 投资回报的证据。到了第十二个月，工程团队有一半的代码库已无法向新员工解释清楚，重构成本高得令人望而却步，工程师花在调试 AI 生成代码上的时间，比他们手写这些代码所需的时间还要多。
这不是一个关于 AI 代码暗中存在缺陷的故事。这是一个关于 AI 生成代码的质量特征如何系统性地瓦解团队已有的组织实践的故事——以及这些实践在技术债务复利失控之前需要如何改变。
令人迷惑的质量特征
AI 生成的代码有一种独特的质量签名，能够欺骗大多数代码审查流程。在函数层面，代码看起来非常出色：格式整洁、命名一致、结构清晰。审查者扫一眼某个方法或类， 会得出"这是扎实的工作"的结论。
问题出现在模块和系统层面。AI 智能体的上下文窗口有限，对三次会话前做出的架构决策也没有持久记忆。当代码库中已经有一个使用某种模式的 UserRepository，而智能体开始新的会话时，它可能会生成一个使用不同模式的 UserStore——因为它不知道第一个的存在。经过数十次这样的会话，你会积累出针对相同问题的并行解决方案、不一致的抽象层，以及命名约定因文件生成时间而异、而非源于任何连贯设计的混乱局面。
GitClear 对 AI 辅助代码库的纵向分析发现，代码重复率比 AI 出现前的基准高出四倍。卡内基梅隆大学追踪 807 个使用 Cursor 的代码库的研究发现，尽管初期效率有所提升，代码复杂度平均增加了 25%。AI 生成的 PR 中，格式不一致的情况出现频率是人工代码的 2.66 倍；命名不一致的情况出现频率几乎是人工代码的两倍。
简而言之：AI 代码实现了高局部连贯性和低全局一致性。这与代码审查本来要捕捉的失败模式恰恰相反。
代码审查如何沦为橡皮图章
传统代码审查是为一个 PR 以审查者能够处理的速度到来的世界而设计的。审查者可以在脑海中保留作者的推理过程，探究边界情况，并对架构决策提出异议——因为他们有足够的认知空间来做到这些。
当团队中的每个开发者都在使用 AI 智能体生成代码时，这个模型就崩溃了。PR 数量急剧增加。每个单独的 PR 看起来都比手写代码更整洁、更有把握——AI 没 有状态不好的时候，不会产生马虎的格式，也不会犯那些会触发审查者怀疑的明显错误。在数量压力下，审查者从架构层面的审查转向只检查代码格式是否正确、测试是否通过。
两件事同时发生。首先，那些能捕捉到意图失误的审查（"为什么这里要用三个独立的数据库查询，而一个连接查询就够了？"）不再发生，因为审查者没有时间处理。其次，审查者内化了一个更低的标准——代码看起来没问题，CI 通过了，发布吧——他们即使在有时间深入审查时也会沿用这个标准。
一项调查发现，59% 的开发者报告说他们使用了自己并不完全理解的 AI 生成代码。如果作者都是如此，在时间压力下的审查者更是如此。
死代码积累问题
人类工程师对自己编写的代码有一种所有权感。当某个功能被废弃或某个工具函数不再需要时，存在一种社会压力——以及个人记忆——来清理它。作者知道它的存在，知道它是用来做什么的，并且对它的命运感到负责。
AI 生成的代码在这个意义上没有作者。当智能体生成一个最终用不上的辅助函数时，没有人会标记它待删除。静态分析警告不断积累。未使用的导入继续保留。整个工具类处于休眠状态，因为能够移除它们的重构永远不会发生。
一项对大量 AI 辅助开发代码库的研究发现，12 个月内静态分析警告增加了 18%，认知复杂度增加了 39%。代码重构——定义为移动或重构的代码行，而非新增的代码行——在 AI 辅助项目中从 2021 年占变更代码的 25% 下降到 2024 年的不足 10%。二十年来复制粘贴操作首次超过了移动操作。
代码库的增长速度超过了其被修剪的速度。每一次新的 AI 会话都在不断扩大的死代码和不一致的基础上叠加新代码。
入职危机
当一名新工程师加入一个已经使用 AI 智能体生成代码一年的团队时，他们面对的代码库有一个特殊属性：它没有连贯的"声音"。不同部分对相同问题使用不同的模式。有些抽象是高度面向对象的，另一些是函数式的，还有一些是过程式的。架构不是设计出来的——它是从数百次独立的 AI 会话中涌现出来的，每次会话内部连贯，但在全局上不一致。
对于一个试图建立系统工作原理心智模型的新工程师来说，根本无处着力。他们无法读一个模块然后推断其设计理念，因为根本没有统一的设计理念。他们也无法询问作者为什么选择某种方法，因为作者是一个 AI，那次会话的上下文早已不复存在。有经验的工程师用于在新代码库中快速定位的模式识别，在模式相互矛盾时完全失效。
实际结果是，在大量使用 AI 辅助的代码库中，入职时间不降反升——与团队从绿地起步测量效率提升时的预期恰恰相反。
复利式恶化轨迹
维护陷阱以几个阶段展开，现在已经可以相当精确地描述：
第 1-3 个月：效率显著提升。工程师更快地生成更多代码。PR 吞吐量增加。代码库快速增长。管理层为生 产力指标欢欣鼓舞。
第 4-6 个月：代码审查沦为橡皮图章。死代码悄然积累。不同会话中编写的模块呈现出不一致的模式。新工程师开始抱怨代码库难以导航。
第 6-12 个月：重构尝试失败，因为没有人理解需要改变的完整范围。调试时间增加。构建失败变得更频繁。效率提升趋于平稳，然后开始下降，因为工程师花在绕过已积累债务上的时间超过了交付功能的时间。
第 12-18 个月：维护成本已增长到可比传统代码库的四倍。团队发现自己无法有把握地交付功能，因为他们无法推断一次变更的影响范围。本应加速开发的系统已成为其自身的障碍。
这种轨迹并非不可避免——但避免它需要对团队采用 AI 智能体的方式进行结构性改变，而大多数团队直到已经深陷债务才会做出这些改变。
三种真正有效的实践
1. 在生成时捕获意图
当 AI 智能体生成代码时，其选择背后的推理——为什么是这个抽象、为什么是这个数据结构、为什么是这个边界——只存在于会话上下文中。会话结束时，推理消失。代码留了下来，但"为什么"不见了。
在生成时捕获意图的实践原则上很简单：在你接受 AI 生成的代码之前，记录它试图做什么以及什么约束塑造了实现。这不意 味着写一本小说——一个解释非显而易见设计选择的两句话注释，就足以防止未来的工程师（和未来的 AI 会话）无意中覆盖一个有意为之的决策。
研究人员已提出将此正式化为"变更意图记录"——在生成时创建的结构化文档，捕获目标、约束、边界和假设。关键洞察是：意图是持久的产物；代码是派生的。当意图丢失时，即使代码继续运行，它也变得更难维护。
2. 为 AI 的失败模式重新设计代码审查
针对 AI 生成代码的代码审查需要检查与针对人工生成代码审查不同的事项。低级别的样式和语法问题最好委托给自动化工具——linter、格式化器、静态分析器。人工审查应聚焦于 AI 系统性不擅长的架构性问题：
- 这个新增部分是否遵循了相邻模块中已有的模式？
- 这个抽象真的有必要吗，还是智能体把一个简单问题过度设计了？
- 代码库中是否已经存在做同样事情但名称不同的东西？
- 六个月后的新工程师能否理解为什么选择了这种方法？
PR 大小上限尤为重要，因为 AI 生成的代码倾向于扩张蔓延。超过 500 行的任何内容都接近架构审查变得不切实际的阈值；超过 1000 行的内容，无论审查者花多少时间，实际上都处于未被审查的状态。
风险分级审查架构有助于将审查精力分配到最重要的地方：安全关键和数据敏感代码获得深度人工审查；外围代码获得自动化门控加轻量级人工签 署。大多数团队犯的错误是对所有代码应用统一的审查深度，这在低风险变更上造成了疲劳，而使高风险变更审查不足。
3. 用工具而非善意强制执行架构一致性
期望个别开发者在 AI 会话之间保持架构一致性是不现实的。上下文窗口有限；开发者承受时间压力；AI 不知道在它未参与的会话中建立了什么约定。一致性需要由工具来强制执行。
这意味着要超越样式 linter 的范畴。它意味着将架构决策——命名约定、抽象模式、模块边界——编码为在违反时会导致构建失败的显式规则。它意味着要求新模块与做类似事情的现有模块列表进行核对，迫使工程师有意识地决定是扩展现有抽象还是引入新的抽象。它意味着在 CI 中追踪死代码指标，当未使用的代码积累超过阈值时使构建失败。
目标是将通常存在于高级工程师脑海中的架构决策编码为机器可检查的规则。在 AI 出现之前的代码库中，这些决策通过结对编程、代码审查和共享上下文来传播。在 AI 辅助的代码库中，这种传播机制崩溃了——工具必须填补这个空缺。
所有权问题
这一切之下还有一个更深层的问题：AI 生成的代码在传统意义上没有所有者。没有工程师做出产生它的判断，没有工程师为维护它感到自豪，没有工程师在它失败时面临问责。
成功应对维护陷阱的团队往往会明确分配所有权。不是 AI，不是整个团队——特定的工程师拥有特定的模块，包括那些主要由 AI 智能体生成的模块。这种所有权意味着他们负责理解代码、维护代码，并确保代码与系统其余部分保持一致。
这听起来显而易见，但它需要文化上的转变。AI 智能体让个别工程师更快的叙事，往往会遮蔽"谁拥有智能体所产出之物"这个问题。当每个人都认为是 AI "写"了某些东西时，就没有人感到有责任知道它是如何运作的。
大多数工程组织对 AI 采用的 12 个月事后回顾揭示：效率提升是真实的——但它们是从未来的维护能力中借来的。那些走在债务前面的团队，是那些将 AI 生成的代码视为需要被拥有和维护的草稿、而非可以交付的成品的团队。那些没有这样做的团队，至今仍在偿还这笔债。
AI 编程智能体不会消失，它们带来的生产力提升也不会消失。但在不造成 18 个月后维护危机的情况下提取这种提升的组织实践，与当前规范的差异已足够大，以至于大多数团队只有在付出代价之后才会发现它们。陷阱不在代码里——它在于假设适用于人工生成代码的方法同样适用于 AI 生成的代码。
