用AI把自然语言需求整理成结构化条目，关键前提是先定好字段与层级规则、给每段原始需求保留来源标记，再让AI按固定格式抽取。本文按“定规则—备语料—写提示词—分批整理—处理歧义—人工复核—检查入库”的顺序给出可执行步骤，适用于会议记录、聊天、工单、访谈笔记等来源的需求整理场景。
要点总览（TL;DR）
- 先定字段与层级规则：编号、标题、描述、来源、优先级、验收要点为最小字段集，业务需求、用户故事、功能点、约束条件四类条目按规则挂接。
- 语料在清洗前完成来源编号，每段原文保留来源ID、采集时间和原文片段，合并时保留全部出处。
- 提示词固定四部分：角色与任务、字段定义与输出格式、层级判断规则、依据与不确定性标注，原文未提及的字段填“待定”。
- 按来源分批抽取、按主题跨来源合并，冲突表述单独列清单，由需求分析人员判断而非AI取舍。
- 歧义由AI识别提问、提出方给答案，复核按角色分工记录“通过／修改后通过／退回”，入库前逐项核对完成清单。
先定字段与层级：结构化条目的最小规则
在把任何一段自然语言交给AI之前，先确定“整理成什么样”。规则越明确，AI输出的稳定性越高，人工复核也越容易判断对错。这一步的产物是一份字段与层级规则表，后续提示词直接引用它。
条目类型划分
先约定团队使用哪几类条目，避免同一诉求被归到不同类型。常见划分如下，团队可按实际裁剪：
- 业务需求：描述业务目标或用户价值，通常粒度较粗，是父级。
- 用户故事：以角色、场景、价值描述一个可交付的能力。
- 功能点：可开发、可测试的具体功能描述，通常挂在用户故事之下。
- 约束条件：性能、合规、兼容性、时间窗口等限制，可挂在任意层级。
必填字段与填写口径
字段不宜过多，先保证必填项能填满、能核验。建议的最小字段集如下：
| 字段 | 填写口径 | 粒度示例 |
|---|---|---|
| 编号 | 按“来源ID-序号”生成，全局唯一 | MTG-003-02 |
| 标题 | 一句话说明要做什么，动词开头，不超过30字 | 支持按手机号查询历史订单 |
| 描述 | 说明场景、对象、动作和预期结果，不写实现方案 | 客服在订单页输入手机号，可查看该号码近12个月订单列表 |
| 来源 | 来源ID加原文片段定位 | MTG-003，第2段 |
| 优先级 | 按团队既有分级填写，缺依据时标“待定” | 高／中／低／待定 |
| 验收要点 | 可观察、可验证的判断条件，每条独立成句 | 输入不存在号码时提示“无记录” |
层级与关联规则
层级关系要写成可判断的规则，例如：业务需求可作为父级，用户故事必须挂在一个业务需求下，功能点必须挂在用户故事下，约束条件可挂任意层级。依赖与关联用“依赖：编号”“关联：编号”两个字段表达，禁止条目互为父级形成循环。规则表里同时写明“一个父级下子条目数量的合理范围”，防止AI把一句话拆成十几个碎片。
准备语料：原始需求的来源标记与清洗
输入质量决定输出质量。语料准备的目标是让每一条结构化结果都能回溯到原文，因此来源标记要在清洗之前完成，而不是整理之后再补。
收集与编号
把会议记录、聊天记录、邮件、工单、访谈笔记按来源类型收集，每份材料分配一个来源ID，并记录采集时间和提供人。同一场会议拆成多份记录时，用“来源ID-分段号”区分。建议在语料清单中保留原始文件位置，便于回溯。
清洗与合并
清洗只做不影响语义的处理：去除重复表述、合并同一诉求的多种说法、删掉与需求无关的寒暄和流程性内容。合并时保留被合并片段的来源ID，避免合并后丢失出处。原文片段要原样保留，不做改写，因为改写后的文字无法作为追溯依据。
这一步的交付物是带来源ID的原始需求语料清单，格式可以是表格：来源ID、来源类型、采集时间、原文片段、初步主题标签。主题标签用于后续分批投喂。
设计提示词：让AI按规则抽取条目与层级
提示词的作用是把第一步的规则表翻译成AI可执行的指令。一份可复用的提示词通常包含四部分：角色与任务、字段定义与输出格式、层级判断规则、依据与不确定性的标注要求。
提示词结构模板
- 角色与任务：说明你是需求分析助手，任务是从给定原文中抽取结构化需求条目，不补充原文没有的信息。
- 字段定义：逐条列出必填字段、填写口径和粒度要求，直接引用规则表。
- 输出格式：指定表格或JSON，固定字段顺序，便于后续合并。JSON适合程序化处理，表格适合人工快速浏览。
- 层级判断：写明什么情况归为父级、什么情况归为子条目，无法判断时输出“层级待定”而不是猜测。
- 依据标注：要求每条结果附原文引用片段和所在位置，并对不确定的字段标注置信度或“待确认”。
输出格式示例
以JSON为例，单条结果可包含：编号、类型、标题、描述、来源ID、原文引用、父级编号、依赖、优先级、验收要点、待确认问题、置信度。提示词中明确“原文未提及的字段填‘待定’，不得编造”，可以显著减少AI自行补全的情况。
执行整理：分批抽取、合并与去重
实际执行时不要一次性投喂全部语料。按来源或主题分批，单批控制在AI能完整处理的规模内，每批输出后立即记录处理结果和版本，便于出问题时回退。
分批与合并
建议先按来源分批抽取，再按主题做跨来源合并。合并时以“同一业务对象、同一动作、同一预期结果”为判断标准，把不同来源的相似条目合并为一条，来源字段保留全部来源ID。合并后重新检查层级，避免合并导致父子关系错乱。
冲突与版本记录
不同来源对同一需求描述不一致时，不要由AI自行取舍，单独列入冲突清单，注明各自来源和差异点，交给需求分析人员判断。每批处理记录应包含：批次号、输入来源ID、输出条目数、合并与删除记录、冲突条目、处理时间。
处理歧义：标记、追问与回填
AI整理需求时最常见的风险是把不确定的信息写成确定表述。处理歧义的原则是：AI只负责识别和提问，答案由需求提出方给出。
常见歧义类型
- 指代不明：原文中的“这个功能”“他们”没有明确指向。
- 范围不清：没有说明适用角色、终端、数据范围或时间窗口。
- 条件缺失：只写了正常流程，未说明异常和边界情况。
- 术语不一致：同一对象在不同来源中使用不同叫法。
追问与回填
在提示词中要求AI输出待确认问题清单，每个问题关联对应条目编号和原文位置。需求分析人员汇总后向提出方追问，把答案回填到描述或验收要点，并在条目中记录回填时间和回答人。暂时无法确认的条目保留“待定”状态，不进入开发排期，也不因等待而阻塞其他条目的整理。
人工复核：角色分工与评审要点
AI输出只是初稿，复核是把初稿变成可用需求条目的必要环节。复核要明确谁看什么、按什么标准通过。
| 角色 | 复核职责 |
|---|---|
| 需求提出方 | 确认描述与原始诉求一致，回答待确认问题 |
| 需求分析人员 | 检查字段完整性、层级合理性、条目粒度与去重结果 |
| 开发或测试代表 | 检查验收要点是否可验证，约束条件是否遗漏 |
复核检查项包括：必填字段是否齐全、来源是否可追溯、层级是否合理且无循环、验收要点是否可观察可验证、歧义项是否已关闭或明确挂起。复核结论按“通过／修改后通过／退回”记录，退回时写明具体问题和修改要求，修改后重新走同一检查项。
当结构化条目需要进入需求库管理时，可以把确认后的条目写入工作项系统，让条目、来源文档和评审记录保持关联。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，可围绕需求提炼要点、待澄清问题与拆解建议，并基于 ONES 权限体系执行，输出过程可追踪；团队可将复核通过的条目落到工作项中继续跟踪状态与负责人。
示例：一段会议记录如何变成结构化条目
以下为演示情景，用于说明流程，不代表真实客户案例。
原始会议记录片段
来源ID：MTG-007，采集时间：3月12日。原文：“客服那边说查订单太慢了，要输好几个条件。能不能直接输手机号就出来？另外老客户的历史订单也要能看到，大概一年内的吧。这个月底前要上线，不然大促来不及。”
AI抽取结果
| 字段 | 内容 |
|---|---|
| 编号 | MTG-007-01 |
| 类型 | 用户故事 |
| 标题 | 支持客服按手机号查询订单 |
| 描述 | 客服在订单查询页输入手机号，直接返回该号码关联的订单列表 |
| 来源 | MTG-007，第1段 |
| 优先级 | 高（原文提到月底上线） |
| 验收要点 | 输入有效手机号返回订单列表；输入无记录号码给出提示 |
| 待确认问题 | “一年内”是否指近12个月；是否包含已取消订单 |
| 置信度 | 描述高，时间范围低 |
复核与最终条目
需求提出方确认时间范围为近12个月、包含已取消订单；测试代表补充“列表按时间倒序”作为验收要点。复核结论为修改后通过，条目更新为MTG-007-01 v2，待确认问题关闭并记录回答人。约束条件“月底前上线”单独建为一条约束条目，关联到该用户故事。
完成检查：结构化结果是否可用
入库前逐项核对以下清单，全部满足或已明确标注例外，才算本轮整理完成。
- 每条需求都有来源ID和可定位的原文依据。
- 必填字段无空缺；确有空缺的已标注原因和责任人。
- 层级关系无循环、无孤立条目，父级与子条目类型符合规则表。
- 跨来源重复条目已合并，冲突条目已单独列出并有处理结论。
- 歧义项已关闭，或明确挂起并记录追问对象与时间。
- 验收要点逐条可观察、可验证。
- 复核记录完整，包含复核人、结论和修改痕迹。
- 批次处理记录与版本号可查，能回溯到任一历史版本。
清单通过后，把条目写入需求库并保留版本记录。后续需求变更时，沿用同一套字段与来源规则增量整理，避免新旧条目口径不一致。
常见问题
原始需求分散在会议记录、聊天和工单里，先整理哪一类比较合适？
建议先按来源类型分批处理，优先整理信息密度高、上下文完整的材料，例如正式会议记录和访谈笔记，再处理聊天和工单这类碎片化来源。每批处理完立即记录批次号、输入来源ID和输出条目数，便于后续合并时定位出处。碎片化来源中的同一诉求往往需要跨批次合并，放在后面处理可以减少重复劳动。
AI抽取时把原文没说的内容补全了，怎么控制？
在提示词中明确“原文未提及的字段填‘待定’，不得编造”，并要求每条结果附原文引用片段和位置。输出后逐条比对引用片段与字段内容，凡是描述超出原文范围的条目退回重做。对时间范围、适用角色、数据范围这类容易补全的字段，可以单独要求AI标注置信度，低置信度条目进入待确认清单。
同一需求在不同来源里说法不一致，应该以哪份为准？
不预设哪份为准。把不一致的表述单独列入冲突清单，注明各自来源ID和差异点，交给需求分析人员判断，必要时向需求提出方确认。冲突条目在解决前保持待定状态，不进入开发排期。解决后把结论和依据回填到条目中，保留冲突记录以便回溯。
复核环节需要哪些角色参加，能否只由需求分析人员把关？
建议至少覆盖三类角色：需求提出方确认描述与原始诉求一致并回答待确认问题；需求分析人员检查字段完整性、层级合理性和去重结果；开发或测试代表检查验收要点是否可验证、约束条件是否遗漏。只由需求分析人员把关，容易漏掉验收要点的可验证性和技术约束。团队规模较小时可由一人兼多个角色，但检查项仍需逐项执行并记录结论。
结构化条目确认后，如何与后续的需求跟踪衔接？
把复核通过的条目写入需求库或工作项系统，保留编号、来源ID和评审记录之间的关联，后续变更沿用同一套字段与来源规则增量整理。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，可围绕需求提炼要点、待澄清问题与拆解建议，并基于 ONES 权限体系执行，输出过程可追踪；团队可将确认后的条目落到工作项中继续跟踪状态与负责人。
