需求澄清记录把模糊需求问清楚并固定下来，避免口头沟通后各方理解不一致。本文提供一份可直接复制的空白表格，逐字段说明填写要求，划分必填与选填，并用一条完整示例演示如何填写，最后说明模板如何随团队流程调整与维护。
要点总览（TL;DR）
- 需求澄清记录用一张表固定“谁提出、为什么做、给谁用、做到什么程度、本次做什么、还有什么没定、谁确认”，减少口头沟通造成的理解偏差。
- 模板按基本信息、需求理解、期望与验收、范围与约束、待确认问题、确认签字六个区域组织，共24个字段，可直接复制到文档或表格工具。
- 必填项覆盖追溯、问题对齐、完成标准和确认责任；不做范围、约束条件、依赖方按需求情况选填，只填必填项即可构成最小可用版本。
- 填写时把验收口径写成可检验的条件，待确认问题逐条记录结论、确认人和日期；文中以客服工单排序需求为例给出完整填写示范。
- 模板建议每季度回顾一次，按需求类型调整必填规则并做版本管理；澄清记录与需求评审、需求建模顺序衔接，各自承担不同职责。
可复制空白需求澄清记录表
下表按六个区域组织字段，可直接复制到文档工具或表格工具中使用。每个区域对应澄清过程中的一类信息：基本信息用于追溯，需求理解用于对齐问题，期望与验收用于判断完成标准，范围与约束用于控制边界，待确认问题清单用于闭环，确认签字用于明确责任。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | |
| 需求名称 | ||
| 需求来源 | ||
| 提出人 | ||
| 澄清日期 | ||
| 记录人 | ||
| 需求理解 | 背景 | |
| 目标用户 | ||
| 使用场景 | ||
| 要解决的问题 | ||
| 期望与验收 | 期望结果 | |
| 验收口径 | ||
| 优先级 | ||
| 范围与约束 | 本期范围 | |
| 不做范围 | ||
| 约束条件 | ||
| 依赖方 | ||
| 待确认问题 | 问题 | |
| 结论 | ||
| 确认人 | ||
| 确认日期 | ||
| 确认签字 | 产品 | |
| 需求提出方 | ||
| 研发 | ||
| 测试 |
待确认问题通常不止一条，实际使用时可将该区域展开为多行清单，每行记录一个问题及其结论、确认人和确认日期。确认签字区记录各方对当前版本记录内容的认可，签字后如有变更，应更新记录并注明变更内容。
每个字段填什么：字段说明
字段说明与上表一一对应。填写时以“后来的人能否只看这张表就理解需求”为标准，减少依赖口头补充。
基本信息类字段
- 记录编号：团队约定的唯一标识，便于检索和引用，例如按“年份-序号”编排。
- 需求名称：用一句话概括需求对象和动作，避免“优化一下”“改改体验”这类无法判断的名称。
- 需求来源：写明来自客户反馈、内部运营、数据分析、合规要求等渠道，并注明具体出处，便于后续追溯。
- 提出人：填写实际提出需求的人，而非转述者。
- 澄清日期：本次澄清沟通完成的日期，多次澄清时记录最新一次。
- 记录人：负责整理记录的人，通常为产品经理或需求分析人员。
需求理解类字段
这一类字段决定后续讨论是否在同一问题上。写法上要落到可判断的表述：背景写触发需求的具体事件或数据；目标用户写角色而非笼统的“用户”；使用场景写用户在什么情况下、按什么顺序做什么；要解决的问题写当前做法带来的具体困难，例如耗时、出错、信息缺失。
期望结果与验收口径
两个字段容易混写。期望结果描述需求完成后业务上希望达到的状态，例如“客服可以在一个页面内完成退款审批”；验收口径描述用什么条件判断这个状态已经达到，例如“审批平均耗时从两天降到半天以内，且审批记录可查询”。期望结果偏方向，验收口径偏可检验的条件，后者应尽量包含对象、动作和判断标准。
范围边界与约束依赖
本期范围列出本次要交付的内容；不做范围明确列出容易混淆但本次不做的内容，防止范围蔓延。约束条件记录时间、合规、技术环境、预算等限制；依赖方记录需要其他团队或系统配合的事项，并写明依赖内容和期望时间。
待确认问题清单
每条问题记录四要素：问题本身、当前结论、确认人、确认日期。结论未定时留空并标注“待确认”，不要用推测内容填充。澄清会议结束后，由记录人逐条跟进，结论确定后补填确认人和日期，形成闭环。
必填与选填怎么分
字段过多会让记录表变成负担，最终被弃用。建议按“缺了它就无法判断需求是否清楚”的标准划分必填项，其余作为选填。
| 字段 | 建议 | 理由或适用场景 |
|---|---|---|
| 记录编号 | 必填 | 追溯和引用需要唯一标识 |
| 需求名称 | 必填 | 识别需求的基本信息 |
| 需求来源 | 必填 | 影响优先级判断和后续沟通对象 |
| 提出人 | 必填 | 澄清和确认的直接联系人 |
| 澄清日期 | 必填 | 判断信息时效 |
| 记录人 | 必填 | 明确记录责任 |
| 背景 | 必填 | 缺少背景无法判断需求合理性 |
| 目标用户 | 必填 | 决定方案面向谁 |
| 使用场景 | 必填 | 决定功能如何被使用 |
| 要解决的问题 | 必填 | 需求存在的理由 |
| 期望结果 | 必填 | 对齐方向 |
| 验收口径 | 必填 | 判断完成的标准 |
| 优先级 | 必填 | 排期依据 |
| 本期范围 | 必填 | 控制交付边界 |
| 不做范围 | 选填 | 需求边界清晰时可省略；易混淆时建议填写 |
| 约束条件 | 选填 | 存在时间、合规、技术限制时填写 |
| 依赖方 | 选填 | 涉及跨团队或外部系统时填写 |
| 待确认问题清单 | 必填 | 澄清过程的核心产出，无问题时注明“无” |
| 确认签字 | 必填 | 明确各方对记录内容的认可 |
只填必填项时，记录表仍能回答“谁提出、为什么做、给谁用、做到什么程度、本次做什么、还有什么没定、谁确认”这几个问题，构成最小可用版本。对于内部小改动类需求，可进一步简化背景和使用场景的篇幅，但验收口径和待确认问题清单不建议省略。
按需求类型调整时，可参考以下规则：面向外部客户的需求，加强需求来源和验收口径的记录；涉及多系统集成的需求，必填依赖方和约束条件；合规或安全相关需求，必填约束条件并保留确认签字；探索型需求，可放宽验收口径的精确度，但需在待确认问题清单中写明待验证的假设。
填写示例：一条完整的需求澄清记录
以下示例为演示情景，用于说明各字段的写法，不代表真实客户案例。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | 2025-031 |
| 需求名称 | 客服工单支持按客户等级自动排序 | |
| 需求来源 | 客服团队季度复盘会议，反映高价值客户工单响应偏慢 | |
| 提出人 | 客服主管李某 | |
| 澄清日期 | 2025年3月12日 | |
| 记录人 | 产品经理王某 | |
| 需求理解 | 背景 | 上季度高价值客户工单平均首次响应时间为6小时，普通客户为2小时，原因是工单按提交时间排队，高价值客户工单常被积压 |
| 目标用户 | 一线客服人员、客服主管 | |
| 使用场景 | 客服登录工单列表后，系统按客户等级和提交时间综合排序，客服优先处理高等级客户工单；主管可在列表中筛选查看各等级工单积压情况 | |
| 要解决的问题 | 高价值客户工单无法优先处理，导致响应超时和客户投诉 | |
| 期望与验收 | 期望结果 | 高价值客户工单在提交后1小时内得到首次响应，客服可按客户等级查看和处理工单 |
| 验收口径 | 工单列表默认按客户等级降序、同级按提交时间升序排列；高价值客户工单首次响应时间统计不超过1小时；主管可按客户等级筛选工单 | |
| 优先级 | 高 | |
| 范围与约束 | 本期范围 | 工单列表排序规则调整、客户等级字段展示、主管筛选功能 |
| 不做范围 | 本期不做自动分配工单、不做客户等级规则的自定义配置 | |
| 约束条件 | 需在4月底前上线，配合客户续约季；客户等级数据来自现有CRM系统 | |
| 依赖方 | CRM团队提供客户等级接口，需在3月25日前确认字段口径 | |
| 待确认问题 | 问题 | 客户等级分为几档，排序时是否所有高等级都优先于低等级 |
| 结论 | 客户等级分为三档，排序按等级降序，同等级内按提交时间升序 | |
| 确认人 | 客服主管李某 | |
| 确认日期 | 2025年3月14日 | |
| 确认签字 | 产品 | 王某，2025年3月14日 |
| 需求提出方 | 李某，2025年3月14日 | |
| 研发 | 张某，2025年3月15日 | |
| 测试 | 赵某，2025年3月15日 |
示例体现了三点填写规范：验收口径写成可检验的条件，包含排序规则、响应时间和筛选能力；待确认问题记录了结论、确认人和日期，可追溯；不做范围明确列出自动分配和自定义配置，避免后续争议。实际使用时，待确认问题可能有多条，应逐条记录并跟进至结论确定。
模板的调整与维护方法
模板需要随团队流程演进，建议每季度回顾一次使用情况，按以下方法裁剪和维护。
按需求类型与团队规模裁剪字段
- 小团队或需求较少的团队，可先使用最小可用版本，只保留必填字段，减少填写负担。
- 需求量大、跨团队协作多的团队，建议保留依赖方、约束条件和确认签字，便于交接和追责。
- 面向外部客户或合规场景的需求，增加需求来源出处和验收口径的详细程度。
- 探索型或早期需求，可简化验收口径，但保留待确认问题清单，记录待验证的假设。
模板版本与变更记录
为模板设置版本号，例如“v1.0”，并在模板末尾附变更记录，写明变更日期、变更内容和变更人。字段增删或必填规则调整时升级版本号，已填写的记录保留原版本，避免历史记录被追溯修改。变更后通知使用模板的团队，说明调整原因。
与需求评审、需求建模的衔接边界
澄清记录解决“需求是否被理解清楚”的问题，输出的是对齐后的需求描述和待确认问题结论。需求评审在此基础上判断需求是否值得做、优先级是否合理；需求建模进一步把需求转化为结构化的表达，例如流程、状态或数据关系。三者顺序衔接，澄清记录不替代评审结论，也不承担建模职责。评审中如发现新的模糊点，应回到澄清记录补充，而不是只在评审纪要中口头说明。
定期回顾模板使用情况的检查点
- 抽查近期记录，检查验收口径是否可检验、待确认问题是否都有结论和确认人。
- 统计哪些字段经常留空，判断是字段不适用还是填写习惯问题，据此调整必填规则。
- 收集团队反馈，确认模板是否增加了不必要的填写负担。
- 检查澄清记录与后续评审、开发任务的对应关系，确保记录可被引用和追溯。
当团队使用文档或工作项工具承载澄清记录时，可将模板固化为文档模板，使每次澄清按同一结构创建；记录与对应的需求工作项保持关联，便于在评审和开发阶段回查。ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应；文档记录页面版本并支持查看与回滚，也可为不同角色配置读写权限。ONES Assistant 可围绕音视频转录、用户反馈洞察和 PRD 质量检查提炼要点与待澄清问题，辅助完成澄清和录入，具体可用范围以实际开通情况为准。工具承载的是记录和追溯动作，模板字段和填写规范仍由团队按自身流程确定。
常见问题
澄清会上问题很多，当场定不下来的怎么记？
当场无法定论的问题，在待确认问题清单中记录问题本身，结论栏留空并标注“待确认”，同时写明计划找谁确认、期望何时有结论。会后由记录人逐条跟进，结论确定后补填结论、确认人和确认日期。这样记录表能反映真实的澄清进度，避免用推测内容填充结论，后续评审时也能直接看到哪些前提尚未落定。
需求很小，也要填完整张表吗？
不需要。小改动类需求可以使用最小可用版本，只填必填字段：记录编号、需求名称、需求来源、提出人、澄清日期、记录人、背景、目标用户、使用场景、要解决的问题、期望结果、验收口径、优先级、本期范围、待确认问题清单和确认签字。背景和使用场景的篇幅可以压缩，验收口径和待确认问题清单建议保留，它们决定后续能否判断需求是否完成。
澄清记录和需求评审纪要有什么区别，需要各写一份吗？
两者解决的问题不同。澄清记录回答“需求是否被理解清楚”，输出对齐后的需求描述和待确认问题结论；评审纪要考虑“需求是否值得做、优先级是否合理”，输出评审结论和排期意见。实际操作中不必重复记录同一内容：评审前以澄清记录作为输入，评审中如发现新的模糊点，回到澄清记录补充字段和待确认问题，评审纪要只记录评审结论与决策依据。
待确认问题的结论后来变了，原记录要改吗？
建议保留原记录，以追加方式更新。可以在待确认问题清单中新增一行，写明变更后的问题、新结论、确认人和日期，并注明替代了此前的哪条结论；如果使用支持版本管理的文档工具，也可以保留历史版本供回查。直接覆盖旧结论会让后续人员看不到判断依据的变化过程，尤其在需求范围或验收口径调整时容易产生争议。
团队用文档工具承载澄清记录时，怎样和需求工作项对应起来？
常见做法是把澄清记录模板固化为文档模板，每次澄清按同一结构创建文档，并在文档中写明对应的需求编号或工作项链接。以 ONES 为例，ONES Wiki 支持使用模板库一键创建文档，页面组可关联项目，使需求与文档互相对应；文档记录页面版本并支持查看与回滚，也可为不同角色配置读写权限。这样在评审和开发阶段可以顺着需求回查澄清依据。具体模板字段和填写规范仍由团队按自身流程确定。
