AI需求澄清可以按“拆要素、生成追问、人工确认、形成结论”四段推进：先把原始需求拆成目标、用户、场景、输入输出、边界和验收等要素，再让AI按固定问题清单提出追问与歧义点，由需求负责人逐条确认回填，最后整理成带确认记录的需求说明和待验证项。AI负责提问、归纳和一致性检查，判断与拍板仍由人完成。下面给出可直接执行的步骤、字段表、角色分工、示例和完成检查清单。
要点总览（TL;DR）
- AI需求澄清按“拆要素—生成追问—人工确认—形成结论”推进，AI负责提问和归纳，需求负责人负责确认与拍板。
- 用目标、用户、场景、输入输出、边界、验收六个必填字段组织输入，AI的追问才能落到具体判断点，减少空泛提问。
- 提示词要限定AI只提问、不给方案、不自行补全原文没有的信息，并要求标注不确定项和原文依据。
- 澄清完成的判断标准是必填要素无空白、关键歧义已关闭、待验证项有责任人和时限、确认记录可追溯。
- 澄清记录、追问清单和待验证项应与需求条目关联留痕，避免评审和交接时重新讨论。
AI需求澄清的核心流程与关键步骤
一次完整的AI辅助需求澄清通常包含六个步骤。每一步都有明确输入、动作、输出和完成标志，避免澄清停留在“再沟通一下”的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 原始需求收集与预处理 | 需求提出人的口头描述、聊天记录、工单、会议纪要或反馈原文 | 把原始描述整理成一段完整文本，保留原话中的数字、角色和场景词，删除与需求无关的寒暄 | 一份可阅读的原始需求文本 | 需求负责人能复述需求大意，原始文本可追溯到提出人 |
| 2. 用固定要素模板拆解需求 | 原始需求文本、澄清要素表 | 按目标、用户、场景、输入输出、边界、验收逐项填写已知信息，未知项留空并标记 | 一份带空缺标记的要素草表 | 每个要素都有“已知/未知/待确认”状态 |
| 3. 让AI生成追问清单与歧义点 | 要素草表、提示词模板 | 要求AI只提问、不给方案，按要素逐项输出追问，并单独列出歧义点和相互矛盾之处 | 追问清单、歧义清单 | 追问能对应到具体要素，歧义点有原文位置 |
| 4. 人工确认与回填 | 追问清单、需求提出人 | 需求负责人逐条向提出人确认，把答案回填到要素表，无法当场确认的转为待验证项 | 更新后的要素表、确认记录 | 每条追问都有“已确认/待验证/不适用”的结论 |
| 5. 形成澄清结论 | 更新后的要素表、确认记录 | 整理成需求说明，写明目标、范围、边界、验收口径和遗留问题 | 澄清后的需求说明 | 研发和测试能据此判断是否可进入评审 |
| 6. 登记待验证项 | 未关闭的问题 | 为每个待验证项写明责任人、验证方式和时限 | 待验证项清单 | 每项都有责任人和截止时间 |
这六步可以在一到两次澄清会内完成。步骤2和步骤3可以合并进行：需求负责人边填要素表，边把空缺交给AI生成追问。步骤4是耗时最长的一步，建议把AI追问清单提前发给需求提出人，让对方先自行补充，再集中确认。
澄清要素表：让AI问对问题的字段设计
AI能否问出有价值的问题，取决于输入时给了它什么结构。下面这张要素表把需求拆成七个字段，每个字段都配了提问示例和必填判断。字段越具体，AI的追问越少停留在“请补充细节”这类空话上。
| 字段 | 字段说明 | AI提问示例 | 必填判断 |
|---|---|---|---|
| 目标与价值 | 这个需求要解决什么问题，完成后谁受益、如何衡量 | “这个需求希望改善哪个业务结果？现在这个问题造成了什么可观察的影响？” | 必填 |
| 用户与角色 | 谁使用、谁操作、谁审批，各自权限和关注点 | “这个功能涉及哪几类角色？每类角色分别完成什么动作？” | 必填 |
| 使用场景与触发条件 | 在什么时间、什么业务节点、由什么事件触发使用 | “用户在什么情况下会用到这个功能？触发它的前置事件是什么？” | 必填 |
| 输入输出与数据来源 | 功能接收什么数据、产生什么结果、数据从哪里来、流向哪里 | “输入数据由谁提供、以什么格式提供？输出结果展示给谁、用于什么后续动作？” | 必填 |
| 边界与非目标 | 本次明确不做什么，哪些情况不在处理范围内 | “这次明确不覆盖哪些场景或角色？哪些相邻功能不在本次范围内？” | 必填 |
| 验收标准与约束 | 怎样算完成，有哪些时间、合规、性能或依赖限制 | “用什么条件判断这个需求已完成？有没有必须满足的时间点或外部依赖？” | 必填 |
| 优先级与关联需求 | 与其他需求的关系、上线批次和依赖顺序 | “这个需求依赖哪些已有功能或外部系统？它和哪些需求需要一起上线？” | 选填，涉及排期时补填 |
必填字段用于判断需求是否具备进入评审的基本条件；选填字段在涉及排期、跨团队协作时补充。填写时尽量使用提出人的原话，把“提升体验”“优化流程”这类判断转成具体动作或可观察结果，例如“客服在工单详情页可直接看到用户近三次反馈”。
角色分工与各环节交付物
AI澄清中最容易出问题的地方，是把AI的追问直接当成结论，或者没人对确认结果负责。角色分工要明确三件事：谁提供信息、谁组织澄清、谁拍板。
| 角色 | 主要动作 | 参与时点 | 交付物 |
|---|---|---|---|
| 需求提出人 | 提供原始需求背景，回答追问，确认业务口径 | 步骤1、步骤4 | 原始需求描述、确认答复 |
| 需求负责人/产品经理 | 组织澄清、填写要素表、向AI发起追问、逐条确认回填、拍板需求范围 | 全流程 | 要素表、追问清单、澄清后的需求说明 |
| 研发 | 从实现角度指出输入输出、数据来源和依赖中的不清楚之处 | 步骤3之后、步骤5之前 | 技术疑问清单、可行性反馈 |
| 测试 | 检查验收标准是否可验证，补充异常场景 | 步骤5之前 | 验收口径补充、待验证项 |
| AI输出复核人 | 检查AI追问是否脱离原文、是否自行补全信息、是否把方案混入需求 | 步骤3之后 | 复核意见、删除或修正记录 |
复核人通常由需求负责人兼任，也可以在团队内指定一名熟悉业务口径的成员。拍板权归需求负责人：哪些追问必须关闭、哪些可以转为待验证项、需求范围是否收窄，都由其决定。研发和测试的参与时点不宜过早，否则容易在需求目标尚未清楚时进入实现讨论；也不宜过晚，否则验收口径会在开发后期才暴露分歧。
示例：一次AI辅助需求澄清的完整过程
以下为演示情景，用于说明流程如何落地，不代表真实项目数据。
原始需求描述：“客服反馈用户查订单进度要跳好几个页面，希望在工单里直接看到订单状态，最好能自动提醒异常订单。”
AI生成的追问与歧义清单（节选）：
- “直接看到订单状态”展示哪些字段：订单号、当前节点、预计完成时间，还是全部？
- “异常订单”的判定条件是什么：超时未更新、物流停滞，还是用户主动投诉？
- “自动提醒”提醒给谁：客服本人、客服主管，还是触发工单升级？
- 订单数据来自哪个系统，工单页与订单系统之间是否已有可用的数据接口？
- 原文未说明覆盖范围：所有工单类型都展示，还是仅售后类工单？
- “跳好几个页面”是现状描述，需要确认目标是把操作缩短到一步，还是仅减少查询次数。
人工确认后的补充信息：展示字段确定为订单号、当前节点、预计完成时间三项；异常判定先采用“超过承诺时间未更新”一个条件；提醒对象为当前工单的客服处理人；订单数据来自订单中心，已有查询接口；覆盖范围为售后类工单；目标是把查询动作从三次页面跳转缩短为工单详情内一次查看。
澄清后的需求说明与遗留问题：需求说明写明目标、角色、触发条件、展示字段、异常判定条件、数据来源和验收口径——客服在售后工单详情页可看到三项订单信息，超时未更新时出现提醒标识。遗留问题包括：提醒是否需要同时通知主管、异常判定的时间阈值由谁配置，两项均登记为待验证项，责任人为需求负责人，时限为评审前。
提示词与追问清单的组织方式
让AI稳定输出追问的关键，是在提示词中限定它的角色和任务边界。可以直接复用下面的结构：
- 角色设定：“你是需求澄清助手，任务是发现信息缺口并提出问题，不提供解决方案，不评价需求好坏。”
- 任务边界：“只基于我提供的需求原文和要素表提问。原文没有的信息，标注为‘原文未提供’，不要自行补全。”
- 逐项提问结构：“按目标、用户、场景、输入输出、边界、验收六个要素逐项输出：已知信息、缺失信息、需要追问的问题。”
- 不确定项标注：“对存在多种理解的地方，列出可能的理解方式，并说明各自需要确认什么。”
- 禁止直接下结论：“不要给出功能设计方案、优先级建议或实现方式，这些由人工决定。”
- 多轮收敛：“每轮只追问上一轮未关闭的问题；已确认的内容不再重复提问；当剩余问题都需要业务方判断时，停止追问并输出待确认清单。”
追问清单可以按“要素—问题—原文依据—影响”四列组织。原文依据一列要求AI引用需求描述中的具体语句，方便人工核对问题是否成立；影响一列说明该问题不确认会导致什么后果，帮助需求负责人判断确认顺序。多轮追问时，把上一轮的确认结果回填给AI，并要求它只针对未关闭项继续提问，可以避免问题反复和清单膨胀。
常见偏差与质量校验
AI在需求澄清中的输出需要经过校验才能使用。常见偏差集中在四类，每类都有对应的检查动作。
| 偏差 | 表现 | 校验动作 |
|---|---|---|
| 自行补全未提供的信息 | 追问中出现了原文没有的角色、字段或业务规则，并被当作已知条件 | 逐条对照原文，凡原文未出现的具体信息一律标回“待确认”，要求AI重述依据 |
| 追问停留在表层 | 问题多为“请补充细节”“是否还有其他要求”，无法推动确认 | 检查每个问题是否指向具体要素和具体判断点，把笼统问题改写成二选一或填空式问题 |
| 把方案当成需求 | 输出中出现“建议增加按钮”“应该用弹窗提醒”等实现描述 | 区分需求描述与方案描述，方案内容移入待讨论区，需求说明只保留目标和约束 |
| 确认记录缺失 | 追问有了答案，但没有记录谁确认、何时确认、依据是什么 | 每条确认结论附提出人、确认时间和原话摘要，未记录的视为未确认 |
校验可以由需求负责人完成，也可以安排一次短会集中复核。复核时重点看三处：AI输出中每个具体信息能否在原文找到出处；每条追问是否对应一个可判断的确认动作；确认记录是否足以让未参与澄清的人理解结论来源。发现偏差时修正记录，不直接删除，保留修正痕迹有助于后续追溯。
完成检查：澄清到什么程度可以进入下一步
澄清是否完成，可以用下面的清单逐项判断。全部通过即可进入需求评审或排期；出现阻断项时，先关闭阻断项再推进。
- 要素完整度：目标、用户、场景、输入输出、边界、验收六个必填字段均已填写，没有空白项。
- 关键歧义关闭：AI列出的歧义点中，影响范围、角色和验收口径的部分已全部确认；其余歧义已转为待验证项并说明原因。
- 待验证项有主有时限：每个待验证项都有责任人、验证方式和截止时间，且截止时间不晚于评审或开发启动节点。
- 确认记录可追溯：每条关键结论都能找到确认人、确认时间和原始答复。
- 验收口径可验证：测试能根据验收标准写出至少一条可执行的验证条件。
- 边界清晰：非目标已写明，研发能判断哪些内容不在本次范围内。
阻断条件包括：目标或验收标准缺失；核心角色的使用场景未确认；输入数据来源不明且无责任人跟进；待验证项没有时限。出现任一阻断条件时，需求不进入评审，由需求负责人组织补充澄清。
把澄清过程沉淀到协作工具中
澄清结论如果只停留在聊天记录或个人文档里，评审和交接时容易重新讨论。把澄清记录与需求条目关联起来，可以让追问、确认和待验证项跟着需求走。具体做法是：在需求条目下附上要素表、AI追问清单和确认记录，把待验证项登记为独立工作项并关联原需求，评审时直接引用这些记录作为讨论依据。
ONES 的需求与工作项管理可以承载这一过程：澄清后的需求说明、追问记录和待验证项可以关联到同一需求条目，待验证项作为工作项跟踪责任人和时限，评审与交接通过状态流转留下记录。ONES Assistant 可围绕会议、反馈和文档等输入提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入；其输出基于项目、工作项和 Wiki 页面等工作上下文，结果仍需人工确认。对于已经在 ONES 中管理需求的团队，可以把AI生成的追问清单和人工回填结果一并留在需求条目下，使澄清过程可追溯，并与后续评审、开发和测试衔接。
常见问题
需求提出人无法参加澄清会，AI追问清单还能用吗？
可以用，但需要调整确认方式。把AI追问清单提前发给需求提出人，请其以文字形式逐条答复，并注明答复时间和原话摘要；无法文字确认的问题转为待验证项，写明责任人和补充确认的时限。需求负责人可以依据已有答复先推进要素表填写，但涉及范围收窄、验收口径变化的关键结论，仍应由提出人明确确认后再定稿。
AI生成的追问清单很长，如何判断哪些必须先确认？
按影响面排序：先处理影响需求范围、核心角色和验收口径的问题，再处理展示细节和交互方式。可以在追问清单中增加“影响”一列，说明该问题不确认会导致什么后果，例如范围无法收窄、测试无法写验证条件。影响范围或验收的问题必须在评审前关闭，其余可以转为待验证项并设定时限。
多轮追问后AI开始重复提问或自行发挥，怎么收敛？
每轮把已确认的结论回填给AI，明确要求只针对未关闭项继续提问，已确认内容不再重复。同时在提示词中重申任务边界：只基于提供的原文和要素表提问，原文没有的信息标注为未提供。当剩余问题都需要业务方判断时，停止追问，输出待确认清单交由人工处理。
澄清记录放在聊天记录里可以吗？
聊天记录可以作为原始素材，但不适合作为唯一载体。评审和交接时，参与人需要快速找到某条结论的确认人、确认时间和依据。更稳妥的做法是把要素表、追问清单和确认记录附在需求条目下，待验证项登记为独立工作项并关联原需求。使用 ONES 的团队可以把这些内容留在需求条目中，通过状态流转记录评审与交接过程。
需求很小，也需要走完整的六步流程吗？
可以按比例裁剪。小需求可以合并步骤2和步骤3，边填要素表边让AI生成追问；步骤6的待验证项如果为空，可以省略。但目标、用户、场景、边界和验收这几个必填要素仍需填写，确认记录也要保留，否则后续排期或测试阶段仍会因口径不清返工。
