需求评审专家Skill
一、为什么是这个项目
一个产品最贵的错误，不是代码写错，而是做了一个不应该做的东西。
很多产品团队都有这样的经历：需求文档写完了，开评审会时却发现一方没对齐、边界没覆盖、逻辑有漏洞。更常见的情况是——根本开不成评审会。排期冲突、角色不全、大家赶着进开发，评审被压缩成「走过场」，问题留到开发阶段甚至上线后才暴露。
我观察到的问题是：需求评审是产品质量最高杠杆的环节，但它恰恰是大多数团队做得最薄弱的环节。 不是大家不想评，而是组织一场全员到位的深度评审，成本太高了。
这个项目就是为了解决这个问题而做的——一个 AI 需求评审专家，在任何时候都能给出多个角色视角的结构化评审意见: 你可以直接丢一份 PRD 或者需求文档过来，它立刻化身 9 个角色（产品经理、开发经理、算法工程师、UI设计师、测试工程师、运维工程师、安全工程师、项目经理、数据分析师），每个角色都用自己的一套专业 checklist 从头到尾审一遍。
不是“帮你看看有没有问题”那种泛泛的对话——它按 方向层 → 结构层 → 细节层 三层递进，方向不对直接一票否决，不浪费口水评细节。
二、痛点：评审难组织的背后，是效率问题
需求评审这事，大部分团队其实没做好：
- 视角不全——评审会永远是 PM + 后端开发出席，安全、运维、算法的人从来不在场
- 流于形式——变成“读文档会”，没人系统性地过一遍边界条件、异常路径、状态机
- 反馈太水——“建议加强体验”这种话，改了等于没改
- 方向错了还在抠细节——花几小时讨论按钮颜色，结果需求本身是个伪需求
简单说：没人能在有限时间里同时保持 9 个角色的专业深度。
我的判断是：需求评审不需要更多人，需要的是更系统的视角和更低的使用门槛。
三、核心亮点
三层框架 + 一票否决：先判方向对不对（伪需求/技术不可行/ROI 为负直接毙掉），再过结构完不完整，最后才看细节。上层出大问题，下层不评。
角色不是摆设：每个角色有独立人设。安全工程师“9 年经验，对越权和明文存储高度敏感”，发现问题权重 1.5 倍，P1 直接升 P0。算法工程师“对没有评估方案的需求零容忍”，权重 1.3 倍。
每条建议都有 7 要素：问题定位到具体段落 → 描述为什么是问题 → P0-P3 定级 → 给可落地方案 → 预期效果 → 哪个角色提的。不存在“建议优化”这种空话。
三种模式：快速版（~4K tokens，仅挑 P0/P1）→ 概念版（~8K，只评方向层）→ 完整版（~16K，三层全覆）。按需求成熟度选，不浪费任何一粒token。
产品：让每一次需求都有 9 个人替你审过
这个项目的核心，是做了一个模拟 9 个关键干系人视角的评审系统——产品经理、开发经理、算法工程师、UI 设计师、测试工程师、运维工程师、安全工程师、项目经理、数据分析师。用户把需求文档交给它，它从每个角色的立场出发，给出结构化评审意见。
几个关键的产品决策：
- **先评方向，再评结构，最后评细节。**很多需求评审最大的问题是上来就抠细节——按钮放哪、文案怎么写——但方向都没对齐。我决定采用三层递进框架：方向不对直接一票否决，不浪费时间评细节。这个顺序本身就是一种产品思维。
- **每个角色有独立人格和专业 checklist。**不是简单的「换个 prompt 再说一遍」。产品经理的角色设计成 8 年经验、理性克制、看重商业逻辑；安全工程师对敏感数据有天然的警惕；测试工程师会检查每个边界条件。每个角色的评审维度是逐一设计的，不是泛泛地说「提意见」。
- **自动裁剪角色，不浪费每一次评审。**一个纯功能需求不需要算法工程师来审，一个技术重构不需要 UI 设计师的意见。我设计了按需求类型自动匹配角色的机制，既保证覆盖面，又避免输出无关内容。
- **问题要定位到具体段落，建议要可落地。**这是最硬的要求之一。评审意见不能是「建议加强安全性」这种空话，必须指出需求原文中哪段有什么问题，并给出可执行的修改方案。
四、整体业务流程
五、商业化思考：从团队工具到标准流程
此项目最初是为自己和身边的产品经理做的工具。但深入做下去后，我发现它其实切中了一个更普遍的需求。
**目标用户很明确：**所有写 PRD 的产品团队。互联网公司、SaaS 厂商、甚至硬件团队的需求评审环节，都是潜在场景。
商业化的路径有几个方向：
- 嵌入现有产品管理工具：作为飞书文档、Notion、Confluence 的插件存在，用户在写完 PRD 后一键发起 AI 评审。
- **我认为这个模式走得通的原因是：**需求评审是每个团队的刚需，但市场上现有的工具停留在文档协作层面，没有真正解决评审质量的问题，尤其是当前AI coding盛行，对PRD需求的质量把控尤其重要。而 AI 模拟多角色评审，恰好能用很低成本覆盖这个空白。
六、下一步
这个项目的方向不是做成一个通用 AI 工具，而是成为产品团队的「标准预评审环节」——在正式评审会之前，先用 AI 过一遍，把 80% 的基础问题扫掉，让人力集中在真正需要讨论的核心决策上。
对我来说，做这个项目的价值不只是做出一个能用的工具。它体现的是我对产品开发流程的理解：真正好的产品决策，不是在代码阶段做出的，而是在需求阶段。抓住那个环节，才是最高杠杆的事。