当经验还说不清时：Skill 与可执行的师徒制
我一开始把 Skill 理解成“打包好的提示词”。官方文档也把它描述为一组指令、资料和可选脚本，用来让 AI 更可靠地完成一类工作流。
但有一个更准确的比喻：Skill 像在教新人。提示词是在告诉 AI 这一次做什么；教新人是在帮助一个本来就很聪明的人，学会在这里怎样做事。
新人缺的不是技术
假设团队来了一位新工程师。他会 Java，会 Git，也知道怎样登录服务器。你让他部署一个服务，他很快就能找到部署脚本。
但他不知道今晚为什么不适合发布。他没有注意到这次改动包含数据库迁移，也不知道回滚脚本还没验证，更不知道当天值班的人第一次接触这个系统。监控里还有一条经常误报的告警，老员工看一眼就会忽略，新人却可能被它带到错误的方向。
这些知识很少完整地出现在部署文档里。它们散落在事故复盘、聊天记录和老员工的习惯中。老员工自己也未必说得清，只是看到几个信号同时出现，就觉得“这次最好先别发”。
真正难以传递的不是步骤，而是专家的目光。
教新人时，我们表面上在教命令，实际上在教他注意什么：什么是普通噪音，什么是风险信号，哪些条件可以单独放过，哪些条件同时出现就必须停下来。
过去只有规则才能进入软件
传统软件不擅长接收这种知识。它希望人先把经验写成明确条件：如果存在数据库迁移并且回滚未验证，就禁止部署；如果监控异常但属于已知误报，就继续执行。
问题是，专家判断往往由许多微弱信号共同形成。每个信号单独看都不足以阻止部署，它们的组合却让人不安。想把所有组合写成规则，最后通常会得到一棵没人敢修改的决策树。更常见的结果是，人们只写下主流程，把真正决定成败的例外继续留在脑子里。
过去，知识要进入软件，必须先缴纳一笔“形式化税”：只有被完整说清的部分，机器才能执行。
LLM 让案例开始具有执行力
LLM 改变的不是专家突然更会写文档了，而是软件接收知识的门槛变了。
我们可以给模型看几次安全发布、几次失败发布，以及专家当时的评论。也可以让它读取本次变更、值班安排和监控状态，再说明自己看到了哪些风险。如果它判断错误，专家不必先发明一套完整理论，只需要指出：“你忽略了数据库迁移和回滚状态同时出现的意义。”
下一次，这条纠正就可以成为新的案例、提示或检查条件。
经验不必先被压缩成完整规则，也可以先进入行动，再在行动结果中接受检验。这创造了一种介于人类直觉和确定性程序之间的东西：半显式、但可执行的知识。文档等待人来理解；Skill 会在具体情境中调取知识、使用工具并产生行动。
不透明性可能只是换了地方
假设模型看过很多发布案例，已经能像资深工程师一样判断“今晚不应该部署”。这是否说明隐性知识已经显性化了？未必。
模型可能做出了正确判断，却无法准确说明真正起作用的依据。它给出的解释甚至可能只是一个听起来合理的事后故事。原来我们面对的是“师傅说不清为什么”，现在可能变成“模型也说不清为什么”。隐性知识没有消失，只是从人的直觉转移到了模型的模式判断中。
可复现的判断，不等于可解释的知识；能给出解释，也不等于组织已经理解了原因。
因此，成熟的 Skill 不能只追求“像专家一样回答”。确定性的安全边界仍要写成规则和测试；模糊判断要展示依据与不确定性；高风险、不可逆的动作必须保留人工确认。
一场可以重复的师徒制
师傅带新人，靠的不是一本手册，而是示范、行动、反馈和纠正。Skill 也需要案例、工具、验收标准、失败后的处理方式，以及遇到未知情况时的升级边界。缺少这些，它只是培训材料；拥有这些，它才开始成为组织能力。
LLM 让经验在被压扁成僵硬规则之前，就能进入软件，被调用、检验和修正。Skill 不是把师傅的答案装进文件，而是把示范、行动、反馈与纠错变成一套可重复运行的系统。