需求文档目录是一张按层级登记需求文档的索引表，用文档编号、层级、标题、版本、状态、负责人、关联需求与存放位置等字段，把散落的PRD和规格说明组织成可检索、可追溯的目录。本文提供一份可直接复制填写的空白表格，并说明每个字段的填写口径、必填与选填的划分、一份完整填写示例，以及目录建好后的维护方法。
要点总览（TL;DR）
- 需求文档目录用文档编号、层级、标题、版本、状态、负责人、关联需求、存放位置等字段，把PRD与规格说明组织成可检索、可追溯的索引表。
- 最小可用版本保留文档编号、标题、状态、负责人、存放位置五列；文档量增长或需与需求池对账时，再增加层级、版本、关联需求、更新日期和备注。
- 目录按层级排列：父级PRD为1级，子级规格说明为2级，更细的补充文档为3级，跨模块公共文档为0级，层级建议不超过三层。
- 维护动作绑定文档生命周期：新增在首次评审后登记，变更同步版本与状态，废弃保留行并注明替代编号，拆分合并保留原编号标注关系。
- 目录只登记当前有效版本，状态使用固定枚举，版本与状态在同一次操作中更新，避免目录与文档现状脱节。
可复制空白模板：需求文档目录表
下表是需求文档目录的空白模板，可直接复制到Excel、飞书表格、在线文档或ONES Wiki页面中填写。表头字段固定，行按文档层级从上到下排列：父级PRD在上，其下的子级规格说明紧随其后并缩进登记，形成可读的树状索引。
| 文档编号 | 层级 | 文档标题 | 版本 | 状态 | 负责人 | 关联需求 | 存放位置 | 更新日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
行结构建议按以下方式组织：
- 第一行为父级PRD，层级填“1”，代表一个需求主题或产品模块的总体说明。
- 其下的子级规格说明层级填“2”，标题前可用缩进或编号体现从属关系，例如“1.1 登录流程规格说明”。
- 同一父级下若还有接口说明、数据字典等更细文档，可继续用“3”级登记，层级不宜超过三层，避免目录本身变得难读。
- 跨模块的公共文档（如通用交互规范）单独放在目录末尾，层级填“0”，表示不归属某个具体需求。
字段说明：每个目录列登记什么
字段的作用是让目录同时承担“找得到”和“对得上”两件事：找得到靠编号、标题和存放位置，对得上靠层级、关联需求和版本状态。下表逐列说明填写口径。
| 字段 | 登记内容 | 填写口径 |
|---|---|---|
| 文档编号 | 文档的唯一标识 | 建议采用“模块缩写-序号”格式，如PRD-LOGIN-001；编号一经分配不再复用，文档废弃后编号保留并标注状态 |
| 层级 | 文档在需求结构中的位置 | 用数字表示，1为父级PRD，2为子级规格说明，3为更细的补充文档，0为跨模块公共文档 |
| 文档标题 | 文档的正式名称 | 与文档内标题保持一致，写清对象和范围，如“会员中心积分规则PRD”，避免“需求文档v2最终版”这类无法辨识的命名 |
| 版本 | 文档当前有效版本 | 填写当前对外生效的版本号，如V1.2；历史版本留在文档系统里，目录只登记当前版本，避免多版本并存造成误读 |
| 状态 | 文档所处的生命周期阶段 | 建议使用固定枚举：草稿、评审中、已确认、开发中、已上线、已废弃；状态由负责人变更时同步更新 |
| 负责人 | 对该文档内容负责的人 | 填写具体姓名而非团队名，负责评审组织、变更确认和状态更新 |
| 关联需求 | 文档对应的需求条目 | 填写需求管理系统中的需求编号或需求池条目号，使目录与需求列表可以互相跳转核对 |
| 存放位置 | 文档实际所在的路径或链接 | 填写知识库路径、文件夹名称或文档链接，保证从目录能一步定位到原文 |
| 更新日期 | 目录行最近一次修改时间 | 每次变更版本、状态或负责人时同步刷新，用于识别长期未维护的条目 |
| 备注 | 补充说明 | 记录拆分、合并、替代关系等，如“已由PRD-LOGIN-003替代” |
字段之间存在对应关系，填写时需要一起看：文档编号与层级共同决定目录的排序和归属；版本与状态共同表达“这份文档现在能不能作为开发依据”，状态为“已确认”或“开发中”时版本才有执行意义；关联需求与存放位置一内一外，前者指向需求侧，后者指向文档侧，两者都填才能完成追溯闭环。若关联需求为空，说明该文档尚未挂到具体需求上，应在评审前补齐。
必填与选填：哪些字段不能空
目录字段不必一次全部启用。团队规模小、文档量少时，先保证最小可用版本能回答“有哪些文档、在哪、谁负责、什么状态”；文档量增长或需要与需求系统对账时，再补充扩展字段。
| 字段 | 属性 | 理由与适用场景 |
|---|---|---|
| 文档编号 | 必填 | 唯一标识是检索和引用其他字段的基础，缺失会导致同名文档无法区分 |
| 文档标题 | 必填 | 目录的首要用途是让人找到文档，标题缺失则目录失去意义 |
| 状态 | 必填 | 决定文档能否作为开发或测试依据，缺失会造成误用旧稿 |
| 负责人 | 必填 | 变更、评审和废弃都需要有人确认，责任人不明时目录会逐渐失效 |
| 存放位置 | 必填 | 目录是索引，必须能指向原文，否则只是重复登记 |
| 层级 | 选填（推荐） | 文档量少时可省略；出现父子文档关系后建议启用，用于表达PRD与规格说明的从属 |
| 版本 | 选填（推荐） | 单版本流转的团队可省略；存在多轮评审或对外交付时建议启用 |
| 关联需求 | 选填 | 已使用需求管理工具的团队建议启用，用于目录与需求列表对账；纯文档团队可暂缓 |
| 更新日期 | 选填 | 用于识别长期未维护条目，文档量较大时价值明显 |
| 备注 | 选填 | 记录替代、拆分等特殊情况，按需填写 |
最小可用版本保留文档编号、标题、状态、负责人、存放位置五列，适合十人以内、文档数量在几十份量级的团队。完整版本在此基础上增加层级、版本、关联需求、更新日期和备注，适合多模块并行、需要与需求系统核对、或文档需要对外交付的场景。两种版本的字段含义一致，后续扩展时直接加列即可，不需要重建目录。
填写示例：一份完整的需求文档目录
以下示例为演示数据，编号、人名和版本号仅用于说明填写方式。示例覆盖一个父级PRD及其下的规格说明，并包含一份已废弃文档，用于展示状态与备注字段的配合。
| 文档编号 | 层级 | 文档标题 | 版本 | 状态 | 负责人 | 关联需求 | 存放位置 | 更新日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| PRD-MEMBER-001 | 1 | 会员中心改版PRD | V2.0 | 开发中 | 张岚 | REQ-2024-031 | 知识库/产品/会员中心/PRD-MEMBER-001 | 2024-06-18 | 含积分与等级两个子模块 |
| SPEC-MEMBER-002 | 2 | 1.1 积分获取与消耗规格说明 | V1.3 | 已确认 | 李哲 | REQ-2024-031 | 知识库/产品/会员中心/规格/积分 | 2024-06-15 | 接口字段以本文为准 |
| SPEC-MEMBER-003 | 2 | 1.2 会员等级升降规则规格说明 | V1.0 | 评审中 | 王敏 | REQ-2024-032 | 知识库/产品/会员中心/规格/等级 | 2024-06-20 | 待运营确认保级周期 |
| PRD-MEMBER-004 | 1 | 会员权益展示PRD（旧版） | V1.4 | 已废弃 | 张岚 | REQ-2024-018 | 知识库/产品/会员中心/归档 | 2024-05-30 | 已由PRD-MEMBER-001替代 |
| SPEC-COMMON-005 | 0 | 通用弹窗交互规范 | V1.1 | 已确认 | 陈可 | — | 知识库/设计/规范/交互 | 2024-04-12 | 跨模块公共文档 |
从示例可以看出字段如何配合：PRD-MEMBER-001作为父级，其下两份规格说明的关联需求分别指向REQ-2024-031和REQ-2024-032，说明同一PRD可以拆出对应不同需求条目的子文档；SPEC-MEMBER-002状态为“已确认”、版本为V1.3，表示该版本可作为开发依据，而SPEC-MEMBER-003仍在“评审中”，开发不应据此排期；PRD-MEMBER-004状态为“已废弃”，备注写明替代关系，读者据此转到新文档，编号仍保留在目录中以便追溯历史决策。公共文档SPEC-COMMON-005层级为0、关联需求留空，用“—”占位，避免空单元格被误认为漏填。
调整与维护方法：让目录长期可用
目录的价值取决于它是否与文档现状同步。建议把更新动作绑定到文档生命周期节点上，而不是依赖定期集中整理。
- 新增文档：文档创建并通过首次评审后，由负责人在目录中新增一行，分配编号、填写层级与关联需求，状态先填“评审中”，确认后改为“已确认”。未评审的草稿不进入目录，避免目录被草稿淹没。
- 变更文档：版本升级时更新版本号与更新日期，状态按实际阶段调整；若变更影响子文档，同步检查其下规格说明是否需要联动修改，并在备注中注明联动关系。
- 废弃文档：不删除行，将状态改为“已废弃”，在备注中写明替代文档编号，并把原文移动到归档位置后更新存放位置。保留废弃行是目录可追溯的关键。
- 拆分与合并：文档拆分时保留原编号并标注“已拆分至×××”，新文档分配新编号；合并时保留主文档编号，被合并文档标注替代关系。
版本与状态的维护规则建议固定下来：目录只登记当前有效版本，历史版本由文档系统自身保存；状态使用统一枚举，不允许各人自造词；状态变更与版本变更在同一次操作中完成，避免出现“版本已升、状态未改”的错位。可以约定每周由负责人核对一次本人名下条目的更新日期，超过一个月未变动且状态仍为“评审中”的条目，需要在例会上说明进展或调整状态。
字段裁剪按团队实际情况进行：十人以内、单一产品线的团队使用最小可用版本即可，重点保证编号、标题、状态、负责人和存放位置准确；多模块并行、需要与需求池对账的团队增加层级和关联需求；文档需要对外交付或经历多轮评审的团队再启用版本和更新日期。裁剪的原则是每个保留字段都有人实际使用，长期无人查看的列可以合并进备注。
当团队已经在使用ONES管理需求时，目录中的“关联需求”列可以与需求工作项对应起来。ONES Wiki支持页面组关联项目，需求与文档互相对应，文档也可关联项目任务；目录本身可以作为Wiki中的一个页面维护，借助页面树的层级组织和搜索功能定位条目，文档版本变化时通过页面版本记录查看与回滚。这样目录与需求、文档处在同一套协作环境中，状态变更和关联核对可以在同一处完成，减少目录与需求列表脱节的情况。
常见问题
需求文档目录和需求列表、需求池是什么关系？
两者记录的对象不同：需求列表登记的是需求条目本身，目录登记的是承载需求的文档。目录中的“关联需求”列填写需求编号，作用是把文档挂回需求条目，便于从文档找到需求、从需求找到说明文档。若团队尚未使用需求管理工具，这一列可以留空或用“—”占位，先保证编号、标题、状态、负责人和存放位置准确。
文档还在草稿阶段，要不要先登记进目录？
建议在文档通过首次评审后再登记，状态先填“评审中”，确认后改为“已确认”。未评审的草稿频繁变动，提前登记会让目录出现大量无效条目，反而降低检索价值。如果团队需要保留草稿线索，可以在备注中记录，等评审通过再正式分配编号入目录。
同一份PRD拆成多份规格说明后，编号怎么处理？
保留原PRD编号，在备注中写明“已拆分至×××”，新拆出的规格说明各自分配新编号，层级填2，关联需求按实际对应条目填写。这样历史引用仍然指向原编号，读者能顺着备注找到新文档，不会因为编号消失而断链。
目录里的“存放位置”填链接还是填路径？
两种都可以，关键是能从目录一步定位到原文。使用在线文档或知识库时，填页面链接更直接；使用共享文件夹时，填相对路径并保持命名稳定。若文档迁移了位置，需要同步更新这一列，否则目录会指向失效地址。存放位置与关联需求一内一外，两者都填才能完成追溯闭环。
团队已经在用ONES管理需求，目录还需要单独维护吗？
可以继续保留目录作为索引页，把“关联需求”列与需求工作项对应起来。ONES Wiki支持页面组关联项目，需求与文档互相对应，文档也可关联项目任务；目录本身可以作为Wiki中的一个页面维护，借助页面树的层级组织和搜索功能定位条目，文档版本变化时通过页面版本记录查看与回滚。这样目录与需求、文档处在同一套协作环境中，状态变更和关联核对可以在同一处完成。
