需求评审漏项雷达

它解决什么问题

需求评审常常在“看起来开完了”和“真的能开发”之间留下裂缝：PRD 里写了但会上没人确认的条目、会上说得热闹但实际只是某个人的倾向、文档和转写结论互相打架、任务没有负责人也没有截止时间。等到开发要动手时才发现验收标准是空的，只能把评审再开一遍。

它如何工作

这个技能不是会议摘要器，而是把 PRD、会议转写或纪要当成可交叉核验的证据源。它会先判断资料组合属于哪种模式：

• coverage_review：PRD 加会议资料，逐项检查每个需求是否被讨论、是否形成结论。
• single_doc_qc：只有一份 PRD 或只有一份会议纪要，按十一个维度检查完整性，并明确说明无法完成跨文档比对。
• dev_entry_gate：判断需求当前能否进入设计、开发、联调或测试。
• meeting_close：在散会前抓出未决事项、缺失负责人、缺失截止时间和需要同步的文档项。

分析时，它会把会议语句区分为事实、提议、讨论、倾向、共识、正式决策和待确认，避免把“我觉得”当成“会上已经定了”。重要结论会附上来源资料、原文片段或文档章节；信息不足的地方直接标成「待确认」，不会补造验收标准或负责人。

最后输出覆盖矩阵、阻断项、文档更新清单、散会前确认问题，以及开发准入等级：

• A：可以进入开发。
• B：有条件准入，需按模块补齐阻断项。
• C：暂不可开发，关键事项未闭环。
• D：不具备准入基础，需要重审。

适用边界

它不接腾讯会议、飞书或 Jira，不做语音转写，不自动改 PRD，不替业务负责人拍板，也不承诺技术可行性。普通会议纪要润色、采访整理、无关项目的待办提取都不是它的目标场景；这些应改用通用摘要能力。所有结果都是评审辅助建议，最终仍需相关角色确认。