原创内容，未获授权禁止转载、转发、抄袭。

拿到一份 PRD 后，测试人员通常要完成两次转换：先把产品描述拆成业务规则和测试点，再把测试点写成带前置条件、步骤、预期和优先级的测试用例。直接让 AI “根据 PRD 生成用例”，这两次转换会混在一起。需求中没写清楚的规则可能被悄悄补全，通用边界场景大量涌入，最终得到几十条格式整齐却无法执行的用例。更麻烦的是，问题往往要到执行阶段才暴露：前置数据无法准备，预期结果不能判定，失败后是否回滚也没人说得清。

我把这项工作拆成两个 Codex Skill：PRD Test Analyzer 负责读懂需求并建立测试范围，Testcase Writer 负责把确认后的测试点展开为 Markdown 用例。中间保留一次人工评审，让产品规则、推断项和待确认问题在写用例前暴露出来。下面使用一份虚构的优惠券领取 PRD 演示完整过程，文中的 Skill、接口、用户和业务数据均已脱敏。

为什么拆成两个 Skill

两个 Skill 的输入和责任边界不同：

PRD / 原型 / 截图
        |
        v
PRD Test Analyzer
        |
        | 模块、需求点、需求描述、测试点
        v
人工确认需求与测试范围
        |
        v
Testcase Writer
        |
        | Markdown 用例
        v
用例评审与执行

PRD Test Analyzer 会检查功能、权限、安全、性能、兼容性、体验和异常处理，但不会替代产品决策。遇到描述含糊的地方，它应该使用可观察行为表达，并标记待确认项。Testcase Writer 不再重新理解 PRD，只消费已经确认的测试点，这样能减少生成用例时擅自扩需求或遗漏原始测试意图。

这条分界也方便定位问题。如果测试场景漏了，应回到 Analyzer 的输出；如果场景存在但步骤无法执行，则调整 Writer 的规则，不需要反复重写一条巨型提示词。

安装 Skill

公开版保留下面这些文件：

shared_skills/
├── prd-test-analyzer/
│   ├── SKILL.md
│   └── agents/openai.yaml
└── testcase-writer/
    ├── SKILL.md
    └── agents/openai.yaml

下载压缩包并解压后，个人使用时可以复制到个人 Skill 目录；团队共享时则放进代码仓库的 .agents/skills/：

unzip prd-test-skills-public.zip -d prd-test-skills-public
mkdir -p ~/.agents/skills
cp -R prd-test-skills-public/{prd-test-analyzer,testcase-writer} ~/.agents/skills/

安装后新建 Codex 任务，再通过 $prd-test-analyzer 和 $testcase-writer 调用。Skill 的 description 要写清楚触发条件，因为 Codex 会据此判断何时使用它；具体项目的测试命令、目录和数据规则仍适合放在仓库 AGENTS.md 中。

准备一份可验证的 PRD

演示需求是“优惠券领取”，里面保留了两处未定义信息，用来观察 Skill 是否会替产品做决定：

# 优惠券领取 PRD

- 已登录用户可以领取优惠券；未登录用户点击领取时，页面提示“请先登录”，确认后进入登录页。
- 活动进行中且库存大于 0 时，按钮显示“立即领取”。
- 同一用户在同一活动中只能领取一张优惠券。
- 领取成功返回 `COUPON_RECEIVED`，按钮更新为“已领取”。
- 重复领取返回 `ALREADY_RECEIVED`，库存不得再次扣减。
- 库存不足返回 `SOLD_OUT`，页面提示“优惠券已领完”。
- 高并发领取时，库存不得为负数，也不得超发。
- 领取记录创建后，通过异步消息写入用户券包，正常情况下 5 秒内可见。
- 消费失败时系统自动重试，但 PRD 未说明最大重试次数和最终失败提示。

真实项目中，输入可以是本地 Markdown、在线文档、原型链接或截图。在线 PRD 需要登录时，应使用经过授权的连接器或浏览器会话；没有权限就停下来申请授权，不能根据页面标题或历史经验补写正文。截图中的批注、弹窗和状态图也属于需求证据，读取时不要只抓可复制文本。

第一步：用 PRD Test Analyzer 提取测试点

调用时把输入位置、输出范围和推断规则说清楚：

$prd-test-analyzer

完整阅读 prd_skill_practice/coupon_prd.md，提取模块、需求点、需求描述和测试点。

要求：
- 明确区分 PRD 已定义规则和待确认项
- 覆盖正常、异常、边界、并发与异步失败
- 测试点必须说明可观察结果
- PRD 未定义的错误文案和重试次数不得自行补全
- 返回原始 Markdown

Analyzer 输出了 3 个需求点、11 条测试点，完整内容如下：

## 模块：优惠券领取

