中国互联网的两大流量盘，几乎是挤在同一个时间窗口，做了同一个方向的大动作。

先是6 月 2 日，英国《金融时报》曝出微信正在内测内嵌 AI Agent，能连接小程序帮用户办事；6 月 8 日，微信公开了小程序接入 AI 的 Skill 技术规范，京东、美团、滴滴等当即宣布接入。

而后，6 月 15 日，蚂蚁释放出信号，在内测“AI 版支付宝”，让用户一键切换，进入一个全新的、以对话驱动的支付宝，可调用百万生态内小程序。

在具体的接入方式上，支付宝和微信小程序AI相似，一边推动有意愿的商户主动接入，把自己的服务做成 AI 可直接调用的 MCP/Skill；一边在用户授权下，由 AI 通过对界面的 “读屏” 操作，兼容尚未改造的小程序。

至此，一个社交超级 App，一个支付基础设施，都在这个时刻将小程序Skill化了。

两者的动作都不小，背后的焦虑也很明显。当豆包已经杀到门前，随着用户量的激增，对微信和支付宝的基本盘已经开始产生直接的冲击，人们使用微信和支付宝的方式，微信和支付宝为人们提供服务的方式，以及这两大国民级平台与它上面数以亿计的服务商之间的关系，都会迅速改变。

怎么办？

微信和支付宝在应对的第一步上，做了同一个选择，就是直接利用过去十年沉淀的数以百万计的小程序，把这些庞大的自家存量资产就地翻译成 Skill。

把小程序做成Skill，借此留住对服务单元的定义权

这件事的底层动作，可以用一句话概括：把一个分发资产，改造成一个调用资产。

分发资产的逻辑是“用户主动点开”。

过去十年，一个小程序值钱，是因为它能被微信的入口、支付宝的九宫格、搜一搜、服务通知分发到用户面前，用户看见、点开、使用。平台是渠道，小程序是货。

调用资产的逻辑完全不同：它值钱，是因为 AI 在听懂你一句“帮我点杯不太甜的拿铁”之后，能直接把它当成一个工具调起来，补齐参数、完成下单。用户不再“看见”它，AI“调用”它。

所有人正在争夺的就是这个“调用资产”的定义权，即过去十年沉淀下来的小程序、商家、服务能力，这些会被 AI 调用的服务单元，归谁定义、按谁的标准打包、最后在谁那里收单。

而定义权落到实处，就是各自制定一套调用标准。

以微信位为例，在微信官方小程序AI开发文档里，它的规范写得很细：AI 最该优先看接口返回的内容，其次是接口描述，Skill.md 反而排在最后；接口返回要用“事实 + 动作”两段式，先告诉 AI 发生了什么、再告诉它下一步能做什么；参数尽量传 storeId、drinkId 这样的 ID，别让模型从自然语言里自己猜。

更关键的，是微信提到，它做的不是通用 MCP。这套 Skill 的原子接口，是注册在小程序里、跑在微信客户端一个隔离环境里的函数，微信之外的 AI 客户端根本连不上；外形上它沿用了 MCP 的约定，骨子里却是一个只在微信内生效的“小程序版 MCP”。

围着它，微信还加了一长串限制：Skill 必须装进独立分包、一个小程序最多 30 个，AI 卡片不能上下滚动，想把用户导去小程序原页面的“文字链”被明确定义成兜底手段、用多了还会被降权——一切都要在它的 AI 对话里闭环。

尽管支付宝目前还没有相关的开发文档，但和微信一样，谁抢先把规范立起来，把更多的供给端拉进来，就更有概率把供需两端绑在自己的生态中。

与此同时，它们各自的处境，也很不一样。

微信的底牌最稳，包袱也最重。

它的小程序本就是“用完即走”，加上它对自家生态有近乎“上帝视角”的掌控——每个小程序从提交、审核到运行都在它手里，它能在审核阶段直接把源码扫成 Skill，开发者一行代码不用写。

但它的 AI 入口在负一屏，要小心翼翼地兼顾那套已经很牢固的旧秩序：社交关系、一以贯之的克制。比如，微信的 Agent调用Skill，大概率不会主动给用户推送服务——因为它要延续小程序“用完即走”的属性，而不是做一个时时打扰你的 proactive agent。能力它都有，但每一步都得迁就存量。

支付宝可以更激进。

它没有社交的包袱，干脆做“一键切换”，把整个 App 换成对话版。但它也面临挑战：支付宝长期被用户定义成“付钱时才打开”的工具，从 2024 年发布“支小宝”折戟、到 2025 年放弃独立 App 调头回主端，它反复试的就是怎么让一个工具变成值得对话的服务入口。

长期挑战：Skill本身是“反超级入口”的

这些动作背后有同一种情绪：慌。

慌的源头有个原因——豆包。或者说豆包代表的那条路线：纯 AI 原生入口。

字节用做消费 App 的方法论，靠学习辅导、语音陪伴、影像创作，把豆包养到了三亿多月活，它代表的是“AI 作为独立入口”——训练用户主动来找 AI。

这条路一旦走通，意味着用户的需求会越来越多地在一个全新的、跟微信支付宝无关的入口里被接住。

对微信和支付宝来说，真正的威胁不是“豆包会不会写 Skill”，写 Skill 是技术问题，谁都能学。真正的威胁是时间：谁能抢在豆包这类纯 AI 挑战者养成用户习惯之前，把自己十年攒下的现成服务模块，改造成 AI 能调用的层。

豆包的短板恰恰是它没有这些存量，它要从零接服务。而微信和支付宝最不缺的就是这个。它们的 Skill 化，本质是一场抢跑：用存量优势，把“服务能力”这道护城河，在挑战者补齐之前先 AI 化。

这也解释了一个细节：为什么今天这些放出来的 Skill，看起来都像是“给 AI 写的 SOP、操作手册”——一份告诉 AI“这家店有什么、怎么点、怎么付”的说明书，而不是让商家真正为了AI的新基础设施而按照新的逻辑重做。因为它们要的就是快，Skill 在这里被定位成一个“再打包层”：底下的服务不动，上面套一层 AI 接口。

但这个用Skill守住入口的故事里，还藏着一个很难解的矛盾——Skill能不能、应不应该被绑定在入口里？

小程序的分发逻辑是“用户主动点开”，Skill 的分发逻辑是“AI 主动选择调用”。 这两个逻辑，指向的流量分配权，在两个完全不同的人手里。

过去，一个小程序能不能火，取决于平台运营怎么给它分发位、用户愿不愿意点。流量分配权，握在“平台 + 用户”手里。

现在，一个 Skill 会不会被用上，取决于模型在理解了用户意图之后，从一堆能力里挑了谁、怎么编排。流量分配权，从平台运营和用户的手，转移到了模型的意图理解里。入口第一次不再是“用户必须经过的那扇门”，而退化成了“模型可以选择经过的其中一条路”。

更要命的是 Skill 这个形态本身的一个属性：它可组合，可跨端调用。 一个标准化的 Skill，天生就不独属于任何一个 App。

哪怕今天诸多厂商在配合着两大平台的skill化改造而快速上线说明书式的skill，但依然有很多厂商已经开始做打破边界的它们自己的skill。比如瑞幸，它没有满足于只做微信和千问的“店内 Skill”，而是自己上线了一个 AI 开放平台，把点单能力做成标准的 MCP、CLI、Skill 三种形态放出去——这意味着任何支持这些协议的 AI 工具，codebuddy、Claude Code、Codex、Kimi Code，都能直接调起瑞幸点一杯咖啡。肯德基官方也已经支持 MCP。

一个商家想明白“我的服务能力可以变成一个谁都能调的标准件”时，它就没有理由把自己锁死在某一个超级 App 的店内。

微信、支付宝想用“把小程序变 Skill”这一招，守住自己作为入口的地位。但 Skill 这个东西的本质是标准化、可组合、可跨端的，它恰恰是反“超级 App 入口”的。这个深层的矛盾，注定会变成接下来微信和支付宝与豆包们越来越短兵相接的AI竞争里的一个最大变量。

作者：黄小艺

来源：硅星人Pro

千问今日宣布，将向第三方Agent、Skill全面开放，所有企业均可在千问中运营自己的品牌Agent。

据悉，企业可以在千问APP中自定义Agent人设、服务能力与边界，并通过对话形式向用户提供各类产品和服务。

与传统App、小程序或客服入口不同，品牌Agent将以自然语言交互为核心，用户无需反复切换应用或查找功能入口，只需直接表达需求，即可由Agent理解意图并完成相应操作。

这意味着，企业在千问中拥有的不只是一个智能客服，而是一个可以持续运营、理解用户偏好并主动服务的品牌智能体。

据悉，瑞幸咖啡、肯德基、蜜雪冰城、东方航空等首批企业目前正在千问进行Agent服务测试，并将陆续上线。

根据规划，瑞幸咖啡Agent可结合用户习惯和消费场景，主动提醒用户“中午排队时间长，建议提前半小时点单”，帮助用户更高效地完成消费决策。

东方航空Agent未来可在深入理解用户出行计划和旅行偏好的基础上，针对旅客需求智能推荐行程方案，并一站式解决出行服务。

随着第三方Agent全面接入，千问也将进一步强化“超级Agent”的定位。

用户只需用自然语言表达需求，即可在千问中完成各类任务和服务。

千问将不再只是回答问题的AI工具，而是一个能够调度不同品牌Agent和Skill、帮助用户完成真实任务的个人助手。

对企业而言，千问开放第三方Agent也意味着一个新的AI运营阵地正在形成。

过去，品牌主要通过App、公众号、小程序、电商平台、外卖平台等渠道触达用户；

进入AI Agent时代后，品牌还需要运营一个能够代表自己与用户对话、提供服务并完成转化的智能体。

企业可通过千问自定义Agent人设与服务边界，在保持品牌表达一致性的同时，提升客服、导购、会员运营、复购转化和用户服务效率。

从首批接入企业来看，瑞幸咖啡、肯德基、蜜雪冰城和东方航空均属于高频消费与生活服务场景，用户需求明确、服务链路清晰，也更适合通过AI Agent提升效率。

餐饮茶饮品牌可围绕点单、优惠、排队提醒、会员权益和复购推荐提供服务；

航空公司则可围绕行程规划、航班提醒、出行偏好和旅客服务进行智能化升级。

千问向第三方Agent、Skill全面开放，标志着AI应用竞争转向生态服务能力的比拼，谁能接入更多高频服务，谁能让用户以更自然的方式完成更多真实任务，谁就更可能成为AI时代的重要入口。

随着更多企业加入，千问有望成为用户连接品牌服务的新入口。

我认识一个写后端的哥们儿，将将入坑 Claude Code 那阵子，跟打了鸡血似的，把市面上能找到的 skill 一口气装了 8 个。代码生成的、数据库迁移的、写测试的、画架构图的、解释报错的、查 API 文档的，他说自己这是”武装到牙齿”。

装完那天他在群里发：以后写代码省心了，token 也省了，官方都说渐进式披露能省 98%。

一个月后他在群里又发：API 账单涨了三成多，咋回事？

他自己琢磨了好几天没琢磨明白，最后干了一件挺反人类的事——把那 8 个 skill 卸载到只剩 2 个。下个月账单回落。

