2025 年 10 月 16 日 Anthropic 正式推出 Claude Skills 能力，宣布 Claude 可以使用“技能”来提升特定任务的表现：“Claude can now use Skills to improve how it performs specific tasks. Skills are folders that include instructions, scripts, and resources that Claude can load when needed.”。换言之，开发者可以把某类任务的指导文档、示例代码等打包成一个 Skill，Claude 会在需要时动态加载，从而更好地完成专门任务（如处理 Excel 表格、遵循品牌文档格式等）。 Anthropic 官方工程博客 的定义：随着模型能力的提升，我们现在可以构建与完整计算环境交互的通用 Agent。但随着这些 Agent 变得更强大，我们需要更可组合、可扩展、可移植的方式来为它们配备领域专业知识。这促使 Anthropic 创建了 Skills：有组织的指令、脚本和资源文件夹，Agent 可以动态发现和加载它们，以更好地执行特定任务。
附带工具使用：如果该技能涉及模型调用已有工具（如模型自带的读写文件、运行代码等操作），可以写明调用方式和注意事项。例如 Claude Code 环境下常用的 <bash>、<python> 等工具指令。Anthropic 建议在 Claude 中使用特定格式（如 XML 标签）来提示模型严格遵循指令，这在 Skill 中也可体现。
明确的命名与描述：技能的名称和描述是模型决策的入口，必须清晰准确。名称最好能概括技能主题，例如“pdf-reader”“sql-query”等，长度短而有辨识度。描述则需要点明技能要做什么以及何时该用。Anthropic 建议描述不要泛泛而谈，应包含触发场景的关键词。例如：“Apply Acme Corp brand guidelines to presentations and documents” 这条描述清楚表明了应用场景（演示文稿和文档）。另外，从 OpenCode 社区经验来看，描述的措辞甚至可以带有引导性语气，以促使模型注意使用技能——比如在描述里使用“MUST”或“重要”等词强调必要性。有开发者分享说，把描述改成“You MUST load me before any commit”后，模型几乎每次在提交代码前都会调用对应技能。当然，要避免滥用夸张词，否则可能导致模型过于频繁地错误调用技能。总之，描述的策略是在 200 字符左右的限制内，既准确包含技能功能，又埋下足够的提示让模型联想到相关场景
合理的内容结构（Schema 设计）：这里的“Schema”不是指 JSON Schema，而是 Skill 正文内容的组织。良好的结构能帮助模型快速抓住重点。可以考虑将 Skill.md 正文拆分成几个小节，例如：“What I do（我能做什么）”、“When to use me（何时使用）”、“Steps（步骤）”、“Examples（示例）”等，用二级或三级标题划分。在“What I do”部分列出技能提供的具体功能点，用简短 bullet points 描述，让模型了解能力边界。在“When to use me”部分说明触发条件，这能强化描述里已有的信息，让模型更精准判断时机。如果有示例输入/输出或模板格式，可以放在 Examples 部分，让模型模仿。这样的模块化写法既方便模型阅读，也利于日后维护扩充。另外，如果技能内容较多，Anthropic 建议使用渐进披露的思路，将不常用或互斥的内容拆到附加文件中，用超链接引用。这样当模型不需要那部分信息时，就不会占用主 SKILL.md 的宝贵上下文窗口。例如，在 PDF Skill 中，关于填写 PDF 表单的说明被移到了 forms.md，主 Skill.md 里只在需要时提示 Claude 打开它。这种结构优化可以让技能既详尽又高效。
提供调用上下文与约束：在 Skill 中，我们可以巧妙地为模型设置执行时的上下文信息，包括允许哪些操作、不允许哪些操作等。Anthropic Claude 的技能规范甚至支持在元数据里限定技能执行时可用的工具集合（Claude Code 的实现里有一个 allowed_tools 机制，用于防止技能滥用无关工具）。在 OpenCode 中，可以通过权限配置限制哪些技能可被哪些代理使用。作为技能作者，应在说明中明确模型该如何使用技能内的工具/脚本。例如：“Use the fetch_data function from this skill’s script to get the data” 这样的提示，确保模型不会偏离预期流程。同时，也可以在 Skill 中指定不要做什么，例如提示模型“请勿调用网络 API”或“遇到错误不要反复尝试超过 3 次”等等。如果技能需要依赖某些第三方库或特殊环境，也务必在元数据的 dependencies 字段注明（如 python>=3.8, pandas>=1.5.0），以便部署技能时准备好运行环境。总之，想象模型在没有人类监护的情况下执行技能，你需要在 Skill 里把边界和规则交代清楚。
模型提示的设计技巧：Skills 毕竟还是以“提示”的形式在引导模型，因此编写时要遵循良好的提示设计原则。首先，语言上简明扼要、措辞专业但避免歧义。模型有时会错误解读人类语言中的模糊表述，所以尽量使用直接的指令语句。例如，“Step 1: Do X. Step 2: Do Y. If Z happens, do …”。必要时可以使用列表、表格、特殊格式来强化结构。Anthropic 的经验是，Claude 对于带有 XML 标签的提示遵从度更高，因为它被训练中过类似格式。因此在 Claude 的技能中，开发者常用<tool>、<assistant>之类的标签包裹指令，让模型更严格地执行。而对于 OpenAI 的模型，使用 Markdown 代码块、分隔符等方式也能帮助模型理清步骤。其次，避免在 Skill 中加入与该任务无关的信息，以免干扰模型注意力。技能应该聚焦于完成当前任务的一系列要点，切忌把过多背景或聊天式的内容混进来（除非这些就是任务必须的）。再次，要考虑模型可能的误解点，提前在 Skill 中澄清。例如，如果技能涉及翻译代码注释，也许要提醒模型不要翻译代码本身。换位思考模型阅读 Skill 时的视角：哪些地方可能让模型困惑？它会不会忽略某个重要步骤？通过不断模拟模型执行技能，可以发现提示需要改进之处。
Skills 生态和自动化发现：随着 Anthropic 将技能规范开放，以及社区贡献大量技能范例，各平台有望出现技能市场或目录，方便共享和发现技能。有人在讨论中提到：“如果有一个带评论和评分的 Skills 市场，那将大大推动这项技术传播”。Anthropic 官方也表示，会致力于完善技能的完整生命周期支持，包括发现、分享等环节。未来我们也许能在类似 App Store 的平台浏览各类技能，一键安装到自己的 AI 代理中。与此同时，模型自动发现技能的能力可能出现——例如模型遇到未掌握的新任务时，能联网检索相应的技能包并请求用户确认后加载。这类似于人不会的就去搜教程的思路。技术上要实现这一点，需要解决技能的标准化描述和可信度评估问题，但开放标准已经迈出第一步。可以想见，一个繁荣的技能生态将极大丰富 AI 的即用能力库，让“小模型也能办大事”（通过加载专精技能来弥补参数规模不足）。
上下文驱动的 Skills 装配：当前的 Skills 主要以单一技能调用为单位，未来代理可能学会动态组合多个技能来应对复杂任务。这有点类似人类解决难题时会调用不同领域的专长。OpenCode 等已经支持子代理（Sub-agent）和多技能并行，如 Reddit 社区中有人用 Skills 让模型并行调用谷歌搜索获取深度资料。未来模型或许能根据上下文自动决定技能调用顺序，甚至在一次对话中串联多个技能（先用 Skill A 处理文本，再用 Skill B 分析结果）。这需要更强的规划与记忆能力，可能涉及和 Agent 规划算法结合。不过值得高兴的是，Skills 本身为这种流水线式智能提供了很好的模块封装。我们已经看到一些探索：比如 Anthropic 提到，会研究 Skills 如何与 MCP 等多步调用协议互补，教会代理处理涉及外部软件的复杂工作流。这暗示未来 AI 代理在拿到任务时，可能先通过内置 planner（或大模型 chain-of-thought）分解子任务，然后挑选合适的技能一步步执行——这和当前一些开源 Agent 框架（如 AutoGPT）试图让 AI 自己规划调用工具的思路不谋而合。有了技能这个高层抽象，agent 的自主决策空间将更加优化，自动化组装技能解决问题的时代值得期待。
多模态 Skills 和模型融合：今天的 Skills 主要围绕文本和结构化数据处理，但随着多模态大模型的发展，多模态技能可能会出现。例如，一个图像处理技能，里面包含如何调用图像识别模型或绘图工具的说明；一个语音助手技能，指导模型如何调用语音合成/识别引擎等。实际上，OpenAI 已经在尝试这方面：ChatGPT 的 PDF 技能通过将 PDF 转为图片，再利用具备视觉能力的 GPT 模型来解析，从而保留了格式和图像信息。这可以视作一种雏形的多模态 Skill 应用。未来，当多模态模型（如 Google Gemini 等）成为主流，技能中可以囊括处理视觉、音频的步骤，让 AI 真正成为全能助手。例如，“设计海报”技能可以指导模型调用绘图 API 生成初稿，再用视觉模型检查设计是否美观，再调整，如此循环。这需要跨模型协作，而技能文件恰好可以作为不同能力模型之间沟通的桥梁，因为它以一种人类可读、模型可解析的形式描述任务。在开放技能标准下，不排除未来出现技能级别的多模态接口，即一个技能既能被语言模型加载，其内嵌的脚本还能调用视觉模型 API。这会将 AI 能力提升到一个新的层次，真正实现多模态、多工具融合。
自主 Agent 与 Skills 的融合：2025 年被称为“AI Agents 元年”，各种定义的 Agent 层出不穷。Skills 的出现，无疑为 Agent 提供了更易用的能力插件。我们可能会看到，未来的 AI Agent 框架把技能当作原生单元，支持热插拔。Agent 可以根据用户目标动态加载相关技能，而不是预先写死在系统提示里的功能。另外还可以让代理自主地进化：Anthropic 展望未来，希望让“Agents to create, edit, and evaluate Skills on their own”。也就是说，让 AI 代理在执行任务中学会把自己的新知识提炼成技能，下次遇到类似问题就能自己调用。这几乎是在赋予 AI 一种“编写说明书教自己”的元能力。如果实现，AI 将具备持续改进的闭环：执行任务 → 学到新模式 → 生产新技能 → 下次表现更好。这有点像人类在工作中总结沉淀方法论，只不过由 AI 自动完成。当然，实现这一点还有诸多挑战，包括保证 AI 编写的技能正确且不危害系统。不过一些早期迹象已经出现：OpenAI Codex 引入了 skill-creator 工具，可以根据用户描述自动生成技能骨架供开发者完善。这说明让 AI 参与技能编写并非天方夜谭。
更安全和精细的能力管控：随着技能赋予模型更多自主权，安全问题也不可忽视。未来的发展一方面会加强技能沙盒环境的安全隔离（例如执行代码的权限控制、资源使用限制等），另一方面会引入更细粒度的技能权限。OpenCode 已经实现了按模式（pattern）控制哪些技能可被使用，未来企业可能需要对技能做签名、验证，确保模型只能加载可信来源的技能。也可能出现技能审计工具，自动分析技能脚本是否存在恶意操作。这些配套措施将使技能生态在扩大的同时，安全性有保障。最终目标是建立可信的 AI 能力商店：用户/企业可以方便地获取所需技能，又不用担心其中暗藏风险。
展望：Skill 技术的出现，被很多业内人士视为 AI 应用的一个分水岭。一位开发者甚至称：“Skills 的出现也许比 MCP 更为重要”。因为它找到了一个几乎零门槛（写文档）的方式来持续提升 AI 能力，让专业人士可以将自己的 know-how 注入 AI。如果说预训练模型给予 AI 普遍的语言和常识，那么技能机制正在赋予 AI 一个连接人类具体经验和工具的接口。可以想象，不久的将来，不同领域会沉淀下丰富的技能库，AI Agent 可以像安装软件那样加载“法律咨询技能”“医学诊断技能”“编程调试技能”……AI 不再是一个通用的大脑，而可以瞬间学习各种“手艺”。这种灵活性和可扩展性，正是 Skill 技术的魅力所在。我们正迈向一个高度模块化、可组装的 AI 智能时代。在这个过程中，无论是开发者还是普通用户，都将因技能生态的繁荣而受益：前者更快捷地构建复杂应用，后者享受到更专业、更个性化的 AI 助手服务。
结语
Skills 技术展现了统一的趋势：让大模型变得更聪明、更勤劳、更听话。它汲取了软件工程的模块化思想，又融合了 Prompt 的灵活创造力，正在重塑人们对 AI 能力边界的想象。对于 AI 开发者来说，掌握 Skills 意味着掌握了一种新的编程范式——不再只是写代码给计算机执行，而是写“说明书”给 AI 去理解执行。而对于普通用户，将来或许一句话就能安装“新技能”到你的 AI 助手，让它完成以前无法企及的任务。Skills 为 AI 打开了一扇门，一扇通往无限可能的门。我们正站在门槛，目睹一个丰富多彩的 AI 技能世界徐徐展开。
