VA-01 · 验收测试用例生成

① 场景引入

一、这件事现在是什么样

验收与发布 · 真实业务触发

v3.4 的 8 条通过需求进入开发尾声。江晓的下一个身份是测试验收员 —— 公司没有 QA 岗，按惯例她要在发布前把功能过一遍。以前的「过一遍」是凭感觉点一点主流程，v3.3 那次「连锁反应式灾难」上线后她学乖了：影响 12 家客户的事故，复盘时第一条改进就是「验收没有覆盖异常分支」。这次 8 条需求，她需要至少能拿得出手的用例清单 ——但写用例的时间，和准备发布材料的时间，是同一块。

二、痛点 · 每条都有来源

1. 上线事故的形状：一行代码的变更踩了别人的线 —— 验收没覆盖异常分支是常见根因；「上线后 24 小时手机不能静音」是产品经理的自保实录
   依据：连锁反应式灾难上线判例：跨域限制只在生产环境生效导致数据服务失效 —— 需求评审时没拉出影响范围图，一行代码的变更踩了别人的线；「上线后 24 小时手机不要静音，你是第一责任人」是产品经理的自保实录
2. PRD 缺验收标准时研发估算偏差超 50% —— 反过来，验收标准不落到用例，就是写了也没人验：故事与用例之间缺一道翻译
   依据：需求评审的真实痛点：评审会变成产品经理单方面汇报、其他角色沉默或事后才提异议，导致开发阶段频繁返工；许多 PRD 缺少验收标准与非功能性要求，致使研发估算偏差超 50%
3. 中小企业「产品即测试」是常态 —— 用例生成的活是「扩张型」（AI 出清单、人跑测试），恰是无 QA 团队最缺的那双手
   依据：发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out ofScope）是对外交付的护身符

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 上线事故的形状：一行代码的变更踩了别人的线 —— 验收没覆盖异常分支是常见根因；「上线后 24 小时手机不能静音」是产品经理的自保实录
• PRD 缺验收标准时研发估算偏差超 50% —— 反过来，验收标准不落到用例，就是写了也没人验：故事与用例之间缺一道翻译
• 中小企业「产品即测试」是常态 —— 用例生成的活是「扩张型」（AI 出清单、人跑测试），恰是无 QA 团队最缺的那双手

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 主流程用例 · 每条需求的正向路径用户故事 → 操作步骤 → 预期结果 —— 三段式，跑测时照着点
2. 异常分支补全 · 找茬清单的落地边界/并发/超时/权限 —— DC-01 找出的每个异常生成至少一条用例
3. 历史事故回归· 疼过的必须再验上次事故的根因分支（跨域配置）生成回归用例 —— 疼过的地方测两遍
4. 环境矩阵 · 私有化与标准版两个版本的差异项生成对照用例 —— 华正们的环境和标准版不一样
5. 验收清单成册 · 发布日的脚本86条用例按模块分组、含记录栏 —— 跑一条勾一条，结果留档

要准备什么：PRD（终稿）用例的第一来源 —— 用户故事与验收标准需求清单（本迭代通过项）8 条需求逐条生成 ——一条不落DC-01 找茬报告的边界清单找出的边界与异常 —— 用例必须覆盖的高危区历史事故的改进项（如有）上次事故的根因分支 —— 本次必测项

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.0

最大差异点：不要求懂测试方法论。PRD 与需求清单扔进来 —— 用例按需求逐条展开、异常分支自动补全，跑测的脚本直接可用。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：验收用例册.xlsx 86 条用例 + 记录栏 + 分组
• 可派发清单：异常分支用例表.xlsx 找茬清单对应的用例 · 高危区全覆盖
• 可派发清单：回归用例清单.xlsx 上次事故根因分支的必测项 · 含验证位

这套东西不承诺什么：不做「自动执行测试」—— 用例是人跑的（点击、核对、记录）。也不做「代替验收签字」——通过与否的判定与签字权在产品与客户。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：驭数科技（虚构）验收准备日：v3.4 的 8 条通过需求进入开发尾声。公司没有 QA 岗，按惯例江晓要在发布前把功能过一遍 —— 以前的「过一遍」是凭感觉点主流程。v3.3 那次「连锁反应式灾难」上线后她学乖了：影响 12 家客户的事故，复盘第一条改进就是「验收没有覆盖异常分支」。

用例总数86 条 · 5 组主流程21 条 · 全跑回归用例6 条 · 上次事故根因结论私有化 3 条补齐后定稿

输入产品手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_PRD终稿（8条需求）.txt 用例的第一来源 —— 故事与验收标准v1.0 终稿 · 2026-08-22
• 02_DC-01边界与异常清单.xlsx 找茬找出的边界 —— 用例的高危区DC-01 产出 · 2026-08-20
• 03_v3.3事故复盘改进项.xlsx 疼过的地方 —— 回归用例的来源v3.3 复盘 · 2026-07
• 04_私有化环境差异清单.xlsx 双版本用例的对照原料实施交付组 · 2026-08
• 05_研发自测记录.xlsx 「研发自测过了就不用验」的检验原料谭锐提供的自测清单 · 2026-08-25

