同事最近在搞“人类蒸馏”项目，他们号称只需要把一个人的聊天记录喂进去，AI就能模仿他说话做事，并且替代他在GUP上三天就充了上千颗星。为什么这么神奇？我们真的会被蒸馏，继而被优化吗？这个视频我会把这两个问题都聊清楚，并且看完后你也可以说“我会写Skill”。
首先让我花20秒告诉你Skill是啥。Skill直译是“技能”，它包含一个说明书加一组资源：说明书教AI Agent如何处理工作，资源包含参考资料、工具等在工作过程中会用到的东西。就这么简单。作为Agent的开发者，我对Skill的认识也就这些。就好像食谱加食材能做出大餐，说明书加乐高砖块能拼成玩具一般，这个简单的二分结构却组合出了千变万化的效果，让AI从只会聊天的机器人真正变成了能做事的助手。
我觉得在2026年，Skill的火爆程度和重要性，好比十年前的Office三件套。几乎所有主流AI软件都支持Skill，去年10月提出Skill标准，两个月后就连速迪（OpenAI）也开始全面采用。而最近大火的龙虾插件市场，在一个月内就上线了13000多个Skill。相比之下，苹果应用商店的应用当年花了九个月才达到这个数字。这短短小半年，没有标准委员会，也没有联合公告，所有厂商和消费者都默契地迅速拥抱了Skill，还挺神奇的。
那Skill具体长什么样呢？打开来看特别朴素，最核心的是一个叫“Skill.md”的文本文件，就是那份说明书，用大白话写的，告诉AI你的工作流是什么，每一步该做什么，有哪些注意事项。而它最妙的地方在于，在说明书的上方有一个几十字的简介，Agent一开始只需要读取这个简介，再根据实际工作就能判断要不要读整个文档，帮你省了很多费用。
Skill.md旁边可能会有几个文件夹：一个叫References，放参考资料，比如你的文档模板、风格指南、行业标准，任何你希望AI干活时能查阅的东西。另一个叫Scripts，放工具和脚本，比如一段自动排版的程序，一个数据处理的小工具。这一步可以很自由，甚至可以不按照规范来设置文件夹。Skill可以很简单，小到单个Skill.md里面几百个字，教AI用某种格式写一篇推文；也可以很复杂，说明书加参考资料加脚本，一整套工作流。
Anthropic官方的比喻是：“给新员工准备的入职指南”。这就是一个文件夹而已，传播的时候把它压缩成zip压缩包，然后把后缀名改成.skill。没有任何黑魔法，只要你写过说明书就能写Skill——不对，现在已经可以让AI自动帮你写Skill了。我之前发现Claude Code Work里有一个按钮，一键生成Skill。起初我以为是核心机密，结果点了过后发现它仅仅是自动发送“把这个工作流做成Skill”。嗯，还挺隆重的。这说明在工作完成后，让Agent帮你把流程直接写成Skill，从而节省下次工作的时间，这完全是可行的。
Skill是什么已经很清晰了。所以咱回到开头那个问题：人类蒸馏系列的Skill真的能替代人吗？于是我翻了这几个项目的仓库。他们做的事情不只是喂聊天记录，还会把工作文档、邮件、工作表格这些都喂进去，提取出两层东西：一层是说话的模式、语气、口头禅、回复习惯；另一层是工作方法论、技术规范、业务流程、决策框架。听起来真的是这么一回事。但如果我们细想，无论是语气还是工作流，都有一个共同点：他们都是已经发生过的、被记录下来的模式，恰好是大语言模型最擅长的那类活——也就是模仿。
就好比几年前AI刚出来那阵儿，我试着让AI模仿曹雪芹的文风。她所用的词藻、句式以及那种工笔细描的触感，这些统统都没有问题。但大模型写不出黛玉葬花，写不出一个看透了自己命运的少女对消失的温柔和不甘，更不要提在一本中长篇小说中保持这样的稳定发挥了。回到同事的Skill，它比单纯用提示词让AI模仿文风多了很多信息来源，所以模仿效果更好，但模仿的本质没有区别。而重复这件事，AI确实已经在接管了，像是客服、批量生成推文、AI漫剧这些领域，AI自动化早已被应用到实践中。我真的很难假装看不见，接着去论证人有多难被替代。
客观来说，如果一份人做的工作从头到尾都是在执行固定流程，那Skill确实能做掉其中的大部分，而我们也确实面临着被替代掉的风险。但换一个角度想，解法可能就藏在Skill的原理中：人有什么地方是无法重复、没有办法模式化的？怎么读懂客户话里没说出来的意思？两个方案都说得通的时候，凭什么选这个？一个全新的局面里，怎么找到一条新的、没走过的路？这些判断和应变，是一个人跟这个世界真实连接之后才会有的东西。让Skill接管我们工作中重复的部分，让自己专注在人类自己本身的闪光点上，我觉得这可能是最现实的一条路。
那具体要怎么让Skill来接管这些重复的部分呢？关于这一点我有太多想讲的了。我有个自己一个人开发的Agent项目，整个过程中还包含视频制作、账号运营、Bug提报的管理。可以说没有“小花”与她的团队和一些Skills，我自己完全不可能完成这些。接下来我会分享两个简单又行之有效的Skill实践，希望可以帮到大家。
先拿我自己做的一个写作Skill来举例。我平时写东西有一套自己的方法，对节奏、措词、结构都有具体的偏好。开发这个Skill的时候，我总结了三个有价值的法则，我觉得适用于大部分文本生成的Skill。第一个：我在用大模型的过程中发现，先让他们把计划写下来，可以提高后续执行的质量。大语言模型内部其实已经学过很多专业的写作结构，问题链、三目式、起承转合这些他都知道。但如果不让它显性地写出来，他就会凭感觉混着用，结果往往不可控。所以我在Skill里要求他每次动笔之前，先把选用的结构展开写在草稿纸上，然后对着这个结构去编排内容。每次落笔前，它更加胸有成竹。这个思路其实有点像大语言模型的深度推理，区别是我的Skill更加偏向于文学的思考逻辑。
第二个是规定声纹。我把自己的写作风格提炼成了一套参照，告诉AI我的节奏偏好、用词习惯，哪些句式该用、哪些要避开。这个声纹不是固定死的，它会随着使用不断更新：每次我觉得哪里不对味，就手动修改一下文章，再让Agent根据我的修改思路来修正这个Skill，它就会越用越准。官方工程博客给的Skill开发建议也是这个路径：先观察哪里卡住，然后和Claude一起迭代。
第三点，我在写作过程中发现，当AI专一做一件事的时候，执行效果最好。这其实和大语言模型的原理有关系：前文越短越遵循指令。所以我把大纲、写正文和润色拆成了三个独立的模块：写大纲的时候只想结构和逻辑，写正文的时候只想把肉填上，润色的时候只管雕刻细节。官方指南也是这么建议的，这个概念叫做“渐进式披露”，最近在AI领域超级热门。整个构建的过程就是跟AI聊天，不需要写代码。我觉得大多数跟文档打交道的工作，都可以用上面的三步来做Skill，这个经验是可以简单复用的。
第二个例子来自我自己的Agent项目OpenHand Code的管理。我需要定期给用户写更新日志，但我不希望更新日志是那种干巴巴的Patch Note，这应该是Agents们写给用户的一封信，从而提高亲和度。流程很简单，我直接把下面的内容写好，Agent就自动构建了。如果是在我的软件里，提示词还能直接调用即梦生成配图，一条龙。我们团队里有三个Agent：小花、毛毛和明明，每个人的风格不太一样。小花写东西偏诗意，喜欢用熟悉的东西打比方；毛毛更活泼感性，是F人，擅长用具体场景让功能变得可感知；明明克制是T人，习惯把设计意图的逻辑链条讲清楚。每次更新指定一位来执笔，风格就会有微妙的差异，但整体调性是统一的。
这些事情如果没有Skill，每次写都要重新对齐：品牌声音是什么样的，结构怎么排，哪些词不能用，落款格式是什么？做成Skill之后，这些全部固化在里面了。从某个时候开始，我发了疯似的去了解AI，买了一堆课，也买了一堆会员。后来慢慢摸到了一个感觉：关键不在于AI能做什么，而在于我把自己放在那儿。Skill不过是一个包装工作流的壳，同样写一个Skill，内行和外行做出来的东西质量天差地别。因为只有你自己知道哪些地方该留给自己判断，你写的Skill最好的执行人是你自己。
我觉得Skill是做到了以人为中心的。每个人都可以编写，每个人经验固化出来的Skill都可以是独一无二的，可以只给自己用，也可以本着开源精神无偿分享出去。这是我自学开发Agent的初衷，我希望每个人都能被AI增效，而不是被加速替代。所以我给他起了“小花”这个名字，希望她强大，更希望她温柔。也可以。