需求澄清会议结束后，判断记录是否完整，关键看它能否直接支撑三个后续动作：评审会上做判断、排期时拆工作项、验收时对照口径核对结果。如果记录只写了讨论过程，评审时还要重新澄清，排期时无法估算，这份记录就还没有达到完整标准。下面这份检查清单按使用对象、字段标准、三级判定、证据分工和阻断项组织，适合在提交评审前和排期前逐项核对。
要点总览（TL;DR）
- 判断澄清记录是否完整，看它能否直接支撑三个动作：评审会上做判断、排期时拆工作项、验收时对照口径核对结果。
- 字段检查覆盖背景目标、范围边界、功能与规则、验收口径、依赖约束、未决项、确认与版本七类，每项以“有无明确结论”为通过标准，不以篇幅长短论完整。
- 三级判定递进使用：可评审要求字段无空缺、争议收敛为待决策项；可排期要求范围可拆、依赖已确认；可验收要求口径具体到可核对的条件或示例。
- 每类检查项都要明确证据由谁提供、由谁确认，确认以版本号、时间和确认人留痕，口头确认需补文字记录。
- 范围未定、验收口径缺失、关键依赖未确认、重大未决项无负责人和时限属于阻断项，清零且双方确认后方可放行。
谁在什么时点使用这份检查清单
这份清单检查的对象是需求澄清记录，检查目的是判断记录是否足以支撑评审、排期与验收。它不评价需求本身是否值得做，也不替代需求建模和正式评审流程。澄清记录检查通过，意味着后续环节可以基于记录做判断；需求方案是否成立、优先级是否合理，仍要在评审中决定。
清单由四类角色共同使用，各自关注点不同：
| 角色 | 主要检查内容 | 检查时点 |
|---|---|---|
| 需求提出方 | 背景目标、范围边界、业务规则、验收口径是否符合业务预期 | 澄清会议结束后确认，提交评审前复核 |
| 产品/需求分析人员 | 字段是否齐全、结论是否明确、未决项是否登记完整 | 会议结束后整理记录时，提交评审前 |
| 研发负责人 | 功能与规则描述是否可拆解、依赖与约束是否明确、未决项是否影响估算 | 排期前 |
| 测试负责人 | 验收口径是否具体到可核对的条件或示例 | 提交评审前，排期前复核 |
检查分三次进行：澄清会议结束后做首次完整性检查，补齐缺项；提交评审前做放行检查，确认阻断项清零；排期前做可排期复核，重点看范围可拆分性和依赖确认情况。三次检查使用同一份记录，检查结论随记录版本更新。
澄清记录必备字段与逐项通过标准
字段检查的判断标准是“有无明确结论、能否据此做后续判断”，记录篇幅长短不作为完整度依据。以下七类字段逐项核对，每项都需要对应的证据形式。
| 检查项 | 通过标准 | 证据形式 |
|---|---|---|
| 背景与目标 | 写清要解决的具体问题、受影响的角色或业务环节，以及成功如何体现；目标可对应到可观察的结果 | 会议纪要中的目标陈述、业务方确认消息 |
| 范围边界 | 本次做什么、明确不做什么各有清单；边界外的相近需求已注明归属或另行处理 | 范围清单、原型或文档链接 |
| 功能与规则描述 | 主流程步骤完整，异常流程有处理结论，关键业务规则写明判断条件和结果 | 流程图、原型、规则说明文档 |
| 验收口径 | 验收条件可判断真假，或给出具体示例说明输入与预期结果；避免“体验流畅”这类无法核对的表述 | 验收条件列表、数据样例、测试场景示例 |
| 依赖与约束 | 上下游系统、数据来源、外部团队配合事项逐项列出，注明对接方和当前确认状态 | 依赖清单、对接确认消息、接口文档链接 |
| 未决项清单 | 每个未决项写明问题描述、负责人、截止时间、未按时解决的默认处理方式 | 未决项表格、负责人确认记录 |
| 确认与版本 | 记录有版本号、确认时间和确认人，需求方与研发方均已确认当前版本 | 文档版本记录、确认消息 |
逐项检查时，遇到“会上讨论过但没写结论”的内容，按未通过处理，补写结论后再勾选。功能与规则描述中，异常流程常被遗漏，检查时重点看失败、超时、权限不足、数据为空等情形是否有明确处理方式。验收口径检查可以请测试负责人用一句话复述“怎样算通过”，复述不出来说明口径还不够具体。
支撑评审、排期与验收的三级判定
字段检查回答的是单项是否达标，三级判定回答的是整份记录能否进入下一个环节。三个判定递进使用，后一级在前一级基础上增加要求。
| 判定级别 | 必要条件 | 不满足时的处理 |
|---|---|---|
| 可评审 | 七类必备字段无空缺；争议点已收敛为待决策项，每项写明可选方案和倾向意见；范围边界与验收口径有初稿 | 退回补充记录，不进入评审议程；争议未收敛的，先安排专项澄清 |
| 可排期 | 范围可拆分为具体工作项；依赖与约束已确认到对接方和当前状态；未决项不影响主流程工作量估算，或已有默认处理方式 | 依赖未确认的，先完成对接确认；未决项影响估算的，转为排期前置任务 |
| 可验收 | 验收口径具体到可核对的条件或示例，测试负责人确认可测；验收所需的数据或环境条件已注明 | 口径模糊的，补充示例后重新确认；测试无法构造场景的，补充数据样例 |
三级判定之间存在升级条件。可评审的记录进入评审后，评审结论（如方案调整、范围裁剪）需要回写到记录并更新版本，才能进入可排期判定。可排期的记录在开发启动前，验收口径仍需保持可核对状态；如果开发过程中验收口径发生变化，需要重新走确认流程并记录变更原因。评审会上只需对记录中的待决策项做判断，如果会上仍在澄清背景和范围，说明记录尚未达到可评审判定。
证据留存与负责人分工
记录只有结论没有依据，后续出现理解分歧时无法追溯。每类检查项都要明确证据由谁提供、由谁确认，确认结果留在记录中。
| 检查项 | 证据类型 | 证据提供方 | 确认方 |
|---|---|---|---|
| 背景与目标 | 会议纪要、业务方确认消息 | 需求提出方 | 产品/需求分析人员 |
| 范围边界 | 范围清单、原型或文档链接 | 产品/需求分析人员 | 需求提出方、研发负责人 |
| 功能与规则描述 | 流程图、原型、规则说明 | 产品/需求分析人员 | 研发负责人 |
| 验收口径 | 验收条件列表、数据样例 | 产品/需求分析人员、需求提出方 | 测试负责人 |
| 依赖与约束 | 依赖清单、对接确认消息 | 研发负责人 | 产品/需求分析人员 |
| 未决项清单 | 未决项表格、负责人回复 | 产品/需求分析人员 | 各未决项负责人 |
确认方式采用可留痕的形式：在记录中标注版本号、确认时间和确认人，口头确认需要补一条文字记录。证据缺失时，该项按未通过处理，由对应提供方在约定时间内补齐；补齐前该项不参与放行判定。需求方确认业务口径，研发确认技术可行性与依赖状态，测试确认验收可测，三方确认范围不重叠，避免同一项被重复确认或无人确认。
澄清结论需要进入后续流程时，记录本身要能被评审和排期环节直接引用。ONES 的文档与工作项协作方式可以把澄清记录沉淀在 Wiki 页面，并把拆解出的工作项放入项目计划，评审和排期时基于同一份内容推进；ONES Assistant 可围绕会议转录、用户反馈和 PRD 提炼要点、待澄清问题与拆解建议，帮助减少整理记录时的遗漏，具体可用范围以实际部署与权限配置为准。
阻断项与记录完成条件
阻断项是必须清零才能进入评审或排期的检查项，跟踪项可以带入后续环节但需要登记。两类分开处理，避免把所有缺项都当成放行障碍，也避免把关键缺项当成普通待办。
| 类型 | 示例 | 处理方式 |
|---|---|---|
| 阻断项 | 范围边界未确定；验收口径缺失或无法判断；关键上下游依赖未确认对接方；重大未决项没有负责人和截止时间 | 清零后方可提交评审或排期；未清零的记录退回补充 |
| 跟踪项 | 非关键规则的细节待补充；次要异常流程的处理方式待确认；文档格式或表述待统一 | 登记负责人和时限，可带入评审，但在对应工作项启动前关闭 |
记录整体完成的判定条件有三条同时满足：阻断项全部清零；需求方与研发方对当前版本完成确认，测试负责人对验收口径确认可测；记录有版本号和确认留痕。三条中任一条不满足，记录状态保持“待补充”，不进入评审议程或排期池。
退回补充时，由产品/需求分析人员在记录中列出未通过项、对应负责人和补充截止时间，补充完成后更新版本号并重新走放行检查。同一需求多次退回的，在记录中保留每次退回原因，便于评审时判断争议集中在范围、口径还是依赖上。记录完成并放行后，后续评审结论和排期调整继续回写到同一份记录，保持版本连续，验收时以最新确认版本的验收口径为准。
常见问题
澄清会议开完了，但记录里还有几处没写结论，能先提交评审再补吗？
要区分缺的是什么。如果缺的是范围边界、验收口径、关键依赖这类阻断项，记录应保持“待补充”状态，退回补齐后再提交评审；带着这些缺口进评审，会上往往要重新澄清背景和范围，评审就变成了第二次澄清会。
如果缺的是非关键规则的细节、次要异常流程的处理方式，可以作为跟踪项登记负责人和时限后带入评审，但要在对应工作项启动前关闭。判断依据是这条缺项会不会影响评审做判断、排期做估算。
需求方和研发方对某条业务规则的理解不一致，记录该怎么写才算完成？
理解不一致本身不构成记录不完整的理由，关键是把分歧转成明确的待决策项：写清分歧点、双方各自的理解、可选方案和倾向意见，指定决策人和决策时限。这样记录达到可评审判定，评审会上只需对这条待决策项做判断。
如果分歧涉及范围边界或验收口径，则属于阻断项，需要先收敛再放行。记录中保留分歧的原始表述，便于后续追溯结论是怎么形成的。
排期前发现某个上下游依赖还没确认对接方，记录还能算可排期吗？
不能。依赖与约束已确认到对接方和当前状态，是可排期判定的必要条件。依赖未确认时，工作量估算缺少前提，排出来的计划容易在开发中途返工。
处理方式有两种：先完成对接确认再排期；或者把该依赖转为排期前置任务，明确负责人和完成时间，主流程工作项在依赖确认后再启动。两种方式都要回写到记录并更新版本。
开发过程中验收口径变了，原来的澄清记录还有效吗？
原记录仍作为历史版本保留，但验收以最新确认版本的验收口径为准。口径变化需要重新走确认流程：由产品/需求分析人员更新记录，测试负责人重新确认可测，记录变更原因和确认时间，更新版本号。
如果变化影响到范围或依赖，还要同步复核可排期判定，避免计划与实际范围脱节。版本连续留存的价值在于，验收出现争议时可以追溯口径是在哪个版本、由谁确认的。
小需求也要按这份清单逐项检查吗？
清单的检查项可以按需求复杂度裁剪，但阻断项的逻辑不变。范围边界、验收口径、关键依赖这几项，无论需求大小都直接影响评审判断和排期估算，缺失就会在后续环节暴露。
可以简化的是证据形式和检查深度：小需求用会议纪要加一条确认消息即可，不必单独出原型或规则文档；但“有无明确结论”这个标准不因需求小而降低。
