对 AI 生成代码“惰性依赖”的警惕与治理

Brief

对 AI 编程助手和代理（agents）的研究和实践逐渐暴露出一个结构性问题：随着使用时间增加，代码质量容易因为“惰性依赖”（complacency）而下滑。

• 实证信号：
  • GitClear 2024 研究发现，重复代码和代码 churn 的增长超出预期，而提交历史中的重构活动在减少。
  • 微软针对知识工作者的研究表明：AI 帮助带来的“信心提升”，往往以“批判性思考能力下降”为代价；在长期使用编程助手后，这种惰性思考会明显加剧。
• 机制上：
  • AI 代理可以一次性生成更大规模的改动集（large change sets），人工 review 成本和难度上升，问题更难被及时发现。
  • 加速了“写代码”这一步，就隐性地对“审查、测试、重构”等后续环节施加压力，如果不做制度化补偿，整体质量会被侵蚀。
• 应对建议（来自原文）：
  • 在生产环境中有效使用 AI，需要重新强化代码质量意识和实践。
  • 尤其是将 TDD、静态分析等既有工程实践重新嵌入到编码工作流中，例如通过针对软件团队的“共享指令集”（curated shared instructions）来固化这些约束与规范。

来源：技术雷达

Details

一、背景与现状：从“提效工具”到“系统性质量压力”

1.1 技术与业务场景：AI 编程从辅助走向代理

• 典型使用场景：
  • 日常编码中使用 Copilot 类助手补全和生成函数、测试。
  • 通过自然语言需求驱动 agent 生成多个文件、跨模块改动。
  • 在原型开发、绿地项目中，用 AI 快速跑通端到端 demo。
• 背景趋势：
  • 早期共识是“AI 编码主要是提效工具”，风险更多被视为局部的、可控的。
  • 随着 AI 的覆盖范围从“补全几行代码”扩展到“生成大规模改动集”，其对整体工程系统的影响被显著放大。

这也意味着：对 AI 的评估不能只看“开发速度”，需要把“演进后的代码库形态”和“团队认知习惯的改变”也纳入考量。

1.2 研究发现：效率收益与质量退化并存

• GitClear 2024：
  • 观察到**重复代码（duplication）和代码 churn（短期内频繁增删改的代码）**显著上升。
  • 与此对照，重构类提交占比下降，说明许多“第一次写得差不多就算了”的代码，没有被系统性打磨。
• 微软对知识工作者的研究：
  • AI 使得个体在完成任务时**“自我感知的信心”上升**。
  • 但在可测量的指标上，批判性审查和深度思考的投入反而减少。
  • 长期使用编程助手后，团队中这种“有答案就不再往下问”的惰性模式会更明显。

对技术负责人来说，这些信号指向的是：AI 的“提效收益”会与“认知松懈”叠加，最终体现在存量代码质量的慢性恶化上。

二、问题与风险：惰性依赖的技术与组织后果

2.1 代码层面的结构性退化

在广泛使用 AI 编码助手/代理的团队中，常见的风险模式包括：

• 重复与散乱：
  • AI 为了“就近满足上下文需求”，倾向于复制相似逻辑，而不是抽象复用。
  • 结果是：功能上线更快，但后续修 bug / 改需求时维护成本急剧上升。
• 短期 churn 增加：
  • 开发者更容易“先让它写一版再说”，产生大量低质量试验性代码。
  • 如果缺乏严格的 review / 清理机制，这些“实验产物”往往残留在主干代码库。
• 重构意愿降低：
  • 由于“复制修一份就能过需求”，团队对“抽象、整合、简化”的内在动力被稀释。
  • 体现在数据上，就是重构型提交在整个提交历史中的占比下降。

这些现象并不是 AI 独有，而是人类长期就存在的问题被放大加速。

2.2 认知与流程层面的惰性

• 过度信任模型输出：
  • “AI 写的看起来没问题”常常替代了“我真的理解了代码意图和边界”。
  • 评审被动化：review 流于查风格、改命名，而不是深度审查领域逻辑。