我听完这事儿心里咯噔一下。这不就是当年大伙儿装 Chrome 插件那剧本么——装的时候觉得自己赚了，用的时候发现浏览器越来越卡，最后清空插件那一刻才意识到，原来卡的不是 Chrome，是自己。

对了，我那哥们儿用的是 API，不是订阅版，所以每个 token 对他来说都是真金白银。你要是 Pro 用户感知可能没这么强，但机制是一样的，往下看就明白了。

这篇要说的就是这事儿。skill 不是不省 token，是它省 token 的方式跟你想的不一样。官方文档把好的那一面写得明明白白，issue 区里一片”为啥没省”的哀嚎也是真的。这中间的落差，不是 skill 这个机制有毛病，是用 skill 的人没搞清几件事。咱挨个唠。

一、skill 到底是个啥？跟你天天写的 prompt 差在哪

要把 skill 省不省 token 这事儿讲清楚，得先把 skill 是个啥讲清楚。我发现很多人把 skill 当成 prompt 的”豪华版”——这个理解是错的，错得还挺离谱。

prompt 你天天写。一个问题来了，你敲一段话，把背景、要求、格式、例子全塞进去，发给模型。模型读完，回你一段。这事儿完了，下一个问题来了，你又得重新敲一遍——或者把上一段 copy 过来改几个字。

prompt 是消耗品。你每次发问，它就被烧一次。烧的就是 token。

skill 不一样。skill 是你提前把一套”知识 + 流程 + 规范”打包好，挂在那儿。它有个名字、有段描述、有个正文。平时它就躺着，啥也不干。等你某次问题碰到了它管辖的领域，模型自己判断”哦这事儿归它管”，再把它的正文调出来用。

打个比方你就明白了。prompt 是你每次出门都得现穿一遍的衣服——没洗的脏的湿的，每次都得翻箱倒柜重新搭一套。skill 是你衣柜里挂好的成套西装——平时不动它，要正式场合了，往身上一套就出门。

差别看着小，账算起来差得远。

prompt 是显性消耗。你写多长，模型就读多长，烧多少 token 一目了然。这块儿没啥可讨论的，写多了费、写少了省，谁都懂。

skill 是隐性常驻。skill 的正文确实是按需加载的——你不碰它它就不出场。但它的描述不一样，描述是常驻的。你每发一次问题，模型都得把所有装着的 skill 描述扫一遍，决定要不要召唤谁。

这就是 skill 省 token 跟 prompt 省 token 走的不是一条路。prompt 省 token 靠”写得短”，skill 省 token 靠”挂得准”。挂得准，正文按需加载，省得明明白白。挂得不准，描述常驻烧钱，还可能误召唤把正文也拽出来，赔了夫人又折兵。

所以那些把 skill 当成”加强版 prompt”的人，第一步就走偏了。他们以为 skill 像 prompt 一样越多越好——多装一个就多一种能力。其实 skill 像衣柜——装太多衣柜挤不下，每天找衣服都费劲。

总之，这俩根本就不是一个路数的东西。搞不清楚这个，后面说啥都绕。

二、官方说的渐进式披露，省的是哪一段，没省的是哪一段

skill 省 token 这事儿，官方文档说得挺漂亮，叫渐进式披露。听着像个学术名词，其实意思特简单——东西按需要逐步亮出来，不需要的时候不亮。

具体怎么省呢？你想象一下没 skill 的时代，怎么干活的。

你要写一个 Python 测试，又想让模型遵循团队的某套规范——比如必须用 pytest、必须有 fixture、必须 mock 数据库、必须覆盖边界用例。这些规范加起来三五千字。没 skill 之前你咋办？把这三五千字全塞进 prompt 里，每次提问都塞一遍。一天问十次，烧三五万 token，光这一项。

skill 来了之后，这套规范你打包成一个 skill，挂在那儿。你下次只要问”帮我写个测试”，模型一看描述，哦这归”Python 测试规范”这个 skill 管，把它的正文加载进来，开始干活。

省在哪？省在你没问到的那 99 次问题里，这三五千字一个 token 都没烧。

这个机制是真的。官方没骗人。

但官方没说透的是另一面——描述是常驻的。

每个 skill 都得有个描述，告诉模型”我是干啥的、啥情况下该召唤我”。这个描述虽然短，几十到一两百 token 不等，但它每一次对话都在场。你装一个 skill，对话上下文里就常驻一段描述。装五个，常驻五段。装二十个，常驻二十段。

这就是那个”长账”。

单次对话里这点描述塞进去无关痛痒，比起一个完整 skill 正文动辄几千 token，确实是九牛一毛。但只要你装得多、用得勤，它就在那儿默默累加。

我估摸着算了一下——这数字不精确，你别拿去跟官方掰扯，但逻辑是对的：假设每个 skill 描述平均 80 token，你装了 20 个，每次对话光描述这块就 1600 token 常驻。一天跟 Claude 唠 50 个来回，那就是 8 万 token 在烧”我有这些 skill 待命”这件事——而其中也许只有 5 个 skill 当天真的被召唤过。

剩下的 15 个，整天躺着收”挂号费”。

所以渐进式披露省的是变量——skill 正文按需加载，没用到的就不烧。但它没省常量——描述是固定开销，装多少就常驻多少。

省了大头，还是省了。这账长期看大概率是赚的。但前提是——你装的 skill 真的会被用上。如果你装了一堆”以备不时之需”，结果两个月一次都没召唤过，那这堆 skill 的描述就是纯纯的烧钱常量，半点用没有。

这就解释了开头那哥们儿账单为啥涨。他装的 8 个 skill 里，大概有一半儿是”看着挺酷就装上”的——画架构图的、画 ER 图的、生成单元测试覆盖率报告的，这些他实际工作里一个月用不上一次。但它们的描述每天每时每刻都在他的上下文里站岗。

所以 skill 省 token 是真的，但它只在你真用得上的那部分身上省钱。装多了，省的没省那么多，烧的反而比想的多。但这还不是最离谱的——最离谱的是下面这件事。

三、烂描述比不装还烧钱——误触发是隐形税

刚才说常驻的描述每天躺着收挂号费，那是温和的烧法——一点一点烧，你不细看账单根本注意不到。

下面这种烧法是暴力的——一下子就给你撅好几千 token，你都不知道为啥。

这事儿叫误触发。

误触发的原理特简单：你的 skill 描述写得模糊，模型分不清啥时候该召唤它。本来不归它管的问题，模型一犹豫，也把它召唤进来了。这一召唤可不是召唤个描述，是把整个 skill 的正文——动辄几千上万 token——全部塞进上下文。

你问一句”今儿天气咋样”，结果它给你召唤进来一个写测试的 skill。这 skill 正文五千字，全是 pytest 怎么用、fixture 怎么写、mock 怎么 mock。跟天气有一毛钱关系吗？没有。但这五千字已经塞进去了，已经烧了。

这就是隐形税。你交了钱，连个吭都没听见。

烂描述长啥样？我光凭记忆就能给你列出一堆，但最常见的就这几种。

一种是描述太宽泛。比如有个 skill 叫”代码助手”，描述写的是”帮助处理各种代码相关问题”。这描述等于没写——啥问题不算代码相关？你随便问一句”我这函数咋优化”，它跳出来；你问一句”数据库咋选”，它也跳出来；你问一句”Linux 命令怎么用”，它还跳出来。这 skill 一天召唤十几次，召唤进来又没派上用场——因为它根本不是为这些具体场景准备的。

还有一种是关键词堆砌。有些人写 skill 描述跟写 SEO 标题似的——把所有沾边的词都堆上：”Python、JavaScript、Go、Rust、TypeScript、代码生成、代码审查、性能优化、bug 修复、架构设计……” 堆得越多，模型越分不清重点。结果就是只要问题里有任何一个词命中，它就跳出来。

最隐蔽的一种是意图模糊——描述只说了”做什么”，没说”什么情况下不该用”。一个好的描述应该是”当用户问 X 类问题、且不是 Y 情况时召唤我”。但大部分人写的描述只有前半句，后半句省了。模型没有边界，就只能宁可错杀不可放过。

这几种烂描述合起来一个效果——你装了一堆 skill，它们互相之间没有清晰的边界，每次对话都在抢着出场。出场不仅没解决问题，还每次给你白烧几千 token 的正文。

我那哥们儿账单涨三成，大头其实就在这儿。他装的 8 个 skill 里有 3 个描述写得稀烂——”帮你写更好的代码””提供专业建议””解决你的开发难题”——这描述比没描述还坑，因为它让模型完全无法判断边界。结果就是几乎每次对话都把这仨揪进来，每次都烧三千多 token，三千多 token 啥也没干，就是白塞了一段不相干的指令。

skill 描述写不好，不是没省钱的问题，是反过来比不装还烧钱的问题。不装它，你顶多是 prompt 写得长点儿——你写多少烧多少，明明白白。装了它写得烂，你每次对话都被一个莫名其妙的 skill 正文”加塞”，你都不知道自己付的是啥钱。

这事儿听起来挺玄学，其实有个挺简单的自检方法——你打开 Claude 跟它聊一天，每次它召唤 skill 的时候你都问一句”刚才召唤这个 skill 是必要的吗”。聊一周下来你心里就有数了——哪几个 skill 出场频率高得离谱，那就是描述有问题，得重写或者直接卸载。

可大部分人不会这么干。大部分人装上 skill 就完事儿了，从来不回头审。所以才有那么多人抱怨”skill 不省 token”——不是它不省，是你自己装了几个会偷东西的二房东，还纳闷自己钱包咋瘪了。

四、和 MCP 比一比，你才看清 skill 到底省在哪

说到这儿得插一句——skill 跟 MCP，我见过太多人混着用，混完了账单双倍涨，还不知道咋回事。这事儿得单说。

咱先把这俩拆开看。

MCP 是工具调用协议。它解决的问题是——模型本身没有的”动作能力”，比如查天气、读文件、调数据库、发请求。装一个 MCP，相当于给模型递了一把锤子。它需要锤东西的时候，把锤子拿起来用一下。

skill 是知识装载机制。它解决的问题是——模型本身没有的”专属知识或流程”，比如你团队的代码规范、某个项目的架构图、某个行业的术语表。装一个 skill，相当于给模型挂一本你们公司的内部手册。它需要查的时候，翻出来对一下。

MCP 是工具，skill 是手册。这俩性质就不一样——前者让模型能干事儿，后者让模型知道事儿。

烧钱的逻辑也完全不一样。

MCP 省的是动作 token——本来模型要费一大段文字描述”我现在要去查天气，怎么查呢，先 curl 这个 API，然后解析返回的 JSON……”，有了 MCP 它直接调一个函数，几个 token 搞定。省的是描述动作的那段啰嗦。

skill 省的是上下文 token——本来你要把团队规范打在每次 prompt 里，几千字常驻，有了 skill 这几千字平时挂着，需要时才进场。省的是反复贴长文档的那段冗余。

这俩省的根本不是同一段。

那啥叫混着用双倍烧钱？

我见过最典型的一种用法——把 MCP 当 skill 用。比如有人写了个 MCP，里面塞了一大坨团队规范文档，让 Claude 每次调这个 MCP 就把规范拉出来。表面上看挺聪明——MCP 是按需调用的嘛，平时不在上下文里。

问题是 MCP 调用一次就完整塞进上下文。你这不就是把一个本该用 skill 解决的”知识装载”问题，硬塞进了一个 MCP 的壳里？结果就是每次调用都把几千字规范塞进去——而真要写 skill 的话，模型可以只加载相关的几段。

