你每次打开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年春天送给所有人最好的开年礼物。

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