• 拆解问题的能力退化：
  • 在“提示-生成-接受”的循环中，工程师容易跳过需求澄清、边界定义、建模等关键思考步骤。
  • 长期来看，团队的“架构思维密度”和“问题分解能力”都会受损。
• 流程瓶颈挤压：
  • 写代码明显加速后，测试、review、上线评估成为新的瓶颈。
  • 如果组织不主动“抬升”这些环节的工程能力，就会自发削弱它们的标准，以适配更快的提交节奏。

三、模式与原理：从“快写”到“系统配平”

3.1 速度—质量—认知负载的再平衡

可以把 AI 编码工具视为在“实现代码”环节上强行压缩了周期：

• 过去：
  • 需求澄清 → 设计 → 手写代码 → 手写测试 → review & 重构
• 现在（AI 辅助）：
  • 需求描述 → prompt → 一次生成大量代码 + 测试样例 → 轻量 review → merge

如果其他环节不做调整，典型后果包括：

• 代码审查阶段：diff 过大，reviewer 很难逐行理解和验证。
• 测试阶段：测试覆盖和质量“被动接受”模型输出，而非由工程师主动设计。
• 演进阶段：缺少重构和演化设计，代码库像“地层沉积”一样堆积。

因此，引入 AI 的前提不是“让工程实践变轻”，而是“重新设计如何让实践在新的速度条件下依然有效”。

3.2 Coding agents 带来的“巨大变更集”问题

相对普通助手，coding agent 的突出特点是：

• 生成多文件、多模块的改动；
• 改动之间经常存在跨边界依赖；
• 本质上更接近“自动化执行一个小型重构或特性开发”。

这直接导致：

• Review 复杂度从“函数级”上升到“模块/系统级”；
• 线上回滚与故障定位难度增加——一次错误可能影响更多路径；
• 对 CI/CD 与回归测试体系提出更高要求，否则就只能靠“运气上线”。

四、对比与演进：AI 工具前后的工程形态

4.1 传统高质量工程实践 vs AI 加持下的新挑战

传统上，维持代码库长寿的关键手段包括：

• TDD / 测试先行：先定行为边界，再写实现；
• 持续重构：在功能迭代中不断整理抽象边界；
• 静态分析与规范：对常见错误和风格问题做自动化约束；
• 小步提交与可审查变更集。

引入 AI 后，如果不做任何治理，常出现如下反差：

• TDD 弱化： “AI 代码已可运行”被当作“行为已可靠”的替代。
• 重构滞后：工程师更习惯“再复制一段新代码满足当前需求”。
• 静态分析形同虚设：规则不更新、不针对 AI 生成模式做加强（例如检测重复逻辑、copy-paste 风险）。
• 提交粒度变大：agent 一次性生成大变更集，破坏“小步可回滚”原则。

4.2 可能的演进方向

为了让 AI 真正服务于长期可维护性，可以考虑这样的演进路径：

• 将 AI 纳入“质量工具链”：
  • 不是“人在上、AI 在下”，而是把 AI 作为执行规范与检查的自动化手段之一。
• 让 AI 也参与重构和测试改进：
  • 引导 AI 生成 refactoring plan、测试增强方案，而非只用来“生成新功能代码”。
• 从“代码级助手”升级为“工程级守门人”：
  • 用共享指令固定质量红线（见下文），让 AI 在生成时自带审查意识。

五、系统影响：对架构、工程效率与协作的牵引

5.1 对架构与代码库形态的影响

如果不加约束，AI 辅助编码往往会导致：

• 领域边界模糊：AI 只关心“把当前需求拼起来能跑”，不关心是否破坏既有领域划分。
• 接口与模型扩张：为了兼容临时诉求不断往对象、DTO、API 里加字段，缺少“收敛与精简”。
• 技术债表面隐蔽：
  • 从静态看，代码能编译、能跑测试；
  • 从动态看，复杂度和耦合在缓慢积累，几年后演进阻力巨大。

