前两篇我们聊了用 AI 写 PRD 和做竞品分析，这篇是系列第三篇——产品方案评审。
为什么选这个话题？因为评审会可能是产品经理日常工作中情绪浓度最高的环节。
你精心准备了一周的方案，30 分钟的评审会上被怼得体无完肤。技术说"做不了"，设计说"没想清楚"，业务说"这不是我要的"。最后不欢而散，下次再来。
我经历过最极端的一次：一个方案的评审会开了四轮，每一轮推翻上一轮的结论，最后回到最初的方案——但已经浪费了三周。
后来我发现，评审会低效的根本原因不是"方案不好"，而是"信息不对称"。 每个人带着不同的理解、不同的假设、不同的评判标准进会议室，自然各说各话。
AI 解决不了人的问题，但它可以在会议前帮你消除信息差、预判争议点、准备应答方案——把"吵架会"变成"决策会"。
一、评审会为什么总是"吵架"？
在讲方法之前，先拆解一下评审会常见的四种冲突：
冲突 1：需求理解不一致
产品经理说"支持批量导入"，业务理解的是"Excel 一键导入"，技术理解的是"提供 API 批量创建"，设计理解的是"拖拽文件上传"。
看似在讨论同一个功能，实际上每个人脑子里想的东西完全不同。
这种冲突的可怕之处在于：它不会在会上直接暴露，而是在开发到一半时才发现"啊？原来你要的不是这个"。
冲突 2：技术可行性之争
产品说"这个功能很简单吧"，技术说"这个要做底层架构改造"。
这类争论的本质是双方对"复杂度"的认知不同。产品看到的是"页面上一个按钮"，技术看到的是"按钮背后的数据流转、并发处理、异常兜底"。
而且这类争论往往没有"客观标准"——你说复杂，他说不复杂，各执一词。
冲突 3：优先级分歧
产品觉得这个功能是 P0，业务觉得那个功能才是 P0。每个人都从自己的视角出发，觉得自己的需求最重要。
这类争论最难调和，因为它不是对错问题，而是资源分配的价值判断。
冲突 4：方案细节的"深坑"
大方向大家认同了，但在某个具体字段、某个交互细节上卡住了。比如"这个状态要不要加一个'进行中'？"或者"列表要不要支持多选？"
一个细节讨论 20 分钟，会议时间耗尽，大方向反而没时间对齐。
这四种冲突的共性是：信息不对称。
如果每个人在会前就看到了完整的信息——需求背景、技术约束、用户数据、竞品方案——至少有一半的争论根本不会发生。
AI 能做的，就是在会前帮你把这些信息准备到位。
二、AI 辅助评审的三阶段模型
我把 AI 辅助评审拆成三个阶段：
会前：预判 + 准备 → 会中：辅助 + 记录 → 会后：沉淀 + 追踪
| 阶段 | 目标 | AI 的角色 |
|---|---|---|
| 会前 | 消除信息差、预判争议点、准备应答 | 模拟评审员，帮你提前"被怼" |
| 会中 | 实时记录、聚焦讨论、避免跑题 | 会议助手，记录和结构化讨论 |
| 会后 | 会议纪要、结论追踪、方案迭代 | 总结者，把讨论变成可执行的行动项 |
下面用一个真实案例，逐步演示每个阶段怎么做。
三、案例背景
继续用前面系列文章的项目——项目管理系统的任务协作模块。
经过竞品分析和用户调研后，我们已经产出了一份功能方案，现在需要组织评审会。
参会人员：
| 角色 | 人数 | 关注点 |
|---|---|---|
| 产品经理 | 1（我） | 方案通过，进入开发 |
| 技术负责人 | 1 | 技术可行性、开发工作量 |
| 前端开发 | 1 | 交互细节、组件复用 |
| UI 设计师 | 1 | 设计空间、一致性 |
| 业务方代表 | 1 | 是否满足业务需求 |
| 测试负责人 | 1 | 可测试性、边界条件 |
评审方案概要：
任务协作模块的第一期方案，包含 6 个核心功能：
- 任务创建（手动 + 模板 + IM 转任务）
- 任务看板视图
- 任务分配与指派
- 截止时间与提醒
- 任务内评论与 @提醒
- IM 通知推送
四、会前准备：让 AI 帮你"预演被怼"
这是整个流程中最有价值但最容易被跳过的环节。
大多数产品经理的会前准备是"把 PRD 发到群里，让大家提前看"。但现实是：没人看。到了会上才开始理解方案，然后现场质疑。
AI 可以帮你做一件事：在会前模拟所有参会角色的视角，提前发现争议点，准备好应答方案。
4.1 模拟评审：让 AI 扮演各角色"质疑"你的方案
我的 Prompt：
我需要组织一场产品方案评审会，以下是我的方案概要。
请分别扮演以下角色，从各自的视角对我的方案提出质疑和问题：
1. 技术负责人（关注：技术可行性、架构影响、开发工作量、技术风险）
2. 前端开发（关注：交互复杂度、组件复用、性能、兼容性）
3. UI 设计师（关注：设计空间、交互一致性、设计规范对齐）
4. 业务方代表（关注：是否解决业务痛点、上线时间、ROI）
5. 测试负责人（关注：可测试性、边界条件、回归影响）
对每个角色，请提出 3-5 个"最可能问的问题"，按"尖锐程度"排序。
每个问题用该角色的口吻提出，越真实越好——不要客气，评审会上没有人会对你客气。
---
【方案概要】
项目背景：项目管理系统新增"任务协作"模块（第一期）
核心功能：
1. 任务创建
- 手动创建：填写标题、描述、分配人、截止时间、优先级
- 模板创建：选择预设模板，自动填充字段和子任务
- IM 转任务：在聊天消息上右键"转为任务"，自动提取标题和描述
2. 任务看板视图
- 默认按状态分列：待处理、进行中、已完成
- 支持拖拽切换状态
- 卡片显示：标题、分配人头像、截止时间、优先级标签
3. 任务分配与指派
- 支持单人/多人分配
- 分配时发送 IM 通知
- 支持按角色分配（如"前端开发"角色，系统自动分配给该角色的成员）
4. 截止时间与提醒
- 支持设置截止时间
- 截止前 24 小时自动提醒（IM + 站内信）
- 逾期自动标红，并通知分配人和其上级
5. 任务内评论与 @提醒
- 任务详情页支持评论
- 支持 @具体成员或 @角色
- 被提及者收到 IM 通知
6. IM 通知推送
- 任务创建、分配、状态变更、评论、截止提醒均推送 IM 通知
- 支持在 IM 通知卡片上直接操作（如标记完成、快速回复）
预期排期：6 周开发 + 2 周测试
AI 的输出：
🔧 技术负责人的灵魂拷问
1.（尖锐） "你说 IM 转任务'自动提取标题和描述'，这个 NLP 解析的准确率你能接受多少？如果用户发了一条 200 字的消息，截取前 20 字当标题，剩下的当描述——这种体验你确定能接受？如果提取错了，用户修改的成本是不是比手动创建还高？"
2.（尖锐） "按角色分配'系统自动分配给该角色的成员'——这个自动分配的策略是什么？轮询？负载均衡？随机？如果某个角色下只有 1 个人但 100 个任务都分给了这个角色，你的系统能处理吗？"
3.（尖锐） "你说所有状态变更都推送 IM 通知。一个 50 人的项目，一个状态变更发 50 条通知？你知道 IM 消息的并发上限是多少吗？你考虑过消息风暴的问题吗？"
4.（一般） "逾期通知'上级'——组织架构数据你从哪来？实时查还是缓存？缓存更新频率是多少？"
5.（一般） "6 周开发 6 个功能，平均每周 1 个功能。IM 转任务涉及 NLP、看板涉及拖拽交互、通知涉及消息系统——你确定不需要单独做技术预研？"
💻 前端开发的连环追问
1.（尖锐） "看板拖拽——你说'支持拖拽切换状态'，这是 HTML5 原生拖拽还是用第三方库？列表项超过 500 个的时候拖拽性能你测过吗？移动端拖拽怎么做？"
2.（尖锐） "IM 通知卡片上'直接操作'——你是要在 IM 客户端里嵌入我们的业务组件？IM 那边的卡片渲染能力支持到什么程度你调研过吗？"
3.（一般） "模板创建——模板数据结构怎么设计？不同类型的任务模板字段不一样，前端怎么动态渲染表单？"
4.（一般） "看板的列自定义——你说按状态分列，那状态能不能自定义？如果客户要加一个'测试中'的状态，列也要跟着变？"
🎨 UI 设计师的温柔一刀
1.（尖锐） "看板卡片上要显示标题、分配人头像、截止时间、优先级标签——信息密度这么高，卡片要做多高？如果标题是 50 个字呢？截断还是换行？换行的话卡片高度不一致，看板怎么对齐？"
2.（尖锐） "你提到'逾期自动标红'——是用背景色、文字色还是标签色？和现有的'高优先级=红色'标签冲突吗？用户会不会分不清'这是逾期了'还是'这是高优先级'？"
3.（一般） "IM 转任务的交互流程是什么？右键菜单里'转为任务'之后，是直接创建还是弹出表单让用户确认？如果弹表单，表单里预填哪些字段？"
📊 业务方代表的灵魂质疑
1.（尖锐） "6 周开发 + 2 周测试，那就是 2 个月后才上线？我们下个月就要开始用新的项目管理流程了。能不能先上核心功能？IM 转任务、模板创建这些锦上添花的后面再说？"
2.（尖锐） "你说'按角色分配'——我们公司有 300 多个角色，角色和人的对应关系经常变。你是每次分配都实时查角色成员，还是有个管理后台可以维护？如果有人离职了但角色没更新，任务分配给谁？"
3.（一般） "任务评论里 @人能收到通知，那 @的人不在项目组里怎么办？能 @外部人员吗？我们经常需要拉外部顾问进任务讨论。"
🧪 测试负责人的死亡追问
1.（尖锐） "IM 转任务的测试用例怎么写？'自动提取标题和描述'这个功能的通过标准是什么？提取 80% 准确算通过还是 95%？如果是人工判断，每个测试用例都得手动验证？"
2.（尖锐） "看板拖拽——拖到一半松手怎么处理？拖到无效区域怎么处理？两个状态之间拖拽有业务规则限制吗（比如'已完成'能不能拖回'待处理'）？并发拖拽同一个任务怎么处理？"
3.（一般） "逾期提醒的时区怎么处理？跨国团队的话，'24 小时前'是按哪个时区算？"
4.（一般） "多人分配的任务，谁可以标记完成？一个人标记完成是全部完成还是部分完成？"
看到这些问题，我的第一反应是：好多问题我确实没想过。
这就是 AI 模拟评审的价值——它帮你在会前"被怼"一遍，让你带着答案进会议室，而不是带着慌张。
4.2 准备应答方案
针对 AI 提出的每个尖锐问题，我逐一准备了应答。
同样可以用 AI 辅助：
我的 Prompt：
以下是我的产品方案在模拟评审中收到的质疑。请帮我针对每个问题准备应答：
要求：
1. 对于能回答的问题，给出清晰、有数据支撑的回答
2. 对于暂时无法确定的问题，给出"会后跟进"的建议方案
3. 对于确实存在的风险，给出"已知风险 + 缓解方案"
4. 对于需要调整方案的问题，给出调整建议
格式：每个问题用"应答策略 + 参考话术"的格式输出。
质疑列表：
[粘贴上一步 AI 模拟的质疑]
AI 输出示例（节选）：
质疑 1：IM 转任务的 NLP 提取准确率
应答策略： 降低预期 + 分阶段实现
参考话术： "关于 IM 转任务，第一期的实现方式不是 NLP 智能提取，而是规则提取：
- 取消息前 100 字作为任务描述（自动填入描述字段）
- 标题留空，由用户手动填写（必填）
- 打开创建表单时预填描述，用户可以修改后确认提交
这样做的好处是：
- 不依赖 NLP，技术实现简单，不会出错
- 用户始终有确认环节，不会出现'提取错误但已创建'的问题
- 后续第二期再引入 AI 智能提取，作为体验升级
这是'先保证可用，再追求好用'的思路。"
质疑 2：按角色自动分配的策略
应答策略： 明确策略 + 补充边界条件
参考话术： "自动分配的策略是最少任务优先：系统查询该角色下所有成员的当前任务数，分配给任务数最少的人。
边界条件：
- 角色下只有 1 人：直接分配给该人
- 角色下无人：提示'该角色暂无成员，请手动分配'
- 所有成员任务数相同：按加入团队的先后顺序分配
- 分配后可手动调整（不是强制的）
另外，会在'系统设置'中提供角色成员的管理界面，支持维护角色和人的对应关系。人员离职时，系统会自动将其名下未完成的任务标记为'待重新分配'。"
质疑 3：通知消息风暴
应答策略： 已考虑 + 给出具体方案
参考话术： "通知策略已经做了分级处理：
通知类型 推送范围 推送方式 任务创建 仅分配人 IM 通知 任务分配 仅被分配人 IM 通知 状态变更 任务关注者 站内信（不推 IM） @提醒 仅被@的人 IM 通知 截止提醒 仅分配人 IM 通知 逾期提醒 分配人 + 项目负责人 IM 通知 所以不会出现'一个变更发 50 条通知'的情况。只有和本人直接相关的操作才会推 IM 通知，其他信息通过站内信查看。"
质疑 5：6 周排期是否合理
应答策略： 诚实面对 + 给出分阶段方案
参考话术： "确实，6 个功能在 6 周内完成是有压力的。我准备了一个分阶段交付方案：
第一阶段（4 周）：
- 任务创建（仅手动创建）
- 看板视图（基础版，不含拖拽）
- 任务分配（仅单人分配）
- 截止时间与提醒
第二阶段（3 周）：
- 拖拽切换状态
- 多人分配 + 角色分配
- 模板创建
- IM 转任务
- 任务内评论
- IM 通知卡片操作
第一阶段上线后可以覆盖核心场景，业务方可以先用起来。第二阶段补充体验增强功能。"
这一步的价值： 我带着这组应答进评审会，当技术负责人问出"IM 转任务的 NLP 准确率"时，我直接回答"第一期不做 NLP，用规则提取 + 用户确认"，对方立刻点头——因为这不是临时想的借口，而是提前想好的方案。
4.3 生成评审材料清单
除了方案本身，AI 还可以帮你准备评审会需要的配套材料。
我的 Prompt：
我的产品方案评审会还有 2 天，参会人有：技术负责人、前端、UI 设计师、业务方、测试。
请帮我列出评审会前需要准备的完整材料清单，以及每份材料的准备要点。
重点关注：
1. 不同角色最关心什么材料？
2. 哪些材料应该提前一天发出去？
3. 有没有容易被忽略但很重要的材料？
AI 输出：
评审会材料清单
必须准备的材料：
序号 材料 目的 优先发给谁 1 PRD 文档 完整方案说明 全体 2 交互原型（可点击） 直观体验功能流程 UI 设计师、前端 3 信息架构图 展示模块结构和关系 技术负责人 4 状态流转图 任务从创建到关闭的完整流程 技术负责人、测试 5 功能优先级说明 P0/P1 的划分逻辑 业务方、技术负责人 6 已知风险清单 提前暴露风险 全体 7 排期方案（含分阶段） 时间预期对齐 业务方、技术负责人 提前 1 天发出的材料：
- PRD 文档 + 功能优先级说明 → 全体（哪怕没人看，也要体现"已提前告知"）
- 交互原型链接 → UI 设计师 + 前端（让他们有时间提前看交互）
容易忽略但重要的：
- 竞品参考截图：把竞品的同类功能截图带上。"别人是这样做的"比"我想这样做"更有说服力
- 用户调研结论：如果有用户反馈支撑某个功能决策，带上原始引用。"8 个用户里有 7 个提到这个痛点"比"我觉得用户需要"有效 100 倍
- 与现有功能的关系说明：明确这个功能和系统其他模块的关系，避免评审中反复问"这个和 XX 功能有什么区别"
- 上次评审的待确认项：如果不是第一次评审，务必把上次遗留的问题和结论带上——这是展示"你在推进"的最好方式
- 会议议程：提前发出 30 分钟的议程安排，让每个人知道"哪个环节和我相关"
五、会中：AI 辅助实时记录与聚焦
5.1 用 AI 做会议记录
评审会最大的问题之一是：讨论很热烈，但没人记录。 会后各人记忆中的结论不一致，又得拉会"对齐"。
如果你使用的是飞书/钉钉/Teams 等支持 AI 纪要的工具，直接开启会议录音转写即可。如果工具不支持，也可以用 AI 辅助整理。
会议结束后，我的 Prompt：
以下是今天产品方案评审会的笔记（由录音转写 + 手动补充）。
参会人：产品经理、技术负责人（张工）、前端（李工）、UI 设计师（王设计）、业务方（赵总）、测试（孙工）
会议时长：90 分钟（原定 60 分钟，超时 30 分钟）
请帮我整理成一份结构化的会议纪要，要求：
1. 按议题组织（不是按时间线）
2. 每个议题包含：讨论内容、争议点、结论、待确认项
3. 明确标注每个待确认项的负责人和截止时间
4. 单独列出"方案变更"——相比评审前的方案有哪些调整
5. 用 Markdown 格式输出
会议笔记：
[粘贴录音转写或手动笔记]
AI 输出的会议纪要（模拟）：
产品方案评审会纪要
日期： 2026-06-03 项目： 任务协作模块第一期 参会人： 全体（见上方）
议题一：任务创建方式
讨论内容：
- 确认第一期支持"手动创建"和"IM 转任务"，模板创建移至第二期
- IM 转任务的实现方式：规则提取（取前 100 字作为描述）+ 用户手动确认
争议点：
- 赵总提出"模板创建是高频需求，能否保留在第一期？"
- 讨论后结论：模板创建技术实现简单（数据配置），但需要业务方先梳理 3-5 个标准模板，业务方表示需要 1 周时间
结论： 模板创建保留在第一期，但需要业务方在 6 月 10 日前提供标准模板内容
待确认项：
- 业务方提供标准任务模板内容 → 赵总，6/10 前完成
议题二：看板视图
讨论内容：
- 确认看板视图的默认列：待处理、进行中、已完成
- 拖拽交互确认支持，使用成熟的拖拽组件库
争议点：
- 张工提出"拖拽涉及实时排序和持久化，50+ 任务时可能有性能问题"
- 王设计提出"卡片信息密度高，建议简化移动端卡片展示"
结论：
- 拖拽性能上限设为 200 条/列，超过时提示"请使用列表视图"
- 移动端卡片仅显示标题 + 分配人头像，PC 端显示完整信息
方案变更：
- 新增：单列任务数上限 200 条的性能限制说明
- 变更：移动端看板卡片信息精简（砍掉截止时间和优先级标签）
待确认项：
- 确认拖拽组件库选型 → 李工，6/7 前完成
- 移动端看板卡片设计方案 → 王设计，6/9 前完成
议题三：通知策略
讨论内容：
- 确认分级通知策略（IM 通知 vs 站内信）
- 孙工提出"站内信是否需要已读/未读状态？"
结论： 站内信支持已读/未读，但第一期不做"未读提醒弹窗"
待确认项：
- 站内信已读/未读的技术方案 → 张工，6/9 前完成
议题四：排期与分阶段方案
讨论内容：
- 赵总对 2 个月上线周期表示不满，希望压缩
- 张工评估后认为第一阶段（4 周）合理，但第二阶段需要根据第一阶段实际情况调整
结论：
- 采用分阶段交付方案
- 第一阶段 4 周开发 + 1 周测试，目标 7 月中旬上线
- 第二阶段排期待第一阶段启动后再评估
待确认项：
- 第一阶段详细排期（到功能级别的开发计划） → 张工 + 李工，6/12 前完成
方案变更汇总
变更项 评审前 评审后 原因 模板创建 第二期 保留第一期 业务方确认为高频需求 IM 转任务 NLP 提取 规则提取 + 确认 降低技术风险 看板拖拽 无上限 单列 200 条上限 性能保障 移动端卡片 完整信息 精简信息 信息密度和性能 排期 6+2 周 分阶段 4+1 周 满足业务时效需求
待确认项汇总
序号 待确认项 负责人 截止时间 1 标准任务模板内容 赵总 6/10 2 拖拽组件库选型 李工 6/7 3 移动端看板卡片设计 王设计 6/9 4 站内信技术方案 张工 6/9 5 第一阶段详细排期 张工 + 李工 6/12
5.2 用 AI 保持会议聚焦
除了记录，AI 还可以在另一个维度帮忙——防止会议跑题。
这个不需要用 Prompt，而是用一种我在实践中总结的"议题清单法"：
会前把议程发给所有人：
评审会议程（预计 60 分钟）
09:00-09:05 开场：方案概要回顾（产品）
09:05-09:15 议题一：任务创建方式（全员）
09:15-09:25 议题二：看板视图（技术+设计重点）
09:25-09:35 议题三：通知策略（技术重点）
09:35-09:45 议题四：排期确认（全员）
09:45-09:55 自由提问
09:55-10:00 待确认项汇总
然后在每个议题开始时说一句话：
"这个议题我们有 10 分钟，重点讨论 XX。如果有超出这个议题范围的问题，我们先记到'停车场'里，会后有需要再单独讨论。"
这个方法看起来简单，但实践下来能减少 50% 以上的会议跑题。
六、会后：AI 辅助沉淀与追踪
6.1 自动生成行动项追踪表
上面的会议纪要里已经有待确认项了。但光有清单不够，需要持续追踪。
我的 Prompt：
基于今天的评审会纪要，请生成一份行动项追踪表。
要求：
1. 每个行动项包含：编号、内容、负责人、截止时间、状态、优先级
2. 按截止时间排序
3. 标注前置依赖关系（如某项依赖另一项完成后才能开始）
4. 用 Markdown 表格格式
AI 输出：
行动项追踪表
编号 行动项 负责人 截止 优先级 状态 依赖 A-01 拖拽组件库选型 李工 6/7 P0 待开始 — A-02 移动端看板卡片设计 王设计 6/9 P1 待开始 — A-03 站内信技术方案 张工 6/9 P1 待开始 — A-04 标准任务模板内容 赵总 6/10 P0 待开始 — A-05 第一阶段详细排期 张工+李工 6/12 P0 待开始 A-01（组件选型影响排期） A-06 PRD 更新（方案变更） 产品经理 6/12 P0 待开始 A-01~A-04（需等确认项结论） 关键路径： A-01 → A-05 → A-06 风险提示： A-04（业务方提供模板）如果延期，模板创建功能可能需要移至第二期
6.2 方案迭代：基于评审结论更新 PRD
评审会后，方案通常需要调整。这时候可以回到上一篇的"AI 写 PRD"流程，用评审结论作为输入更新方案。
我的 Prompt：
以下是我的 PRD 原始方案和评审会的变更结论。请帮我生成更新后的 PRD 变更说明。
变更结论：
1. IM 转任务：从 NLP 提取改为规则提取 + 用户确认
2. 看板拖拽：新增单列 200 条上限
3. 移动端看板卡片：精简为标题 + 分配人头像
4. 模板创建：从第二期调整到第一期
5. 排期：改为分阶段交付（4+1 周）
对每个变更，请说明：
- 变更内容（原文 vs 修改后）
- 变更原因
- 影响范围
用 Markdown 输出，格式为变更对比表。
七、完整工作流全景
把三阶段合在一起看：
┌─────────────────────────────────────────────────────────────┐
│ AI 辅助评审工作流 │
└──────────────────────────┬──────────────────────────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌────▼─────┐ ┌─────▼──────┐ ┌─────▼──────┐
│ 会前准备 │ │ 会中执行 │ │ 会后沉淀 │
└────┬─────┘ └─────┬──────┘ └─────┬──────┘
│ │ │
┌────┼────┐ ┌───┼───┐ ┌───┼───┐
│ │ │ │ │ │ │ │ │
模拟 应答 材料 议程 记录 聚焦 纪要 行动项 PRD
评审 准备 清单 管理 整理 控制 生成 追踪 更新
效率对比：
| 工作项 | 传统方式 | AI 辅助 | 效率提升 |
|---|---|---|---|
| 会前：预判争议点 | 凭经验，容易遗漏 | AI 模拟 5 个角色，15 分钟出 20+ 问题 | 质和量都大幅提升 |
| 会前：准备应答 | 临时想，不够充分 | AI 辅助准备结构化应答 | 2 小时 → 30 分钟 |
| 会前：材料清单 | 容易遗漏 | AI 生成完整清单 | 10 分钟搞定 |
| 会中：会议记录 | 手写笔记，会后回忆 | AI 整理转写内容 | 1 天 → 30 分钟 |
| 会后：纪要和行动项 | 人工整理，容易漏 | AI 生成结构化纪要 | 2 小时 → 15 分钟 |
| 会后：PRD 更新 | 手动修改对比 | AI 辅助生成变更说明 | 1 小时 → 15 分钟 |
更重要的是质量提升：
- 会前模拟评审让我提前解决了 80% 的争议点，实际评审会只用了 60 分钟（原来经常超时到 90-120 分钟）
- 评审一轮通过，不需要第二轮（原来平均 2-3 轮）
- 会后行动项清晰，没有"会后各人理解不一致"的问题
八、踩坑与经验
陷阱 1：模拟评审≠真实评审
AI 模拟的问题质量很高，但它无法替代真实的人际互动。比如：
- 技术负责人可能不会直接问"你的 NLP 准确率是多少"，而是问"这个功能你打算怎么做？"— 然后在你的回答中找漏洞
- 业务方可能不会质疑某个具体功能，而是在会上突然提一个全新的需求（"能不能顺便加上 XX？"）
对策： AI 模拟是"预演"不是"替代"。把你从 AI 模拟中学到的应答内化，而不是背下来。会上要根据实际提问灵活应对。
陷阱 2：AI 生成的应答不能直接照搬
AI 给的应答参考话术通常比较"理想化"——逻辑清晰、措辞完整、滴水不漏。但真实的评审会上，你需要用自己的语言和风格来表达。
如果直接照搬 AI 的话术，你会像在"背稿"，反而显得不真诚。
对策： AI 给的应答是"弹药"，你需要自己决定"怎么开枪"。把关键论点记在心里，用自己的话说出来。
陷阱 3：过度准备导致"防御心态"
有时候准备了太多应答，进了评审会后心态变成"我要反驳每一个质疑"。这反而会让评审会变成对抗。
对策： 记住评审会的目标是"让方案更好"，不是"证明我是对的"。遇到好的质疑，直接说"这个点很好，我没考虑到，会后调整"。示弱比逞强更有力量。
陷阱 4：会后纪要发完就不管了
很多人发了会议纪要就觉得"评审完成了"。但现实中，待确认项经常无人跟进，下次开会又讨论同样的问题。
对策： 把行动项追踪表放在项目管理工具里（Jira/飞书项目/Notion），设置截止时间提醒。每 2-3 天主动跟进一次，确保所有待确认项按时关闭。
九、可复用的 Prompt 模板库
🎭 模板一：模拟评审
请分别扮演以下角色，对我的产品方案提出质疑：
1. 技术负责人（关注：技术可行性、架构影响、开发工作量）
2. 前端开发（关注：交互复杂度、组件复用、性能）
3. UI 设计师（关注：设计空间、交互一致性）
4. 业务方（关注：是否解决痛点、上线时间、ROI）
5. 测试（关注：可测试性、边界条件）
每个角色提 3-5 个问题，按尖锐程度排序，用该角色口吻提问。
【方案概要】
...
💬 模板二：应答准备
以下是我的方案在模拟评审中收到的质疑。请针对每个问题准备应答：
要求：
1. 能回答的给出有数据支撑的回答
2. 不确定的给出"会后跟进"建议
3. 确实有风险的给出"已知风险 + 缓解方案"
4. 需要调整的给出调整建议
格式："应答策略 + 参考话术"
质疑列表：
...
📋 模板三：材料清单
我的产品方案评审会还有 N 天，参会人有：【角色列表】。
请列出会前需要准备的完整材料清单：
1. 每份材料的准备要点
2. 不同角色最关心什么
3. 哪些需要提前发出
4. 容易遗漏的材料
📝 模板四：会议纪要
以下是产品评审会的笔记。
参会人：【列表】
会议时长：【X】分钟
请整理为结构化会议纪要：
1. 按议题组织
2. 每个议题：讨论内容、争议点、结论、待确认项
3. 待确认项标明负责人和截止时间
4. 单独列出"方案变更"汇总
5. Markdown 格式
会议笔记：
...
✅ 模板五：行动项追踪
基于以下会议纪要，生成行动项追踪表：
要求：
1. 每项含编号、内容、负责人、截止时间、状态、优先级
2. 按截止时间排序
3. 标注依赖关系
4. 指出关键路径和风险
会议纪要：
...
写在最后
回顾整个系列：
- 第一篇：用 AI 写 PRD —— 解决"从 0 到 1 的启动难"
- 第二篇：用 AI 做竞品分析和用户调研 —— 解决"信息收集和处理慢"
- 第三篇：用 AI 辅助产品评审 —— 解决"信息不对称导致评审低效"
你会发现一个共同的主题：
AI 最大的价值不是"替代你思考"，而是"消除你和高质量输出之间的效率鸿沟"。
在评审这个场景中，AI 帮你做到的事情是：
- 把单向的"汇报式评审"变成双向的"讨论式评审" —— 因为你提前解决了基础问题，会上可以聚焦真正需要讨论的决策
- 把模糊的"口头约定"变成清晰的"书面承诺" —— AI 辅助生成的纪要和行动项，让每个人的责任和截止时间一目了然
- 把"一次性评审"变成"持续追踪" —— 行动项追踪确保评审的结论真正落地
评审会不应该是产品经理的"受难日"，而应该是团队对齐认知、共同决策的"里程碑"。AI 能帮你的，就是让这个里程碑来得更快、更顺畅。
系列完。
感谢你读到这里。如果这个系列对你有帮助，欢迎分享给你的产品经理朋友们。
如果你在实践中遇到了什么问题，或者有更好的 AI 辅助产品工作的方法，欢迎评论区交流。
本文基于真实项目经验整理，案例中的人名和会议细节已做脱敏处理。
