需求资产沉淀下来之后，如果没有固定的维护动作，条目会逐渐失效：内容过时、引用断裂、无人认领，最终反而增加查找和判断成本。建立定期评审机制，就是把“哪些资产还值得用、由谁判断、多久看一次、看完怎么处置”变成例行动作。这套机制由范围与分级、评审周期、角色分工、处置与清理四部分构成，下面按搭建顺序展开。
要点总览（TL;DR）
- 先划定纳入评审的四类需求资产（可复用需求条目、需求模板、场景描述、验收要点），再按复用频率与业务影响分A/B/C三级，分别对应季度、半年、年度评审周期。
- 周期采用固定节奏加事件触发：重大版本发布、业务方向调整、连续两个周期无引用，都可提前把受影响资产纳入待议清单。
- 评审由资产管理员发起并跟踪，产品负责人做价值判断，业务代表回答是否用得上，研发代表回答是否对得上，四类角色按资产级别决定参与范围。
- 处置统一为保留、更新、合并、降级、归档失效五类结论，每条记录结论、责任人、完成时间、下次复核时间，失效资产标注原因、解除引用、保留追溯记录。
- 用资产复用次数、长期未引用资产占比、评审决议完成率观察机制健康度，出现待议积压、结论长期为保留、任务无人认领时校准周期或分级标准。
评审机制先定三件事：范围、分级与周期
机制搭建的第一步是划清边界。需求资产的范围如果定得太宽，评审会变成对所有需求文档的普查，难以持续；定得太窄，又会漏掉真正在被复用的内容。建议把以下四类纳入评审范围：可复用需求条目（跨版本、跨项目被引用的需求描述）、需求模板（需求文档结构、字段规范）、场景描述（典型业务场景与用户旅程说明）、验收要点（可复用的验收标准与检查项）。这四类资产的共同特征是会被反复引用，一旦过时就容易误导后续使用。
范围之外要明确一条边界：待处理需求集合（新提出、尚未进入开发的需求）归需求池管理，按优先级排序和排期处理，不进入本文的资产评审机制。两类对象的生命周期不同，混在一起评审会让会议议题失焦。
范围确定后，按复用频率与业务影响做分级。分级的目的不是贴标签，而是让不同资产匹配不同的评审投入。可参考下表：
| 资产级别 | 判定参考 | 评审周期 | 评审深度 |
|---|---|---|---|
| A级：核心复用资产 | 被多个项目或版本引用，涉及核心业务流程 | 每季度一次 | 逐条评审，产品负责人必须参与 |
| B级：常规复用资产 | 有一定引用记录，影响单个业务域 | 每半年一次 | 按批次评审，抽样加重点条目 |
| C级：低频或待观察资产 | 引用少、新沉淀或用途尚不明确 | 每年一次，或触发时评审 | 批量筛查，重点看是否降级或归档 |
周期设定采用“固定周期加事件触发”的组合。固定周期保证机制有稳定节奏，事件触发则处理周期之间的突发变化。建议设置三类触发条件：重大版本发布后（需求内容可能随功能调整而过时）、业务方向调整时（场景描述和验收要点的适用前提变化）、资产长期无人引用（例如连续两个评审周期无引用记录，提前纳入待议清单）。触发评审只针对受影响的资产子集，不必重开全量评审。
这一节的交付物是一份资产范围与分级表：列出纳入评审的资产类型、分级判定标准、各级对应的评审周期和触发条件，经产品负责人确认后作为机制文档的第一部分。
评审会的角色分工与输入材料
评审流于形式，通常是因为角色不清：有人发起但没人决策，有人决策但没人执行。建议设置四类角色，各自职责如下：
| 角色 | 主要职责 | 在评审中的动作 |
|---|---|---|
| 资产管理员 | 维护资产台账，组织评审 | 发起评审、汇总待议清单、记录结论、跟踪处置完成 |
| 产品负责人 | 判断需求内容的复用价值 | 对保留、更新、合并、降级给出业务判断 |
| 业务代表 | 提供实际使用反馈 | 说明资产在业务场景中是否仍然适用 |
| 研发代表 | 提供实现约束 | 指出验收要点、场景描述与当前实现是否一致 |
资产管理员是机制的运转轴心，负责台账的准确性；产品负责人是价值判断的决策者；业务与研发代表提供两类不同的输入——前者回答“还用不用得上”，后者回答“还对不对得上”。四类角色不必每次全员到场，B级、C级资产的批量评审可由资产管理员加产品负责人完成，A级资产评审建议四类角色都参与。
评审前需要准备的材料清单包括：资产台账（含分级、责任人、上次评审时间）、引用与复用记录（哪些项目、文档引用了该资产）、上次评审的处置结果（未闭环事项优先列入本次议程）。材料在评审前两到三个工作日发出，让参与者有时间核对。
议事规则建议明确两点：单次评审的条目上限（例如A级资产不超过三十条，避免会议时间失控），以及决议方式（逐条给出结论并当场指派责任人，无法当场判断的条目记为“待补充信息”，指定补充责任人和下次评审时间，不留在会上反复讨论）。
从评审结论到失效清理的操作步骤
评审结论必须对应具体操作，否则会议记录只是意见集合。建议统一使用五类处置结论，每类结论的输入、动作、输出和完成标志如下表：
| 结论 | 适用情形 | 具体动作 | 完成标志 |
|---|---|---|---|
| 保留 | 内容仍准确、仍被引用 | 更新台账中的评审日期与下次复核时间 | 台账字段回填完成 |
| 更新 | 主体可用，部分内容过时 | 由责任人修订内容，同步检查引用位置的描述是否需调整 | 修订版本发布，引用方确认 |
| 合并 | 多条资产内容重叠 | 确定保留条目，将其他条目的有效内容并入，原条目转为归档并指向合并目标 | 合并后条目通过复核，原条目解除独立引用 |
| 降级 | 引用减少但仍有潜在价值 | 调整资产级别，延长评审周期 | 台账级别与周期同步更新 |
| 归档失效 | 内容过时、场景消失或长期无人引用 | 标注失效原因，保留可追溯记录，解除与其他文档的引用关系 | 状态改为已归档，引用清单清零 |
失效清理是最容易被拖延的环节，操作上分三步：第一，在资产条目上标注失效原因（例如“对应功能已下线”“业务规则已变更”），保留原文以便追溯，不做物理删除；第二，检查并解除引用关系，包括需求文档中的引用、模板中的示例引用、验收要点被其他条目继承的部分，逐处确认替换或移除；第三，通知曾使用该资产的团队，说明替代条目或不再适用的结论。
更新与合并时，关联文档要同步维护。一条需求条目被更新后，引用它的需求文档、场景描述可能仍指向旧版本，需要在处置时一并检查。建议在处置记录中增加“关联引用位置”字段，由责任人逐项确认。
每条处置结果记录四个字段：结论、责任人、完成时间、下次复核时间。这四个字段构成闭环的最小单元，缺任何一项都会导致下次评审时无法判断上次决议是否执行。
当资产台账、处置状态和评审记录分散在多个文档中时，跟踪成本会明显上升。ONES 可以用工作项承载资产条目、用状态字段记录处置结论与完成时间，评审记录以文档形式关联到对应条目，资产管理员在同一处查看待议清单和未闭环事项，减少跨文档核对的工作量。
一个季审示例：从台账到清理完成
以下为演示情景，用于说明一次完整季审的组织方式，不代表特定企业的实际数据。
背景设定：某产品线经过两年迭代，积累了约一百二十条可复用需求条目、若干需求模板和场景描述，其中部分条目已长期无人引用。产品负责人决定启动首次季度评审。
评审前一周，资产管理员从台账导出全部条目，按分级筛选出A级资产约四十条，并筛出连续两个季度无引用记录的条目约十五条，合并为本次待议清单。同时附上每条资产的引用记录和上次评审（如有）的处置结果，提前发给参会人员。
评审会上，按待议清单逐条讨论。产品负责人对每条给出结论：约二十条保留并更新复核时间；八条需要更新内容，当场指派修订责任人；五条内容重叠的条目合并为两条；六条降为C级；剩余条目中，十二条判定为归档失效，原因是相关功能已下线或业务规则变更。每条结论都记录责任人和完成时间，会议控制在两小时内。
会后一周内，责任人完成内容修订和合并操作，资产管理员执行归档：标注失效原因、解除引用、通知相关团队。所有处置结果回填台账，未完成事项标记为待办并注明预计完成时间。
下次评审时，议程第一项是复核上次处置的闭环情况：检查更新条目是否已发布、归档条目的引用是否已清零、待办事项是否按期完成。未闭环事项重新指派责任人，并分析拖延原因，作为校准评审节奏的依据。
机制运转的检查项与持续校准
机制建立后，需要定期检查它是否真的在运转。可按以下清单逐项核对：
- 评审是否按计划周期召开，触发条件出现时是否及时启动专项评审；
- 每次评审的处置结论是否都有责任人和完成时间，是否在约定时间内闭环；
- 归档失效的资产是否完成引用解除，是否还有文档指向已失效条目；
- 台账中的评审日期、级别、下次复核时间是否与实际一致；
- 待议清单是否在评审前按时发出，参会角色是否到位。
观察指标建议聚焦三个：资产复用次数（统计周期内被引用的次数，反映资产是否仍在发挥作用）、长期未引用资产占比（连续两个周期无引用的资产占总量比例，反映沉淀质量）、评审决议完成率（按期闭环的处置条目占全部决议的比例，反映执行力）。这三个指标不需要精确到小数点，趋势比绝对值更有参考意义。
出现以下信号时，说明机制需要校准：待议清单持续积压，单次评审无法消化，应考虑提高评审频率或缩小A级资产范围；评审结论长期集中为“保留”，说明分级标准可能过宽，或评审缺乏实质判断，需要重新审视判定依据；处置任务频繁无人认领，说明责任分配方式需要调整，可改为按业务域固定责任人；触发评审频繁发生，说明固定周期与业务节奏不匹配，应缩短周期或调整触发条件。
机制文档本身也需要维护。建议指定资产管理员为文档维护责任人，每半年或在重大组织调整后修订一次，修订内容包括范围、分级标准、周期规则和角色分工。修订记录随文档保留，便于追溯规则变化的原因。
常见问题
首次评审应该从全量资产开始，还是先选一部分？
建议首次评审先覆盖A级资产和长期未引用条目，形成一次完整闭环后再扩展到B级、C级。全量普查在机制尚未跑通时容易拖长会议时间，也会让参与者难以判断评审的实际价值。首次评审的目标是验证流程：待议清单能否按时发出、结论能否当场指派责任人、会后一周内能否完成处置回填。流程跑顺之后，再按分级表逐步纳入更多资产。
资产长期无人引用，是直接归档还是先降级观察？
取决于该资产是否还有明确的潜在使用场景。如果对应功能已下线、业务规则已变更，或所属业务域已不再规划，可以直接归档失效；如果只是当前阶段引用少，但业务方向仍可能回到该场景，先降为C级并延长评审周期更稳妥。降级时同步更新台账中的级别和下次复核时间，下一个周期仍无引用再归档。两种处理都应在处置记录中写明理由，便于后续追溯判断依据。
评审会上无法当场判断的条目怎么处理？
记为“待补充信息”，当场指定补充责任人和下次评审时间，不留在会上反复讨论。补充责任人需要在两次评审之间收集缺失信息，例如引用方的实际使用反馈、研发侧的实现现状，形成简短说明后提交。下次评审时该条目优先讨论，直接给出处置结论。这样既避免会议时间失控，也防止模糊条目在台账中长期悬置。
评审周期和分级标准多久需要调整一次？
建议每半年或在重大组织调整、业务方向变化后复核一次机制文档。日常运行中出现以下信号时可提前调整：待议清单持续积压、单次评审无法消化，考虑提高频率或缩小A级范围；评审结论长期集中为保留，考虑重新审视分级判定依据；触发评审频繁发生，说明固定周期与业务节奏不匹配。调整内容记入修订记录，说明变化原因，避免规则反复变动而无人知晓。
资产台账和评审记录用什么方式承载比较合适？
关键是让台账、处置状态和评审记录能互相关联，减少跨文档核对。可以用工作项承载资产条目，用状态字段记录处置结论、责任人和完成时间，评审记录以文档形式关联到对应条目。ONES 的工作项与文档关联能力可以支撑这种组织方式，资产管理员在同一处查看待议清单和未闭环事项。具体字段和流程按团队现有工具习惯设计，重点是保证四个记录字段完整、可查询。
