需求澄清会议记录模板通常包含五组字段：会议信息、参与角色、待澄清需求清单、澄清问答与结论、待办与遗留事项。其中需求编号与名称、澄清问题、原理解与澄清后理解、结论状态、待办负责人与截止时间构成核心记录内容，其余字段可按会议正式程度裁剪。本文先给出一份可直接复制填写的空白表，再逐字段说明填写口径、区分必填与选填，并用一份完整示例示范记录粒度。
要点总览（TL;DR）
- 模板以五组字段组织：会议信息、参与角色、待澄清需求清单、澄清问答与结论、待办与遗留事项，可直接复制空白表使用。
- 核心必填项包括需求编号与名称、澄清问题、澄清后理解、结论与结论状态、待办负责人与截止时间，保证未参会者能据此行动。
- 小范围快速澄清可只保留最小字段集；正式澄清会应补齐参与角色、会议目标、原理解、确认人与关联版本。
- 记录粒度收敛为“问题—原理解—澄清后理解—结论”四段，不逐字记录发言，未决事项标注状态并落到待办。
- 模板需定期维护：按填写情况增删字段、固定结论状态取值、保留版本变更记录，并与需求条目和评审记录衔接。
可复制的需求澄清会议记录空白模板
下面的空白表按五个分区组织，开会时可直接复制到文档或表格工具中逐项填写。分区顺序对应会议的推进顺序：先确认基本信息与到场角色，再逐条过需求、记录问答与结论，最后收口待办与遗留问题。
一、会议信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | |
| 会议日期与时间 | |
| 会议形式与地点 | |
| 记录人 | |
| 会议目标 | |
| 关联需求批次或版本 |
二、参与角色
| 姓名 | 角色 | 所属团队 | 是否必须到场 |
|---|---|---|---|
三、待澄清需求清单
| 需求编号 | 需求名称 | 提出人 | 业务目标 | 本次澄清重点 | 处理状态 |
|---|---|---|---|---|---|
四、澄清问答与结论
| 需求编号 | 澄清问题 | 原理解 | 澄清后理解 | 结论 | 结论状态 | 确认人 |
|---|---|---|---|---|---|---|
五、待办与遗留事项
| 事项 | 类型 | 负责人 | 截止时间 | 关联需求编号 | 状态 |
|---|---|---|---|---|---|
每个字段记录什么：字段说明与填写口径
字段名称相同，不同人填写的结果可能差别很大。下表给出每个字段的含义、填写口径和示例值，团队可以据此统一记录习惯，减少会后反复确认。
会议信息类字段
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 会议主题 | 本次会议的名称 | 写明澄清对象与范围，避免只写“需求沟通” | 订单模块二期需求澄清会 |
| 会议日期与时间 | 会议发生的时点 | 写到分钟，跨时区团队标注时区 | 2025-03-12 14:00–15:30 |
| 会议形式与地点 | 线上或线下、使用的会议渠道 | 线下写会议室，线上写会议工具名称 | 线上会议 |
| 记录人 | 负责整理本记录的人 | 写姓名，便于会后追补 | 李敏 |
| 会议目标 | 本次会议要达成的结果 | 用一句话写清“澄清完什么、做出什么决定” | 确认订单拆单规则与异常处理范围 |
| 关联需求批次或版本 | 本次需求所属的批次、版本或迭代 | 与需求管理中的编号保持一致 | V2.4 迭代 |
需求与角色类字段
参与角色区记录“谁在场、以什么身份参与”，需求清单区记录“这次要澄清哪些需求”。需求编号建议沿用需求池或需求管理工具中的既有编号，保证会议记录与需求条目可以互相对应。业务目标写提出人希望解决的业务问题，澄清重点写本次会议最需要拉齐的分歧点，两者分开填写，避免把目标写成功能描述。
澄清问答与结论类字段
这一组是记录的主体。澄清问题写会上实际提出的疑问，原理解写提出人或业务方原本的设想，澄清后理解写讨论后达成的共同认识，结论写最终决定。结论状态建议使用固定取值，例如“已确认”“待补充”“有分歧待决策”，便于会后筛选。确认人写对该结论负责拍板的人，而不是记录人。
待办与遗留类字段
待办指会后需要执行的动作，遗留事项指本次未能澄清、需要另开会或补充材料的问题。两者都要求写负责人和截止时间，类型字段用于区分“补充材料”“另行决策”“修改需求描述”等。关联需求编号保证每条待办都能追溯到具体需求。
易混淆字段的填写口径
- 原理解与澄清后理解：前者保留原始设想，后者记录修正后的共识。两者都保留，才能看出分歧在哪里、为什么调整。
- 结论与结论状态：结论是内容，状态是进度标记。只写“已确认”而不写确认了什么，记录无法独立使用。
- 待办与遗留事项：待办有明确动作和责任人；遗留事项的核心是问题尚未解决，需要标注下一步由谁推动。
- 提出人与确认人：提出人是需求来源，确认人是对结论负责的人，两者可以是同一人，但字段含义不同。
必填与选填：按会议类型裁剪字段
字段齐全的模板适合正式澄清会，小范围快速对齐则不必全部填写。判断依据是会议是否产生需要长期追溯的结论：只要结论会被后续开发和评审引用，核心字段就应保留。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 会议日期、记录人 | 必填 | 任何记录都需要可追溯的时间与责任人 |
| 会议主题 | 必填 | 用于检索和归档 |
| 参与角色 | 必填（至少记录关键角色） | 结论的有效性与到场角色相关 |
| 需求编号与名称 | 必填 | 与需求条目对应的唯一锚点 |
| 澄清问题 | 必填 | 记录的核心内容 |
| 澄清后理解 | 必填 | 未参会者据此行动的依据 |
| 结论与结论状态 | 必填 | 区分已定与未定，决定后续动作 |
| 待办负责人与截止时间 | 必填（有待办时） | 没有责任人和时间的待办无法跟踪 |
| 会议形式与地点 | 选填 | 正式归档或跨团队协作时填写 |
| 会议目标 | 选填 | 正式澄清会建议填写，快速沟通可省略 |
| 关联需求批次或版本 | 选填 | 按迭代管理的团队建议填写 |
| 提出人与业务目标 | 选填 | 需求来源复杂时填写，便于回溯动机 |
| 原理解 | 选填 | 分歧较大的需求建议保留，简单确认可省略 |
| 确认人 | 选填 | 涉及跨角色决策时填写 |
| 事项类型 | 选填 | 待办较多时用于分类筛选 |
小范围快速澄清与正式澄清会的差异
两三个人的快速对齐，可以只保留最小字段集：会议日期、记录人、需求编号与名称、澄清问题、澄清后理解、结论状态、待办负责人与截止时间。正式澄清会涉及多方角色和跨团队决策，应补齐参与角色、会议目标、原理解、确认人和关联版本，便于后续评审引用和争议回溯。
裁剪后仍需保留的最小字段集
无论会议规模如何，以下字段建议始终保留：需求编号与名称、澄清问题、澄清后理解、结论状态、待办负责人与截止时间。这六项保证记录能被未参会者读懂，并能转化为可执行的动作。其余字段的取舍以“是否影响结论追溯”为标准。
完整填写示例：一次需求澄清会怎么记
以下示例为演示情景，用于说明字段之间的对应关系和记录粒度，不代表真实项目。
示例会议背景与参与角色
某电商团队计划在 V2.4 迭代中调整订单拆单逻辑。参会角色包括：产品经理（需求提出与结论确认）、订单模块开发负责人、测试负责人、客服业务代表、记录人。会议目标为确认拆单触发条件与异常订单的处理范围。
示例需求条目与澄清问题
| 需求编号 | 需求名称 | 提出人 | 业务目标 | 本次澄清重点 |
|---|---|---|---|---|
| REQ-0312 | 订单按仓库可用库存自动拆单 | 客服业务代表 | 减少因单仓缺货导致的整单延迟 | 拆单触发条件、部分缺货时的处理方式 |
会上提出的澄清问题包括：库存不足多少时触发拆单；拆单后运费如何计算；已支付订单拆单是否需要通知用户。
示例结论与状态标记
| 澄清问题 | 原理解 | 澄清后理解 | 结论 | 结论状态 | 确认人 |
|---|---|---|---|---|---|
| 何时触发拆单 | 任一仓库缺货即拆单 | 按可满足整单的仓库优先，无法整单满足时按仓库可用量拆分 | 采用“整单优先、缺货再拆”规则 | 已确认 | 产品经理 |
| 拆单后运费计算 | 按子订单分别计费 | 需与运费规则负责人确认 | 暂不决定，列入遗留事项 | 待补充 | 产品经理 |
| 是否通知用户 | 不通知 | 拆单影响预计送达时间时应告知 | 拆单后发送站内通知 | 已确认 | 产品经理 |
示例待办与遗留事项
| 事项 | 类型 | 负责人 | 截止时间 | 关联需求编号 | 状态 |
|---|---|---|---|---|---|
| 补充运费计算规则说明 | 补充材料 | 客服业务代表 | 2025-03-14 | REQ-0312 | 进行中 |
| 确认拆单通知文案 | 另行决策 | 产品经理 | 2025-03-17 | REQ-0312 | 未开始 |
| 更新需求描述中的拆单规则 | 修改需求描述 | 产品经理 | 2025-03-13 | REQ-0312 | 未开始 |
示例中体现的记录粒度
示例没有逐字记录发言，而是把讨论收敛为“问题—原理解—澄清后理解—结论”四段。每条结论都能让未参会者理解决定了什么、依据是什么；未决定的事项明确标注状态并落到待办。这种粒度既能支撑后续开发与测试，也避免记录变成会议逐字稿。
模板的调整与长期维护方法
模板用一段时间后，会出现字段冗余或缺失。维护的目标是让字段始终服务于“结论可追溯、待办可跟踪”，而不是字段越多越完整。
新增与删除字段的判断依据
- 连续多次会议中某字段无人填写，且删除后不影响结论理解，可考虑移除。
- 会后经常需要额外沟通才能补齐的信息，说明缺少对应字段，应新增。
- 新增字段先在一个团队试用两到三次会议，再决定是否纳入统一模板。
字段命名与编号规则维护
字段名称保持稳定，避免同一含义出现多种叫法。需求编号沿用需求管理中的既有规则，会议记录不另建编号体系。结论状态使用固定取值集合，新增状态需同步更新填写说明。
模板版本与变更记录方式
建议在模板文件头部保留变更记录表头：版本号、变更日期、变更人、变更内容、影响范围。每次调整字段都登记一条，便于团队成员确认自己使用的是最新版本。
与需求条目、评审记录的衔接
澄清记录的价值在于被后续环节引用。需求编号应与需求条目一致，澄清结论作为需求描述的补充依据，正式评审时直接引用会议记录中的结论与遗留事项。团队若使用 ONES，可将澄清记录沉淀在 ONES Wiki 的文档页面中，页面组关联项目后，需求与文档可以互相对应；ONES Wiki 记录页面版本并支持查看与回滚，模板调整前后的内容都能追溯。ONES Assistant 可围绕 PRD 质量检查与需求智能生成提炼待澄清问题与拆解建议，帮助会前准备澄清清单，具体可用范围以实际产品版本与配置为准。
定期回顾模板有效性的做法
建议每季度抽查若干份会议记录，检查三项内容：结论状态是否都有明确取值、待办是否都有负责人和截止时间、未参会者能否仅凭记录理解结论。抽查中发现的高频缺口，作为下一版模板的调整输入。模板调整后，同步更新字段说明与填写示例，保持三者一致。
常见问题
需求澄清会议只有两三个人参加，还需要填完整模板吗？
不必填完整模板。两三个人的快速对齐可以只保留最小字段集：会议日期、记录人、需求编号与名称、澄清问题、澄清后理解、结论状态、待办负责人与截止时间。判断标准是结论是否会被后续开发或评审引用；只要需要追溯，这六项就应保留，其余字段按需补充。
会上没有达成一致的澄清问题应该怎么记录？
把未决问题写入“待办与遗留事项”，在结论状态中标注“待补充”或“有分歧待决策”，并写明下一步由谁推动、截止时间是什么。澄清问答表中保留原理解与讨论后的理解，让后续参与者能看出分歧点在哪里。遗留事项与待办分开记录，前者是问题尚未解决，后者是已有明确动作。
澄清记录和需求评审记录需要分开维护吗？
建议分开维护、互相引用。澄清记录聚焦需求理解与分歧收敛，评审记录聚焦正式确认与质量检查。两者通过需求编号对应，评审时可直接引用澄清记录中的结论与遗留事项，避免重复讨论。若团队使用 ONES，可将澄清记录沉淀在 ONES Wiki 文档页面中，页面组关联项目后与需求条目互相对应，评审时按编号追溯。
模板里的结论状态应该用哪些固定取值？
常用取值包括“已确认”“待补充”“有分歧待决策”，团队可按实际流程增减，但应保持取值集合稳定。新增状态时同步更新字段说明，避免同一含义出现多种叫法。固定取值的作用是会后能快速筛选出未决事项，并据此生成待办。
用文档工具承载澄清记录时，需要注意什么？
重点保证三件事：记录能被检索、版本可追溯、与需求条目能对应。ONES Wiki 支持模板库一键创建文档，页面组关联项目后需求与文档互相对应，文档记录页面版本并支持查看与回滚，模板调整前后的内容都能追溯；具体可用范围以实际产品版本与配置为准。
