需求澄清记录把口头讨论转成可核对的结论，适合需求刚提出、理解存在分歧、需要跨角色确认的场景。本文提供一张可直接复制填写的空白表，逐项说明字段含义与必填选填规则，并用一条完整示例演示填写过程，最后给出模板调整与维护方法。
要点总览（TL;DR）
- 需求澄清记录由表头信息区和问题明细区组成：表头锁定需求、组织人、日期与记录状态，明细区按“一行一个问题”记录待澄清问题、确认结论、影响范围与责任人。
- 必填字段集中在可追溯性上：记录编号、需求名称、澄清日期、待澄清问题、责任人、状态、影响范围；确认结论在状态为“已确认”时必填。
- 填写时结论写答案本身，影响范围写具体模块或接口，范围不明先标“待评估”并指定评估人，避免结论悬空。
- 模板按团队实际使用情况增删字段，需求变更时追加新问题行、保留历史结论，失效结论改状态而非覆盖。
- 澄清记录与需求条目双向关联（记录编号回填需求、需求编号写入表头），归档按项目或版本归集，便于回答“当时为什么这样定”。
可复制空白需求澄清记录表
下表分为表头信息区和问题明细区两部分。表头信息区记录这次澄清围绕哪条需求、由谁组织、在什么时间完成；问题明细区逐条记录待澄清问题及其结论。复制到文档或表格工具后，删除示例占位文字即可使用。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 记录编号 | （如 CR-001） |
| 需求名称 | |
| 需求编号 | |
| 所属项目/版本 | |
| 需求提出人 | |
| 澄清组织人 | |
| 参与人 | |
| 澄清日期 | |
| 澄清方式 | （会议 / 书面 / 原型走查等） |
| 记录状态 | （草稿 / 待确认 / 已确认 / 已失效） |
问题明细区
| 序号 | 问题类别 | 待澄清问题 | 澄清方式 | 确认结论 | 影响范围 | 关联需求/文档 | 责任人 | 计划确认时间 | 状态 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||
| 2 | |||||||||
| 3 |
问题明细区按“一行一个问题”填写。一条需求通常会产生多条澄清问题，逐行记录便于分别跟踪状态，也便于后续追溯某条结论是在哪次讨论中形成的。
每个字段记录什么：字段说明
同一张表由不同角色填写时，最容易出现口径不一致：有人把“结论”写成讨论过程，有人把“影响范围”写成个人判断。下表按四类字段给出统一口径，填写前可先对齐一遍。
标识类字段
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 记录编号 | 这份澄清记录的唯一标识 | 按团队约定规则编号，如“项目缩写-序号”，保证可检索、不重复 |
| 需求名称 | 被澄清需求的简要名称 | 与需求条目上的名称保持一致，便于对照 |
| 需求编号 | 需求在需求池或项目中的编号 | 填写系统内编号；尚无编号时留空并在结论确认后补录 |
| 所属项目/版本 | 需求归属的项目与计划版本 | 写到可定位的层级，版本未定时注明“待排期” |
| 序号 | 问题在本次澄清中的顺序号 | 从1开始连续编号，便于引用“第3条结论” |
问题与结论类字段
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 问题类别 | 问题所属的澄清维度 | 可用业务规则、范围边界、数据口径、交互细节、非功能要求等分类，便于统计高频分歧点 |
| 待澄清问题 | 需要被确认的具体疑问 | 写成可回答的问句，一题一问；避免“再讨论一下”这类无法判定是否解决的表述 |
| 澄清方式 | 通过什么途径获得结论 | 记录会议、书面回复、原型走查、数据核对等方式，必要时附会议或文档位置 |
| 确认结论 | 澄清后达成的明确答案 | 写结论本身，不写讨论过程；涉及取舍时写明选择了哪种方案及理由要点 |
责任与状态类字段
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 责任人 | 负责推动该问题得出结论的人 | 填具体个人，不填部门；责任人应有权协调结论确认 |
| 计划确认时间 | 该问题预期完成澄清的日期 | 按问题粒度填写，避免整份记录只写一个笼统截止日 |
| 状态 | 该条问题的处理进度 | 建议取值：待澄清、澄清中、已确认、已失效；状态变化时同步更新 |
| 记录状态 | 整份记录的完成情况 | 所有必答问题确认后改为“已确认”；需求取消或方案推翻时改为“已失效” |
影响与关联类字段
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 影响范围 | 该结论会波及的需求、模块、接口或交付节点 | 写具体对象，如“影响订单导出模块与对账接口”；范围不明时标注“待评估”并指定评估人 |
| 关联需求/文档 | 与该问题相关的其他需求、原型、接口文档 | 填写编号或文档名称，便于后续追溯依据 |
| 参与人 | 参加本次澄清的角色 | 按角色记录，如产品、研发、测试、业务方，便于判断结论的确认覆盖面 |
必填与选填：哪些字段不能空
必填字段的作用是保证记录可追溯、可判断是否完成。以下划分适用于多数团队，规模较小或需求简单的项目可在此基础上精简，但精简前应先确认不会影响追溯。
| 字段 | 要求 | 说明 |
|---|---|---|
| 记录编号 | 必填 | 缺少编号会导致记录无法被引用和检索 |
| 需求名称 | 必填 | 至少能定位到具体需求 |
| 澄清日期 | 必填 | 结论有时效性，日期缺失会影响后续判断 |
| 待澄清问题 | 必填 | 没有问题就失去记录意义 |
| 确认结论 | 必填（状态为“已确认”时） | 未确认前可暂空，但状态不得标为已确认 |
| 责任人 | 必填 | 无人负责的问题容易长期悬置 |
| 状态 | 必填 | 用于判断记录是否可关闭 |
| 影响范围 | 必填 | 结论若影响其他模块而未被记录，容易在开发阶段返工 |
| 需求编号 | 选填 | 需求尚未录入系统时可后补 |
| 所属项目/版本 | 选填 | 版本未规划时可暂缺 |
| 问题类别 | 选填 | 问题较少时可不分类 |
| 澄清方式 | 选填 | 书面澄清且留有原文时可省略 |
| 关联需求/文档 | 选填 | 无关联对象时留空 |
| 计划确认时间 | 选填 | 紧急问题建议填写，作为跟踪依据 |
| 参与人 | 选填 | 一对一书面澄清时可只记责任人 |
必填字段缺失时的处理规则：
- 记录编号、需求名称、待澄清问题缺失，记录不得进入流转，由澄清组织人补齐后再提交。
- 责任人缺失，由澄清组织人当场指定，不留在“待分配”状态过夜。
- 影响范围暂时无法判断，先填“待评估”并指定评估人，同时把该条状态保持为“澄清中”，评估完成后回填具体范围。
- 确认结论缺失但状态被误标为“已确认”，视为无效记录，需退回补充结论或改回“澄清中”。
填写示例：一条需求澄清记录怎么填完整
以下为演示情景：某电商团队计划在订单列表增加“批量导出对账单”功能，需求提出后，产品、研发与财务业务方对导出范围和数据口径存在分歧，通过一次澄清会议形成记录。
示例背景
需求提出人希望财务人员能按月份批量导出对账单，研发对导出数据是否包含退款订单、金额以哪个时间点为准存在疑问，业务方对导出文件格式有额外要求。澄清组织人为产品经理，参与人包括研发负责人、测试负责人和财务业务方代表。
逐字段填写内容
| 字段 | 填写内容 |
|---|---|
| 记录编号 | CR-012 |
| 需求名称 | 订单列表批量导出对账单 |
| 需求编号 | REQ-2087 |
| 所属项目/版本 | 订单中心 / V2.4 |
| 需求提出人 | 财务业务方 张琳 |
| 澄清组织人 | 产品经理 陈默 |
| 参与人 | 产品、研发负责人、测试负责人、财务业务方代表 |
| 澄清日期 | 2025-03-11 |
| 澄清方式 | 澄清会议 + 会后书面确认 |
| 记录状态 | 已确认 |
问题明细区填写如下：
| 序号 | 问题类别 | 待澄清问题 | 澄清方式 | 确认结论 | 影响范围 | 关联需求/文档 | 责任人 | 计划确认时间 | 状态 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 范围边界 | 导出数据是否包含退款订单？ | 澄清会议 | 包含退款订单，并在文件中单独标注退款状态列 | 影响导出模板列设计与对账口径 | 对账规则说明 v1.2 | 陈默 | 2025-03-11 | 已确认 |
| 2 | 数据口径 | 订单金额按支付时间还是退款完成时间统计？ | 会后书面确认 | 按支付时间归属月份统计，退款金额单列，不冲减原订单金额 | 影响统计逻辑与财务对账结果 | REQ-2087 | 研发负责人 李哲 | 2025-03-12 | 已确认 |
| 3 | 交互细节 | 导出文件格式用 Excel 还是 CSV？ | 澄清会议 | 默认导出 Excel，单次上限 5 万行，超出时提示分批导出 | 影响导出任务实现与性能评估 | — | 陈默 | 2025-03-11 | 已确认 |
澄清前后的变化
澄清前，研发按“仅导出已完成订单、金额按退款后净额统计”理解需求，业务方则期望看到含退款的完整流水，双方对文件格式也没有约定。澄清后，三条问题分别落到范围、口径和交互三个维度，结论写入记录并回填到需求条目，导出模板的列设计、统计逻辑和分批策略都有了明确依据，测试也可以据此设计用例。这份记录同时成为后续需求变更时的对照基线。
调整与维护：让模板跟着需求走
模板不是一次定稿就固定不变。团队在几轮使用后，通常会发现问题类别不够用、某些字段长期空置，或记录与需求状态脱节。调整时应围绕“是否影响追溯和判断”做取舍。
字段增删的取舍原则
- 新增字段前先问：缺少它是否会导致结论无法追溯或无法判断完成？例如需要记录结论的确认人时，可增加“结论确认人”字段。
- 连续多个项目都空置的选填字段，可以合并或删除，避免表格过宽导致填写意愿下降。
- 问题类别随业务复杂度扩展，但保持取值有限，便于统计高频分歧点。
- 字段调整后同步更新字段说明，保证模板、说明和示例三处口径一致。
记录更新时机
- 澄清会议或书面确认结束后当天完成记录，避免结论随记忆模糊。
- 需求发生变更时，在原记录上追加新问题行，并标注与原结论的关系，不直接覆盖历史结论。
- 结论被推翻时，将原条目状态改为“已失效”，新增条目记录新结论及变更原因。
- 需求进入开发或评审前，检查记录状态是否为“已确认”，未确认的问题应明确处理方式。
归档与追溯方式
澄清记录应与需求条目建立稳定关联：记录编号回填到需求条目，需求编号写入记录表头，形成双向可查。归档时按项目或版本归集，保留历史版本，便于回答“当时为什么这样定”。当澄清记录需要多人协作填写、与需求状态联动时，可将其承载在需求管理工具中。ONES 支持将文档关联项目任务，页面组可关联项目，使需求与文档互相对应；ONES Wiki 的模板库可用于一键创建记录文档，页面版本可随时查看与回滚，并可按角色配置读写权限。对于会议录音、用户反馈等材料，ONES Assistant 可提炼要点与待澄清问题，帮助团队更快形成澄清清单，具体能力范围以实际开通的功能为准。
维护规则可以固化为一张检查清单：每次澄清结束核对必填字段是否齐全；每周检查“澄清中”条目是否超期；每个版本关闭前确认记录状态与需求状态一致；需求变更时确认是否新增了澄清条目。按这套规则执行，澄清记录才能持续作为需求理解的可信依据。
常见问题
澄清会上口头确认了结论，但责任人当场无法判断影响范围，这条记录该怎么处理？
把该条状态保持为“澄清中”，影响范围先填“待评估”，并在责任人一栏指定评估人，约定回填时间。结论本身可以先写入“确认结论”，但整份记录状态不要改为“已确认”，等影响范围回填后再关闭。这样既保留了已达成的一致，也不会让未评估的影响在开发阶段才暴露。
需求在开发过程中发生变更，原来的澄清结论还作数吗？
原结论作为历史依据保留，不直接覆盖。做法是在原记录上追加新的问题行，写明变更原因和与原结论的关系；被推翻的旧条目把状态改为“已失效”，新条目记录新结论。这样后续追溯时能看清结论演变过程，评审和测试也能对照变更点判断影响。
团队规模小、需求简单，模板字段可以精简到什么程度？
可以精简，但优先保留影响追溯和完成判断的字段：记录编号、需求名称、待澄清问题、确认结论、责任人、状态、影响范围。问题类别、澄清方式、参与人、关联文档等选填字段在问题较少时可先省略。精简后要同步更新字段说明，避免不同人按不同口径填写。
澄清记录需要和需求条目放在一起吗，还是单独存档？
建议建立双向关联：记录表头写需求编号，需求条目上回填记录编号，两边都能互相查到。单独存档时按项目或版本归集，保留历史版本。若团队使用 ONES，可将文档关联项目任务，页面组关联项目使需求与文档对应；ONES Wiki 的模板库可用于一键创建记录文档，页面版本支持查看与回滚，并可按角色配置读写权限。对于会议录音、用户反馈等材料，ONES Assistant 可提炼要点与待澄清问题，帮助更快形成澄清清单，具体能力范围以实际开通的功能为准。
一条需求澄清出十几个问题，全部逐行记录会不会太重？
逐行记录的价值在于分别跟踪状态和追溯单条结论来源。问题较多时，可按问题类别分组，先记录影响范围大、阻塞开发的问题，其余问题标注计划确认时间分批推进。记录状态统一为“已确认”前，确认没有遗留的“待澄清”或“澄清中”条目即可，不必要求所有条目在同一天完成。
