在做了一周"Skill作家"后，我发现AI爱看这样的文章
上周五深夜，我盯着屏幕上第 14 个刚生成好的 Skill，忽然觉得不对劲。
我花了两天时间，从公司知识库里抓了 100 篇游戏技术文章，一篇一篇读过去，试着把它们喂给 skill-creator，转化成可以直接上手使用的 Skill。简单来说，就是把别人写的经验和方法论，变成一个 AI 能理解、能执行的”能力包”——你对它说”帮我做个 AI 漫剧”，它就真的能一步步带你从剧本写到出片。
听起来很美好对吧？
但做到第 14 个的时候，我发现了一个让我坐不住的规律：不是所有文章都能变成好 Skill，甚至大部分都不行……但是我们却可以用一些特定的方法略施小计，化腐朽为神奇。这个发现可能要比”做出 Skill”本身更有价值。所以今天这篇随笔，是我对于 Skill 应用和转化的一些心得和发现。
01 别被名字唬住
很多人一听”Skill”，又是什么”渐进式披露”、“脚本执行”……以为是什么很玄乎的东西。其实没那么复杂。
你可以把它理解成一份给 AI 看的入职手册。就像你新加入一个项目组，leader 给你一份文档，上面写着”这个项目的流程是什么、注意事项有哪些、遇到坑怎么办”，你照着做就能上手。Skill 做的就是这件事，只不过”新人”变成了 AI。
技术上说，一个 Skill 就是一个文件夹，里面最核心的是一个叫 SKILL.md 的 Markdown。它告诉 AI”你是谁、你能做什么、遇到什么情况该怎么做”。如果知识量比较大，还可以把细节拆到 references 目录下——AI 按需查阅，就像你翻查项目 wiki 一样。
这和直接问大模型有什么区别？区别就像问路人”附近有啥好吃的”和问一个在这条街住了十年的朋友。路人可能给你推荐大众点评排名前三，但作为当地人的朋友才会告诉你隐藏的宝藏小店。
Skill 里装的，就是经过过滤之后的经验。
02 论知识之分类
知识库里的文章五花八门，但读了 100 篇之后，我发现它们基本可以分成三大类——而且每一类转化成 Skill 的”命运”完全不同。
第一类：手把手教你做的”SOP 型”文章。
这类文章最典型的特征是有明确的步骤——“先做 A，再做 B，注意 C，最后得到 D”。就像一道菜谱，你不需要是大厨，照着做就能端出一盘差不多的菜。
转化成 Skill 之后效果非常好。因为这类文章的”骨架”天然就是一个工作流——你只需要把步骤提炼出来，把踩坑经验标注好，把具体的案例内容剥掉，一个能用的 Skill 就成型了。
第二类：跟你聊项目心得的”复盘型”文章。
这类文章通常是某个团队做完一个项目之后写的总结。你能读到很多有价值的经验——“我们一开始遇到了什么问题，试了什么方案，最后发现什么方法管用”。
听起来也很有料对吧？但转化成 Skill 之后，我发现了一个尴尬的问题：生成出来的 Skill，和直接拿这篇文章去问大模型，体感差别不大。因为这些知识和他们团队用的特定技术栈绑定太紧了。框架只占两成，案例占八成。把案例抹掉之后，骨架太薄了。
第三类：横向对比的”分析型”文章。
这类文章最容易写成”A 公司做了什么、B 公司做了什么、C 公司做了什么”的罗列——案例很丰富，对比维度也有，但缺少一个让读者”拿来就用”的分析框架。因为它缺少一个”不依赖具体案例也能成立的分析框架”。
03 换皮测试
我后来想明白了一件事，用一个方法就能判断一篇文章能不能变成好 Skill——我管它叫**“换皮测试”**。
方法很简单：把文章里所有的项目名、公司名、具体数据、技术栈名字全部抹掉。然后看看剩下的部分，读者还能不能从中学到一套可以直接用的方法。
如果能——恭喜你，这篇文章的”骨架”是硬的，转出来的 Skill 会很好用。
如果不能——那说明这篇文章的价值和它的具体案例粘在了一起，你把案例一扒，就什么都不剩了。
用做菜打个比方：好文章教的是”红烧的方法”，换鱼、换排骨、换豆腐都能用；不够好的文章教的是”红烧这条鱼”，换个食材、甚至换条鱼，你就不知道该放多少酱油了。
所以我得出的核心结论是：文章的”抽象层级”决定了 Skill 的质量。 抽象层级越高——提供的是方法论、框架、思维模式——Skill 越好用、越通用。抽象层级越低——提供的是具体案例、特定数据——在 Skill 加持下的 agent 就退化成了一个低等的文章摘要机器人。
04 不存在”坏”Skill，但存在”错配”
那第二类、第三类文章就一文不值了么？不是的。更准确的说法是：它们不适合转成同一种 Skill。
在实际操作中，我发现 Skill 至少有三种形态：
-
工作流型（Workflow）： 适合”菜谱型”文章。Skill 的角色是”引导你一步步做”，用户触发方式是”帮我做 X”。体感最好的一种，因为它真的在帮你干活。
-
能力参考型（Capabilities）： 适合”复盘型”文章中方法论含量高的。Skill 的角色是”你遇到问题时给你方案参考”，触发方式是”怎么做 X”。更像一个随叫随到的技术顾问。
-
决策参考型（Reference）： 适合”分析型”文章。Skill 的角色是”帮你梳理信息、辅助决策”，触发方式是”对比 X 和 Y”。更像一个信息整理助手。
Skill 的上限，不取决于 AI 有多聪明，而取决于那篇文章里藏了多少”可复用的东西”。
05 授人以渔和鱼
做完这 100 篇的深度 PoC 之后，如果让我给所有写技术文章的人提一个建议：
写的时候想一想：别人读完你的文章，带走的是”一个方法”还是”一个故事”。
故事会过期，方法不会。
如果你能向上抽一层——把”我们做了什么”变成”遇到这类问题时可以怎么做”——你的文章就从一个”故事”升级成了一个”方法”。而这个”方法”，就是 AI 能真正学会、并且帮别人复用的东西。
我总结了一个简单的结构建议：问题 → 思路 → 框架 → 案例验证。 注意，案例是在最后用来验证你的框架的；而不是案例在前面，框架让读者自己总结。
06 这可爱的小东西会颠覆什么吗？
做完这些之后，我下意识地开始用产品的脑子想问题——Skill 对”知识管理”这个产品形态来说，到底意味着什么？
Skill 更像是高铁站的摆渡车。 你坐高铁从北京到深圳，那是技术的跨越、是范式的切换。但你从高铁站到酒店，总不能也修一条高铁，你需要打个车。它不酷，不颠覆，但它把最后三公里的路接上了。
Skill 就是在这两个现实之间架了一根桥——把已经沉淀好的人类经验，翻译成 AI 能理解的格式。 不性感，但管用。
说到这，让我想到了最近一个吵得很凶的问题：未来的产品，到底还是不是给人类做的？
但我反而更笃定了一件事：产品仍然是给人做的。
道理很朴素——你去看我做的那些 Skill，哪怕是最”AI 化”的工作流型 Skill，它解决的问题仍然是”帮一个人类更高效地做 AI 漫剧”。Agent 在中间跑的每一步——拆分镜、选模型、调参数——本质上都是在替代一个人类原本要手动做的操作。不服务于人类需求的产品，就是空中楼阁。
产品的”界面”在变，但产品的”朝向”没变——它永远面向人。
技术本质
Skill 的技术本质，是一种”程序性知识”的标准化封装格式。
知识分两种：一种是”陈述性知识”——某条规定是什么、某个数据是多少；另一种是”程序性知识”——遇到这类问题该怎么做、这件事的步骤是什么。传统的 RAG 擅长处理前者；Skill 干的事情，恰恰是把后者完整地、结构化地交给 AI。
从架构上看，现在的 AI 工具链正在长出一个清晰的分层结构：底层是数据和 API，中间是 MCP 这样的标准化连接协议（负责让 AI 能”够到”外部工具），上层就是 Skill（负责教 AI”怎么用”这些工具）。MCP 是 AI 的”手”，Skill 是 AI 的”脑子里的操作手册”。
渐进式披露
Skill 在工程上做了一个很聪明的设计：把知识分成三层——最外层是一小段元数据摘要（~100 token），告诉 AI”我是谁、我能干什么”；中间层是完整的操作指令；最里层是参考文档和可执行脚本。AI 启动时只读最外层，判断”这个任务需要哪个 Skill”，然后才按需加载中间层和里层。
传统做法是把所有工具定义一股脑塞进上下文，轻松吃掉上万 token；Skill 的做法是初始只消耗几百 token，剩下的按需加载。
说白了，Skill 能做的事，不会超过”一个聪明人读完一份好文档之后能做的事”。 这就是它的天花板。这不是贬低——这个天花板其实已经很高了。但关键词是”好文档”。
现在流行一个词叫**“上下文工程”（Context Engineering）**——在大模型时代，真正的技术活不是训练模型，而是怎么把正确的信息、在正确的时机、用正确的格式喂给模型。Skill 就是上下文工程的一种具体实践。
所以如果你问我”Skill 会改变知识管理吗”，我的回答是：会，但不多。 它改变的不是知识管理的范式，而是让”写好文章”这件本来就该做的事，多了一个实实在在的回报——你的经验不只是被人读到，还能被 AI 用起来。
但如果你期待它颠覆什么，抱歉，摆渡车不是 F1 赛车。它的最大价值，恰恰是让你从旧范式走到新范式的这段路不用淋雨。
07 我真正学到的东西
坦白说，我一开始做这个项目的时候，想的是”怎么把文章变成好 Skill”。但做着做着，我发现这个项目其实在回答一个更底层的问题：什么样的知识才是真正可复用的？
不是所有写下来的东西都是”可复用的知识”。有些是记录，有些是感想，有些是总结——但只有那些被抽象到一定高度的、能脱离具体场景独立成立的内容，才真正具备”可复用性”。
Skill 只不过是把这件事变得更加显性了——因为它需要 AI 来”理解”你的知识并”执行”出来，所以知识是不是真的可复用，AI 一跑就知道了。
从这个角度说，AI 不是在替代人的知识，它是在帮人检验知识的质量。
核心就三句话：
- 文章教”方法”的部分才能变成好 Skill，教”故事”的部分只能变成摘要
- 用”换皮测试”：抹掉具体案例后，框架还能不能站住
- 写文章的时候多想一步：“如果有人要拿我的经验去用，他需要我写成什么样？“——这一步，就是从”记录者”到”知识工程师”的跨越
因为好知识的标准从来不是”你做了什么”，而是”别人读完能做什么”。
文章最后推荐 SkillHub，在充分本地化之后展现出了对中文用户惊人的适配程度。
原文首发于微信公众号「BodyHeat体温集」，2026 年 3 月 29 日。