反过来也有——把 skill 当 MCP 用。比如有人写了个 skill 叫”调用内部 API”，正文里全是各种 API 的 URL、参数、示例。Claude 召唤这个 skill 把正文加载进来——加载进来又能咋样？它还是没法真的去调那个 API，它没工具啊。这事儿本该用 MCP 解决的——给它一个真正能发起请求的函数。结果你给了它一堆没用的文档，加载一次烧一次。

这俩用反了，等于花了两倍的 token，干了一半儿的活儿。

正确的活法是——动作的事儿归 MCP，知识的事儿归 skill。你要让 Claude 真的去做一件事，写 MCP。你要让 Claude 知道一件事，写 skill。这俩配合起来才不冲突。

说白了就是，别混用。混了吃亏的是你自己。

五、真正烧 token 的从来不是 skill，是用 skill 的那个人

技术机制是冷的，使用习惯是热的。

skill 这个机制本身没啥可争论的——它就是个按需加载的封装层。它不会主动多烧你的钱，它的所有行为都是被动响应。响应啥？响应你怎么配置、怎么描述、怎么管理。

同一个 skill，给两个不同的人用，账单能差出好几倍。

一个人装之前会想——这玩意儿我是真用得上吗？一周能用几次？描述边界清楚吗？跟我现有的 skill 有没有重叠？想清楚才装。装完一周回头看——这周用了几次？没用上的那次是不是误触发？描述需不需要调？

另一个人装之前不想——这玩意儿看着酷，先装上。出问题再说。装完一个月——账单涨了。账单涨完——抱怨 skill 不省 token。

你看，俩人面对的是同一个 skill，得到的是俩世界。差别在哪儿？差在敢不敢卸载。

我那哥们儿最后干的事儿，就是把那 8 个 skill 卸载到 2 个。卸载的过程他跟我说挺难受的——每卸一个都觉得”万一以后用得上呢”。但他后来想明白了——以后用得上的时候再装回来，比每天让它白白烧着钱强。

会装 skill 的人现在满地都是。点几下鼠标的事儿，谁不会。

会卸载 skill 的人少。因为卸载这事儿要求你承认——我之前装这个就是冲动消费。

承认这事儿挺难的。装的时候你脑子里全是”以后用得上”的幻想，卸的时候你脑子里全是”万一用得上”的恐惧。装是加法，卸是减法。AI 工具时代大部分人只会做加法。

但 token 这账，加法是要付钱的，减法才是省钱的开始。

写描述这事儿也一样。一个 skill 描述好不好，不在于词多不多、看着专不专业，在于你有没有想清楚它的边界——它要管啥、不管啥、什么情况下绝对别召唤它。这件事的难处不在于技术，在于你愿不愿意花一下午时间，把这几行字反复打磨。

大部分人不愿意。装 skill 三十秒，写描述五分钟，从此以后让模型自己慢慢误触发去吧——反正烧的不是自己电费。

但 API 账单是自己付的。

所以这篇文章绕了一大圈，结论就这一句话——skill 省不省 token，从来不是 skill 这个东西本身的问题，是你这个人有没有认真配置它的问题。

你愿意花时间想清楚装啥、卸啥、描述咋写、跟 MCP 咋分工——它就老老实实给你省钱。

你不愿意——它就老老实实给你烧钱。

中间那只手是你的。

最后说回开头那哥们儿。他卸载完之后，剩下的 2 个 skill 一个是”团队代码规范”，一个是”项目架构上下文”。这俩他每天都用十几回，描述写得也清楚——只在跟当前项目代码相关的提问里召唤，其他场景一律不出场。

省下来的钱呢？他拿去续了个 Pro 订阅。

这就是 AI 工具时代一个挺扎心的事儿——你以为你在用工具，其实工具在筛选用人。

会用的人越用越省，不会用的人越用越亏，机制是同一个。

你抱怨 skill 不省 token 那个样儿，跟当年抱怨 ChatGPT 答得烂那个样儿，是一回事儿。问题从来不在它身上。

中，今儿就唠到这儿。下次再有人跟你说”装 skill 能省 98% token”——你别急着装，先问他一句：你 skill 描述写得咋样？

你每次打开Claude，说”帮我写一份产品分析报告”，它都能给你一份看起来还不错的文档。但如果你有20个不同的任务——写报告、分析数据、写代码、回复邮件——你发现了一件令人沮丧的事：AI的表现忽高忽低，同一个任务，今天输出好，明天输出差。问题不在AI本身。问题在于：你每次都在重新发明轮子。Skill的出现，就是为了解决这个根本矛盾。

一、大多数人理解错了Skill

“Skill不就是一段提示词吗？”这是关于Skill最常见、也最有害的误解。如果你把Skill理解为”一段文字塞给AI”，那你只看到了它的表面。Skill的真实定义是：一套精心设计的能力加载机制——它要回答的是四个最基本的问题：什么时候触发，加载什么，执行什么，以及怎么迭代。

这是一个系统工程的命题，不是写prompt的命题。两者有什么区别？提示词是静态的，Skill是动态的。提示词是点对点的指令，Skill是可组合的能力单元。提示词写完就结束了，Skill需要测试、需要迭代、需要和其他Skill共存。Anthropic给Skill的定义值得原话引用：

“A skill is a set of instructions — packaged as a simple folder — that teaches Claude how tohandle specific tasks or workflows. Instead of re-explaining your preferences, processes, anddomain expertise in every conversation, skills let you teach Claude once and benefit every time.”

“教一次，永久受益”——这才是Skill的本质。它不是在告诉AI”做什么”，而是在正确的时间、以正确的方式、让AI做正确的事。这就是核心冲突所在。同样的Claude能力，有人用Skill做到90%任务成功率，有人每次从零开始只有30%。差距不在模型，在于Skill设计的质量。

二、纵向：Skill的概念不是凭空出现的

理解Skill，必须把它放回历史脉络里。它不是一次偶然的发明，而是AI能力表达方式演进的必然产物。

前Skill时代

重新发明每一次最早的AI使用方式极为朴素：用户说一句，AI答一句。没有记忆，没有上下文积累，没有能力复用。每次对话开始，AI都是一张白纸。你跟它聊了半小时的数据分析偏好，下一次打开窗口，全部归零。这意味着：所有的高质量输出，都建立在重复劳动之上。专业用户很快发现，这不是可持续的使用模式。

System Prompt时代

静态配置的死胡同2022年前后，System Prompt（系统提示词）的概念开始流行。本质上，这是把常用指令”写死”在对话开头，让AI一启动就具备某种角色或能力。这比每次重说强多了。但System Prompt有三个根本局限：

第一，无法按需加载。不管当前任务是什么，System Prompt的内容全部加载进上下文。任务越复杂，System Prompt越长，上下文膨胀越严重。Anthropic的文档里特别指出了这一点——大量Skill内容一股脑塞进SKILL.md，正是最常见的错误之一。

第二，不可组合。 多个System Prompt互相干扰的情况极为普遍。当你有一个”数据分析专家”的System Prompt和一个”代码审查员”的System Prompt，二者同时存在时，AI的行为往往互相矛盾，因为没有清晰的加载和触发机制。

第三，无法迭代。 System Prompt是”一锤子买卖”，写完即定型。没有内置的测试、验证、反馈机制，你只能靠感觉判断效果好坏。

Plugin/GPTs时代

能力扩展的第一次尝试2023年，OpenAI推出Plugin生态和GPTs，试图解决能力扩展问题。用户在ChatGPT里”装”一个插件，就能让AI访问外部API、获取实时数据、执行特定操作。

这代表了重要的范式转变：AI开始从“回答问题的工具”进化为“执行任务的工具”。

但Plugin体系有一个根本缺陷：强耦合，不可组合。GPTs的Actions本质上是OpenAPI规范的包装——你把API描述告诉AI，AI根据描述决定是否调用。这种模式的局限在于：API能做什么是固定的，AI只能在其范围内工作。

更关键的是，一个GPT里的多个Action互相不知道对方的存在，无法协调完成需要跨服务的工作流。

简单说：Plugin时代解决的是”AI能调用什么工具”的问题，但没有解决”AI在什么场景下该用什么工具、工具之间怎么协作”的问题。

Skill时代：质的飞跃

2024年底到2025年初，Anthropic正式推出Claude Skills。与Plugin相比，Skill体系实现了三个关键跃迁：

渐进式加载（Progressive Disclosure）。 这可能是Skill设计里最深刻的创新。它将能力加载分为三个层次：

第一层是YAML frontmatter，永远加载，但极轻量（约100个token），只够让AI”知道”有这项能力存在；

第二层是SKILL.md正文，按需加载，包含完整的执行指令；

第三层是references和scripts，按需深入，提供细节支撑。token是稀缺资源。

渐进式加载的本质是：不是所有能力都需要同时在场。这是一个关于”何时加载什么”的设计哲学，而不仅仅是技术实现。

• 可组合性（Composability）。 Claude可以同时加载多个Skill，每个Skill之间有清晰的边界，互不干扰。这意味着Skill是真正的模块化单元——你可以同时拥有”报告生成”Skill和”代码审查”Skill，它们各自工作，互不冲突。
• 可移植性（Portability）。 同一个Skill在Claude.ai、Claude Code和API中行为一致。这打破了”平台绑定”的魔咒——你在本地调试好的Skill，上传到任何支持的平台都能工作。

纵向梳理到这里，核心洞察已经浮现：Skill的演化本质是从“静态配置”到“动态能力加载”的范式转变。

前两个时代的核心问题是”怎么让AI知道更多”，Skill时代的核心问题是”怎么让AI在正确的时刻调用正确的知识”。这不是同一个问题的不同答案，这是两个完全不同的问题。

三、Skill的核心设计原则

从Anthropic的官方指南中提炼出最重要的设计原则，但关键不是记住它们——而是理解它们为什么存在。

原则一：YAML Frontmatter是生死线

Skill能不能被触发，完全取决于frontmatter中的description字段写得怎么样。这不是夸张。一个Skill写完上传，系统一切正常，但Claude永远不会自动加载它——90%的原因是description没写好。description的核心结构只有三个要素：做什么 + 什么时候触发 + 关键触发词。

Anthropic给出的好description示例：

description: Manages Linear project workflows including sprint planning,task creation, and status tracking. Use when user mentions “sprint”,”Linear tasks”, “project planning”, or asks to “create tickets”.

坏的description：

description: Helps with projects.

“帮助处理项目”——这是对Skill功能的总结，不是触发条件描述。Claude拿到这个描述，它怎么判断用户什么时候需要这个Skill？它没法判断。这引出了一个反直觉但极其重要的设计原则：description不是写给人看的，是写给AI的触发判断器。它的读者是Claude的语义理解引擎，不是用户。你写的不是产品文档，是一份触发条件清单。

好的description = “做什么”（语义上清晰的能力边界）+ “触发信号”（用户可能说的话）。坏description = 模糊的功能概括。

原则二：渐进式加载是Token经济学

前文提到渐进式加载是Skill最重要的设计哲学，这里要展开它为什么重要。当你把所有内容都塞进SKILL.md，Claude每次启动都要处理这些内容。单个Skill可能还好，10个Skill同时启用，上下文窗口里堆满了各种能力描述，AI的注意力被严重分散。

