需求澄清记录要保留四类信息：澄清对象与背景、问题与答复、结论与影响、责任与后续动作。记录以“一问一答一结论”为最小单元，每条结论能追溯到答复人和确认时间，未确认的事项单独标为待定。这样，开发、测试和业务方在后续设计、验收时能查到依据，减少因理解偏差返工。记录归档时，可借助ONES等工作项与文档关联能力，把澄清记录挂到对应需求条目下。
要点总览（TL;DR）
- 需求澄清记录保留四类信息：澄清对象与背景、问题与答复、结论与影响、责任与后续动作，以“一问一答一结论”为最小单元。
- 字段按头部、问答、结论、后续四个信息块组织；每条结论标注答复人和确认时间，待定项单独列出并指定负责人。
- 填写按澄清前整理问题清单、澄清中逐条确认、澄清后整理结论、归档关联需求条目四步推进，记录随过程同步形成。
- 需求提出方、分析人员、开发、测试和记录维护人各有交付物；结论由提出方与分析人员共同确认，验收口径类结论需测试参与。
- 同步前用检查清单核验：结论可追溯、待定项有归属、范围与验收口径可判定、记录与需求条目关联并保留版本。
一份澄清记录先写清哪些字段
字段设计的目标是让记录脱离会议现场后仍能被读懂。建议按四个信息块组织，每块承担不同职责：头部说明“澄清了什么”，问答块保留“谁怎么答复”，结论块固定“最终确认了什么”，后续块交代“还有什么没完成”。
头部字段：定位澄清对象
头部用于把记录和具体需求绑定，至少包含：需求名称或编号、需求来源（业务部门、客户、内部改进等）、提出人、澄清参与人及所属角色、澄清时间与记录人。需求名称应与需求条目保持一致，避免同一需求出现多个叫法。参与人写清角色比只写姓名更有用，后续追溯时能判断答复的权威性。
问题与答复字段：保留原始依据
每条问题单独成行，字段包括：问题编号、问题描述、答复内容、答复人、答复时间、确认状态。问题描述要写到具体分歧点，例如“订单取消后优惠券是否退回、退回后有效期如何计算”，避免只写“优惠券规则待确认”。答复内容记录要点和关键原话，尤其是带条件的表述，如“仅限未发货订单”。确认状态可设为已确认、待定、有争议三类，便于筛选。
结论字段：固定确认结果
结论不是答复的简单复制，而是整理后的可执行表述。需要写明：确认范围（本次澄清覆盖哪些功能或流程）、验收口径（怎样算满足要求）、边界与排除项（明确不做什么、哪些场景不适用）。如果澄清影响了已有需求或方案，在结论中注明受影响的条目编号和影响方式，例如“原需求REQ-102的退款时效由3个工作日调整为5个工作日”。
后续字段：让待定项有归属
后续字段包括：待办事项、负责人、截止时间、关联文档或工作项链接。待定项必须单独列出，不能混在结论里。每条待办写清完成标志，例如“补充优惠券退回规则说明文档并由业务负责人确认”，而不是“继续跟进”。
| 信息块 | 字段 | 填写要求 |
|---|---|---|
| 头部 | 需求名称/编号、来源、提出人、参与人及角色、澄清时间、记录人 | 与需求条目一致，参与人标注角色 |
| 问题与答复 | 问题编号、问题描述、答复内容、答复人、答复时间、确认状态 | 一问一行，状态限已确认/待定/有争议 |
| 结论 | 确认范围、验收口径、边界与排除项、受影响需求 | 写成可执行表述，注明影响条目 |
| 后续 | 待办、负责人、截止时间、关联文档 | 待定项单列，写清完成标志 |
按什么步骤完成一次澄清并落记录
字段只有嵌入澄清过程才有价值。把一次澄清拆成澄清前、澄清中、澄清后和归档四段，每段都有明确的输入、动作和输出，记录随过程同步形成，避免会后凭记忆补写。
澄清前：整理问题清单
输入是需求初稿、相关背景材料和已有疑问。动作是逐条梳理理解分歧，把模糊表述转成可回答的问题，并按影响程度排序。输出是一份待澄清问题清单，每个问题注明提出人和希望得到的答复类型（规则、范围、优先级等）。问题清单提前发给答复方，能让对方带着信息参会，减少现场空转。
澄清中：逐条提问并当场确认
输入是问题清单和参会角色。动作是按编号逐条提问，记录答复人原话要点，每得到一条答复就复述一遍请对方确认，确认后当场标记状态。遇到无法当场决定的问题，明确记为待定，并约定答复人和时间。输出是带确认状态的问答记录。现场记录不必追求措辞完整，但要保证答复人和关键条件不遗漏。
澄清后：整理结论与待定项
输入是现场问答记录。动作是把已确认答复整理成结论，检查结论之间是否矛盾，把待定项汇总成待办清单并分配负责人和截止时间，然后将记录同步给提出人、开发和测试等相关角色。输出是一份可评审的澄清记录和一份待办清单。同步时说明哪些结论改变了原有理解，方便相关角色快速定位影响。
归档：与需求条目关联
输入是定稿的澄清记录。动作是把记录挂到对应需求条目或需求文档下，保留版本号和修改痕迹，后续补充澄清时新增版本而非覆盖原文。输出是可追溯的记录版本。使用ONES时，可以把澄清记录作为需求工作项下的文档或关联内容保存，需求状态、负责人和变更历史在同一处查看，评审或验收时从需求条目直接找到对应澄清依据。
角色分工与各自交付物
澄清记录常见的失效原因是无人对结论负责。把提问、答复、确认、维护四类动作分配到具体角色，每类角色都有可见的交付物，记录质量才有保障。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求提出方 | 说明业务场景、期望结果和约束条件，对业务规则类问题给出答复 | 业务背景说明、规则答复、结论确认 |
| 需求分析人员 | 组织问题清单，主持澄清，整理答复与结论 | 待澄清问题清单、澄清记录初稿、结论汇总 |
| 开发角色 | 从实现角度提出数据、接口、异常场景的疑问 | 技术类问题清单、实现约束说明 |
| 测试角色 | 从验收角度提出判定标准和边界场景的疑问 | 验收口径问题、测试关注点 |
| 记录维护人 | 维护记录版本，跟踪待定项关闭，保证可追溯 | 定稿记录、待办跟踪表、版本变更说明 |
需求分析人员通常兼任记录维护人，但在澄清场次多、待定项多时，建议指定专人跟踪待办。答复人对自己的答复内容负责，结论由需求提出方和需求分析人员共同确认；涉及验收口径的结论，测试角色参与确认。角色可以一人多岗，但每类交付物要有明确归属。
填写示例：一条澄清记录如何从问题走到结论
以下为演示情景，用于说明字段写法，不代表真实项目。假设某内部管理系统需求中，业务方提出“审批超时后自动提醒”，团队对“超时”和“提醒”的理解不一致。
问题与背景
问题编号Q-03，问题描述：“审批超时自动提醒”中的超时如何计算，提醒发给谁、通过什么渠道、频率如何？背景是原需求只写了一句话，开发和测试都无法确定实现范围和验收标准。
答复记录
答复人：业务负责人李某；答复时间：2025年3月12日澄清会。答复要点：超时从审批任务到达审批人时开始计算，工作日满24小时视为超时；提醒发给当前审批人，渠道为系统内消息；每个审批任务每天提醒一次，最多提醒三次。记录时保留“工作日”“每天一次”“最多三次”这些条件，不概括为“定时提醒”。
结论与待定项
结论写成：审批任务到达后满1个工作日未处理即触发提醒，提醒对象为当前审批人，渠道为系统内消息，每日一次、最多三次；验收时以任务到达时间、提醒记录条数和接收人为判定依据。待定项单列：节假日是否计入工作日尚未确认，负责人为业务负责人李某，截止时间3月19日。这样结论可直接用于开发和测试，待定项也不会被误当成已确认规则。
关联待办
待办一：确认节假日规则并更新结论，负责人李某，截止3月19日，完成标志是澄清记录新增确认条目。待办二：测试角色根据结论补充提醒场景用例，负责人测试张某，截止3月21日。关联文档填写该需求条目编号及本次澄清记录版本号，便于后续追溯。
完成检查：记录是否可用的判断标准
澄清记录写完后，用一组可核验的检查项判断它能否作为设计、开发和验收的依据。以下清单建议在同步前逐项过一遍。
- 每条已确认结论都有答复人和确认时间，抽查任意一条能说清依据来源。
- 待定项单独标注，有负责人和截止时间，且未与已确认结论混写。
- 确认范围写明本次澄清覆盖的功能或流程，边界与排除项明确列出不做什么。
- 验收口径具体到可判定的条件，例如时间起点、数量上限、接收对象，而非“及时提醒”一类表述。
- 受影响的已有需求或方案已注明条目编号和影响方式。
- 记录与需求条目或需求文档关联，保留版本号和修改痕迹，补充澄清以新版本记录。
- 记录已同步给提出人、开发和测试等相关角色，关键结论变更有人确认。
检查中发现结论缺少答复人、待定项无人负责或验收口径无法判定时，回到对应问答条目补充确认，再更新记录版本。记录达到上述状态，即可作为需求理解阶段的稳定依据进入后续设计与评审。
常见问题
澄清会上没来得及确认的问题，记录里怎么处理才不影响后续开发？
把这类问题记为“待定”状态，单独列在后续字段中，写清待定原因、拟答复人和约定答复时间，不要为了记录完整而临时给出推测性结论。开发可以依据已确认部分先推进不受影响的工作，涉及待定项的模块在设计说明中标注依赖关系。待定项关闭后，以新版本补充确认结论，并注明本次变更影响了哪些已确认内容，方便开发和测试判断是否需要调整。
澄清记录和需求文档是什么关系，需要各写一份吗？
两者职责不同。需求文档描述需求最终要做什么，澄清记录保留理解形成的过程依据：谁在什么时间对哪个分歧给出了什么答复。实践中可以把澄清记录作为需求条目的关联文档保存，需求文档引用已确认结论，避免同一结论在两处维护出不一致的版本。补充澄清时新增记录版本，需求文档按需同步更新，并保留指向对应澄清版本的引用。
口头澄清或即时沟通得出的结论，也要补记录吗？
只要结论会影响范围、验收口径或实现方式，就值得补一条记录。补记时写明沟通形式（如即时消息、电话）、答复人、时间和关键原话要点，并请答复人确认后标记为已确认。补记的价值在于后续追溯：当开发与业务方对某条规则理解不一致时，记录能说明结论的来源和时间。仅涉及措辞、格式等不影响交付判断的沟通，可以不单独成条。
多人参与澄清时，记录由谁定稿、谁确认？
通常由需求分析人员整理定稿，需求提出方确认业务规则类结论，测试角色确认验收口径类结论，答复人对自己的答复内容负责。参与角色多、待定项多时，建议指定专人跟踪待办关闭和版本更新。定稿后同步给所有参与角色，关键结论发生变更时，由变更提出人说明原因并请原确认人复核，避免结论在传播中被二次改写。
澄清记录需要保留多久，后续需求变更时怎么衔接？
保留期限按团队的需求管理与审计要求确定，通常与需求条目的生命周期一致，需求存续期间记录可查。需求变更时，先判断变更是否触及原澄清结论：触及的，新增澄清记录版本并注明替代了哪条旧结论；未触及的，在原记录上标注变更关联即可。归档时保留版本号和修改痕迹，评审或验收环节从需求条目直接定位到对应澄清版本，追溯链条才完整。
