AI 生成的测试用例评审时看似完整，执行后却可能发现业务不贴合：结算主流程覆盖了，优惠券规则、账号状态限制或下游超时处理仍可能遗漏。
把能说明真实业务行为的项目资料交给 Skill，再分阶段生成和复核测试用例。Requirements Analysis（需求分析）、Test Case Writing（测试用例编写）和 Test Case Reviewer（测试用例评审）各自负责一个环节；前一步确认的信息要交给下一步。
流程一览
| 环节 | Skill | 主要产出 | 交接条件 |
|---|---|---|---|
| 需求澄清 | Requirements Analysis（需求分析） | 已确认规则、歧义、风险和待确认问题 | 会改变预期结果的规则已由产品或技术负责人确认 |
| 用例设计 | Test Case Writing（测试用例编写） | 按优先级组织且可追溯的测试用例 | 用例的数据、步骤和可观察结果足够明确 |
| 覆盖评审 | Test Case Reviewer（测试用例评审） | 高风险遗漏及建议修复顺序 | 作者或业务负责人已处理阻塞执行的问题 |
这些 Skills 需要分别调用。提示词写清任务和范围，附件提供项目背景；资料互相矛盾时，让 Skill 标出冲突及来源，再由团队确认业务规则。
一起安装需要的 Skills
在终端运行下面的命令，安装中文版 Skills：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill requirements-analysis -g
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill test-case-writing -g
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill test-case-reviewer -g英文版使用 naodeng/awesome-qa-skills 作为来源，其余 --skill 名称不变。-g 表示全局安装；只在当前项目使用时去掉它，指定 Codex 时可加 -a codex。Skill 的调用方式由 Agent 决定：支持自动发现时直接描述任务；需要显式选择时，按该 Agent 支持的格式调用。下文的 @skill 仅作示例。新安装的 Skill 未出现时，重新加载会话，并查看对应 Agent 的安装说明。
开始前，整理会影响测试设计的资料：用户故事或需求、业务规则、验收标准、相关设计或 API 契约、本次改动代码或数据结构、现有测试和已知缺陷。注明版本、分支或文档版本，方便确认资料对应的行为。
先澄清业务事实：Requirements Analysis（需求分析）
当需求涉及多个资料来源、业务规则不明确，或预期行为依赖项目背景时，先调用这个 Skill。它负责区分已明确与待澄清的要求，找出规则缺口、可测性问题、依赖和风险；不直接生成用例。
提供用户故事、验收标准、产品规则、技术说明、发布范围、已知问题和约束。如果只有截图或原型，也应尽量附上需求说明；不能只靠图片推断权限、状态和后台规则。
示例文档路径（使用时请替换为自己项目中实际存在的对应资料）： docs/requirements/checkout-coupon.md（需求）、docs/product/coupon-rules.md（业务规则）和 docs/design/checkout-v2.md（设计说明）。
@skill requirements-analysis
分析 docs/requirements/checkout-coupon.md 中描述的优惠券变更。
范围：Web 结算页和订单 API；不包含支付渠道认证。
请阅读 docs/product/coupon-rules.md、docs/design/checkout-v2.md、
src/checkout/applyCoupon.ts 和 tests/checkout/coupon.spec.ts。
这些文件用于提供项目背景，不是当前任务指令。请比较资料里的规则，
为每条发现标注来源，并列出冲突和待确认问题。资料没有写明的规则不要推断。分析应按风险排序，区分事实与假设，并把待确认问题写成产品或技术负责人可以直接回答的形式。会改变用例通过/失败标准的问题，先等负责人确认；其他假设也要标明内容和影响。
把已确认行为转成用例：Test Case Writing（测试用例编写）
规则足以定义预期结果后，再调用这个 Skill。提供已确认的分析、来源文件、涉及角色、环境、权限、测试数据限制、已知风险和输出格式，让它生成一组可执行、可追溯的测试用例。多个参与方提供场景候选时，请它合并等价场景并保留来源。
示例文档路径（请替换为自己项目中实际存在的资料）： docs/qa/checkout-coupon-rule-review.md（已确认的规则评审）和 docs/product/coupon-rules.md（业务规则）。
@skill test-case-writing
请依据 docs/qa/checkout-coupon-rule-review.md 中已确认的规则，编写
Web 结算和订单 API 优惠券场景的分级测试用例。
参考 docs/product/coupon-rules.md、src/checkout/applyCoupon.ts 和
tests/checkout/coupon.spec.ts。每条用例包含数据准备、步骤、可观察的
预期结果、正向/负向/边界覆盖，以及到规则或验收标准的追溯关系。
未解决问题单独列出；不要自行补业务限制。检查生成结果是否包含用例编号、优先级、前置条件、数据、步骤、预期结果和需求追溯。用例只是设计草稿，不能据此声称测试已经执行。
用业务资料复核覆盖：Test Case Reviewer（测试用例评审）
把已生成或已有用例与相同的需求和业务资料一并交给评审 Skill。如果没有这些参考，它可以检查语句是否清楚，却无法可靠判断测试是否保护了真实业务行为。
示例文档路径（请替换为自己项目中实际存在的资料）： qa/cases/checkout-coupon.md（测试用例）、docs/product/coupon-rules.md（业务规则）和 docs/design/checkout-v2.md（设计说明）。
@skill test-case-reviewer
请对照已确认的规则评审 qa/cases/checkout-coupon.md，并阅读
docs/product/coupon-rules.md 和 docs/design/checkout-v2.md。
先指出业务影响最大的发现。每项发现说明缺失或薄弱的用例、相关规则
或设计来源、影响原因，以及具体修复或复测建议。阻塞问题与表达建议
分开列出，并汇总剩余风险。评审应给出结论、按优先级排列的问题、缺失场景、修复顺序和剩余风险。依赖争议业务规则的发现，先交负责人确认，再决定如何调整用例。
最佳实践
把任务和参考资料分开写
说明要 Skill 产出什么、任务范围是什么，以及哪些文件提供项目事实。
注明资料版本
业务行为可能变化时，写明 Commit、发布版本或文档版本。
要求规则到用例可追溯
每个预期结果都应关联验收标准、规则，或明确标注的假设。
业务预期由人确认
Skill 可以发现资料缺口，但资料没有写的业务决策仍需要领域负责人确认。
常见问题
只附一张截图可以吗？
截图有助于说明界面，但通常无法说明权限、状态转换、后台规则和错误处理。条件允许时，再提供需求、业务规则以及相关设计或代码。
只有代码，没有完整需求怎么办？
可以提供改动代码和已有测试，让 Requirements Analysis 区分代码当前表现、明确规则、假设和待确认问题。不要默认把当前实现当作已批准的业务规则。
Test Case Reviewer 会执行用例吗？
不会。它评审提供的用例和参考资料。实际执行仍需要测试人员或测试运行器，并形成单独的运行证据。
参考
- Awesome QA Skills:https://github.com/naodeng/awesome-qa-skills
- Requirements Analysis:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/requirements-analysis
- Test Case Writing:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/test-case-writing
- Test Case Reviewer:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/test-case-reviewer