ARTICLE · 1149657
需求文档丢进去,5 分钟拿到需求分析 + 测试 checklist:QA Architect Skill 从 0 到 1 全拆解
每次拿到一份 PRD，最头疼的不是读不懂，而是读完之后要自己动手拆——拆业务全景、拆状态机、拆测试点、拆风险，最后还要给开发整理一份能照着测的 Checklist。一整套下来，半天没了。
如果有一个 Skill，你把 PRD 或截图丢进去，它自动帮你做深度解构、技术风险预判、隐性需求检查，并输出一份结构固定的需求分析文档 + 一份开发可直接勾选的需求测试点 Checklist——就能把更多时间留给评审沟通和用例细化。
这就是「资深质量架构师（QA Architect）」Skill 的设计初衷。
01
PART
这个 Skill 省了什么
做需求分析的测试人大多有过类似经历：
PRD 一摞，结论自己梳理
产品给的是飞书文档、几张截图或原型图，你要自己整理成「业务全景、状态机、测试点、风险」，写进分析文档。
文档格式不统一
有时用 Word，有时用 Confluence，有时临时贴几段话，领导和开发看得费劲，评审时对不齐。
隐性需求容易漏
幂等性、主从延迟、兼容性、可观测性——需求里经常不写，但线上容易出事，分析时不知道从哪几层过一遍。
开发要一份「能照着测」的清单
光有需求分析不够，开发自测、联调验收时希望有一份可勾选的测试点清单，和需求一一对应。
这个 Skill 解决的就是这四件事：把「自己拆 PRD + 码字 + 列测试点」变成「提供 PRD/截图和说明 → 拿到需求分析文档 + 开发用 Checklist」。
02
PART
它做了什么
QA Architect 是一个 Cursor Agent Skill，核心做三件事：
第一，看你的需求素材。支持 PRD 全文、需求文档（文本），或 1 张乃至多张需求相关图片（原型图、流程图、界面截图等），以及你补充的文字描述。支持图文混合。
第二，做专业需求分析。结合内置的「能力矩阵」与「专家 Checklist」，按固定工作流执行：
深度解析（Context、角色权限、状态机）
技术风险预判（数据流、性能边界、逆向异常流）
输出高级测试点
从截图和描述里提取功能/模块，按「架构级 / 业务级 / 性能安全」做分层分析，并强制过一遍幂等性、一致性、兼容性、可观测性四类隐性需求。
第三，输出两份标准文档：
需求分析完整文档：包含「业务全景图、逻辑与状态机、深度测试点、风险建议/缺陷预警」四部分；多图时按图 1、图 2… 组织，便于评审与追溯。
开发用需求测试点 Checklist：从分析结论提炼的可执行、可勾选条目，按「功能与界面、字段与接口、状态与权限、异常与边界、性能与安全」分块，带「来源」「开发自测」列，便于开发自测与联调验收。
03
PART
谁适合用
典型使用场景：
单模块需求（如登录、订单、支付流程）需要完整分析并留档。
多页/多图原型，希望按图序号整理成一份完整需求分析，每条结论可追溯。
需要把「截图 + 口头结论」整理成正式需求分析文档 + 开发用 Checklist，便于归档或跨团队沟通。
需求评审/Kickoff 前，希望提前过一遍幂等性、一致性、兼容性、可观测性，并在风险建议里挑战模糊点。
04
PART
输入与输出
你需要提供什么（输入）
必选之一：
文本：PRD 全文、需求文档、功能说明、接口/业务描述（可直接粘贴或提供文件路径）。
或图片：1 张或多张需求相关图片（原型图、流程图、界面截图等）；在 Cursor 里可直接粘贴截图，或提供已保存的图片路径。
支持图文混合（例如「图 1～图 3 是界面，下面这段是补充说明」）。
建议补充：简短文字描述，例如业务背景或模块名、关注点、环境或版本说明。描述越清晰，生成的「业务全景图」和「风险建议」越贴实际诉求。
你会得到什么（输出）
默认先在对话中输出 Markdown；若你说「保存到 output」或指定路径，会写入两份文件到当前工作区下的 output/ 目录。该 Skill 不负责编写逐条详细测试用例、不生成 XMind 测试用例树，产出的是「需求分析结论 + 给开发用的检查清单」。
05
PART
在 Cursor 里怎么用
确保 Skill 已启用
将 qa-architect-requirement-specialist 放到当前项目或 Cursor 可识别的技能目录中（如 .cursor/skills/），并在 Cursor 里启用/引用该 Skill。
发起一次对话
在对话中上传 PRD 文本或 1 张乃至多张需求相关图片（粘贴或拖拽），并用文字简单说明业务/模块、关注点。明确说出你的需求，例如：
「根据这些截图和描述做需求分析，并输出开发用 Checklist。」「对这份 PRD 做需求分析，保存到 output。」「这是门诊医生站的三张界面图，请做图片需求分析，按图序号整理，并生成开发用 Checklist。」
触发词（任选其一或组合即可）
「需求分析」「PRD 解构」「测试点设计」「图片需求分析」「截图需求」「多图需求」「质量架构」「风险预判」「状态机梳理」「做质量保证」「风险治理」。
等待生成
AI 会按 Skill 内的工作流：深度解析 → 技术风险预判 → 输出高级测试点 → 过专家 Checklist → 填写需求分析四部分 → 同步产出开发用 Checklist。
查看与二次编辑
需求分析文档与 Checklist 均为 Markdown，用任意编辑器打开即可；如需微调表述或补充信息，可直接编辑，或让 AI 再改一版。
06
PART
分析质量是怎么保障的
要保证「分析有层次、结论有依据、Checklist 可落地」，Skill 里内置了四类资源：
能力矩阵（expertise-matrix.md）
定义需求分析阶段的 5 大核心能力：业务与上下文解构、角色与权限分析、状态与生命周期、技术风险与数据流、测试点与质量保障设计。约定运用顺序：1 → 2 → 3 → 4 → 5，并在步骤 4、5 中结合专家 Checklist 做隐性需求检查。
专家 Checklist（qa-expert-checklist.md）
分析时强制自检四类「隐性需求」：幂等性、一致性、兼容性、可观测性。每类有「关注点、典型场景、检查方式、输出建议」，避免只写「正常流程」而忽略重复提交、主从延迟、老数据兼容、日志埋点等问题。
报告结构规范（output-template.md）
明确定义需求分析文档四部分各自写什么、怎么写；约定多图时按图号分节，保证每条分析可对应到具体图片；约定双输出：需求分析完整文档 + 开发用需求测试点 Checklist。
开发用 Checklist 模板（dev-checklist-template.md）
定义 Checklist 的文档头与五块结构；约定「序号、测试点描述、来源、开发自测☐」等列，便于开发勾选与追溯需求。
填写原则：客观（基于 PRD/截图可见内容，不臆测）、可读（分条分表，避免过多行话）、可操作（风险建议尽量具体，并区分需求澄清、设计补充、测试重点关注）。
07
LAST
写在最后
QA Architect Skill 面向的是「有 PRD 或需求截图、需要快速产出规范需求分析 + 开发用 Checklist」的场景，尤其适合软件测试工程师在 Cursor 里把「PRD/截图 + 描述」变成「可直接给领导、开发看的需求分析文档和可勾选 Checklist」。
分析有固定工作流（深度解析 → 技术风险预判 → 测试点设计）和专家 Checklist（幂等性、一致性、兼容性、可观测性），输出结构统一；你只需提供需求素材和简单说明，即可在几分钟内得到两份可分享、可归档的文档。
如果你在需求分析上经常耗时、文档格式不统一，或对隐性需求拿不准，可以尝试把本 Skill 接入当前工作流，把重复性的「整理 PRD + 写分析 + 列 Checklist」交给 AI，把时间留给评审沟通和用例设计。
完整 Skill 包、规范 MD、以及实操示例，我已经整理好了。关㊗️后回复「666」，按指引自取。
