需求文档过期，通常指文档内容与当前需求、实现或评审结论不一致，读者按旧信息行动就会产生返工。处置时先界定哪些文档、哪些字段已失效，再查清过期原因，按影响面分级更新或作废，最后做一致性核对并建立变更触发机制。本文围绕这条路径展开，涉及文档内容维护，不讨论一般文档协同权限与AI生成文档。
要点总览（TL;DR）
- 需求文档过期指内容与当前需求、实现或评审结论不一致；先按“谁在按文档行动”分级，影响开发测试执行或对外承诺的优先处理。
- 原因排查按“变更事实—回写动作—责任与机制”推进，用变更记录、评审纪要、版本历史和责任人字段验证，避免把单次漏回写与机制缺口混为一谈。
- 高影响文档先冻结引用再更新正文并通知受影响角色；中低影响文档标注过期、限期更新或合并作废，覆盖旧版本前保留历史，作废前确认无下游引用。
- 更新后与需求记录、测试用例、评审结论逐项核对，由责任人和主要引用方共同确认；把文档回写挂到需求变更和评审结论上，配合定期一致性巡检防止复发。
先判断：哪些“过期”需要处理
判断需求文档是否过期，看的是内容一致性：文档描述的需求范围、流程、字段、规则、验收标准，与当前需求记录、已实现功能或最新评审结论是否对得上。对不上就是内容过期，需要进入处置流程。文档打不开、协作编辑冲突、访问权限不足属于协同与权限问题，按对应流程处理，不纳入本文的过期处置。
过期的典型症状可以对照以下清单识别：
- 文档描述的功能范围或业务规则与当前需求记录不一致，开发按文档实现后与预期不符。
- 评审中已确认的修改结论停留在会议记录或聊天里，没有写回文档正文。
- 上下游文档、测试用例、接口说明仍引用旧版本的需求编号、字段定义或流程步骤。
- 文档中存在多个并行版本，读者无法判断哪一版是当前有效版本。
- 文档长期无人维护，责任人已转岗或离职，内容停留在数月前的状态。
识别出症状后，按影响面分级，决定处置优先级：
| 影响级别 | 判断口径 | 处置优先级 |
|---|---|---|
| 高影响 | 文档直接指导开发、测试执行，或支撑对外承诺、合同交付、客户沟通 | 立即处理，先控制引用再更新 |
| 中影响 | 文档被其他团队引用作为输入，但短期不直接触发开发或对外动作 | 限期更新，期间标注过期状态 |
| 低影响 | 仅用于阅读参考、背景了解，无下游依赖 | 标注过期、合并或作废 |
分级时以“谁在按这份文档行动”为准，而不是以文档篇幅或重要程度的主观感受为准。一份简短但被测试团队直接引用的字段说明，影响级别可能高于一份长篇的背景介绍。
过期原因排查：假设与验证证据
文档过期是结果，原因需要证据支撑。排查时先列出可能的原因假设，再为每类假设找到可查的记录，避免凭印象下结论。常见原因假设与对应验证证据如下：
| 原因假设 | 验证证据 | 确认后的含义 |
|---|---|---|
| 需求变更未回写文档 | 需求变更记录、变更单、需求状态流转历史，与文档最后修改时间对比 | 变更真实发生，文档未同步 |
| 评审结论未落地 | 评审纪要、评审意见条目，逐条核对文档正文是否体现 | 结论已达成，回写动作缺失 |
| 多版本并行分叉 | 版本历史、副本或分支文档、各版本修改人 | 存在多个有效版本，读者取用混乱 |
| 责任人缺位 | 文档责任人字段、交接记录、最近一次维护人 | 无人对内容准确性负责 |
| 模板字段缺失 | 文档模板与实际填写内容对比，检查关键字段是否留空或沿用旧值 | 结构上缺少必须维护的信息项 |
排查顺序建议按“变更事实—回写动作—责任与机制”推进。第一步确认变更是否真实发生：查需求变更记录和状态流转，确认需求确实改过，而不是文档写错。第二步确认回写动作是否执行：查文档版本历史和评审纪要，看变更发生后文档是否有对应修订。第三步确认责任与机制：查文档责任人字段和交接记录，判断是个人疏忽还是流程缺位。这个顺序的价值在于，先排除“需求其实没变、只是文档写错”的情况，避免把内容错误误判为同步问题。
排查中要区分两类结论：一类是单次事件，例如某次变更漏了回写，处置时补齐内容并提醒即可；另一类是机制性缺口，例如文档没有责任人、变更流程不包含文档更新环节，这类需要调整流程，否则同类过期会反复出现。证据不足时，把假设标注为待验证，继续收集记录，不把猜测写成原因结论。
按影响分级处置：更新、作废与通知
确认过期范围和原因后，按影响级别执行处置。高影响文档的处理顺序是：先冻结引用，再更新正文，最后同步通知受影响角色。冻结引用的具体动作包括在文档顶部标注“内容更新中，暂勿引用”、通知正在按该文档开发的团队暂停相关实现、在测试用例和接口说明中标记待核对。更新正文时以当前需求记录和最新评审结论为准，逐项修订，不整篇重写，保留可追溯的修改说明。更新完成后通知开发、测试、上下游文档维护人，说明变更点和生效时间。
中低影响文档可以标注过期状态、限期更新或合并作废。标注过期状态时写明过期原因和预计更新日期；限期更新适合内容仍有价值但需要修订的文档；合并作废适合内容已被其他文档覆盖、或需求本身已取消的情况。作废时保留文档入口并注明“已作废，替代文档为××”，方便历史引用者找到去向。
处置中有两类破坏性操作需要交代风险边界：
- 覆盖旧版本前保留历史版本。直接覆盖会让排查失去依据，也无法在更新出错时回退。使用支持版本记录的文档工具时，确认历史版本可查看、可回滚后再修订正文。
- 作废前确认无下游引用。检查测试用例、接口文档、外部交付材料是否引用该文档，确认引用方已切换或不再依赖后再执行作废。
在文档与需求同处一个研发管理平台的情况下，处置动作可以更连贯。ONES Wiki 的页面组可关联项目，使需求与文档互相对应，更新时能直接对照需求记录核对内容；文档实时同步并记录所有页面版本，支持随时查看与回滚，覆盖旧版本前有历史可查；误删除的页面可从回收站恢复。这些能力服务于“先保留历史、再修订正文”的处置要求，具体使用方式以团队实际配置为准。
验证恢复与防止再次过期
更新完成不等于恢复完成，需要做一致性核对。核对清单可以按以下条目执行：
- 文档描述的需求范围、流程、字段、规则与当前需求记录逐项对应，无遗留旧值。
- 文档中的验收标准与测试用例一致，测试团队确认可按文档执行。
- 评审纪要中的每条结论都能在文档正文找到对应修订。
- 上下游文档、接口说明中的引用已切换到新版本，旧版本链接已标注失效或指向新版本。
- 文档版本历史中保留本次修订记录，修改说明可追溯。
核对完成后，由文档责任人和主要引用方共同确认，确认记录写入文档或评审记录，作为恢复完成的标志。
防止再次过期，重点是把文档更新挂到需求变更的动作上，而不是依赖定期想起来检查。可落地的机制包括：需求变更流程中增加“关联文档更新”环节，变更单关闭前确认文档已回写；评审结论形成后直接转化为文档修订任务，指定责任人和完成时间；按固定节奏做一致性巡检，例如每个迭代结束前抽查高影响文档与需求记录是否一致。责任与节奏要写清楚：每份需求文档有明确责任人，责任人变更时同步更新字段并交接；巡检时点、抽查范围和异常上报路径在团队内约定。
在工具层面，ONES Wiki 提供页面模板库，可一键创建制式化文档模板，把需求编号、责任人、版本、变更记录等字段固化进模板，减少字段缺失导致的过期；页面组关联项目后，需求与文档保持对应，巡检时可按项目逐项核对。ONES Assistant 围绕 PRD 质量检查和需求智能生成，可提炼要点、待澄清问题与拆解建议，帮助团队在需求澄清阶段发现文档中的模糊表述，这类检查作为人工确认的辅助，不替代责任人对文档内容的最终确认。机制能否持续，取决于变更流程是否真正包含文档回写环节，以及责任人是否在每次变更后被触发行动。
常见问题
需求文档只是措辞不清楚、内容本身没错，算过期吗？
这类情况按内容错误处理，与过期分开。过期指文档描述与当前需求、实现或评审结论不一致，措辞不清属于表达质量问题，处置动作是澄清和修订表述。两者可以同时出现在一份文档里，排查时先确认事实是否变化，再决定是补同步还是改表述，避免把写错当成变更漏回写。
需求已经取消，文档应该删除还是作废？
优先作废并保留入口，注明“已作废”和替代文档或取消说明。直接删除会让历史引用者失去线索，测试用例、接口说明和外部交付材料中的引用也无法追溯。作废前确认没有下游仍在依赖该文档；确认后保留文档与版本历史，比删除更利于后续排查。
团队人少、变更不频繁，还需要建文档回写机制吗？
可以简化，但至少保留两个动作：需求变更关闭前确认关联文档已更新，每份需求文档有明确责任人。人少时靠口头同步容易漏，把回写作为变更流程的一个确认项，成本不高。定期巡检的节奏可以放长，例如每个迭代或每月抽查高影响文档，按团队实际变更频率约定即可。
用 ONES Wiki 管理需求文档，处置过期时哪些能力可以直接用上？
ONES Wiki 的页面组可关联项目，需求与文档互相对应，更新时能直接对照需求记录核对内容；文档实时同步并记录所有页面版本，支持随时查看与回滚，覆盖旧版本前有历史可查；误删除的页面可从回收站恢复。页面模板库可一键创建制式化模板，把需求编号、责任人、版本、变更记录等字段固化进模板，减少字段缺失导致的过期。具体配置以团队实际使用为准。
一致性巡检多久做一次比较合适？
按变更频率和文档影响面定。变更频繁、文档直接指导开发测试的团队，可以在每个迭代结束前抽查高影响文档；变更较少的团队按月或按季度巡检即可。巡检范围优先覆盖被下游引用的字段说明、接口说明和验收标准，发现问题记录到责任人并限期修订，巡检结果作为流程调整的依据。
