夜雨聆风折腾 OpenClaw Skill 之后，我改变了对它的看法
我记得很清楚，那是某个下午，我把一个在 Claude Code 里用了很久、已经调教得很顺手的 Skill 文件，复制进了 OpenClaw 的目录。
操作非常简单。理论上应该直接能用。然后它就静静地躺在那里，什么都没发生。
我以为是路径不对，检查了一遍。没问题。我以为是 description 写得太模糊，改了一版。还是不触发。后来它偶尔触发了，但执行路线完全不对，像一个在异国他乡找路的人，工具拿错了，流程走偏了，最后给出了一个看起来很像样但其实没什么用的结果。
最让人抓狂的不是出错，而是那种软失效——它没坏，只是不顺手。你找不到明显的问题，但就是感觉哪里不对劲。
我后来翻来覆去看 SKILL.md，越看越觉得没毛病，但它就是跑不好。
直到我慢慢想清楚了一件事：
Skill 不是“复制过去”就能复用的，Skill 的本质也不是“一个 Markdown 文件”。
这篇文章，我想分享的是折腾了一圈之后，关于 OpenClaw Skill 几个最有感触的认知，重点讲 4 件事：
OpenClaw Skill 和 Anthropic Skill 到底哪里不一样 为什么很多人装了 Skill，却觉得“不太好用” 怎么创建和适配一个真正能用起来的 Skill 有哪些实践原则，能让 Skill 不只是“装上了”，而是真的“跑起来了”
Skill 不是插件，Skill 是工作方法的封装
很多人第一次接触 Skill，容易把它理解成插件：装一个不就等于多一个功能吗？有个 SKILL.md，不就等于这个能力已经接进来了？
但真正折腾之后，你会慢慢发现：Skill 不是“功能开关”，而是“工作方法打包”。
一个 Skill 真正有价值的地方，不只是“告诉模型做什么”，而是同时回答了这些问题：
- 什么时候该用我？
- 遇到这类任务，你应该怎么做？
- 优先调用什么工具？
- 哪些情况别乱来？
- 最后输出成什么样子？
你可以把它想象成团队里的“专项 SOP”。
比如你团队里有个同事特别擅长做竞品分析。他不是只会一句“我会分析竞品”，而是脑子里天然有一套流程：先确认分析对象，再拆维度（功能、定价、体验、渠道），必要时查官网、社媒、更新记录，最后不是简单罗列信息，而是提炼结论和建议。
Skill 的价值，就是把这套“会做事的经验”结构化地交给 Agent。
好 Skill，不是在加功能；好 Skill，是在给 Agent 增加“靠谱的做事习惯”。
Claude Skill 能用，不代表 OpenClaw Skill 也能用
这是我最近最有感触的一点。
很多人，包括我自己，一开始都有一种天然预期：既然 Claude Code 那边这个 Skill 很好用，OpenClaw 里直接加载一下，应该问题不大吧？
但为什么会出现那种“软失效”？
因为 Claude / Anthropic 的 Skill，和 OpenClaw 的 Skill，虽然名字都叫 Skill，但所处的“系统环境”其实不一样。
在 Claude 语境里，你更多是在和 Claude 自身的上下文能力打交道——系统提示、工具理解方式、任务跟随风格。
但在 OpenClaw 里，你面对的是一个 Agent 框架。Skill 不只要考虑自己写得对不对，还要考虑：AGENTS.md 怎么定义角色，TOOLS.md 怎么规定工具规则，有没有 MCP，有没有 Memory，当前有哪些权限、哪些目录结构……
这就像一个在公司 A 特别能打的同事，跳槽到公司 B 之后，能力还在，但马上会遇到一堆新问题：协作工具不一样，汇报格式不一样，审批流程不一样，谁能拍板、谁能执行也不一样。
你说这个人不行吗？不是。但他很难原封不动地套用原来那套打法。
跨框架迁移 Skill，迁移的不是文件，迁移的是“经验 + 环境适配”。
最容易被低估的，不是步骤，而是触发
如果只让我讲一个最关键的点，我会讲这个：
一个 Skill 好不好用，首先不取决于它“写了多少步骤”，而取决于它“会不会在正确的时候出现”。
也就是说，Skill 的第一道门不是执行，而是触发。
很多人做 Skill，会把大量精力放在正文步骤上，写得特别细：第一步做什么、第二步做什么、第三步输出什么。这些当然重要。但如果这个 Skill 根本不会在该出现的时候出现，那后面写再多都没用。
我碰到的很多“Skill 不太行”的情况，本质上不是执行烂，而是触发烂。
典型有两种：该触发的时候不触发，或者不该触发的时候乱触发——明明用户只是问一句“帮我润色这段话”，一个“重型评审 Skill”突然冲出来，开始搞大而全分析。
这背后，最常见的问题就是 description 写得不行。
很多 Skill 写成这样：
用于分析需求文档
这句话不能说错，但几乎等于没说。它没有回答：用户会怎么提出这个需求？是评审、补充、总结、润色，还是解释？什么时候该用？什么时候不该用？
Skill 的正文决定它“怎么干活”，description 决定它“有没有机会上岗”。
一个更实战的写法是：
当用户需要对 PRD 进行结构化评审、发现遗漏、识别边界条件、检查异常流程时使用此 Skill。若用户只是要求解释文档内容、润色表达或总结段落，不要触发。
你看，这就一下子不一样了。它不只是说“我会做什么”，而是在说我什么时候上场、什么时候别上场、我不是来抢所有文档类任务的。
换一个场景，调研类 Skill 也一样。如果你写的是：
用于网络信息调研和总结
那基本上，一半的问题都会触发它。更好的写法是：
当用户需要对特定主题进行多源信息采集、交叉验证、结构化整理时使用此 Skill。若用户只是想快速了解某个概念的基本定义，或只需要一句话解释，不要触发。
这两个例子说明同一件事：description 的核心不是“我能做什么”，而是“我在什么情况下值得出场”。
这是成熟 Skill 和初学者 Skill 最显著的差别之一。
Skill 不是孤立存在的，它要跟 AGENTS.md、TOOLS.md 一起看
有时候你会觉得一个 Skill 写得挺好，逻辑也没毛病，但就是运行起来不顺。反复看 SKILL.md，看不出问题。后来才发现，问题压根不在 Skill 本身，而在它和环境没对齐。
我现在越来越倾向于这么理解：
AGENTS.md像操作规范手册（管启动行为、记忆规则等） TOOLS.md像工具使用宪法 SKILL.md像专项任务手册
如果你只写 Skill，不看另外两者，就很容易翻车。
举个例子：你写了一个“网页调研 Skill”，正文里写的是“打开目标网页，用浏览器进行搜索和页面遍历”。看起来没毛病。但如果你的 TOOLS.md 里明确写了“所有浏览器操作必须使用某个指定 browser-agent”，而 Skill 正文里默认的是另一套浏览器方式，就会产生冲突。
最尴尬的不是“完全跑不起来”，而是：有时候能跑，有时候跑偏，有时候模型自己会试图绕过去，最后你会觉得这个 Skill 不稳定。
可本质上，它不是不稳定，而是没有和环境的规则层对齐。
在 OpenClaw 里，Skill 不是独立作品，Skill 是系统里的部件。
系统里的部件最怕的，就是单看自己没问题，一接到整机上就不兼容。
安装 Skill 只是开始，真正难的是让它“跑起来”
很多人容易有一种“安装完成 = 这事结束了”的错觉。但 Skill 这件事，最容易踩坑的恰恰是后半段。
我现在更愿意把 Skill 的可用状态拆成四层：
第一层，装上了——文件已经进目录了。
第二层，加载了——系统能识别它，没有被依赖或规则拦掉。
第三层，触发了——在你期待的场景里，它真的出场了。
第四层，跑对了——它不仅出场了，还用对了工具、走对了流程、给出了对的结果。
很多时候，我们以为“Skill 不行”，其实只是因为它卡在其中某一层。比如你装了一个需要 API Key 的 Skill，文件已经在那儿了，但因为环境变量没配，它根本没被加载。于是你会以为是 description 写得不行。但问题压根不在触发，而在加载。
或者 Skill 已经出场了，但正文里默认调用的工具，在 OpenClaw 里并不是你实际允许使用的那套——它拿到的是一张过期地图。
装上 Skill 是体力活，用好 Skill 才是脑力活。
从零开始做 Skill？先把这 3 件事做对
别一上来追求复杂，先把下面 3 个动作做对。
动作一：先把“触发边界”写清楚，再去补正文。
很多人做 Skill 的顺序是：先想步骤，再想工具，最后补一句 description。我现在越来越觉得应该反过来：先定义什么时候该用、什么时候不该用，再定义执行步骤。
有一句话特别好用来检验自己有没有想清楚：
如果你说不清这个 Skill “什么时候不要用”，那你大概率也没真正定义清楚它“什么时候该用”。
以后设计 Skill，可以先逼自己写一句“本 Skill 不适用于……”。如果这句写不出来，通常说明 Skill 的职责还太散。
动作二：把工具约束写明白，别假设“模型自己懂”。
你越依赖工具，越要显式写清：优先用什么、禁止用什么、没有时怎么办、失败时怎么办。
比如不要只写“搜索网页并提取结论”，而要写成：
当需要浏览网页信息时，优先使用当前环境允许的浏览器代理工具；若浏览器工具不可用，则先向用户说明限制，不要虚构网页内容。
这句话做了两件事：告诉 Agent 用对工具，告诉 Agent 工具不可用时别胡编。
好 Skill 不只是“会做”，还要“不会乱做”。
动作三：装完之后一定要做“正反两类测试”。
准备 3 个应该触发的场景，再准备 3 个不应该触发的场景，都跑一遍。
很多 Skill 最大的问题不是“不会做”，而是“分不清自己什么时候该出手”。正反测试，恰好是最能暴露这个问题的方法。
一个 Skill 是否成熟，不看它写得多长，要看它会不会在不该出手的时候忍住。
上面说的是从零开始做 Skill 的情况。但很多人真实面对的其实是另一个问题：
我已经有一个在 Claude Code 用得不错的 Skill，怎么把它带到 OpenClaw 里？
把 Claude Skill 搬过来？不要“搬”，要“改”
第一步：先抽象出原 Skill 的“核心经验”。
不要先盯着原文怎么写，先看：它真正解决的是什么任务？它好用的原因是什么？它依赖的工具前提是什么？
迁移 Skill，迁移的是方法，不是原文。
第二步：重写 description，不要直接沿用。
原来的 description 是在 Claude 语境里成立的，到 OpenClaw 里，匹配方式、上下文层级、已有 Skill 关系可能都不一样。要重写成更符合当前环境的版本。
第三步：把工具链全部重映射一遍。
把原 Skill 里隐含的工具假设全部翻出来：浏览器是谁来做？搜索是谁来做？shell 能不能跑？有没有权限限制？是否要走 MCP？
如果这些不重做映射，就会出现一种很典型的现象：
Skill 看起来被装上了，但它做事像在异国他乡找路。
第四步：对齐你自己的 TOOLS.md 和 AGENTS.md。
如果你的环境里已经有明确规则——浏览器操作只能用指定代理、某类事情必须先确认再执行——那 Skill 正文就必须对齐这些规则。否则就像一个新人，脑子里带着前公司的规章制度来上班。他不是不努力，但很难真正融入当前团队。
第五步：做一次真实任务闭环，不要只看“有没有触发”。
触发了不算完。工具用得对不对？输出值不值得保留？你真正追求的不是“可运行”，而是“值得长期留下来”。
最后留下来的 5 条原则
折腾下来，我觉得最值得记住的就这 5 句：
先定义边界，再定义能力。 边界不清的 Skill，迟早会变成误触发大户。
description 决定上岗机会，正文决定工作质量。 这是 Skill 设计最重要的分工。
好 Skill 不只是会做，还知道什么时候别做。 能忍住不乱触发，往往比“能处理很多场景”更高级。
跨框架迁移 Skill，迁移的是经验，不是文件。 如果你是从 Claude Code 转过来的，这句话值得记一下。
装上 Skill 是体力活，用好 Skill 才是脑力活。 装上只是把工具箱放进房间，真正的价值在于你有没有把它用到位。
折腾了一圈，反而更看重它了
挺有意思的是，折腾了这一圈之后，我反而比之前更看重 OpenClaw Skill 这套东西了。
因为我慢慢意识到，OpenClaw Skill 真正有意思的地方，不是它“也能写个 Skill”，而是它更逼着你去思考：你的 Agent 到底怎么工作，你的工具规则到底怎么定义，你的能力模块到底怎么分层，你的经验到底怎么沉淀成可复用资产。
相对而言，Claude / Anthropic Skill 更侧重增强模型能力，而 OpenClaw Skill 更像是在建设自己的 Agent 工作系统。
一旦你开始从这个角度理解它，Skill 这件事就不只是“会不会写一个 SKILL.md”了。它会慢慢变成一种更长期的能力：把自己做事的方法，沉淀成 Agent 也能复用的工作资产。
以前，我们说一个人有经验，那份经验只在他脑子里，带不走、传不了、没法复用。但如果你能把这套经验写进 Skill，让 Agent 也能按这套方法做事，那这份经验就从“只属于你”变成了“可以持续工作”的东西。
这有点像把知识从“存在脑子里”变成“存在系统里”。
不只是工程师的事，越来越多重度使用 AI 的人，迟早会面对这个问题：我积累下来的做事方法，有没有办法让 Agent 也真正用起来？
折腾 Skill 的过程，其实就是在回答这个问题。
如果你也在折腾 OpenClaw，不妨先问自己一个问题：你有没有一个 Skill，是你真正愿意长期维护、持续打磨的？
如果有，你已经开始建设自己的 Agent 工作系统了。
