一个上线三天后才发现的问题：优惠券在金额刚好等于门槛时不能叠加，测试时用的都是明显超过门槛的金额，没人试过相等的那一档。这类漏洞不是测得不认真，是测得太顺着功能的写法走。AI 在这件事上的价值很具体：它不会因为知道业务大概怎么跑，就跳过那些不常发生的分支。这篇讲清怎么把它用成一张不漏的网，以及哪些判断它给不了。
用例的价值在覆盖，不在条数
一份两百条用例的文档，如果一百八十条都在测正常下单，覆盖率可能还不如三十条精心设计的。测试的产出不是文档厚度，是有多少种失败方式被提前想到。人写用例的盲区很稳定：顺着主流程写，把异常当边角料，边界值凭感觉取。
模型恰好在这个盲区上有优势——它见过大量「系统在什么情况下出错」的描述，会主动往空值、超长、越权、重复提交这些方向想。这不是它更懂你的业务，是它没有你的路径依赖。
六步，从一段功能说明到可执行清单
把过程拆开，每一步的产出和坑都很具体：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 交底：功能说明、业务背景、已知限制 | 一份模型能读懂的输入 | 只给一句话需求，模型只能按通用电商或社交逻辑脑补 |
| 先要主流程用例 | 一条能跑通的正常路径 | 一上来要全部用例，主流程被异常用例淹没，不好排优先级 |
| 单独要边界与异常 | 边界值、空值、越界、超时、权限、并发、字符集七类清单 | 混在一轮里要，模型会挑好写的写，难的漏掉 |
| 让它标出容易漏但风险高的 | 一份按风险排序的候选清单 | 不要求标注，它会把所有用例写得一样重要 |
| 人工核对假设 | 一份删掉了脑补项的用例集 | 不核对，用例测的是模型想象出来的功能 |
| 定优先级、补预期结果、落库 | 可执行、可分级的测试清单 | 只写操作不写预期结果，执行的人无法判断通过与否 |
第三步是这套流程的核心。分轮要，比一次要全，效果好得多——每轮目标单一，模型不会为了凑数而稀释重点，你核对起来也快。
边界、异常、并发，三类最容易漏的
边界值的取法有规律：等于、刚好小于、刚好大于、空、零、负数、最大值、超长。金额、数量、时间、字符长度、文件大小，每一类数值型字段都该走一遍。这类用例人常常只取正常值和明显异常值，中间那一档最容易被跳过。
异常场景要按依赖去想：网络断了、接口超时、第三方返回错误码、数据库连接失败、权限不足、会话过期。并发则要问三个问题：同时提交两次会怎样、快速连点会怎样、两个用户同时改同一条记录会怎样。字符集这一类常被忽略：表情符号、零宽字符、从右到左的语言、超长文本、前后空格。
把这七类列成清单，每次让模型按清单逐项过，比笼统地说考虑异常情况可靠。这个思路和模型评估指标里的覆盖逻辑一致：先定义要覆盖哪些格子，再看每格有没有填上。
一句「不确定就标注」，能省掉一半返工
模型最大的问题是会替你补设定。功能说明里没写未登录用户能不能领券，它会按常见做法假设不能，然后生成一串基于这个假设的用例。这些用例看着合理，实际测的是一个不存在的规则。
解法是在提示词里写死一条：不要假设功能细节，凡是说明里没定义的行为，单独列出来让我确认。这一条能把脑补从藏在用例里，变成摆在清单上，核对成本降一个量级。同理，要求它给每条用例写预期结果，也能暴露假设——写不出预期结果的用例，通常意味着规则本身没定义清楚。
它列得出用例，排不出优先级
优先级判断，它给不了。模型能穷举可能出错的地方，不能判断哪个错了最要命。支付链路的千分之一和帮助页文案的千分之一，优先级差着几个数量级，而这个判断来自业务——这笔钱谁付、这个功能谁用、出了事谁承担。
三件事它替代不了。其一，业务理解——真正重要的场景往往来自对业务规则的理解，比如结算周期切换那天的特殊处理，模型不知道。其二，探索性测试——靠经验和直觉去乱点、去试探系统边界的那部分，给不了。其三，执行与判定——用例要人跑，结果要人判断这算不算通过。
用例也会过期，维护比生成更花时间
需求改了、接口变了，用例集如果不同步，测出来的通过就是假的。这类失效和数据漂移同构：参照系变了，旧结论就不再成立。定期拿新需求对照旧用例，能较快找出该删该改的部分，这件事让模型先过一遍再人工定，比自己从零翻一遍省力。
还有一层：只测熟悉路径的用例集，会像过拟合一样，在已知场景上表现很好，遇到没见过的组合立刻失效。判断一套用例好不好，不妨看它有多少条是「不看需求文档就想不到的」——这个比例，比总条数更能说明问题。
速查：测试用例的六步清单
- 先交底：功能说明、业务背景、已知限制
- 分轮要：主流程一轮，边界与异常单独一轮
- 按七类清单逐项过，别只说「考虑异常」
- 提示词里写死：不确定的行为单独列出待确认
- 每条用例都要有预期结果，优先级和风险判断由人定
