需求澄清会议记录模板建议包含三类字段：会议基本信息、待澄清需求清单、澄清结论与待办。会议信息解决“谁在什么场合讨论了哪些需求”，需求清单逐条记录原始表述、澄清问题、答复与结论，结论区写明确认口径、未决事项、负责人和截止时间。本文给出一张可直接复制的空白表，并说明每个字段的填写口径、必填与选填的划分，以及一份完整填写示例，范围限于需求澄清会议本身的记录。
要点总览（TL;DR）
- 模板按三段组织：会议基本信息、待澄清需求清单、澄清结论与待办，条目区与结论区通过需求编号对应。
- 必填字段围绕可追溯与可交接：会议主题与时间、主持人、记录人、参会角色、需求编号与名称、原始表述、澄清问题、澄清结论，以及未决事项的负责人与截止时间。
- 填写时把原始表述、澄清问题、答复要点、澄清结论分开记录，结论要能独立成立，供开发和测试直接引用。
- 单条需求快速澄清可精简选填字段；批量或多方参与的澄清会补齐需求范围、答复要点和状态。
- 模板每季度或每批需求后回顾一次，按填写率和交接失误情况增删字段，并保留版本标识。
可复制空白模板：需求澄清会议记录表
下面这张表按三块组织，可直接复制到文档或表格工具中使用。复制后先填会议信息，再按需求逐行填写澄清条目，最后汇总结论与待办。条目数量按实际需求增减行数，结论区与条目区通过需求编号对应。
第一块：会议基本信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | |
| 会议时间 | |
| 地点 / 线上链接 | |
| 主持人 | |
| 记录人 | |
| 参会角色 | |
| 对应需求范围 |
第二块：需求澄清条目
| 需求编号 | 需求名称 | 原始表述 | 澄清问题 | 答复要点 | 澄清结论 | 状态 |
|---|---|---|---|---|---|---|
第三块：结论与待办
| 需求编号 | 确认口径 | 未决事项 | 负责人 | 截止时间 | 下次跟进 |
|---|---|---|---|---|---|
每个字段记录什么：字段说明与填写口径
字段说明与上面的空白表一一对应。填写时把握一个原则：让没有参会的人读完后，能知道这条需求原来怎么提的、会上问清了什么、最后定了什么。颗粒度以“可交接”为准，不必复述讨论过程。
会议信息字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 会议主题 | 本次澄清会的范围 | 写清是哪个项目或哪批需求的澄清，避免只写“需求沟通” |
| 会议时间 | 会议发生的日期与时段 | 精确到日期，跨时区协作时注明时区 |
| 地点 / 线上链接 | 会议形式与入口 | 线下写会议室，线上写平台名称或链接，便于回看 |
| 主持人 | 组织并推进澄清的人 | 写姓名与角色，便于后续追问 |
| 记录人 | 负责整理本记录的人 | 写姓名，明确记录责任归属 |
| 参会角色 | 参与澄清的角色构成 | 按角色列，如业务方、产品、研发、测试，不必逐一列全名 |
| 对应需求范围 | 本次会议覆盖的需求编号或批次 | 与条目区的需求编号对应，方便按会议检索需求 |
澄清条目字段
条目区是记录的主体。原始表述、澄清问题、答复要点、澄清结论四个字段承担不同作用，填写时不要互相替代。原始表述保留提出方当时的说法，包括模糊之处；澄清问题写会上实际提出的疑问，一条需求有多个问题时分行或编号；答复要点记录业务方或需求方的回应，抓关键信息；澄清结论写会议形成的判断，例如“按方案 A 实现”“范围缩小到某场景”“暂不纳入本期”。状态字段用于标记该条目的处理进度，常用取值如待澄清、已澄清、待补充、已关闭，团队可自行统一。
结论与待办字段
确认口径是对已澄清结论的汇总表述，供开发和测试直接引用，写法上要能独立成立，不依赖上下文。未决事项记录会上没有结论、需要会后确认的问题，每条都要落到负责人和截止时间，否则容易悬空。下次跟进写明复查时间或下一次会议安排，让未决事项有明确的回收节点。
必填与选填：哪些字段不能省
必填字段的判断标准是记录能否被追溯和交接：能定位到具体需求、能看出澄清了什么、能知道谁在何时跟进。满足这三点的字段建议必填，其余按会议复杂度增补。
| 字段 | 必填 / 选填 | 理由与适用场景 |
|---|---|---|
| 会议主题、会议时间 | 必填 | 记录的时间与范围标识，缺失后无法归档和检索 |
| 主持人、记录人 | 必填 | 明确责任归属，便于后续追问和补充 |
| 参会角色 | 必填 | 判断澄清结论是否覆盖了必要的角色视角 |
| 需求编号、需求名称 | 必填 | 与需求池或其他记录建立对应关系 |
| 原始表述 | 必填 | 保留提出方的原话，是判断澄清是否偏离的依据 |
| 澄清问题、澄清结论 | 必填 | 记录的核心内容，缺失则记录失去意义 |
| 负责人、截止时间 | 必填（针对未决事项） | 没有责任人和时间的待办无法跟踪 |
| 地点 / 线上链接 | 选填 | 需要回看录像或跨团队协查时填写 |
| 对应需求范围 | 选填 | 单需求澄清会可省略，批量澄清时建议填写 |
| 答复要点 | 选填 | 答复简短时可直接并入澄清结论；讨论复杂时单独记录 |
| 状态 | 选填 | 条目较多、需要分批跟进时启用 |
| 下次跟进 | 选填 | 存在未决事项时建议填写 |
按会议规模裁剪时，可以这样处理：单条需求的快速澄清，保留会议时间、参与角色、需求编号、原始表述、澄清问题、澄清结论和待办即可；涉及多个需求或多方角色的澄清会，补齐需求范围、答复要点和状态字段；需要长期跟踪的复杂需求，再增加下次跟进和关联文档位置等字段。裁剪的前提是必填项完整，选填项按需增补。
填写示例：一次需求澄清会议的完整记录
以下为演示情景，用于说明字段如何填写，不代表真实项目记录。
会议信息
| 字段 | 填写内容 |
|---|---|
| 会议主题 | 订单模块二期需求澄清会 |
| 会议时间 | 2025 年 3 月 12 日 14:00–15:00 |
| 地点 / 线上链接 | 线上会议，会议链接已附于会议邀请 |
| 主持人 | 产品经理 李某 |
| 记录人 | 产品助理 王某 |
| 参会角色 | 业务方、产品、研发、测试 |
| 对应需求范围 | REQ-021、REQ-022 |
澄清条目
| 需求编号 | 需求名称 | 原始表述 | 澄清问题 | 答复要点 | 澄清结论 | 状态 |
|---|---|---|---|---|---|---|
| REQ-021 | 订单批量导出 | 业务方提出“希望能把订单批量导出来，方便对账” | 1. 导出范围是全部订单还是筛选结果？2. 单次导出量上限是多少？3. 导出字段是否固定？ | 按当前筛选条件导出；单次不超过 1 万条；字段沿用列表页展示字段，另加下单时间 | 按筛选结果导出，单次上限 1 万条，字段为列表页字段加下单时间；超过上限时分批导出 | 已澄清 |
| REQ-022 | 对账差异提醒 | 业务方提出“对账有差异的时候要能提醒到人” | 1. 差异由谁判定？2. 提醒渠道是什么？3. 提醒频率如何控制？ | 差异由财务在对账环节标记；提醒走站内消息；同一差异每天提醒一次，处理后可关闭 | 财务标记差异后触发站内消息提醒，同一差异每日一次，处理完成即停止提醒 | 已澄清 |
结论与待办
| 需求编号 | 确认口径 | 未决事项 | 负责人 | 截止时间 | 下次跟进 |
|---|---|---|---|---|---|
| REQ-021 | 按当前筛选条件导出订单，单次上限 1 万条，字段为列表页字段加下单时间 | 超过 1 万条时的分批导出交互方式待确认 | 产品经理 李某 | 2025 年 3 月 19 日 | 3 月 20 日澄清会复查 |
| REQ-022 | 财务标记对账差异后触发站内消息，同一差异每日提醒一次，处理完成停止 | 提醒消息的文案与跳转位置待与财务确认 | 产品助理 王某 | 2025 年 3 月 18 日 | 3 月 20 日澄清会复查 |
这份示例中，两条需求都经历了“原始表述—澄清问题—答复—结论”的完整链路，未决事项单独列出并指定了负责人和时间。开发与测试可以直接依据确认口径开展后续工作，不需要再翻会议聊天记录。
模板的调整与维护方法
模板需要随团队协作方式和需求类型变化而调整，但调整应有依据，避免字段越加越多、填写负担越来越重。
新增字段的判断标准
出现以下情况时考虑新增字段：同一类信息在多次会议的备注里反复出现，说明它值得独立成列；某个字段缺失导致过交接失误或返工，说明它是必要信息；团队新增了固定的协作角色或审批环节，需要记录对应信息。新增前先确认现有字段能否通过改写填写口径覆盖，能覆盖的不新增。
定期回顾与合并冗余字段
建议每季度或每完成一批需求后回顾一次模板使用情况。检查方法：统计各字段的实际填写率，长期空白的选填字段考虑删除；检查含义重叠的字段，例如“答复要点”和“澄清结论”在多数记录中内容雷同，可合并或明确分工；收集填写人的反馈，找出填写耗时但很少被查阅的字段。回顾结论形成简短记录，说明改了什么、为什么改。
版本与存放位置
模板本身应有版本标识，例如在模板页脚注明版本号和更新日期，修改后在团队内同步说明变更点，避免不同人使用不同版本。存放位置建议统一在团队文档空间中，与需求相关文档放在同一页面组下，便于查找和引用。澄清记录归档时按项目或需求批次组织，与需求条目建立对应关系，后续追溯时能从需求直接找到对应记录。
当澄清记录需要与需求条目联动时，可以把记录文档放在与项目关联的文档页面组中，让需求与文档互相对应；记录中的未决事项和待办可以转为工作项跟踪，负责人和截止时间随工作项流转。ONES Wiki 支持使用模板库一键创建文档，并记录页面版本、支持按角色配置读写权限，适合承载这类需要长期留存和多人协作的会议记录；ONES Assistant 可围绕 PRD 质量检查和需求智能生成提炼待澄清问题与拆解建议，帮助会前准备澄清清单。具体模板种类与字段映射以团队实际配置为准。
常见问题
澄清会上问题很多，记录时要不要把讨论过程都写下来？
不需要逐句记录讨论过程。记录的目标是让未参会的人能看懂这条需求原来怎么提、会上问清了什么、最后定了什么。建议把每个问题压缩成一句疑问，答复只保留关键信息，讨论中的反复和假设可以省略。如果某个问题当场没有结论，把它移到未决事项，写清负责人和截止时间，比在条目区保留大段讨论更有用。
一条需求在会上没澄清完，记录里应该怎么标？
把这条需求的澄清结论写成当前已确认的部分，未确认的部分单独列入未决事项，并指定负责人和截止时间。状态字段可以标为“待补充”或“待澄清”，便于下次会议前筛选。下次跟进字段写明复查时间或下一次会议安排，让这条需求有明确的回收节点，避免记录归档后无人跟进。
澄清记录和需求评审记录需要合并成一张表吗？
建议分开。澄清记录承载的是需求理解结果，包括原始表述、澄清问题和结论；正式的需求评审与确认涉及质量检查、评审意见和通过结论，属于另一个环节。两者可以用需求编号关联，但字段目的不同，合并后容易让澄清结论和评审意见混在一起。本文模板的范围限于澄清会议本身，评审记录可另设模板。
团队用文档工具管理澄清记录时，有哪些维护上的注意点？
记录需要长期留存和多人协作时，重点在版本和权限。ONES Wiki 支持使用模板库一键创建文档，并记录页面版本、支持按角色配置读写权限，适合承载这类会议记录；页面组可关联项目，让需求与文档互相对应。具体模板种类与字段映射以团队实际配置为准。无论使用哪种工具，都建议在模板页脚标注版本号和更新日期，修改后在团队内同步变更点。
会前准备澄清清单时，有什么办法减少遗漏？
可以在会前把需求原始表述逐条过一遍，把模糊点、边界条件和依赖项先写成问题清单，会上按清单逐条确认。ONES Assistant 可围绕 PRD 质量检查和需求智能生成，提炼待澄清问题与拆解建议，帮助会前准备澄清清单；具体能力范围以产品实际配置为准。清单中的问题在会上没有结论的，直接转入记录的未决事项，保证每个问题都有落点。