## 需求点1：登录状态校验
  需求描述：已登录用户可以发起领取；未登录用户点击“立即领取”时提示“请先登录”，确认后进入登录页。
  测试点：
  1. 已登录且活动可领取时，点击“立即领取”能够发起领取请求。
  2. 未登录时点击“立即领取”，展示“请先登录”，确认后进入登录页。
  3. 登录会话在点击前失效时，领取接口拒绝请求，页面引导重新登录且不扣减库存。

## 需求点2：单用户限领与库存控制
  需求描述：活动进行中且库存充足时，每个用户只能领取一张；重复领取和库存不足必须返回明确结果，高并发下不得重复发券、超发或出现负库存。
  测试点：
  1. 首次领取成功，接口返回 `COUPON_RECEIVED`，生成一条领取记录，库存减 1，按钮更新为“已领取”。
  2. 同一用户重复领取，接口返回 `ALREADY_RECEIVED`，领取记录和库存均不再变化。
  3. 库存为 0 时领取，接口返回 `SOLD_OUT`，页面提示“优惠券已领完”，不生成领取记录。
  4. 库存为 1 时由多个不同用户并发领取，只允许一人成功，最终库存为 0 且只生成一条领取记录。
  5. 同一用户并发提交多个领取请求，只允许一次成功，库存只减 1，用户只获得一张券。

## 需求点3：异步写入券包
  需求描述：领取记录创建后通过异步消息写入用户券包，正常情况下 5 秒内可见；消费失败后自动重试，但重试上限和最终失败提示尚未明确。
  测试点：
  1. 领取成功后 5 秒内，用户券包出现对应优惠券，券实例与活动、用户和领取记录一致。
  2. 注入一次消费失败后，消息重试成功，券包最终只写入一张券。
  3. 持续消费失败超过 5 秒时，记录实际状态、重试次数和页面表现，将最终失败策略标为待确认，不擅自断言错误文案。

这一阶段我会重点检查三件事：每条结论能否在 PRD 中找到依据，推断项是否符合当前模块，以及测试点有没有落到数据和副作用。比如“重复领取失败”不能只验证错误码，还要确认库存、领取记录和消息都没有再次变化。

Analyzer 的覆盖清单比较全面，也可能带来过度扩展。一个简单表单不需要机械塞入所有浏览器、性能和安全场景；保留与需求风险有关的内容，删除无法说明测试目的的通用条目。待确认问题不能直接交给 Writer，否则只会得到一条无法判定通过或失败的“用例”。

人工确认：先补规则，再写用例

针对异步消费持续失败的问题，演示项目补充了下面的产品结论：

消费失败后最多重试 3 次。重试仍失败时，将领取记录更新为 ISSUE_FAILED，恢复已扣减的库存，不写入用户券包；用户再次进入活动页时显示“领取失败，请重试”。

因此，最后一条测试点改为：持续消费失败并完成 3 次重试后，领取记录为 ISSUE_FAILED，库存恢复，券包中没有对应优惠券，页面提示“领取失败，请重试”。这条规则有了可准备的条件和可观察的结果，才可以进入 Testcase Writer。真实项目中如果暂时拿不到结论，就让问题停留在待确认清单中，不生成正式用例。

第二步：用 Testcase Writer 展开用例

确认后的完整测试点可以直接作为 Writer 的输入：

$testcase-writer

使用上一步经人工确认的完整 Markdown，逐条生成可执行测试用例。

要求：
- 保留模块和需求点分组
- 每条用例包含前置条件、测试步骤、预期结果和优先级
- 默认一条步骤对应一条预期，复杂场景拆成多条用例
- 不补写输入中没有定义的产品规则
- 返回原始 Markdown，生成后结束

Writer 会把“测试意图”转换成“执行记录”。本次生成的 11 条用例如下：

# 优惠券领取

## 登录状态校验
### 验证已登录用户发起领取
- **前置条件**: 用户已登录，活动状态为进行中，库存大于 0，用户未领取过该活动优惠券。
- **测试步骤**: 1. 在优惠券中心点击“立即领取”。
- **预期结果**: 1. 系统发起当前活动的领取请求，且请求携带当前测试用户身份。
- **优先级**: High

### 验证未登录用户领取跳转登录页
- **前置条件**: 用户未登录，活动状态为进行中且库存大于 0。
- **测试步骤**: 1. 点击“立即领取”，在“请先登录”提示中确认。
- **预期结果**: 1. 页面展示“请先登录”并在确认后进入登录页，不生成领取记录且库存不变。
- **优先级**: High

### 验证领取前登录会话失效
- **前置条件**: 页面已打开，测试用户会话已在服务端失效，活动库存大于 0。
- **测试步骤**: 1. 点击“立即领取”。
- **预期结果**: 1. 领取请求被拒绝并引导重新登录，不生成领取记录且库存不变。
- **优先级**: High

