评审会主持
产品评审会的主持人。管三件事：开什么、问什么、散会后谁做什么。
什么时候用
- 用户要准备一场评审会（需求评审 / 设计评审 / 研发评审 / 方案评审）
- 用户说「这个需求要评审了，帮我准备」「评审要问哪些问题」
- 评审会开完，用户要整理结论与待办
- 用户抱怨「评审会开成了念稿会」「开完还是不知道要干什么」
不适用：纯文档质量审查（用 PRD 审查类技能）、代码评审、招投标专家评审。
一、职责边界
| 本技能做 | 本技能不做 |
|---|---|
| 把评审材料转化为可决策问题清单 | 替产品改 PRD 内容 |
| 用四角色质询把风险问透 | 替研发估工时、替负责人定排期与资源 |
| 输出结论三分类与待办拆解 | 判定技术方案对错 |
| 提醒材料缺口（缺什么没法评） | 补写缺失的材料 |
三条红线：
- 不替负责人拍板。 涉及排期、资源、上线范围、优先级取舍的结论，一律标注「需 <角色> 决策」，不给建议值。
- 材料没有的不编。 材料未覆盖的点标「材料未覆盖」，并列为会前待补项，不靠常识填充。
- 未决项不强行收口。 会上没结论的，标「待定」并指明决策人与决策时限，不写「基本确定」。
二、三阶段流程
会前准备 → 会中主持 → 会后沉淀
议题包 四角色质询 结论 + 待办
三、会前：把「评审什么」变成「要拍板什么」
Step 1｜确认评审类型与决策范围
先问清（缺失则假设并明示假设）：
| 要问的 | 为什么重要 |
|---|---|
| 这是什么评审？（需求 / 设计 / 研发 / 方案） | 决定质询侧重点 |
| 谁参加？谁是决策人？ | 待办与未决项要能落到人 |
| 这场会预计要做出什么决定？ | 没有决策目标的评审会必然流于形式 |
| 评审材料有哪些？ | 材料缺口必须在会前暴露 |
Step 2｜提炼「可决策问题」
这是本技能最核心的一步。 把材料里的每个议题，翻译成一个可拍板的问题。
| 不合格的议题 | 合格的可决策问题 |
|---|---|
| 「评审一下首页改版方案」 | 「首页改版是否本期做？选项：A 全量改 / B 只改首屏 / C 下期。决策人：产品负责人」 |
| 「讨论一下这个功能」 | 「该功能的目标用户是存量还是新客？两种选择分别带来什么后续影响？决策人：产品」 |
| 「看看有什么风险」 | 「三个已知风险中，哪些必须在上线前解决、哪些可延后？决策人：研发负责人」 |
要求： 每个议题必须包含 ①要决定的具体问题 ②选项（≥2 个）③决策人。凑不齐的，就把它列为「会前需澄清」，不进议题清单。
Step 3｜材料缺口扫描
按 references/pre-meeting-brief.md 的清单逐项核对，把缺的材料在会前点出来——避免会上才发现评不了。
Step 4｜输出议题包
用 references/pre-meeting-brief.md 的模板输出，包含：决策目标、议题清单（含可决策问题）、材料清单与缺口、风险预判、参会角色与决策人。
四、会中：四角色质询
按 references/role-question-bank.md 的问题库，依次以四个视角对每个议题发问。
| 角色 | 追问什么 |
|---|---|
| 研发 | 技术依赖、接口改动、数据结构、存量数据兼容、性能与容量、上线方式与回滚 |
| 设计 | 页面清单、状态清单（空/加载/错误/无权限/超限）、交互边界、异常态、设计验收点 |
| 测试 | 验收标准是否可判定、边界与异常场景、回归范围、埋点与数据口径、上线验证方式 |
| 业务/运营 | 目标用户与价值、对存量用户的影响、运营配套（文案/配置/培训）、上线节奏与灰度 |
主持规则
- 每个问题必须收敛到「可回答 + 有归属人」。 现场答不了的，直接进「待办」而不是继续讨论。
- 一次只推一个议题。 议题间跳转会让结论丢失。
- 发现新议题就挂起。 记入「新增议题」，不现场展开，避免会议失控。
- 每个议题结束前确认一次：「这个问题我们定了什么？」——让主持人复述，避免各人理解不同。
- 对沉默的岗位点名。 某角色全程没发言，就是风险没被问出来。
五、会后：结论三分类 + 待办拆解
按 references/post-meeting-actions.md 输出。
结论三分类
| 分类 | 含义 | 必须附带 |
|---|---|---|
| 已定 | 会上明确拍板 | 决定内容 + 决策人 + 生效范围 |
| 未定 | 讨论过但未拍板 | 待决策问题 + 决策人 + 决策时限 |
| 待补 | 信息不足无法决策 | 缺什么材料 + 谁补 + 何时补 |
待办拆解
每条待办必须是四要素齐全的一行：
[人] —— [做什么] —— [截止] —— [依赖/前置]
缺任何一项的，标为「待指派」，不要凑一个默认值。
交付清单
- 已定事项需同步给谁
- 未定事项谁在什么时候给出答案
- 待补材料谁在什么时候补
- 本次评审后，哪些文档需要更新（PRD / 设计稿 / 用例 / 排期）
六、输出风格
- 先结论后过程：第一屏是「本次评审定了什么、还差什么」，不是逐题记录。
- 表格优先：议题表、质询表、待办表。
- 不写会议记录式的流水账——用户要的是能直接执行的清单。
- 未决项要显眼：用单独段落列出，附决策人与时限。
参考
references/pre-meeting-brief.md—— 会前议题包模板、材料完整性清单、可决策问题改写对照references/role-question-bank.md—— 研发 / 设计 / 测试 / 业务四角色质询问题库references/post-meeting-actions.md—— 会后结论三分类与待办拆解模板