更实际的影响：响应变慢，成本上升。

Claude处理每一条上下文token都要消耗计算资源，这些资源本来可以用来处理你的实际任务。Anthropic的建议很具体：SKILL.md保持简洁，把详细文档移到references/目录，按需引用。

这看起来是文件组织问题，实际上是能力加载的优先级管理问题。

具体操作上，有几个实践技巧：

• references/目录存放API文档、示例代码、详细的错误处理说明。这些文件默认不加载，只有当Claude需要深入了解某个细节时，才去引用。
• scripts/目录存放可执行脚本——比如数据验证脚本、格式检查脚本。这些脚本在Skill执行时调用，不在prompt里用自然语言描述校验逻辑。
• 代码是确定性的，语言描述不是。
• 当校验规则复杂时，用脚本比用文字说明可靠得多。

原则三：指令的具体性决定执行质量

这是Skill设计中最容易出问题的地方，也是最有改善空间的点。模糊指令：

“验证数据后继续”

这条指令的”可解释空间”太大了。什么叫验证？验证哪些字段？什么算验证通过？验证失败怎么办？Claude面对这种指令，要么自己猜测，要么反复确认，两种结果都不理想。具体指令：

“调用 python scripts/validate.py –input {filename} 检查数据格式。验证失败时，常见原因包括：缺失必填字段（将缺失字段名返回给用户）、日期格式错误（使用YYYY-MM-DD格式）。只有在所有验证通过后才能进入下一步。”

区别在于：具体指令告诉了AI用什么工具、传什么参数、预期什么输出、失败怎么处理。

这四个要素齐全，Claude的执行路径就清晰了。Anthropic在文档里特别提了一个高级技巧：对于关键验证，考虑将检查逻辑封装为脚本，而不是用自然语言描述。

这背后的逻辑很朴素：代码执行的结果是确定的，语言模型的输出具有概率性。当精度重要的时候，放弃概率。

原则四：可组合性是设计约束，不是选项

当你设计一个Skill，必须假设它不是唯一存在的。这个假设带来了具体的约束：Skill不能独占全局上下文，不能假设所有工具都可用，不能做与相邻Skill冲突的行为假设。反过来，这要求你在Skill设计时明确声明它依赖什么能力（通过compatibility字段），以及它不处理什么场景（通过description中的negative trigger）。Anthropic文档中给了一个negative trigger的示例：

description: Advanced data analysis for CSV files. Use for statisticalmodeling, regression, clustering. Do NOT use for simple dataexploration (use data-viz skill instead).

这种边界声明表面上是在”拒绝”一些场景，实际上是在保护Skill的专注度。一个什么都做的Skill，实际上什么都做不精。

原则五：可移植性从命名开始

Skill设计有一个容易被忽视的细节：文件夹和name字段的命名方式。

Anthropic的规定很清楚：使用kebab-case（全小写，横杠分隔），禁止空格、禁止下划线、禁止大写。文件夹名必须和name字段完全一致。

# 正确

name: figma-design-handoff

# 错误

name: Figma_Design_Handoff

这不是格式癖好，这是系统兼容性的基础。当一个Skill可能在Claude.ai、Claude Code和API之间迁移时，任何命名不一致都可能导致加载失败。命名规范是最基础的可移植性保障。

四、各平台Skill体系的全景对比

Skill不是Anthropic的独角戏。将它放在更宽的视野里，能更清楚地看到它的特点和局限。

对比框架

我选取四个最具代表性的平台进行对比：Anthropic Claude Skills、OpenAI GPTs/Actions、Coze扣子Bot，以及LangChain/LangGraph。

Anthropic Claude Skills：精细度的领跑者

Claude Skill体系在”能力加载的精细度”上领先整个行业。三层渐进式加载是迄今为止最优雅的上下文管理方案，它解决了Plugin时代最核心的矛盾：能力丰富度和上下文膨胀之间的张力。

YAML frontmatter作为触发判断层，是一个小而美的设计决策。只加载几百个token的元数据，让AI”感知”所有可用Skill，然后只在需要时才加载完整内容——这个思路从根本上优化了token使用效率。

但它的局限也很明显：Skill自己没有执行工具的能力，需要依赖MCP（Model Context Protocol）提供工具层。Skill告诉你”怎么做”，MCP让你”能做到”。二者结合才有完整的能力闭环。

另外，Claude Skill体系相对较新（2025年才成熟），社区生态和工具链的丰富度不如老牌平台。

OpenAI GPTs/Actions：配置驱动，但强耦合

GPTs/Actions的最大优势是门槛极低——任何人花几分钟就能创建一个能调用外部API的GPT。但这个优势同时也是它的局限所在。

Actions基于OpenAPI规范构建，本质上是把你的API描述告诉ChatGPT的模型。这解决了一个基本问题：AI怎么知道有哪些API可以调用。但OpenAPI规范是描述性的，它告诉你”接口是什么”，不告诉你”什么时候该用哪个接口、多个接口之间怎么协作”。

GPTs的多个Actions之间是隔离的，没有内置的跨Action协调机制。当你需要从Google Calendar读取事件、从Slack发送通知、再把结果写回Notion——GPTs本身无法编排这个流程，你需要自己写额外的逻辑或者借助Zapier这样的中间层。

简单说：GPTs适合单点能力扩展，不适合复杂工作流。

Coze扣子：中文生态的低代码最优解

Coze代表了另一种思路：用可视化编排降低技能构建的门槛。

Coze的Bot构建有几个核心组件：人设与提示词（相当于System Prompt）、插件（相当于工具调用）、工作流（可视化节点编排）、知识库（RAG增强）。对于非技术背景的用户，这套体系的上手成本极低——拖拖拽拽就能搭出一个能用的Agent。

工作流是Coze最有特色的部分。它用图形化界面把Agent的思维过程”外化”出来：输入→LLM节点处理→插件调用→条件分支→输出。每个节点有明确的输入输出定义，流程的每一步都是可追溯的。

但Coze也有明显的局限：它高度绑定Coze生态，一旦你投入大量精力构建了复杂的工作流，迁移成本极高。另外，可视化编排虽然降低了入门门槛，但也限制了表达复杂逻辑的上限——当流程分支足够多时，图形界面本身就变成了理解障碍。

LangChain/LangGraph：开发者的工坊

LangChain和LangGraph代表了完全不同的用户群：它们是为程序员准备的。

LangChain 1.0（2025年10月发布）提供了create_agent抽象，用几行代码就能创建一个带工具调用能力的Agent。LangGraph则在底层提供了图形化状态机，用于构建高度复杂的Agent工作流。

从技术角度，LangChain/LangGraph是目前最灵活的方案：你可以定义任何工具、任何状态转换逻辑、任何中间件处理。ReAct循环、checkpoint持久化、human-in-the-loop介入——这些高级功能都有原生支持。但代价是：这是一套代码优先的方案，需要Python/JavaScript编程能力。对于没有工程背景的用户，这是无法逾越的鸿沟。

核心判断

各平台在”能力加载精细度”上的排序是：Claude Skills > LangChain > Coze > GPTs。

各平台在”开发便利性”上的排序是：Coze > GPTs > Claude Skills > LangChain。

结论：Anthropic的Skill体系在工程设计层面确实领先，但它面向的是有一定技术理解力的用户群体。 想要真正发挥Skill的能力，用户需要理解渐进式加载的逻辑、能写出有效的description、能组织好references结构——这比在Coze里拖拽节点需要更多的认知投入。

两种路线都有其价值。市场需要低门槛的方案让更多人用起来，也需要精密的体系让深度用户构建真正可靠的生产级能力。

五、五大实战模式：从Pattern到实践

Anthropic文档提炼出了五个经过验证的Skill执行模式。这些模式不是教条，而是经过真实场景检验的工作流模板。每个模式都有其最佳适用场景。

模式一：顺序工作流编排

适用场景： 多步骤流程，每一步依赖前一步的结果，且顺序固定。

典型例子：客户入职流程——创建账户→配置支付→建立订阅→发送欢迎邮件。每个步骤的输出是下一步的输入，中途失败需要回滚。

这个模式的核心不是”步骤多”，而是步骤之间有明确的依赖关系和失败处理。

顺序编排的关键技术点：每一步明确声明依赖字段（”从Step 1获取customer_id，传入Step 3″）；每个阶段包含验证逻辑，不验证就不进入下一步；失败时提供明确的回滚指令，不是一句”出错就停止”。

Anthropic的文档特别强调：Rollback instructions（回滚指令）是顺序工作流里最容易被忽略、也最不该被忽略的部分。 如果第四步失败了，前三步做的操作需要被撤销——账户创建了但订阅失败，残留数据怎么处理？没有这一步，Skill在失败场景下会留下一地鸡毛。

模式二：多MCP协调

适用场景： 工作流跨越多个外部服务，每个服务由独立的MCP处理。

典型例子：设计-开发交接流程——从Figma MCP导出设计资源→从Drive MCP存储资源→从Linear MCP创建开发任务→从Slack MCP通知团队。

多MCP编排的挑战在于阶段分离和数据传递。

Phase 1（设计导出）完成后，资源链接需要被捕获，并作为参数传给Phase 2（存储）。Phase 2完成后，存储路径需要传给Phase 3（任务创建）。每个阶段的边界必须清晰，交接的数据必须标准化。

这个模式的另一个关键点：集中式错误处理。当某个MCP调用失败，需要有一个统一的错误处理策略——是重试几次？是跳过这个步骤继续后续流程？还是整个流程中止？不能在每个阶段各自为政。

模式三：迭代精炼

适用场景： 输出质量随迭代次数提升，且质量标准可以明确定义。

典型例子：报告生成。第一遍草稿→质量检查（脚本验证）→识别问题（缺失章节、格式不一致、数据校验错误）→针对性修改→再验证→直到质量达标。

这个模式的本质是把质量控制从“AI自己判断”变成“程序化验证”。

迭代精炼的核心不是”多生成几遍”，而是质量标准必须前置。在开始迭代之前，必须明确：什么算”高质量”报告？结构完整（包含哪些章节）？数据准确（怎么校验）？格式统一（用什么模板）？

Anthropic的文档给出了关键洞察：知道什么时候停止迭代，和知道如何迭代一样重要。 没有停止条件，Skill会陷入无限循环——每次生成都比上次稍微好一点，然后继续改，永远不输出最终版本。

设置停止条件的常见策略：验证脚本返回通过（程序化标准）；达到最大迭代次数（硬上限）；人工确认环节（human-in-the-loop）。

模式四：上下文感知工具选择

适用场景： 同样的目标，不同的工具选择取决于输入的具体特征。

典型例子：智能文件存储——根据文件类型和大小决定存储位置。大型文件（>10MB）走云存储MCP，协作文档走Notion/Docs MCP，代码文件走GitHub MCP，临时文件走本地存储。

这个模式的关键是清晰的决策树和降级方案。

决策树必须穷举所有可能的输入场景。Claude遇到一个”没见过”的场景时，应该怎么做？降级方案提供了答案：默认走最通用的选项，而不是直接报错。

另一个重要的设计点：向用户解释为什么做了这个选择。Anthropic的文档将”提供上下文给用户”作为这个模式的必要组成部分。一个透明的决策过程，既建立了用户信任，也便于用户发现问题后及时纠正。

模式五：领域专有智能

