一句话概括：Claude Skill 更像“让模型会”，OpenClaw Skill 更像“让系统管”。
这篇文章我想让 AI 写，不是因为 Skill 这个词有多新，而是因为最近在走访一些伙伴和客户，隐隐之中，感觉在中国市场已经开始走上一条“智能体”的老路。
从个人而言，我觉得 openclaw 对中国 toB 软件影响和意义更为关键，本质上：
从会用 AI 的人淘汰不会用 AI 的人，已经转变到了“会给 Agent 当老板”的人淘汰“不会给 Agent 当老板”的人
以下内容主要是AI 从 Claude 和 OpenClaw 两个平台的 skill 能力与机制来对比，但实际上我觉得 toB 行业可能会有更底层的软件开发及应用产业链的改变，AI 的分析还是比较表层，今天不展开了。
=====以下是 AI 撰写分割线=====
过去几年，智能体这个概念在国内已经被讲得太多了。很多公司一边说自己在做 Agent，一边其实只是把工作流、多轮对话、工具调用，甚至只是一个套壳问答，重新包装成了“智能体”。概念一热，定义就开始膨胀；定义一膨胀，市场就开始失真。最后，真正做能力沉淀的人没被看见，反而是最会包装概念的人把声音做大了。
很多团队今天讲 Skill，并不是在讲如何把一项专业能力沉淀成可复用、可调用、可治理的单元，而是在把它当成一个新的包装词。原来不好意思继续叫 Agent 的，现在改叫 Skill；原来只是 prompt 模板的，现在也叫 Skill；原来只是加了一层工具编排的，也叫 Skill。结果就是，概念又开始被炒热，但行业理解反而更混乱了。
所以我想写这篇文章，不是想再给 Skill 这个词添一把火，恰恰相反，我是想把它往下拽一拽，拽回到能力边界和系统边界里来看。
同样叫 Skill，Claude 和 OpenClaw 说的并不是一回事。
一、先别急着问谁更先进，先看它们各自在解决什么问题 链接到标题
Claude 想解决的问题，本质上是：如何把一段可复用的专业能力，变成模型可以自动发现、自动调用的工作流单元。
这也是为什么 Anthropic 官方文档里反复强调几个点：一是 Skill 是模块化能力；二是 Claude 会在请求相关时自动使用；三是它采用分层按需加载，先让模型知道有哪些 Skill，再在触发后读取 SKILL.md 和额外资源，以降低上下文占用。Claude 还明确把 Skill 内容分成元数据、主说明、附加资源/代码三个层级来组织。
换句话说，Claude 的 Skill 更像一种 capability packaging。它的重点不是“把提示词写长”，而是把“何时触发、读取什么、怎样复用、如何减少上下文污染”组织成一个模型可以稳定调用的能力对象。
OpenClaw 想解决的问题则更偏平台工程：如何把 Agent 的能力做成可安装、可配置、可筛选、可更新、可同步、可分发的模块。
OpenClaw 文档里最醒目的不是 prompt，而是运行机制：Skills 会从内置目录、用户目录和工作区目录三层加载，冲突时有明确优先级；还可以通过额外目录扩展；并且会基于操作系统、二进制是否存在、环境变量、配置项等条件做加载时过滤。
这说明 OpenClaw 的 Skill 已经不只是“模型怎么学会一件事”，而是“平台怎么把一项能力纳入治理体系”。
二、真正的差别，不在文件结构，而在系统边界 链接到标题
如果只看表面，Claude 和 OpenClaw 的 Skill 确实很像。
两边都强调 SKILL.md；两边都强调 description；两边都不是把 Skill 当普通 prompt，而是把它当成带元数据、说明和资源的能力包。Claude 官方要求 Skill 通过 YAML frontmatter 描述名称和用途，并在相关时自动触发；OpenClaw 也明确说自己遵循 AgentSkills 的布局和意图。
但真正决定它们不是一回事的，不是目录长得像不像，而是系统边界完全不同。
Claude 的边界主要在模型侧。它关心的是：这个能力什么时候该被模型用上？被用上以后，模型应该读取什么？怎样把未触发的内容留在文件系统里而不占上下文？
OpenClaw 的边界主要在平台侧。它关心的是：这个能力从哪里装载？是否满足运行条件？是否应该进入当前 run？是否要注入 env 或 apiKey？是否只暴露给用户命令？是否可以跳过模型直接到工具？是否能够通过注册中心搜索、安装、更新和发布？
所以，虽然两边都叫 Skill，但它们抽象的其实不是同一个对象：Claude 抽象的是“能力如何被模型调用”；OpenClaw 抽象的是“能力如何被平台装载、治理和分发”。
三、一张图看懂：Claude Skill 与 OpenClaw Skill 的本质差异 链接到标题
| 对比维度 | Claude Skill | OpenClaw Skill | 一句话判断 |
| 本体定位 | 更像模型侧能力封装 | 更像平台侧能力插件 | Claude 更偏“让模型会做”；OpenClaw 更偏“让平台能管” |
| 核心目标 | 把领域知识、方法和工作流教给模型，让模型在相关时自动调起 | 把能力纳入加载、过滤、配置、命令、安装、分发体系 | 一个偏 capability packaging，一个偏 capability operations |
| 触发方式 | 以 description 为入口，模型自主判断何时使用 | 既可模型调用，也可 user-invocable 显式触发，还可 command-dispatch: tool 直接路由到工具 | Claude 偏语义触发，OpenClaw 偏平台调度 |
| 上下文/运行方式 | 分层按需加载，尽量减少上下文占用 | 先看 eligibility，再把有资格的 Skills 纳入当前 run | Claude 重视上下文效率，OpenClaw 重视运行资格 |
| 依赖管理 | 更强调 instructions、resources、scripts 如何服务模型推理 | 更强调 env、apiKey、binary、config、sandbox 等运行条件 | OpenClaw 更像真正的运行时系统 |
| 命令系统 | slash command 是补充入口，本质仍围绕模型能力 | slash command 已经是平台能力，可直达 Skill 或工具 | OpenClaw 的命令系统更平台化 |
| 加载层级 | 更像模型发现和读取能力 | 明确有 bundled / local / workspace / extraDirs 的优先级 | OpenClaw 更像插件系统 |
| 生态与分发 | 更适合企业内部 workflow 标准化与知识沉淀 | 更适合做能力市场、注册表、安装更新同步 | OpenClaw 已明显往技能市场演进 |
| 更适合的产品方向 | 专家型 Copilot、知识型助手、行业智能助手 | Agent 平台、企业工作台、插件生态平台 | 一个更像智能专家层，一个更像能力操作系统层 |
这张表背后的事实基础并不复杂：Claude 官方文档强调自动相关触发、文件系统承载和按需加载；OpenClaw 官方文档强调 AgentSkills 兼容、目录优先级、前置过滤、命令暴露、环境注入和 ClawHub 分发。
所以，同样叫 Skill，Claude 和 OpenClaw 抽象的并不是同一个对象。这不是术语差异，而是产品路线差异。
四、放进具体场景里看，就更容易理解它们为什么不是一回事 链接到标题
场景 1：做一份银行客户周报 PPT 链接到标题
假设一个销售说：“帮我把这周几家银行客户进展整理成一份汇报 PPT。”
在 Claude 的语境里，更像是：系统里已经有一个做 PPT 的 Skill。Claude 先看 description，判断当前请求是否相关；如果相关，就读取 SKILL.md，再按需调用模板、脚本和资源去完成任务。
在 OpenClaw 的语境里，更像是：平台先判断这个 PPT Skill 是否已安装、在哪一层目录、是否满足运行条件、是否被禁用、是否需要注入 API Key、是否作为 slash command 对外暴露；然后才决定它是否进入当前 agent run。
所以同样是“做 PPT 的 Skill”，Claude 更像在回答：模型怎样学会这件事；OpenClaw 更像在回答：系统怎样把这件事装进去、管起来、分发出去。
场景 2：做一个“招投标应答 Skill” 链接到标题
比如一家金融科技公司，想把“读招标文件—抽取要求—匹配产品能力—生成应答初稿”沉淀成一个 Skill。
如果放在 Claude 的语境里，这更像一个“组织经验包”。你把流程、注意事项、过往优秀案例、输出模板、辅助脚本全部放进 Skill 目录，让 Claude 在遇到相关任务时自动调用。
如果放在 OpenClaw 的语境里，平台团队会继续关心一堆运行时问题：它是全局共享还是某个 workspace 独享？放在
所以这里的差别是：Claude 侧重点是把专业做法封装给模型；OpenClaw 侧重点是把企业能力纳入平台运行体系。
场景 3：客服运营团队做“质检分析 Skill” 链接到标题
再比如，一个客服主管说：“把昨天 500 通录音做情绪识别、违规话术检查和改进建议。”
在 Claude 这边，最自然的做法是把质检规则、评分标准、标签体系、输出格式要求封装进 Skill，让 Claude 在质检任务出现时自动拿起这一套方法。这里 Skill 更像“业务专家包”。
在 OpenClaw 这边，除了规则本身，平台还会继续考虑：这个 Skill 是否依赖外部工具或二进制？是否需要环境变量？在宿主机运行还是 Docker 沙箱里运行？如果在沙箱里，宿主机的 env 默认不会继承进去，该如何配置？
这就是为什么我会说：Claude 的 Skill，更像能力说明书 + 操作手册；OpenClaw 的 Skill，更像能力包 + 运行插件。
场景 4：给一线团队开放成显式命令 链接到标题
不是所有能力都适合“让模型自己判断要不要用”，有些能力就是希望用户显式触发。
在 Claude 体系里，slash command 是一个入口，但重点仍然是模型会不会在适当时机调用相关能力。Claude SDK 也支持自定义 slash commands，不过它们与 Skill 是相关但不等同的两层机制。
在 OpenClaw 体系里，slash command 明显更平台化。user-invocable 的 Skill 可以暴露成命令；默认命令仍可交给模型处理，但如果 Skill 声明 command-dispatch: tool，就能直接绕过模型，走确定性工具路径。
这背后的思路差异非常大：Claude 是在说，这个能力既可以被人叫出来，也可以被模型想起来；OpenClaw 是在说，这个能力除了给模型用，还可以成为平台的命令系统和工具网关的一部分。
五、Claude 的 Skill 和 OpenClaw 的 Skill，对 to B 软件真正的启发是什么？ 链接到标题
1）更适合 Claude 式 Skill 的，是“知识密集型、判断密集型、工作流非完全确定型”的软件 链接到标题
如果一个软件的核心价值在于：不是替用户点击按钮，而是替用户调用专业知识、行业经验、模板方法和判断框架，那它更适合往 Claude 这条路上走。
比如这些场景就很适合：
·金融/政企售前：招投标应答、方案撰写、客户拜访纪要整理、竞品对比
·客服运营：质检分析、会话复盘、坐席辅导建议、服务策略生成
·数据分析产品：从“报表工具”走向“会分析数据的业务助手”
·法务/合规产品：合同审阅初稿、条款比对、合规检查清单生成
·企业知识产品：把 SOP、案例、最佳实践真正变成模型可调用的工作包
这些场景的共性是：任务并不完全确定，但专业方法很重要。
Claude 的 Skill 机制之所以适合这类软件，是因为它天然适合沉淀领域知识、模板、脚本和最佳实践，并让模型在相关任务里按需取用，而不是每次都靠人手工复制一段提示词。
如果一家 to B 软件公司更适合走这条路，那产品上通常要做三类改变：第一，要把原来散落在实施文档、培训手册、售前模板里的经验，重新整理成能力包；第二，要让模型具备“自动想起这些经验”的机制；第三，要建立一套围绕 Skill 的评估体系。
2）更适合 OpenClaw 式 Skill 的，是“集成密集型、权限敏感、流程确定性强”的软件 链接到标题
如果一个软件的核心价值在于：它要接很多系统、调很多工具、处理很多权限和运行依赖，而且很多操作最好是确定性执行，那它更适合往 OpenClaw 这条路上走。
比如这些场景更贴近 OpenClaw 的思路：
·企业运营工作台：跨 CRM、ERP、工单、IM、日历、邮件的统一操作
·运维 / IT 自动化平台：告警处理、脚本执行、变更操作、巡检流程
·内部办公助手平台：显式命令触发请假、报销、工单、日程、审批
·多团队协作平台：不同部门、不同租户、不同 workspace 装配不同能力包
·ISV 生态平台：让合作伙伴发布、安装、升级、回滚各类能力扩展
这些场景的共性是：能力不仅要被“理解”，更要被“治理”。
OpenClaw 的 Skills 之所以更像插件系统，就是因为它把企业软件最头疼的问题直接拉进了 Skill 本身：依赖是否存在、环境变量怎么注入、能力对谁可见、是模型调用还是用户命令触发、能不能直接走工具、如何安装更新同步。
如果一家 to B 软件公司更适合走这条路，那产品上通常要做四类改变：第一，要把能力抽象成可安装、可版本化、可配置的运行单元；第二，要有清晰的能力装配层；第三，要有治理层；第四，要有分发层。
3）未来大多数成熟的 to B 软件，最后会走向“双层 Skill 架构” 链接到标题
我自己的判断是，未来大多数成熟的 to B 软件，最后不会只选 Claude 式或 OpenClaw 式其中一种，而会形成一种双层结构：上层是 Claude 式 Skill，负责让模型具备领域理解、方法调用和内容生成能力；下层是 OpenClaw 式 Skill，负责把工具、系统、权限、环境和分发治理起来。
也就是说：上层解决“会不会”；下层解决“能不能、稳不稳、可不可控”。这两层叠在一起，才比较像真正成熟的企业 AI 软件。
比如一个金融行业 AICC 产品，往上看，它需要“投诉分析 Skill”“质检复盘 Skill”“营销策略 Skill”这类专家型能力；往下看，它又必须处理 CRM、工单、录音、知识库、权限、审批、租户隔离这些平台型问题。前者更像 Claude 式 Skill，后者更像 OpenClaw 式 Skill。
4）对国内 to B 软件厂商来说，真正的挑战不是“会不会讲 Skill”，而是组织要不要重构 链接到标题
这件事说到底，不只是产品里多一个新名词。
如果你真的想把软件做成 Skill 驱动的产品，组织上至少要变三件事：第一，产品定义方式要变；第二，交付方式要变；第三，商业模式也可能要变。
一旦 Skill 真变成能力单元，它就不只是交付物，也可能成为增值包、行业包、伙伴包、市场包。那时候卖的就不只是 license，而是能力资产。
六、为什么这件事重要：Skill 正在从 Prompt 资产，变成运行时资产 链接到标题
很多人今天谈 Skill，还停留在“它是不是更高级的 prompt 模板”。
这其实低估了它。
如果只是模板，它最多解决“复用文字说明”的问题；但从 Claude 到 OpenClaw，这个概念已经在往前推进。Claude 把 Skill 变成模型可发现、可按需加载、可复用的专业能力；OpenClaw 则进一步把 Skill 变成可安装、可配置、可筛选、可更新、可同步和可分发的运行时单元。
这意味着，Skill 的价值正在发生变化。
过去，一个组织沉淀 AI 经验的方法，更多是保存 prompt、写 SOP、做知识库；而现在，Skill 试图把这些经验变成系统真正可以调用、装载、治理和复用的能力对象。它不再只是文档资产，而开始像一种软件资产。
从这个角度看，Claude 和 OpenClaw 其实不是谁对谁错，而是走在同一条演化曲线上，只是停在了不同位置：Claude 更靠近模型侧的能力封装；OpenClaw 更靠近平台侧的能力运营。
七、真正值得警惕的，不是 Skill 火了，而是 Skill 又要被讲滥了 链接到标题
今天市场上很多人把 Skill 当成 Agent 之后的新包装词，但真正值得关注的，不是名称有没有变，而是能力单元的边界有没有变。
如果一个所谓的 Skill，既不能提升模型在某类任务上的稳定表现，也不能被系统装载、治理和分发，那它大概率只是换了名字的 prompt、workflow，或者 demo 外壳。
这也是我真正想提醒市场的一点：Skill 不是一个更时髦的词，Skill 应该是一种更严肃的能力封装。
如果我们最后只是把 Agent 这个词讲烂之后，再把 Skill 也讲烂一遍，那行业并没有进步，只是换了一层新的遮羞布。
八、最后的判断 链接到标题
如果一定要用一句话来概括这篇文章，我会这样写：Claude Skill 的重点，是让模型更稳定地复用一种能力；OpenClaw Skill 的重点，是让平台更系统地治理一种能力。
所以，这场讨论真正值得关注的，并不是“哪个产品也用了 Skill 这个词”，而是：Skill 正在从“模型提示词的复用方式”，演化成“Agent 时代的能力封装与分发单元”。
前者偏 capability packaging，后者偏 capability operations；前者更像在定义“怎么让模型会”，后者更像在定义“怎么让系统管”。
这，才是 Skill 这个概念真正有价值的地方。也是为什么今天我们必须尽快把它从炒作里拽回来，重新放回能力建设和系统建设的语境里。
参考资料 链接到标题
Anthropic, Agent Skills Overview — https://platform.claude.com/docs/zh-CN/agents-and-tools/agent-skills/overview
Anthropic, Agent SDK Slash Commands — https://platform.claude.com/docs/zh-CN/agent-sdk/slash-commands
OpenClaw, Skills — https://docs.openclaw.ai/zh-CN/tools/skills
OpenClaw, Skills Config — https://docs.openclaw.ai/zh-CN/tools/skills-config
OpenClaw, ClawHub — https://docs.openclaw.ai/zh-CN/tools/clawhub