ARTICLE · 1133565
需求文档丢进 Cursor,自动生成测试用例思维导图:prd-to-xmind Skill 完整拆解,附源码
需求评审一结束，测试这边就开始和时间赛跑。PRD 动不动几十页，功能点藏在章节缝隙里，边界条件散得七零八落。手动拆解模块、逐条编写用例，熟练的老手也得搭上小半天，新人更容易漏掉关键分支。更头疼的是整理环节：Excel 拉到两三百行，回头翻找个用例像大海捞针；思维导图确实清爽，可一条条往 XMind 里敲，工作量半点没减。
我在 Cursor 里搭了一个 Skill，专门打通这个堵点。思路不复杂：把需求文档喂进去，交代一句「生成测试用例」，它自动完成模块识别、策略覆盖、步骤填充，最后输出一份能直接拖进 XMind 的 Markdown 文件。原先半小时起步的活，现在几分钟收工。
01
PART
这个 Skill 到底帮你省了什么
先算一笔账。传统方式产出一套完整的测试大纲，通常要经历这几道手：
通读整份 PRD，人工标注功能归属和模块划分；
逐条构思测试点，补全正向、反向、边界和异常分支；
整理成结构化文档，调格式、对齐层级；
评审时根据反馈反复修改排版。
有经验的人也要 30 分钟以上，遇上复杂需求一小时打底。而且人脑不是 checklist，边界条件、异常路径、状态流转，记不全就漏，评审时被开发追问「这个场景怎么没覆盖」，再回头补坑。
这个 Skill 的分工是：AI 扛住读文档、拆模块、套策略的体力活；人守住审结果、补业务、定标准的决策权。你省掉的是逐条手写和手动排版的机械劳动，把时间腾出来干真正值钱的活——理解业务逻辑、抓边界风险、审 AI 产出。
02
PART
它做了什么
Skill 叫 prd-to-xmind-testcases，一句话概括：拿需求文档当输入，吐出一版可直接转成 XMind 导图的测试用例大纲。
整个流程拆成四步：
读文档：支持三种喂料方式——丢进固定目录、指定任意路径、直接粘贴正文；兼容 .docx、.pdf、.txt、.md 几种常见格式；
拆模块：从文本里提取功能模块，尽量跟需求原有的章节结构对齐，降低漏测概率；
套策略：默认加载通用设计规范（正向、反向、边界值、等价类、场景法、状态流转）；如果你明确说「按接口规范」或「按性能规范」，自动切到对应专项维度；
出结构：输出 Markdown，层级约定为根节点 → 模块 → 功能 → 测试点 → 步骤与预期，导入 XMind 后层级基本不用动。
产出的 .md 文件大概长这样：
# 测试用例-XXX项目
## 用户系统模块
### 用户登录
#### 正向-正确账号密码
- 步骤：输入已注册账号与正确密码点击登录
- 预期：登录成功进入首页或个人中心
#### 反向-错误密码
- 步骤：输入正确账号与错误密码
- 预期：提示密码错误且不跳转
#### 边界-空账号或空密码
- 步骤：账号或密码为空提交
- 预期：提示不能为空
在 XMind 里走「文件 → 导入 → Markdown」，选中这份文件，中心节点就是「测试用例-XXX项目」，一级分支是各模块，二级是功能，三级是具体测试点，下面挂着步骤和预期。拿着这张图去评审，开发一眼就能看明白覆盖到了哪一层。
03
PART
谁适合用
功能测试
接到需求文档后，想快速搭一份按模块组织的测试点框架，习惯用导图管理用例库或做评审。
接口测试
需求里夹了接口说明，希望按「入参校验、返回码覆盖、鉴权策略、幂等并发」等维度生成结构。
性能测试
需求中有性能指标或 SLA，想按「基准指标、负载场景、容量瓶颈」等角度搭框架。
测试负责人
团队需要统一用例风格，确保边界值、场景法等策略被系统性执行，可把本 Skill 当作规范落地的工具。
04
PART
输入与输出
输入端：需求文档（PRD、PDF、Word、纯文本均可），或者一段直接贴在对话里的需求片段。
输出端：一份按模块和功能拆分、带步骤与预期结果的测试大纲，格式为 Markdown，可直接导入 XMind 生成思维导图。
内置三套规范，你说什么它就加载什么：
这些规范都以 Markdown 参考文档的形式躺在 Skill 的 references/ 文件夹里，随时打开查看，也能打印出来给团队培训。如果项目有额外约定——比如特定字段命名规则、必测场景清单——往 references/ 里扔一份自己的 .md，对话里提一句「参考 references 里的某某约定」，Skill 生成时就会把这些规则吃进去。
05
PART
Cursor 四步上手
前置条件：本地已装 Cursor，且本 Skill 放在 Cursor 能识别的路径下（项目级如 .cursor/skills/prd-to-xmind-testcases/，或用户级如 ~/.cursor/skills/）。
推荐走法：
把需求文件复制到 Skill 目录下的 requirements/ 文件夹；
在 Cursor 对话框里敲一句：「读取 requirements 里的需求文件，生成测试用例」；
如果目录下有多份文档，Skill 会先列清单，你回复要处理哪一份；
等它解析完、生成完整 .md 后保存，然后打开 XMind「文件 → 导入 → Markdown」选中文件，导图就出来了。
除了固定目录之外，你也可以说「根据 docs/需求v2.docx 生成测试用例」来指定任意路径，或者先粘贴一段需求片段再说「根据下面这段内容生成导图用例」。核心就两件事：告诉它读哪、要不要切接口/性能规范。
06
PART
质量保障：三道约束
Skill 内置的规范不是摆设，而是硬约束，生成时会强制带入：
01通用规范（默认加载）
不只是 happy path。每个核心功能至少一条合法流程；必填缺失、格式错误、越权访问、重复提交等反向场景必须出现；有范围限制的字段要做最小值、最大值、超界、空值；有效/无效等价类取代表值；典型用户旅程和状态机非法跳转也要覆盖。
02接口规范（明说「接口测试」时叠加）
在通用基础上增加请求与参数（必填缺失、类型错误、可选参数）、响应与错误码（文档里定义的每个码至少一条用例、未定义错误如何处理）、鉴权与权限（未携带、失效/过期、越权）、幂等与并发（重复提交、限流阈值）。
03性能规范（明说「性能测试」时叠加）
围绕指标与基线（响应时间、吞吐、资源占用）、场景类型（基准、稳态、峰值、长稳）、瓶颈与退化（阶梯加压、降级/限流/熔断触发条件）三个维度展开。
无论加载哪套规范，输出结构始终保持「模块 → 测试点 → 步骤/预期」的层级，方便你直接跟接口文档、性能指标或压测方案对表。
07
PART
进阶：跨项目复用与团队定制
想不止在一个项目里用这个 Skill？把整个目录（SKILL.md + references/ + requirements/）复制到 Cursor 的用户级 Skill 目录，以后任何项目打开都能直接调用。
团队如果有自己的用例规范——比如特定字段命名、必测场景清单、专属风险项——在 references/ 下新建一份 .md，对话中交代「生成时参考 references 里的项目约定」，Skill 就会把这些规则揉进输出里。相当于给团队建了一个可复用的用例生成模板。
///
LAST
写在最后
这个 Skill 不是让你「躺平不动脑」。AI 能替代的是逐条手写、手动排版的机械劳动，替代不了「该验什么、什么叫过」的业务判断。真正值钱的，是你把省下来的时间花在理解需求、补全边界、识别风险上。
如果你现在每次接需求还在手动拆模块、一条条敲 XMind，不妨把它接进 Cursor 试试。一句话从 PRD 到导图，省下来的时间够你多喝两杯咖啡，多审两轮边界。
如果这篇对你有启发，欢迎转发给还在手动写用例的同事。关于 Skill 搭建或测试提效的任何问题，留言区见。
完整 Skill 包及实操示例，我已经整理好了。关㊗️后回复「666」，按指引自取。
既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。
THANKS FOR READING