我们从接入生成式 AI 编程工具之后的一次线上事故聊起。那个周五晚上十一点预发环境的订单汇总数据开始错乱排查到凌晨才发现是一个工具函数在处理时间戳时把时区信息丢了——这段代码是 AI 生成的语法漂亮、注释齐全、单测全绿但它在真实业务上下文中做了一件任何人肉审查都会立刻拦住的事。那一刻我意识到一个问题代码写得快验证跟不上这已经不是个别现象而是所有依赖生成式 AI 写代码的团队正在集体积累的一笔隐形债务。这篇文章想聊的就是这笔验证债务。它不是AI 写得对不对这种能靠跑一次测试回答的问题而是一整套AI 产出速度暴涨、验证能力原地踏步的结构性失衡。文中会拆解它的成因、典型形态、为什么传统验证工具兜不住以及我目前在团队里实际落地的一套应对方法。适合的对象是已经在用或准备用生成式 AI 写业务代码的开发者、技术负责人还有那些正在为单测覆盖率 90% 但线上还是出事而困惑的团队。1. 从三分钟写完到三小时验证验证债务是怎么累积起来的先说清楚我理解的验证债务是什么。它不指代某一行具体的坏代码而是指单位时间内系统新增的代码量所需要的验证工作量和团队实际投入的验证工作量之间的差值。差值为正的时候债务就在增长。人工写代码的年代这个差值通常是收敛的。一个人一小时能写二三十行核心逻辑他写完之后天然会花一部分时间自查、跑相关用例、想想边界条件产出和验证之间有一个人脑的隐性调节机制。但生成式 AI 改变了这个调节机制开发者从一个逐行写代码的人变成了审阅、粘贴、拼接 AI 产出的调度员代码产出速度可以提升 5 到 10 倍但验证能力——包括 Code Review 的注意力、回归测试的执行范围、对业务上下文的理解深度——并没有跟着提升 5 倍于是差值被急剧拉大。我用一个具体数字说明白。上个月团队做一个小型数据同步模块三位同事用 AI 辅助编码三天写完了大约四千行代码包括配置、工具函数、链路日志和重试逻辑。放在以前这个量级一个人要写两周两周时间意味着期间有大量的边写边想环节很多问题在写的过程里就被消化了。而这次三天交付之后Code Review 花了整整两天仍然不敢说看完了因为 AI 生成的代码里大量使用了我们不太熟悉的第三方库和写法评审者需要额外查文档确认语义。这就是验证债务AI 把写代码的时间压缩了但验证的时间不仅没压缩反而因为代码的陌生感增加了。1.1 为什么单测跑通了仍然不能覆盖验证很多人有一个误区AI 生成代码之后我跑一遍单元测试全绿就说明验证做到位了。这句话在人工写代码时代勉强成立在生成式 AI 时代基本失效。原因是 AI 生成测试代码的时候往往和被测试代码共享同一套假设——它认为输入一定是某个格式、某个依赖一定存在、某个回调一定被调用然后基于这些假设构造测试用例。问题在于这些假设本身可能就是错的。举一个我们真实踩过的例子。AI 生成了一段 URL 有效性校验函数开发要求是过滤出合法的外链AI 写的函数用正则匹配 http/https 协议头、检查域名中是否包含点号、排除 javascript 协议看起来非常完整。它生成的单元测试也覆盖了合法 URL、非法协议、空字符串等场景全部通过。但放到真实业务里这个函数被用来校验用户上传的链接输入里出现了带中文域名的 URL——正则不认直接给拦了用户反馈合法链接提交不了。单测没过吗过了。代码有问题吗有。问题出在哪验证债务——测试和被测代码共享了URL 就是 ASCII 字符这个错误假设而验证环节没有引入多样化的真实输入。1.2 验证债务会自我强化更麻烦的是验证债务有自我强化倾向。债务累积到一定程度团队会本能地开始少验证来自我保护既然代码量太大审不完那就只看 diff 里明显的逻辑问题跳过高风险区块既然回归测试经常挂但都是环境问题就先把失败用例标记为flaky。这些做法短期减轻了验证压力但会进一步扩大债务因为 AI 产出的代码进入主干的效率变高了垃圾进入主干的速度也跟着变高。最终团队会陷入一种上线前集体祈祷的状态——用速度换来的时间又不够弥补出问题后擦屁股的时间甚至反而更慢。2. 编译通过不等于能上线验证债务的四种典型形态要想治理验证债务得先能识别它。我把过去半年在项目里遇到的 AI 代码问题归纳成四类每一类背后都对应一种特定的验证缺口。2.1 形态一API 误用与行为偏差AI 大模型对常用 API 的调用模式训练得很充分但它并不理解你当前代码库里封装的具体实现。最典型的问题是把参数顺序传错、把同步方法当异步调用、或者调用了一个存在但语义完全不同的重载。这类错误的特点是不会导致编译失败甚至能通过基本的调用测试只有走到特定分支才会暴露。比如我们有一个内部的消息中间件封装send(topic, message, delay)的第三个参数是延时毫秒。AI 生成代码时从别的开源项目里学到了send(message, topic, delay)这种签名直接套用了。编译没问题单测用小规模的 happy path 也没问题到了线上发现大量消息被投递错误主题才顺着排查发现是参数位置反了。这种问题怎么验证才有用契约测试——在接口层面固定签名和语义让 AI 的产出在接入之前被契约检验一遍而不是靠人肉盯参数。2.2 形态二边界条件与异常路径的静默缺口这是最普遍的一种形态。AI 生成一个函数的时候正常路径往往写得很完整——输入合法、依赖在线、并发正常这些情况它见过太多训练样本写得驾轻就熟。但边界和异常路径就薄弱得多输入为 null、集合为空、下游超时、并发重复提交、磁盘写满、中间件重启窗口内的重试。不是 AI 不会写这些分支而是如果你没有在提示词里明确要求它默认输出的是最典型的解决方案而典型方案往往不包含公司内部的特殊约束。我印象最深的例子是一个 AI 生成的 JWT Token 登录验证中间件。代码结构清晰过期校验、签名校验、claim 提取都很标准。但它没有处理同一个 token 被并发请求同时打到服务上时底层的缓存击穿问题也没有处理 token 里缺少签发者字段的兼容逻辑。这些在线上监控里都是低频但高破坏性的场景。要验证这类缺口常规单侧重不到需要属性测试和故障注入后面我会展开说。2.3 形态三安全与合规层面的隐性雷AI 在生成代码时倾向于复用训练样本里的常见模式这意味着它也会复用样本里的过时模式和安全隐患。比如生成密码哈希时直接用了训练数据里出现率很高的 MD5、生成随机令牌时用了random模块而不是secrets、写 SQL 时用了字符串拼接。如果团队的安全审查还停留在人工 Code Review 层面这些隐患在 AI 高速产出的背景下很容易漏过去——因为审查者可能默认AI 写的代码至少不会犯低级安全错误这个默认本身就是安全的验证缺口。更隐蔽的是依赖风险。AI 会让你使用某个第三方包来实现功能它给出的版本号往往是训练数据里最常见的版本——而这个版本可能已经存在已知漏洞。上个月我们处理过一个案例AI 建议的图片处理库版本有一个已知的拒绝服务漏洞虽然我们的场景里影响有限但安全扫描直接拦了发布流水线。排查来源发现是 AI 生成代码时从旧项目代码片段里学来的。所以现在我们的验证流程里强制加入了依赖漏洞扫描和许可证检查并把这两项放在 AI 生成代码合并之前的必须关卡。2.4 形态四环境与依赖的黑盒风险最后一种形态和本地环境、运行环境强相关。热搜词里有一类是由于找不到 msvcp140.dll 无法继续执行代码这类 Windows 运行库问题在传统开发里属于老生常谈但用 AI 生成代码接入新依赖时这类问题会被成倍放大。AI 不会知道你当前的运行环境是 Python 3.9 还是 3.11、底层操作系统有没有装 VC 运行库、Node 版本是否支持某个新语法。它给出的安装命令和代码片段在自己训练数据的环境里没问题但换到你的环境就是一连串在我机器上能跑的翻版。我们团队遇到过一个更隐蔽的变种AI 生成的代码引用了某个环境变量但这个变量只在 CI 环境存在本地开发环境根本没有。代码在 CI 上跑得好好的开发者本地一跑就崩。后来验证环节里加了一条硬性规定——AI 生成的涉及环境依赖的代码必须在 README 里显式列出全部前置条件和环境变量且要有一个最小可运行清单通过本地环境的冒烟验证。不满足这条的代码不允许合入。3. 传统验证手段为什么在 AI 编码节奏下失效很多人问我我们不是有单元测试、静态分析、Code Review 吗为什么还是堵不住 AI 代码的问题这个问题问得好因为它触及了验证债务的本质——不是没有验证手段而是传统手段的运行前提已经被 AI 编码模式摧毁了。3.1 单元测试覆盖率虚高测了不等于验了单元测试的基本逻辑是开发者为自己的代码编写测试从而验证行为是否符合预期。这个逻辑有一个隐性前提——开发者理解这段代码应该做什么。AI 编码场景下这个前提不成立开发者往往是在不完全理解的前提下把代码接入系统然后让 AI 顺手生成测试。这时候测试的预期是从代码反推出来的不是从需求正推出来的等于用代码验证代码自己形成逻辑闭环。覆盖率达到 90% 也没有意义因为这个 90% 覆盖的可能是错误行为和它的镜像测试。我后来做过一个实验把一个已知有 bug 的 AI 生成函数拿给另一个 AI 实例去补测试测试全部通过。为什么因为它俩共享了同一套错误假设。这就是为什么不能用 AI 验证 AI必须引入独立于生成过程的验证源——真实业务场景的输入样本、契约定义、不变量约束。3.2 静态分析只能抓语法层面的坏味道静态分析工具SonarQube、ESLint、Pylint 等擅长的是抓语法错误、未使用变量、明显的反模式但生成式 AI 产出的代码在语法层面通常非常干净——这是大模型的强项。它的问题几乎都出在语义层参数顺序弄反、边界条件缺失、并发控制不对、安全模式过时。这些都是静态分析工具鞭长莫及的。这让我想起一个常被忽略的点静态分析工具的规则库本质上是人类历史上踩过的坑的编码化——它们只能识别已知模式。而 AI 代码的问题在于它会组合出没人踩过的坑。比如它用一个不常见的装饰器组合改变了函数的执行时序静态分析完全无感运行时才会出问题。所以验证策略的重心必须从查代码长得规不规范转向验行为符不符合契约。3.3 Code Review 的注意力瓶颈人成了瓶颈Code Review 曾经是质量保障的最后一道防线但在 AI 编码加持下这道防线正在失效不是因为它不重要而是因为人类的注意力带宽固定不变。一个评审者每小时可以认真审查的代码行数是有限度的AI 把产出速度提了 5 倍评审者的吞吐量没有提升 5 倍于是只能掠过越来越多的代码。这个过程中真正的验证深度急剧下降。更有意思的是评审者面对 AI 生成的代码会有一种天然的把关人效应——看到命名规范、注释清晰、结构工整的代码下意识会认为质量不错。AI 输出的代码恰恰在最容易给人靠谱感的层面非常完美真正的语义错误藏在这些表面质量的背后。我在团队里遇到过评审者给了LGTM的代码第二天因为并发问题被回滚——不是他不认真而是他只有那么多时间分配给四千行 AI 代码上的平均注意力不足以支撑深度验证。3.4 回归测试的组合爆炸改得越快挂得越多生成式 AI 还有一个显著特征迭代频率高。开发者会不断用对话的方式要求 AI 修改代码加一个参数换个判断条件这里改成异步。每一次对话式修改本质都是一次未经过深思熟虑的变更。传统开发里一次修改会触发开发者对受影响范围的持续关注而在 AI 对话模式下开发者经常连续提出十几个修改要求每个要求的副作用都超出了他的认知范围。回归测试的执行范围随之爆炸——不是测试用例变多了而是每一次改动可能影响的路径变多了你根本不知道该回归哪些测试。我们经历过一个项目上午让 AI 改了一个数据校验的公共方法下午另一个模块开始报数据格式错误。两个模块没有直接调用关系但都间接依赖同一个工具类。传统开发里修改公共方法的开发者会本能地全局搜索调用点AI 对话式修改中这个环节直接被跳过了。验证债务就这样在不知不觉中翻倍。4. 管理验证债务的三个抓手契约先行、分级审查、自动化兜底面对验证债务完全靠加强人工审查是死路一条因为人的带宽就那么多。我的思路是把验证工作前置、分层、自动化。这里分享三个我认为最有效、也已经在团队里跑出效果的抓手。4.1 契约先行在 AI 写代码之前先固化必须满足什么传统开发里接口定义和实体类已经是一种契约但不够。我给这个思路的升级版做了三个动作第一所有 AI 要生成的代码必须先提供输入输出样例和边界行为说明形式上可以是文档、JSON Schema 或者函数签名备注第二关键模块必须写契约测试——不测内部实现只测给这个输入必须得到这个输出、必须抛这个异常、必须保证这个不变量第三把契约测试放进 CIAI 代码接入后先跑契约测试而不是先跑单元测试。举一个可落地的例子。我们需要一个验证 URL 有效性的工具函数以前的做法是直接让 AI 写写完自己再 review。现在我们的做法是先定义契约文件里面写清楚——合法 URL 例子含中文域名、带端口、带 query 参数、非法 URL 例子XSS 协议、空格、控制字符、超长 URL 的处理策略、空串的返回约定。然后把这个契约文件丢给 AI告诉它按契约实现不要加戏。契约测试独立于实现存在AI 生成的代码必须在这个测试下跑通才允许进入后续流程。这一步等于把验证什么从人脑子里搬到了自动化流程里AI 产出多快验证都能跟上。为什么契约要人肉写而不是让 AI 写因为契约是需求层面的东西必须来自业务方和资深开发者的判断。AI 写的契约大概率会和 AI 写的实现共享同一套错误假设又回到用代码验证代码的闭环里了。4.2 分级审查把稀缺的人工评审注意力花在高危区我们团队现在不对所有 AI 代码做同等强度的验证而是按风险分级。风险等级取决于三个因素模块是否处理资金或安全敏感数据、是否被多个上游调用扇入越大风险越高、是否涉及并发或分布式一致性。高风险模块的 AI 代码必须经过逐行人工审查并且要有资深成员在 CR 记录里明确署名中风险模块要求自动验证过门槛审查可以采用抽样式低风险工具函数只要自动测试覆盖且没有安全扫描问题允许简化流程。这套分级的核心逻辑人工验证的稀缺资源必须按出问题后的爆炸半径来分配而不是按代码行数均匀分配。我们的法律合规、资金安全相关模块从一开始就禁用了 AI 直接改代码必须人工起草核心逻辑AI 只负责辅助补全。这个边界必须提前划清楚否则 AI 一句提示词就可能给核心模块埋下定时炸弹。4.3 自动化兜底把验证能力做成流水线而不是靠人肉传统 CI 里通常已经有 lint、单元测试、覆盖率门禁但应付 AI 时代不够。我们在流水线里额外加了四样东西依赖漏洞扫描覆盖面直接依赖和传递依赖契约测试执行前置条件AI 代码合并前必须跑通快照测试拦截意外的行为变更特别适合抓 AI 对话式修改导致的隐性变化模糊测试对输入做随机化变异攻击边界条件和异常路径。模糊测试是其中性价比最高的一项。我们用现成的模糊测试框架让 AI 生成的解析类、校验类、工具类代码接受随机化输入经常能找出开发者完全没想过的异常路径。上个月一个 AI 生成的 JSON 解析函数在模糊测试下跑出了一个深层嵌套导致栈溢出的问题——人肉审查看不出这种问题单元测试覆盖不到这种数据形态只有让机器用暴力但高效的方式才能兜住。5. 我踩过的坑与现在的 AI 协作工作流最后聊点实际经验。我并不是一开始就意识到验证债务这回事反而是踩了几个大坑之后才倒逼出来的流程调整。分享出来希望别的团队能少走弯路。5.1 第一个坑让 AI顺便写个测试等于白写最开始用 AI 写代码的时候我图方便在提示词末尾加一句顺便生成对应的单元测试输出结果是单测 100% 通过、覆盖率 95%。第一次让我警觉的是上面提过的 URL 校验函数单测和实现共享了同一套错误假设。后来我改成先写契约测试再让 AI 根据契约写实现。第一次切换到这种模式时明显不习惯因为验证前置让 AI 产出的第一版显得更慢但长期看返工率降了一大截。现在我的固定工作流是写代码之前先花 20 分钟把输入样例、非法输入、边界条件、异常行为列出来这一步绝不能跳然后用这些去定义契约测试最后才把契约交给 AI 让它实现。体感上总时间反而少了因为 AI 不会对着一个模糊需求先写出一版漂亮但错误的东西然后再花半小时修修补补。5.2 第二个坑对话式修改失控另一个大坑是对话式修改。原来我习惯让 AI 改完一个函数再改另一个连续对话几轮之后整个文件变成了一个没有人完全理解全部上下文的缝合怪。有一次 AI 在修一个 bug 时把另一个函数里的一段逻辑顺手重构了重构后的代码逻辑等价但风格迥异评审时完全没看出来直到一周后有人在这个函数上叠加新功能时才发现——验证成本被推后了。现在我对 AI 的每一次修改都要求它先行输出 diff而且明确规定修改范围。如果一次修改涉及超过两个函数必须主动解释为什么会有连带改动并重新跑契约测试和快照测试。快照测试在这个场景里救了命——它会拦住意外行为变更。5.3 调整后的团队协作流验证预算制团队层面我引入了一个简单的验证预算概念。每个迭代周期AI 生成代码的合并量不是无上限的而是根据团队的可投入验证时间换算出一个配额。配额用完剩下时间不允许再合入新的 AI 生成代码只能写测试、修债务。听起来有点反效率但它避免了那个最坏的结果——一个月内 AI 写了上万行代码月末大家都在疲于应付自己都不理解的问题。具体执行上我们以每周为单位统计AI 合入的代码行数、人工审查投入的小时数、线上问题回溯中指向 AI 代码的比例。当比例开始升高就主动降低 AI 编码的使用强度而不是继续加码。验证债务就是这样它不会自动消失只会在你不看它的角落里利滚利。对我来说使用生成式 AI 写代码这件事本身没有问题问题在于我们用工业时代的生产心态去套信息时代的生产工具——只关注产出速度忽略了对产出物的验证能力必须同步升级。把验证从事后环节提到事前契约从人肉盯着变成流水线兜底从均匀用力变成分级投放这才是和 AI 协作的正确姿势。