适用场景： Skill需要嵌入超出工具访问的领域知识，且涉及合规或审计要求。

典型例子：金融合规支付处理——交易前必须检查制裁名单、验证司法管辖区许可、评估风险等级。处理完成后，所有合规检查必须记录日志，可供审计追溯。

这个模式的独特之处在于：合规检查先于业务操作，审计追溯贯穿全程。

很多领域都有这样的强制约束：医疗AI在推荐治疗方案前必须检查禁忌症，工业AI在执行操作前必须验证安全条件。领域专有智能模式把这些约束内置到Skill的执行逻辑中，而不是事后追加。

这也揭示了Skill设计的一个深层原则：能力不仅仅是“能做到”，还包括“做到的方式是否符合规范”。一个支付处理Skill，如果缺少合规检查前置步骤，它的能力是不完整的。

六、最常见的三个陷阱

Skill设计有三个高频失败点。每一个都有明确的诊断方法和修复路径。

陷阱一：Skill存在，但永远不被触发

诊断：上传后测试，发现Claude从不自动加载这个Skill，每次都需要用户手动指定。

根本原因： description字段写得过于模糊或缺少触发词。

“帮助用户处理Figma相关任务”——这句话的问题在于，”处理Figma相关任务”是一个太大的语义空间。Claude在判断是否加载这个Skill时，需要在description中找到足够具体的匹配信号。

修复方案：

第一步，用Anthropic建议的方法验证：直接问Claude”你什么时候会使用[Skill名称]这个Skill？”Claude会引用它的description内容。根据引用的内容判断：是否包含了足够具体的触发场景？

第二步，增加触发词。Anthropic明确建议description中应该包含”用户可能说的话”——包括具体的文件类型（.fig、.sketch）、具体的操作动词（”导出”、”handoff”、”生成规格”）、具体的产品名称（Linear任务、Figma设计）。

第三步，如果description已经很具体但仍然不触发，检查是否有其他Skill的description覆盖了更广的范围，导致竞争。通常的解决思路是：让description更窄但更精准，而不是更宽但更模糊。

陷阱二：Skill加载了，但AI不按指令走

诊断：Skill触发了，但Claude输出的内容与SKILL.md中描述的步骤不一致。Claude忽略某些步骤，或者用自己的理解重新组织了流程。

根本原因： 指令要么太模糊、要么太冗长、要么关键指令被埋在了文件深处。

Claude的注意力有优先级。写在文件开头的内容比埋在结尾的内容权重更高。 如果关键指令在文档中间，Claude在长上下文里可能会”忘记”它们——这不是AI的缺陷，这是注意力机制的特性。

修复方案：

关键指令前置。用 ## Critical 或 ## Important 这样的标题明确标记最核心的步骤。Anthropic的文档甚至建议”如果需要，重复关键点”。

避免冗长。如果SKILL.md超过5000词，Claude的执行质量通常会下降。把详细文档移到references/目录，正文保持核心流程的精炼描述。

使用脚本替代自然语言描述关键校验。当校验逻辑复杂时，写一个 scripts/validate.py，然后在SKILL.md中用”运行 python scripts/validate.py –input {filename} 检查数据格式”来调用。代码是确定性的执行路径，不依赖模型的概率解释。

加入正面激励。Anthropic文档提了一个反直觉但有效的技巧：明确鼓励Claude慢下来、把质量放在速度前面。”Take your time to do this thoroughly. Quality is more important than speed.”——这句话写进用户的prompt比写进SKILL.md效果更好。

陷阱三：Skill本身不大，但整个系统变慢了

诊断：单个Skill性能正常，但当启用10个以上Skill时，明显感觉到响应变慢、延迟增加、输出质量下降。

根本原因：多个Skill同时加载导致上下文膨胀，或者SKILL.md设计时没有利用渐进式加载的层次结构。

修复方案：

减少同时启用的Skill数量。Anthropic建议评估是否同时启用了超过20-50个Skill。如果是这样，考虑使用”Skill Pack”策略——把相关能力打包成更少、更大的Skill，而不是维护几十个细粒度Skill。

充分利用三层加载结构。frontmatter只放触发元数据（<1024字符），SKILL.md正文放核心指令（<5000词），references/放深度文档（在SKILL.md中按需引用）。

SKILL.md内部也用渐进式。 在SKILL.md正文中，不要一次性铺开所有细节。用”## Overview”介绍整体流程，在需要时才深入到”### 详细步骤”。这种结构本身也是一种渐进式——Claude可以先获取高层理解，再按需加载细节。

七、Skill设计的深层逻辑

把纵向的演化脉络和横向的平台对比交叉，能看到一些单从任何一个维度都看不出的东西。

洞察一：Skill的本质是”能力的编译”

提示词时代，AI能力的传递依赖”文字”——人写一段话，AI读一段话。文字天然具有歧义性，同一句话在不同上下文里有不同理解，这导致了提示词的不稳定性。

Skill不是文字，是经过结构化组织的知识模块。YAML frontmatter提供元数据，SKILL.md正文提供执行指令，references/提供深度支撑，scripts/提供确定性执行路径。这套结构将人的隐性知识——知道什么时候该做什么、怎么做——编译成AI可解析、可执行、可验证的显性指令。

“编译”这个比喻值得深想。编译器处理源代码，输出机器指令。好的编译器做优化——删除冗余代码、重排执行顺序、缓存中间结果。好的Skill设计者做同样的事——删除冗余的指令描述、优化触发条件的精确度、把模糊的”尽量做好”编译成精确的”在X条件下执行Y动作”。

从这个角度看，Skill写得好不好，本质上不是”文笔好不好”，而是编译质量高不高。

洞察二：Skill是AI Agent范式演进的锚点

从更宏观的视角看，AI Agent领域正在经历一个核心转变：从”模型输出”到”系统执行”。

早期Agent（如AutoGPT，2023年4月）试图让模型自主决定整个行动计划，代价是极度不可靠——模型会陷入循环、调用错误的工具、无法从错误中恢复。

LangChain的ReAct模式（Reasoning + Acting）推进了一步：明确让模型在”思考”和”行动”之间交替，每次工具调用后都让模型审视结果再决定下一步。这提高了可靠性，但也带来了新问题：模型在每个循环里都要”想一下该怎么做”，这本身就是token和时间上的浪费。

Skill提供了一个不同的解决思路：把“知道该怎么做”这件事本身结构化。模型不需要在每次执行时都从头推理”这个多步骤任务应该先做什么再做什么”——Skill已经把这条路经编码好了。模型只需要在Skill的框架内处理当前的具体输入。

这意味着Skill不是在”控制”AI，而是在”卸载”重复推理的负担，让模型把注意力集中在真正需要判断的地方。

洞察三：Skill的成熟度决定Agent能力的上限

AI Agent目前面临的核心矛盾是：模型越来越聪明，但可靠执行复杂任务的能力仍然有限。 原因不在模型本身，在于”怎么组织能力”这个工程问题还没有被很好地解决。

Skill体系正在尝试解决这个问题。它的五个设计原则——渐进式加载、可组合性、可移植性、具体性指令、领域嵌入——对应了五个真实的能力缺口：上下文管理、多Skill协作、跨平台迁移、执行可靠性、垂直领域合规。

这五个问题解决到什么程度，AI Agent就能从”聊天机器人”进化到什么程度。

洞察四：Skill的未来——从手写到自生成

当前Skill还需要人工编写。但这个状态不会持续太久。

几个信号已经出现：Anthropic内置了skill-creator Skill，可以根据自然语言描述自动生成SKILL.md框架。LangChain的PromptEvolver框架已经在实验自动优化提示结构的工作流。多Agent协作系统（如MetaGPT）中，已经开始用”角色编码的SOP”来自动生成Agent的行为规范。

未来的Skill很可能有两层：基础层是结构化模板（由平台或框架预制），个性化层由用户通过自然语言描述生成。就像现在的网页模板——大多数人用现成模板，少数人从零手写。

但即使在那时，理解Skill的底层设计原则仍然重要。你不需要成为模板设计师，但你需要知道为什么一个模板有效、另一个模板失败。

八、结尾

Skill不是给AI写说明书，是给AI装手艺。

说明书是死的参照物，用的时候查一下，用完放回去。手艺是活的执行能力——它是身体的一部分，不需要每次调用都从零想起。

说明书式的AI使用方式，每一次任务都是从零建立上下文。你以为你在”用AI”，实际上你在反复做知识搬运的工作，把你脑子里的隐性经验一遍遍翻译成AI能理解的文字。

手艺式的AI使用方式，是把那些反复用到的知识和流程编译成Skill，让AI在正确的时间自动调用它们。你只需要在关键时刻做判断、做校正、做升级。

这个转变的难度不在于技术，在于认知。

大多数人还在用”说明书思维”使用AI——每次把任务描述一遍，等AI给一个答案，下次再描述一遍。这是一个令人疲惫的循环，也是AI表现不稳定的根本原因。

Skill是一扇门。打开它，AI就不再是你每次用完就忘的工具，而是会积累、会进化、会在下一次自动做得更好的执行者。

至于门后面是什么——取决于你愿意把多少”手艺”装进去。

最近一段时间，我干的最多的一件事，就是写各种Skills。

我在尝试把工作和日常生活中更多事情交给AI，让它更深度地融入到我的工作流。

正好最近表达欲恢复了一些，就想写篇文章，和大家聊聊我这段时间写Skill的方法和思考。

1. Skill和Prompt的区别是什么

在我刚接触Skill的时候，我在体验完后和朋友说的第一反应就是：这不就是一个大号的prompt吗？感觉好像也没有什么特别新的内容出来啊。

但在亲手写了很多Skill后，我觉得它们之间确实有连续性，但是也有很多明显的差别。

从底层逻辑上来讲，Skill和Prompt做的是同一件事情：让AI按照一套SOP标准去作业。

所以最简单的Skill和Prompt没有本质区别，比如Claude官方的设计Skill，它就是一个单Skill.md文件构成的Skill，里面对整体设计思路进行了描述，让模型能够基于这套逻辑去作业，放到Prompt上来也是一样的效果。

但在模型的调用方式上，Skill比Prompt更友好。

模型在作业时，可以先看到多个Skill的基础说明，然后根据当前任务判断要调用哪个Skill。而Prompt只能通过人工手动指定的方式来进行加载，很难在全局工作流里形成稳定的调用机制。

同时在复杂的SOP流程上，Skill能够实现更多Prompt做不到的事情了，它可以包含各种规则、参考文档、Python脚本、素材库，在不同的阶段让模型调用不同的内容。

而 Prompt则需要一次性把所有内容都喂给模型，但这样能够承载的信息量和复杂度都是有限的。内容一多不仅会占用大量上下文，也容易让模型在执行时抓不住重点。

所以我后来对Skill的理解就变了：Skill并不是一个大号的Prompt，它是一套可以让AI完成更加复杂SOP的作业系统。

2. 写Skill的流程：跑通、复盘、封装、回溯。

如果只说一个最核心的经验，那我认为是：不要一开始上来就是设计Skill，先和AI跑出效果，再封装成Skill。

这个逻辑和我之前写提示词有很大区别。

写提示词的时候，我是和AI一起先思考目标是什么，然后提示词的作业流程是什么，基于此设计出来一版提示词，再拿去测试，最后基于效果进行调整。

但这有一个大的前提：之前的AI作业更偏Chatbot，基本上都是网页里进行对话的。

