AI 写框架用例·场景与阶段
让系统性测试从「太贵没人写」变可落地——但不是所有东西都值得为它买单
速查
- 是什么：AI 在懂需求/功能/白盒前提下，按五层 + 提示词工作流（plan→评审→TDD→自测报告）写框架测试代码（Vitest/Cypress/Playwright），进 git 当回归门禁
- 就该用它的场景：系统性覆盖（核心/安全类）、回归网、TDD 新功能、重构保行为、bug fail 用例、CI 长期门禁
- 适合阶段：开发全程（从 plan 到 CI 都在）
- 核心观点：AI 让系统性测试从「太贵没人写」变可落地；但不是所有东西都值得为它买单
- AI 专属陷阱：AI 会写「看着覆盖、实则不验证」的假绿用例 → 反向验证 + 人评审粒度是防线
AI 写用例改变了什么
精确到 case 的五层测试、副作用分支逐个列、安全类 100%、反向验证——这套纪律一直都对，问题从来不是「该不该做」，而是「太贵，没人有时间写」。于是团队长期欠着技术债，覆盖率虚低，回归靠人肉。
AI 把这件事的成本打下来了。在它懂需求、懂功能、能读白盒代码的前提下，按提示词工作流，它能把系统化用例真正写出来：plan 阶段精确到 case，TDD 先 fail 再实现，逐层推进，最后生成自测报告。「系统性测试」从奢侈品变成日用品——这是 AI 写用例真正的价值。
但我要立刻泼一盆冷水：这不意味着所有东西都该让 AI 写成框架用例。 下面先说哪些场景就该用它，再说为什么不能滥用、以及怎么防 AI 写假绿。
就该用 AI 写框架用例的场景
系统性覆盖：核心与安全类
核心业务链路、安全类代码（鉴权/数据权限/token/登录限制），需要的是严谨、不漏分支的覆盖。安全类要 100%/100%，业务核心 ≥85%/≥75%。这种「把每个分支、每个副作用、每个反例都列到」的活，正是 AI + 五层 + 精确到 case 工作流最擅长的——人来写又对又全但太累，AI 来写能做到同样的严谨度。
回归网：每个 bug 的永久守护
所有缺陷的复现用例永久进套件构成回归网。让 AI 把每个修过的 bug 写成 fail-first 用例（先复现 fail，修完转绿），CI 天天跑，同类问题再出现自测阶段就拦掉。回归网的价值是「长期反复跑」，正好是框架 spec 的主场。
TDD 新功能：先 fail 再实现
新功能从零开始，让 AI 走 TDD——每个 case 先写 fail 测试、跑确认 fail、再写实现、再跑确认 pass。提示词里显式写死这个顺序（提示词 2 的铁律），否则 AI 默认会先写实现再补「正好能过」的测试，等于没 TDD。
重构保行为：复用既有用例当安全网
行为不变的代码调整，靠既有各层用例验证「改完行为没变」。让 AI 在重构前确认相关用例齐全、绿着，重构后重跑——一旦变红就说明行为被改动了。plan 里标注新增/调整的 case 数。
bug fail 用例：配合 bug-fail-first
跟回归网配套。修 bug 必须先有复现的 fail 用例，让 AI 选合适的层（优先低层 L1>L2>L4>L5，能 L1 别 L5）写复现用例，确认 fail，再修，再确认 pass。该用例永久保留，禁删禁 skip。
CI 长期门禁：确定、可重复、卡红
CI 需要的是确定、可重复、能一键跑成百上千次的回归网——这是框架 spec 的独占地盘（MCP 做不到，见 MCP 边界）。让 AI 把核心用例写成 spec 进 CI，不达标就卡红，挡住覆盖率回退。
各阶段怎么用
| 阶段 | AI 写用例做什么 | 对应提示词 |
|---|---|---|
| plan | 精确到 case 写测试计划（五层、副作用分支、反例） | 提示词 1 + 评审提示词 6 |
| 编码 | TDD 逐层实现（先 fail 再实现） | 提示词 2 |
| 自测 | 跑五层 + 覆盖率 + 反向验证 + 生成报告 | 提示词 3 |
| 修 bug | fail-first 复现用例 | 提示词 5 |
| CI 门禁 | spec 进回归网，覆盖率卡红 | — |
为什么不是所有东西都值得为它买单
「成本降了」不等于「无脑全上」。框架用例有它的维护成本——spec 要跟着代码改，写多了反而拖累迭代。我的取舍：
- 值得：长期反复跑的（回归网）、严谨度要求高的（核心/安全类）、稳定可复现的。这些一次写好，CI 天天回本。
- 不值得：一次性验证（→ 用 MCP 说句话就跑，别写 spec）、靠人判断的（→ 手工，框架断言不出「好不好用」）、还在频繁改的早期功能（spec 写完就过时，纯浪费）。
一句话：框架用例是给「值得长期守」的东西用的。 临时的、主观的、易变的，硬写成 spec 是给自己挖维护坑。这正是三方式平权的意义——AI 写用例有它的最优场景，但它治不了探索性，也不该抢临时验证的活。
AI 专属防线：揪出假绿用例
这是用 AI 写用例最大的陷阱，必须单独拎出来讲：AI 很擅长写「看着覆盖、实则不验证」的假绿用例。
典型假绿长这样：
mount了组件，但根本没断言渲染结果，覆盖率却涨了。- 调了接口只
expect(res.status).toBe(200)，没验业务语义（数据对不对、副作用生没生效）。 expect(true).toBe(true)式的凑数，或断言写得永远成立。
这些用例覆盖率好看、CI 全绿，实则一个 bug 都拦不住。两道防线缺一不可：
- 反向验证（机器防线）：故意往被测逻辑打一个 bug → 对应用例必须 fail；故意删一个安全类用例 → 覆盖率必须掉。纹丝不动就是假绿。 自测报告里必须有反向验证记录（安全类建议 ≥2 条）。
- 人评审粒度（人的防线）：PR review 时人去看「这个用例到底验了什么」——是不是只测了 200 响应、漏了业务语义？改了接口签名测试动没动？这道关 AI 自己把不了，必须人来。
别让 AI 自己验自己
AI 写的用例，反向验证可以让 AI 执行（打 bug → 跑 → 看 fail），但「这个用例够不够、有没有假绿」的最终判断必须是人。让 AI 自己声明「我的用例很全很好」，等于没有防线。准入审查（QA 抽查复现）和 PR review（人看粒度）就是为这道防线存在的。
下一步
- 原则与方法：反向验证、五层、提示词工作流的完整说明
- MCP·AI 跑 e2e·场景与阶段：一次性验证用 MCP，别写 spec
- 手工·场景与阶段：主观判断用手工，框架断言不出来
- 参考：提示词工作流速查 + 五层速查