去年年底的一天，我盯着 Claude Code 的对话框，陷入了深深的自我怀疑。
屏幕上是刚写好的一段 Prompt，长达 800 字，几乎占满了上下文窗口。里面有项目的技术栈说明、代码风格约束、命名规范、测试要求——所有能让 AI 写出合格代码的指令。我已经写过几十个这样的 Prompt 了，每一个都像是在写一份小型产品说明书。
然后我在 Anthropic 的更新日志里看到了一行小字："Introducing Skills——a new way to package expertise for Claude。"
三个月后，我把所有 Prompt 都删了。
回忆：Prompt 时代的"手艺活"
如果一年前你问我，用好 AI 的关键是什么，我会毫不犹豫地回答：写 Prompt。
那时候，"提示词工程"是 AI 圈最火的概念。市场上充斥着"Prompt 模板大全""万能 Prompt 公式"，甚至诞生了"Prompt 工程师"这个新工种。听起来很高大上，但实际体验远没有想象中光鲜。
每一段 Prompt 都是一次重复劳动。项目换了一个新模块，Prompt 要重写。代码风格更新了，Prompt 要调整。团队来了新人共享同一套 Claude 配置，你还是得把 Prompt 发给他。
这不是工具的问题，而是思维方式的局限——我们一直在告诉 AI"这次怎么做"，却从来没有教它"按照我们的方式做事"。
这种模式有一个专有名词：一次性指令。每轮对话都是重新开始，知识无法沉淀，经验无法复用。
转折：Skill 出现了
2025 年 10 月，Anthropic 在 Claude Code 中推出了 Skill——一个看起来不起眼、但后来越想越不对劲的新功能。
Skill 的官方定义是"可复用的知识包"，但我更愿意叫它"AI 的岗位培训手册"。它不再是你对 AI 说的那句"这次记住要……"，而是一份可以永久保存在项目里的 SOP——告诉 AI：不管什么时候、不管什么任务，遇到这类情况，请按这套规则来。
刚推出时，我周围的人反应并不热烈。"不就是把 Prompt 挪到文件里吗？"是普遍第一印象。
但真正让我改观的是 Skill 的渐进式披露设计。这个名字很技术，但理解起来很简单：
想象一个工具箱。Prompt 就像你把所有工具都堆在桌子上——不管你用不用，它们都在那里占地方。而 Skill 是把工具放在挂着标签的抽屉里——平时你看不到它们，但当你需要板手的时候，你拉开标着"板手"的抽屉，里面的东西正好在那里。
具体来说，Skill 只有 name 和 description 常驻在 Claude 的上下文中（大约 100 个 token），完整的指令体只在匹配到任务时才加载。如果你注册了 50 个 Skill，Claude 不会一次性读 50 份文档，它只读它现在需要的那一份。
这个设计的精妙之处在于：它承认了 AI 的上下文是有限资源，并为此做了工程取舍。
对比一下：传统 Prompt 把所有的规则塞进对话窗口——Token 消耗高、匹配精度低、每次都要重复。Skill 把规则分散存储、按需加载——Token 消耗降 60-80%，精度反而更高。
深挖：从"告诉它怎么做"到"让它学会怎么做"
Skill 的出现，改变的不仅仅是技术指标。
2025 年底到 2026 年初，Anthropic 在不到两个月的时间里做了一系列动作：
- 2025 年 12 月，将 Agent Skills 作为开放标准发布。48 小时内，Microsoft 和 OpenAI 宣布采纳。
- 同月，将 MCP 捐赠给 Linux 基金会管理的 Agentic AI Foundation。
- 2026 年 2 月，发布 30 多页的《Skill 创建指南》。
- 2026 年 5 月，开源
anthropics/skills示例仓库。
一家公司的一小步，变成了整个行业的一大步。
这背后反映的是什么？我认为是 AI 开发从"提示词工程"到"技能工程"的范式转移。
提示词工程本质上是告诉——你告诉 AI 你要什么。技能工程本质上是教会——你帮 AI 建立一套可以长期遵循的行为模式。
就像"给一个人一份菜谱"和"教一个人学会做菜"的区别。前者每次都要重来，后者一次学会终身受用。
Skill 不是唯一一个在做这件事的系统。Claude Code 的扩展机制实际上有三个层次：
Hooks 解决"不能做什么"——在操作前自动检查是否踩了红线。 Skills 解决"应该怎么做"——在任务触发时告诉 AI 正确的流程。 Agents 解决"谁来做"——把复杂任务交给独立的子 Agent 处理。
这三个层次和 CLAUDE.md 一起，构成了 AI 开发的完整"治理体系"。业界有个很形象的类比：Claude Code 从"需要手把手带的实习生"变成了"自带 SOP 的高级工程师"。
不只有光鲜的一面
当然，如果你觉得 Skill 是完美的，那还言之过早。
Anthropic 自己的测试数据揭示了一个不容忽视的瓶颈：当 Skill 数量超过 50 个，模型的选择精度会断崖式下降。换句话说，Claude 在 50 个选项中选对的概率还不错，但塞进 100 个 Skill 时，它开始犯迷糊了。
社区的实践经验也暴露了不少问题：
最常见的踩坑是 description 写成了功能摘要，而不是触发条件。很多人在写 Skill 时，description 写的是"为测试提供指导"，而不是"当用户要求生成测试、编写测试用例、添加测试覆盖时使用"。前者 Claude 几乎不会主动触发——它不是不够聪明，而是根本不知道这个 Skill 应该在什么场景下用。
另一个典型问题是 SKILL.md 写成了小说。有人把整个团队的代码规范全都塞进一个 Skill 文件里，结果触发一次吃掉几千 token。正确的做法是把 body 控制在 2000 字以内，详细内容拆到 references/ 目录按需加载。
Anthropic 内部团队分享过一个观点："任何 Skill 中信息量最大的部分就是踩坑点章节。" 一个好的 Skill 不是从零开始设计出来的，而是在使用中不断补漏洞迭代出来的。
对 2026 年 AI 开发的思考
Skill 的快速普及让我开始重新思考一个问题：AI 开发者的核心能力到底是什么？
去年，大家的答案是"写 Prompt 的能力"。但过去几个月发生的事让我改变了想法。当 Skill 把"知识封装"这件事从手工操作变成标准化流程，真正拉开差距的，不再是谁能写出更长更精细的 Prompt，而是谁能构建更清晰、更可复用的能力体系。
Skill 带来的最大改变不是技术上的，而是思维方式上的：从"和 AI 对话"到"训练 AI 的工作方式"。
Anthropic 在开源 Skills 时说过一句话，我觉得是对这个时代最好的注脚：
"大模型的第一阶段是规模竞争。第二阶段是推理能力竞争。现在正在进入第三阶段：能力工程化。真正的差距，不在模型参数，而在能力结构设计。"
这或许就是 2026 年 AI 开发最需要理解的变化。模型在变得更好，但用好模型的方法论也在变得完全不同。Skill 只是一个开始。
参考来源：Anthropic 官方帮助中心、Claude Code 实战社区、Anthropic Skills 开源仓库
本文同步发布于微信公众号，欢迎关注获取更多 AI 工具实战内容。
