如果 AI 编程助手只能做一件事，它永远比不上能做一百件事的助手。但如果这一百件事每次都要你手把手教，那也不比自己做快多少。真正的效率飞跃，来自把"教过一次的经验"变成"随时可调用的能力"。
这就是 Claude Code 技能系统要解决的问题。
从一个真实场景说起
Anthropic 内部有数百个活跃技能，每天都在被工程师使用。这些技能不是什么高深的 AI 黑科技——它们就是 Markdown 文件。
一个典型的技能长这样：
---
name: code-review
description: "当用户要求审查代码变更时使用此技能"
when_to_use: "用户说'审查这段代码'、'review这个PR'、或提到代码质量时"
model: sonnet
effort: high
---
你是一名高级代码审查者。请检查以下内容：
1. 逻辑错误和潜在 bug
2. 安全漏洞
3. 性能问题
4. 代码风格一致性
对于每个发现，给出严重程度（🔴 严重 / 🟡 警告 / 🟢 建议）和修复建议。就这么简单。一个 YAML 头部描述元数据，一段 Markdown 正文描述指令。没有 JSON schema，没有 Python 插件系统，没有 npm 依赖——纯文本。
Anthropic 的工程师 Thariq 在分享中提到一个有趣的数据：内部最受欢迎的技能不是那些复杂的工作流编排，而是最简单的几行规则——比如"每次保存文件后自动格式化"，或者"提交代码前检查有没有遗留的 console.log"。
技能的九种类型
Thariq 把 Anthropic 内部的数百个技能归纳为九大类型，覆盖了软件开发的几乎所有环节：
1. 库/API 参考
把常用库的 API 文档整理成技能，让 Claude 不用每次都去查文档。比如"React Server Actions 最佳实践"，里面包含了完整的用法示例和常见坑。
2. 产品验证
定义什么是"好的用户体验"，让 Claude 在写代码时有判断标准。比如"移动端适配检查清单"，列出了触摸目标大小、字体层级、断点处理等标准。
3. 数据获取与分析
教 Claude 如何连接内部数据库、如何写特定格式的查询、如何解读结果。
4. 业务流程自动化
把重复的业务操作封装成技能——生成周报、同步状态、发送通知。
5. 代码脚手架
项目初始化模板、新组件创建规范、文件命名约定。
6. 代码质量审查
这是使用最频繁的类型。代码审查、安全扫描、性能检查。
7. CI/CD 部署
定义构建、测试、部署的完整流程。
8. Runbooks
故障排查手册——出问题时 Claude 照着步骤走就行。
9. 基础设施运维
Kubernetes 配置、服务器管理、日志分析。
这九种类型揭示了一个关键洞察：技能的本质不是"教 AI 新能力"，而是"把团队的最佳实践固化成可复用的知识单元"。
两种技能模式
技能系统有两种工作模式，它们看起来相似，但设计哲学完全不同。
模式一：主动技能（Skill）
这是最常见的模式。用户通过斜杠命令或自然语言触发，技能像一个独立的工具被调用。
比如"天气 SVG 生成器"技能——你问"今天天气怎么样"，Command 组件收到请求后，让 Agent 去获取天气数据，然后调用这个技能把数据渲染成一张漂亮的 SVG 图表。
关键特征：
- 用户可见，可以主动调用
- 接收对话上下文中的数据作为输入
- 独立执行，产出自包含的结果
- 类比：工具箱里的专用工具
模式二：代理技能（Agent Skill）
这种技能不直接被用户调用。它被注入到某个代理的启动上下文中，作为该代理的"领域知识"。
比如一个"天气数据获取"技能——它不会被用户直接使用，而是被预加载到天气代理的知识中。当天气代理启动时，这个技能的完整内容已经被塞进了上下文窗口。代理知道该调用哪个 API、参数格式是什么、怎么解析返回值。
关键特征：
- 用户不可见（
user-invocable: false） - 在代理启动时注入，不是运行时调用
- 提供指令性知识而非可执行操作
- 类比：新员工的入职手册
这两种模式的配合方式很优雅：代理技能负责"怎么获取数据"，主动技能负责"怎么呈现结果"。获取和渲染解耦，各管各的。
写好技能的九条铁律
根据 Thariq 分享的 Anthropic 内部经验，写好一个技能需要遵循九条最佳实践。
1. 不说废话
技能正文里不要写"你是一个优秀的 AI 助手"之类的客套话。每一行都应该是有信息量的指令。模型不需要鼓励，它需要规则。
❌ "请仔细检查代码，你很棒的！"
✅ "检查以下三项：空指针引用、SQL 注入、未处理的 Promise"2. 建 Gotchas 区
这是整个技能系统里价值最高的部分。Gotchas 就是"踩坑记录"——记录那些看起来正确但实际会出错的地方。
## Gotchas
- Stream API 的 `.collect()` 在空流上不会抛异常，但会返回空集合
- `@Transactional` 只对 public 方法生效，private 方法上的注解会被静默忽略
- Docker 多阶段构建中，COPY 指令的路径是相对于前一个阶段的Thariq 特别强调：在技能被 Claude 加载时，Gotchas 区域的信号量（即注意力权重）最高。因为这些是来自真实失败的经验，模型会优先参考。
3. 文件系统渐进式披露
不要把所有内容塞进一个巨大的 SKILL.md。告诉 Claude 文件结构，让它按需读取。
## 参考文件
- `api-spec.yaml` — 完整的 API 规格
- `examples/` — 使用示例
- `gotchas.md` — 常见陷阱这样 Claude 在处理简单问题时只读 SKILL.md 本身，遇到复杂场景才去翻参考文件。上下文更精简，响应更快。
4. 不要过度约束
这是最常见的错误。给目标和约束，不要给步骤式指令。
❌ "第一步打开文件，第二步找到函数，第三步修改参数..."
✅ "将所有 API 调用从 REST 迁移到 GraphQL，保持向后兼容"原因很简单：模型比你更擅长规划执行步骤。你规定步骤反而限制了它的优化空间。
5. 描述字段是触发条件，不是摘要
技能的 description 字段不是给人类看的简介，而是告诉模型"什么时候该用这个技能"的触发条件。
description: "当用户提到部署、发布、上线、或者需要将代码推送到生产环境时使用"模型会根据这个描述判断是否激活技能。写成摘要就失去了这个功能。
6. 想清楚设置流程
有些技能依赖外部配置——API 密钥、数据库连接、MCP 服务器。在技能里明确写出设置步骤，避免 Claude 盲目尝试。
7. 记忆与数据存储
告诉 Claude 技能产出的数据应该存哪里。是写入文件、更新数据库、还是只在对话中返回。这避免了结果丢失或重复计算。
8. 脚本与代码生成
技能不只是文字指令，可以包含完整的脚本模板。比如一个"数据库迁移"技能，里面可能包含 SQL 模板、回滚脚本、验证查询。
9. 按需 Hooks
Hooks 是确定性挂载到代理生命周期的钩子函数。比如 PostToolUse Hook 可以在每次文件写入后自动运行格式化。不是每个技能都需要 Hook，但在需要自动化流程时它非常强大。
编排的艺术：Command → Agent → Skill
技能不是孤立使用的。Claude Code 的架构推崇一种三层编排模式：
Command（入口）→ Agent（执行者）→ Skill（能力单元）以"天气查询"为例：
- Command 收到用户请求"今天天气怎么样"，先用轻量模型（haiku）询问用户偏好（摄氏还是华氏）
- Agent 被派出去获取天气数据，它启动时已经预加载了天气获取技能（Agent Skill），知道该调用哪个 API
- Skill 被调用来把数据渲染成 SVG 图表（主动技能）
每一层各司其职：Command 负责交互和路由，Agent 负责执行和获取数据，Skill 负责专业输出。这种分离让每个组件可以独立替换——换一个城市的天气 API？改 Agent Skill。换一种图表风格？改主动 Skill。用户交互流程变了？改 Command。互不影响。
Boris 在分享中提到一个深刻的设计原则：入口轻，执行重。Command 用便宜快速的模型，Agent 用中等模型处理逻辑，只有在真正需要深度思考的时候才用 Opus 这种顶级模型。整个调用链的模型选择像一个金字塔——底层频繁调用用便宜模型，顶层复杂决策用贵模型。
10 个官方内置技能
Claude Code 自带 10 个内置技能，覆盖了最常见的开发场景：
| 技能 | 用途 |
|---|---|
| code-review | 深度代码审查 |
| batch | 大规模批量操作 |
| debug | 系统化调试 |
| loop | 定时循环任务 |
| claude-api | SDK 开发辅助 |
| fewer-permission-prompts | 减少权限弹窗 |
| run | 启动应用服务 |
| verify | 验证代码变更 |
| run-skill-generator | 生成新的启动配方 |
| simplify | 代码精简 |
其中最值得细说的是三个：
/batch 是 Boris 最喜欢炫耀的功能。它能把一个大规模变更并行分发到数百个独立的 git worktree 中，每个 worktree 由一个独立的 Agent 处理。Boris 曾经一次性让 Claude 在 200 个仓库中统一升级依赖版本——整个过程全自动，每个仓库一个独立 PR。
/loop 是定时任务的优雅实现。/loop 5m /simplify 会每 5 分钟运行一次代码简化技能，最长持续 3 天。任务绑定在会话上，退出 Claude 就自动停止。底层使用 CronCreate/CronList/CronDelete 工具，但用户完全不需要知道这些。
/simplify 的设计很有意思。它不是让一个 Agent 去简化代码，而是同时派出 4 个独立的 review Agent，从不同角度审查代码质量。4 个 Agent 各自给出简化建议，然后汇总决策。这种"多视角并行审查"的模式，比单个 Agent 反复检查更有效。
从个人技能到团队知识库
技能的威力在于它的分发方式。
小团队把技能文件夹检入 Git 仓库，所有人共享。每次有人踩了新坑，就更新 Gotchas。技能在 PR review 中不断迭代，越用越精准。
大团队用插件市场。Anthropic 内部有一个技能商店，工程师可以发布、搜索、安装技能。好的技能会自然浮上来——不是因为有人推广，而是因为用的人多。
Boris 有一个观点值得深思：技能系统的终极目标不是让 AI 更聪明，而是让团队的知识不再只存在于个人的脑子里。 每个人的经验、踩过的坑、总结的最佳实践——都变成一个 .md 文件，可以版本控制、可以 review、可以传承。
当资深工程师离职时，他留下的不是空荡荡的工位，而是一套经过千锤百炼的技能文件。新来的工程师不需要"跟老人学习三个月"——Claude 已经学会了所有前人的经验。
这可能是技能系统最深远的影响。
下期预告
下一篇，我们将深入 Claude Code 最令人兴奋的能力：多代理协作。Boris 怎样同时指挥 5 个 AI 实例并行工作？Agent Teams 和 Subagent 有什么区别？从单兵作战到 AI 军团的组织方法是什么？
下期见。
Views: 18