项目经验库的分类要围绕“以后谁会来查、按什么线索查”来设计：先按项目类型或业务领域建立主干目录，再用经验类型标签区分复盘、问题处置、方案决策和模板工具，辅以阶段、角色、客户、技术栈等可筛选属性，形成“目录+标签+属性”的三层结构。维护则拆成入库、评审、更新、归档四个动作，明确责任人和完成标志，并把触发点嵌入项目结项、问题关闭等既有节点。下面按分类框架、维护流程、角色分工、完整示例和检查清单依次展开。
要点总览（TL;DR）
- 项目经验库采用“主干目录+经验类型标签+可筛选属性”三层结构：主干目录按项目类型或业务领域二选一，经验类型标签区分复盘总结、问题处置、方案决策、模板工具，属性字段只保留能稳定填写且确有筛选需求的项。
- 维护流程拆为入库、评审、更新、归档四个动作，每个动作明确输入、做法、输出和完成标志，触发点嵌入项目结项、问题关闭等既有节点。
- 角色分工按经验贡献者、领域负责人、知识库管理员、使用者划分，各自对应可交付物，避免维护责任悬空。
- 一条项目经验从结项材料到可检索条目，需经过分类归属判断、标准结构撰写、评审与标签补全、入库后检索入口设置和后续更新触发。
- 用分类检查与维护检查两组清单逐项核对，并以条目无人检索、标签膨胀、长期未复核作为失效信号，优先修正触发点和责任人再调整结构。
项目经验库的分类框架怎么搭
分类框架的目标是让一个没参与过该项目的人，在几分钟内找到与当前问题相关的经验。实现这一点靠三层结构分工：主干目录解决“这条经验属于哪个业务范围”，经验类型标签解决“它是什么性质的经验”，属性字段解决“在什么条件下适用”。三层各管一件事，维度不重复堆叠，检索时才能逐层收窄。
主干目录：按项目类型还是业务领域划分
主干目录承担稳定归属，一条经验只能落在一个主目录下。两种划分方式各有适用条件：
- 按项目类型划分，适合项目形态差异大、交付模式相对固定的团队，例如实施交付类、定制开发类、内部平台建设类。优点是同类项目的经验天然聚在一起，复盘时容易横向对照。
- 按业务领域划分，适合业务线清晰、同一领域反复做项目的组织，例如零售、制造、金融等方向。优点是业务人员按自己的领域就能找到入口，不必先理解项目分类。
两种方式不必二选一，但主干目录只保留一层主维度，另一维度降为属性字段。判断标准是：团队里多数人找经验时，第一反应是“我做的这类项目”还是“我这个业务方向”。目录层级建议控制在两到三层，超过三层后，多数人会改用搜索而不是逐层点开。
经验类型标签：常见取值
经验类型标签跨目录使用，让不同主目录下性质相同的经验能被一起检索。常见取值有四类：
| 标签 | 收录内容 | 典型检索场景 |
|---|---|---|
| 复盘总结 | 项目整体或阶段性的得失分析、改进项 | 新项目启动前了解同类项目的坑 |
| 问题处置 | 具体故障、冲突、风险的排查过程与解法 | 遇到相似问题时找处置路径 |
| 方案决策 | 关键技术选型、架构方案、商务策略的取舍理由 | 做类似决策时参考当时的约束和结论 |
| 模板工具 | 可复用的文档模板、检查表、脚本、配置 | 直接取用，减少重复制作 |
标签集要封闭管理，新增标签需经知识库管理员确认，避免同义标签并存，例如“复盘”“总结”“项目回顾”同时存在会让检索失效。
属性字段：能筛选、能稳定填写
属性字段的选取原则只有两条：确有筛选需求，且提交人能稳定填写。常见字段包括项目阶段、承担角色、客户或行业、技术栈、适用项目规模。字段数量控制在五到八个，每个字段给出固定选项而非自由填写，否则同一含义会出现多种写法，筛选形同虚设。无法稳定填写的字段，例如“经验价值评分”，不适合作为入库必填项。
把上述结构整理成一份可直接讨论的草案：
| 层级 | 内容 | 填写要求 |
|---|---|---|
| 主干目录（一级） | 按项目类型或业务领域，二选一 | 必填，单选 |
| 主干目录（二级） | 按子类型或细分领域 | 必填，单选 |
| 经验类型标签 | 复盘总结 / 问题处置 / 方案决策 / 模板工具 | 必填，可多选但不超过两个 |
| 属性字段 | 项目阶段、角色、客户/行业、技术栈、项目规模 | 必填三到五项，选项固定 |
从入库到归档：维护流程的四个关键动作
维护流程要回答的是：经验什么时候进来、谁来确认它可信、什么时候需要更新、什么时候该下架。四个动作各自有输入、做法、输出和完成标志，触发点尽量挂在项目结项、问题关闭这类已有节点上，减少额外发起流程的次数。
| 动作 | 输入 | 做法 | 输出 | 完成标志 |
|---|---|---|---|---|
| 入库 | 结项材料、问题记录、方案文档、原始数据 | 在项目结项或问题关闭时，由贡献者按标准条目结构提交，至少包含背景、做法、结果、适用条件四项 | 一条待评审的经验条目 | 条目已提交且必填字段完整 |
| 评审 | 待评审条目及原始材料 | 领域负责人核对事实准确性、结论是否有材料支撑、分类归属是否合理；一般条目在五个工作日内完成 | 通过、退回补充或合并到已有条目 | 条目状态变为已发布，分类与标签确认 |
| 更新 | 已发布条目、使用反馈、相关项目新进展 | 定期复核按季度或半年批量进行；事件驱动更新在同类项目再次发生、方案被推翻、工具版本变化时触发 | 修订后的条目及版本记录 | 复核记录留痕，修订内容可追溯 |
| 归档 | 长期未更新、适用条件已消失的条目 | 复核时判定过期，移入归档区并标注失效原因，保留可查但不进入默认检索结果 | 归档条目清单 | 条目状态为已归档，主目录中不再展示 |
入库门槛是这套流程能否持续的关键。门槛过低会积累大量只有结论没有依据的条目，门槛过高则没人愿意提交。可操作的做法是设“最低完整度”：背景、做法、结果、适用条件缺一不可，其余细节允许后续补充。评审环节只判断准确性和归属，不承担改写义务，避免评审人变成代笔人。
更新环节要区分两种节奏。定期复核解决“内容老化”，按固定周期抽查或全量检查；事件驱动更新解决“结论被推翻”，由使用者或领域负责人在触发事件发生时发起。归档不是删除，保留历史条目有助于解释“为什么当时那样做”，但要在检索入口上明确区分现行有效与已归档。
在工具承载上，经验条目需要稳定的存放位置、统一的条目模板和可追溯的修改记录。ONES Wiki 支持页面树组织项目文档与知识信息，页面组可关联项目，并提供页面模板库用于创建制式化文档；文档记录所有页面版本，支持查看与回滚。将经验条目的标准结构做成模板，评审意见和修订过程留在页面版本中，可以让上述四个动作有据可查。评审流转与归档状态的具体管理方式，需结合团队实际配置确认。
角色分工与各环节交付物
维护责任悬空通常源于角色定义模糊：大家都觉得经验库该维护，但没人对具体条目负责。按四类角色划分职责，每类角色对应明确的交付物，责任就能落到条目上。
| 角色 | 职责边界 | 交付物 |
|---|---|---|
| 经验贡献者 | 项目结项或问题关闭时提交经验，提供原始材料，对事实描述负责 | 符合标准结构的经验条目、支撑材料（会议记录、数据、文档链接） |
| 领域负责人 | 判断内容准确性与分类归属，决定通过、退回或合并 | 评审意见、最终分类与标签确认 |
| 知识库管理员 | 维护目录结构与标签集，处理重复条目，执行归档，统计入库与复核情况 | 目录与标签变更记录、去重与合并记录、归档清单 |
| 使用者 | 按需检索并应用经验，反馈失效内容或补充新场景 | 失效反馈、适用条件补充说明 |
领域负责人是这套分工里最容易被忽略的角色。如果评审全部压给知识库管理员，管理员既没有业务判断力，也会成为流程瓶颈。领域负责人按主干目录分配，一个目录对应一到两名负责人，人员变动时同步交接。使用者的反馈渠道要足够短，例如在条目页面直接留言或提交修订建议，否则失效信息传不回来，更新动作就失去输入。
示例：一次项目结项经验如何进入经验库
以下为演示情景，用于说明分类与维护动作如何衔接，不指向具体真实项目。
背景。某实施项目在数据迁移阶段出现两次返工，原因是源系统字段口径在启动阶段未确认。项目按期上线，但迁移工时超出预估约三成。结项会上，项目经理提出把这段经历沉淀下来。
分类归属判断。该项目属于实施交付类，主干目录落在“实施交付 / 数据迁移”下。经验性质是问题处置，因为核心内容是发现问题和解决路径；同时涉及启动阶段的检查缺失，可加“复盘总结”作为第二标签。属性填写：阶段为启动与实施，角色为项目经理与实施顾问，行业为制造，技术栈为关系型数据库迁移。
条目正文结构。背景部分写明项目类型、迁移规模和返工发生的时点；做法部分写清两次返工的具体原因、当时如何发现、最终采用的字段口径确认方式；结果部分给出工时偏差和上线结果；适用条件部分说明该做法适用于源系统文档不全、多方系统并存的迁移场景，源系统文档完备时可直接沿用既有清单。
评审与标签补全。领域负责人在评审时确认了工时数据有结项报告支撑，将“复盘总结”标签调整为可选，理由是条目主体是处置过程；同时补充了“数据迁移检查表”作为关联模板。条目状态变为已发布。
检索入口与后续更新。条目发布后，从“实施交付 / 数据迁移”目录可进入，也可通过“问题处置”标签和“制造行业”属性筛出。半年后同类项目再次启动，使用者发现源系统类型不同，字段确认方式需要调整，于是在条目下提交补充说明，领域负责人据此发起一次事件驱动更新，修订后的版本保留在页面历史中。
分类与维护的完成检查
机制是否可用，可以用下面两组检查项逐条核对。检查不追求一次全部达标，但每项都应有明确的当前状态和改进行动。
分类检查
- 主干目录层级不超过三层，每条经验有且只有一个主目录归属。
- 经验类型标签集已封闭，不存在同义标签并存，新增标签有确认记录。
- 属性字段全部为固定选项，抽查十条条目，同一含义的填写方式一致。
- 随机抽取三个真实检索问题，能在三步操作内定位到相关条目。
维护检查
- 入库门槛已书面化，抽查近期条目，背景、做法、结果、适用条件四项齐全。
- 评审有明确负责人和时限，近期条目能查到评审记录与完成时间。
- 定期复核有排期和执行记录，事件驱动更新有触发记录。
- 归档条目有失效原因标注，且不出现在默认检索结果前列。
常见失效信号
出现以下情况时，说明分类或维护机制需要调整：条目持续增加但检索和引用很少，通常是分类线索与实际查找方式不匹配；标签数量快速膨胀，说明标签集缺少准入控制；大量条目超过复核周期未更新，说明复核责任没有落到人；同一主题存在多条内容相近的条目，说明入库前缺少查重和合并动作。发现信号后，优先修正触发点和责任人，再调整结构，避免频繁改目录导致历史条目归属混乱。
常见问题
项目经验库的主干目录应该按项目类型还是业务领域划分？
两种方式各有适用条件。项目形态差异大、交付模式相对固定的团队，按项目类型划分更便于同类项目横向对照；业务线清晰、同一领域反复做项目的组织，按业务领域划分更贴近业务人员的查找习惯。主干目录只保留一层主维度，另一维度降为属性字段。判断标准是团队多数人找经验时的第一反应：是“我做的这类项目”还是“我这个业务方向”。目录层级建议控制在两到三层。
经验条目入库后长期没人检索，应该先改分类还是先改维护流程？
建议先检查触发点和责任人，再考虑调整分类结构。条目持续增加但检索和引用很少，常见原因是分类线索与实际查找方式不匹配，也可能是入库时缺少查重和合并，导致同一主题存在多条相近条目。可以先抽查近期条目，看使用者实际用什么词、从哪个入口找经验，再判断是目录归属问题还是标签和属性字段设置问题。频繁改目录会让历史条目归属混乱，调整前应确认问题根源。
评审环节应该由领域负责人还是知识库管理员负责？
评审的内容准确性和分类归属应由领域负责人判断，知识库管理员负责目录结构、标签集、去重和归档执行。如果评审全部压给管理员，管理员缺少业务判断力，也容易成为流程瓶颈。领域负责人按主干目录分配，一个目录对应一到两名负责人，人员变动时同步交接。评审只判断准确性和归属，不承担改写义务，避免评审人变成代笔人。
定期复核和事件驱动更新分别适合什么情况？
定期复核解决内容老化问题，按季度或半年批量进行，适合检查条目中的结论、工具版本、适用条件是否仍然成立。事件驱动更新解决结论被推翻的问题，在同类项目再次发生、方案被推翻、工具版本变化时触发，由使用者或领域负责人发起。两种节奏可以并存：定期复核保证覆盖面，事件驱动更新保证时效性。复核和修订记录需要留痕，便于追溯。
归档后的经验条目还能被查到吗？
归档不是删除。过期条目移入归档区并标注失效原因，保留可查，但不进入默认检索结果，主目录中也不再展示。这样既能让使用者区分现行有效与已归档内容，也能解释“为什么当时那样做”。归档判定在复核时完成，归档条目清单由知识库管理员维护。