注意标橙色那一份 —— 03_v3.3事故复盘改进项.xlsx。它v3.3 复盘 · 2026-07，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

v3.4 的 PRD 终稿、8 条通过的需求清单、DC-01 的找茬报告都在这，还有上次事故的复盘改进项，帮我出一份验收用例册。

8 条需求每条先出主流程用例：步骤、预期结果，我拿着就能点；

找茬报告里的边界和异常，每项至少生成一条用例 —— 上次就是死在没人测的分支上；

上次事故的根因分支帮我生成回归用例 —— 疼过的地方这次必须再验；

私有化和标准版的差异项单独拉一组对照用例；

最后按模块分好组、留好记录栏 —— 发布那天我跑一条勾一条。复制

短是因为「三段式用例结构、异常分支补全规则、回归用例策略」都在能力包里。产品经理只要把 PRD 和找茬报告扔进来。

触发8 条需求开发尾声 vs 产品即测试的现实

没有 QA 的公司 —— 用例册就是那道像样的闸门

江晓把 PRD、找茬边界清单、事故改进项、环境差异、研发自测记录全部扔进来 —— 用例的生成不是从零写，是把已有资产翻译成可执行的核验步骤。

第 1 步 · 主流程用例 · 11 个故事 21 条

每个故事至少一条正向路径 —— 三段式照着点

第 2 步 · 异常分支用例 · 36 条高危区

找茬清单的边界 × 环境差异 —— 事故生长的土壤

第 3 步 · 回归用例 · 上次疼过的地方

跨域配置的根因分支 —— 三条必测

第 4 步 · 环境对照用例 · 私有化的 11 条

44 家私有化客户的行为差异 —— 双版本各跑一遍

对照项标准版私有化用例数权限模型两级架构跑 1 遍三级架构跑 1 遍8文件保留 72 小时对象存储验证本地存储验证3环境对照 11 条全部是研发自测的盲区 —— 但其中 3 条（三级架构的权限组合）依赖 PRD 3.2 补丁的最终确认（DC-03 在途）—— 这 3 条今天还写不完整。

第 5 步 · 用例册成册 · 发布日的脚本

分组 × 记录栏 × 优先级 —— 跑一条勾一条

不讲省了多久 · 讲少了几个隐患、沉淀了什么

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

验收测试用例生成 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

acceptance-cases.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是产品手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁VA-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_PRD终稿（8条需求）.txt 用例的第一来源 —— 故事与验收标准
• 02_DC-01边界与异常清单.xlsx 找茬找出的边界 —— 用例的高危区
• 03_v3.3事故复盘改进项.xlsx 疼过的地方 —— 回归用例的来源
• 04_私有化环境差异清单.xlsx 双版本用例的对照原料
• 05_研发自测记录.xlsx 「研发自测过了就不用验」的检验原料

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

v3.4 的 PRD 终稿、8 条通过的需求清单、DC-01 的找茬报告都在这，还有上次事故的复盘改进项，帮我出一份验收用例册。

8 条需求每条先出主流程用例：步骤、预期结果，我拿着就能点；

找茬报告里的边界和异常，每项至少生成一条用例 —— 上次就是死在没人测的分支上；

上次事故的根因分支帮我生成回归用例 —— 疼过的地方这次必须再验；

私有化和标准版的差异项单独拉一组对照用例；

最后按模块分好组、留好记录栏 —— 发布那天我跑一条勾一条。复制

为什么这么短就够了：短是因为「三段式用例结构、异常分支补全规则、回归用例策略」都在能力包里。产品经理只要把 PRD 和找茬报告扔进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• VA-01_验收用例册.xlsx 正式件本体 · 86 条用例 + 记录栏 + 分组
• VA-01_异常分支用例表.xlsx 找茬清单对应的用例 · 高危区全覆盖
• VA-01_回归用例清单.xlsx 上次事故根因分支的必测项 · 含验证位

Skill 里固化了什么：从事故复盘里「想起」了必须测的分支该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：PRD（终稿）用例的第一来源 —— 用户故事与验收标准需求清单（本迭代通过项）8 条需求逐条生成 —— 一条不落DC-01 找茬报告的边界清单找出的边界与异常 —— 用例必须覆盖的高危区历史事故的改进项（如有）上次事故的根因分支 —— 本次必测项

人工边界：不做「自动执行测试」—— 用例是人跑的（点击、核对、记录）。也不做「代替验收签字」—— 通过与否的判定与签字权在产品与客户。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

验收与发布 · 产出即下一步输入

VA-02 · 发布检查清单执行留痕 — 「连锁反应式灾难」的复盘第一条：回滚预案没有 · 检查清单的价值不在列出来，在逐项核过并留下痕迹 查看 →VA-03 · 事故复盘初稿 — 事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。