5.2 对工程效率与质量文化的拉扯

• 短期效率观：
  • 团队容易只看“功能交付速度”，忽略“未来一年维护投入”。
• 质量文化淡化：
  • 如果管理层只追求“AI 提效指标”，工程师自然会在质量标准上“向下对齐”。
• 知识沉淀路径变化：
  • 原本通过手写和重构沉淀的“隐性知识”，被部分转移到“提示语”和“过往生成代码”中。
  • 如果缺乏规范的共享指令与知识库建设，这些知识很难被团队系统地复用。

六、落地建议：在生产中“负责任地用 AI”

6.1 强化并嵌入既有实践：TDD 与静态分析

原文明确提出：在生产环境中有效使用 AI，需要重新强化代码质量实践，尤其是 TDD 和静态分析，并把它们嵌入到开发流中。

一个可操作的落地思路是：

• 对 TDD 的强化：
  • 明确要求“AI 生成代码前先定义测试”，或者让 AI 先生成测试 skeleton，再填实现。
  • 在 review checklist 中加入“测试先行/测试充分性”项，而不仅是“代码可读性”。
• 对静态分析的升级：
  • 针对 AI 生成特点增加规则，例如： - 重复逻辑检测； - 可疑大函数/大类的警报； - magic number / 无注释复杂逻辑的提示。
  • 将静态分析结果纳入 CI 阶段的“硬门槛”，而不是可选提示。

6.2 利用“共享指令”把规范写进工作流

原文提到的一个关键建议是：通过精心策划的“共享指令集”（curated shared instructions）直接嵌入团队的编码工作流。这在实践中可以演化为：

• 团队级系统提示（system / team prompt）：
  • 固定质量原则：如“禁止复制粘贴大段代码”、“需要解释复杂逻辑意图”等。
  • 约束生成范围：例如“严禁改动超出当前模块边界的代码”。
• 场景化模板：
  • 不同任务类型（bug 修复 / 新功能 / 重构 / 跨模块变更）对应不同的提示模板和 review checklist。
• 持续演化机制：
  • 将线上事故、review 发现的问题沉淀为新指令，不断迭代团队共享 prompt。

这样做的目标是：把“经验性规范”变成“系统性约束”，并让 AI 自身也遵守这些约束。

6.3 控制变更粒度与审查策略

对于 coding agents 特别需要注意：

• 限制单次变更范围：
  • 在提示中明确“一个任务只改一个有界上下文/子系统”，减少超大 diff。
• 强化自动化保护网：
  • 为 agent 生成的改动配置更严格的测试门槛和预发布验证流程。
• 采用分阶段 rollout：
  • 对高风险变更采用灰度发布、分流验证，并要求 agent 输出“变更点清单”和“潜在影响区域”。

6.4 识别不适用场景与风险边界

在以下场景中，应更加谨慎使用 AI 直接生成或大规模修改代码：

• 高安全/高合规要求系统（金融、隐私敏感业务等）；
• 对领域建模要求极高、规则复杂且多变的核心域；
• 现有代码库已高度耦合，缺乏测试与观测基础，无法有效回归与监控。

对于这些场景，更合理的策略通常是：

• 优先用 AI 做辅助分析、重构建议、测试生成，而非直接放权给 agent 做大规模改动；
• 先补齐测试和监控能力，再逐步扩大 AI 参与范围。

综合来看，原文的核心立场并不是“反对 AI 编程”，而是明确提醒：AI 提速的是“编码”这一局部环节，但代价是在系统层面增加了质量管理的复杂度和认知风险。要在生产中有效使用这类工具，技术负责人需要把 TDD、静态分析、review 规范等实践重新“嵌入工作流”，并通过共享指令和流程设计，把团队的质量文化编码进 AI 使用方式，而不是寄希望于“更聪明的模型自动抵消这些风险”。