产品方案评审记录要同时做到三件事：留下讨论痕迹、让结论可追踪、方便事后复盘。下面以一次假设的“会员积分改版方案”评审为演示情景，给出一份从头到尾填写完整的记录范例，并逐项解释每个字段为什么这样写、哪些写法可以迁移到其他方案评审、哪些情况需要调整。示例为假设情景，非真实客户案例。
要点总览（TL;DR）
- 产品方案评审记录至少包含会议信息、评审对象、参会角色、逐条意见、结论与待办六部分，示例以假设的“会员积分改版方案”评审完整演示一遍。
- 评审对象写到版本与范围，意见写成可判断是否完成的具体表述，结论区分通过、有条件通过、退回，待办带负责人、截止时间和完成标志。
- 可迁移的做法是按评审维度分组记录意见、把争议点与结论分开写、让每条待办对应到方案文档的具体修订位置。
- 方案规模、评审层级、跨部门或外部参与会改变字段设置；记录人如实记录，结论效力来自评审组织者或决策人确认。
这份示例要示范什么
这份示例要回答的核心问题是：一份产品方案评审记录应该包含哪些内容，写成什么样才算完整。读者拿到范例后，应当能对照自己的评审场景，判断哪些字段必须填、哪些字段可以按需增减。
示例设定为一次方案评审会：产品团队提出“会员积分改版方案”，涉及积分获取规则、积分消耗场景和等级权益调整，参会方包括产品、研发、运营、客服和数据分析。评审阶段处于方案初稿完成、进入研发评估之前，属于方案层面的沟通与验证，不涉及视觉设计与原型制作细节。
这份记录要达到三个效果。留痕：会后任何人翻看记录，都能知道当时讨论了什么、谁提出了什么意见。可追踪：每条待办都有负责人和时间，能判断是否闭环。可复盘：结论和争议点分开记录，方案上线后回看时能还原当时的判断依据。
示例覆盖的方案类型是业务规则类改版方案，评审阶段是方案初稿评审。其他类型方案（如新功能从零设计、系统迁移方案）可以沿用字段结构，但评审维度和参会角色需要按实际情况调整。
完整示例：会员积分改版方案评审记录
以下为一份填写完整的评审记录范例，所有人员姓名、数据和时间均为演示设定。
会议基本信息与评审对象
| 字段 | 填写内容 |
|---|---|
| 会议主题 | 会员积分改版方案评审 |
| 评审时间 | 2024年6月12日 14:00–15:30 |
| 评审地点 | 线上会议 |
| 评审对象 | 《会员积分改版方案》V0.3，覆盖积分获取规则、积分消耗场景、等级权益三部分；不含前端页面视觉稿 |
| 主持人 | 产品负责人 张明 |
| 记录人 | 产品经理 李婷 |
| 评审目的 | 确认改版方向与核心规则，识别研发与运营风险，决定是否进入研发评估 |
参会角色与关注点
| 角色 | 参会人 | 主要关注点 |
|---|---|---|
| 产品 | 张明、李婷 | 方案目标、规则完整性、与现有会员体系的一致性 |
| 研发 | 王磊 | 积分规则变更对现有账户体系的影响、历史数据兼容 |
| 运营 | 陈芳 | 积分发放成本、活动配置灵活性、用户沟通节奏 |
| 客服 | 赵倩 | 规则变更后的用户咨询口径、历史积分处理说明 |
| 数据分析 | 周航 | 积分发放与消耗的统计口径、效果评估指标 |
逐条评审意见
| 序号 | 评审维度 | 意见内容 | 提出人 | 处理方式 |
|---|---|---|---|---|
| 1 | 业务规则 | 积分获取从“按订单金额”改为“按商品类目差异化比例”，需要明确类目比例表由谁维护、多久更新一次 | 陈芳 | 方案补充类目比例维护责任人与更新周期 |
| 2 | 技术影响 | 历史积分余额是否需要按新规则折算，若不折算，新旧规则并存期间的用户解释成本较高 | 王磊 | 列为遗留问题，由产品与运营一周内给出折算方案 |
| 3 | 用户体验 | 等级权益调整涉及降级规则，需明确降级前是否提供保级提醒 | 赵倩 | 方案增加保级提醒触达节点 |
| 4 | 数据口径 | 积分消耗率的分母应统一为“当期发放积分”，避免与“累计积分”混用 | 周航 | 方案指标定义章节按此口径修订 |
| 5 | 运营配置 | 积分活动配置需要支持按人群圈选，当前方案只写了全量发放 | 陈芳 | 纳入方案二期范围，一期先做全量 |
评审结论与遗留问题
评审结论：有条件通过。方案方向与核心规则获得认可，可以进入研发评估；需在研发评估前完成三项修订：补充类目比例维护机制、明确保级提醒触达节点、统一积分消耗率统计口径。
遗留问题：历史积分余额的折算方案尚未确定，由产品与运营在一周内补充，补充后以书面形式同步参会人确认，不再单独召开评审会。
待办事项
| 待办事项 | 负责人 | 截止时间 | 完成标志 |
|---|---|---|---|
| 补充类目比例维护责任人与更新周期 | 李婷 | 6月14日 | 方案文档更新并同步群内 |
| 给出历史积分折算方案 | 李婷、陈芳 | 6月19日 | 书面说明经王磊确认 |
| 增加保级提醒触达节点 | 李婷 | 6月14日 | 方案文档更新 |
| 修订积分消耗率统计口径 | 周航 | 6月14日 | 指标定义章节更新 |
| 确认一期范围不含人群圈选配置 | 张明 | 6月13日 | 范围说明写入方案 |
逐项解释：每个字段为什么这样填
评审对象要写到版本与范围。示例中写的是“《会员积分改版方案》V0.3，覆盖积分获取规则、积分消耗场景、等级权益三部分；不含前端页面视觉稿”，这样记录能对应到具体文档版本，事后复盘时不会出现“当时评的是哪一版”的争议。常见错误写法是只写“积分改版方案”，缺少版本号和范围边界，导致后续修订无法与评审结论对应。
意见要写成可判断的具体表述。示例第1条写“需要明确类目比例表由谁维护、多久更新一次”，这是一个可以判断是否完成的要求；如果写成“类目比例需要再讨论”，会后无法判断讨论到什么程度算结束。每条意见还应带上提出人，便于后续澄清时找到原始语境。
结论要区分通过、有条件通过、退回三种状态。示例给出“有条件通过”，并紧接着列出通过的前提条件，条件与结论相邻，读者不会误以为方案已无条件放行。退回适用于方案存在方向性问题、需要重新提交评审的情况；无条件通过则适用于无需修订即可进入下一环节的情况。三种状态的选择依据是修订项是否影响方案主体，而不是意见条数的多少。
待办要带负责人和截止时间，最好再加一个完成标志。示例中“书面说明经王磊确认”就是完成标志，它把“做完了”变成可核验的状态。只有事项没有负责人，待办会在会后迅速失焦；只有负责人没有时间，跟踪时缺少判断依据。
记录中的争议点与结论分开写。示例把“历史积分是否折算”放在遗留问题里，把已经达成的结论放在结论段，两者不混在一起。这样复盘时能清楚看到哪些是当时已定的判断，哪些是留待补充的开放项。
从这份示例能迁移出什么
按评审维度分组记录意见，是这份示例最值得迁移的做法。示例用了业务规则、技术影响、用户体验、数据口径、运营配置五个维度，每个维度下的意见归属清晰。换到其他方案评审时，维度可以替换为安全合规、成本预算、上线节奏等，但“先分维度再列意见”的结构保持不变，这样参会人按自己关注的维度阅读，也便于统计哪类问题反复出现。
把争议点与结论分开写，是第二条可迁移规律。评审会上往往既有共识也有分歧，记录如果按发言顺序流水账式记录，会后很难分辨哪些已经定案。把结论单独成段、把未决事项列入遗留问题，能让记录同时承担“决议”和“待议”两种功能。
记录要与后续跟踪衔接。示例的每条待办都能对应到方案文档的具体章节修订，完成标志也指向文档更新或书面确认。迁移到自己的评审时，可以在待办中直接写明“更新方案第几节”，让记录成为方案修订的入口，而不是一份会后就归档的会议纪要。
当评审记录需要承载意见流转和待办状态时，可以借助 ONES 这类研发管理工具：把评审意见作为工作项关联到方案文档，待办分配给负责人并设置截止时间，结论与遗留问题随文档版本一起留存，后续修订和确认在同一处完成，减少记录与执行脱节的情况。是否采用工具承载，取决于团队已有的协作习惯和评审频次。
示例的适用边界
方案规模与评审层级不同时，字段需要增减。小型方案评审可能只有产品与研发两方参加，参会角色表可以简化为一行；涉及多团队的大型方案，可能需要分层评审，此时记录应标明本次评审属于哪一层级、上一层级结论是什么，避免不同层级的结论互相覆盖。
跨部门或外部评审需要额外字段。涉及法务、财务或外部合作方时，记录中应补充合规意见、预算审批意见和保密要求；外部参会人的意见需要注明其身份和授权范围，便于判断意见的约束力。这类评审的记录通常还需要在会后发送确认邮件，记录中可增加“确认方式”字段。
记录与决策权限要区分开。记录人负责如实记录讨论与结论，评审结论的效力来自评审组织者或决策人的确认。示例中主持人与记录人分开设置，就是为了避免记录人替决策人下结论。若评审会上未能形成明确结论，记录应如实写“未形成结论，另行安排评审”，而不是用模糊表述代替决策。
这套写法适合方案层面的沟通与验证，不覆盖视觉设计与原型制作的具体评审标准，也不涉及需求质量评审的判定细则，遇到这些场景时需要结合相应的方法另行设计记录字段。
常见问题
评审会上意见很多但没有形成明确结论，记录该怎么写？
如实写“本次评审未形成结论，另行安排评审”，并注明未决的原因和下一步安排。不要用“基本认可”“原则上同意”这类模糊表述代替决策，也不要由记录人自行归纳出一个结论。未决事项应逐条列入遗留问题，写明由谁在什么时间前补充材料或组织复议，这样下一次评审可以直接接着讨论。
评审意见和待办是什么关系，需要一条意见对应一条待办吗？
两者不必一一对应。意见是会上提出的判断和疑问，待办是会后要执行的动作。有的意见当场确认无需修改，只作为讨论痕迹保留；有的意见会拆成多条待办，比如“补充类目比例维护机制”可能同时涉及文档修订和责任人确认。建议在意见表中加一列“处理方式”，写明该意见是采纳修订、列入遗留问题还是记录备查，再在待办表中只列需要执行的事项，避免待办表变成意见的重复抄写。
跨部门评审时，法务、财务的意见怎么记录才有约束力？
记录中要注明参会人的部门、身份和授权范围，意见按提出人归属，避免把某个人的个人看法写成部门结论。涉及合规、预算的明确意见，应记录其依据和适用条件，并在会后通过确认邮件或书面回复固定下来。记录本身是过程留痕，约束力来自有权决策人的确认，因此建议在记录中增加“确认方式”字段，写明结论经谁确认、以什么形式确认。
方案经过多轮评审，多份记录之间怎么衔接？
每份记录都应标明评审对象的具体版本和本次评审所属层级，并在开头引用上一轮结论与遗留问题的处理情况。这样翻看任意一份记录，都能知道它是第几轮、承接了哪些未决事项、本轮又新增了什么。若方案版本发生较大调整，建议在记录中说明调整原因，避免后续复盘时把不同版本的结论混在一起。
用文档工具还是研发管理工具承载评审记录更合适？
取决于评审频次和后续跟踪的复杂度。评审较少、以文档讨论为主的团队，用文档工具按模板填写即可满足留痕需求；评审频繁、意见和待办需要持续跟踪闭环的团队，可以把评审意见作为工作项关联到方案文档，待办分配负责人并设置截止时间，结论随文档版本留存。ONES 的文档协同与项目管理能力可以承载这类场景，具体采用哪种方式，按团队已有的协作习惯决定。
