前言
2025 年 10 月，Anthropic 悄然上线了一个叫 Claude Skills 的功能。彼时，大多数人的注意力还集中在模型参数竞赛和 MCP 协议上，Skill 只是开发者社区里一个不起眼的小实验。
短短两个月后，2025 年 12 月 18 日，Anthropic 做了一个出人意料的决定：将 Agent Skills 发布为开放标准，规范托管在 agentskills.io。
紧接着，微软、OpenAI、Cursor、GitHub 等巨头相继跟进——ChatGPT 悄悄出现了几乎一模一样的架构，CodeBuddy 成为国内首个支持 Skills 的 AI 编程工具。
到 2026 年 1 月，字节跳动的 AI Agent 平台 “扣子”上线了“技能商店” ，把“Skill”这个词正式带入国内大众视野。
从一个厂商的实验性功能，到全球 AI 生态的集体跟进，Skill 只用了不到三个月。
这背后隐含着一个关键判断：AI 的竞争，正在从“谁家模型更强”，转向 “谁能让模型真正干好活” 。而 Skill，恰好就是连接“聪明的大脑”与“能干的手”之间的那根关键纽带。
一、Skill 是什么？
1.1 一个简单的类比：AI 的工作手册
想象一下这个场景：你招了一个很聪明、知识面很广的新员工。他知道 SQL 是什么，懂编程语言的基础语法，甚至可以帮你分析数据。但你让他按照公司的代码规范写一段接口，他却不知道你们用的是什么框架、命名风格是什么、测试用例该怎么写、PR 流程怎么走。
这不是他不够聪明，而是你没有给他“工作手册”。
Skill 就是这样一份“给 AI 看的工作手册”。它用结构化的方式告诉 AI：面对某类特定任务时，你应该按照什么步骤操作、遵循什么规范、注意哪些坑、使用哪些工具。
所以，Skill 的本质就是我们熟悉的提示词（prompt）。但让它从普通 Prompt 中脱颖而出的，是三个工程维度的关键升级：
- 自动发现和按需加载：Skill 不用你每次手动粘贴提示词，AI 会根据任务自动判断是否需要加载；
- 自包含的指令包：Skill 可以携带参考文档和可执行脚本，形成一个完整的“能力单元”；
- 开放标准格式：Skill 遵循标准化的文件夹规范，理论上可跨平台、跨工具复用。
用一句话来概括 Skill 的核心定义：它是给 AI Agent 用的“技能包”模板，将特定领域的专业知识、工作流程和工具封装成独立、可复用的模块。
二、Skill 的结构：一个文件夹里的“能力工程化”
2.1 三层结构
从技术实现上看，一个 Skill 就是一个文件夹。打开它，你会看到这样的结构：
my-skill/
├── SKILL.md # 核心指令文件（必须）
├── scripts/ # 可执行脚本（可选）
├── references/ # 参考文档（可选）
└── assets/ # 资源文件（可选）
其中最核心的 SKILL.md 文件，由两部分组成：
- YAML 元数据：包含
name（技能名）和description（描述）。name仅限小写字母、数字和连字符，不超过 64 个字符；description最多 1024 个字符，需要清楚说明 Skill 的功能和使用时机。
- Markdown 正文：详细的工作指导、步骤说明、最佳实践、注意事项和示例。
除了核心的 SKILL.md，Skill 还可以携带：
- Scripts：Python、JavaScript 等可执行脚本，让 AI 除了“知道怎么做”还能“真正动手”。
- Resources：模板、参考数据、示例文件等，为 AI 提供更多上下文和素材。
2.2 渐进式披露：Skill 最精妙的设计
Skill 真正的设计精髓，在于“渐进式披露”机制：
- 第一层：AI 启动时只加载所有已安装 Skill 的元数据（name + description）。每个 Skill 在上下文窗口中只占几十个 token 的摘要。
- 第二层：当 AI 判断某个 Skill 与当前任务相关时，才加载完整的
SKILL.md内容。 - 第三层：当需要执行具体操作或查阅参考资料时，AI 才会进一步读取脚本和附加文件。
这意味着，你可以为一个 Skill 准备海量的参考资料和复杂脚本，但不会一次性把上下文窗口塞满。无关任务时，Skill 几乎不占 token；相关任务时，它才会逐步展开。
这种设计让 Skill 实现了“知道什么时候应该用什么”——这也就形成了动态的 Prompt。
三、Skill / Tool / Agent / Prompt：四者如何分工？
很多人第一次接触 Skill 时会困惑：它和 Tool 有什么区别？和 MCP 有什么关系？Agent 又在其中扮演什么角色？
一张简单的四层架构图可以帮助理清思路：
- Tool（工具层） ：最底层的原子操作，比如“执行 SQL 查询”“发送 HTTP 请求”“读取文件”。Tool 解决的是“能做哪些操作”的问题。
- Skill（能力层） ：将多个 Tool 和专业知识组合成一个可复用的能力单元，比如“PDF 处理”“品牌风格文案生成”“全栈开发自动化”。Skill 解决的是“一件事怎么做对”的问题。
- Agent（调度层） ：负责理解用户意图、拆解任务、选择合适的 Skill 并协调执行。Agent 解决的是“谁来统筹做”的问题。
- Prompt（指令层） ：最基础的交互方式，每次都需要手动编写。Prompt 解决的是“一次性交流”的问题。
当 Skill 清晰时，Agent 会更简单；当 Skill 混乱时，调度逻辑会指数级膨胀。这就是为什么 Anthropic 核心工程师会说：“别造 Agent 了，造 Skills 就行”。
四、AI Coding 的新范式：我们不写代码了，我们写 Skill
这才是这篇文章最想和你聊的部分。
过去两年，AI 编程工具的发展经历了一个清晰的轨迹：从代码补全（GitHub Copilot 早期版本），到对话式编程（Cursor Composer），再到 Agent 模式（Devin、Cognition）。
每一步都在减少“人写代码”的比重。
但 Skill 的出现，把这件事推到了一个质变的临界点。
4.1 代码是给机器看的，Skill 是给 AI 看的
在传统软件开发中，我们的工作产出是源代码。源代码的本质，是一套精确的、无歧义的指令，告诉计算机应该如何执行计算、存储数据、渲染界面。
而 Skill，本质上也是一套指令——但它的受众不是计算机，而是 AI 模型。
这是一个根本性的角色转换：你不再直接指挥计算机干活，你是在训练和配置一个 AI 员工，让它按照你的标准和流程去指挥计算机干活。
让我们看一个具体的例子。假设你在一家电商公司，需要开发一个“用户下单后发送优惠券”的功能。
传统方式下，你写的是实现逻辑：条件判断、对象创建、方法调用。
Skill 方式，你写的是工作流程：
## 触发条件
当用户订单金额超过 100 元时，执行此技能。
## 执行步骤
1. 调用订单服务，获取用户 ID 和订单金额。
2. 如果金额 > 100：
a. 调用优惠券服务，创建一张面值 10 元的折扣券并分配给该用户。
b. 调用邮件服务，使用模板 `order_coupon_email` 发送通知。
3. 记录本次操作到日志表 `marketing_actions`。
## 注意事项
- 优惠券有效期设为 30 天。
- 同一用户 24 小时内最多触发一次，避免骚扰。
- 邮件模板已包含退订链接，不要重复添加。
你不再写 if 和 else，你写的是“先做什么，再做什么，注意什么”。AI 拿到这份 Skill 后，会自己去调用相应的工具（Tool），生成实际的代码并执行。
4.2 你的价值从“实现”变成了“定义”
这个转变的核心在于：工作的重心从“如何实现”转移到了“如何定义”。
过去，一个程序员的专业能力体现在他知道如何用代码表达业务逻辑——知道用哪种设计模式、如何处理边界条件、如何优化性能。
未来，一个“AI 时代的程序员”的专业能力将体现在：
- 流程设计能力：能不能把一个业务需求拆解成清晰、无歧义、可执行的步骤？
- 规范沉淀能力：能不能把团队的编码规范、架构约束、业务规则沉淀为结构化的指令？
- 边界定义能力：能不能准确预判 AI 会在哪里出错，并提前在 Skill 中加入约束和提醒？
- 工具编排能力：知不知道有哪些 Tool 和 MCP 服务可用，并能把它们恰当地编排进 Skill？
换句话说，你从“写代码的人”变成了“写说明书的人”——但这份说明书不是给人看的，是给一个极度聪明但缺乏常识的 AI 看的。这本身就是一个全新的技能工种。
4.3 一个真实的工作场景模拟
让我们模拟一个真实场景，感受一下这种转变。
背景：你所在的公司有一套严格的后端开发规范——Controller 层只做参数校验和路由，Service 层处理业务逻辑，Repository 层封装数据库操作。DTO 和 Entity 必须严格分离，所有数据库字段必须有注释，所有 API 必须提供 OpenAPI 注解。
传统做法：每个新入职的开发者都需要花一两周熟悉这套规范，Code Review 时 Senior 工程师不断指出“这里不应该在 Controller 里调用 Repository”“DTO 不要直接暴露 Entity 字段”之类的问题。一套 CRUD 接口，真正写业务逻辑的时间可能只有 30%，剩下 70% 是在“按规矩办事”。
引入 Skill 后：团队的 Tech Lead 写了一个 backend-crud-generator Skill：
## 技能名：backend-crud-generator
## 描述
为公司 Spring Boot 项目生成标准的 CRUD 接口。当用户需要新增一个数据实体时使用。
## 执行规范
1. 必须生成以下文件结构：
- Controller: {Entity}Controller.java
- Service: {Entity}Service.java + {Entity}ServiceImpl.java
- Repository: {Entity}Repository.java
- DTO: {Entity}CreateDTO.java, {Entity}UpdateDTO.java, {Entity}ResponseDTO.java
- Mapper: {Entity}Mapper.java (使用 MapStruct)
2. 各层职责：
- Controller: 只做 @Valid 校验，调用 Service，返回统一响应格式 Result<T>
- Service: 包含业务逻辑，事务注解 @Transactional，禁止直接调用 Repository 以外的数据访问
- Repository: 继承 JpaRepository，方法命名遵循 Spring Data JPA 规范
3. 必须包含：
- 所有数据库字段的 @Column 注解和 comment 属性
- 所有 API 的 @Operation 注解和描述
- 分页查询接口（使用 Pageable）
- 对应的单元测试骨架
## 输入变量
- `{Entity}`: 实体名称（如 User, Order, Product）
- `{fields}`: 字段列表及类型
现在，一个初级开发者只需要告诉 AI：“用 backend-crud-generator 给 Product 实体生成 CRUD，字段包括 name(String)、price(BigDecimal)、stock(Integer)。”
AI 会严格按照 Skill 中定义的规范生成全套代码——Controller 不会越界调用 Repository，DTO 和 Entity 严格分离，注解一个不落。Code Review 的负担从“检查规范遵守情况”变成了“检查 Skill 定义是否合理”。
Tech Lead 的工作产出变了：他不再需要逐个审查每一行代码，而是把精力花在迭代和优化这份 Skill 本身。他思考的问题是：这份 Skill 的步骤是否足够清晰？有没有覆盖所有边界情况？要不要加入对缓存策略的处理？
4.4 “写 Skill”这件事，本身就是一种编程
你会发现，写一份好的 Skill，和写一份好的代码，底层能力是相通的。
- 抽象能力：你需要把一个重复出现的任务模式抽象成一个通用模板，保留可变的参数（就像函数的参数）。
- 模块化思维：一个 Skill 应该只做一件事，就像单一职责原则。复杂任务应该通过多个 Skill 协作完成，而不是写一个巨大的“万能 Skill”。
- 边界条件处理：你需要在 Skill 中预判 AI 可能犯的错误，并加入“注意事项”和“错误处理”段落——这本质上就是异常处理逻辑，只是用自然语言表达。
- 可测试性：好的 Skill 会附带测试用例，就像代码有单元测试。
所以，不要觉得“写 Skill”是降级了。恰恰相反，它可能是一种更高级的编程——你在用一种 AI 能理解的语言，编写一套能够在无限具体场景中实例化的“元程序”。
一位 Cursor 社区的开发者说得很好：“我以前写 TypeScript，现在写 Markdown。看起来是降维了，但实际上我在做更抽象的工作——我写的是代码生成器，只不过生成器本身也是一个 AI。”
五、未来展望：Skill 正在改变 AI 的工程范式
Anthropic 发布的一份 30 多页《Skill 创建指南》，首次系统定义了“能力模块化”范式。其中明确写道：
“大模型的第一阶段是规模竞争。第二阶段是推理能力竞争。现在正在进入第三阶段：能力工程化。真正的差距，不在模型参数，而在能力结构设计。”
这个判断精准地捕捉到了当前 AI 生态的转折点。
过去一年，我们看到 MCP 解决了 AI 如何连接外部世界的问题，A2A 解决了 AI 智能体之间如何通信协作的问题，而 Skill 解决的是 AI 如何系统化地掌握专业技能的问题。
对于我们这些写代码的人来说，一个更深远的变化正在发生：
软件工程的“源代码”概念正在被重新定义。
过去，源代码是 .java、.py、.ts 文件。
未来，一个软件项目的核心资产可能是一套 .skill 文件夹——它们定义了 AI 如何理解业务、如何遵循规范、如何编排工具。代码本身变成了 AI 根据 Skill 动态生成的“中间产物”。
这就像我们从汇编语言走向高级语言，再从高级语言走向声明式配置。每一次跃迁，我们都在用更抽象的方式描述“我们想要什么”，而把“如何实现”交给更下层的系统。Skill 只是这条演化路径上的最新一站。
当然，这一切不会一夜之间发生。在今天，Skill 还处于早期阶段，标准在演化，工具在完善，最佳实践在沉淀。但方向已经足够清晰：AI 时代的开发者，不是被 AI 替代的人，而是懂得如何“编程 AI”的人。
总结
Skill 不是一个炫酷的“神技术”，而是一个务实且极具工程价值的创新。它用“一个文件夹 + 一份 Markdown 文件”的极简方式，解决了 AI 领域一个长期存在的痛点：通用模型虽然知识渊博，但缺乏特定领域的操作流程和专业规范。
更重要的是，Skill 正在重新定义我们的工作。在 AI Coding 的时代，我们的核心产出不再是逐行编写的代码，而是定义工作流程、沉淀领域规范、编排工具能力的 Skill。
写好一份 Skill，就是写好一份给 AI 的“元程序”——它比单次的代码产出更具杠杆效应，因为它可以在无数次生成中被复用、被遵循、被迭代。
理解 Skill，不仅是理解一个新工具，更是理解 AI 时代一种新的工作方式。当写代码这件事逐渐变成 AI 的职责，我们真正的竞争力，就落在了“如何教会 AI 写好代码”这件事上。
