AI 生成代码的能力越强，它带来的“隐性技术债”也越明显。我们常常能看到分层完美、注释齐全的交付物，但这背后可能隐藏着只有一个实现的接口、无人回收的调试代码以及未被覆盖的逻辑分支。本文总结了 AI 辅助编码时的七大常见失效场景，并提供了从“强约束”到“弱纪律”的分层治理方案。


核心前提：为什么传统规范在 AI 面前失效？

项目规范（Conventions）需要开发者主动遵守和检查，但在赶工或发版时，这往往是最先被忽略的环节。真正能拦住问题的是**“会失败的闸门”（Failing Gates）**——比如不通过就无法合并代码的 CI 流水线，它不依赖任何人的主观意愿。

在深入具体措施前，需明确我们的适用场景：

  • 资产类客户端：业务实体多、差异细微。
  • 高频迭代：没有专门的重构窗口。
  • 高容错成本：线上错误代价巨大。
  • AI 参与度高：单周代码改动量可能超过人工审阅上限。

当单位时间内的改动量远超人工阅读容量时，“依赖 review”就不再是可靠的防线。


七大失效场景与对策

AI 的失效模式可归结为三类：做多（过度设计）、看少（视野局限）、不收尾（缺乏持续上下文）。

一、它会“做多”：过度设计与无意义的抽象

AI 没有维护成本的概念，因此它倾向于生成更“稳健”、更“通用”的代码，哪怕这在当前语境下是冗余的。

1. 无必要的抽象层

  • 现象：生成只有一个实现的接口或基类。
  • 对策：任何新增抽象层必须回答“当前有几个实现”。

2. 把规范当成油门

  • 现象：“新增 feature 按 domain/data 分层”这句指令，AI 会执行得毫无节制。
  • 对策：规范不仅要写“怎么做”，必须写清楚“什么时候不该做”。

3. 用产出量证明勤奋

  • 现象：交付包含大量空目录、空文件或只有一行 Export 的 Barrel 文件。
  • 对策：交付前自查，每个新增文件都要能说出“现在就有用”，说不出就删。空目录一律不预建。

二、它会“看少”：视野局限与上下文缺失

AI 每次会话都从零开始，它的视野完全由你的 Prompt 和检索范围决定。

4. 把归档当成现状

  • 现象：检索到三个月前废弃的文档，并基于过时方案生成代码。
  • 对策：

5. 只看见给定的文件

  • 现象：在一个文件中修复了逻辑，忘了在另外五个文件中同步修改。
  • 对策：进行符号迁移（重命名/删除）时，检索范围必须覆盖测试目录（不只是 lib 或 src）。

三、它“不收尾”：缺乏持续的责任边界

AI 的任务边界仅限于当前对话，它不会记得清理留下的“烂摊子”。

6. 顺手改了无关逻辑

  • 现象：重构时顺手优化了附近的代码，导致“名义上的重构”变成了“隐性的行为变更”。
  • 对策：在修改处显式声明**“与旧逻辑严格等价”**，并强制把旧逻辑原封不动地抄下来。

抄写的动作本身就是一种自检，迫使你逐行核对变更。

7. 忘记回收调试出口

  • 现象：日志开关、调试路由或抓包工具被留在正式版本中。
  • 对策：
  • 增加阻断性校验：在打包脚本中检查上述两层保险是否依然存在，若被移除则中止打包。


分层治理策略

上述对策按约束力可分为三层，治理顺序应从下往上推导：


层级生效机制适用场景举例
第一层：强制闸门编译期错误 / 打包失败安全、稳定性红线调试代码剥离校验
第二层：机检工具Lint / CLI 脚本报错可自动修复的规范问题裸色值检测、分层检查
第三层：纪律约束代码评审 / 文档约定需要主观判断的场景新增文件合理性、等价性声明

第二层机检工具的设计原则

针对可机检的问题，需建立分级处理机制：

  • 绿色（可自动修复）：由工具直接修改（如：强制使用 Token 替换裸色值）。
  • 黄色（需人工决策）：提供多个选项供开发者选择（如：选择合适的语义化图标）。
  • 红色（报告但不修改）：仅标记位置，严禁自动重构（如：绕过网络层的直连调用）。

关键设计：工具只扫描本次 Diff 的新增行，不追溯历史债务，避免“吹毛求疵”导致团队反感。


结语：AI 的边界在哪里？

即使是最严密的闸门，也无法拦截领域语义错误（Domain Semantics Bug）。例如，将业务上代表“未知”的 null 误判为“空值 0”，这在代码规范上毫无破绽，只能靠真机回归和业务知识来发现。

AI 的定位应当是：替我们守住“规则”的底线，把精力解放出来去攻克“理解”的天花板。 建立这些规则的目的，是确保 AI 生成的代码不会成为没人维护的“技术黑盒”。