需求文档目录一旦与正文脱节，查找、评审和交接都会失去可靠入口。目录维护需要一套可执行的闭环：明确变更触发条件，按统一字段修订条目，同步正文并评审，归档版本，再用定期巡检清理失效项。下面按操作步骤、字段设计、角色分工、完整示例和检查清单展开。
要点总览（TL;DR）
- 目录维护按“变更触发—目录修订—内容同步—评审确认—归档版本”五步执行，每步明确输入、输出和完成标志。
- 目录条目至少保留需求编号、名称、层级路径、状态、负责人、版本和关联文档链接七项必填字段，名称、状态、版本、链接须与正文一致。
- 需求负责人触发并修订条目，文档作者同步正文，评审人核对一致性，目录管理员负责归档和巡检，代班安排写入流程。
- 每个迭代做一次轻量巡检、每月做一次完整巡检，失效条目、断链、编号重复、状态不一致和必填字段缺失为阻断项。
- 把目录条目更新和必填字段完整纳入需求评审的完成条件，目录维护才能随需求流程持续运转。
目录更新维护的核心做法与操作步骤
目录维护的核心是把“改目录”从个人习惯变成流程动作。建议先确定目录的层级规则和编号规则，再规定哪些变更必须触发目录更新，之后按“变更触发—目录修订—内容同步—评审确认—归档版本”五步执行。每一步都要有明确输入、输出和完成标志，避免改到一半无人接手。
第一步：确定目录层级与编号规则
目录层级建议与需求分解结构保持一致，例如“产品—模块—功能—需求条目”四层，层级深度控制在团队能够快速定位的范围内。编号规则要保证唯一性和可读性，常见做法是“模块代码—序号”，如PAY-014；拆分或合并需求时，原编号保留并标注去向，新条目另起编号，避免历史引用失效。
这一步的输入是现有需求清单和文档结构，动作是梳理层级、分配编号段、形成书面规则，输出是《目录层级与编号规则》一页说明。完成标志是团队内每个需求负责人都能按规则为新需求分配编号，且抽查时不存在重号。
第二步：明确变更触发条件
以下四类变更必须触发目录更新：新增需求、需求内容修改、需求废弃、需求拆分或合并。触发时机建议放在变更被确认之后、正文修改之前，由提出变更的人在需求条目上标注变更类型，需求负责人据此判断目录需要新增、修改还是标注失效。
触发环节的输入是变更申请或评审结论，动作是登记变更类型和影响范围，输出是待处理的目录修订任务。完成标志是每条变更都能对应到一条目录修订记录，没有“改了正文但目录未动”的情况。
第三步：修订目录条目并同步正文
需求负责人按字段要求修订目录条目，文档作者同步修改正文中的需求描述、验收标准和关联链接。两者可以并行，但必须以同一份变更结论为依据，避免目录写“已拆分”而正文仍是旧版本。
这一步的输入是变更结论和现行目录，动作是更新条目字段、调整层级位置、补充或替换文档链接，输出是修订后的目录和同步后的正文。完成标志是目录条目中的名称、状态、版本与正文一致，链接可以正常打开。
第四步：评审确认
评审人对照目录和正文逐项核对：条目是否完整、编号是否唯一、状态是否准确、链接是否指向当前版本。评审可以并入需求评审会，也可以单独设置目录核对环节，关键是形成书面确认记录。
输入是修订后的目录与正文，动作是逐项核对并记录差异，输出是评审结论和遗留问题清单。完成标志是评审通过，或遗留问题已明确责任人和处理期限。
第五步：归档版本
评审通过后，将目录和正文作为同一版本归档，记录版本号、归档日期和变更摘要。归档不是简单保存文件，而是让后续使用者能判断“当前有效版本是哪一份”。
输入是评审通过的目录与正文，动作是打版本标签、填写变更摘要、替换旧版本入口，输出是可追溯的版本记录。完成标志是新版本可被检索到，旧版本标注为历史版本且不再作为引用依据。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 确定规则 | 现有需求清单、文档结构 | 梳理层级、分配编号段、形成规则说明 | 目录层级与编号规则 | 新需求可按规则分配唯一编号 |
| 变更触发 | 变更申请或评审结论 | 登记变更类型与影响范围 | 目录修订任务 | 每条变更对应一条修订记录 |
| 修订同步 | 变更结论、现行目录 | 更新条目字段、同步正文、替换链接 | 修订后目录与正文 | 目录与正文名称、状态、版本一致 |
| 评审确认 | 修订后目录与正文 | 逐项核对、记录差异 | 评审结论、遗留问题清单 | 评审通过或问题已指派 |
| 归档版本 | 评审通过的目录与正文 | 打版本标签、填写变更摘要 | 版本记录 | 新版本可检索，旧版本标注历史 |
当需求条目和文档分散在不同工具中时，目录维护容易变成人工对账。ONES 的需求管理与文档管理可以把需求条目状态、负责人和关联文档放在同一工作项下，变更后由需求负责人更新条目、文档作者同步正文，评审记录和版本信息随工作项留存，减少目录与正文各改各的情况。是否采用工具承载，取决于团队现有的需求条目数量和文档分布。
目录条目该包含哪些字段
目录条目要能独立回答“这是什么需求、在哪一层、当前什么状态、找谁、看哪份文档”。字段设计宜少而稳定，必填字段保证可核对，选填字段补充追溯信息。字段过多会增加维护负担，过少则无法支撑评审和巡检。
| 字段名 | 说明 | 必填/选填 | 示例 |
|---|---|---|---|
| 需求编号 | 全局唯一，按编号规则分配，拆分合并时保留原号并标注去向 | 必填 | PAY-014 |
| 需求名称 | 与正文标题一致，使用业务可读的短名称 | 必填 | 支付结果页增加退款入口 |
| 层级路径 | 从产品到当前条目的完整路径，便于定位和排序 | 必填 | 支付产品/收银台/结果页 |
| 状态 | 草稿、评审中、已确认、开发中、已上线、已废弃 | 必填 | 已确认 |
| 需求负责人 | 对该条目内容和状态负责的人 | 必填 | 张三 |
| 版本 | 条目当前对应的文档版本号 | 必填 | V1.2 |
| 关联文档链接 | 指向当前有效正文的位置，废弃条目保留历史链接 | 必填 | 需求文档-支付结果页 |
| 变更类型 | 新增、修改、废弃、拆分、合并 | 选填 | 修改 |
| 上游来源 | 业务方、工单号或原始需求记录 | 选填 | 客服工单 #2210 |
| 最后更新日期 | 条目最近一次修订时间，用于巡检判断陈旧程度 | 选填 | 2025-03-18 |
字段与正文的对应关系要写清楚：名称、状态、版本、链接必须与正文一致；层级路径决定条目在目录中的位置；变更类型和上游来源用于追溯，不要求正文重复。必填字段缺失时，条目不应进入评审通过状态，这是后续检查清单的判断依据。
角色分工与各角色交付物
目录维护无人负责，通常是因为触发、修订、评审、巡检四个动作没有落到具体角色。建议至少明确四类角色：需求负责人、文档作者、评审人、目录管理员（可由配置管理员兼任）。小团队可以一人兼多角，但每个动作仍要有明确的责任人。
| 角色 | 流程节点 | 主要动作 | 交付物 |
|---|---|---|---|
| 需求负责人 | 变更触发、目录修订 | 确认变更类型，修订条目字段，判断层级位置 | 变更记录、修订后的目录条目 |
| 文档作者 | 内容同步 | 按变更结论修改正文、验收标准和关联链接 | 同步后的需求文档 |
| 评审人 | 评审确认 | 核对目录与正文一致性，记录差异 | 评审结论、遗留问题清单 |
| 目录管理员 | 归档、定期巡检 | 打版本标签、维护目录结构、执行巡检并登记问题 | 版本记录、巡检报告、问题处置记录 |
职责交接要写进流程：需求负责人休假或转岗时，由目录管理员指定代班人，代班人承接未完成的目录修订任务；评审人不能由本次变更的文档作者单独担任，至少增加一名核对人。交接时以目录条目和变更记录为准，口头说明不作为交接依据。
一个需求变更的目录维护示例
以下为演示情景，用于说明流程如何落地，不代表真实项目数据。
示例背景：支付产品“收银台结果页”原需求PAY-014描述退款入口位于订单详情页。业务方提出将退款入口前移到支付结果页，变更类型为“修改”，影响范围包括结果页正文、交互说明和关联的验收标准。
按步骤执行
- 需求负责人在变更确认后登记变更类型为“修改”，影响条目为
PAY-014，形成目录修订任务。 - 需求负责人修订条目：名称改为“支付结果页增加退款入口”，状态改为“评审中”，版本由V1.1升为V1.2，层级路径保持“支付产品/收银台/结果页”。
- 文档作者同步正文：更新入口位置描述、补充异常场景说明、调整验收标准，并把正文中的旧链接替换为新版本。
- 评审人核对条目名称、状态、版本与正文一致，确认链接可打开，记录一条遗留问题“退款失败提示文案待确认”，指派给文档作者。
- 问题关闭后，目录管理员打V1.2版本标签，填写变更摘要“退款入口前移至结果页”，旧版本标注为历史版本。
目录条目修改前后对比
| 字段 | 修改前 | 修改后 |
|---|---|---|
| 需求名称 | 订单详情页退款入口 | 支付结果页增加退款入口 |
| 状态 | 已上线 | 评审中，通过后改为已确认 |
| 版本 | V1.1 | V1.2 |
| 关联文档链接 | 指向V1.1正文 | 指向V1.2正文 |
| 变更类型 | 空 | 修改 |
评审与归档结果是：目录条目与正文在名称、状态、版本上一致，遗留问题关闭后完成归档，V1.1保留为历史版本供追溯。整个过程的关键在于变更结论只有一份，目录和正文都从这份结论出发修改。
定期巡检与完成检查清单
日常更新解决“改了有没有同步”，定期巡检解决“长期有没有积压”。建议每个迭代结束做一次轻量巡检，每月做一次完整巡检，由目录管理员执行，需求负责人配合确认。巡检结果要记录，发现的问题要指派责任人和处理期限。
巡检检查清单
| 检查项 | 检查方法 | 通过标准 | 是否阻断 |
|---|---|---|---|
| 失效条目 | 核对状态为“已废弃”的条目是否仍被正文或下游引用 | 废弃条目已标注去向，无有效引用 | 是 |
| 断链 | 逐条打开关联文档链接 | 必填链接全部可访问且指向当前版本 | 是 |
| 编号重复 | 按编号排序检查重号 | 不存在重复编号 | 是 |
| 状态不一致 | 抽查目录状态与正文标注状态 | 抽查条目全部一致 | 是 |
| 必填字段缺失 | 筛选必填字段为空的条目 | 无缺失，或缺失项已登记处理 | 是 |
| 陈旧条目 | 查看最后更新日期超过约定周期的条目 | 陈旧条目已确认仍有效或已更新 | 否 |
| 层级错位 | 抽查条目是否位于正确层级路径下 | 错位条目已调整或登记 | 否 |
阻断项未清零时，本轮巡检判定为不通过，目录管理员需在问题记录中写明条目、问题类型、责任人和期限，并在下一轮巡检中复核。非阻断项可以限期整改，但连续两轮未处理的，升级为阻断项。巡检记录建议保留最近三轮，便于观察目录质量趋势。
把目录维护纳入需求评审的完成条件，是让这套机制持续运转的关键：评审时目录条目未更新或必填字段缺失，评审不予通过。这样目录维护就不再依赖个人自觉，而是跟着需求流程一起走。
常见问题
需求拆分或合并后，原目录条目应该删除还是保留？
建议保留原条目并标注去向，新条目另起编号。删除原编号会让历史文档、评审记录和下游引用失去指向，后续追溯时无法判断旧需求去了哪里。具体做法是把原条目状态改为“已废弃”或“已拆分”，在条目中写明拆分后的新编号或合并目标，关联文档链接保留历史版本入口。巡检时重点核对废弃条目是否仍被有效正文引用，有引用就说明正文尚未同步。
团队规模小、一人兼多角时，目录维护流程可以简化到什么程度？
可以合并角色，但触发、修订、评审、归档四个动作仍要有人负责。小团队常见做法是需求负责人同时承担目录修订，文档作者与需求负责人为同一人，评审环节保留一名独立核对人，目录管理员由配置管理员或项目负责人兼任。简化的是人手，不是检查点：评审时目录条目未更新或必填字段缺失，仍应判定评审不通过。若连独立核对人都难以安排，可改为交叉核对，由另一名需求负责人抽查。
目录条目和正文分别由不同的人维护，怎么避免两边改得不一致？
关键是让目录修订和正文同步依据同一份变更结论，并在评审时逐项核对名称、状态、版本和链接。操作上可以约定：变更结论确认后先登记目录修订任务，需求负责人和文档作者从同一份结论出发分别修改，评审人对照两者核对差异并记录遗留问题。目录条目中的版本字段要与正文版本号保持一致，链接指向当前有效版本。若两边长期由不同人维护，建议在流程中增加一次同步确认动作，由需求负责人在提交评审前确认正文已同步。
巡检发现阻断项后，本轮巡检还能算通过吗？
不能。阻断项未清零时本轮巡检判定为不通过，目录管理员需在问题记录中写明条目、问题类型、责任人和处理期限，并在下一轮巡检中复核。非阻断项可以限期整改，连续两轮未处理的升级为阻断项。巡检记录建议保留最近三轮，便于观察目录质量变化。若阻断项集中在某一模块，可先冻结该模块的新增引用，待修复后再恢复，避免错误条目继续扩散。
目录维护要不要等需求全部确认后再统一做一次？
不建议集中到最后统一处理。需求变更在确认后、正文修改前触发目录更新，目录和正文才能同步推进；积压到阶段末统一修订，容易出现变更结论丢失、责任人不清晰的情况。对于批量导入的历史需求，可以安排一次集中建目作为起点，之后转入按变更触发的日常维护。集中建目时同样要按字段要求补齐必填项，并标注哪些条目属于历史遗留、需要后续巡检重点核对。
