需求澄清的目标，是把一句模糊诉求转成提出方和研发方都能确认的理解。具体做法分四步：先界定澄清对象与范围，准备一份可逐条追问的问题清单；再组织澄清会议，围绕背景、目标、场景、边界和验收口径逐条确认；会后把结论、分歧和待定项写成澄清记录并完成确认；最后用检查清单判断是否可以交接给需求建模或评审。澄清记录和待确认项可以放在工作项与文档中承载，便于后续跟踪。
要点总览（TL;DR）
- 需求澄清分四步：会前界定范围并准备问题清单，会上逐条追问并当场确认，会后写成澄清记录完成确认，最后用检查清单判断能否交接。
- 问题清单按背景与目标、使用场景、边界与例外、验收口径四个维度组织，每个问题标注提出方和期望回答人，模糊表述标记为待追问项。
- 澄清会上把信息分为事实、假设和待定项三类，能当场确认的当场复述确认，分歧记录双方观点，待定项指定责任人和期限。
- 确认与拍板责任归需求提出方或其授权代表，产品经理负责组织确认并记录结果，研发和测试提供判断依据。
- 澄清完成的判断标准是检查项全部有对应证据：范围、场景、边界、验收口径有结论，待确认项有责任人和期限，确认人已书面确认。
需求澄清先做什么：从模糊诉求到可追问的问题清单
澄清会开得散，多半是准备阶段没做。会前要完成两件事：界定这次澄清的对象和范围，把原始诉求拆成可以逐条追问的问题。输入是原始需求描述、相关业务材料、历史反馈或工单记录；输出是一份问题清单和一份待澄清项列表，由产品经理或需求分析人员准备，需求提出方配合补充背景材料。
界定范围时先回答三个问题：这次澄清针对哪个业务环节或哪类用户；哪些内容属于本次讨论，哪些留到后续；澄清结论将交给谁使用。范围写清楚，会议才不会滑向方案设计或技术实现。原始诉求里常见的“优化一下”“尽快支持”“体验不好”这类表述，要标记为需要追问的模糊点，而不是直接当成结论。
问题清单建议按四个维度组织，每个问题标注提出方和期望回答人：
- 背景与目标：这个诉求由什么业务变化或用户问题引起；希望达成什么可观察的结果；不做的后果是什么。
- 使用场景：谁在什么时间、什么条件下使用；操作前后的完整流程是什么；涉及哪些角色和数据。
- 边界与例外：哪些情况需要处理，哪些明确不处理；异常、权限不足、数据缺失时如何表现；与现有功能如何衔接。
- 验收口径：怎样算满足需求；由谁判断；有没有可量化的指标或可演示的操作路径。
问题清单不必追求数量，重点是每个问题都能引出一个可确认的回答。准备完成后，把无法从材料中得到答案的条目整理成待澄清项，提前发给参会人，让对方带着信息进会。使用 ONES Assistant 的场景中，可以围绕音视频转录、用户反馈和 PRD 材料提炼要点与待澄清问题，作为问题清单的初稿，再由需求负责人核对补充；具体可用范围以实际部署和权限配置为准。
澄清会议怎么开：逐条追问与当场确认的做法
澄清会议的价值在于当场把理解对齐，而不是会后各自猜。参会角色通常包括需求提出方、业务方、产品经理、研发代表和测试代表。需求提出方负责说明背景和期望结果，业务方补充实际使用场景，产品经理主持追问并记录，研发和测试从实现与验证角度提出边界问题。会议时长控制在能逐条走完问题清单的范围内，议题按清单顺序推进。
追问的顺序建议从背景和目标开始，再进入场景，然后讨论边界与例外，最后确认验收口径。每一条追问要追到能落地为止：问到“谁用”之后继续问“在什么情况下用”；问到“要支持”之后继续问“支持到什么程度、什么情况下不处理”。追问深度以研发和测试能判断影响范围、提出方能判断是否符合预期为准，不必在会上展开技术方案。
会上要把信息分成三类并分别标注：事实是已有材料或提出方明确确认的内容；假设是当前理解但尚未验证的判断，需要写明由谁验证；待定项是会上无法确认的问题，要指定责任人和确认期限。三类信息混在一起，后续交接时最容易返工。能当场确认的结论，当场复述一遍请提出方确认；存在分歧的，记录双方观点和分歧点，不强行在会上拍板。
会议结束前留出几分钟做收尾：逐条核对问题清单的覆盖情况，确认哪些已有结论、哪些进入待确认清单、哪些需要补充材料后再议。会议产出是一份结论记录和一份分歧清单，由主持人整理后在约定时间内发出。
澄清结果怎么落地：记录、确认与交接
会议结论只有写成可交接的产物，才算完成澄清。澄清记录建议包含以下字段：澄清对象与范围、原始诉求、逐条问题的结论、假设与验证责任人、待确认项及期限、分歧点、确认人和确认时间。记录要能让没参会的人读懂结论依据，而不是只留一句“已沟通”。
确认方式可以是书面回复、文档确认或工作项状态流转，确认人应是能对需求内容负责的提出方代表；涉及多业务方时，明确主确认人，避免多人意见并列却无人拍板。待确认项在确认前不进入开发排期，确认后再随澄清记录一起交接。
交接边界要写清楚：澄清记录交给需求建模环节，作为结构化描述和方案细化的输入；进入正式需求评审时，评审关注的是需求完整性、可行性和优先级，澄清阶段遗留的待定项应在评审前关闭或明确处理方式。需求发生变更时，按变更影响范围重新走一遍澄清：范围、场景或验收口径任一发生变化，都要更新澄清记录并重新确认，而不是在旧结论上直接改实现。
在 ONES 中，业务需求池、产品需求池与工单可以承载需求条目和状态，澄清记录与待确认项可放在对应工作项的文档或 Wiki 页面中，确认状态随工作项流转，方便业务、产品和研发按同一份信息跟进。这样做的实际作用是让澄清结论有固定位置可查，减少口头结论散落的情况。
角色与交付物分工表
澄清过程中的职责如果只写“共同负责”，容易出现没人准备、没人确认的情况。下表按环节列出各角色的动作与交付物，团队可结合自身规模裁剪。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求提出方 | 说明诉求背景、目标与期望结果；回答场景与验收问题；对澄清结论做最终确认 | 背景材料、确认意见 |
| 业务方 | 补充实际使用场景、用户反馈和业务规则；指出例外情况 | 场景说明、业务规则补充 |
| 产品经理 | 界定澄清范围；准备问题清单；主持会议；整理澄清记录与待确认项；跟踪确认闭环 | 问题清单、澄清记录、待确认清单 |
| 研发代表 | 从实现角度追问边界、数据与衔接条件；评估澄清结论对现有系统的影响 | 边界问题、影响说明 |
| 测试代表 | 追问验收口径与异常场景；确认可验证的判断标准 | 验收问题、验证要点 |
确认与拍板责任归需求提出方或其授权代表，产品经理负责组织确认并记录结果，研发和测试提供判断依据但不替代业务确认。待确认项的责任人按问题归属指定，期限在会议上明确，逾期未确认的条目由产品经理升级给确认人处理。
一个澄清示例：从一句诉求到可确认结论
以下为演示情景，用于说明追问如何推进，不代表真实项目。
原始诉求是一句：“希望订单列表能按客户筛选，方便销售查单。”这句话包含对象、动作和目的，但缺少场景细节和验收口径，直接进入开发容易做出不符合预期的功能。
追问过程可以这样展开：销售在什么场景下需要按客户查单，是接客户电话时查历史订单，还是批量核对某客户的订单状态；筛选结果需要展示哪些字段；一个客户存在多个联系人时按哪个维度匹配；客户名称有重名或简称时如何处理；筛选无结果时页面如何提示；查询响应时间有没有要求。追问后得到的补充信息是：主要场景是客服接听电话时快速定位该客户近一年的订单，需要展示订单号、下单时间、金额和状态，客户按主账号匹配，重名时展示客户编号辅助区分，无结果时提示“未找到该客户的订单”。
澄清后的结论是：在订单列表增加按客户主账号筛选，结果展示四个字段，无结果给出明确提示。仍待确认的项包括：近一年范围是否可配置、历史订单数据是否完整、响应时间指标由谁验证。这三项分别指定了责任人和确认期限，在进入需求建模前关闭。对比澄清前后可以看到，原始诉求只描述了功能方向，澄清后形成了可判断对错的范围、字段和提示规则。
完成检查：澄清到什么程度可以结束
澄清是否做到位，用一份检查清单逐项核对，比凭感觉判断更可靠。以下检查项全部通过，才适合把需求交接给建模或评审。
| 检查项 | 通过标准 | 证据 |
|---|---|---|
| 澄清对象与范围 | 写明了本次澄清覆盖的业务环节和不在范围内的内容 | 澄清记录首段 |
| 背景与目标 | 说明了诉求来源和期望的可观察结果 | 问题清单对应结论 |
| 使用场景 | 主要场景有角色、触发条件和操作流程 | 场景说明或流程描述 |
| 边界与例外 | 明确了不处理的情况和异常表现 | 边界问题结论 |
| 验收口径 | 有可判断是否满足的标准和判断人 | 验收条目 |
| 待确认项 | 每项有责任人和期限，且不影响当前交接判断 | 待确认清单 |
| 确认闭环 | 确认人已书面确认，确认时间可查 | 确认记录或工作项状态 |
未通过的检查项按性质处理：信息缺失的，补充材料后重新组织一次短会；存在分歧的，记录分歧点并升级给确认人决策；待确认项影响范围判断的，暂缓交接，先关闭该项。检查清单本身可以随团队流程调整，关键是每项都有对应证据，而不是只在会上口头说过。
常见问题
澄清会上提出方和研发方对某个场景的理解始终对不上，应该怎么处理？
先把分歧拆细，确认双方说的是不是同一件事：是场景本身不同，还是对同一场景的期望表现不同。如果属于事实层面，补充材料或找实际使用该场景的业务人员核实；如果属于期望层面，把双方观点和依据都写进分歧清单，不在会上强行拍板，由需求提出方或其授权代表决策。分歧未关闭前，相关条目暂缓进入开发排期，避免按某一方理解先做。
待确认项在进入需求评审前还没关闭，可以继续往下走吗？
要看待确认项是否影响范围、场景或验收口径的判断。影响这些内容的，建议先关闭再交接，否则建模和评审会建立在不确定的前提上；只影响实现细节、不影响需求理解的，可以带进评审并注明处理方式和责任人。无论哪种情况，待确认项都要有责任人和期限，逾期未确认的由产品经理升级给确认人处理。
需求上线前发生变更，澄清要全部重做吗？
按变更影响范围决定重做程度。范围、使用场景或验收口径任一发生变化，都要更新澄清记录并重新确认；只涉及文案、字段顺序等不影响需求理解的调整，可在原记录上补充说明。重新澄清时沿用原问题清单，重点核对受影响的条目，不必从头再走一遍全部问题。
团队规模较小，没有独立的业务方和测试代表，角色分工表怎么裁剪？
角色表的作用是让每项职责有明确归属，人数少时可以合并角色，但不能合并掉确认责任。例如产品经理同时承担问题清单准备和会议主持，需求提出方仍然要对结论做最终确认；测试代表缺席时，验收口径的追问由产品经理和研发代表共同完成，并在记录中注明由谁验证。合并后要在澄清记录里写清实际承担人，避免出现“共同负责”却无人确认的情况。
澄清记录放在哪里，才能让业务、产品和研发看到同一份结论？
关键是让记录和需求条目绑定，而不是散落在个人文档或聊天记录里。在 ONES 中，业务需求池、产品需求池与工单可以承载需求条目和状态，澄清记录与待确认项可放在对应工作项的文档或 Wiki 页面中，确认状态随工作项流转，业务、产品和研发按同一份信息跟进。具体字段和模板可按团队流程配置，以实际部署为准。
