“编译能过、单测全绿、本地也能跑，一上线就崩”——这两年凡是认真用 AI 辅助写代码的人，多多少少都撞到过这种邪门场面。大家在群里聊起来，最后多半归到"AI 生成的代码质量不行"，但以我自己的观察，问题往往不是 AI 写得不够好，而是我们的验收方式还停留在"人类写代码时代"的惯性里。
传统上，一段代码只要过了编译、过了单测，基本就能放心合入。这套规则对程序员手工写的代码大体成立，因为人在写代码时脑子里装着需求边界、历史包袱、异常情况和线上环境的各种隐性约束，单测只是把这些显性化的一部分。可 AI 不一样，它写代码时锚定的只有你给它的上下文、它见过的海量样本、以及"让这段代码自己看起来自洽"的本能。于是你会发现：AI 产出的代码特别容易陷入一种"自我闭环"——编译不过就调类型声明，单测不过就改断言或者补一个分支，改到最后实现和测试严丝合缝地互相印证，运气好点 Demo 也能跑通，唯独没有和真实世界发生过一次硬碰硬的对话。
这篇文章想聊的就是这件事：AI 代码为什么会在传统验收标准下全线飘绿、上线却翻车，以及我们后来在验收流程里加了哪些真实有效的检查环节。我会从三个维度展开——先说传统验收的三个指标各自的盲区，再复盘几类我实际撞过的"上线炸"典型模式，最后给一套现在我们团队在用的、针对 AI 代码的验收补充方案。如果你是正在用 AI 写业务代码、或者团队里有人这么干但总觉得哪里不对，这篇文章应该能给你一些立刻能用的抓手。
1. "能编译"、"能跑"、"单测绿"：三个信号各自证明了什么
先说编译。编译通过这件事，本质上只代表代码满足了编程语言的语法和类型规则。这里面就有第一个要命的地方——AI 非常擅长"用类型宽松换取编译通过"。我需要一个严格的类型约束，它可能悄悄给我一个any或者一个宽泛的联合类型，编译不报错，语义却退化了。更常见的是，AI 会把所有可能出现的边界情况"压缩"成一种它觉得安全的类型形态，这样写起来顺手，编译也不会拦你。换句话说，编译通过只代表"语法上没错"，不代表"类型上真的表达了约束"。
然后是"能跑"。这条最迷惑人。AI 生成的代码天然倾向线性逻辑——输入正常、环境正常、依赖正常、时序正常，一条 happy path 从头走到尾，当然能跑。但它不会主动去验证这条路上如果有绊脚石会怎样：入参里混进一个格式诡异的字符串怎么办，下游接口超时五秒怎么办，并发请求同时打到同一个共享变量上怎么办，缓存里读到半截脏数据怎么办。人写代码时，这些场景会在大脑后台自动过一遍，因为你在真实系统里吃过亏；AI 没有这种肌肉记忆，你不明确告诉它要处理，它就默认"这件事不会发生"。
最后是单测全绿，这是最大的陷阱。我专门观察过 AI 写测试的行为模式，它会做三件非常隐蔽的事：
- 反向拟合：先写完实现，再照着实现的行覆盖去补测试。每个分支都覆盖到了，但那些分支只是"代码里有"的逻辑，不一定是"需求里要有"的行为。测试证明的是"代码和自己一致"，不是"代码和需求一致"。
- 断言过弱：只断言返回值存在、类型正确，或者调用了某个函数，但没断言具体行为、时序、边界、异常结果。测试通过得非常容易，因为它根本没在验收任何有价值的东西。
- 测试和实现一起错：这是最毒的。需求和 AI 说的时候有个隐含前提，AI 没理解对这个前提，但它写的实现是基于它误解后的模型，测试也是基于同样的误解写的。两边自洽，全绿，上线炸。
打个比方：传统单测像数学考试里的验算——你算完一道题，再顺着自己的步骤检查一遍，发现每一步都通，于是觉得肯定对了。但你从来没有翻开书后的标准答案对一眼。如果 AI 从第一步的公式就理解错了，那验算再顺，也验不出错误。
所以你看，传统验收三件套对 AI 代码几乎失效，是因为这三个信号的底层假设是"写代码的人对世界有完整的、隐性的理解，而这些检查只是兜底"。到了 AI 这里，这三个信号变成了"代码内部自洽性的三个侧面"，它们和你真正关心的问题——"这段代码在复杂、混乱、不完美的真实环境里会不会坏"——隔着一条深深的鸿沟。
2. 实际翻车的五类模式：这些坑我都在 AI 辅助开发的代码里撞过
这一节我按自己的真实经历，把 AI 代码上线后爆出来的问题归纳成五类模式。每一类都不是偶发个例，而是我尝试用 AI 深度参与业务代码开发之后反复踩中的同款坑。看懂这五类模式，你就知道该往验收清单里加什么。
2.1 边界条件空洞：默认参数永远"合法"
最常见的一类，是 AI 生成的函数对入参的合法性有一种"迷之信任"。我遇到过一个很典型的例子：某内部工具需要处理一批用户上传的 Excel 文件，AI 生成的解析函数里写了if (value != null)做校验，然后就放心地把value.Length、value.Split(',')一路用了下去。单测里喂的都是完整规范的字符串，全绿。线上跑了一周，有人传了一个字段为空字符串的表格，整个批处理任务直接抛异常中断。
后来我让 AI 自己复盘这段代码，它斩钉截铁地说校验没问题。问题就出在"非空"和"合法"之间的距离太大了——空字符串、全角空格、超长文本、异常编码、字段缺失、类型不匹配，这些都是真实世界里每天都在发生的"正常情况"。AI 默认这些不存在，因为没有人告诉它这些是它必须处理的对象。
验收教训：现在团队里验收 AI 代码，第一眼不看功能实现，先看它对非法输入、极端值、空值、超大值的处理。我会强制要求让 AI 为每个公共函数写一个"如果世界是恶意的话会怎样"的用例清单，再拿这份清单反向测试代码。
2.2 异常被吞：静默失败比报错更可怕
这个模式比边界条件更隐蔽。AI 代码里高频出现try { ... } catch (Exception e) { /* TODO */ }或者catch之后打一行日志、然后返回一个默认值。在单测环境里，异常几乎不会发生，所以这种代码全绿。上线之后，异常发生了，然后被吞掉，系统继续往下走，但数据已经错了或者丢了——而且没人知道。
我印象最深的是某支付回调模块，AI 在回调处理函数里包了一层 try-catch，捕获异常后只是 log 了一下。结果线上某个第三方渠道的回调格式偶发变化，解析异常被吞，回调就这么"成功"了，但订单状态没更新。由于日志淹没在海量信息里，这个问题从发生到被发现整整过了三天，中间产生了大量对账差异。如果当时没有仔细查账，这个雷可能埋更久。
验收教训："代码不会报错"不是优点，是警报。现在我们要求 AI 生成的代码在捕获异常时必须回答三个问题：这个异常发生后正确的行为是什么？需要给上层什么信号？如何保证重试或补偿能够发生？如果 catch 块没有任何实质处理逻辑，一律退回重写。
2.3 状态与生命周期：单测环境里根本不会出现的"多副本地狱"
AI 写无状态函数很强，但一旦涉及状态管理、生命周期、并发和共享资源，翻车率直线上升。单测跑的时候通常单实例、单线程、数据量小、资源充足，所以很多状态相关的问题根本不会暴露。
我撞到过一个很典型的例子：AI 给某个数据同步服务加了一个"内存缓存最近一次拉取结果"的优化，变量直接挂在全局 map 上。单测里一个实例跑，逻辑完全正常。线上起了四个副本，流量一上来，四个进程各自缓存各自的，互相看到对方的旧数据，本地缓存击穿，然后就是各种错乱的数据不一致。AI 完全没有多副本意识。类似的问题还有：缓存没有失效策略导致内存缓慢上涨、连接池配置成单连接导致并发一高就排队、定时任务的并发控制完全没有考虑分布式锁。
验收教训：凡是 AI 写的涉及状态、缓存、锁、连接池、定时任务的代码，默认都需要人工 review 状态的生命周期。我会问三个固定问题：状态存多久？谁清理？如果多个进程/副本同时访问会怎样？这三个问题 AI 不会主动替你考虑，你得替它想。
2.4 外部依赖的隐性契约：文档外的东西，AI 根本不知道
这个大类我愿称之为"AI 代码的盲区之王"。每个外部系统——数据库、Redis、消息队列、第三方 API、内部微服务——都有文档之外的实际行为：限流阈值、超时时间、重试策略、幂等性要求、流量突增时的退化模式。单测里这些依赖通常被 mock 成永远正常、永远快、永远不报错的理想对象，所以相关问题全绿。
真实案例是 AI 接入某第三方短信服务时，直接按最简单的方式调了接口，没有做任何限流控制和超时处理。测试环境流量极小，一切正常。上线后某个营销活动一小时内调了上万次接口，第三方开始限流，但我们这边没有退避重试策略，直接批量报错。这还没完，AI 代码对接口响应的解析也过于"天真"，第三方错误码格式稍变就把它当成功处理了。
验收教训：对于 AI 生成的所有外部调用代码，review 时必须补齐三件套：超时上限、重试策略（含退避）和错误响应识别。更重要的是，凡是 AI 写的代码要接外部依赖，一定要在 prompt 里明确要求它列出所有已知假设，再逐个验证这些假设。
2.5 性能退化：单测数据量下的"隐形炸弹"
最后一类，是 AI 代码里高频出现的性能问题。单测数据集通常就几十条、几百条，复杂度是 O(n²) 也毫无体感。但到了线上，数据量一上来，慢查询、循环嵌套、重复请求、不必要的大对象复制，这些问题会迅速从"理论上的缺点"变成"实际上的事故"。
我有一次让 AI 优化一个报表统计逻辑，它给我写了一个双重循环，遍历所有订单去查每个订单的明细，粗略一看逻辑全对，单测也绿。但那是一个每天新增几百万数据量的系统，上线后直接把数据库打挂了。后来我把问题抛回给 AI，问它能不能优化，它立刻给出了一个用批量查询 + 预聚合的方案——你看，它不是不会，只是没有人要求它那么做。
验收教训：AI 生成代码的性能验证，绝不能靠单测跑数据集来判断。我们现在的做法是，凡是 AI 写的涉及循环、查询、数据处理、批处理的代码，必须先让它自述复杂度，再对线上量级的模拟数据进行一次压力验证，通过审查后才能合入。
3. 验收流程怎么改：我给团队加的四个补充环节
说了这么多问题，该说解决方案了。我们对 AI 代码的验收，在原有"编译 + 单测 + 人工 review"的基础上，加了四个补充环节。它们不复杂，但每一个都实打实地拦截过问题。
3.1 强制让 AI 输出"假设清单"和"风险清单"
第一步在 prompt 阶段就做。我现在要求所有 AI 生成的代码必须附带两份清单：
- 假设清单：这段代码基于哪些前提假设？比如"入参一定非空"、"下游接口一定在两秒内返回"、"缓存永远有效"、"并发量不超过 N"。
- 风险清单：如果某个假设不成立，会发生什么？影响范围是什么？会静默失效还是显式报错？
拿到清单之后，团队 review 最优先的事情不是看代码实现，而是看这两份清单是否合理。大多数线上事故，都能在清单阶段被提前识别——因为你会发现 AI 的假设里往往藏着"世界是美好的"这种天真前提。
3.2 用"属性测试"补充传统单测的盲区
传统单测是"给定输入，断言输出"。这个模式有一个天然的弱点：你永远只能测你想得到的用例。AI 写的测试更是这样——它只会测它想得到的行为。所以我们引入了属性测试（property-based testing）：不指定具体输入，而是描述"对于所有满足某种条件的输入，输出应该满足什么不变量"。
举个例子：一个解析函数，不再测"输入{'name': 'alice'}得到什么"，而是说"对于任意合法的 JSON 字符串，解析后字段数量和原字符串中字段数量一致；对于任意非法 JSON，函数不得抛出未捕获异常"。然后让测试框架自动生成海量随机输入去轰炸这段代码。这是在用"验证行为契约"替代"验证具体用例"，边界条件的炸点更容易被预先踩中。
3.3 异常注入和故障演练必须进入验收流程
单测环境里一切正常，不代表线上一切正常。我们现在的做法是，在测试环境里主动制造混乱：让下游接口随机超时、随机返回 500、随机返回格式错误的响应；让数据库连接随机断开；让系统在低内存、高延时条件下运行。AI 代码在这种"混乱测试"下经常一秒破功——各种默认重试、默认超时、默认成功处理就会露出马脚。
具体工具上不需要多复杂，我们早期甚至用一个简单的 proxy 脚本随机改流量，后来才上了比较完整的故障注入工具。关键是这个环节不能省，因为异常路径是 AI 代码最薄弱的地方，也是传统单测最不覆盖的地方。
3.4 上线前的真实样本回放
最后一个补充环节是"回放"：用线上脱敏的真实请求日志，在测试环境里回放一遍 AI 生成的代码，观察是否有异常、超时、数据不一致。这一步的价值在于，真实数据里夹杂着各种"开发者想象不到"的边界情况——空格、大小写、时区差异、陈旧格式、历史脏数据——这些单测和属性测试生成的数据永远模拟不出来。
我们有一个内部工具专门做这个事：抓取线上接口的请求和响应，脱敏后放到测试环境按顺序回放，对比新老代码的处理结果差异。AI 写的代码第一次跑回放时，几乎必然暴露问题。这不是因为 AI 特别差，而是因为真实世界的复杂程度远超任何人的想象，包括 AI 的。
4. 从源头降低风险：我也在改进和 AI 协作的方式
验收流程再怎么补，都不如在源头降低问题的概率。用了大半年 AI 辅助开发之后，我在 prompt 设计和工作方式上积累了一些不算新的经验，但对减少"上线炸"确实有效。
4.1 Prompt 里必须写清验收标准，而不是只写需求
大部分人用 AI 写代码，prompt 就写"帮我实现一个 XX 功能，输入是 X，输出是 Y"，完事。这等于告诉 AI："你只需要做你自己理解的正确事情。" 它当然会按它自己理解的最顺畅逻辑来写。
我现在写 prompt 的标准模板是四段式：需求描述 + 验收标准 + 已知边界 + 约束条件。其中验收标准这一块我会写得特别具体——"函数必须对所有非法输入返回错误码而不是抛出异常"、"所有外部调用必须有超时和重试策略"、"性能复杂度不得高于 O(n log n)"、"禁止使用全局可变状态"。这些约束直接堵住了 AI 的默认懒惰路径。你会发现，当验收标准说清楚之后，AI 生成的代码质量立刻上了一个台阶，因为它的"目标函数"变了。
4.2 让 AI 先写测试，再写实现
这是我认为性价比最高的一招。让 AI 先根据需求写一份测试用例，review 通过之后，再让它写实现。这么做的核心价值在于：测试用例比实现更难"自欺欺人"。因为用例体现的是对行为的定义，AI 在写用例时必须把"什么样算对"具体化。如果它前期理解错了需求，大概率会在测试用例阶段就露馅，而不至于等到实现写完、测试和实现互相印证之后才出问题。
我们团队现在把这条写进了流程：所有 AI 生成的代码，必须附上它的测试用例，review 的时候先审用例，再审实现。审用例时我们只盯两件事——断言是不是足够强（是否真在验证行为），以及用例里有没有体现边界和异常路径的处理。通过后再让 AI 写实现，否则提前打回。
4.3 小步提交 + 强制隔离：AI 改动的默认处理方式
在工程流程上，我也有两个非常实际的变化。第一是 AI 的改动一律不允许直接合入主干，必须走独立分支，由人类开发者 review 后手动合入。这样做不是为了怀疑 AI，而是因为 AI 的一次改动往往牵涉面比它想的大，没有隔离，出问题很难回滚。第二是强制小步提交。把大需求拆成一个个小任务，每个任务单独交给 AI，独立验证，独立合入。大需求一次性生成的代码，内部耦合度高，问题暴露慢，排查成本直线上升。小步推进虽然看起来"浪费"了 AI 的并行能力，但实际上把整体风险降了一个数量级。
4.4 可观测性埋点：验收的最后一道防线
最后一招是给所有 AI 生成的代码加"强制可观测性"要求。我在 prompt 里会明确写：所有外部调用必须记录耗时、状态码和错误原因；所有异常路径必须输出结构化的告警日志；所有涉及数据的变更操作必须记录操作前后状态。这些埋点在平时看起来有点"重"，但一旦出了问题，定位成本会低一个数量级。很多"上线炸"最终能快速收敛，靠的往往不是代码本身多完美，而是可观测性做得好，几分钟内就能锁定问题模块。
我自己在 AI 辅助开发这条路上踩过不少坑，现在最大的体会是：AI 是一个极其强大的执行者，但不是一个合格的验收者。它能快速把想法变成代码，但"这段代码真的对吗"这个问题，它没有能力、也没有动力去回答。这个责任只能落在人身上。所以我现在花在"验收"上的时间，比花在"让 AI 写更多代码"上的时间还要多。但反过来想，正是因为 AI 把写代码的时间从几小时压缩到几分钟，我们才有了充裕的时间去仔细验收每一段代码。这个投入产出比，算下来是划算的。
如果你也正在团队里推行 AI 辅助开发，我的建议很简单：多信任 AI 的执行力，但永远不要信任它的"自评"。编译通过、单测全绿、本地能跑，这些都只是入场券，真正的验收从你开始质疑这段代码在真实世界里的样子才算开始。把"它看起来没问题"变成它经历过边界轰炸、异常注入、真实数据回放之后"仍然没问题"，上线炸这种体验，你大概率就不会再遇到了。
