用AI把自然语言需求整理成结构化条目，真正决定成败的是两件事：每条需求能否回到原始材料，每个说不清的地方能否被明确收敛。本文给出一套可执行的方法，包括字段模板、操作步骤、来源锚点规则、歧义处置流程和复核检查清单，帮助需求负责人和需求分析人员把AI输出变成可入库、可追溯、可确认的需求条目。
要点总览（TL;DR）
- 先固定需求条目字段与层级模板，把来源锚点和歧义状态设为必填，AI输出与人工复核才有共同基准。
- 操作按输入编号、第一遍抽取、第二遍校验、层级归并、输出待复核清单五步执行，每步保留产出物。
- 来源追踪用文档级、段落级、语句级三档锚点，条目编号与来源编号对应，变更时追加记录而非覆盖。
- 歧义按指代不明、范围不清、条件缺失、术语不一致、多方冲突分类，AI只标注不补全，由提出人确认后回写。
- 复核设三类硬门槛：来源锚点缺失、歧义未闭环、验收要点为空，均不得入库。
先定字段与层级：结构化模板怎么设计
结构化模板要在AI开始抽取之前确定下来。模板一旦固定，AI的输出格式、人工复核的检查项、需求库的字段就能对齐，后续不会因为每次整理口径不同而反复返工。模板由需求负责人统一维护，版本变更时通知所有使用人。
需求条目必备字段
下表可作为团队起步模板，字段名称可按现有需求管理工具调整，但必填与选填的划分建议保留。
| 字段 | 填写要求 | 必填/选填 |
|---|---|---|
| 条目编号 | 团队内唯一，按规则生成，不复用 | 必填 |
| 标题 | 一句话说明这条需求要解决什么 | 必填 |
| 描述 | 行为、对象、结果，避免形容词堆叠 | 必填 |
| 验收要点 | 可判断是否完成的观察点，至少一条 | 必填 |
| 优先级 | 按团队既有分级填写 | 必填 |
| 提出人 | 原始诉求的提出者或业务负责人 | 必填 |
| 来源锚点 | 原始文档、段落或语句的定位信息 | 必填 |
| 歧义状态 | 无歧义、待确认、已确认、已拆分、已驳回 | 必填 |
| 复核状态 | 草稿、待复核、已复核、已入库 | 必填 |
| 关联条目 | 父子关系或相关需求编号 | 选填 |
| 备注 | 补充说明、讨论结论 | 选填 |
来源锚点和歧义状态必须设为必填，原因很直接：这两项缺失时，条目无法被验证，也无法判断它是否已经可以进入开发。优先级、验收要点同样必填，因为它们决定条目是否具备可执行性。
层级拆分粒度规则
层级建议采用三层：史诗、特性、用户故事；业务系统类需求可对应为业务需求、功能需求、子功能。拆分粒度按以下规则把握：
- 史诗：对应一个业务目标或一个较大的用户场景，通常跨多个迭代。
- 特性：史诗下可独立交付的能力单元，能对应一组验收要点。
- 用户故事或子功能：最小可确认单元，一条描述一个动作或一个结果，能单独判断完成与否。
拆分时以“能否单独确认含义和验收”为判断标准。一条需求里出现两个以上动作、两个以上角色或两个以上条件分支时，通常需要继续拆分。模板和粒度规则由需求负责人维护，变更时同步更新AI抽取时使用的提示说明，保证AI输出与团队口径一致。
AI结构化的操作步骤：从原始材料到待复核条目
整个流程分五步，每步都有明确输入、动作、输出和完成标志。按顺序执行，避免边抽取边修改导致来源断链。
第一步：输入准备
收集原始需求文档、访谈记录、工单和会议纪要，统一编号，例如“DOC-001”“MTG-2024-03-12”。每份材料保留原始版本，不做删改。完成标志是所有待整理材料都有编号，且能对应到具体提出人或会议。
第二步：第一遍抽取
把编号后的材料和字段模板一起交给AI，要求按模板输出条目草稿，并逐条引用原文片段作为来源。提示中明确：不确定的内容标注歧义，不自行补全。输出为条目草稿清单，每条带来源引用。完成标志是草稿覆盖了材料中的主要诉求点。
第三步：第二遍校验
人工对照原文检查两件事：条目是否覆盖原文要点，是否出现原文没有的内容。发现AI补充了原文未提及的范围、条件或验收标准时，删除或转为待确认问题。输出为校验后的草稿清单和一份遗漏点记录。完成标志是每条草稿都能在原文中找到依据。
第四步：层级归并
把重复条目和从属条目合并到父级，合并时保留被合并条目的来源锚点，记录合并关系。输出为带层级关系的条目清单。完成标志是没有孤立条目，父子关系可以解释。
第五步：输出待复核清单
整理成待复核清单，包含条目编号、来源锚点、歧义状态和待确认问题，交给需求负责人和提出人确认。完成标志是清单进入人工确认环节，复核状态置为“待复核”。
来源追踪怎么落地：锚点、编号与变更留痕
来源追踪的目标是让任何人拿到一条结构化需求，都能在几分钟内回到原始材料，确认这条需求的出处和原始表述。实现方式是把锚点、编号和留痕三件事固定成规则。
来源锚点的三种粒度
| 粒度 | 记录内容 | 适用情况 |
|---|---|---|
| 文档级 | 文档编号、版本、章节 | 背景性需求、范围较大的史诗 |
| 段落级 | 文档编号加段落位置或小标题 | 一般特性与功能需求 |
| 语句级 | 文档编号加原文语句摘录 | 关键需求、存在争议或歧义的需求 |
按需求重要度选择粒度：影响范围大、涉及多方或曾经产生分歧的条目用语句级，普通条目用段落级即可。粒度不必统一，但同一层级内的条目建议保持一致，便于抽查。
编号对应与变更留痕
条目编号与来源编号建立对应关系，例如条目“REQ-012”的来源锚点写为“DOC-003 第2.1节”。条目重新编号时，在备注中记录旧编号，避免引用断链。AI改写或合并条目时，原始表述保留在来源锚点或备注中，改写后的描述单独存放，两者不混在一起。
需求变更时，来源记录采用追加方式：新增一条来源记录并注明变更时间和原因，原有记录保留。定期抽查可以按迭代进行，随机抽取若干条目，检查来源锚点是否可定位、原始表述是否完整、变更记录是否连续。抽查结果记录在复核记录中，作为流程改进依据。
在工具层面，ONES Assistant 智能助手可基于指定的 Wiki 页面组回答问题并附上引用来源，其知识问答和任务执行基于ONES权限体系，输出过程可追踪、结果可审计。这类能力适合承载“条目挂接来源、复核留痕”的管理动作，具体锚点粒度的存储方式以团队实际配置为准。
歧义怎么处理：分类、标注与确认闭环
歧义处理的原则是标注而非补全。AI遇到不确定内容时，输出歧义类型和待确认问题，由提出人确认后再回写条目。这样做的目的是把猜测变成可核查的确认记录。
常见歧义类型
| 歧义类型 | 典型表现 | 确认方向 |
|---|---|---|
| 指代不明 | “这个功能”“他们”指代不清 | 明确具体对象或角色 |
| 范围不清 | “支持多种格式”未说明哪些 | 列出具体范围或排除项 |
| 条件缺失 | 只描述结果，未说明触发条件 | 补充前置条件和例外情况 |
| 术语不一致 | 同一概念在不同材料中叫法不同 | 统一术语并记录对照 |
| 多方诉求冲突 | 两个提出人要求相反 | 由需求负责人组织对齐 |
状态流转与确认记录
歧义条目的状态按“待确认、已确认、已拆分、已驳回”流转。待确认表示已标注但未获得答复；已确认表示提出人给出了明确含义；已拆分表示原条目含义不清但可拆成多条明确需求；已驳回表示该诉求不再需要。每次状态变化记录时间、确认人和结论。
向提出人确认时，问题要具体到可回答，例如“这条需求中的‘快速’指页面加载在几秒内，还是指操作步骤不超过几步”，避免问“请再说明一下”。确认结果回写到条目描述和验收要点中，原歧义标注保留在备注里，形成“曾有何歧义、如何确认”的完整记录。ONES Assistant 在需求澄清场景中可提炼要点、待澄清问题与拆解建议，可作为生成歧义清单的辅助手段，确认结论仍由提出人和需求负责人给出。
角色分工与人工复核规则
结构化工作涉及四类角色，各自在不同环节交付不同产物。分工清楚，复核才有依据。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求负责人 | 维护模板与粒度规则，组织歧义确认，对条目质量负责 | 模板版本、复核记录、入库决定 |
| AI使用人/需求分析人员 | 准备输入材料，执行抽取与校验，整理歧义清单 | 条目草稿、校验记录、待确认问题清单 |
| 提出人/业务方 | 回答歧义问题，确认条目含义与验收要点 | 确认结论与确认记录 |
| 复核人 | 按复核规则检查条目，签署复核意见 | 复核签署记录 |
复核规则设置三类硬性门槛：来源锚点缺失的条目不得入库；歧义未闭环的条目不得入库；验收要点为空的条目不得入库。复核人逐条检查这三项，通过后签署复核意见并更新复核状态。复核记录保留检查人、检查时间和发现的问题，便于后续追溯责任和复盘流程。
示例：一条模糊需求如何变成可追踪的结构化条目
以下为演示情景，用于说明流程如何落地，不涉及真实项目数据。
原始表述与歧义点
会议纪要中记录：“客户希望报表能快点出来，最好能自己调整。”这句话包含三处歧义：范围不清（哪些报表）、条件缺失（“快点”指生成速度还是操作路径）、指代不明（“自己调整”指调整筛选条件还是调整报表结构）。
AI草稿与来源锚点
AI按模板输出草稿：条目“REQ-021 报表生成效率优化”，描述为“提升报表生成速度”，来源锚点为“MTG-2024-03-12 第3段”，歧义状态标为“待确认”，待确认问题为“具体指哪些报表、目标响应时间是多少、‘自己调整’指调整哪些内容”。
确认与终稿
需求分析人员向提出人确认，得到答复：指销售日报和月度汇总两类报表，生成时间希望在一分钟内，“自己调整”指调整时间范围和筛选维度。确认后条目拆为两条用户故事，分别对应两类报表，验收要点写为“在指定数据量下生成时间不超过一分钟”“用户可自行调整时间范围和筛选维度”。来源锚点保留原会议记录，备注中记录确认时间和确认人，歧义状态更新为“已确认”。
这个例子体现的规律是：原始表述越模糊，越需要把歧义拆成可回答的具体问题；确认结果要落到描述和验收要点上，原标注保留，形成可回溯的记录。
完成检查：结构化结果是否可交付
本轮结构化工作结束前，按以下清单逐项检查。全部通过才可进入入库和后续排期。
- 条目覆盖率：原始材料中的每个诉求点都有对应条目，遗漏点已记录原因。
- 来源链：每条需求都能通过来源锚点定位到原始文档、段落或语句，合并条目保留了被合并条目的来源。
- 歧义闭环：不存在状态为“待确认”的条目，已确认条目记录了确认人和结论。
- 层级关系：父子关系合理，没有孤立条目，拆分粒度符合团队规则。
- 验收要点：每条需求至少有一条可判断的验收要点。
- 复核签署：复核人已按三类硬性门槛检查并签署意见，复核状态更新为“已复核”。
检查中发现的问题回到对应环节处理：来源缺失补锚点，歧义未闭环回到确认流程，层级不合理重新归并。检查记录与复核记录一并归档，作为下一轮结构化工作的参考。
常见问题
原始材料本身没有编号，怎么补来源锚点？
先给材料补编号再抽取，不要等条目生成后再回头找来源。可以按材料类型加日期或序号命名，例如文档用“DOC-001”、会议纪要用“MTG-2024-03-12”，并在编号登记表中记录材料名称、版本、提出人和存放位置。补编号时保留原始文件不做删改，条目生成后直接引用该编号即可。若材料已经在其他系统中有编号，沿用原编号并登记对应关系，避免出现两套编号。
AI把两条需求合并后，来源锚点应该挂在哪一条上？
合并后的条目保留全部被合并条目的来源锚点，并在备注中记录合并关系，例如“由REQ-018、REQ-019合并”。如果合并后条目对应多个原始段落，来源锚点逐条列出，不要只保留其中一条。原始表述同样保留在备注或来源记录中，改写后的描述单独存放。这样后续有人质疑条目含义时，可以同时回到两条原始材料核对。
提出人无法及时确认歧义，条目能先入库吗？
建议不入库。歧义未闭环的条目进入开发后容易返工，复核规则中通常把“歧义未闭环”设为硬门槛。可以先把条目留在待复核清单中，标注待确认问题和已等待时间，按迭代节奏集中向提出人确认。若业务上确实需要提前排期，可先拆出含义明确的部分入库，含义不清的部分单独保留为待确认条目，并记录拆分依据。
来源锚点用语句级还是段落级，团队需要统一吗？
不必全部统一，按需求重要度选择即可：影响范围大、涉及多方或曾产生分歧的条目用语句级，普通条目用段落级，背景性史诗可用文档级。同一层级内的条目建议保持一致，便于抽查和交接。团队可以在模板中写明选择标准，由需求负责人维护，避免不同人按各自习惯随意选择导致抽查困难。
ONES Assistant 在需求结构化流程中能承担哪些环节？
ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等工作上下文，把自然语言指令转化为 ONES 中可追踪的工作；在需求澄清场景中可提炼要点、待澄清问题与拆解建议，也可基于指定的 Wiki 页面组回答问题并附上引用来源。这些能力适合用于生成条目草稿和歧义清单。字段模板配置、锚点存储方式和状态流转的具体实现，以团队在 ONES 中的实际配置为准。
