需求评审记录要能回答两个问题：当时评审的是哪个版本的需求，以及每条意见后来怎么处理。围绕可追溯和可复核，记录至少保留六类信息：评审对象与版本、评审安排、参与人与角色、评审意见条目、结论与处置、确认与留痕。下面给出可直接建表的字段清单、从会前到归档的填写流程、角色分工、一条完整示例和归档前检查清单。
要点总览（TL;DR）
- 需求评审记录围绕可追溯与可复核设计，至少保留六类信息：评审对象与版本、评审安排、参与人与角色、评审意见条目、结论与处置、确认与留痕。
- 记录质量在会前就已决定：提前锁定需求版本号与文档链接、填好模板表头，会中逐条编号记录意见，散会前由主持人复述结论并当场写入。
- 主持人对结论口径负责，记录人对条目完整负责，评审人确认本人意见记录无误，需求负责人认领处置并回写结果；确认动作建议由提出意见之外的人完成。
- 归档前重点核对结论与责任人是否匹配、记录版本与需求版本是否一致，以及高严重程度意见是否已处置或明确挂起安排。
一份可用的需求评审记录包含哪些字段
字段设计的目标是让未参会的人也能还原评审过程：谁在什么时间评审了哪份需求，提出了什么问题，最终结论是什么，由谁负责在什么时间完成。按这个目标，可以把字段分成六组。
| 分组 | 字段 | 填写要求 |
|---|---|---|
| 评审对象与版本 | 需求编号、需求标题、需求版本号、关联文档链接、所属产品/项目 | 版本号与文档链接必须指向本次评审的实际版本，避免后续需求修改后记录与内容对不上 |
| 评审安排 | 评审时间、地点或会议方式、主持人、记录人 | 时间写到具体时段；线上评审注明会议工具或会议号 |
| 参与人与角色 | 评审人、需求提出方、开发代表、测试代表、缺席人员 | 按角色列名，缺席人员单独标注，便于判断意见覆盖范围 |
| 评审意见条目 | 意见编号、问题描述、提出人、严重程度、对应需求条目、意见类型 | 一条意见一行，问题描述写具体，不停留在“需优化”这类概括 |
| 结论与处置 | 评审结论、每条意见的处置方式、责任人、计划完成时间 | 结论从通过、有条件通过、退回修改、不通过中选一；有条件通过需写明条件 |
| 确认与留痕 | 结论确认人、确认时间、记录版本、后续变更关联 | 确认人与主持人可以是同一人，但确认动作要单独留时间；后续需求变更需回链到本记录 |
六组字段中，评审意见条目和结论与处置是记录的主体，其余四组为它们提供上下文和证据。字段数量可按团队习惯增减，但这六类信息缺一类，记录的追溯能力就会打折扣：缺版本信息无法确认评审对象，缺责任人无法跟踪闭环，缺确认留痕则难以证明结论经过各方认可。
从会前准备到归档：记录怎么一步步形成
评审记录的质量很大程度在会前就已决定。把记录工作拆成四个阶段，每个阶段明确输入、动作和输出，可以避免会后凭记忆补记。
会前：准备材料与记录模板
输入是待评审的需求文档和评审通知。动作包括：确认需求版本号并锁定文档链接，把评审议程、参与人名单填入记录模板的表头部分，提前把模板发给参会人。输出是一份表头已填好、意见区为空的记录草稿。完成标志是记录人手中有一份与本次评审对象一一对应的模板，而不是会后再去找版本。
会中：逐条记录意见与结论
输入是评审过程中的讨论。动作是：每出现一条明确意见就当场编号记录，写清问题描述、提出人和对应的需求条目；讨论中出现分歧时记录分歧点而非只记最终说法；会议结束前由主持人复述结论，记录人当场写入结论字段。输出是意见条目齐全、结论已填的会议记录。完成标志是散会时每条意见都有编号，结论字段不为空。
会后：补齐责任人与时间并送确认
输入是会议记录。动作是：为每条意见确定处置方式和责任人，与责任人确认计划完成时间；把记录整理成正式版本，发送给主持人和主要评审人确认。输出是待确认的完整记录。完成标志是所有意见条目都有责任人和时间，且记录已发出确认请求。
归档：与需求条目建立关联
输入是确认后的记录。动作是：记录确认人和确认时间，标注记录版本号，把记录链接回写到对应的需求条目上，并在需求后续变更时补充关联。输出是可检索、可回溯的归档记录。完成标志是从需求条目能直接找到本次评审记录，从记录也能回到需求当前版本。
当需求评审在统一的需求池中流转时，记录与需求条目的关联可以借助工具承载。ONES 通过统一的需求池与任务看板同步状态与信息，便于追溯需求与问题；评审记录作为需求条目的关联材料存放，后续查看需求时能一并看到评审结论和处置情况。是否使用工具承载取决于团队已有的需求管理方式，记录字段和流程本身不依赖特定工具。
谁负责记录、谁负责确认：角色与交付物分工
评审记录常见的失效方式是职责不清：记录人只记讨论、不追结论，主持人只给口头结论、不落文字，意见提出后无人认领。按角色划分职责和交付物，可以让每个环节都有明确的责任人。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 主持人 | 把控评审节奏，会中明确结论口径，区分通过、有条件通过与退回修改；对结论的准确性负责 | 当场确认的评审结论及通过条件 |
| 记录人 | 会前准备模板，会中逐条记录意见，会后整理成完整记录并送确认 | 字段完整的评审记录及确认请求 |
| 评审人 | 提出具体意见，会后核对自己提出的意见是否被准确记录、处置方式是否认可 | 对记录中本人意见条目的确认 |
| 需求负责人 | 认领意见处置，给出完成时间，推动修改并回写处置结果 | 处置结果与需求新版本，回链到原评审记录 |
四个角色中，主持人和记录人共同对记录质量负责：主持人保证结论口径清楚，记录人保证条目完整。评审人的确认解决“意见有没有被记错”的问题，需求负责人的处置解决“意见有没有被落实”的问题。小团队中一人可能兼任多个角色，但确认动作建议由提出意见之外的人完成，避免自评自确认。
填写示例：一条评审意见如何记录完整
以下为演示情景，需求编号、人名和时间均为示例，用于说明字段填写方式。
意见条目的写法
意见编号 R-03；问题描述“需求中‘订单导出’未说明单次导出条数上限，也未定义超限时的提示方式，开发和测试无法确定验收标准”；提出人：测试代表李某；严重程度：中；对应需求条目：3.2 订单导出；意见类型：需求缺失。
这条意见的可取之处在于写清了缺什么、影响谁、对应哪一节需求。对比之下，“导出功能需完善”这样的记录在会后无法判断是否已修改，也无法分配给具体责任人。
结论与处置的写法
评审结论：有条件通过。通过条件：3.2 节补充导出条数上限及超限提示规则，补充后由测试代表确认即可进入开发，无需再次召开评审会。处置：R-03 由需求负责人王某在评审后两个工作日内补充需求文档并更新版本号；处置完成后在记录中回写“已补充，版本 v1.3，测试代表确认通过”。
确认留痕的写法
结论确认人：主持人张某；确认时间：评审当日；记录版本：v1.0；后续变更关联：需求 v1.3 的变更说明中引用本次评审记录编号。确认留痕的关键是确认动作有独立的时间和记录版本，后续需求再修改时，能从变更记录回溯到当初的评审结论和通过条件。
归档前的完成检查
归档前逐项核对以下检查项，全部通过再标记为已归档。检查可以由记录人自检，也可以由需求负责人复核。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 字段完整性 | 六组字段是否齐全 | 评审对象与版本、评审安排、参与人、意见条目、结论与处置、确认留痕均无空缺；确实不适用的字段注明原因 |
| 意见质量 | 每条意见是否可执行 | 问题描述具体，有提出人和严重程度，能对应到需求的具体条目 |
| 结论与责任人一致性 | 结论与处置是否匹配 | 结论为退回修改时，每条阻断性问题都有责任人和完成时间；有条件通过时，通过条件写明且可验证 |
| 版本与关联 | 记录与需求是否对得上 | 记录中的需求版本号与文档链接指向同一版本；记录已回链到需求条目 |
| 阻断项处理 | 是否存在未闭环的阻断项 | 严重程度为高且影响开发启动的意见，要么已处置并回写结果，要么在记录中明确挂起原因和下次处理时间 |
检查中最容易被跳过的是阻断项处理。评审结论为通过、但记录中仍留有未处置的高严重程度意见，这类记录归档后会在开发阶段重新引发争议。归档前把阻断项逐条过一遍，确认已处置或已明确挂起安排，记录才算真正可用。
常见问题
评审会上意见很多，记录人来不及逐条写全怎么办？
优先保证编号和问题描述两项当场落地：每条意见先编号，用一句话写清缺什么、影响谁、对应需求哪一节，提出人和严重程度可以会后补齐。分歧点要当场记下，不能只记最终说法。散会前留几分钟由主持人复述结论，记录人当场写入结论字段，避免会后凭记忆还原。
有条件通过的结论，记录里要写到什么程度才算清楚？
通过条件要写成可验证的表述：改哪一节需求、补什么内容、由谁确认、确认后是否还需要再次评审。示例中“3.2 节补充导出条数上限及超限提示规则，补充后由测试代表确认即可进入开发”，责任对象、验收方式和后续路径都在一句话里。只写“补充完善后通过”，归档后无法判断是否已满足条件。
需求后续发生变更，原来的评审记录需要跟着改吗？
原记录保持原样，作为当时结论的证据留存；变更通过新版本的需求文档和变更说明体现，并在变更说明中引用原评审记录编号，形成回链。这样从需求当前版本能回溯到当初的评审结论和通过条件，从原记录也能看到后续变更走向。若把原记录直接改写，评审当时的结论就失去了留痕意义。
小团队人手少，主持人和记录人由同一人兼任可以吗？
可以兼任，但要注意两点：一是结论口径和条目完整由同一人把关时，容易漏记对自己观点的异议，建议会中指定一位参会人协助核对意见条目；二是确认动作尽量由提出意见之外的人完成，避免自评自确认。角色可以合并，确认留痕的独立时间不能省。
评审记录一定要放进需求管理工具里吗？
字段和流程本身不依赖特定工具，用文档模板加共享目录也能运转。当需求数量多、变更频繁时，把记录与需求条目关联存放会更省事：从需求条目能直接找到评审记录，从记录也能回到需求当前版本。ONES 通过统一的需求池与任务看板同步状态与信息，便于追溯需求与问题，评审记录可作为需求条目的关联材料存放；是否采用取决于团队已有的需求管理方式。
