专家经验分享要产生复用价值，关键在于把专家头脑中的判断过程转成带场景、条件和反例的结构化条目，再放回具体工作环节接受使用检验。本文按选题选人、访谈提取、结构化整理、评审挂载、复用验证的顺序展开，并给出条目模板、角色分工和一份端到端示例，帮助团队把一次分享做成可重复执行的机制。
要点总览（TL;DR）
- 先按业务影响、复用频次、人员流失风险筛出值得沉淀的经验主题，并确认专家有成熟且可表达的做法，形成待分享主题清单。
- 访谈前准备背景材料与关键事件清单，提纲围绕做法、判断依据、适用条件、失败与例外四类问题追问，产出保留原话和数字的访谈记录稿。
- 把素材整理成含场景、问题、做法、判断依据、适用边界、反例六个字段的条目，区分事实与个人偏好，标题按使用者可能的检索词来写。
- 评审分同行评审与技术负责人评审两层，通过后把条目挂载到需求、设计、评审、故障处理等实际环节，并写明由谁在什么环节引用。
- 判断分享是否完成，看未参与访谈的同事能否独立引用条目并产生可观察结果；条目长期无人引用或专家离职后无人确认，都是需要回到选题与评审环节的信号。
先定分享什么：经验主题筛选与专家选择
专家经验分享常见的失败起点是“请专家随便讲讲”。主题过于宽泛，访谈容易变成个人经历回顾，听众难以带走可用的做法。启动前先做一次主题筛选，把有限的访谈时间投向最值得沉淀的经验。
筛选可以从三个维度打分：业务影响，即该经验出错的代价有多大；复用频次，即同类问题在团队中多久出现一次；人员流失风险，即掌握该经验的人是否集中、是否难以替代。三项都高的主题优先安排。反过来，一次性项目中的特殊处理、依赖外部不可控条件的做法，可以降低优先级。
选人时除了看资历，更要判断经验是否成熟且可表达。可用的判断信号包括：专家在该领域有多次成功和失败经历，能说清“当时为什么这样选”，能指出做法在什么情况下不成立。只会复述标准流程、无法给出具体判断依据的人，适合做评审人而非分享人。
筛选结果落成一份待分享主题清单，至少包含主题、价值理由、候选专家、优先级和计划时间。清单不必一次列全，按季度滚动更新即可。
| 主题 | 价值理由 | 候选专家 | 优先级 |
|---|---|---|---|
| 高并发接口性能调优 | 线上故障代价高，多个项目反复遇到 | 后端负责人A | 高 |
| 第三方支付对接异常处理 | 复用频次中等，依赖外部接口 | 后端工程师B | 中 |
| 某次临时迁移脚本编写 | 一次性任务，后续不再出现 | 运维工程师C | 低 |
把隐性经验问出来：访谈与复盘的操作步骤
访谈的目标是获取素材，不是当场产出文档。一次有效的访谈通常需要提前准备、按提纲追问、事后整理三个动作，每个动作都有明确输入和输出。
访谈前准备
提前收集背景材料：相关项目文档、故障记录、监控数据、历史评审意见。同时梳理关键事件清单，标出专家做出重要判断的时间点，例如“为什么在第二次压测后调整了缓存策略”。带着具体事件进入访谈，比开放式提问更容易问出细节。
访谈提纲
提纲围绕四类问题展开，每类都要求专家给出具体例子：
- 做法：当时具体做了什么，顺序是什么，用了哪些工具或参数。
- 判断依据：看到什么信号决定采取这个做法，哪些数据或现象是关键。
- 适用条件：这个做法在什么规模、什么架构、什么团队条件下成立。
- 失败与例外：试过但不奏效的情况有哪些，哪些情况下要换另一种做法。
一对一访谈与复盘会的取舍
一对一访谈适合深挖个体判断，专家更愿意讲失败和犹豫的过程，适合技术性强、判断密集的经验。复盘会适合还原团队协作过程，能暴露交接、沟通和决策链条上的问题，但容易停留在结论层面。实践中可以先用一对一访谈获取素材，再用复盘会补充协作背景和多方视角。
整理原始素材
访谈结束后尽快整理记录稿，保留专家的原话和具体数字，标注不确定或需要核实的内容。记录稿是后续结构化的输入，不必追求文采，但要保证时间、对象、现象、动作、结果这些要素齐全。
整理成可复用条目：结构化字段与写作要求
访谈记录是素材，知识条目是产品。条目要让没有参与访谈的同事能直接照着判断和行动，因此需要固定字段，并对写作提出约束。
| 字段 | 填写要求 |
|---|---|
| 场景 | 说明业务、系统、规模和数据量，例如“日订单十万级、单库MySQL的查询接口” |
| 问题 | 描述可观察的现象和影响，避免只写“性能不好” |
| 做法 | 按步骤写动作和参数，标明先后顺序 |
| 判断依据 | 写清依据哪些指标、日志或现象做决策，给出阈值或参照 |
| 适用边界 | 说明规模、架构、版本、团队条件等前提，以及不适用的情况 |
| 反例 | 记录尝试过但失败的做法及原因，帮助使用者避开弯路 |
写作时区分事实描述与个人偏好。“将连接池上限调到200后，等待时间从800ms降到120ms”是事实；“我觉得连接池大一点比较好”是偏好，偏好可以保留在备注中，但不能替代判断依据。标题按使用者可能搜索的词来写，例如“MySQL单库查询接口慢查询调优：索引与连接池的取舍”，比“性能优化经验分享”更容易被检索到。关键词覆盖业务对象、技术组件和问题现象三类词。
条目沉淀需要承载文档和版本管理。ONES Wiki 可用于集中管理技术文档、项目规范和复盘记录，支持页面模板库一键创建制式化文档模板，并记录页面版本、支持查看与回滚，便于条目在多人修改后仍能追溯。条目与项目工作保持关联时，ONES Wiki 的页面组可关联项目，文档也可与 ONES 的项目、任务场景结合使用。
评审与挂载：让经验进入实际工作环节
条目写完不等于可用。评审解决准确性和边界问题，挂载解决“用的时候找得到”的问题，两者缺一不可。
评审分工
同行评审由同领域工程师承担，重点核对做法是否准确、步骤是否可操作、判断依据是否与实际情况相符。技术负责人评审把关边界是否清楚、是否与现有规范冲突、是否存在被误用到不适用场景的风险。两类评审可以先后进行，同行评审通过后再提交负责人确认。
评审关注点
- 准确性：数字、参数、工具名称与实际情况一致，没有把个别现象写成普遍规律。
- 边界清晰：适用条件写成了可判断的条件，而非“视情况而定”。
- 可操作：读者按步骤能复现关键动作，遇到分支时有判断依据可循。
挂载到工作环节
条目要放到使用者实际会经过的位置：需求评审时引用相关设计经验，方案设计模板中附上对应条目链接，代码评审检查项中列出常见反例，故障处理手册中挂载排查步骤。挂载位置应写进评审记录，明确由谁在什么环节引用。条目与工作项的关联越具体，被使用的概率越高。
角色分工与交付物清单
专家经验分享涉及多个角色，职责不清时容易出现“访谈做完没人整理、条目写完没人维护”的情况。下表给出一种可按团队规模调整的分工方式。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 知识负责人 | 组织主题筛选、安排访谈、跟踪评审与挂载进度 | 待分享主题清单、进度记录 |
| 领域专家 | 提供经验素材，参与访谈和复盘，确认条目内容 | 访谈记录稿、条目内容确认 |
| 评审人 | 同行评审准确性与可操作性，负责人评审边界与规范一致性 | 评审意见与修改记录 |
| 使用者 | 在实际工作中引用条目，反馈使用结果和问题 | 复用记录与反馈 |
| 维护责任人 | 定期检查条目有效性，处理过期内容 | 更新记录、失效标记 |
交接关系上，知识负责人把访谈记录交给整理人，整理完成的条目进入评审，评审通过后由知识负责人确认挂载位置，使用者反馈回到维护责任人。维护责任人通常由领域专家或同组工程师担任，按季度或按版本节奏复核一次。团队规模较小时，知识负责人与维护责任人可由同一人兼任。
示例：一次性能调优经验的完整分享过程
以下为演示情景，用于说明各环节的实际产出，不对应具体企业案例。
选题与专家确定。团队在季度主题筛选中发现，订单查询接口的慢查询问题在近半年出现三次，处理人集中在后端负责人A身上。该主题业务影响高、复用频次中高、人员集中度高，列为高优先级，专家定为A。
访谈问题与关键回答。访谈围绕一次具体故障展开。问“当时看到什么信号决定先查索引”，A回答：慢查询日志中同类语句占比超过六成，且执行计划显示走了全表扫描。问“什么情况下你会先调连接池而不是加索引”，A回答：当等待时间集中在获取连接阶段、数据库CPU并不高时，加索引收益有限。问“有没有试过但没用的做法”，A提到曾直接扩大连接池上限，结果数据库连接数打满，问题反而加重。
整理后的条目样例。场景写明单库MySQL、日订单十万级；问题写明接口P99延迟超过2秒；做法分两步，先看慢查询日志和执行计划，再根据等待阶段选择索引优化或连接池调整；判断依据给出慢查询占比和CPU水位两个参照；适用边界注明分库分表后需重新评估；反例记录扩大连接池导致连接打满的经历。
评审意见与修改。同行评审指出判断依据中的阈值缺少来源，建议补充观测周期；技术负责人指出适用边界未覆盖读写分离架构，要求补充。修改后条目通过评审，挂载到故障处理手册的数据库排查章节和方案设计模板的性能评估部分。
他人复用后的反馈。两个月后，另一名工程师在处理类似接口时按条目先查执行计划，确认属于索引问题，按步骤完成优化，P99延迟回落。反馈中补充了一条新反例：在数据量较小的测试环境中该判断依据不敏感，条目据此增加了环境说明。
完成检查：判断经验是否真的被复用
分享是否完成，不看文档数量，看条目是否被他人独立使用并产生结果。以下检查表可逐项核对。
| 检查项 | 通过标准 |
|---|---|
| 条目完整性 | 场景、问题、做法、判断依据、适用边界、反例六个字段齐全，无空缺或占位内容 |
| 边界清晰度 | 适用条件可判断，读者能据此决定用或不用 |
| 独立复用 | 至少一名未参与访谈的同事在实际工作中引用条目并完成对应任务 |
| 结果可观察 | 复用后有明确结果记录，如问题解决、耗时变化或评审结论 |
| 挂载有效 | 条目出现在约定的工作环节中，使用者能在需要时找到 |
| 过期处理 | 维护责任人已复核条目有效性，失效内容有标记或更新记录 |
常见失败信号包括：条目只有做法没有判断依据，读者照做但遇到分支就停；条目长期无人引用，挂载位置形同虚设；专家离职后条目无人能确认准确性；同一问题反复出现但条目未更新。出现这些信号时，回到选题和评审环节检查，而不是继续增加文档数量。
把上述流程固定下来后，专家经验分享就从一次性活动变成可重复的机制：主题清单驱动选题，访谈提纲保证素材质量，条目模板约束输出，评审与挂载保证可用，复用检查确认效果。团队可结合自身规模调整角色兼任方式和复核周期，先在一个高价值主题上跑通全流程，再逐步扩展。
常见问题
专家不愿意讲失败经历，访谈怎么推进？
失败经历往往是最有价值的素材，但直接追问容易让专家有防御感。可以换一种问法：不问“你哪里做错了”，而问“当时有哪些方案被排除，排除的原因是什么”“如果换一个条件，你会怎么改”。把问题落在决策过程上，专家更容易展开。
另一种做法是先用一对一访谈而非复盘会，减少当众评价的压力。访谈记录稿整理后请专家确认，明确哪些内容可以公开、哪些只作为内部参考，也能提高配合意愿。
团队规模小，没有专职知识负责人，流程能简化吗？
可以。角色分工表给出的是职责划分，不是岗位编制。小团队常见的做法是知识负责人与维护责任人由同一人兼任，评审人从同领域工程师中临时指定。
需要保留的最小环节是：主题清单、访谈记录、条目六字段、一次同行评审、一个明确的挂载位置。复用检查可以按季度集中做一次，不必每个条目单独验收。等条目数量增加、参与人变多，再拆分角色。
条目挂载到工作环节后，怎么知道它真的被用了？
挂载本身不代表使用。可观察的信号包括：条目在方案设计或故障处理中被引用并留下记录，使用者在评审意见或处理记录中提到该条目，条目收到补充反例或修改建议。
如果条目挂载数月没有任何引用记录，也没有评论和修改，通常说明挂载位置与实际工作路径不重合，或者条目内容不足以支撑判断。此时优先检查挂载位置和条目边界，而不是继续增加条目数量。
专家离职后，已沉淀的条目还能继续用吗？
条目能否继续使用，取决于它是否写清了判断依据和适用边界。只记录做法、没有判断依据的条目，在条件变化时很难判断是否仍然成立。
建议为每个条目指定维护责任人，由同领域工程师担任，按季度或按版本节奏复核一次。复核内容包括参数是否仍适用、依赖的组件或架构是否变化、是否出现新的反例。发现失效时标记或更新，保留修改记录以便追溯。
用 ONES Wiki 承载经验条目时，哪些能力对应本文的流程环节？
ONES Wiki 可用于集中管理技术文档、项目规范、复盘记录等需要长期沉淀的知识，并提供页面模板库，可一键创建制式化文档模板，适合承载条目模板和访谈记录稿。页面版本记录支持查看与回滚，便于条目在多人修改后追溯变更。
在挂载环节，ONES Wiki 的页面组可关联项目，文档也可与 ONES 的项目、任务场景结合使用，使条目和具体工作保持关联。条目评审流程、有效期提醒等能力在现有资料中未提及，选型时可向厂商进一步确认。
