AI需求澄清是把原始诉求转成可评审、可执行需求说明的一套动作：收集原始诉求与背景，用AI生成澄清问题清单和结构化需求草稿，由需求负责人组织业务方与研发方逐条确认，最终形成带验收口径的需求条目和待办问题清单。AI承担提问、归纳和补全字段，人负责判断优先级、确认边界和定稿。下面按步骤、问题清单设计、角色分工、完整示例和完成检查五部分展开，给出可直接照做的操作流程。
要点总览（TL;DR）
- AI需求澄清分五步推进：收集原始诉求与背景、AI生成澄清问题清单、整理结构化需求草稿、人工确认定稿、按检查清单判断能否进入评审。
- 澄清问题按目标、用户、范围、规则、数据、异常、验收七个角度组织，用字段表记录提问对象、优先级、答复和状态，高优先级问题以是否阻塞评审为判断标准。
- 需求提出方提供事实，需求负责人组织判断并定稿，研发与测试提出可实现与可验证的质疑，AI输出一律作为初稿，推断内容单独标注后由人确认。
- 澄清收口的判断标准是：影响范围、核心规则和验收口径的问题全部关闭，剩余问题不影响研发评估工作量和测试设计验收用例。
AI需求澄清的核心步骤与输入输出
整个澄清过程可以拆成五步，每一步都有明确的输入、动作、输出和完成标志。按顺序推进，避免在信息不全时过早进入方案讨论。AI在第二、三步承担主要工作量，第一、四步以人为主，第五步是人工判断的收口动作。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集原始诉求与背景 | 业务方口述、会议记录、用户反馈、现有文档 | 记录原始表述，补齐提出人、使用场景、期望结果、时间约束 | 一份原始需求记录，含背景与来源 | 能说清“谁在什么场景下遇到什么问题、希望达到什么结果” |
| 2. AI生成澄清问题清单 | 原始需求记录、相关业务资料 | 按目标、用户、范围、规则、数据、异常、验收七个角度让AI批量提问，人工筛选保留高价值问题 | 澄清问题清单，标注优先级和提问对象 | 每个待确认点都有对应问题，且能指到具体责任人 |
| 3. 结构化需求草稿整理 | 问题清单、业务方初步答复 | 让AI把答复归纳成结构化草稿：需求描述、范围边界、业务规则、数据要求、异常处理、验收口径 | 结构化需求草稿，空缺字段明确标出 | 草稿字段完整，空缺项有明确标注而非留白 |
| 4. 人工确认与定稿 | 结构化草稿、问题清单 | 需求负责人组织业务方与研发方逐条过问题，确认边界、优先级和验收口径，记录未决事项 | 定稿需求条目、待办问题清单 | 业务方与研发方对范围与验收口径无异议，未决事项有责任人和时间 |
| 5. 进入评审准备 | 定稿需求条目、待办问题清单 | 按完成检查清单逐项核对，判断是否具备评审条件 | 可提交评审的需求包 | 检查清单全部通过，或剩余项已明确不影响评审 |
第一步容易被跳过。很多团队拿到一句“要做一个导出功能”就直接让AI生成方案，结果问题清单里全是技术选型，真正该问的“导出哪些字段、给谁用、多大数据量、失败怎么办”反而缺失。原始诉求记录的价值在于给AI提供提问的锚点，背景越具体，生成的问题越贴近业务。
第三步的草稿整理要保留AI的归纳痕迹。让AI把每条结论对应到具体答复来源，人工确认时能快速判断哪条是业务方原话、哪条是AI推断。推断内容单独标注，确认环节重点核对，避免把AI的合理猜测当成既定事实写进需求。
澄清问题清单怎么设计：字段与提问角度
问题清单的质量决定澄清效率。按七个角度组织提问，能覆盖大多数需求的关键盲区；每个问题配上字段结构，方便分派、跟踪和回收答案。
七个提问角度
- 目标：这个需求解决什么问题，成功时业务指标或用户行为有什么变化。
- 用户：谁使用、谁受益、谁审批，不同角色的操作权限差异。
- 范围：本期做什么、明确不做什么，与现有功能的边界在哪里。
- 规则：业务判断逻辑、状态流转、优先级规则、计算口径。
- 数据：涉及哪些数据对象、字段、来源系统，数据量和更新频率。
- 异常：输入缺失、超时、并发冲突、权限不足时系统如何表现。
- 验收：用什么场景、什么数据、什么结果判定通过。
问题清单字段表
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 问题编号 | 唯一编号，便于引用和跟踪 | Q-012 |
| 提问角度 | 七类之一 | 异常 |
| 问题描述 | 一句话问清一个点，避免复合问题 | 导出数据量超过十万行时，是分页下载还是异步生成文件？ |
| 提问对象 | 具体角色或姓名 | 业务运营负责人 |
| 优先级 | 高/中/低，高为阻塞评审的问题 | 高 |
| 答复 | 记录原话或结论，注明答复人 | 异步生成，完成后站内通知 |
| 状态 | 待提问/已答复/待确认/已关闭 | 已答复 |
| 关联需求条目 | 对应到需求草稿的哪个字段 | 异常处理-大数据量导出 |
AI提示词的组织方式
让AI生成问题清单时，提示词里至少交代四件事：原始需求原文、已知背景、提问角度清单、输出格式要求。可以这样组织：“以下是业务方提出的原始需求和相关背景……请按目标、用户、范围、规则、数据、异常、验收七个角度，各生成3到5个澄清问题，每个问题标注提问对象建议和优先级，输出为表格。”背景信息越具体，问题越少停留在泛泛而问。
生成后不要直接采用。人工做两件事：合并重复问题，删掉当前阶段不需要回答的问题。优先级排序按“是否阻塞评审”判断，影响范围、验收口径和核心规则的问题排高，界面细节、文案措辞排低。高优先级问题在确认会上逐条过，低优先级问题可以书面回复或留到设计阶段。
角色分工与各环节交付物
澄清不是一个人的工作。需求提出方提供事实，需求负责人组织判断，研发与测试从可实现和可验证角度提出质疑，AI工具使用者负责把输入整理成结构化材料。四类角色各管一段，交接点清晰，澄清才不会变成反复追问。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求提出方（业务方） | 说明原始诉求、使用场景、业务规则和期望结果；回答澄清问题；确认范围与优先级 | 原始需求记录、问题答复、范围确认意见 |
| 需求负责人（产品角色） | 组织澄清会议；筛选和分派问题；判断优先级与边界；定稿需求条目 | 澄清问题清单、结构化需求草稿、定稿需求条目、待办问题清单 |
| 研发角色 | 从实现角度提出约束和风险；评估技术可行性；确认异常处理和数据要求 | 技术约束说明、可行性意见、异常场景补充 |
| 测试角色 | 检查验收口径是否可测；补充边界和异常用例；确认验收数据准备方式 | 验收口径意见、测试场景清单 |
| AI工具使用者 | 整理输入材料；运行AI生成问题清单和草稿；标注AI推断内容；维护问题状态 | AI生成的问题清单初稿、结构化草稿、推断标注记录 |
AI工具使用者的操作边界需要提前约定：AI输出一律作为初稿，不直接进入需求库；AI推断的内容单独标注，由需求负责人确认后才能写入定稿；涉及权限、数据范围和安全规则的问题，由对应责任人答复，不由AI代答。这样既发挥AI批量提问和归纳的效率，又保证每条结论有人负责。
澄清后的需求条目、待澄清问题和拆解建议需要有地方承载和跟踪。ONES Assistant 可围绕会议记录、用户反馈和文档提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入；它连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等工作上下文，把自然语言指令转化为可追踪的工作。澄清会上确认的需求条目和遗留问题，可以在同一套权限体系下记录状态、指派责任人和跟踪关闭情况，输出过程可追踪、结果可审计。
示例：一条模糊需求如何澄清到可评审
以下为演示情景，用于说明流程如何落地，不作为真实客户案例。
原始需求描述
业务方在需求收集表中填写：“希望订单列表能批量导出，方便运营做月度分析。”提出人：运营主管；期望上线时间：下个迭代。除此之外没有更多信息。
AI生成的澄清问题（节选）
- 目标：月度分析具体看哪些指标，导出后由谁使用、用于什么决策？
- 用户：哪些角色可以导出，是否需要按数据权限过滤可见订单？
- 范围：导出当前筛选结果还是全部订单，是否包含历史归档数据？
- 规则：导出字段固定还是可选，金额、时间字段的格式和口径是什么？
- 数据：单次导出最大数据量是多少，预计每月导出频次？
- 异常：数据量过大时如何提示，导出失败是否重试，文件保留多久？
- 验收：用什么数据量和字段组合验证导出结果正确？
确认后的需求条目
需求描述：运营角色在订单列表按筛选条件批量导出订单数据，用于月度经营分析。范围：导出当前筛选结果，包含近24个月订单，不含已删除订单。权限：按角色数据权限过滤，运营主管可导出全部，运营专员仅导出本人负责的订单。字段：订单号、下单时间、客户名称、商品明细、实付金额、订单状态，金额保留两位小数，时间为北京时间。数据量：单次上限五万行，超过时提示缩小筛选范围。异常：导出任务异步执行，完成后站内通知；失败可重新发起；生成文件保留七天。验收：以三万行测试数据验证字段完整、金额与源数据一致、权限过滤正确、超限提示准确。
验收口径与遗留问题
验收口径已写入需求条目，测试角色补充了权限过滤和超限提示两个边界场景。遗留问题两项：导出文件是否需要支持定时自动生成，由业务方在下个迭代前答复；历史归档数据是否纳入导出范围，待数据负责人确认归档表结构后关闭。两项均指定了责任人和答复时间，不阻塞本次评审。
完成检查：澄清到什么程度可以进入评审
澄清不足会让评审变成新一轮提问，过度澄清会拖慢交付节奏。用下面这份清单逐项核对，全部通过即可提交评审；未通过项判断是否阻塞，阻塞项必须关闭，非阻塞项带入评审作为待办跟踪。
| 检查项 | 通过标准 | 常见不通过表现 |
|---|---|---|
| 必填字段齐全 | 需求描述、目标、用户、范围、规则、数据、验收均有内容 | 范围写“相关功能”，规则写“按业务逻辑处理” |
| 边界明确 | 明确写出本期不做什么，与现有功能的交界清楚 | 只写做什么，未说明与已有模块的重叠部分 |
| 异常有处理 | 输入缺失、超限、权限不足、失败重试等场景有结论 | 异常场景标注“待定”且无责任人 |
| 验收可测 | 有具体场景、数据条件和预期结果，测试角色认可 | 验收写“功能正常”“体验良好” |
| 遗留问题可跟踪 | 每项有责任人、答复时间和是否阻塞评审的判断 | 遗留问题只列内容，无人认领 |
| 结论有出处 | 关键规则能对应到业务方答复或确认记录 | AI推断内容未标注，直接写入定稿 |
停止澄清的时机按阻塞性判断：影响范围、核心规则、验收口径的问题必须关闭；界面细节、文案措辞、非本期范围的优化点可以带入评审或留到设计阶段。当剩余问题都不影响研发评估工作量和测试设计验收用例时，澄清即可收口。把这份检查结果和需求条目一起提交评审，评审会上讨论的是方案取舍，而不是重复确认需求本身。
常见问题
团队没有专职产品经理，AI需求澄清的流程可以简化吗？
可以按角色合并，但不能跳过确认环节。小团队里需求负责人常由研发骨干或业务负责人兼任，此时把“组织澄清会议”和“定稿需求条目”两项动作保留在一个人身上即可，问题清单的筛选和优先级判断仍要有人明确负责。AI生成的草稿和推断标注照常保留，定稿前由业务方对范围与验收口径做一次书面确认，避免后续因理解差异返工。
AI生成的澄清问题很多，如何判断哪些必须在上会前关闭？
按是否影响研发评估工作量和测试设计验收用例来判断。影响范围边界、核心业务规则、数据口径和验收标准的问题属于阻塞项，必须在确认会上逐条过；界面细节、文案措辞、非本期范围的优化点可以书面回复或带入评审作为待办。问题数量多时，先合并重复项，再按提问角度归类，同一角度下保留最贴近业务场景的那几条。
澄清过程中业务方迟迟不答复，需求还能进入评审吗？
取决于未答复问题是否阻塞。阻塞项未关闭时，带着明确标注的待确认问题进入评审，评审结论应限定为“有条件通过”，并写明责任人和答复时间，避免研发按假设开始排期。非阻塞项可以带入评审跟踪。若业务方长期不答复，需求负责人需要把问题升级到能拍板的层级，而不是让AI或研发代为假设。
澄清后的需求条目和遗留问题放在哪里跟踪比较合适？
关键是让需求条目、待澄清问题和责任人状态在同一处可见，避免散落在聊天记录和文档里。ONES Assistant 可围绕会议记录、用户反馈和文档提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入；它连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等工作上下文。澄清会上确认的条目和遗留问题可以在同一套权限体系下记录状态、指派责任人和跟踪关闭情况，输出过程可追踪、结果可审计。
AI在澄清中给出的推断内容，怎样避免被当成业务方结论？
在草稿阶段就做区分：业务方原话或书面答复标注来源，AI归纳和推断的内容单独标记，确认会上重点核对推断部分。定稿时只保留经责任人确认的结论，推断内容要么转为确认结论，要么进入遗留问题清单。这样需求条目里的每条关键规则都能对应到具体答复记录，评审时不必再回头追问依据。
