AI把会议记录、用户反馈或PRD整理成需求清单时，输出往往只有一段段文字，条目之间没有父子关系，也看不出某句话来自哪份材料。要让结构化结果真正可用，模板需要同时承载三件事：单条需求写什么、需求之间怎么分层、每条需求从哪里来。下面按“条目—层级—来源”三组字段给出可填写的模板设计，并说明父子拆分、验收条件挂载和回溯链路的判断规则。
要点总览（TL;DR）
- 模板按“条目层—层级层—来源层”三组字段设计：条目层写清这条需求是什么，层级层标明它属于谁、由谁拆出，来源层记录它从哪来、谁改过。
- 父需求与子需求以“能否独立验收”为界：可独立交付并验收的作为父需求，父需求下无法单独验收的拆为子需求；验收条件挂在可验收的最小条目上，父子之间不重复挂载。
- 层级用唯一编号加父需求编号表达，并保留层级路径与深度，例如 REQ-008 / REQ-012，便于排序、检索和检查层级是否闭合。
- 来源追踪至少包含原始出处、原始表述摘录、结构化表述、整理人、AI参与方式、确认状态与变更记录，使每条结构化需求都能回到原始材料的具体位置。
- AI生成内容与人工确认内容用“生成方式”和“确认状态”分开标记，复核时先看确认状态，避免把模型推断当成已确认需求。
模板先定三层结构：条目、层级、来源
模板的骨架可以拆成三个字段组，每组回答一个独立问题。把它们分开设计，AI输出时就不容易把描述、层级和出处混在同一段文字里。
| 字段组 | 回答的问题 | 典型字段 | 在AI输出中的位置 |
|---|---|---|---|
| 条目层 | 这条需求是什么 | 需求编号、标题、描述、类型、优先级、状态、验收条件 | 每条需求一个对象，作为输出的基本单元 |
| 层级层 | 它属于谁、由谁拆出 | 父需求编号、层级路径、层级深度、拆分依据 | 条目对象的关联字段，指向另一条需求 |
| 来源层 | 它从哪来、谁改过 | 原始出处、原始表述摘录、整理人、AI参与方式、确认状态、变更记录 | 条目对象的附属信息，可一对多记录多次来源 |
三层分开的好处是输出格式稳定：AI每次按同一组字段生成，评审人按字段逐项检查，后续导入工作项管理工具时也能按字段映射。条目层是主体，层级层和来源层都是挂在条目上的属性，不需要另起一套结构。
设计时先确定条目层的必填字段，再确定层级层用哪个字段做关联键，最后补来源层。顺序反过来容易出现来源信息无处安放、层级关系靠文字描述的情况。
需求条目字段：从原始表述到可验收条目
条目层承载单条需求的核心信息。字段划分的依据是：缺少该字段会导致需求无法评审、无法排期或无法验收的，设为必填；只影响阅读便利的，设为选填。
| 字段名 | 说明 | 必填/选填 | 示例 |
|---|---|---|---|
| 需求编号 | 全局唯一，建议带前缀，生成后不再复用 | 必填 | REQ-012 |
| 标题 | 一句话说明要解决的问题或要交付的能力，避免写成方案名 | 必填 | 支持按手机号查询历史订单 |
| 描述 | 结构化后的需求正文，说明场景、对象和期望结果 | 必填 | 客服在订单后台输入完整手机号，可查看该号码关联的全部历史订单 |
| 类型 | 区分业务需求、功能需求、非功能需求、缺陷修复等 | 必填 | 功能需求 |
| 优先级 | 用固定档位，如高/中/低，并注明判定依据 | 必填 | 中（影响客服查询效率，不阻塞主流程） |
| 状态 | 标识条目所处阶段，如待确认、已确认、已拆分、已关闭 | 必填 | 待确认 |
| 验收条件 | 可观察、可判断通过与否的条件，挂在可验收的最小条目上 | 必填（可验收条目） | 输入完整手机号后3秒内返回订单列表；号码不存在时给出明确提示 |
| 生成方式 | 标记该条目由AI生成、人工编写或AI生成后人工改写 | 必填 | AI生成后人工改写 |
| 确认状态 | 区分未确认、业务方已确认、评审通过 | 必填 | 未确认 |
| 备注 | 补充背景、待澄清问题或关联材料 | 选填 | 需确认是否支持模糊匹配 |
验收条件的写法要落到可观察的动作和结果上，例如“输入什么、看到什么、在多长时间内”。它挂在能够独立验收的最小条目上：父需求如果只是分组，不写验收条件；子需求如果可单独交付，就写自己的验收条件。AI生成内容与人工确认内容通过“生成方式”和“确认状态”两个字段分开标记，评审时先看确认状态，避免把模型推断直接当成已确认需求。
层级字段：父需求、子需求与验收条件怎么区分
父子关系的判定标准是能否独立验收。能够独立交付、独立判断通过与否的，作为父需求；父需求下无法单独验收、需要组合起来才构成完整交付的，拆为子需求。按这个标准，一个“订单查询能力”可以作为父需求，其下的“按手机号查询”“查询结果分页”作为子需求。
层级用编号表达，不靠缩进或文字描述。每条需求记录父需求编号，同时保留完整层级路径，便于排序和检索：
- 父需求编号：直接填写上级条目的编号，顶层需求留空或填“无”。
- 层级路径：从顶层到当前条目的编号序列，如 REQ-008 / REQ-012。
- 层级深度：用数字标注，顶层为1，便于检查是否过深。
- 拆分依据：一句话说明为什么拆，如“按查询入口拆分，便于分别排期”。
验收条件挂在可验收的最小条目上。判断方法是问一句：这条需求能否单独交给测试验证？能，就写验收条件；不能，说明它只是分组节点，验收条件应下移到子需求。父子同时写验收条件容易造成重复验证和责任不清。
层级深度建议控制在两到三层。超过三层时，先检查是否把验收条件误拆成了子需求，或者把实现步骤当成了需求层级。同一父需求下的子需求应互不重叠，若两条子需求描述的是同一交付物的不同说法，应合并而不是继续拆分。
来源追踪字段：让每条需求可回溯
来源层的目标是让评审人从一条结构化需求出发，能回到原始材料的具体位置，并看清这条需求经过谁的手、被改过什么。
| 字段名 | 说明 | 必填/选填 | 示例 |
|---|---|---|---|
| 原始出处 | 材料名称、位置（页码、段落、时间戳）与材料时间 | 必填 | 客服访谈记录 2024-05-14，第3段 |
| 原始表述摘录 | 原文摘录，保留口语和模糊表达，不做润色 | 必填 | “现在查一个号码要翻好几个页面，太慢了” |
| 结构化表述 | 整理后的需求描述，与摘录形成对照 | 必填 | 客服可在订单后台按手机号一次查询全部历史订单 |
| 整理人 | 负责该条目整理的人员 | 必填 | 张三 |
| AI参与方式 | 说明AI在哪个环节参与，如提取、拆分、改写、仅校对 | 必填 | AI提取原始表述并生成初稿，人工改写描述 |
| 确认状态 | 记录业务方确认结果与确认人 | 必填 | 业务方李四已确认 |
| 变更记录 | 版本号、变更时间、变更人、变更内容摘要 | 必填 | v2，2024-05-16，王五，补充验收条件 |
一条完整回溯链路可以这样呈现：原始材料“客服访谈记录 2024-05-14 第3段”中的原话，经AI提取后由张三整理为 REQ-012，业务方李四确认，随后王五在 v2 中补充验收条件。任何人看到 REQ-012，都能沿这条链路核对原始语境，判断结构化表述是否偏离原意。
来源字段允许一条需求对应多条来源记录，例如同一需求同时来自访谈和工单数据。此时按来源逐条记录，而不是把多个出处塞进一个单元格。
完整示例：一条原始记录拆成结构化条目
以下为演示情景，材料名称、人员与编号均为虚构，仅说明填写方式。
原始材料片段（客服访谈记录 2024-05-14 第3段）：“现在查一个号码要翻好几个页面，太慢了。有时候客户催得急，我只能先记下来回头再查。”
拆分结果：父需求 REQ-008“提升客服订单查询效率”，下挂两条子需求。
| 字段 | REQ-008（父需求） | REQ-012（子需求） | REQ-013（子需求） |
|---|---|---|---|
| 标题 | 提升客服订单查询效率 | 支持按手机号查询历史订单 | 查询结果支持按时间排序 |
| 类型 | 业务需求 | 功能需求 | 功能需求 |
| 优先级 | 中 | 中 | 低 |
| 状态 | 已拆分 | 待确认 | 待确认 |
| 父需求编号 | 无 | REQ-008 | REQ-008 |
| 层级路径 | REQ-008 | REQ-008 / REQ-012 | REQ-008 / REQ-013 |
| 验收条件 | 不单独写，由子需求承载 | 输入完整手机号后3秒内返回订单列表；号码不存在时给出明确提示 | 查询结果默认按订单时间倒序，可切换正序 |
| 原始出处 | 客服访谈记录 2024-05-14 第3段 | 同左 | 同左 |
| 原始表述摘录 | “查一个号码要翻好几个页面，太慢了” | “查一个号码要翻好几个页面” | “有时候客户催得急，我只能先记下来回头再查” |
| AI参与方式 | AI归纳主题并建议拆分 | AI提取并生成初稿 | AI提取并生成初稿 |
| 确认状态 | 业务方已确认拆分方向 | 未确认 | 未确认 |
示例中的追踪关系是：两条子需求共享同一原始出处，但各自摘录对应原话的不同部分；父需求只承担分组和方向确认，验收条件全部落在子需求上。评审时若对 REQ-013 的必要性有疑问，可直接回到访谈原文核对“先记下来回头再查”这一表述的语境。
角色分工与模板落地检查
模板要落地，需要明确每个字段由谁负责填写、谁负责确认。下表给出一种常见分工，团队可按规模调整，但确认动作不宜由整理人自己完成。
| 角色 | 主要职责字段 | 交付物 |
|---|---|---|
| 需求整理人 | 条目层全部字段初稿、层级路径、来源层原始出处与摘录 | 结构化需求清单初稿 |
| 业务方 | 确认描述与优先级，确认状态字段 | 确认意见与待澄清问题 |
| 开发 | 核对类型与技术可行性，补充备注 | 可行性反馈 |
| 测试 | 核对验收条件是否可验证 | 验收条件修订建议 |
AI输出后的复核动作按顺序进行：先查编号是否唯一、层级路径是否闭合，再逐条对照原始表述检查结构化描述是否偏离，最后确认验收条件是否可观察。复核人应在确认状态字段留下记录，而不是只在聊天中口头确认。
落地时可以把这套字段映射到工作项管理工具中。ONES 的工作项支持层级组织，需求文档可在 ONES Wiki 中维护；ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项和 Wiki 页面等上下文，并可将 PRD 拆解为需求和任务、按模块分配负责人。团队可让AI先生成条目初稿和拆分建议，再由整理人补齐来源字段、业务方确认，使结构化结果在工具内保持可追踪。具体字段配置方式以实际环境为准。
模板完成检查清单：
- 编号唯一：清单内无重复编号，已关闭条目的编号未被复用。
- 层级闭合：每条子需求的父需求编号都存在，层级路径与父编号一致，深度不超过约定层数。
- 来源可回溯：每条需求至少一条来源记录，原始出处能定位到具体位置，摘录与结构化表述可对照。
- 验收条件可验证：可验收条目均有验收条件，条件包含可观察的动作或结果，父子之间没有重复挂载。
- 确认留痕：生成方式与确认状态已填写，AI生成内容经过人工确认后才进入已确认状态。
常见问题
原始材料里一句话同时包含多个诉求，应该拆成几条需求？
先判断这句话里的诉求能否分别独立验收。能分别判断通过与否的，拆成多条子需求，并让它们共享同一条原始出处，各自摘录对应原话的不同部分；只能组合起来才构成一次完整交付的，保留为一条需求，在描述里写清多个诉求的关系。
拆分后要检查子需求之间是否重叠。如果两条子需求描述的是同一交付物的不同说法，应合并而不是继续拆。父需求只承担分组和方向确认，验收条件下移到子需求。
AI生成的需求条目，来源字段应该由谁补、补到什么程度？
建议由需求整理人补齐来源字段，AI负责提取原始表述和生成初稿。来源字段至少要能定位到材料名称、位置和时间，并保留原文摘录，使评审人可以对照结构化表述是否偏离原意。
补到什么程度以“能否回到原始语境”为准：看到这条需求，能顺着出处找到原话并判断整理是否准确，就达到要求。同一需求来自多份材料时，按来源逐条记录，不把多个出处塞进一个单元格。
层级深度超过三层时，应该继续拆还是回头检查？
先回头检查，再决定是否继续拆。常见原因是把验收条件误拆成了子需求，或者把实现步骤当成了需求层级。把这类节点合并回可验收的条目后，层级通常会回到两到三层。
如果业务本身确实需要更深的分解，可以在层级路径中保留完整编号，并在拆分依据里写明原因，同时约定深度上限，避免后续继续加层导致责任和验收边界模糊。
需求确认后又发生变更，来源追踪字段怎么记录？
变更记录按版本逐条追加，写明版本号、变更时间、变更人和变更内容摘要，原始表述摘录与结构化表述保持对照关系，不覆盖旧版本。确认状态同步更新，注明新的确认人和确认结果。
如果变更改变了需求的验收边界，应重新检查验收条件是否仍然可观察、可判断，并确认父子层级是否需要调整。变更留痕的目的是让后来的人能看清这条需求经过哪些修改，而不是只看到最终版本。
这套字段能否直接映射到工作项管理工具中使用？
可以按字段对应关系映射：条目层对应工作项的标题、描述、类型、优先级、状态与验收条件，层级层对应父子工作项关系，来源层可作为描述中的固定段落或独立记录维护。映射前先确认工具是否支持父子层级和自定义字段。
ONES 的工作项支持层级组织，需求文档可在 ONES Wiki 中维护；ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项和 Wiki 页面等上下文，并可将 PRD 拆解为需求和任务、按模块分配负责人。团队可让AI生成条目初稿和拆分建议，再由整理人补齐来源字段、业务方确认。具体字段配置方式以实际环境为准。
