需求澄清记录把口头讨论中模糊、分散、容易失真的信息，整理成可复核的书面结论。本文给出一份完整填写的记录示例，覆盖澄清对象、问题清单、确认结果、业务规则、非功能约束、冲突取舍与待办闭环，并逐项解释填写依据。示例为演示情景，非真实客户案例，读者可据此迁移到自己的需求澄清场景。
要点总览（TL;DR）
- 一份可用的需求澄清记录至少包含：澄清对象与背景、待确认问题清单、逐条确认结果、业务规则与边界、非功能约束、冲突与取舍、待办与责任人、结论状态。
- 示例把“自动提醒快要超期的任务”拆成6个可回答的问题，确认结果写成含条件、动作与例外的可验证陈述，非功能约束落到可检查的数值条件。
- 迁移到新需求时按“先列问题再记结论、按业务问题到冲突分层组织、用状态与待办闭环、与建模评审衔接”的顺序填写。
- 澄清记录只承载需求理解，结构化表达归需求建模，正式质量检查归需求评审；常见误用包括只记结论不记问题、结论不可验证、冲突无决策人。
这份示例要解决什么问题
示例设定一个常见的业务问题型需求：运营团队希望系统能够“自动提醒快要超期的任务”，但最初只有这一句口头描述。提出方说不清提醒对象是谁、提前多久提醒、通过什么渠道提醒；开发方也无法判断工作量与影响范围。澄清前，这个需求处于“听起来合理、做起来没底”的状态。
示例的目标是把这句模糊描述转成一组可复核的确认结论：谁在什么条件下收到提醒、提醒内容包含什么、哪些情况不提醒、性能与权限上有什么要求、还有哪些问题悬而未决。澄清完成后，团队应能据此判断是否进入需求建模与评审，而不是继续依赖口头共识。
为便于对照，先给出示例背景卡：
| 项目 | 示例内容 |
|---|---|
| 澄清对象 | 任务超期提醒需求（业务问题型） |
| 提出方 | 运营团队负责人 |
| 参与角色 | 需求提出人、产品经理、开发负责人、测试负责人 |
| 澄清目标 | 明确提醒触发条件、接收对象、渠道、边界与约束，形成可复核结论 |
| 示例声明 | 本文为演示情景，非真实客户案例，不涉及真实客户身份、实测数据或量化效果 |
完整示例：一份填好的需求澄清记录
下面是一份已填写的记录。为便于阅读，按记录头部、问题清单、规则与约束、冲突取舍、待办、结论状态分块呈现，实际使用时可以合并为一张表或一份文档。
记录头部
| 字段 | 填写内容 |
|---|---|
| 需求名称 | 任务超期提醒 |
| 提出方 | 运营团队负责人 |
| 澄清日期 | 示例日期，按实际澄清会议日期填写 |
| 参与角色 | 需求提出人、产品经理、开发负责人、测试负责人 |
| 记录状态 | 已澄清，部分事项待补充 |
待确认问题清单与逐条确认结果
| 编号 | 待确认问题 | 确认结果 | 状态 |
|---|---|---|---|
| Q1 | 提醒针对哪些任务？ | 仅针对已指派负责人且设置了截止日期的任务；未指派或未设截止日期的任务不提醒。 | 已确认 |
| Q2 | 提前多久提醒？ | 截止日期前1天提醒一次；截止日期当天未完成再提醒一次。 | 已确认 |
| Q3 | 提醒发给谁？ | 发给任务负责人；任务负责人为空时不发送，由任务创建人补指派后进入提醒范围。 | 已确认 |
| Q4 | 通过什么渠道提醒？ | 站内通知；是否增加邮件渠道待补充确认。 | 待补充 |
| Q5 | 已完成任务是否还提醒？ | 任务状态为已完成或已取消后不再提醒。 | 已确认 |
| Q6 | 提醒内容包含什么？ | 任务标题、截止日期、剩余天数、任务链接。 | 已确认 |
业务规则、边界与非功能约束
| 类别 | 条目 |
|---|---|
| 业务规则 | 同一任务在同一提醒节点只发送一次，避免重复打扰；截止日期变更后按新日期重新计算提醒节点。 |
| 业务边界 | 本期只覆盖任务超期提醒，不包含项目整体延期提醒、跨项目汇总提醒。 |
| 数据边界 | 提醒只读取任务标题、负责人、截止日期、状态四类字段，不读取任务描述正文。 |
| 非功能约束 | 提醒发送延迟不超过设定节点后30分钟；单次提醒发送失败时重试1次；提醒记录保留90天可查。 |
| 权限约束 | 提醒内容仅对任务负责人及项目管理员可见，遵循现有项目权限配置。 |
冲突点与取舍结论
| 冲突点 | 各方意见 | 取舍结论 | 理由与决策人 |
|---|---|---|---|
| 提醒频率 | 运营希望每天提醒；开发担心打扰过多 | 按Q2的两个节点提醒，不每日重复 | 在覆盖关键时点的前提下控制打扰；决策人为产品经理，提出方认可 |
| 提醒渠道 | 运营希望同时发邮件；开发建议先做站内通知 | 本期站内通知，邮件渠道列入待补充 | 先验证提醒规则是否有效，再扩展渠道；决策人为产品经理 |
待办事项与责任人
| 待办 | 责任人 | 截止时间 |
|---|---|---|
| 确认是否增加邮件渠道及发送范围 | 需求提出人 | 示例日期后2个工作日内 |
| 补充提醒失败重试的技术方案说明 | 开发负责人 | 示例日期后3个工作日内 |
| 核对权限约束与现有项目权限配置是否一致 | 测试负责人 | 示例日期后3个工作日内 |
结论状态
本记录结论状态为“部分待补充”：Q1、Q2、Q3、Q5、Q6及规则、边界、非功能约束已确认，可进入需求建模；Q4渠道问题与两项技术待办完成后，记录状态更新为“已确认”。若邮件渠道涉及跨团队资源协调，则升级为“需升级决策”，由产品负责人与运营负责人共同决定。
逐项解释：每个字段为什么这样填
示例中的每个字段都承担特定判断任务。理解填写依据，比照抄表格更重要。
问题清单如何从模糊表述中拆出可回答的问题
原始描述“自动提醒快要超期的任务”包含多个未定义成分：提醒对象、触发时点、接收人、渠道、内容、例外情况。拆问题时，针对每个未定义成分提出一个可以用“是/否”或具体条件回答的问题，例如把“快要超期”拆成“提前多久”和“截止当天是否再提醒”两个问题。问题清单的价值在于暴露分歧，Q2和Q4正是讨论中出现不同意见的地方。
确认结果如何写成可验证的陈述
确认结果避免复述原话。示例中Q1写成“仅针对已指派负责人且设置了截止日期的任务；未指派或未设截止日期的任务不提醒”，读者可以直接用一条任务去核对是否符合。可验证的陈述通常包含条件、动作和例外三部分；只写“提醒负责人”无法判断边界，也无法据此设计测试用例。
业务规则与边界如何区分
业务规则描述系统在业务上必须遵守的约束，例如“同一任务在同一提醒节点只发送一次”；业务边界描述本期做什么、不做什么，例如“不包含项目整体延期提醒”。规则回答“怎么算对”，边界回答“做到哪里为止”。两者分开记录，后续范围变更时更容易判断影响。
非功能约束如何落到可判断的条件
非功能约束容易写成“及时”“稳定”这类无法判断的词。示例把它落成“发送延迟不超过30分钟”“失败重试1次”“记录保留90天”，每一条都可以在验收时检查。填写时追问一句“怎么判断做到了”，通常就能把形容词转成条件。
冲突取舍如何记录理由与决策人
冲突点记录各方意见、最终结论、理由和决策人四项。只写结论不写理由，后续有人质疑时无法回溯；不写决策人，争议会反复回到讨论桌。示例中提醒频率和渠道两处冲突都记录了决策人为产品经理，并提出方认可，这为后续变更提供了明确起点。
可迁移规律：换一个需求怎么套用
把示例迁移到新需求时，可以按以下顺序组织，每一步都有明确的完成标志。
- 先列问题，再记录结论。澄清会前根据原始描述列出待确认问题，会上逐条讨论并当场记录结果。完成标志是每个问题都有“已确认”“待补充”或“需升级决策”之一的状态。
- 按层次组织内容。依次覆盖业务问题（为什么做、解决谁的什么问题）、功能行为（触发条件、接收对象、内容）、业务规则（重复、变更、例外）、约束（性能、权限、数据范围）、边界（本期不做什么）、冲突（分歧与取舍）。层次清楚，遗漏更容易被发现。
- 用状态和待办闭环。每条待补充事项都要有责任人和截止时间，下次澄清从待办清单开始，而不是重新讨论全部问题。全部待办关闭后，记录状态更新为已确认。
- 与后续环节衔接。已确认的记录作为需求建模的输入，建模时发现的新问题回填到记录中；进入评审前，评审者可以先核对记录中的结论是否被完整表达。记录、建模、评审三者形成前后衔接，而不是各自独立。
记录需要在团队内留存和流转时，可以放在项目工作项与知识库中：把澄清结论关联到对应需求工作项，把完整记录沉淀为文档页面，待办转为可跟踪的任务并指派责任人。ONES 支持在工作项与 Wiki 页面中组织这类内容，ONES Assistant 可围绕会议、反馈和文档提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入；相关能力以实际版本与配置为准。
适用边界与常见误用
需求澄清记录服务于需求理解：把讨论中的模糊信息整理成可复核的结论。它不承担结构化表达的任务，需求的建模与表达归需求建模环节；它也不承担正式质量检查，评审与确认归需求评审环节。澄清记录可以作为这两步的输入，但不能替代它们，也不应被当作需求规格说明书使用。
常见误用及对照如下：
| 误用 | 表现 | 修正方式 |
|---|---|---|
| 只记结论不记问题 | 记录里只有“已确认提醒规则”，看不出当初哪些点存在分歧 | 保留问题清单与状态，结论对应到具体问题编号 |
| 结论不可验证 | 写“及时提醒”“合理范围内”，无法判断是否做到 | 补充条件、数值或可检查的判断标准 |
| 冲突无决策人 | 记录了取舍结果，但不知道谁定的、为什么 | 每条冲突写明决策人与理由 |
| 待办无闭环 | 待补充事项没有责任人和时间，下次会议重新讨论 | 待办指派到人并设截止时间，状态随进展更新 |
| 把记录当规格书 | 用澄清记录直接替代需求文档与评审 | 明确记录只承载理解结论，建模与评审另行完成 |
掌握这些边界后，记录才能稳定发挥“把口头共识变成书面结论”的作用，并在需求变更时提供可回溯的依据。
常见问题
澄清会上问题很多，时间不够逐条讨论完，记录该怎么处理？
把问题按“影响能否进入建模”排序，先讨论会直接阻塞后续工作的条目，例如触发条件、接收对象、范围边界。会上无法形成结论的问题，当场标记为“待补充”或“需升级决策”，写明责任人和补充时间，不要留空或凭印象补写。下次澄清从待办清单开始，避免重新讨论已确认内容。
提出方在澄清后改变了想法，已确认的结论怎么更新？
保留原结论并新增一条变更记录，写明变更内容、提出人、时间和影响范围，再更新对应问题编号的状态。涉及冲突取舍的变更，需要原决策人重新确认。这样记录既能反映当前结论，也能回溯此前的判断依据，避免口头变更后各方理解不一致。
需求比较简单，是否还需要完整的澄清记录？
可以按比例裁剪字段，但问题清单、确认结果和结论状态建议保留。简单需求通常问题数量少，记录可以只有几行；省略问题清单会让后续无法判断哪些点已经讨论过。判断标准是：换一个未参与讨论的同事读这份记录，能否据此理解需求边界并开始建模。
澄清记录和需求文档、评审是什么关系？
澄清记录是需求文档的输入之一，承载讨论中形成的理解结论；需求建模把这些结论组织成结构化表达；需求评审对表达结果做正式质量检查。三者顺序衔接，记录中的待补充事项未关闭前，不建议直接进入评审，否则评审会退化为重复澄清。
记录中的待办如何跟踪，避免澄清后无人推进？
每条待办指派到具体责任人并设截止时间，状态随进展更新。团队可以把澄清结论关联到对应需求工作项，把完整记录沉淀为文档页面，待办转为可跟踪的任务。ONES 支持在工作项与 Wiki 页面中组织这类内容，ONES Assistant 可围绕会议、反馈和文档提炼要点、待澄清问题与拆解建议，相关能力以实际版本与配置为准。
