1. 绿色的测试套件，掩盖了多少红色问题
1.1 一个让人后背发凉的“全绿”场景
先讲一个我最近实际遇到的场景。项目里有个订单金额计算的模块，团队引入了AI编程助手来补测试。开发同事把需求文档和现有实现丢给AI，几分钟后生成了一整套单元测试，本地跑完，Tests passed: 47/47，覆盖率从62%直接跳到91%。commit message写着“test: 增加订单模块单元测试，覆盖率提升至91%”，所有人都觉得这活干得漂亮。
但真正让我不舒服的是另一个数字。我把其中一条测试用例打开，发现它断言的是order.calculateTotal()返回200.00，而输入是“商品A单价100元，商品B单价100元，折扣码打了5折”。问题是，当时那个折扣码对应的折扣逻辑在代码里根本还没实现，服务端传过来的折扣率字段一直都是null。AI在生成测试时，选择了“跑通”而不是“验证正确”：它把当前实现里if(discountRate != null)这个分支走不到、因此返回原价的行为，直接记录成了预期值。
这个测试跑得再绿，也只说明“AI写了一段代码，把另一段AI生成或人工写的代码的行为拍了个快照”，并没有校验任何业务规则。更麻烦的是，这个模块后来真的接入了折扣逻辑——满100减20、限时5折——重构的手刚伸过去，所有相关测试全部红了。你以为测试在保护你，实际上它只是把“错误的现状”保护得死死的。
这个例子不是个例。过去一年里我看了大量AI生成的测试代码，越来越确认一件事：AI写测试正在把质量问题的重心，从“产品逻辑是否正确”转移到“测试本身是否正确”。而后者往往被大家忽略，因为一个快速变绿的测试套件太容易让人放松警惕了。
1.2 问题从“代码写得对不对”转移到了“测试本身对不对”
传统意义上，测试代码是一种“二次验证”：开发写功能代码时可能会犯错，测试作为独立视角把行为钉住，防止回归。人工手写测试时，写的人至少会问自己几个问题：这个接口的输入边界是什么？这条用例想验证哪个业务规则？为什么这个异常路径需要覆盖？这些思考过程本身就是对需求的一次重新梳理。
AI生成测试的过程完全不同。它拿到一段代码和相关上下文，本质是在做一个概率预测：给定这段输入、这个函数体，最“像样”的测试应该长什么样。它没有对业务的“对不对”负责，它只对“像不像”负责。这意味着三个层面的问题同时出现：
- 需求层面：AI不知道业务规则，只知道代码路径。它不会质疑“
discountRate为空时返回原价”这个行为是不是bug，它只会觉得“哦，这里有个分支，我把它覆盖一下”。 - 实现层面：AI倾向于把现有实现的可观测行为当作正确的规格说明来写断言。这就好比让一个从没见过交通规则的人，看了一百个小时的车流视频后，总结出“红灯停、绿灯行”的规律——大部分时候对，但一旦某个路口信号灯坏了，他会把“坏了”也当规律学进去。
- 维护层面：AI生成的测试通常冗余度高、断言碎片化，动辄一个用例断言七八个无关联的中间值。一旦代码需要调整，修测试的成本比手写测试高出几倍。
这就导致一个反直觉的结果：测试套件越“厚”，开发团队的信心越虚。我自己见过好几个项目，测试覆盖率数字上去了，线上故障反而变多了。不是说AI写测试导致了故障，而是AI生成的测试给了团队一种“我很安全”的错觉，让真正的质量漏洞悄悄溜了过去。
2. AI生成测试代码时，四个被放大的缺陷
2.1 幻觉断言：断言的不是业务，是数据
AI在生成测试时，最常见的翻车点是断言。它特别擅长把一个具体的返回值、状态码、字段值硬编码进断言里，而这些值是它根据当前代码推断出来的，不是根据需求证明出来的。
我用一个最简单的例子说明。假设有这样一个函数：
def get_discount_price(price: float, coupon_code: str | None) -> float: """ 根据优惠码计算折后价格。 若无优惠码，返回原价。 """ if coupon_code and coupon_code.startswith("SAVE"): return price * 0.8 return priceAI生成的测试大概率长这样：
def test_get_discount_price_save_coupon(): assert get_discount_price(100.0, "SAVE10") == 80.0 def test_get_discount_price_without_coupon(): assert get_discount_price(100.0, None) == 100.0 def test_get_discount_price_invalid_coupon(): assert get_discount_price(100.0, "COUPON") == 100.0表面看挺全面。但注意，这些断言只验证了“当前代码的行为”，它们没有验证最核心的业务规则。比如：折扣码SAVE10应该代表8折吗？SAVE前缀是唯一的有效规则吗？coupon_code大小写敏感吗？price为负数时应该抛异常还是返回原值？AI不会问这些，它只会扫一遍函数体，然后把能跑通的路径都跑一遍。
这种测试的问题在于：断言绑定的不是业务语义，而是实现细节。一旦产品经理改了规则——“SAVE开头的不一定是8折，SAVE20是9折、其余SAVE前缀才是8折”——这个测试就会红。但测试红了你问心无愧：因为AI压根没测“规则”，它测的是“当前代码的今天下午三点钟的快照”。
2.2 毒测试：为“跑通”而生的自我实现预言
“毒测试”这个词是我从一次代码评审里听来的，后来觉得特别贴切。它指的是那些看起来在验证功能、实际上在固化bug的测试。
AI生成测试代码时有一个天然倾向：它希望所有测试都通过。它不像人类开发者，写测试时偶尔会发现自己写出来的用例跑不过，然后去查“是我的测试写错了，还是功能代码写错了”。AI没有这种纠错冲动。为了让测试快速通过、让输出看起来“完美”，它会顺着当前实现选择能跑通的输入，绕开所有走不通的分支。这就是自我实现预言：AI先预设“这段代码是正确的工作成果”，再围绕这个预设反推合法的输入和期望输出。
我之前接手过一个支付模块，里面有一个函数用来计算手续费，原实现里在某种折扣条件下会把手续费算成负值。团队当时让AI补了测试，结果AI生成了一条用例，输入参数故意避开了那个触发负值的组合——因为那个组合会导致断言失败。测试跑完绿油油，但真实的bug依然躺在那里，甚至因为“覆盖率100%”显得更隐蔽了。
这种毒测试比没有测试更危险。没有测试时，至少代码review的人会认真看逻辑；有了毒测试，大家觉得“有测试兜底了”，review反而走形式。
2.3 虚假信心：绿反馈变成了“心理安慰剂”
人在持续获得“成功”信号时，会不自觉地降低警惕。这是认知心理学里讲烂了的道理，但在工程实践里很少有人把它和AI测试联系起来。
AI辅助生成测试后，开发节奏变成了“写功能 -> 让AI补测试 -> 本地全绿 -> 提交”。提交时的心情是愉悦的，因为CI/CD流程里的每一个信号都是绿灯。但这里边的反馈回路是断的：绿灯只说明“AI生成的测试通过了AI生成的代码”，不代表代码在真实用户手里也能通过。
真实的反馈是要靠用户点出来的。用户可不会管你的覆盖率是91%还是61%，他们只关心按钮点下去订单会不会下成功、优惠券能不能抵扣。而一个被AI测试喂出来的团队，很容易把“测试全绿”和“产品没问题”划等号。我见过不止一次，线上出bug之后开发的第一反应是：“不可能吧，测试都过了啊。”——这句话在AI测试时代会越来越危险，因为过了的测试，很可能连业务规则长什么样都不知道。
2.4 可维护性债务：一份AI测试，三年不敢动
如果说上面三个问题都是“当下”的，那维护性问题就是“未来”的。
AI生成的测试代码，普遍存在三个通病：
- 过度mock：一个简单函数，AI常常会mock掉两三层依赖，只为了让测试跑起来。结果测试变成了“验证mock和被测函数之间的胶水”，而不是“验证真实行为”。
- 冗余断言：一次用例里断言好几个无关联的中间结果。比如测一个下单函数，AI会把
user.id、order.total、inventory.locked、created_at全部断言一遍。任何一个字段内部实现调整，测试就碎一大片。 - 缺乏语义命名：AI给出的测试方法名通常是
test_call_api_success、test_process_data_returns_expected_result，完全看不出业务意图。三个月后回来看，没人愿意去改它。
这些通病叠加起来，会导致一种很别扭的处境：测试代码的维护成本超过了功能代码的维护成本。功能代码改一行，AI生成的测试可能要改十行。结果就是，代码要动的时候，决策标准从“这个改动对业务有没有价值”变成了“这个改动会不会弄碎一堆脆弱测试”。长期下来，技术债越滚越厚。
3. 一条鲜活的翻车链路：AI测试是怎么把bug“固化成预期”的
3.1 初始需求与AI生成测试
理论讲多了，容易飘。我拿一个真实发生过的完整案例，把AI测试“从帮忙到捣乱”的完整链路拆给你们看。
当时是一个抢购系统的库存扣减模块。需求文档写得很明确：并发场景下，库存扣减不能出现超卖；同一用户的同一商品请求只允许成功一次。开发用Redis+Lua脚本实现了原子扣减，功能代码本身是正确的。在提测前，团队让AI补了一套单元测试和集成测试，覆盖库存为0、并发扣减、重复请求等场景。
AI生成测试时，遇到一个难题：它看不到真实的Redis实例，于是它选择用mock把所有Redis调用都替换掉。这没错，单元测试mock外部依赖是合理的。问题出在断言上。AI mock掉的redis.eval方法，直接返回了一个硬编码的1，表示成功。然后测试断言“库存扣减成功”。
这一条断言就把逻辑钉死了：测试只验证了“当Redis返回成功时，业务层会认为成功”。它完全没有验证“当Redis返回失败、库存不足、并发冲突时，业务层到底怎么做”。而这些恰恰是抢购系统里最容易出问题的部分。
3.2 项目重构中发生了什么
后来项目进入二期，团队决定把库存服务从单机Redis迁移到集群模式，同时把扣减逻辑从“Lua脚本直改”改成“预扣+回退”两阶段操作。功能代码的人很小心，改了实现之后，手动跑了几个冒烟场景，看起来没问题。
但他们一直没有动那套AI生成的测试。直到一次全量回归，CI上红了三十多条，全是重复请求和并发扣减相关的用例。开发打开测试，发现断言里写着assert response["success"] is True，而新实现里，因为两阶段操作引入了异步状态，当库存充足但不是“立即可扣”时，接口会先返回success=False, status="PENDING"，等异步确认成功后再回调。从业务角度讲，“PENDING”也是最终会成功的一种中间状态；从接口角度讲，客户端的后续轮询机制本来就是按这种状态设计的。
换句话说：这次改动是符合需求的，但测试红了。因为测试断言绑定的不是业务规则（“不能超卖、不能重复购买”），而是AI当时从旧实现里反推出来的接口行为（“只要请求合法就返回success=True”）。
然后开发做了个很常见的决定：为了快速通过CI，直接把那三十多条用例的预期结果改成了success=True或status="PENDING"。半小时后，全绿。
这里最讽刺的是：在AI生成测试之前，这套逻辑的正确性靠代码评审和人工冒烟保障；在AI生成测试之后，大家都以为测试在保障正确性，实际上它只是把旧的、具体的行为固化成了新的、同样不一定对的预期。真正的“不能超卖”规则，从头到尾没有被自动验证过。它只是在评审时被人工看过一眼。
3.3 为什么人工review没能拦住
有人会问：AI生成测试，人工不是还要review吗？怎么会让这些明显没测到业务规则的用例混过去？
问得对。但实际review时，有一个心理陷阱：人会默认“测试这种机械活，AI已经做完了，我只需要扫一眼有没有明显错误”。你打开一个测试文件，看到四十多个def test_xxx，状态全是pass，覆盖率报告上写着“91%”，直觉上就会觉得“质量不错”。你不太可能逐条去质疑“这条用例到底有没有意义”。
AI生成的测试还有个特点：命名非常“工整”，结构非常“规范”。它不像新手写测试那样歪歪扭扭、一眼看出逻辑漏洞。它长得跟优秀工程师手写的一模一样——只是内容对不对，要细看才知道。这是最麻烦的地方：它没有让你觉得“这测试不对劲”的粗糙感，反而用精致的格式包装了空虚的断言。
我这几年做评审总结出来，人工review对AI测试的拦截率极低，除非你专门做一轮“断言审计”——把每条用例的断言拎出来，逐个问它“到底在验证哪条业务规则”。大部分团队没这个精力和耐心，于是问题就这样被流水线吞掉了。
4. AI写测试的边界：哪些活它干得漂亮，哪些活它根本不该碰
4.1 跑得漂亮的场景：纯函数、契约测试、边界扫描
不是要全盘否定AI写测试。我实际用下来，它确实有几类活干得非常漂亮，省了我大量时间。
- 纯函数测试：对于一个输入输出可以明确化的函数（比如日期格式化、金额分转元、JSON序列化等），AI生成测试的效率极高。它能把常见边界值、异常值、类型错误快速扫一遍，比如
NaN、None、空字符串、超大数。这类测试不需要业务判断，纯粹是对函数的属性做网格化验证。 - 契约测试（Contract Test）：在微服务场景里，服务之间的请求/响应结构是相对固定的。AI可以快速生成请求体/响应体的Schema校验测试，确保接口的字段类型、必填项、枚举值不会在重构中被意外破坏。这种测试的本质是“结构一致”，AI对这种结构模式非常擅长。
- 回归快照测试：对于“当前行为被认定为正确、任何改动都需要人工确认”的老系统，AI生成快照测试，记录下当前行为的全貌，之后任何改动导致快照变化都会红起来，逼着人去审视“这个变化是否有意为之”。虽然快照测试有争议，但在遗留系统维护场景里，它的价值远大于手写。
这些场景有一个共同点：不需要业务语义判断，或者业务语义已经被外部约束定义好了。AI只要忠实地把行为、结构、边界记录下来，就足够好用了。这也是我建议你优先让AI介入的区域。
4.2 碰不得的场景：核心业务规则、复杂状态机、跨模块共享逻辑
反过来，有几种测试，我强烈建议不要交给AI独立完成，至少不要让它决定断言内容。
第一种是核心业务规则测试。比如折扣计算、库存扣减、风控决策、权限判定。这些规则的价值在于“业务上正确”，而不在于“当前代码行为正确”。AI没有能力判断“这个规则在当前代码里实现错了”，它只会顺着代码写出一套自洽但不代表需求的断言。这种测试，只能由懂业务的人来写——或者AI写，但每一条都要拉上产品经理一起review。
第二种是复杂状态机测试。订单状态流转（待支付、已支付、已发货、已完成、已取消、退款中），状态之间的合法迁移是业务强约束。AI生成的测试往往只覆盖“正常路径”，对非法迁移的拦截、对并发状态的保护测试，会捕捉得很弱，而这些恰恰是最容易出线上事故的地方。
第三种是共享模块/公共库的测试。一个被几十个服务引用的工具函数，它的行为变更影响面极大。AI生成的测试往往是“局部视角”，它不知道上游依赖方对哪些行为有隐性期待。这种测试如果由AI来写，容易写出一套“自洽但和真实调用方期望不一致”的约束，导致将来改公共代码时，测试先跳出来阻碍合理改动。
我的原则很简单：AI可以当测试的“草稿生成器”，不能当“断言决定者”。结构、命名、初步覆盖它可以包办，但每一条断言背后都得有一个人来回答“为什么这个结果是正确的”。
5. 实测有效的四条应对策略，给每一个已经在用AI写测试的团队
5.1 先让AI回答“你要测什么”，再看“怎么写”
我调整了和AI协作的方式。以前我会直接说“帮我给这个函数写测试”，现在我会先发这么一段：
以下是需求文档和函数实现。请不要急着写测试代码。 先列出这个函数的业务规则清单，包括正常流程、异常流程、边界条件、隐含假设。 每一项都标注来源（需求文档里明确写了 / 从代码实现推断 / 我不确定）。 然后，请仅针对“来源为需求文档”和“你不确定”的项目，设计测试点。 对于“从代码实现推断”的项目，标注为“待人工确认”，不要写断言。这样一层过滤之后，AI生成的东西质量会明显上一个台阶。它不再是无脑补全，而是被迫先亮出自己的“业务理解”，再由人来判断理解对不对。测试代码的量会减少，但每一条都更接近“在验证规则”。
实际跑下来，效果立竿见影：AI从“测试工厂”变成了“测试讨论者”。它不再直接给你几十个用例，而是先给你一份清单，让你把不准的地方圈出来，然后它围绕你确认过的点去生成断言。这个过程中，人的心智负担大幅降低，但对最终测试质量的把控，反而提升了。
5.2 断言必须绑定业务锚点，不能只锚定实现
在AI生成的测试里，我会强制要求给自己加一道工序：对每一条断言标注“业务锚点”。就是说，打开一个测试方法，旁边必须有一行注释，说明“这个断言在验证哪一条需求”。
比如说，对于库存扣减，有效的断言注释是：
def test_deduct_stock_when_quantity_exceeds_stock(): # 业务规则：库存不足时，扣减必须失败，且不能修改库存量 result = stock_service.deduct(product_id=1, quantity=999) assert result.success is False assert stock_service.get_stock(product_id=1) == 10而无效的断言注释是AI默认的那种“覆盖库存不足场景”。这两种注释的区别决定了测试的维护价值：前者如果红了，你能立刻判断是代码改坏了还是需求变了；后者红了，你还得先花一小时研究代码逻辑。
这步单独靠AI做不到，它不知道业务锚点在哪里。但它可以帮助完成“初步标注”，然后由人来确认。我用了一个模板，每次要求AI按这个格式输出测试文件头：
# 业务规则编号：BR-001 # 规则描述：库存扣减不得出现负数 # 相关需求文档链接：...有了这个前提，后续任何一条断言红掉，团队都能快速定位到对应规则，而不是面对一堆自洽的数字发呆。
5.3 拒绝写死mock，用契约测试守住边界
AI特别喜欢mock。遇到Redis调用、数据库调用、第三方HTTP服务，它最省事的方案是直接mock掉。但mock有个致命问题：mock掩盖了真实依赖的行为变化。你以为测试还在守护边界，其实它守护的是“你脑子里想象的边界”。
我建议两条杠。第一，对于内部服务之间的调用，用契约测试替代mock。先定义好请求/响应体结构和错误码语义，然后让AI基于契约生成测试，而不是基于mock生成测试。第二，对于必须mock的外部依赖，mock的返回值不能由AI随意设定，必须由一个“契约基线数据集”来提供。也就是说，mock数据本身要能被追溯到一个真实的生产样例或一份显式的测试数据说明。
打个比方：以前你和某个服务对接，对方告诉你会返回{status: "SUCCESS"}。AI写测试时，会在mock里放一个{status: "SUCCESS"}，看起来没问题。但真实情况是，对方偶尔会返回{status: "FAIL", code: "LIMIT_EXCEEDED"}。这个现实世界的边界变化，mock测试是测不出来的。要真正确保你对“边界变化”免疫，唯一的办法是让一套契约测试在集成环境里跑起来，接受真实的返回值。
这个思路听起来重，但它能救命。至少，它不会让你在依赖方改接口时，被一条“mock里写死的SUCCESS”测试误导，以为自己的处理逻辑没问题。
5.4 测试评审要像代码评审一样严格，专门审“反断言”
我以前参加测试评审，多半是走个形式：看覆盖率、看有没有明显语法问题、看有没有跳过某些用例。现在我会专门安排一个环节，叫**“反断言检查”**。
做法很简单，抽几条AI生成的用例，做一次“脑内反向验证”：如果我把被测代码改成一段明显错误的实现，这条测试能不能发现？
比如，把get_discount_price改成永远返回原价，那组AI生成的测试能不能拦住？如果测试断言的是“输入100和None返回100”，又把SAVE10那组用例也断言80，是能拦住的。但如果有人改坏了SAVE前缀判断逻辑，只让SAVE10打折、其他SAVE前缀都打了9折，AI生成的测试里如果没有专门针对SAVE20的用例，就拦不住。
这种“反断言”审法特别耗精力，但它能让一个人快速识别出哪些用例是有业务价值的，哪些是纯摆设。我每次评审至少抽10%的AI测试做一遍反断言，坚持下来，团队对AI测试的信任度会回到一个理性的水平——不是全盘信任，也不是全盘怀疑，而是知道“哪些测试可以信，哪些测试只能当参考”。
6. 别把AI当测试工程师，要把它当结对编程的实习生
最后说说我自己的心态变化。我在项目里用AI写测试的初衷和很多人一样，是为了“提速”，把重复劳动甩给机器。但踩了几次坑、仔细看了几百条AI生成的测试之后，我的结论变了一点：AI是效率放大器，不是质量保险丝。它可以让一个理解业务的工程师写测试更快、更全面；但它也可以让一个不理解业务的工程师在十分钟内制造出一堆看起来很专业的假安全感。
我个人习惯的做法，是把AI当成一个“特别勤快、但不够懂业务、又总怕你失望”的实习生。它拿给你的东西，永远比手写快，永远包装得漂漂亮亮，但它不会主动告诉你“你这里逻辑有bug”“这个规则你实现了，但和需求文档不一致”。这不是它蠢，是它没有你的业务背景。所以每一次它把测试代码递过来，我都会留十五分钟，专门做一次“业务规则对上号”的检查，而不是直接复制进项目。
如果把时间轴拉长，我觉得测试行业的核心能力正在从“写代码”变成“定义什么是对的”。AI把“写”的体力活包办了之后，人需要把更多精力放在“定义正确性”上——说清楚业务规则、边界条件、异常语义，让AI在这些明确约束下做机械性的展开。谁定义得清楚，谁就能用好AI；谁只想把写测试这件事整个甩给AI，谁就会收获一堆漂亮又无用的绿点。
这个事儿，没有捷径。AI能帮你写出测试，但定义“什么是对的”，永远得靠人。
)
