AI 编程生成的代码为何会创造一种新的技术债？

AI 编程生成的代码会创造一种更隐蔽的技术债：它往往不是明显错误，而是“看起来正确”。语法合理、结构完整、测试甚至可能通过，但实现依赖了错误假设、遗漏边界条件，或者用补丁掩盖真正问题。团队需要为验证这种可信外观付出额外成本。

明显错误反而容易处理

完全无法编译、调用不存在接口或直接导致测试失败的代码，会快速暴露并被删除。真正难处理的是局部成立的方案：它能运行，也符合常见模式，却不符合当前系统的业务语义和运行约束。

一段讨论 AI 生成代码的视频将这种现象称为一种新的技术债，并强调生产系统中“近似正确”代码的长期风险。该来源属于个人工程观点，不是受控研究；它适合揭示审查模式，不能证明所有 AI 代码都比人工代码差。

这种债务可以叫作“可信外观债”

传统技术债常能从复杂度、重复和架构违规中发现。可信外观债的特殊之处，是代码表面质量降低了人的警惕性。命名清晰、注释完整和异常处理齐全，都可能让错误方案显得更成熟。

债务的本金是未经证实的假设，利息则是未来每次阅读、调试和扩展时的验证成本。维护者不仅要理解代码，还要重新判断它当初是否真正满足需求。

它通常藏在哪里

位置	表面现象	隐藏问题
错误处理	有完整的兜底逻辑	异常被吞掉，失败被当成成功
数据校验	字段类型都正确	业务不变量没有被验证
安全控制	存在鉴权调用	检查发生在错误边界或可被绕过
并发逻辑	单次运行正常	竞态、重试和幂等性被忽略
依赖使用	调用方式符合文档	版本、许可或运行约束不匹配
测试	覆盖率有所提升	断言只重复实现，没有验证需求

为什么普通代码审查容易漏掉

生成补丁往往规模大、格式统一，审查者需要在有限时间内处理更多“看起来合理”的代码。人会自然依赖熟悉的结构和自信的说明，把深度验证留给少数可疑位置。

如果提交者自己也没有经历设计过程，审查中就缺少能解释关键选择的人。双方都可能默认模型已经考虑过边界，形成无人真正拥有假设的状态。

局部正确不等于系统正确

模型通常根据任务描述和有限上下文生成局部方案。生产系统还受数据生命周期、权限边界、历史兼容、容量限制和跨服务契约约束。单个函数正确，放进完整调用链后仍可能产生错误。

因此，验证不能只检查代码本身，还要追踪输入从哪里来、输出到哪里去、失败如何传播，以及重试或并发时状态是否仍然一致。

本文建议的三问审查法

视频说明提到可以用简短问题审查 AI 生成的合并请求，但公开说明没有列出具体问题。下面三问是基于其核心风险整理的独立实施框架，而不是对视频原话的转述。

1. 它依据什么成立：需求、数据和接口假设是否有可核验证据？
2. 它会怎样失败：边界、异常、并发和安全路径是否被测试？
3. 谁能长期负责：是否有人理解设计、监控信号和回滚方法？

三问可以在几十秒内决定审查方向，但不能代替完整测试。任何一问答不上来，都意味着补丁需要更多上下文或更小的变更范围。

第一问：它依据什么成立

要求提交者列出生成代码依赖的事实，例如字段是否允许为空、调用是否保证顺序、接口是否支持幂等、权限由哪一层执行。每项关键假设都应能映射到规格、测试、代码或可靠文档。

“模型认为通常如此”不是项目证据。如果任务上下文不足，应先补充信息，再重新生成或人工修改。

第二问：它会怎样失败

成功路径最容易生成，也最容易演示。审查应主动构造失败场景：超时、部分响应、重复请求、空数据、权限变化、资源耗尽和依赖降级。

测试不仅要证明输出正确，还要证明失败不会被静默吞掉、敏感数据不会泄漏、状态能够恢复，并且监控能让维护者发现问题。

第三问：谁能长期负责

生成代码需要明确所有者。负责人应能说明修改为什么位于当前模块、哪些行为不能改变、上线后看哪些指标，以及异常时如何回滚。

若团队只能再次询问模型才能理解代码，就已经形成认知债。模型的回答也可能随上下文和版本改变，不能充当唯一的系统记忆。

要求模型暴露假设，而非展示自信

提示词可以要求模型分别列出已知事实、推断、未确认事项和替代方案。这样审查者能把注意力集中在不确定区域，而不是被流畅解释说服。

生成说明仍需核验。模型可能为错误实现补写一个听起来合理的理由，因此证据必须来自代码库、规格和可执行测试。

用不变量和属性测试约束行为

示例测试只能覆盖少量输入，业务不变量更适合捕捉“几乎正确”的实现。例如余额不能凭空增加、授权失败不得改变状态、序列化后再读取应保持等价。

属性测试、模糊测试和变异测试可以扩大输入空间，并检验测试是否真的能发现错误。对金额、权限、加密和并发逻辑尤其重要。

比较行为，而不是相信重写

AI 修改遗留系统时，可以在相同输入和环境下同时运行旧实现与新实现，比较输出、状态变化、性能和日志。差异必须被解释，而不能默认新代码更好。

这种差分验证适合重构和迁移任务，但要注意旧行为本身可能有缺陷。已知错误应明确列为预期差异。

防止模型用绕过方式“修复”问题

当模型反复收到错误信息时，可能采用让检查消失的办法，例如捕获并忽略异常、放宽类型、关闭规则或增加无条件兜底。测试转绿不代表根因消失。

代码审查应特别关注被删除的校验、扩大的权限、被抑制的警告和新增回退路径。每个绕过都要说明业务理由，并验证不会把失败伪装成成功。

控制合并请求大小

可信外观债会随补丁规模增长。团队应限制单次生成任务涉及的职责和文件数量，把重构与功能变化分开，并让每个提交可独立回滚。

如果一个任务无法在合理时间内被人完整审查，就需要继续拆分，而不是以自动生成速度作为合并速度的依据。

衡量隐性返工

生成代码行数不能反映债务。更有用的指标包括审查修改轮次、短期重写比例、生产缺陷、回滚次数、错误定位时间，以及维护者为确认假设投入的时间。

团队还可以标记缺陷来源：是需求不清、上下文缺失、模型推断错误，还是人工审查遗漏。分类结果能指导改善流程，而不是把所有问题笼统归咎于工具。

结论

AI 生成代码的新型风险，不是它总会明显失败，而是它能以很低成本产生大量可信、完整、接近正确的实现。表面质量可能延迟发现错误，把验证和理解成本推给未来维护者。

团队应要求关键假设有证据、失败路径可验证、长期所有者能解释代码，并通过小批量变更和多层测试控制风险。AI 可以继续提供速度，但“看起来正确”必须经过工程流程转化为“有证据证明正确”。