AI需求结构化条目模板通常包含五组字段：标识与层级、需求描述、验收与优先级、来源与追踪、状态与责任人。父需求记录目标与范围，子需求记录可验收的细化内容，验收条件写在子需求层级，来源信息逐条记录，并通过父需求ID和关联条目ID串起追踪链。下面给出一张可直接复制的空白表，并说明每个字段怎么填、哪些不能空。
要点总览（TL;DR）
- 模板按五组字段组织：标识与层级、需求描述、验收与优先级、来源与追踪、状态与责任人，共16个字段。
- 父需求填写目标与范围，子需求填写可验收的细化内容；验收条件写在子需求层级，父需求行留空。
- 条目ID、层级类型、标题、优先级、来源类型、状态、负责人、更新时间在父子层级均为必填；父需求ID仅子需求必填。
- 追踪链靠三个字段维持：子需求的父需求ID指向父需求，关联条目记录横向关系，来源链接保留需求出处。
- 模板可按团队规模和需求类型裁剪，但标识、层级、验收、来源四类信息建议保留；调整时记录版本并定期检查一致性。
可复制的AI需求结构化条目空白模板
这张表按五组字段排列，表头固定，行可以复制多份。使用时先填一行父需求，再在下方为每个可验收的细化点各填一行子需求。父需求行的“父需求ID”留空，“层级类型”填“父需求”；子需求行的“父需求ID”填入对应父需求的条目ID，“层级类型”填“子需求”。
| 字段组 | 字段名 | 父需求行填写位置 | 子需求行填写位置 |
|---|---|---|---|
| 标识与层级 | 条目ID | 填写 | 填写 |
| 标识与层级 | 父需求ID | 留空 | 填写所属父需求的条目ID |
| 标识与层级 | 层级类型 | 父需求 | 子需求 |
| 需求描述 | 标题 | 填写 | 填写 |
| 需求描述 | 背景 | 填写 | 按需填写 |
| 需求描述 | 目标 | 填写 | 按需填写 |
| 需求描述 | 范围 | 填写 | 按需填写 |
| 验收与优先级 | 验收条件 | 留空 | 填写 |
| 验收与优先级 | 优先级 | 填写 | 填写 |
| 验收与优先级 | 依赖 | 按需填写 | 按需填写 |
| 来源与追踪 | 来源类型 | 填写 | 填写 |
| 来源与追踪 | 来源链接 | 填写 | 填写 |
| 来源与追踪 | 关联条目 | 按需填写 | 按需填写 |
| 状态与责任人 | 状态 | 填写 | 填写 |
| 状态与责任人 | 负责人 | 填写 | 填写 |
| 状态与责任人 | 更新时间 | 填写 | 填写 |
把上表转成横向表头即可直接使用：条目ID、父需求ID、层级类型、标题、背景、目标、范围、验收条件、优先级、依赖、来源类型、来源链接、关联条目、状态、负责人、更新时间。一行对应一个条目，父需求与子需求共用同一套表头，靠“父需求ID”和“层级类型”区分位置。
字段说明：每个字段记录什么、怎么填
字段说明与上表逐项对应。统一填写口径的目的，是让产品、研发、测试和业务方看到同一条目时理解一致，减少来回确认。
| 字段名 | 记录内容 | 填写口径 |
|---|---|---|
| 条目ID | 条目的唯一编号 | 团队内不重复即可，如REQ-001、REQ-001-01；子需求编号建议带父需求前缀，便于肉眼识别归属 |
| 父需求ID | 所属父需求的条目ID | 父需求行留空；子需求行必须填写，且值要能在表中找到对应父需求行 |
| 层级类型 | 条目在需求树中的位置 | 只填“父需求”或“子需求”两种值，避免出现“二级需求”“子任务”等混用叫法 |
| 标题 | 一句话说明这条需求要解决什么 | 用“对象+动作+结果”的写法，如“支持按项目导出需求清单”；避免只写“优化导出” |
| 背景 | 需求产生的原因和现状问题 | 写清谁在什么场景下遇到什么问题，附必要的业务数据或反馈来源 |
| 目标 | 这条需求完成后希望达到的结果 | 父需求写业务目标，子需求可写该细化点要达成的局部结果；目标要能被验收条件检验 |
| 范围 | 本次做与不做的边界 | 父需求写清涉及的角色、模块和明确排除的内容，防止后续范围蔓延 |
| 验收条件 | 判断条目完成的客观标准 | 写在子需求层级，一条子需求对应一组可核验的条件，用“给定…当…则…”或清单形式描述 |
| 优先级 | 条目的相对重要程度 | 团队统一用同一套等级，如P0/P1/P2，并写明各级含义；父需求与子需求都填 |
| 依赖 | 完成本条目前置的其他条目或外部条件 | 填写依赖的条目ID或外部事项，没有则留空；跨团队依赖要写清对接方 |
| 来源类型 | 需求从哪里来 | 用固定枚举，如用户反馈、数据分析、内部提出、合规要求、AI拆解建议 |
| 来源链接 | 来源的原始记录位置 | 填工单、访谈记录、数据报表或文档的地址；AI生成的条目要保留原始输入的位置 |
| 关联条目 | 与本条目相关但不构成父子关系的条目 | 填写相关条目ID并注明关系，如“重复”“替代”“相关”；用于发现重复需求和影响分析 |
| 状态 | 条目当前所处阶段 | 使用固定状态值，如待澄清、已确认、开发中、待验收、已完成、已关闭 |
| 负责人 | 当前推动该条目的人 | 同一时刻只写一个主负责人，协作人放在关联条目或备注中 |
| 更新时间 | 条目最后一次实质性修改的时间 | 状态、验收条件、负责人变化时必须更新，便于识别长期未推进的条目 |
层级与追踪关系靠三个字段维持：子需求的“父需求ID”指向父需求，“关联条目”记录横向关系，“来源链接”保留需求出处。三者配合，任何一条子需求都能向上找到目标与范围，向外找到原始依据。
必填与选填：哪些字段不能空
必填字段的作用是保证条目可被识别、可被验收、可被追溯。字段全部留空的模板只是空壳，下面按父需求与子需求分别划分。
| 字段名 | 父需求 | 子需求 | 说明 |
|---|---|---|---|
| 条目ID | 必填 | 必填 | 没有ID就无法被引用和追踪 |
| 父需求ID | 留空 | 必填 | 子需求脱离父需求会失去目标上下文 |
| 层级类型 | 必填 | 必填 | 决定该行按父还是按子来评审 |
| 标题 | 必填 | 必填 | 列表和看板中主要靠标题识别条目 |
| 背景 | 必填 | 选填 | 父需求需要交代来龙去脉；子需求可引用父需求背景 |
| 目标 | 必填 | 选填 | 父需求承载业务目标；子需求目标可由验收条件体现 |
| 范围 | 必填 | 选填 | 范围写在父需求层级，子需求默认继承 |
| 验收条件 | 选填 | 必填 | 验收落在子需求，父需求可写整体验收口径但不替代子需求条件 |
| 优先级 | 必填 | 必填 | 排期和取舍都依赖优先级 |
| 依赖 | 选填 | 选填 | 存在前置条件时填写，无依赖留空 |
| 来源类型 | 必填 | 必填 | 用于统计需求来源和评估AI拆解建议的采纳情况 |
| 来源链接 | 必填 | 选填 | 父需求保留原始出处；子需求可继承父需求来源 |
| 关联条目 | 选填 | 选填 | 发现重复、替代或跨需求影响时填写 |
| 状态 | 必填 | 必填 | 没有状态无法判断条目是否可进入下一环节 |
| 负责人 | 必填 | 必填 | 每条需求都要有明确推动人 |
| 更新时间 | 必填 | 必填 | 用于识别停滞条目 |
填写时遇到暂时缺失的字段，按以下方式处理：来源链接缺失时先填来源类型并在链接处标注“待补充”，同时把状态置为“待澄清”；验收条件写不出时，说明子需求还没有细化到可执行程度，应退回澄清而不是先进入开发；负责人未定时由需求提出方或产品负责人临时承接，避免条目无人推进。缺字段的条目可以存在，但不应以“已确认”状态进入排期。
填写示例：一条父需求与两条子需求的完整条目
以下为演示情景，用一份已填写的条目展示字段如何配合。父需求描述一个业务目标，两条子需求分别承载可验收的细化内容，来源信息逐条记录，子需求通过父需求ID指回父需求。
| 字段名 | 父需求 REQ-012 | 子需求 REQ-012-01 | 子需求 REQ-012-02 |
|---|---|---|---|
| 条目ID | REQ-012 | REQ-012-01 | REQ-012-02 |
| 父需求ID | （留空） | REQ-012 | REQ-012 |
| 层级类型 | 父需求 | 子需求 | 子需求 |
| 标题 | 支持按项目导出需求清单 | 导出文件包含需求条目全部字段 | 导出操作记录到操作日志 |
| 背景 | 项目复盘时需要线下整理需求清单，目前靠人工复制，耗时且易漏项 | 人工整理时常遗漏验收条件和来源信息 | 导出涉及数据外带，需要可追溯 |
| 目标 | 复盘准备时间从半天缩短到十分钟内，清单内容与系统一致 | 导出内容与条目字段一一对应 | 每次导出可查到操作人和时间 |
| 范围 | 覆盖需求条目导出；不含测试用例和缺陷导出 | （继承父需求） | （继承父需求） |
| 验收条件 | （留空，由子需求承载） | 给定一个含10条需求的父需求，当执行导出时，则文件包含16个字段且条数与系统一致 | 给定一次成功导出，当查看操作日志时，则能看到操作人、时间和导出条数 |
| 优先级 | P1 | P1 | P2 |
| 依赖 | （留空） | 字段定义定稿 | REQ-012-01 |
| 来源类型 | 内部提出 | AI拆解建议 | 合规要求 |
| 来源链接 | 复盘会议记录-0312 | 复盘会议记录-0312 | 数据外带管理规范第4条 |
| 关联条目 | REQ-008（相关：同属导出能力） | （留空） | （留空） |
| 状态 | 已确认 | 开发中 | 待澄清 |
| 负责人 | 产品-李 | 研发-王 | 产品-李 |
| 更新时间 | 2025-03-14 | 2025-03-18 | 2025-03-15 |
示例中可以看到几条填写规则的实际效果：父需求只写目标与范围，验收条件留在子需求；第二条子需求依赖第一条子需求，依赖字段直接填条目ID；两条子需求的来源不同，分别记录，便于后续统计AI拆解建议的采纳比例。当AI辅助把一段PRD或会议记录拆成条目时，拆解结果先按这套字段落表，再由负责人逐条确认状态，未确认的条目保持“待澄清”。ONES Assistant 可围绕PRD质量检查和需求智能生成提炼要点、待澄清问题与拆解建议，拆出的条目仍需按模板补齐来源与验收条件后再进入排期。
模板的调整与维护方法
模板落地后需要随团队和需求类型调整，调整的原则是保住标识、层级、验收和来源四类信息，其余字段可按需裁剪。
- 按团队规模裁剪。人数较少、需求类型单一的团队可以合并“背景”和“目标”，保留“范围”即可；跨团队协作多、需求来源复杂的团队应保留来源类型、来源链接和关联条目，便于对账和影响分析。
- 按需求类型裁剪。合规类、对外承诺类需求必须保留来源链接和验收条件；内部优化类需求可简化背景描述，但条目ID、父需求ID、状态和负责人不能省。
- 评估字段增删的影响。删除“父需求ID”会切断层级，删除“关联条目”会丢失横向追踪，这两类字段建议只增不删；新增字段时同步更新字段说明表和填写示例，避免模板与说明脱节。
- 版本化模板。每次调整记录版本号、调整内容、生效日期和影响范围，旧条目按原版本保留，新条目按新版本填写；跨版本统计时以条目ID为准，不依赖字段位置。
- 定期检查一致性。按固定周期抽查：子需求的父需求ID是否都能找到对应父需求，验收条件是否为空，状态与更新时间是否长期未变，来源类型是否出现自由填写的新值。发现异常条目退回负责人补齐。
- 清理与归档。已关闭且超过保留期的条目移入归档区，保留条目ID和来源链接，避免活跃表被历史数据淹没；归档前确认没有其他条目通过关联字段引用它。
在协作工具中承载这套模板时，可以把字段定义为工作项属性，把父需求ID对应为父子层级关系，让条目状态和负责人随流程流转更新。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等工作上下文，并可将PRD拆解为需求和任务、按模块分配负责人；团队可在此基础上按本文模板补齐验收条件与来源信息，使AI拆解结果进入可追踪的需求条目体系。
常见问题
AI拆解出来的需求条目，应该先填模板还是先评审？
建议先按模板落表，再进入评审。AI拆解结果通常包含标题、背景和初步的拆分建议，但验收条件和来源信息往往不完整。落表时把拆出的条目按父需求、子需求分别填写，缺失的字段标注“待补充”，状态统一置为“待澄清”。评审时重点看三件事：子需求是否都有可核验的验收条件，父需求ID是否都能找到对应父需求，来源链接是否指向原始输入。评审通过的条目再改为“已确认”进入排期，未通过的退回补充。
子需求的验收条件写不出来，说明什么？
验收条件写不出来，通常说明这条子需求还没有细化到可执行的程度，或者团队对“完成”的判断标准尚未达成一致。此时不宜先进入开发，应退回澄清：确认这条子需求要达成的局部结果是什么、由谁来判断完成、判断依据是什么。如果确实属于探索性工作，可以把验收条件写成阶段性产出，例如“完成技术方案评审并输出结论”，而不是留空。留空的验收条件会让条目在开发中失去完成标准，也影响后续测试和验收。
父需求需要写验收条件吗？
父需求可以写整体验收口径，用来描述这个业务目标达成时的总体判断，但不替代子需求的验收条件。实际执行中，验收落在子需求层级，每条子需求对应一组可核验的条件，逐条通过后父需求才具备关闭条件。如果父需求写了整体口径，建议在字段说明中注明它与子需求验收条件的关系，避免两处标准不一致时产生争议。团队规模较小、需求较简单时，也可以只在父需求写整体口径，子需求用清单形式列出细化条件。
来源链接找不到原始记录时怎么填？
来源链接缺失时，先如实填写来源类型，在链接处标注“待补充”，并把条目状态置为“待澄清”。不要用推测的地址或无关文档代替，否则后续追溯会失真。同时安排一次补充动作：向需求提出方确认原始记录的位置，或补做一次访谈、会议记录作为来源。对于AI拆解产生的条目，原始输入的位置尤其重要，它决定了拆解建议能否被复核。来源信息补齐后，再更新状态和更新时间。
团队已有需求管理工具，还需要单独维护这张表吗？
这张表的作用是统一字段口径，不一定需要独立于工具之外维护。如果团队使用协作工具管理需求，可以把模板中的字段定义为工作项属性，把父需求ID对应为父子层级关系，让状态和负责人随流程流转更新。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项和 Wiki 页面等工作上下文，并可将PRD拆解为需求和任务、按模块分配负责人；团队可在此基础上按模板补齐验收条件与来源信息。工具承载字段之后，模板更多作为字段定义和填写规范的参照，而不是另一份需要同步的表格。