## 单用户限领与库存控制
### 验证首次领取成功
- **前置条件**: 用户已登录，活动进行中，初始库存为 10，用户未领取过该优惠券。
- **测试步骤**: 1. 点击“立即领取”并查询领取记录与活动库存。
- **预期结果**: 1. 接口返回 `COUPON_RECEIVED`，新增一条领取记录，库存变为 9，按钮更新为“已领取”。
- **优先级**: Highest

### 验证同一用户重复领取
- **前置条件**: 用户已领取当前活动优惠券，记录当前库存和领取记录数量。
- **测试步骤**: 1. 再次调用当前活动的领取接口。
- **预期结果**: 1. 接口返回 `ALREADY_RECEIVED`，库存和领取记录数量均保持不变。
- **优先级**: Highest

### 验证库存为零时领取
- **前置条件**: 用户已登录且未领取，活动进行中，库存为 0。
- **测试步骤**: 1. 点击“立即领取”。
- **预期结果**: 1. 接口返回 `SOLD_OUT`，页面提示“优惠券已领完”，不生成领取记录。
- **优先级**: Highest

### 验证最后一张券的并发领取
- **前置条件**: 活动进行中且库存为 1，准备 20 个均未领取的测试用户。
- **测试步骤**: 1. 使用 20 个测试用户并发调用领取接口，完成后查询库存和领取记录。
- **预期结果**: 1. 只有一个请求成功，最终库存为 0，且只新增一条领取记录。
- **优先级**: Highest

### 验证同一用户并发重复领取
- **前置条件**: 活动进行中且库存充足，测试用户未领取过该优惠券。
- **测试步骤**: 1. 使用同一测试用户并发发送 20 个领取请求，完成后查询库存和领取记录，并在 5 秒内轮询券包。
- **预期结果**: 1. 只有一个请求成功，库存只减 1，只生成一条领取记录，且券包中只出现一张用户券。
- **优先级**: Highest

## 异步写入券包
### 验证券包在五秒内可见
- **前置条件**: 用户首次领取成功，记录领取完成时间和领取记录标识。
- **测试步骤**: 1. 在 5 秒超时范围内轮询用户券包。
- **预期结果**: 1. 5 秒内出现一张对应优惠券，活动、用户和领取记录标识均匹配。
- **优先级**: High

### 验证消费失败一次后的重试幂等性
- **前置条件**: 消费者支持测试故障注入，配置首次消费失败、后续恢复，用户未领取过该券。
- **测试步骤**: 1. 完成领取并等待消息重试后查询券包和消费记录。
- **预期结果**: 1. 消息重试成功，券包只生成一张券，不存在重复消费产生的第二张券。
- **优先级**: Highest

### 验证消费持续失败后的补偿
- **前置条件**: 消费者支持持续失败注入，用户首次领取成功，记录领取前库存。
- **测试步骤**: 1. 保持消费者持续失败，等待 3 次重试完成后查询领取记录、库存和券包，再重新进入活动页。
- **预期结果**: 1. 领取记录为 `ISSUE_FAILED`，库存恢复到领取前数值，券包中没有对应优惠券，页面提示“领取失败，请重试”。
- **优先级**: Highest

这里刻意保持一条动作对应一条预期，失败时容易判断是哪项断言不成立。端到端交易确实无法拆开时可以使用多个编号步骤，但步骤 1 必须对应预期 1，不能把页面、接口、数据库和日志四层结果挤进一句“领取成功”。

并发领取、消息重试和权限失效会影响库存或用户资产，因此优先级较高；最终级别仍要结合项目损失和发布范围由测试人员确认。

这套流程仍然需要测试人员把关

AI 能加快需求拆解和格式转换，但它看不到没有提供的会议结论，也无法替团队定义性能阈值、兼容范围和最终失败策略。PRD 写得含糊时，最有价值的输出往往是一条带证据的待确认问题，而不是一百条假设需求成立的测试用例。

最终还要抽查测试点到用例的语义映射，确认前置数据可准备、动作可执行、预期可观察，并检查失败后不应发生的写库、扣库存、发消息等副作用。

我会把人工检查放在两个位置：Analyzer 输出后确认业务规则和测试范围，Writer 输出后确认数据、步骤、预期与优先级。执行阶段再根据真实接口、数据库、消息和页面证据判断结果。这样 Codex 负责整理和展开，测试人员保留需求解释权与质量结论。

总结

PRD Test Analyzer 和 Testcase Writer 把一项容易失控的长提示词任务拆成了两个可评审步骤。前者解决“应该测什么”，后者解决“怎样执行和记录”，最终交付一份可以继续评审和维护的 Markdown 用例。先用小需求跑通这条链路，记录遗漏和误判，再持续修改 Skill，比追求一次生成完整用例库更可靠。