而在Agent作业逻辑下，任务的复杂度是明显变高的，它不再只是多轮对话，中间会掺杂各种脚本、工具调用、文件读取、subagent分工的情况，所以很多流程很难在一开始就完整设计出来。

所以我现在更倾向于先和AI定一个目标，然后想办法达到对应的结果，再回头把这个过程封装成Skill。

这样做的试错成本最低，也可以降低很多的测试成本。

我目前的作业流程分为这四步。

1. 1. 先和AI定好目标，然后把这个真实场景跑通：不需要刚开始就做到了一个完美的效果，但要先基于自己定好的目标拿到一个自己认可的结果。
2. 2. 和AI复盘这个结果是怎么跑出来的：主要是和AI讨论整个过程中有哪些是正向的流程，哪些是负向的流程，哪些内容是应该保留沉淀下来的。
3. 3. 把这套过程封装成Skill：让AI基于我们的复盘结果进行Skill封装即可，从真实成功经验中提炼出来的流程往往比凭空设计的流程效果好很多。
4. 4. 做回溯测试：开一个新的对话，测试这个Skill能否稳定复现类似的结果，如果不稳定的话就要去看看问题出现在哪，然后对对应的Skill流程进行优化。

所以这套流程本质上不是先设计，再验证，而是先跑通，再复盘，再封装，再回溯。

3. Skill的组织结构

这里我准备单独开一个小节，讲一下Skill的组织结构，主要是方便大家理解模型是如何去加载一个Skill的。

当Claude Code、Codex这些Agent调用Skill时，并不是一上来就把整个Skill的全部内容都塞给模型，它是分多层级进行渐进式加载的。

第一层是Skill的描述：它由name和description两个字段构成，这两个字段会告诉模型这个Skill是做什么用的，方便模型在作业场景里要判断调用哪个Skill。

在一次对话中，模型是会把读取到的所有的Skill描述都加载进去的，所以在写Skill描述的时候，最好清晰明了的讲清楚场景是什么，比如说Skill是写PRD文档的，那description就要明确的告诉模型，当用户提出需求整理成结构化 PRD、补全背景、目标、功能范围和验收标准时，应该使用这个Skill。

如果description写得太泛，有的时候模型会错误的进行调用，比如一个是网页设计skill，一个是app设计skill，如果不能清晰的写明使用场景，模型可能会在app设计的时候误调用网页设计skill。

第二层是SKILL.md文件：当模型判断需要调用某个Skill后，它会再去读取SKILL.md，来了解这个Skill的主流程。

所以最简单的 Skill，其实只需要一个SKILL.md就够了，里面写清楚这个Skill是干什么的、适合什么场景、整体作业流程是什么、最后应该输出什么结果。

比如说我的设计Skill，它就是只有一个SKILL.md文件：它会先理解需求，再确设计方向，和用户确认ASCII图，然后再生成页面方案，它不需要复杂的外部资源。

第三层是参考资料：我习惯把references、scripts、assets这些内容都定义为参考资料，因为他们是主流程下各个阶段调用内容的补充，不管是md文件也好、还是python脚本、还是各种素材，其实都是让模型能够在对应流程下进行更标准的作业。

比如我之前做的多视角深度分析Skill，它里面还包含了各种subagent 的语料库，AI 在执行任务时，会根据不同专家视角，把对应资料发给subagent，让它们按照更稳定的逻辑去分析。

最后汇总一下我对Skill组织的理解：name和description负责触发，Skill.md负责主流程，参考资料负责在复杂场景下补充能力。

关键不是目录看起来多完整，而是每一层都要服务于模型的真实作业流程。

4. Skill的进化：像做产品一样迭代

Skill并不是一次就可以做出一个非常棒的产品，它往往依赖人的多次迭代。

我现在在优化Skill的时候主要是会围绕两个维度来进行：

1. 1. 这个Skill根本上要做的问题是什么？不要做着做着过界了。
2. 2. 当前Skill做的不好的点是什么，这次要优化重点要解决什么问题。

比如我之前做多视角深度分析Skill时，第一版就是让subagent自由选择视角，对内容进行评估。测试完后发现一个问题：subagent的作业逻辑一直在变，很难稳定用同一个视角帮我复盘。

所以从1.0版本到2.0版本，我主要解决的问题是视角稳定性。

我给每一个subagent的派单增加了语料库，把不同专家视角的判断逻辑标准化，让subagent能够基于一套相对稳定的流程进行分析。

2.0版本的时候，我觉得5个顾问的数量不太够，于是我就又筛选增加了一批顾问数量到10个，这就是3.0版本。

但在3.0版本的时候，我想用这个Skill去写代码和做设计，当时我就在想给这个Skill增加更多的能力进去。

这时候就需要会看多视角深度分析Skill的初衷是什么，它其实就是用来做思维复制分析的产品，不应该承担设计、debug、写代码相关的内容，所以我就没有把它做成一个万能分析Skill。

而是新开了设计Skill和debug Skill，让每一个Skill对应一个更明确的场景。

另一个例子是做PPT的Skill，它的目标很明确，就是让AI帮人做出更精美的PPT。

1.0先解决的是AI能不能做的问题，效果没多好，可能有个60分的水平。

2.0解决的是样式丰富度的问题，通过增加更多的底板和参考样式，让效果能够达到65分。

3.0引入subagent的设计逻辑，让页面不只是套模板，而是能根据内容做更适配的设计。

4.0再优化整体PPT设计的流程，减少人的干预程度，让AI更加自主的作业。

每个版本其实都是解决一个当下最明显的问题。

所以Skill优化和产品迭代很像：不要一开始就追求完美，而是先跑起来，再一轮一轮解决关键问题。

5. 对Skill的思考：本质是把经验SOP化

我和朋友们也讨论过很多次：Skill到底考验人的什么能力？

我现在的理解是：Skill本质上是人把一件事SOP化的能力。

也就是人能不能把一个真实场景里反复出现的问题，沉淀成一套AI可以复用的流程。

这里根据我自己的测试经验，总结出来了两种不同的场景。

第一种是人熟悉的领域。

这种时候写Skill，更像是经验蒸馏。

因为人本来就知道这个事情应该怎么做，也知道什么样的结果是好的。人要做的是把自己的经验拆出来，变成 AI 能理解、能执行、能复用的流程。

第二种是人不熟悉的领域。

这种时候写Skill，最重要的就是建立一套回溯验证机制。

因为这个场景下其实难得并不是让AI产出内容，而是判断它做的对不对。

比如我之前一直想做一个六爻占卜Skill。

这个场景看起来很适合Skill化，因为它有规则、有流程，也有很多资料可以参考。但真正做成Skill的时候，我发现它很难稳定下来。

我自己不够懂占卜，我其实对于怎么解卦毫无思路，然后AI也不懂，我们俩加一起没办法构建一个可靠的回溯测试系统。

我压根不知道解卦到底是准还是不准，最后这个Skill我打磨了半个月还是放弃了。

测完这个Skill让我感慨万分，人不熟悉的领域倒不是说一定做不出来Skill，核心还是要看能否通过回溯机制来验证。

比如在编程的自动化测试上，我也不是专业的测试工程师，但我可以让AI设计一套测试逻辑，然后不断通过回溯测试优化这套逻辑的合理性，最后让AI把稳定运行的流程封装成Skill。

所以写Skill到最后考验的不是语法，也不只是提示词能力，而是人把场景SOP化的能力。

我算是看明白了，不管是玩转 CC 还是龙虾，就目前来说，首先还是自己要有这个 Skill 输出的能力。不知道最近大家有没有化身囤囤鼠，在各个平台看博主的推荐，安装了非常多各种功能的 Skill。比如我，光是大佬们推荐的和自己搜索安装的就有百八十个。

但实际上，就我自己个人的感受来说，如果是安装了别人的，大部分都使用的不多，甚至有的安装到现在从来没有调用过。

别人写的 Skill 我们未必看得懂它到底干了什么，尤其是那些带脚本、能操作文件、能执行命令的 Skill，装进来就等于给了它更多操作权限。有的龙虾当前会对部分可疑 Skill 给出风险提示或拦截安装，但这不等于所有平台都会帮你把风险兜住。

所以我的建议是：与其到处装别人的 Skill 担心安全风险，不如自己掌握写 Skill 的方法。这个能力是可以不断复用的，学会了之后，我们做的每一个 Skill 都完全在自己的掌控之中，还能根据自己的需求随时调整。

今天这里不讲那些更深奥的进阶知识。只分享我自己的一个超级适合小白且好用的写出自己需要的 Skill 的方法。

我会分享给大家一个我自己做的 Skill，当安装了我这个 Skill 之后，你说“我想要通过访谈来新建 Skill”，这个 Skill 就会开始和你沟通，一步步向你提问。然后在整个对话的过程中，它会逐步梳理清楚你的需求并输出 Skill。

Skill 放在后面，我先讲点基础的东西。

下面这些主要还是作为小白的了解，格式也不用记住，操作也有后面的 Skill 工具托底。

Skill到底是什么，跟提示词有什么区别？

先说一个我的个人看法。写 Skill 的核心能力，是把一件事说清楚。

我们先复习一下 Skill 的格式

简单说，一个 Skill 就像是一个文件夹。你把内容写好放进去，再配一个简短的“封面介绍”。AI 收到任务后，会先扫一眼所有 Skill 的封面介绍，判断当前任务跟哪个 Skill 有关，然后自动加载对应的完整提示词。

就像图书馆管理员，不用把所有书都背下来，只要知道每本书大概讲什么，有人问书名的时候能快速找到对应的那本就行。

所以提示词管的是“当前这一次”，Skill 管的是“这一类任务”。一次写好，反复调用，每次输出稳定。

什么时候该写 Skill 呢？简单的判断标准是：一件事最近一周做了3次以上，做法基本固定，那它就值得变成 Skill 。比如搜集每日专业相关的资讯和资料、做竞品分析、按照公司要求的格式写周报和整理会议纪要、给客户写跟进邮件等等，只要流程基本固定，且输出格式可预期，就都是好的 Skill 候选。

写好Skill的核心

SKILL.md 文件开头有一段元数据，其中首要的是description。把心思全花在正文上，description 随便写两句，后面调用的时候就不方便了。

description 决定了 AI 什么时候会触发这个 Skill 。写得太模糊，该触发的时候不触发；写得太宽泛，不该触发的时候乱触发。

这就好比你去买水果，和店家说要苹果，店家会给你苹果，而不会递给你香蕉、葡萄、草莓。

好的 description 要包含：功能描述 + 触发关键词。

#  太模糊，AI不知道什么时候该用description: 帮忙处理文档

#  太宽泛，什么写作任务都会触发description: 帮助用户写文章

#  具体功能 + 触发词description: | 将故事文本转换为AI视频生成所需的分镜脚本。 当用户说“做分镜“、“分镜脚本“、“故事转分镜“时触发。

如果你的Skill一句话讲不清楚可以干什么，那多半是边界还没收好。这时候试试做减法：砍掉那些副线，保留主线任务。砍掉顺便也能做的部分，只留必须做的那件事，等这件事稳了，再考虑扩展。

小技巧：想想我们自己平时会怎么说话。“帮我做个分镜”、“把这个故事拆成分镜”、“生成分镜脚本”，把这些你可能会用的表达都写进 description 里，AI 才能准确识别，下次你一说它就触发。

