AI需求提取是把访谈记录、会议纪要、工单、邮件等原始材料，按固定字段抽取成结构化需求条目，再由人核对、补全、确认的过程。它的产出是一份可回溯、可评审的需求清单。本文给出需求条目字段表、五步操作流程、角色分工、填写示例和交付前检查清单，帮助你把零散材料整理成团队能直接评审的需求条目。
要点总览（TL;DR）
- 先定需求条目字段表，把字段名、填写口径、必填标记和状态取值写进抽取提示，让AI每次输出同一套结构。
- 按主题或来源分批投喂材料，单批控制在一份访谈或一个议题的规模，先小批试跑再批量处理。
- 抽取结果逐条回溯原文核对，原文没有依据的字段填“未提及”，不靠推断补齐。
- 合并重复条目并标注冲突与缺口，每条待确认项写明确认对象和确认内容。
- 提交评审前按可回溯性、字段完整性、口径一致性、重复与冲突、待确认项责任、状态与评审安排逐项检查。
先定字段：AI要提取出什么样的需求条目
抽取质量首先取决于字段设计。字段定得清楚，AI每次输出同一套结构，后续核对、合并和评审才有共同口径。字段太少，需求只剩一句话，评审时无法判断背景和优先级；字段太多，材料里往往没有对应信息，反而制造大量空白和猜测。建议先采用下表的最小字段集，跑通一轮后再按业务需要增补。
| 字段 | 说明与填写口径 | 必填 |
|---|---|---|
| 需求编号 | 按统一规则生成，如“REQ-模块缩写-序号”，全清单唯一，便于引用和追踪 | 是 |
| 需求描述 | 用“谁在什么场景下需要什么能力、达到什么结果”写清一条需求，一条只讲一件事 | 是 |
| 来源 | 原始材料名称、位置（页码、时间点、段落）和材料日期，用于回溯核对 | 是 |
| 提出人/角色 | 材料中明确出现的提出人或其岗位角色；材料未写明时留空并记入待确认项 | 是 |
| 业务场景 | 需求发生的业务流程、使用环节和触发条件，用于判断需求边界 | 是 |
| 优先级 | 按团队既有分级填写；材料未提及的，标注“待定”而非自行推断 | 否 |
| 状态 | 统一取值，如“待核对、已核对、待确认、已确认、已纳入评审” | 是 |
| 待确认项 | 列出材料中缺失、模糊或相互矛盾的信息，每条写明需要谁确认什么 | 否 |
字段表同时是给AI的输出约束。把字段名、填写口径、必填标记和状态取值写进抽取提示，并要求以固定格式逐条输出；材料中没有依据的字段填“未提及”，不允许推测补全。这样抽取结果可以直接进入核对环节，减少格式返工。
操作步骤：从原始材料到需求清单的五步流程
整个流程按“先圈范围、再抽取、逐条核对、合并标注、确认送审”推进。每一步都有明确输入、动作、输出和完成标志，任何一步未达到完成标志，不进入下一步。
第一步：圈定材料范围与分批策略
输入是手头全部原始材料，包括访谈录音及转录稿、会议纪要、工单、邮件、问卷反馈等。动作是先列出材料清单，标注每份材料的主题、时间、涉及的业务方，剔除与本次需求范围无关的材料；再按主题或来源分批，单批材料控制在一份访谈或一个议题的规模，避免一次投喂过多导致抽取结果混杂。输出是材料清单和分批计划。完成标志是每份材料都有归属批次，且批次边界与需求范围一致。
第二步：设定抽取提示与输出格式
输入是字段表和第一批材料。动作是把字段定义、填写口径、状态取值、输出格式写入提示，明确要求逐条输出、保留原文位置、缺失信息填“未提及”。先抽取一小批试跑，检查输出结构是否符合字段表，再批量处理其余批次。输出是每批材料对应的结构化抽取初稿。完成标志是初稿字段齐全、格式统一，且每条都带有来源位置。
第三步：逐条回溯原文核对
输入是抽取初稿和对应原文。动作是逐条打开来源位置，核对需求描述是否忠实于原文、提出人和场景是否准确、有无AI补充了原文没有的内容。发现偏差就修正描述或降级为待确认项，发现漏项就补抽。输出是核对后的需求条目和核对记录。完成标志是每条需求都能在原文中找到对应依据，无法回溯的条目已删除或转为待确认。
第四步：合并重复、标注冲突与缺口
输入是核对后的条目集合。动作是按业务场景和需求对象归并重复条目，保留信息最完整的一条并注明其他来源；对不同材料中相互矛盾的说法，在原条目上标注冲突双方及各自出处；对信息缺失的条目，写入待确认项并指定确认对象。输出是去重后的需求清单和冲突、缺口清单。完成标志是清单内无重复条目，每条冲突和缺口都有明确记录。
第五步：确认状态并提交评审
输入是去重后的清单。动作是按状态取值更新每条需求的状态，把已核对且无待确认项的条目标为已确认，其余保持待确认并落实确认人；整理评审材料，说明清单范围、来源批次和遗留问题。输出是带状态和负责人的需求清单及评审安排。完成标志是清单状态完整、待确认项均有责任人、评审时间和参与人已确定。
角色与交付物：谁提供材料、谁核对、谁拍板
AI承担的是按字段抽取和初步归并，判断需求是否成立、优先级如何、是否纳入范围，仍由人完成。角色分工不清时，最常见的问题是抽取结果无人核对就直接进入评审。下表给出各角色的职责与交接物。
| 角色 | 主要职责 | 交接交付物 |
|---|---|---|
| 业务方/需求提出人 | 提供访谈、工单、反馈等原始材料，确认需求描述是否符合本意，回答待确认项 | 原始材料、需求确认意见 |
| 需求分析人员 | 设计字段与抽取提示，执行分批抽取，逐条回溯核对，合并去重并标注冲突与缺口 | 抽取初稿、核对记录、去重后的需求清单 |
| 产品负责人 | 判断需求是否纳入范围，确定优先级口径，对待确认项拍板或指定确认人 | 范围结论、优先级结论、待确认项责任人 |
| 评审组 | 评审需求清单的完整性、一致性和可行性，给出通过或退回意见 | 评审意见、评审结论 |
AI位于需求分析人员的环节内，负责把材料转成结构化初稿；人工把关点设在第三步逐条核对和第五步状态确认，前者防止编造和漏项，后者防止未确认内容被当作结论提交。状态变化沿“待核对—已核对—待确认—已确认—已纳入评审”推进，每次交接都对应清单状态的更新。
当需求条目需要在系统中承载状态、负责人和评审流转时，可以把清单落到 ONES 的需求管理工作项中，让每条需求对应一个可追踪的工作项，核对记录和待确认项随条目保存。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项和 Wiki 页面等工作上下文；在需求整理场景中，它可围绕音视频转录、用户反馈洞察、PRD 质量检查等材料提炼要点、待澄清问题与拆解建议，也可基于指定 Wiki 页面回答问题并附引用来源，便于核对时回溯依据。相关能力以实际材料与配置为准。
示例：一段访谈记录如何变成三条需求条目
以下为演示情景，用于说明字段填写与核对过程，不代表真实项目。
原始材料片段（业务方访谈转录稿节选）：“我们仓库盘点现在还是纸单，盘完要第二天才能录进系统，经常对不上。希望能用手机直接扫码盘点，扫完就能看到差异。另外盘点差异现在要主管一个个签字，太慢了，最好能在线审批。还有新来的仓管不熟悉流程，盘点前能不能有个操作指引。”
AI按字段表抽取的初稿：
| 编号 | 需求描述 | 来源 | 提出人/角色 | 业务场景 | 优先级 | 状态 | 待确认项 |
|---|---|---|---|---|---|---|---|
| REQ-盘点-01 | 支持手机扫码盘点，盘点完成后即时显示账实差异 | 访谈转录稿第3段 | 仓库业务方 | 仓库盘点 | 未提及 | 待核对 | — |
| REQ-盘点-02 | 盘点差异改为在线审批，替代主管逐个签字 | 访谈转录稿第3段 | 仓库业务方 | 盘点差异处理 | 未提及 | 待核对 | — |
| REQ-盘点-03 | 盘点前提供操作指引，帮助新仓管熟悉流程 | 访谈转录稿第3段 | 仓库业务方 | 仓库盘点 | 未提及 | 待核对 | — |
人工核对后的修订：第一条补充“即时”的具体含义，原文只说“扫完就能看到差异”，是否实时同步需确认，记入待确认项并指定业务方确认；第二条核对原文“主管一个个签字”，确认审批对象为主管，审批层级是否多级需确认；第三条原文未说明指引的载体和覆盖范围，记入待确认项。三条需求的优先级均标注“待定”，由产品负责人按范围结论确定。修订后状态更新为“待确认”，待确认项分别落实到业务方和产品负责人。
这个示例可迁移的规律有三点：需求描述保留原文的业务语言，不提前替换成方案；原文没有的信息一律进入待确认项，不靠推断补齐；每条需求都带来源位置，核对时能直接回到原句。
完成检查：需求清单交付前的核对项
提交评审前，按下表逐项检查。任何一项不通过，先修正再送审，避免把未确认内容当成结论带入评审。
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 可回溯性 | 每条需求都能定位到原文的具体位置，描述与原文一致 | 删除无法回溯的条目，或降级为待确认项 |
| 字段完整性 | 必填字段均有内容，缺失信息以“未提及”标注并进入待确认项 | 补抽或补充待确认项 |
| 口径一致性 | 需求描述粒度一致，状态和优先级使用统一取值 | 统一改写，拆分过粗或合并过细的条目 |
| 重复与冲突 | 无重复条目，冲突双方及出处均已标注 | 合并重复项，补充冲突记录 |
| 待确认项责任 | 每条待确认项写明确认对象和确认内容 | 由产品负责人指定责任人 |
| 状态与评审安排 | 清单状态完整，评审时间、参与人和材料已确定 | 补齐状态，发出评审通知 |
检查通过后，清单即可进入评审。评审中提出的新问题继续以待确认项形式回填，保持清单状态与实际情况同步，下一轮整理时从这些条目接着推进。
常见问题
原始材料只有录音、没有转录稿，AI需求提取还能做吗？
可以先转录再抽取，但转录稿要作为核对依据保留下来。做法是先把录音转成文字并标注时间点，抽取时把来源字段写成“转录稿+时间点”，核对时回到对应时间点的原话。转录本身可能有错字或漏句，涉及数字、人名、流程名称的地方要回听确认，不能直接采信转录文本。若材料涉及敏感信息，先确认录音和转录稿的存放与访问范围，再决定是否投入抽取。
材料里同一件事有几种说法，AI抽出来多条需求，应该合并还是保留？
先判断是不是同一需求。业务场景和需求对象一致、只是表述不同的，合并为一条，保留信息最完整的那条描述，来源字段列出全部出处。如果说法之间存在实质差异，比如审批层级一个说一级、一个说多级，就保留为一条并在待确认项中写明冲突双方及各自出处，交给产品负责人或业务方确认，不自行选定一种说法。合并和标注的结果都要在清单里留痕，便于评审时追溯。
抽取结果里出现原文没提的优先级或实现方式，怎么处理？
这类内容属于AI补充，核对时应删除或降级为待确认项。处理原则是：需求描述只保留原文表达的业务诉求，实现方式、优先级、时间要求等原文未提及的信息，一律写入待确认项并注明需要谁确认。核对时逐条对照来源位置，发现描述超出原文范围就改回原文口径。抽取提示中明确要求缺失字段填“未提及”，可以减少这类补充，但不能替代人工核对。
需求清单条目多、跨多个业务方时，核对和确认怎么安排才不拖进度？
按批次推进，不要求全部抽完再统一核对。每批材料抽取后立即核对，核对通过的条目先进入待确认状态，同步发给对应业务方确认，下一批抽取与上一批确认并行。待确认项按确认对象分组，集中向同一业务方提问，减少来回次数。产品负责人先对范围和有争议的条目拍板，其余条目按状态推进。评审前只需保证清单状态完整、待确认项均有责任人，遗留问题可以带入评审继续处理。
把需求清单放进系统管理，和用表格维护有什么区别？
表格适合快速整理和小范围流转，条目需要多人更新状态、分配负责人、关联评审记录时，系统承载更便于追踪。以 ONES 为例，每条需求可以对应一个工作项，状态、负责人和待确认项随条目保存，评审流转也在同一处记录。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项和 Wiki 页面等工作上下文，在需求整理中围绕音视频转录、用户反馈洞察、PRD 质量检查等材料提炼要点、待澄清问题与拆解建议，也可基于指定 Wiki 页面回答问题并附引用来源，便于核对时回溯依据。具体能力以实际材料与配置为准。
