需求评审记录的价值在于会后还能还原“谁在什么时间评审了哪条需求、提出了什么意见、最终怎么定、后续谁跟进”。本文提供一张可直接复制到文档或表格工具中的空白模板，覆盖评审基本信息、需求条目、评审意见、结论与待办五类字段，并逐项说明填写口径、区分必填与选填，最后用一条完整示例演示落笔方式。
要点总览（TL;DR）
- 模板以一张可复制的空白表为核心，覆盖评审基本信息、需求条目、评审意见、结论、待办五类字段，一次评审多条需求时基本信息保留一份、需求条目按条扩展。
- 必填项按“缺了就不可追溯或不可跟踪”判断：评审编号、主题、日期、参会人员、记录人、需求编号与描述、意见内容与提出人、评审结论与确认人；待办在结论为有条件通过或退回修改时必填。
- 选填项按评审频次和参与角色取舍：地点、主持人、需求来源、优先级建议、意见类型、结论说明、待办状态等，小范围口头确认可精简，跨部门协作再逐步补回。
- 填写示例演示一条需求从意见编号、结论选项到待办责任人与日期的完整落笔方式，意见写成可判断的具体问题，结论与待办一一对应。
- 模板需指定负责人、按季度或流程变化时调整，保留版本号与变更说明，已归档记录按原版本保留。
需求评审记录空白模板（可直接复制）
下表按“基本信息—需求条目—评审意见—结论—待办”的顺序排列，复制到 Word、在线文档或电子表格后，把每一行当作一条记录使用。一次评审涉及多条需求时，保留一份基本信息，需求条目区按条扩展。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 评审基本信息 | 评审编号 | |
| 评审主题 | ||
| 评审日期与时间 | ||
| 评审地点 / 会议方式 | ||
| 主持人 | ||
| 参会人员及角色 | ||
| 记录人 | ||
| 需求条目 | 需求编号 | |
| 需求名称 | ||
| 需求提出人 / 来源 | ||
| 需求描述 | ||
| 关联目标或业务场景 | ||
| 优先级（建议） | ||
| 评审意见 | 意见编号 | |
| 提出人 | ||
| 意见内容 | ||
| 意见类型（疑问 / 修改建议 / 风险提示 / 补充信息） | ||
| 结论 | 评审结论（通过 / 有条件通过 / 退回修改 / 暂缓） | |
| 结论说明 | ||
| 结论确认人 | ||
| 确认时间 | ||
| 待办与跟踪 | 待办事项 | |
| 责任人 | ||
| 计划完成时间 | ||
| 状态（未开始 / 进行中 / 已完成） | ||
| 关闭说明 |
如果评审以逐条过需求的方式进行，可以把“需求条目—评审意见—结论—待办”做成横向表头，每条需求占一行，意见和待办用编号与正文区分，便于会后按行检索。
每个字段记录什么：逐项说明
字段的作用是让记录在会后可查、可追、可交接。以下按区域说明填写口径，字段名称与上表保持一致。
基本信息字段
- 评审编号：团队内部唯一标识，建议包含日期或流水号，便于与其他记录、需求条目互相引用。
- 评审主题：一句话说明本次评审的范围，例如“第二季度会员权益需求评审”，避免只写“需求评审”。
- 评审日期与时间、地点或会议方式：记录实际发生的时间与形式，线上会议注明所用会议工具即可。
- 主持人：对评审节奏和结论负责的人，通常是产品负责人或需求负责人。
- 参会人员及角色：写明姓名与角色（产品、研发、测试、设计、业务方等），用于判断意见的覆盖面和后续追责。
- 记录人：负责当场记录并会后整理的人，与主持人分开更利于记录完整。
需求条目字段
- 需求编号与名称：与需求池或需求管理工具中的编号保持一致，名称用业务语言描述，避免内部代号。
- 需求提出人与来源：记录提出人及渠道（客户反馈、业务部门、数据分析等），便于后续回溯背景。
- 需求描述：用两三句话写清用户场景、期望结果和范围边界，不粘贴整份需求文档。
- 关联目标或业务场景：说明这条需求支撑的业务目标，评审时用于判断优先级是否合理。
- 优先级（建议）：记录评审中形成的优先级建议，注明是建议值，最终以排期结论为准。
评审意见与结论字段
- 意见编号、提出人、意见内容：一条意见一行，内容写成可判断的具体表述，例如“缺少异常订单的处理规则”，避免“再想想”这类无法跟踪的记录。
- 意见类型：用疑问、修改建议、风险提示、补充信息四类归类，方便统计争议集中点。
- 评审结论：从通过、有条件通过、退回修改、暂缓中选一项，不用模糊措辞代替。
- 结论说明：写清结论的依据，有条件通过时把条件写在这里，并与待办区对应。
- 结论确认人与确认时间：记录对结论负责的人及确认时点，避免会后对结论产生分歧。
待办与跟踪字段
- 待办事项：写成可交付的动作，例如“补充异常订单处理规则并更新需求文档”，而不是“跟进一下”。
- 责任人与计划完成时间：每项待办只对应一个责任人，时间写到具体日期。
- 状态与关闭说明：状态随进展更新，关闭时写明完成情况或不再推进的原因，形成闭环。
哪些必填、哪些选填
必填项的判断标准是：缺少它，记录就无法追溯或无法跟踪。其余字段按评审频次和团队规模决定是否保留。
| 字段 | 要求 | 理由与适用场景 |
|---|---|---|
| 评审编号、评审主题、评审日期 | 必填 | 构成记录的唯一身份，缺一项就难以在历史记录中定位 |
| 参会人员及角色、记录人 | 必填 | 决定意见的代表性和记录的可靠性 |
| 需求编号、需求名称、需求描述 | 必填 | 评审对象本身，缺失则记录失去意义 |
| 评审意见内容、提出人 | 必填 | 评审过程的核心证据，也是后续修改的依据 |
| 评审结论、结论确认人 | 必填 | 没有结论的记录无法驱动下一步动作 |
| 待办事项、责任人、计划完成时间 | 结论为有条件通过或退回修改时必填 | 结论附带条件时，待办是落实条件的载体 |
| 评审地点 / 会议方式、主持人 | 选填 | 线上评审为主或主持人固定时，可简化 |
| 需求提出人 / 来源、关联目标 | 选填 | 需求池中已有来源信息时可省略；涉及优先级争议时建议保留 |
| 优先级（建议）、意见类型 | 选填 | 评审频次高、意见量大时，分类统计有助于发现反复出现的问题 |
| 结论说明、确认时间、待办状态与关闭说明 | 选填 | 小团队口头同步充分时可精简；跨部门协作或周期较长时建议保留 |
调整时把握一个原则：评审越频繁、参与角色越多，越需要保留分类和跟踪字段；两三人小范围、结论当场口头确认的评审，可以只保留必填项加待办。团队规模扩大或评审改为跨部门进行后，再把选填项逐步补回，比一开始就填满所有字段更容易坚持。
完整填写示例：一条需求走完评审
以下为演示情景，人物与数据均为虚构，用于对照字段填写口径。
示例背景：某电商团队在周三下午评审“订单取消后自动退款”需求，参会人有产品经理林某（主持人）、研发负责人周某、测试负责人吴某、客服业务方郑某，记录人为产品助理陈某。
| 字段 | 填写内容 |
|---|---|
| 评审编号 | REV-2025-0312 |
| 评审主题 | 订单取消自动退款需求评审 |
| 评审日期与时间 | 2025年3月12日 14:00–15:00 |
| 评审地点 / 会议方式 | 线上会议 |
| 主持人 | 林某（产品经理） |
| 参会人员及角色 | 林某（产品）、周某（研发）、吴某（测试）、郑某（客服业务方） |
| 记录人 | 陈某（产品助理） |
| 需求编号 | REQ-1042 |
| 需求名称 | 订单取消后自动发起退款 |
| 需求提出人 / 来源 | 客服业务方郑某，来源为近一个月客服工单统计 |
| 需求描述 | 用户取消已支付订单后，系统自动发起原路退款，减少客服手工操作；覆盖未发货订单，已发货订单仍走人工流程 |
| 关联目标或业务场景 | 降低取消订单的退款处理时长，减少客服工单量 |
| 优先级（建议） | 高 |
| 意见编号 / 提出人 / 意见内容 / 类型 | O1 / 周某 / 退款失败时的重试与人工介入规则未定义 / 修改建议 |
| 意见编号 / 提出人 / 意见内容 / 类型 | O2 / 吴某 / 需要明确自动退款的对账口径，便于测试验证 / 补充信息 |
| 评审结论 | 有条件通过 |
| 结论说明 | 需求方向认可，补充退款失败处理规则和对账口径后进入排期 |
| 结论确认人 / 确认时间 | 林某 / 2025年3月12日 15:00 |
| 待办事项 | T1 补充退款失败重试与人工介入规则；T2 明确自动退款对账口径 |
| 责任人 | T1 林某；T2 周某 |
| 计划完成时间 | T1 2025年3月14日；T2 2025年3月14日 |
| 状态 / 关闭说明 | 进行中 / — |
从示例可以看出写法上的三个要点：意见写成可判断的具体问题，并标注提出人；结论用固定选项，条件写在结论说明里；待办与意见一一对应，责任人和时间落到具体人和日期。会后更新状态时，只需改动待办区，评审过程保持原样。
当评审记录需要长期留存并和需求条目对应时，可以把记录放在与项目关联的文档空间中。ONES Wiki 的页面组可关联项目，需求与文档互相对应，评审记录能跟随需求一起被查阅；文档实时同步并记录所有页面版本，支持随时查看与回滚，模板调整前后的差异有据可查；同时支持为多种角色配置不同的读写权限，参会人可编辑、其他成员只读。使用模板库一键创建文档，也能减少每次评审重复搭表的时间，具体能力以实际开通的版本与权限为准。
模板的调整与长期维护
模板用上一段时间后，常见的问题是字段越加越多、填写越来越随意。维护的重点是让字段始终服务于“可追溯、可跟踪”两个目标。
常见调整方向
- 评审频次提高后，把意见类型和优先级建议改为必填，便于按月统计争议集中点。
- 跨部门评审增多时，补充参会角色和结论确认时间，减少会后对结论的反复确认。
- 需求条目改为逐条过审时，把需求区改为一行一条的横向表头，意见与待办用编号关联。
- 发现某些字段长期空白，先判断是流程不需要还是填写习惯问题，前者删除，后者在评审开场时明确要求。
维护责任与更新频率
指定一名模板负责人，通常由产品团队中组织评审的人担任，负责收集填写中的问题并统一修改。建议每季度检查一次，或在评审流程、参会角色、需求管理方式发生变化时立即调整。修改前先在小范围评审中试用一轮，确认字段可填、信息够用后再推广。
版本与历史记录保留
模板每次调整保留版本号和变更说明，写清新增、删除或改名的字段及原因。已归档的评审记录按原版本保留，不随模板更新而改写，保证历史记录可还原。若使用支持页面版本管理的文档工具承载模板，可直接查看历次修改并回滚到旧版本。
与评审流程衔接的检查点
- 评审前：确认记录人已拿到最新版模板，需求条目信息提前填好。
- 评审中：意见当场编号记录，结论当场确认并指定确认人。
- 评审后：24小时内补齐待办责任人与时间，发送给参会人确认。
- 跟踪期：按计划完成时间检查待办状态，关闭时写明结果。
- 复盘时：抽查若干条记录，检查必填项是否完整、结论与待办是否对应。
把这几个检查点固定下来，模板就不只是一张表，而是评审从准备到关闭的完整记录链条。
常见问题
评审会上意见很多，一条需求对应十几条意见，记录表怎么组织才不乱？
把意见区改成“一条意见一行”，用意见编号与需求编号关联，不要在一格里堆叠多条意见。需求条目区保留一条需求一行，意见区按编号逐行展开，结论区只写汇总结论并引用关键意见编号。这样会后检索时，按需求编号能找到全部意见，按意见编号能找到对应的待办。
意见量大时，建议把意见类型设为必填，按月统计疑问、修改建议、风险提示的分布，能看出评审反复卡在哪些环节。
评审结论当场没有定下来，记录该怎么写？
结论字段不要留空，也不要写“待定”了事。可以从模板的四个选项中选择“暂缓”，在结论说明里写清暂缓的原因、还缺哪些信息、由谁在什么时间前补齐，并把补齐动作放进待办区，指定责任人和计划完成时间。下次评审时以这份记录为起点继续讨论，避免同一问题重复从头过一遍。
小团队评审频率低，是否也要填满整张表？
不需要。两三人小范围、结论当场口头确认的评审，保留必填项加待办即可，地点、主持人、意见类型、优先级建议等选填项可以省略。判断标准是记录能否支撑会后追溯和跟踪：如果需求池里已有来源和优先级信息，记录中重复填写意义不大；一旦评审改为跨部门进行或周期拉长，再把参会角色、结论确认时间、待办状态补回。
评审记录和需求条目怎么对应，避免会后找不到？
关键是编号一致：记录中的需求编号与需求池或需求管理工具中的编号保持同一套，评审编号也建议包含日期或流水号。记录承载在文档工具中时，可以把评审记录页面与项目关联，让需求与文档互相对应。ONES Wiki 的页面组可关联项目，需求与文档互相对应；文档实时同步并记录所有页面版本，支持随时查看与回滚；同时支持为多种角色配置不同的读写权限，参会人可编辑、其他成员只读，具体能力以实际开通的版本与权限为准。
模板改版后，之前归档的评审记录要跟着改吗？
不改。已归档的记录按当时使用的版本保留，模板更新只影响之后发起的评审。每次调整保留版本号和变更说明，写清新增、删除或改名了哪些字段及原因，方便对照新旧记录。若承载模板的文档工具支持页面版本管理，可直接查看历次修改并回滚到旧版本，模板调整前后的差异有据可查。