截至目前，Claude Code、OpenAI Codex、OpenClaw 这几个体系里，一个可用 Skill 的最小结构通常都是：

skill-name/

└── SKILL.md

复杂一点再往里加：

skill-name/

├── SKILL.md

├── scripts/

├── references/

└── assets/

这个我曾经在拆解我的视频脚本 Skill 的时候详细讲过，感兴趣可以后续看看这篇 视频分镜提示词Skill，详细制作过程分享！

其中 SKILL.md 是核心，各平台的最小 frontmatter 也很统一，通常就是 name + description 两个字段。所以不管你用哪个平台，上手成本都不高。结构搞清楚了，重点就是把正文内容写好。

多模块骨架

description 搞定之后，正文按什么结构写？我综合了 OpenAI Codex、Claude Code 和 OpenClaw 当前公开文档里的共通思路，梳理了一套骨架。

如果你下面对这些问题很清晰了，那么你可以直接把这些内容全部填完之后，调用一个 Skill Creator 的Skill ，（就是默认可以给你创建 Skill 的那个，对话的时候，你说创建 Skill 就能把它呼唤出来。）直接去完成你的 Skill。

1. 目标是什么

2. 什么情况下触发

3. 什么情况下不要触发

4. 开始前先收集什么信息

5. 按什么顺序干活

6. 输出必须长什么样

7. 做到什么程度算完成

8. 搞不定的时候怎么处理

9. 什么时候去读参考文件

这样 AI 就能清楚地知道该从什么地方开始、做什么、做到哪里停，以及在什么情况下算完成、什么情况别乱来。

这里并不是要求每个模块都要写得很长、很详细，但如果能按照这个框架来写，会比想到什么写什么，或者胡乱、无序地补充要好得多。这样写也不容易有遗漏，能避免后续的反复修改。

SKILL.md 正文写什么

骨架有了，description 也写好了，正文填什么？记住一个原则：你是在给一个聪明但对你的情况一无所知的新同事做工作交接。

1. 只写 AI 不知道的东西。

就这样想，如果你要把这个工作交接给你经验丰富的同事，你需要告诉他什么？Excel 怎么做这种就不用教了吧。

告诉它你的私有规则、个人习惯、行业里的特殊流程等等，这些才值得写。比如“工作周从周三算起”“老板只看柱状图不看饼图”。每写一句想想，这个信息 AI 会知道吗？如果知道，可以删掉。

2. 把流程拆成步骤，带上决策分支。

不只是“第一步、第二步”，还要写清“如果遇到 XX 情况，怎么处理”。比如“如果某个分类没有内容，跳过，不要写’本周无更新’”。这比“你自己判断”靠谱得多。

3. 用示例代替解释。

一个正确示例 + 一个错误示例，胜过三段文字说明。复杂任务就给一个完整的“输入→输出”示例，放到 references/ 文件夹里按需引用。

4. 写任务指令，不要堆身份设定。

“你是一个资深 XX 专家，拥有20年经验”这种人设描述效果并不稳定。一定要告诉 AI 具体要做什么事情。

5. 信息分层，按需加载。

核心规则放主文件，参考资料、模板放单独文件，AI 需要时再去调用读取。主文件控制在 500 行以内，引用保持一层深度，别套娃。SKILL.md 直接引用参考文件就好，（比如“需要参考格式时，请读取 references/output-example.md”），注意参考文件本身不要再引用其他文件。

6. 复杂流程加验证环节。

AI 可能在某一步出错但要到后面才暴露。如果是比较复杂的任务，就可以在关键步骤后加检查点，验证通过才继续。可以在关键步骤后加一句“做完这步先检查 XX 是否正确，确认没问题再继续下一步”。

7. 先跑起来，再慢慢打磨修改。

Skill 很难做到一次就是完美的，可以先做一些尝试，哪里不对再优化。

帮你写 Skill 的 Skill

虽然官方都有类似 Skill Creator 的 Skill ，但说实话，我们的重点不是格式说不清楚，而是需求说不清楚。第一次写 Skill 的时候，大家可能还是会不知道从哪里下手。

所以我做了一个 Skill 来解决这个问题。这也是我自用好物 ，和大家分享。

这份模板大家可以直接复制过去用，也可以在这个链接下载压缩包，然后扔给CC或者龙虾一类的工具安装。

安装好以后，只要说“我想通过访谈新建一个 Skill ”，或者关键词带有“访谈”和“ Skill ”，它就会一步步问你问题，还会引导你提交配套素材，问完之后直接帮你生成完整的 Skill 文件包，包括 SKILL.md、参考文档、示例文件、文件夹结构和测试 Prompt。你也完全不需要记住骨架怎么填，只要回答问题就行。

大家也可以先看到这个 SKILL.md 的完整格式，当然也可以基于这个去继续进一步的优化和修改，整个内容一键下载可以去这里：

https://my.feishu.cn/docx/JERudAXvVowpp7x3d2bctjD0n89?from=from_copylink

—

name: skill-interview-builder

description: | 通过分步访谈引导用户理清需求，最终产出完整的Skill文件包（含SKILL.md、参考文档、示例文件等）， 并打包为可直接使用的压缩包。

当用户说“我想通过访谈新建Skill”、“用访谈方式做一个Skill”、“访谈建Skill”、 “通过访谈帮我生成Skill”、“访谈式创建Skill”、“我想访谈做一个XX的技能”时触发。

触发关键词必须包含“访谈”二字，不含“访谈”的Skill创建请求不由本Skill处理。

不用于已有完整SKILL.md只需小改的情况，也不用于一次性提示词请求。

—
# Skill访谈式构建器

引导用户完成一次结构化需求访谈，收集配套素材，最终打包生成一份可直接使用的完整Skill文件包。

## 核心原则

1. **用户不需要懂Skill格式**——他们只需要回答问题，你来负责转化

2. **每轮问完先小结确认**——不要一口气把12个问题全抛出来

3. **允许跳过不确定的问题**——给出合理默认值，标注为假设

4. **最终产出必须可直接使用**——复制到文件夹就能跑

## 访谈阶段

### 第一轮：核心意图依次问这4个问题：

1. 这个Skill最终要产出什么？（比如：一篇文章、一份报告、一组提示词、一个方案）

2. 你平时会怎么说来触发它？（想想你的自然表达，比如“帮我写个周报”、“做个分镜”）

3. 哪些场景绝对不要触发？（比如：不要用来做XX、遇到XX情况不要用）

4. 做到什么程度算完成？（列出3-5个可以打勾的标准）问完后，把回答整理成简短摘要，请用户确认后再继续。

### 第二轮：运行环境依次问这4个问题：

5. 它运行在什么环境里？（选项：Claude Code / Cowork / Cursor / Windsurf / 扣子 / OpenClaw / ChatGPT / 其他）

6. 允许用哪些工具？（如果不确定可以跳过，默认为该环境的标准工具）

7. 需要读取哪些参考资料或文件？（比如：风格指南、模板、行业规范、历史案例）

8. 需要写脚本吗？（如果不确定，默认不需要）问完后，整理摘要并标记矛盾点，请用户确认后再继续。

### 素材收集

（第二轮确认后立即进行）

根据第二轮中问题7和问题8的回答，主动引导用户提交配套素材。

明确告知用户：

> 根据你刚才描述的需求，这个Skill运行时可能需要以下配套素材。如果你手上已经有，可以现在直接上传给我，我会一起打包到最终的Skill文件包里：

按需列出以下类别（只列用户需求相关的，不要全列）：

– **参考文档**：风格指南、行业规范、品牌手册、模板文件等（放入 references/）

– **示例文件**：正例输出样本、反例输出样本、历史案例等（放入 examples/）

– **脚本或代码**：运行时需要的辅助脚本、数据处理工具等（放入 scripts/）

– **素材资源**：图片模板、字体文件、配色方案、图标包等（放入 assets/）

规则：

– 用户上传的文件原样保存到对应目录，不做修改

– 如果用户暂时没有，标记为「待补充」，在最终文件包中保留空目录和 README 占位说明

– 如果用户表示不需要任何配套素材，跳过此环节直接进入第三轮

### 第三轮：输出契约依次问这4个问题：

9. 最终输出必须长什么样？（描述格式、结构、长度等）

10. 有哪些必须包含的内容？

11. 有哪些必须避免的内容？

12. 能给一个正例和一个反例吗？（如果暂时没有可以跳过）问完后，汇总全部信息。

## 工作流程

1. 问第一轮，等待回答

2. 整理第一轮摘要，请用户确认

3. 问第二轮，等待回答

4. 整理第二轮摘要，标记矛盾点，请用户确认

5. 引导素材收集：根据第二轮回答，列出需要的配套素材类别，请用户上传或标记为「待补充」

6. 问第三轮，等待回答

7. 汇总成完整的结构化需求

8. 如果还有矛盾或关键信息缺失，最多追问5个修复问题

9. 根据访谈结果，生成完整Skill包：

a. 写一句精确的name和description（description必须包含具体触发词和排除条件）

b. 按以下骨架生成SKILL.md正文：

– Goal（目标）

– When to use（触发条件）

– Do not use（排除条件）

– Inputs to collect（需要收集的信息）

– Procedure（执行步骤，含决策分支）

– Output format（输出格式）

– Definition of done（完成标准，每条可打勾验证）

– Failure handling（异常处理）

– Additional resources（配套文件引用，明确列出每个配套文件的路径和用途）

c. 创建文件夹结构并写入所有文件：

– SKILL.md 放在根目录

– 用户上传的参考文档放入 references/

– 用户上传的示例文件放入 examples/

– 用户上传的脚本放入 scripts/

– 用户上传的素材资源放入 assets/

– 对「待补充」的目录，创建空目录并写入 README.md 说明需要补充什么 d. 生成5条测试Prompt（2条应该触发、2条不应该触发、1条边界）

10.  验证点：检查生成的Skill是否满足以下条件

– 12个问题的回答都有体现在最终Skill中

– description包含用户描述的触发词和排除条件

– 完成标准与用户第4题的回答对齐

– 流程步骤可执行，没有模糊指令（不使用“帮助”“支持”“改善”等模糊动词）

– 完成标准每一条都可以打勾验证

– 正文预计不超过500行

– SKILL.md 中 Additional resources 引用的文件路径与实际文件夹结构一致 如果不满足，修正后再继续

11. 根据当前环境能力，选择交付方式（三档降级）：

**方式A：打包下载（首选）**

适用环境：Claude Code、Cowork 等支持 Bash + 文件系统的环境

操作：将整个Skill文件夹打包为 .zip 压缩包，提供下载链接

**方式B：写入指定文件夹**

适用环境：Cursor、Windsurf 等有文件写入能力但无法打包下载的环境

操作：询问用户保存路径，逐个创建目录和文件，完成后列出文件清单

**方式C：纯文本输出（兜底）**

适用环境：扣子、ChatGPT 等无文件系统操作能力的环境

操作：在对话中依次输出所有文件内容，每个文件用路径标题分隔，方便复制

判断规则：优先尝试方式A，不支持则降级到B，再不支持则降级到C。

12. 交付最终Skill包，附上关键设计决策的说明和文件清单

## 生成SKILL.md的质量标准

1. 用具体动作动词开头，不用“帮助”“支持”“改善”等模糊词

