用途：把模糊或口语化的产品想法转化为开发可据以构建、QA 可据以测试、干系人可批准的需求文档。覆盖 SRS、PRD、BRD、FRD、User Stories、Use Cases 六类文档。
主要能力：按输入类型分流处理——口语化描述走发现+撰写流程；已有文档走评审模式；明确指定文档类型时跳过发现直接选型撰写；单一功能或迭代需求则用用户故事模板加验收标准。撰写时强制使用 shall/should/may 规范措辞、主动语态、可量化指标，禁止“快速”“用户友好”“健壮”等模糊词；要求为每条需求提供 ID（如 FR-AUTH-001）、描述、理由、优先级（Must/Should/Could/Won't）、来源、验收标准、依赖与备注。文档必须覆盖功能、非功能（性能、扩展性、安全、可靠性、无障碍、可用性、可维护性、可移植性、合规、国际化）、接口与数据四类需求，并包含假设清单、开放问题日志、需求追溯矩阵、术语表与变更日志。
使用方式：先回答 7 个发现阶段问题（系统范围、干系人、要解决的问题、约束与合规、文档类型、交付格式、已有材料），再按推荐模板撰写；交付前执行歧义扫描、可测试性、完整性、矛盾、接口、优先级、术语、假设、范围、追溯性与开放问题等校验。交付物可按正式文档（含目录、页眉、页码、需求表格）或敏捷格式（可直接导入 JIRA/Linear/Shortcut）生成。评审模式会读取全文，逐条对照质量原则标记歧义、缺失、矛盾、不可测试、不完整问题，按 Critical/Major/Minor 分级并给出质量评分与改写建议。
适用场景：团队需要正式需求基线、合规行业（GDPR、HIPAA、PCI-DSS、SOX、ADA 等）需求梳理、将一句话功能扩展为数十条可测需求、或评审既有需求文档。
限制：资料未说明是否收费、价格、平台支持与具体效果数据；技能要求不得跳过发现阶段，且不确定用户意图时须显式声明假设，不得静默判断。