前言¶
评审需求文档时，最常见的情况是：大家盯着主流程看了一遍，觉得「能跑通」，就排期了。等到写用例时才发现，边界值没人定、异常分支没人想、非功能指标没人接。问题不在人不认真，而在从需求到测试要点这一步缺少固定套路，每次都靠临场发挥。
下面介绍的 从需求提取测试点 这个 Skill，就是把这一步固化下来：读入一份需求文档，按五个固定维度输出结构化的测试要点清单。它是 community 来源的通用 SKILL.md 格式技能，坐标 @user_827d1ddb/requirement-to-testpoints，版本 1.0.0，由 user_827d1ddb 维护。
这是什么¶
一句话定位：给大模型一个需求文档，让它产出一份分好类的测试要点清单，而不是一段零散的评审意见。
解决的问题是覆盖面。人工列测试点容易顺着主流程走，边界、异常、非功能需求这三类最容易漏。这个 Skill 的价值不在于「写得快」，而在于它强制按五个维度展开，每个维度都有输出位。
覆盖的五大维度¶
清单固定分成五类，这是这个 Skill 的核心结构，也是判断输出是否合格的唯一标准。
- 功能测试：需求里声称的每个功能点，对应至少一条验证要点。
- 业务规则：校验规则、状态流转、权限与角色约束、计算口径。
- 边界条件：数值上下限、空值与超长输入、分页与数量边界、时间边界。
- 异常场景：网络失败、超时、重复提交、并发冲突、依赖服务不可用。
- 非功能需求：性能指标、兼容性、安全与隐私、可观测性、文档完备性。
实际操作时，前两类对应需求正文，后三类对应需求里往往只有一句话甚至没写的部分。Skill 的作用是让模型把这三类也摊开写，而不是默认跳过。
核心能力¶
按已核实的资料，这个 Skill 提供的能力有两条。
一是从需求文档中自动提取结构化测试要点清单，输出是分好类的条目，不是段落式描述。
二是对五类维度做系统性覆盖，包括边界条件、异常路径和非功能需求这些人工容易遗漏的部分，目的是防止测试覆盖遗漏。
输入可以是 PRD、设计文档或用户故事，形态不限，但必须是足够具体的文本。需求写得含糊时，提取出的要点也会含糊——这是所有需求解析类 Skill 的共同前提。
如何启用¶
官方来源没有给出包管理器命令或目录约定，因此下面只给能核实到的定位方式，不写推测的安装步骤。
SkillHub 页面：
https://www.skillhub.cn/skills/user_827d1ddb/requirement-to-testpoints
API 地址：
https://api.skillhub.cn/user_827d1ddb/requirement-to-testpoints
坐标：
@user_827d1ddb/requirement-to-testpoints
在支持 SkillHub 生态的 Agent 环境里，通常按坐标引用或在技能市场里按名称搜索「从需求提取测试点」即可启用。具体入口取决于你使用的客户端，建议以官方页面的说明为准。
已知元数据：版本 1.0.0，来源 community，分类 dev-programming，评分 100000，下载 511 次，安装 0 次，标签 requires_api_key=false。最后一项意味着调用不需要额外的 API Key。
典型用法¶
这个 Skill 的触发条件写得很明确：当用户要求「提取/写/生成测试点、测试用例、测试场景、测试清单、QA 计划」，或者提供了需求文档并要求做测试覆盖分析时使用。
用法分三步。
1、把需求文档贴进对话，或直接描述需求范围。文档太长时建议按模块分段喂，避免模型在长文里丢掉细节。
2、给出明确指令，例如：
基于上面这份需求，提取测试点，按功能、业务规则、边界条件、异常场景、非功能需求五类输出。
3、拿到清单后做人工复核。重点核对两类：一是功能类要点是否和需求正文一一对应，有没有凭空多出来或漏掉的功能点；二是边界类和异常类要点是否真的落在当前需求的范围内，模型有时会生成通用模板条目。
适用场景与限制¶
适合的场景：需求已经进入评审阶段、需要快速铺出一份测试要点清单；或者做测试覆盖自查，看有没有维度整体缺失。
不适合的场景：需求只有一句话、没有任何细节时，提取出的清单不会有信息量；需要可直接执行的用例（前置条件、步骤、预期结果完整）时，这个 Skill 给的是要点而非用例，还得再补一步；涉及真实业务规则的口径判断，必须人工确认，模型给出的规则边界可能是推测。
两个需要注意的点。一是它只做提取和分类，不做优先级排序，重要程度需要自己标。二是清单质量上限由需求文档的清晰度决定，需求写得含糊，输出必然含糊。
结语¶
这个 Skill 的价值不在自动化，而在把「从需求到测试要点」这一步变成固定动作，让边界条件、异常路径和非功能需求这三类容易被忽略的维度每次都有输出位。它适合作为测试设计的起点，而不是终点——拿到清单之后，该补细节补细节，该排优先级排优先级。
官方地址：https://api.skillhub.cn/user_827d1ddb/requirement-to-testpoints
