AI 代码为何一重构就暴露隐患

AI 生成的代码看起来已经完工，字段一改、接口响应一变，却可能在测试没覆盖的地方出错。dev.to 的这篇文章把问题指向「隐藏耦合」：代码满足了眼前需求，却没有交代它依赖哪些结构、哪些逻辑必须同步修改。作者给出了三类评审线索，以及两类可放进 CI 的检查。

目前能确认什么

节选列出了三类脆弱模式：

• 重复实现：已有工具函数被重新写了一遍，后续修改只更新其中一份，两份逻辑逐渐分叉。
• 虚构 API：调用看似合理、实际不存在的方法或配置项，再用宽泛的异常捕获掩盖失败。
• 缺少契约：只实现正常路径，省略类型标注、输入校验和错误处理。

这里的「契约」，可以理解为调用双方对输入、输出和异常行为的约定。缺少这些约定，字段访问和硬编码字符串承载的假设就更难被发现。

作者提出，用 jscpd 检测重复代码，用 mypy 严格模式检查 Python 类型，并把真实类型、现有工具函数的签名和错误处理要求写进提示词。人工评审则继续判断代码所处分层、资源释放和模块依赖是否合理。

我的判断

AI 代码验收需要多问一句：它依赖的条件变了，哪里会提醒我们？

例如，新增发票格式化逻辑时，先核对是否已有对应函数；看到 except Exception 返回默认值时，追问它是否把接口调用错误也吞掉了。这比只检查当前输出是否正确，更贴近重构风险。

但节选对自动化效果的表述偏满。重复检测能识别相似片段，不能保证找出写法不同的同义实现；类型检查也依赖类型信息完整，无法保证识别所有动态属性和配置键。

节选给出了 40 tokens 的重复检测阈值，但没有展示它在不同仓库中的误报、漏报情况，也未交代示例 CI 的完整运行环境。把它作为检查起点有依据，把它当作通用门槛，现有信息还不够。