只做一次访谈、录音转写，再让一个 Skill 拆解，通常还不够。访谈能得到高手“怎么说”，却不一定能还原他真实怎么做、依据什么信号判断、在哪些情况下会破例。更稳妥的做法是把一项具体工作按“四证取知、七类成资、双环校准”完成工程化，再用独立样本验收后分级上架。
先定一项具体工作，不以“复制高手”立项
第一步不是采访，而是把目标缩小。先确定要改造哪一项真实业务任务、期望的业务结果、谁负责验收、可以使用哪些资料，以及哪些情况属于高风险红线。
例如，不做“复制整个销冠”这样无法验收的项目，而是选择“判断一条销售线索下一步该怎么跟进”这类有输入、有输出、有人负责的具体工作。录音和转写只能作为原始证据，不能直接成为企业正式知识。
第一步：用“四证取知”交叉获得证据
四证取知就是“访、看、查、比”。
- 访：围绕近期真实关键事件访谈高手，追问他当时看到了什么、为何改变判断、还考虑过哪些处理办法。
- 看：观察高手实际操作，记录动作、工具、停顿、复查和升级点，捕捉他没有说出来的隐性步骤。
- 查：核查文档、日志、历史交付物和结果记录，确认讲述与真实业务痕迹是否一致。
- 比：对比优秀、一般、失败和边界案例，或者比较不同高手的处理差异，找出规则成立的条件与例外。
四种证据相互校验，能够减少只听一次访谈带来的遗漏、理想化表述和个人偏好。
第二步：把经验编译为“七类成资”
取得证据后，不是写一篇访谈总结，而是把经验拆成七类可维护资产：
- 业务对象与事实：工作中涉及什么对象，哪些信息可以确认。
- 目标与质量标准：怎样算合格、优秀或不可接受。
- 流程与动作：正常情况下先做什么、再做什么。
- 信号与判断：看到什么信号后做什么决定，条件之间怎样权衡。
- 例外边界与红线：规则何时失效，什么情况必须拒绝、暂停或升级。
- 角色权限与交接：谁可以看、改、批、发，责任怎样移交。
- 案例与测试：用哪些正例、反例、失败例和边界例检验规则。
知识正本、Skill、测试集、人工闸口、版本和日志共同构成企业资产，而不是单独一份提示词或转写稿。
第三步：通过“双环校准”持续纠错
第一个环是专家纠错环。业务高手负责示范、解释、专业批改和边界确认；业务负责人负责裁决哪些内容属于企业标准，并对验收结果负责。
第二个环是工程归因环。知识工程师、Skill工程师和作业线架构师不能只改最后一段文字，而要判断错误来自输入、转写、知识、Skill、流程、工具、权限还是界面。找到真正的错误源后，修改对应资产，再运行受影响测试和全线回归测试。
专家负责指出“哪里错、正确判断是什么”，工程团队负责定位“为什么错、应该改哪一层”。两个环缺一不可。
第四步：开发样本与验收样本分开
开发样本和保留验收样本必须分开。开发样本用于发现问题、修改知识和调整 Skill；保留验收样本不参与开发，用来判断系统是否能处理未参与开发的新情况。
样本数量不设统一固定值，要根据场景风险、判断分支、例外类型和覆盖充分性决定。不能用同一批已经反复调过的样本同时证明开发完成和验收通过。
第五步：分级上架，不默认全自动
验证通过后，先影子运行，再辅助运行。影子运行阶段，系统给出结果但不影响真实业务；辅助运行阶段，系统进入流程，但关键决定仍由人确认。
高风险节点必须保留人工审核、升级和回滚。只有低风险、边界清楚、监控充分的动作，才适合进一步评估自动化。正式上架后仍要记录版本、输入、输出、人工修改和异常，便于复测与追责。
常见问题
没有完整 SOP，能不能开始？
可以。但要从真实任务、历史痕迹、高手操作和案例对比中反向提炼，不能让 AI 凭常识补齐缺失规则。
只有一位高手，能不能开始？
可以先形成小范围候选版。关键或高风险判断，应优先补充第二位专家、多源证据或业务负责人的复核。
专家意见不一致怎么办？
先检查双方使用的术语、客户情境、时间和目标是否不同。仍有分歧时，保留条件分支并指定裁决人，不把不同意见强行平均。
这套方法的重点不是保存一个人的说法，而是把可追溯的证据、判断规则、测试和责任机制一起做成能够运行、审核和持续维护的组织能力。