从 PRD 到 XMind：开发和测试如何用 AI Skill 快速生成可导入的测试用例
拿到一份 PRD，测试工程师通常要做三件事：找出功能模块，补齐测试场景，再把结果整理成团队能评审的用例结构。开发工程师也需要同一份结构，只是关注点会更靠近接口、状态、数据约束和异常处理。
这中间最容易丢掉的不是“正常流程”，而是那些藏在句子里的限制：字段长度的上下限、重复提交时的行为、不同角色看到的数据、订单状态不能倒退的规则。prd-to-xmind-testcases 这个 Codex Skill 做的事情很具体：读取 PRD，把需求拆成 XMind 可以导入的 Markdown 测试用例大纲。
它不会替团队签字，也不会自动产出一个原生 .xmind 文件。它更像一个把需求初稿变成评审底稿的助手，最终的业务判断仍然要由开发和测试一起确认。
先看清楚它能做什么
Skill 支持三种输入方式：
- 从 Skill 自带的
requirements/目录读取.docx、.pdf、.txt或.md需求文件；目录里有多个文件时，先列出候选让人选择。 - 直接提供任意本地文件的绝对路径。
- 把 PRD 正文直接粘贴到对话中。
默认输出是 Markdown 文件。Markdown 的标题和列表会映射为 XMind 节点，所以它交付的是“可导入的测试用例大纲”，不是测试执行平台里的完整测试单，也不是已经执行过的自动化脚本。
默认通用测试规范会考虑：正向、反向/异常、边界值、等价类、场景法，以及需求涉及状态机时的状态与流程。如果需求明确提出接口测试，Skill 会补充参数校验、响应和错误码、鉴权、权限、幂等、并发等维度；如果明确提出性能测试，则会补充基线、稳态、峰值、长时间稳定性、瓶颈和降级等维度。
安装和第一次调用
这是一个目录型 Skill，关键文件是根目录下的 SKILL.md，references/ 目录里的规范文件也要一起保留。下载仓库后，将完整目录放到 Codex 用户级 Skill 目录：
~/.codex/skills/prd-to-xmind-testcases/
├── SKILL.md
├── references/
└── requirements/
安装完成后重启 Codex，或者开启一个新任务，让它重新发现用户级 Skills。源仓库在 GitHub：
https://github.com/Rose-711/prd-to-xmind-testcases
最快的调用方式是直接给出 PRD 的绝对路径，并把输出位置写清楚：
根据 /Users/me/docs/order-prd.md 生成可导入 XMind 的测试用例，
并保存为 /Users/me/docs/order-testcases.md。
需求比较复杂时，我更推荐先让它只做一次模块识别：
读取 /Users/me/docs/order-prd.md，先列出所有功能模块、业务规则、字段约束、状态流转、权限点和接口影响点，暂时不要生成完整测试用例。
确认清单没有漏项后，再继续：
根据刚才确认的模块清单，按通用测试规范生成完整的 XMind Markdown 测试用例，
保存为 /Users/me/docs/order-testcases.md。
如果把需求文件放到了 Skill 自带的 requirements/ 目录，也可以这样说：
读取 requirements 里的需求文件并生成 XMind 测试用例；如果有多个文件，先列出候选让我选择。
XMind 的层级不是随便写的
XMind 导入 Markdown 时，标题层级和列表位置决定了最终的脑图结构。稳定的写法是：
| Markdown | XMind 节点 | 作用 |
|---|---|---|
# | 中心主题 | 整张测试用例图的根节点 |
## | 一级分支 | PRD 中的功能或模块 |
### | 二级分支 | 模块下的功能点或子模块 |
#### | 三级分支 | 一条具体测试点，用例名就在这里 |
- | 子节点 | 步骤、预期或前置条件 |
有一个容易踩的格式坑：列表项应放在 #### 测试点下面，不要直接把 - 步骤 放在 ### 功能点下面。下面这段可以直接保存成 Markdown 并导入：
# 测试用例-订单管理
## 订单创建
### 订单信息填写
#### 正向-填写完整信息并创建成功
- 步骤：输入有效商品、数量和收货地址，点击提交
- 预期：创建成功，订单进入待支付状态
#### 反向-缺少收货地址时禁止提交
- 步骤：不填写收货地址，点击提交
- 预期：提示必填项，订单不落库
#### 边界-购买数量达到上限
- 步骤：分别输入上限内、等于上限和超过上限的数量
- 预期：前两种输入按需求处理，超过上限时给出明确提示
在 XMind 桌面版中选择“文件 → 导入 → Markdown”，选中生成的 .md 文件即可。.txt 加 Tab 缩进和直接复制一大段纯文本，不能稳定得到同样的层级。
用一个订单 PRD 看它如何拆解
假设 PRD 只写了下面几条：
- 用户选择商品和数量后可以提交订单。
- 数量必须是 1 到 99 的整数。
- 提交成功后订单状态为“待支付”，支付成功后变为“已支付”。
- 同一订单不能重复支付，普通用户只能查看自己的订单。
好的测试大纲不会只生成“提交成功”和“支付成功”两条。它会先按用户可感知的功能块拆出“订单创建”“支付”“订单查询”，再在每个功能块下补充输入、状态和权限场景。
对于数量字段，至少应该出现有效等价类、非法等价类和边界值：整数 1、99，边界外的 0、100，非整数和空值。对于支付流程，还要检查“待支付 → 已支付”的允许迁移，以及“已支付订单再次支付”的拒绝行为。对于查询接口，A 用户访问 B 用户订单是典型的越权场景，预期不能泄露数据。
这些判断的价值在于把需求里的隐含约束变成团队能逐条讨论的节点。开发可以对照节点检查 API、数据库状态和事务边界；测试可以在此基础上补充设备、浏览器、数据准备和执行优先级。
通用测试和专项测试怎么选
没有特别说明时，先按通用规范生成。每个核心功能至少有一条正常流程，同时要问几遍“输入不合法会怎样”“刚好在边界上会怎样”“中途失败会怎样”。当需求出现多步骤状态、角色切换或回退动作时，再把状态与流程单独列出来。
如果要做接口测试，直接在指令中说明：
按接口测试维度，根据这份 PRD 生成 XMind 测试用例，覆盖请求参数、响应结构、错误码、鉴权、权限、幂等和并发；每条用例写清接口方法和路径。
这样生成的节点应该能够落到具体的 GET、POST 等接口，并写出状态码、业务码和关键响应字段。必填参数缺失、类型错误、过期 token、跨租户访问和重复请求，都要有明确的预期。
如果要做性能测试，也要把目标说出来：
按性能测试维度，根据这份 PRD 生成测试点，覆盖基线、稳态负载、峰值流量、长时间稳定性、瓶颈、限流和降级；没有明确指标的地方请标注待补充。
性能用例不能只写“压测一下”。它至少要能回答并发数或 QPS、持续时间、P95/P99 目标、成功率，以及 CPU、内存、数据库连接等观察项。如果 PRD 没给数值，先保留占位并让产品或运维补齐，不要让模型替团队猜 SLA。
开发和测试如何一起用
推荐把工作拆成两个评审点。
第一轮是需求结构评审：让 Skill 只输出模块清单和业务规则。测试看有没有漏掉用户目标、异常分支和状态；开发看接口边界、字段约束、数据归属是否清楚。这个阶段发现问题，回到 PRD 修改成本最低。
第二轮是用例评审：生成完整 Markdown 后，测试工程师负责覆盖度和可执行性，开发工程师负责实现可行性、错误处理、事务和权限。对无法从 PRD 推导出的内容，直接在用例节点旁标成“待确认”，不要用猜测填平空白。
生成结果还需要一次人工快速检查：模块是否完整、标题层级是否连续、每个测试点是否有步骤和预期、异常场景是否会产生副作用、输出文件是否能被 XMind 导入。复杂 PRD 可以分模块生成，再合并到同一张图中。
这套 Skill 的边界
它当前主要是提示词型 Skill，没有内置的自动质量评分脚本，也不会自动导出 Excel、CSV 或原生 XMind 文件。它能显著减少“从空白页开始写用例”的时间，但不能替代领域知识、风险判断和最终评审。
更稳妥的用法是把它当作第一版测试设计器：先让 AI 把需求结构化，再由开发和测试把业务规则、环境数据、优先级和通过标准补到可执行状态。这样，PRD、代码实现和测试用例之间才真正形成一条可以追溯的线。
结语
PRD 转 XMind 并不只是换一种文档格式。真正有用的是把自然语言需求拆成一棵开发和测试都能读懂的风险清单：功能在哪里、边界是什么、状态怎么走、接口如何失败、性能指标由谁确认。AI 负责加速拆解，人负责确认语义和风险；这才是它在工程团队里最合适的位置。