AI需求分析要得出可用结论，前提是先把依据准备齐。通常需要五类材料：业务目标与范围说明、原始需求来源、领域知识与规则约束、历史需求与缺陷记录、明确的判定标准。把这些材料整理成结构化的“需求依据包”，再交给AI做提取、归类和一致性检查，输出可评审的需求条目与待澄清问题清单，由需求负责人确认后才进入正式需求文档。ONES可用于留存依据包、需求条目和评审记录，让整个过程有据可查。
要点总览（TL;DR）
- AI需求分析的依据由五类材料构成：业务目标与范围说明、原始需求来源、领域知识与规则约束、历史需求与缺陷记录、判定标准。
- 把五类材料按统一字段整理成需求依据包，标注来源、负责人和完整度状态，再交给AI处理。
- 执行流程分四步：清洗与结构化、AI提取与归类、AI生成待澄清问题、人工评审确认，AI输出不直接进入正式文档。
- 需求负责人对最终条目负责，业务方提供原始素材，领域专家提供边界条件，AI使用者负责提示词与来源标注。
- 完成前核对依据完整性、来源可追溯、问题闭环和评审留痕；关键依据缺失或来源不可追溯应作为阻断项。
先备齐五类依据：AI需求分析的输入清单
AI对需求的理解质量，取决于输入材料的覆盖面和可追溯性。材料不齐时，模型容易用通用常识填补空白，产出看似完整却无法落地的条目。以下五类依据分别回答不同问题，缺哪一类，对应环节的判断就会失去支撑。
| 材料类别 | 回答的问题 | 典型来源 | 最低完整度 |
|---|---|---|---|
| 业务目标与范围说明 | 为什么做、做到哪、明确不做什么 | 立项材料、项目章程、季度目标文档 | 有一页以内的目标与范围描述，含明确的排除项 |
| 原始需求来源 | 用户和业务方实际提出了什么 | 访谈记录、工单、用户反馈、竞品分析、现有需求文档 | 关键角色至少各有一份原始记录，保留原话 |
| 领域知识与约束 | 哪些规则不能违反、系统边界在哪 | 术语表、业务规则说明、合规要求、架构约束文档 | 核心术语有定义，硬性约束有书面出处 |
| 历史需求与缺陷记录 | 过去怎么表述、哪些问题反复出现 | 需求库、缺陷库、上线复盘记录 | 近一到两个版本的相关记录可检索 |
| 判定标准 | 什么算做完、先做哪个、谁拍板 | 验收口径、优先级规则、评审责任人名单 | 验收口径可检验，评审责任人明确到人 |
业务目标与范围说明是约束AI发挥方向的锚点。范围说明中的“不做什么”尤其重要，它能防止AI把相邻场景的需求一并纳入，导致范围蔓延。原始需求来源要保留原话而非二手转述，访谈记录、工单描述、用户反馈原文都是AI提取需求条目的直接素材。领域知识与约束决定AI提出的需求是否合规、是否符合既有系统边界，术语表则保证同一概念在全文中表述一致。
历史需求与缺陷记录有两个用途：复用经过评审的规范表述，以及识别重复需求。判定标准是容易被忽略的一类依据，它让AI在归类时能按优先级规则排序，也让人工评审时有统一口径可依。五类材料不必一次备齐到完美状态，但每类至少要达到表中的最低完整度，否则应在依据包中标注缺口，而不是让AI自行补全。
把上述材料按统一字段整理，就形成需求依据包。字段表建议包含：材料名称、所属类别、来源位置、提供负责人、完整度状态（齐备/部分/缺失）、备注。这张表本身就是后续评审的输入，也是判断本轮分析能否启动的依据。
按四步执行：从依据包到可评审需求条目
依据包准备好后，按清洗、提取、补问、评审四步推进。每一步都有明确的输入、动作、输出和完成标志，避免AI输出直接进入正式文档。
第一步：清洗与结构化原始材料
输入是依据包中的全部原始材料。动作包括：统一术语（以术语表为准替换同义表述）、给每份材料编号（如访谈-01、工单-07）、剔除与本次范围无关的内容、把口语化记录整理成可读段落但保留原意。输出是一份编号清晰、术语一致的素材集。完成标志是：每条素材都能通过编号定位到来源，术语表中出现的概念在素材中表述统一。
第二步：让AI做需求提取与归类
输入是清洗后的素材集和业务目标与范围说明。动作是要求AI按功能需求、非功能需求、约束条件、待确认事项四类提取条目，每条注明来源编号和原文摘录。归类时参照优先级规则给出初步排序建议。输出是带来源标注的需求条目初稿。完成标志是：每条条目都能回溯到至少一个素材编号，没有来源的条目单独列出而非混入正文。
第三步：让AI生成待澄清问题与冲突点
输入是需求条目初稿和领域约束材料。动作是要求AI识别三类问题：素材之间相互矛盾的表述、信息不足以判断的空白点、与既有规则或系统边界冲突的条目。输出是待澄清问题清单，每个问题注明涉及的需求条目、冲突或缺失的具体内容、建议的澄清对象。完成标志是：每个问题都能指向具体的条目和素材，问题清单经过初筛后没有明显重复。这一步的定位是暴露不确定性，AI在此阶段不给出最终结论。
第四步：人工评审确认
输入是需求条目初稿和待澄清问题清单。动作是由需求负责人主持评审，逐条确认需求条目是否成立、优先级是否合理、待澄清问题由谁在什么时间前答复。输出是确认后的需求条目和遗留问题清单（含责任人和期限）。完成标志是：评审记录留痕，确认的条目进入正式需求文档，未闭环的问题明确挂起而非默认通过。
角色与交付物：谁提供依据、谁确认结果
AI输出无人负责是需求分析中最常见的失效方式。明确每个角色在依据准备和结果确认中的职责，才能让AI产出真正进入研发流程。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求负责人 | 组织依据包、主持评审、对最终需求条目负责 | 需求依据包、评审记录、确认后的需求条目 |
| 业务方与用户代表 | 提供业务目标、使用场景和原始反馈材料 | 目标与范围说明、访谈记录、用户反馈原文 |
| 领域专家/架构与合规角色 | 提供业务规则、合规边界和系统约束 | 术语表、规则说明、约束文档 |
| AI使用者（需求分析执行人） | 编写提示词、维护来源标注、对AI输出做初筛 | 清洗后的素材集、需求条目初稿、待澄清问题清单 |
需求负责人是整个流程的责任主体，依据包的组织、评审的主持、最终条目的确认都由其承担。业务方与用户代表提供的是原始素材，其价值在于保留真实表达，而非提前加工成需求条目。领域专家和架构、合规角色提供的是边界条件，他们的输入决定AI提出的需求是否可执行。AI使用者负责操作层面的质量，包括提示词设计是否覆盖了提取、归类、补问三类任务，来源标注是否完整，初筛是否剔除了明显偏离范围的输出。
交付物清单贯穿全程：需求依据包是输入，需求条目和待澄清问题清单是中间产物，评审记录是确认凭证。四类交付物都应在同一处留存并相互关联，便于后续追溯某条需求来自哪份材料、经过谁确认。在ONES中，可以把依据包作为文档挂到需求工作项下，需求条目以待评审状态流转，评审记录随工作项留痕，使材料、条目和确认动作保持在同一上下文里。
一个完整示例：会员积分需求如何走完依据到条目
以下为演示情景，用于说明依据包如何支撑AI提取与人工确认，不涉及真实企业数据。
背景：某电商平台计划改造会员积分体系，需求负责人组织了一轮AI辅助需求分析。依据包内容包括：目标与范围说明（提升复购，本期只做积分获取与消耗，不做等级体系）、三份用户访谈记录、两份客服工单、积分业务规则文档、上一版本积分相关需求与缺陷记录、验收口径与优先级规则。
AI提取出的需求条目示例：
- 会员完成订单支付后按实付金额比例获得积分（来源：访谈-02、规则文档第3节）。
- 积分可在结算时抵扣现金，抵扣比例受上限约束（来源：访谈-01、工单-05）。
- 退款时按退款金额扣减对应积分（来源：缺陷记录-03，历史曾出现扣减错误）。
AI提出的待澄清问题示例：积分有效期如何设定，现有规则文档未明确；退换货场景中部分退款与整单退款的扣减规则是否一致；积分抵扣与优惠券叠加时的计算顺序。每个问题都标注了涉及条目和建议澄清对象（业务方或财务）。
人工评审后确认：前两条需求条目成立并进入正式文档；退款扣减条目因规则细节待定，标记为挂起，由业务方在一周内答复；积分有效期问题转交业务方确认后补充。评审记录中保留了确认人、确认时间和遗留项责任人。整个过程从依据包到确认条目，AI承担了提取和暴露问题的角色，最终判断由人做出。
完成检查：依据是否够用、结果是否可信
一轮AI需求分析结束前，用以下清单逐项核对。检查的目的是确认依据充分、来源可追溯、结论有人负责，而非追求材料完美。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 五类依据是否齐备 | 每类至少达到最低完整度，缺口已在依据包中标注 | 补齐关键材料或明确标注缺口对结论的影响 |
| 来源是否可追溯 | 每条需求条目都能定位到素材编号和原文 | 无来源条目单独列出，不混入确认清单 |
| 待澄清问题是否闭环 | 每个问题有答复结论或明确挂起并指定责任人 | 未闭环问题不得默认通过 |
| 评审是否留痕 | 需求负责人确认，记录含确认人和时间 | 补充评审后再进入正式文档 |
以下情况应作为阻断项，暂停进入正式需求文档：关键依据缺失（如业务目标或合规约束没有书面材料）、需求条目来源不可追溯、评审未由需求负责人确认。阻断项解决后再继续，避免把不确定性带入研发阶段。检查通过后，需求条目、待澄清问题清单和评审记录一并归档，作为下一轮分析的参考依据。
常见问题
原始需求材料只有口头转述、没有访谈记录，还能启动AI需求分析吗？
可以启动，但需要先补一份可追溯的原始记录。口头转述在传递中会丢失原意，AI提取时缺少原文比对，容易把转述者的理解当成用户诉求。可行的做法是让参与沟通的人补写要点记录，注明时间、参与人和关键原话，再作为素材编号纳入依据包。如果确实无法补齐，应在依据包中标注该来源为“部分完整”，并在评审时对相关条目提高确认要求。
AI提取出的需求条目和人工整理的结果不一致时，以哪个为准？
以人工评审确认的结果为准，但两者不一致的地方值得保留下来分析。AI条目与人工判断出现差异，通常指向三种情况：素材本身表述矛盾、术语理解不一致、或AI把相邻范围的内容纳入了进来。评审时逐条对照来源编号，能定位到具体原因。差异记录可以作为下一轮清洗素材和改进提示词的依据，而不是简单丢弃AI输出。
待澄清问题一直没人答复，是否可以先让需求进入开发？
不建议默认通过。待澄清问题通常涉及规则细节或边界条件，带着未决问题进入开发，往往在实现阶段才暴露冲突，返工成本更高。可行的处理是明确挂起：指定责任人和答复期限，在需求条目上标注未闭环状态，开发可以先行处理不受影响的部分。完成检查清单中，未闭环问题不得默认通过，这一条应在评审记录中体现。
五类依据中哪一类最容易被忽略，影响又最大？
判定标准最容易被忽略。业务目标、访谈记录、规则文档通常有人主动提供，而验收口径、优先级规则和评审责任人往往默认存在于某个人脑中。缺少这类依据时，AI归类只能凭通用常识排序，人工评审也缺少统一口径，容易出现条目都成立但先后顺序争议不断的情况。建议在依据包字段表中把判定标准单列，明确到具体文档或具体人。
小团队人手有限，能否简化依据包和评审流程？
可以按比例简化，但几个关键环节建议保留。依据包字段表可以精简为材料名称、来源、负责人三项，完整度状态用简单标记即可。评审可以合并为一次短会，但需求负责人的确认和记录仍需留痕，来源标注也不能省。人手紧张时，优先保证业务目标与范围说明、判定标准这两类依据的质量，它们对AI输出方向的约束作用最直接。