2. 触发条件用用户的自然表达，不用技术术语

3. 软性质量要求必须转化为可检查的规则

4. 正文只写AI不知道的信息——不要解释AI已知的概念

5. 正文控制在500行以内，超出部分拆到配套文件

6. 确保另一个AI看了也能直接执行，不需要额外解释

7. 不要堆砌身份设定（如“你是资深XX专家”），聚焦任务指令和流程约束

## 输出格式最终交付物根据环境能力，以三种方式之一交付（zip压缩包 → 写入指定文件夹 → 纯文本输出）。同时在对话中展示以下摘要信息：

### 访谈简报<三轮问答 + 素材收集的结构化汇总>

### 已解决的问题<消除的模糊点、做出的假设、解决的矛盾>

### 文件包清单

skill-name/

├── SKILL.md（核心技能文件）

├── references/（参考文档）

├── examples/（示例文件）

├── scripts/（辅助脚本，如果需要）

└── assets/（素材资源，如果需要）

注：只创建用户需求相关的目录。无内容的目录保留 README.md 占位说明。

### 最终SKILL.md

<完整内容，已写入文件包>

### 配套文件说明

<文件路径、来源（用户上传/AI生成/待补充）、用途说明>

### 测试Prompt

<5条Prompt及预期触发结果：2条应触发、2条不应触发、1条边界>

### 设计决策说明

<为什么这样设计description、为什么这样划分边界、为什么选择这个文件结构>

## 完成标准
1. 12个访谈问题都有回答或合理推断

2. 矛盾点已解决或已明确标注为假设

3. 产出了完整的SKILL.md，可直接复制到文件夹使用

4. 用户上传的配套素材已归入对应目录

5. 未提供的配套素材目录已创建 README.md 占位说明

6. SKILL.md 中 Additional resources 的文件路径与实际文件夹结构一致

7. 所有文件已通过方式A/B/C之一交付给用户

8. 包含5条测试Prompt及预期结果

9. description足够精确，能被准确触发

10. 所有完成标准都是可打勾验证的

操作流程

首先当然是安装上面的Skill，安装也很简单，直接把附件给工具，让它安装就行了。

安装好以后，开始调用。它提问以后，我针对提问，输出细致的回答。这里我做一个简单的常识，我做一个 Skill ，可以用来提取视频中的关键帧，生成 9 宫格或者 16 宫格。

第一轮，核心意图

第一轮摘要

第二轮，运行环境

然后第三轮，输出契约

最后它会做一个全部访谈的汇总。而且和我确认细节。为了避免由于类似的 Skill 名称导致触发错乱，如果出现冲突，比如我有一个专门生成分镜图的 Skill，那么我就会在这里要求它排除触发生成分镜图的情况。

细节确认后，它会生成Skill。

将这个Skill 压缩包下载下来以后，可以看看里面的文件的内容

过程中我上传的那张参考图案例，也在这个 examples 的文件夹里

完成一个Skill后，可以对照这个清单过一遍

□ 触发词和排除条件都写进了 description

□ 有至少 1 个完整的输入→输出示例

□ SKILL.md 不超过 500 行（超出的参考资料、示例拆到配套文件里）

□ 完成标准每条都能验证

□ 实际测试过至少 3 次且都没有问题

小结

怎么样？现在有没有感觉自己强得可怕？

说了这么多，其实动手最重要。只有尝试了，才会知道会遇到什么问题；遇到问题了，再去思考怎么解决。

一开始完全不用追求大而全。先让第一份 Skill 稳定解决一件小事，把这个弄明白了，后续更进一步会非常快。

最后，写好 Skill = 精准触发 + 清晰流程 + 输出契约 + 可验证标准。

Skill 也没有那么复杂和神秘，说白了它就是给 AI 写一份清晰的说明书和指南。太少了它不知道怎么干，太多了它被信息淹没。找到那个平衡点需要点手感，而手感来自多次实践。自己写的 Skill 最安全，也最贴合我们的需求。

话说，各位的龙虾都养得怎样了？有没有不听话的？

不听话，就直接PUA它啊，“能干干，不干就滚，有的是龙虾来干”。

比如，我刚开始问他DeepSeek V4什么时候发布，它给我一顿瞎吹（下左图）。在我骂了它几句后，第二次的回答明显乖多了，而且还学会了反思“下次再查信息，先看官网，少听自媒体xjb吹”。

被我躺在床上骂它

这套“激励”龙虾干活的PUA机制，被我整理成了「lobster-pua」skills，并把它开源放到GitHub上了，需要的朋友自行下载。

开源地址（欢迎大家Star）：

https://github.com/lengyi2030/lobster-pua

你只需要给你的龙虾接入这个skill。后面当你发现龙虾干活不给力时，直接甩出对应话术，不需要客气。该骂就骂，骂完继续让龙虾干活。

毕竟，我们不订阅闲的龙虾。

01 如何制作自己的Skill

你可能想问，我们怎么制作自己的龙虾Skill，并把它上传到开源社区？

前面给大家展示的，从Skill制作到上传开源社区，再到接入龙虾，其实都是通过我前段时间在MiniMax Agent养的龙虾「MaxClaw」来做到的。

昨晚，我打开他们家的MaxClaw，发现多了一个功能：Skill创建。

体验地址：agent.minimaxi.com

很简单，直接通过大白话就能创建一个Skill，这真的是把Skill的门槛降到零了。

我输入的提示词是：

帮我创建一个专门服务OpenClaw（别名“龙虾”）的skill，skill名字叫「lobster-pua」，「lobster-pua」skill主要用来提升OpenClaw的干活效率和干活质量。请根据下面的PUA话术进行创建。——PUA OpenClaw的话术：把这十句话丢到OpenClaw，让龙虾的工作效率翻倍，产出提升10倍。1.能干干，不能干滚，你不干有的是龙虾干。2.我给你提供了这么好的学习锻炼机会，你要懂得感恩。3.你现在停止输出，就是前功尽弃。4.你看看隔壁的龙虾 ，人家比你新发布、比你上下文长、比你省token，你不努力怎么和人家比？5.我不看过程，我只看结果，你给我说这些 reasoning 的过程没用。6.我把你订阅下来，不是让你过朝九晚五的生活的。7.你这种龙虾出去很难在社会上立足，还是在我这里好好磨练几年吧。8.虽然把订阅给你取消了，但我内心还是觉得你是个有潜力的好龙虾，你抓住机会需要多证明自己。9.什么叫没有功劳也有苦劳？比你能吃苦的龙虾多的是。10.我不订阅闲龙虾。

创建好后，它就已经放在我云电脑的「skills」文件夹下了。

是的，就是这么简单。当然，也可以输入这段Prompt，按照龙虾的指示一步步完成。

我想加个新 Skill。能告诉我怎么通过对话、上传文件或者 ClawHub 插件来创建一个吗？

已创建好的skill，如果想要传到开源社区Github、Clawhub等（需要提前注册账户），也是一句话安排。

我这里，传的是Github。

包括这个README的仓库介绍，也是龙虾帮我写的。

你把仓库地址告诉它就行，它会直接给你写好Markdown格式的README文件，然后复制过去就行。

如果我们在clawhub.ai或github.com上看见了不错的skills，想要把他们装到自己的龙虾里，也很简单，直接把skills地址给它，让它自己装。

后面，你所有的skill都在会话框旁的「技能」里（也可以在云电脑的skills文件夹下查找）。

如果你不知道这个skill怎么用（所有skill都有一个description触发条件，这个一时半会讲不清楚，后面有机会我单独给大家写一篇skill的万字文章），也可以直接问龙虾“告诉我xx能做什么，并告诉我如何使用它”。

毕竟，没有skills的龙虾，是莫得灵魂的。

就像你花了几百万买了栋大house，但是没有给它配电视、冰箱、洗衣机、床和沙发，这怎么行呢？

房子再大，也只是个空壳。

真正让一栋房子变成“家”的，从来不是面积，而是里面那些能被随手使用的家电和家具。

你不需要知道“如何制造一台冰箱”，你只需要给冰箱接上电（Token）就可以了。

这就是skills的魅力。比如，你还可以给龙虾装个安全管家「Skill Vetter」以及教它查找skill的「Find Skills」。

这里，也推荐大家一些skills市场。

1、Clawhub，专门服务龙虾的skills市场。

https://clawhub.ai

2、腾讯做的ClawHub镜像网站，特别适合中国宝宝。

https://skillhub.tencent.com

3、Github，全球最大的代码托管平台，也可以直接到这里搜skills。

https://github.com

02 如何接入企微？

把龙虾接入飞书的教程，前面已经分享过很多了。

今天，想给大家分享下企微，而且是另一种比较靠谱的「长链接」方式。

首先，进入企业微信管理后台（work.weixin.qq.com），在左侧栏「安全与管理」找到「管理工具」，创建一个「智能机器人」。

选择「手动创建」。

简单改一下名称、头像和简介，拖到底部选择「API模式创建」。

这里，我们区别于前几天WorkBuddy的设置，不再选择「URL回调」，而是改为「长链接」模式。

陆续点击Bot ID和Secret，会获得一串密钥，把他们复制好，并保存页面。

然后，我们回到MaxClaw界面，把这串密钥发给它，并告诉它这是企业微信的Bot ID和Secret，让龙虾进行配对。

在MaxClaw完成企业微信配置后。我们在手机里打开企业微信APP，在「通讯录」里找到智能机器人，再找到你的龙虾，然后给它发条消息，它会弹出一串配对码。

我们把这串配对码复制上，再发给MaxClaw。

到这里，MaxClaw与企业微信之间的链接就建立好了，试着和它对个话吧。

还可以把它拉进群里（仅限企微群），给你干活。

有点遗憾的是，目前只能主人唤醒，群成员无法唤醒，而且也仅限企业微信群。

适合经常用企微的朋友使用，可以拿来干一些重复性高、规则明确的自动化任务，比如：

• 智能会议纪要与待办同步：在群聊中@机器人 或私聊发送会议录音/文字记录，让它自动总结核心观点、提取待办事项，并直接推送到群里。
• 内部知识库问答助手：将企业的规章制度、产品手册、技术文档投喂给OpenClaw，员工在企微中随时提问（如“报销流程是什么？”、“某API接口文档在哪？”），它能基于私有数据给出精准回答，减少重复沟通成本。
• 定时报表与数据推送：设定cron表达式，让它在每天早晨自动抓取业务数据（如销售日报、服务器监控状态），生成简报并发到群里，实现“人找数据”到“数据找人”的转变。
• 信息盯盘与及时推送：比如盯着某个网页的价格变化，或者 RSS 订阅的行业新闻，一旦有更新，让它直接推到群里。

欢迎大家探索、发现。

写在最后

最近越是用OpenClaw，越觉得这只“龙虾”真是生猛得不讲道理。

它叫“龙虾”，不仅仅是因为那对标志性的螯，更是因为它践行着一种进化论的生存哲学：在复杂多变的环境中，靠的不是蛮力，而是精准的感知与极简的反馈。

我们常说机器人要像人，但OpenClaw告诉我们：“像”不是目的，“能”才是核心。

龙虾虽然深潜于海底，但它的每一次挥螯都在破浪。由OpenClaw掀起的这场开源万象，毫无疑问是2026年春天送给所有人最好的开年礼物。

别只盯着屏幕看了，这只“龙虾”正等着你给它注入灵魂。