产品方案评审记录至少要保留五类信息：评审对象与版本、参会角色与职责、评审结论与决策、问题与修改项、依据与附件。这份模板以表格承载，适合方案初评、原型评审和方案定稿等场景使用；字段分为必填与选填，评审结束后由记录人归档，并在下次评审前复核未关闭项。
要点总览（TL;DR）
- 产品方案评审记录至少保留五类信息：评审对象与版本、参会角色与职责、评审结论与决策、问题与修改项、依据与附件。
- 必填项以能否追溯结论、能否关闭问题项为标准：结论类型、决策人、问题描述、责任人、截止时间不能省，其余字段可按评审阶段调整。
- 问题项按一条问题一行记录，每条拥有独立编号、责任人和状态，避免合并后无法单独关闭。
- 评审结束后由记录人按方案名称和版本号归档，下次评审前复核未关闭项，有条件通过的条件需有确认人和确认记录。
- 模板调整看两个信号：字段长期无人填写可删或转选填，同类问题反复口头补充应补入模板并更新字段说明。
可复制的产品方案评审记录空白模板
下面这张表可以直接复制到文档或表格工具中使用。表格分为表头信息、参会角色、评审结论、问题与修改项、附件与依据五个区域，填写时按区域顺序完成即可。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 方案名称 | |
| 版本号 | |
| 评审日期 | |
| 评审阶段 | □ 方案初评 □ 原型评审 □ 方案定稿 |
| 关联需求 | |
| 原型/方案链接 | |
| 记录人 |
参会角色区
| 角色 | 姓名 | 职责说明 |
|---|---|---|
| 主持人 | ||
| 方案主讲 | ||
| 评审人 | ||
| 记录人 |
评审结论区
| 字段 | 填写内容 |
|---|---|
| 结论类型 | □ 通过 □ 有条件通过 □ 退回修改 |
| 结论条件 | |
| 决策人 | |
| 结论说明 |
问题与修改项明细表
| 编号 | 问题描述 | 类型 | 严重程度 | 责任人 | 截止时间 | 状态 |
|---|---|---|---|---|---|---|
| P-01 | ||||||
| P-02 | ||||||
| P-03 |
附件与依据区
| 附件类型 | 名称或链接 | 说明 |
|---|---|---|
| 会议材料 | ||
| 原型截图 | ||
| 数据说明 | ||
| 后续验证方式 |
每个字段记录什么：字段说明与填写口径
字段名统一之后，不同人填出的记录才能互相对照、便于检索。下面逐字段说明含义和填写口径，并列出常见错误，供填写时自查。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 方案名称 | 本次评审的方案主题 | 使用与需求或项目文档一致的正式名称，便于后续检索 | 写成“方案讨论”这类无法定位对象的泛称 |
| 版本号 | 被评审方案的版本标识 | 与原型或文档上的版本号一致；同一方案多次评审时逐次递增 | 只写日期不写版本，导致无法判断评审的是哪一稿 |
| 评审阶段 | 本次评审所处的环节 | 在初评、原型评审、定稿中勾选一项 | 多个阶段混在一次记录中，结论无法对应具体版本 |
| 关联需求 | 方案对应的需求条目 | 填写需求编号或需求标题，保证从记录能回到需求 | 留空，后续无法追溯方案为何而做 |
| 原型/方案链接 | 被评审材料的访问地址 | 填写可访问的原型或文档链接，并注明访问权限要求 | 只写“见群文件”，链接失效后记录失去依据 |
| 主持人 | 组织并推进评审的人 | 记录姓名并注明其职责，如控制议程、确认结论 | 只写姓名，人员变动后无法判断谁对结论负责 |
| 方案主讲 | 讲解方案的人 | 记录姓名与讲解范围 | 与主持人混为一人且不注明，职责边界不清 |
| 评审人 | 给出评审意见的人 | 列出全部评审人及其关注领域，如产品、技术、运营 | 只写“相关同事”，意见来源无法追溯 |
| 记录人 | 整理并归档记录的人 | 记录姓名，并约定记录发出时间 | 多人同时记录，内容重复或互相矛盾 |
| 结论类型 | 本次评审的总体判定 | 在通过、有条件通过、退回修改中选一项，不写模糊表述 | 写“基本通过”，后续无法判断是否需要再次评审 |
| 结论条件 | 有条件通过时需满足的前提 | 逐条写明条件内容、验证方式和确认人 | 只写“修改后再看”，条件不可核验 |
| 决策人 | 对结论负责的人 | 记录姓名与角色，结论以其确认为准 | 结论由多人口头默认，出现分歧时无人拍板 |
| 问题编号 | 问题项的唯一标识 | 按 P-01、P-02 顺序编号，与记录内其他位置引用一致 | 编号重复或中途重排，跟踪时对不上 |
| 问题描述 | 需要修改或确认的具体内容 | 一条问题一行，写清现状、期望和影响范围 | 把三条意见写进一格，状态无法分别更新 |
| 类型 | 问题的归属类别 | 按团队约定分类，如流程逻辑、交互、数据、范围 | 分类过多过细，填写时难以选择 |
| 严重程度 | 问题对方案推进的影响 | 分为阻塞、重要、一般三档，并说明判定依据 | 全部标为“重要”，优先级失去区分度 |
| 责任人 | 负责修改或答复的人 | 写具体姓名，不写团队或岗位代称 | 写“产品组”，实际无人认领 |
| 截止时间 | 问题关闭的时间要求 | 填写具体日期，与下次评审时间衔接 | 写“尽快”，无法纳入跟踪 |
| 状态 | 问题当前处理进度 | 使用待处理、处理中、待确认、已关闭四种状态 | 只在会后口头更新，记录长期停留在初始状态 |
| 附件与依据 | 支撑评审判断的材料 | 按类型登记名称或链接，注明与哪条结论或问题相关 | 附件散落在聊天记录中，归档时缺失 |
角色字段记录职责而非仅记录姓名，原因在于评审记录要在会后被不同的人使用。几个月后回看时，姓名可能已经调岗，职责说明仍能帮助判断当时谁对结论负责、谁提出了哪类意见。问题项按一条问题一行记录，是为了让每条问题拥有独立的责任人、截止时间和状态，避免合并记录后无法单独关闭。
必填与选填：哪些信息不能省
必填项的判断标准是：缺少后是否还能追溯评审结论、是否还能关闭问题项。按这个标准，结论类型、决策人、问题描述、责任人和截止时间属于不能省的部分；其余字段可以按评审阶段和评审轻重调整。
| 字段 | 建议属性 | 理由或适用场景 |
|---|---|---|
| 方案名称、版本号 | 必填 | 缺少则无法定位被评审的是哪一版方案 |
| 评审日期、评审阶段 | 必填 | 用于排序和判断结论的时效 |
| 关联需求 | 必填 | 建立方案与需求的对应关系，便于回溯 |
| 原型/方案链接 | 原型评审必填 | 初评阶段可只填方案文档链接 |
| 主持人、记录人 | 必填 | 明确记录责任与结论确认路径 |
| 方案主讲、评审人 | 必填 | 意见来源需要可追溯 |
| 结论类型、决策人 | 必填 | 记录的核心产出，缺失则评审无法形成决定 |
| 结论条件 | 有条件通过时必填 | 通过或退回时可留空或简述原因 |
| 问题描述、责任人、截止时间、状态 | 必填 | 问题项可跟踪、可关闭的基础 |
| 问题类型、严重程度 | 建议填写 | 用于排序和统计；轻量评审可只标严重程度 |
| 会议材料、数据说明 | 选填 | 有数据论证或外部材料时登记 |
| 后续验证方式 | 有条件通过时建议填写 | 说明条件如何被验证，避免二次评审时重复讨论 |
按评审阶段调整时，方案初评的重点是方向与范围，必填项集中在方案名称、版本、关联需求、结论和主要分歧；原型评审需要保留原型链接、交互类问题项和截图附件；方案定稿阶段则应补齐决策人、结论条件和后续验证方式，确保结论可以直接进入开发排期。
轻量评审可以简化，例如两三人对一个小范围调整做快速确认时，可以合并主持人与记录人、省略问题类型字段，但结论类型、决策人和问题责任人仍应保留。简化的是格式，不是可追溯性。
填写示例：一次原型评审记录怎么填
以下示例为演示情景，用于说明各字段的填写方式，不代表真实项目数据。
示例背景与评审对象
某团队对“订单列表批量导出”方案进行原型评审，评审对象为第二版交互原型，关联需求为订单管理模块下的导出能力需求。
表头与角色区填写
| 字段 | 填写内容 |
|---|---|
| 方案名称 | 订单列表批量导出方案 |
| 版本号 | V2.0 |
| 评审日期 | 2025-03-12 |
| 评审阶段 | 原型评审 |
| 关联需求 | 订单管理-批量导出（需求编号示例：REQ-0312） |
| 原型/方案链接 | 原型文件链接（需项目成员权限访问） |
| 记录人 | 记录人A |
| 角色 | 姓名 | 职责说明 |
|---|---|---|
| 主持人 | 产品负责人B | 控制议程，确认结论 |
| 方案主讲 | 产品经理C | 讲解导出流程与交互设计 |
| 评审人 | 技术负责人D、运营E | 分别关注实现成本与导出字段完整性 |
| 记录人 | 记录人A | 会后一个工作日内发出记录 |
结论与条件填写
结论类型勾选“有条件通过”。结论条件写为：导出字段范围需与运营确认后补充到方案中；大批量导出的等待提示需补充交互说明。决策人为产品负责人B，结论说明中注明条件满足后由主讲人更新方案，不再单独召开评审。
三条问题项的完整填写
| 编号 | 问题描述 | 类型 | 严重程度 | 责任人 | 截止时间 | 状态 |
|---|---|---|---|---|---|---|
| P-01 | 导出字段清单缺少订单备注字段，运营确认是否需要加入 | 数据范围 | 重要 | 产品经理C | 2025-03-14 | 处理中 |
| P-02 | 超过一万条记录导出时的等待提示未设计，需补充进度与取消操作 | 交互 | 阻塞 | 产品经理C | 2025-03-17 | 待处理 |
| P-03 | 导出失败后的重试入口位置不明确，需在原型中标注 | 交互 | 一般 | 设计F | 2025-03-17 | 待处理 |
附件与后续验证安排
附件区登记会议材料（方案说明文档）、原型截图（导出入口与结果页）、数据说明（当前订单量级与导出频率的估算）。后续验证方式写为：P-02 完成后由技术负责人D确认交互方案可实现，P-01 由运营E在字段清单更新后确认，两项确认结果附在记录末尾，作为条件关闭的依据。
模板的调整与维护：让记录持续可用
模板需要随团队和评审阶段演进，但调整应有判断标准，避免每次评审都换一种格式。字段增删可以看两个信号：某个字段连续多次评审无人填写，说明它不承担实际判断；某类问题反复在会后口头补充，说明缺少对应字段。前者可以删除或转为选填，后者应补入模板并同步更新字段说明。
评审结束后，记录人应在约定时间内完成归档。归档时按方案名称和版本号命名，放入与项目或需求对应的文档位置，并在记录中保留原型链接和附件。检索时以方案名称、需求编号和评审日期为主要入口，方便后续按需求回溯历次评审结论。
未关闭问题项需要单独的跟踪节奏。建议在每次评审开始前复核上次记录的未关闭项，逐条更新状态；临近截止时间仍未关闭的，由记录人提醒责任人。状态更新以记录为准，口头确认后也要回写到问题项中。对于有条件通过的方案，条件关闭应有明确的确认人和确认记录，避免条件长期悬置。
模板本身也需要版本管理。字段增删、口径变化时，在模板末尾记录变更日期、变更内容和确认人，旧记录保持原样，新记录使用新版本。这样回看历史记录时，能判断当时使用的是哪一版模板。
产品方案评审记录与需求评审记录的分工边界可以这样划分：需求评审记录围绕需求是否成立、范围是否清晰、验收标准是否明确；方案评审记录围绕方案如何实现、交互与流程是否可行、修改项如何关闭。两者可以互相引用需求编号，但结论和问题项分别记录，避免一份记录承担两类判断。
当评审记录需要长期保存并与项目工作衔接时，可以借助文档工具承载。ONES Wiki 支持文档关联项目任务，页面组可关联项目，需求与文档能够互相对应，适合把评审记录放在与需求相同的项目上下文中；文档记录页面版本并支持查看与回滚，便于追溯记录的修改过程。问题项的指派与状态跟踪，可以按团队实际配置与工作项配合使用，具体关联方式以团队环境和实际配置为准。
常见问题
评审记录里的问题项和需求评审记录的问题项要不要合并成一张表？
建议分开记录，用需求编号互相引用。需求评审记录的问题项围绕需求是否成立、范围是否清晰、验收标准是否明确；方案评审记录的问题项围绕方案如何实现、交互与流程是否可行。两类问题项的关闭条件不同，合并后容易出现一条记录承担两类判断、状态难以分别更新的情况。如果团队规模小、评审频次低，可以在同一文档中分两个表区记录，但结论和问题项仍按两类分开。
评审会上口头确认了修改意见，但责任人当场没空确认截止时间，记录该怎么处理？
记录人可以先在问题项中填入责任人姓名和“待确认”的截止时间，并在记录发出时单独列出这些待确认项，请责任人在约定时间内回复具体日期。截止时间未确认前，该问题项状态保持“待处理”，不因口头同意而视为已安排。下次评审前复核时，仍未确认截止时间的项应作为未关闭项提醒，避免问题长期悬置。
有条件通过的方案，条件关闭需要留下什么记录？
条件关闭至少留下三项内容：条件对应的原始问题编号、确认人姓名与角色、确认时间和确认依据（如更新后的原型链接、字段清单或验证结果）。确认结果附在原评审记录末尾，并把问题项状态更新为“已关闭”。如果条件涉及多人确认，逐项记录各自的确认结果，避免只写一句“条件已满足”而无法回溯是谁确认的。
用文档工具承载评审记录时，需要注意哪些衔接问题？
重点看三件事：记录能否放在与需求相同的项目上下文中，方便按需求回溯历次评审；文档版本是否可查看和回滚，便于追溯记录修改过程；问题项的指派与状态跟踪能否与团队实际使用的工作项配合。以 ONES Wiki 为例，页面组可关联项目，需求与文档能够互相对应，文档记录页面版本并支持查看与回滚，适合把评审记录放在项目上下文中保存。问题项与工作项的具体关联方式，以团队环境和实际配置为准。
轻量评审简化到什么程度仍然可用？
可以合并主持人与记录人、省略问题类型字段、减少附件登记，但结论类型、决策人和每条问题的责任人应保留。判断标准是：会后其他人能否凭这份记录知道方案是否通过、谁拍的板、还有哪些事没做完、由谁在做。这三件事答不上来，简化就过头了。
