这篇想介绍一个很实用的需求分析 Skill，拿去直接用，效果真的好。上周拿到一份电商项目的需求文档，产品写得中规中矩，业务流程图、验收标准都有。但轮到出测试用例时，团队里的同学还是要在脑子里把各种边界条件挨个过一遍：空值怎么办、超时怎么办、越权怎么办、并发冲突怎么办。
每个做测试的人都经历过这个状态：对着一份 PRD 逐行扫描，然后在 XMind 或 Excel 里手动罗列测试点。运气好的时候，需求写得详细，直接对着 AC 逐条翻译就行。运气不好的时候，产品只给一句话需求，比如「做一个文件上传功能」或「订单详情页支持取消」，剩下的全得靠自己补全。
一、工作痛点：需求分析，测试流程里最容易被跳过的环节问题不在能不能干，而在效率。尤其是那种大功能，系统拆了七八个模块，每个模块之间还有数据依赖，等你把测试点梳理完，开发那边已经提测了。排期紧的时候，很多团队干脆跳过分析阶段直接上手写用例，结果测到一半才发现有边界条件没覆盖，临时补用例，测试报告里塞满了「建议补充测试点」。
测试需求分析，说到底是整个测试流程的地基。这个环节做扎实了，后面的用例质量和测试效率才有保障。但它太耗人了，所以我做了这个 Skill。
二、这个 Skill 是什么test-requirement-analysis，名字很长，但功能就一句话：你给需求，它出分析报告。
它不是什么「一键生成测试用例」的工具——那个定位本身就是错的，AI 不可能在不懂业务的情况下直接写出合格的用例。它的定位在更上游：帮你把需求拆成可执行的测试点清单，标好优先级和风险，给出分层测试策略建议。拿到这份报告之后，你再来写用例，是水到渠成的事。
它的核心设计跟市面上大多数「测试点生成器」有一个本质区别：先判断需求质量，再决定怎么处理。
需求写得很详细（超过 100 字，有背景、流程、边界、验收标准）→ 直接深度解析，从 8 个维度提取测试点，输出完整报告。
需求只有一句话（不到 100 字，就一个标题或一句话）→ 不硬编。先生成一份带 【待确认】 占位符的框架版，再反过来给你出一份结构化的待澄清问题清单，等你补完信息后生成完整版。
这个设计上的分寸感，是它跟「假装理解」的生成器最大的不同。
问题一：需求分析靠脑补，容易漏维度
一般的做法是拿到需求，凭经验想几个测试场景就开始写用例。漏掉什么是常态：SQL 注入测了没？并发冲突考虑了没？状态机的非法跳跃校验了没？事务回滚呢？
这个 Skill 内置了一套 8 维度分析框架：正向流程、逆向流程、边界值、状态转换、权限与角色、数据一致性、用户交互与体验、非功能需求。每个功能点都会从这 8 个维度过一遍，你不至于漏掉那些「理论上该测但经常被忘记」的点。
问题二：需求模糊时，不知道该问什么
这是最难受的情况。产品只给一句「做一个 XX 功能」，你明知道缺了很多信息，但具体该问什么、问到什么程度，脑子里是乱的。
Skill 内置了两个知识库来解决这个问题：
附录 A：通用测试点检查清单。五大类（输入验证、业务逻辑、权限安全、界面易用性、兼容性）的地毯式兜底提问——空值处理了吗？特殊字符截断了吗？幂等性考虑了吗？未登录访问怎么处理？列表分页排序正常吗？每个功能点都用这个清单过一遍，把「你不知道自己不知道什么」的盲区覆盖掉。
附录 B：RPN 风险识别模型。RPN = 影响程度 × 发生概率，从 1 到 5 分别打分，算出乘积再定级。比如「退款回调失败」这个风险：影响程度 5 分（涉及钱），如果回调机制没有重试，概率打 4 分，RPN=20，高风险。这个结论不是凭感觉来的，而是有计算逻辑支撑的。你跟开发说「这地方 RPN 是 20，我们能不能加个重试把它降到 12」，比说「我觉得这里比较危险」有说服力得多。
问题三：测试策略拍脑袋，没有分层
报告输出不是只有测试点清单，还包括四层测试策略：
接口/单元测试覆盖什么 UI 自动化回归什么 手工深测重点是什么 需不需要性能压测、安全渗透、兼容性矩阵
这四层不是模板化的「你要做性能测试、安全测试」，而是结合具体需求给出的方向。
四、怎么使用使用门槛几乎为零。我已经把它装在了 WorkBuddy 的 Skill 库里，直接用就行。
方式一：贴需求文档。把 PRD、需求描述、用户故事直接复制到对话框里，然后说「分析这个需求」。Skill 会自动判断需求质量，走对应的处理路径。
方式二：截图。有些需求存在飞书文档或者图片里，不方便复制文字，直接截图贴进去，一样生效。
方式三：跨平台使用。这个 Skill 的核心 Prompt 不到 3000 字，不依赖任何外部文件或联网。如果你用 Cursor、Trae 或者其他 AI 工具，直接把 Prompt 复制过去就行。
使用过程中的两个关键动作：
第一，拿到报告后不要直接当成最终版。你的角色从「扫描机」变成了「审核者」，检查 AI 的分析有没有遗漏，补充业务特有场景，确认待澄清问题有没有得到回答。
第二，补充信息后让 Skill 更新报告。尤其是简短需求场景，你回答了待澄清问题之后，它会把框架版更新为完整版，占位符全部替换为具体内容。
五、电商实战案例案例一：视频去字幕（完整需求场景）
某品牌要把已发布的视频回收，去掉字幕后二次利用。需求文档有明确的业务背景、解决方案和操作流程——典型的完整需求。
我把需求截图提交进去，调用了这个 Skill，输出了 20 条测试点，覆盖上传、预览、下载三个模块。
让我觉得最有用的是风险识别。它自动标记了：
火山云去字幕服务调用失败后的任务处理策略（RPN=16，影响程度 4 × 概率 4） 去字幕版本与原视频的关联关系正确性（RPN=15，影响程度 5 × 概率 3）
第三方服务集成和数据关联——这俩是我们测试线上出过问题的老熟人。不用自己再从头梳理，直接就能聚焦在这两个高风险区域。
测试策略也很落地。它建议接口测试覆盖任务 API 和素材关联查询，UI 自动化跑核心冒烟链路（上传→等待→预览→下载），手工深测重点放火山云异常场景，专项测浏览器兼容性。每一个建议都是对着需求内容来的，不是泛泛的「你要做安全测试」。
案例二：订单修改收货地址（极简需求场景）
去年我们做过一个电商后台控制台的需求。产品只给了一句话：「订单详情页加上买家修改收货地址的功能，仅在待发货状态下可用。」
典型的短需求。如果硬着头皮直接出测试点，大概能列几条——功能通了、状态对了、界面上有了。但真正该测的东西完全没覆盖。
这个 Skill 的处理方式是：先用附录 A 的通用检查清单搭一个带占位符的框架，然后反过来逼你澄清关键问题。比如它问了：
地址修改后是否需要二次确认？（界面交互 → 防止误操作） 买家修改地址后，商家端是否实时同步？（数据一致性 → 避免发货到旧地址） 修改地址是否触发重新计算运费？需要补差价的话，支付流程怎么走？（正向流程 + 异常流程 → 涉及金额） 是否存在恶意利用修改地址骗取运费差价的风险？（业务逻辑 → 安全风险） 旧地址的历史订单数据怎么处理？保留还是覆盖？（数据一致性 → 审计追溯）
这里面有些问题，产品自己写需求的时候都没想过。但它问出来之后，你才意识到确实需要确认。
这就是「引导式分析」的价值。不是替你猜答案，而是把边界逼出来。
测试需求分析这个环节，不是因为不重要才被跳过，恰恰是因为太重要所以太耗时。排期一紧，它就成了第一个被牺牲的。
这个 Skill 做的事很简单：把最枯燥的部分——扫描需求、匹配维度、标记风险、输出结构——自动化了。你的时间从「一条条脑补测试点」变成了「审核 + 补充业务特有场景」。
效率上，一份中等复杂度的需求分析，手动做大概 1～2 小时，用这个 Skill 15 分钟能拿到一份初步报告。真正花时间的，是最后的业务深度场景补充，而这恰好是你作为测试工程师最有价值的判断，不该被机械劳动挤掉。
一个 Skill，做一件事，把它做好。在测试需求分析这个环节上，它确实比手动拆解好用得多。
