选场景：三个信号
专家临近退休、问题重复率高、错误代价大，三个信号出现两个就值得做。场景太泛会导致访谈没有焦点，产出大量无法使用的通用表述；可以先列出三个候选场景，按信号数量与访谈可行性排序，只做一个。
访谈与回溯并行
访谈拿判断逻辑，工单回溯拿真实情形，两条线交叉才能补齐例外。只做访谈，得到的是专家认为的流程；只做回溯，看不到判断依据；两条线最好由两个人分别负责，再由第三人合并，合并时以工单为准。
切分到可检索粒度
一个单元只回答一类情形，长度控制在几句话。切得太粗检索命中后仍需人工筛选，切得太细会丢失上下文与依据；可以用提问的方式检验，如果一个问题需要拼接三个单元才能回答，说明粒度不对。
交叉校验与授权
由第二人按依据逐条核对，并同步标注数据级别与可用范围。没有校验的单元会把个人习惯写成标准，扩散后难以纠正；校验人最好是同岗位的另一位专家，而不是管理者，否则容易只看措辞不看判断。
入库评测与更新
用真实提问做一轮检索评测，看命中率与答非所问的比例，并约定复核周期。没有评测与复核，知识库会在半年内积累大量过时内容；评测集不必大，三十条真实问题就能暴露大部分结构问题，但要覆盖边界与拒答。
适用与不适用
适合谁
- 有资深员工即将退休、需要交接的企业
- 正在建设检索问答或智能客服的团队
- 希望把评审与工单经验沉淀下来的部门
不适合谁
- 只想把文件批量上传、不做切分的团队
- 没有专家可投入、也不愿用工单回溯的项目
典型场景
某物业公司的工程主管经验集中在故障判断上。团队先用一周访谈加三个月工单回溯，切出六十个单元，由第二位主管逐条核对依据，入库后用真实报修问题做检索评测，答非所问的单元被退回重写，三个月后补入十二条新例外。
可执行步骤
- 用三个信号筛出场景与访谈对象，确认工单范围与时间投入，写成一句话目标
- 访谈与工单回溯同步进行，分别记录判断逻辑与真实情形，两条线交叉验证
- 按一类情形一个单元切分，长度控制在几句话，保留依据来源与例外，并标注适用条件
- 由同岗位的第二位专家逐条核对依据，并标注数据级别与授权，核对记录留档
- 用三十条真实提问做检索评测，约定复核周期与更新责任人，评测集不少于三十条
常见坑
- 场景选得太大，访谈两小时仍在讲背景；先用三个信号筛，一次只做一个场景，并写清本次不做哪些
- 只记录结论不记录依据，无法校验；依据要写到条款或工单号，能被人复核，否则第二人无法校验，也无法交叉验证
- 切分粒度过粗，检索命中后仍需人工筛；一类情形一个单元，用提问检验粒度，粗切会让检索失效，命中后还要人工翻
- 入库即结束，没有评测与复核；三十条真实问题就能暴露结构问题，季度复核一次，否则半年后就过期
自检与验收清单
- 场景是否满足至少两个信号，并写明选择理由与边界
- 是否同时做了访谈与工单回溯，两条线都留记录
- 每个单元是否只讲一类情形，并保留依据来源与例外
- 是否有同岗位的第二人按依据逐条核对并签字
- 是否做过检索评测，复核周期是否已约定，并指定维护人
常见问题
五个步骤要多久
一个场景通常三到六周，访谈与回溯占一半，校验与评测占三成。压缩到一周通常只能产出框架，无法形成可用单元；宁可少做一个场景，也不要把访谈和回溯压成一次会议，否则例外收集不全。
需要什么工具
访谈提纲、知识单元模板、工单导出、检索评测集与版本台账即可。工具越轻越容易维护，重点是模板字段与校验流程；不要一上来就上知识平台，字段没定就上系统，后期迁移成本更高。
萃取完怎么保持更新
指定维护人并按季度复核，把新增工单里的例外补进单元。没有维护人，知识库会在一年内与业务脱节；复核时优先看接管记录与答非所问的问题，这些地方最能反映单元是否还适用。