Anthropic 在 2026 年 6 月 3 日发布了一篇工程博客，分享了他们内部大规模使用 Claude Code Skills 之后的总结：九种分类和若干最高回报的写法原则。
这篇文章的价值在于它是"我们自己用了几百个 Skill 之后学到的"，而不是产品发布日的概念介绍。
Skills 不只是 Markdown 文件
一个常见的误解：Skills 就是给 Claude 看的指令文档，所以写成 Markdown 就够了。
Anthropic 的纠正：Skills 是文件夹，不是文件。
一个 Skill 的目录里可以放：
SKILL.md（指令文档）- 脚本和可执行工具（agent 可以发现和调用）
- 参考资料、模板、数据文件（放在子目录里，按需加载）
- 配置文件（持久化用户偏好）
把 Skill 写成单个 Markdown 文件能用，但你放弃了"渐进式披露"的能力——agent 可以先读摘要，在需要时再深入子目录取资料，而不是一口气把所有内容塞进上下文。
九种 Skill 分类
Anthropic 把内部数百个 Skill 归纳成九类。最好的 Skill 清晰地属于其中一类；跨多类、“什么都能做"的 Skill 反而会让 agent 困惑。
1. 库 & API 参考（Library & API Reference）
给内部或外三方库、CLI、SDK 提供文档——重点放在边界情况和常见陷阱，而不是重复官方文档已有的内容。
Claude 本身已经知道 React、NumPy、requests 等主流库的用法。这类 Skill 的价值在于它知道：
- 你们公司内部 SDK 的非显而易见的参数
- 某个 CLI 工具在特定版本有个已知 bug 要绕开
- 某个函数在你们代码库里的惯用方式和文档里不一样
不要写 Claude 默认就会的东西；写它不知道的。
2. 产品验证（Product Verification）
测试工作流 + 外部工具（Playwright、tmux 等），带有程序化断言来验证代码功能。
这类 Skill 的核心价值是把"验证"变成可重复调用的命令：让 Claude 跑完改动之后，一条命令触发 Skill，自动验证结果，而不是靠人肉检查。
3. 数据获取 & 分析（Data Fetching & Analysis）
连接监控栈、数据源，并附上凭据管理和常见查询模式的库。
这类 Skill 的典型形态：给 Claude 一个能查生产数据库慢查询的接口、拉 Datadog 指标的脚本、或者一套凭据管理的规范。Claude 不需要每次去想"这个数据怎么拿”，按 Skill 里的模式走就行。
4. 业务流程 & 团队自动化（Business Process & Team Automation）
把重复工作流整合成单条命令，通常依赖其他 Skills 或 MCP。
比如：“每次发 PR 前，跑 lint、更新 changelog、通知 Slack 频道”——这些步骤可以包成一个 Skill，一条命令搞定。这类 Skill 往往是其他 Skills 的编排层。
5. 代码脚手架 & 模板（Code Scaffolding & Templates）
针对特定框架生成样板代码，支持用自然语言描述需求——远超纯代码生成的能力上限。
和"让 Claude 从头写"相比，Skill 里放着你们团队已沉淀的架构约定，Claude 生成的脚手架天然符合项目规范，不需要再改一遍。
6. 代码质量 & 审查（Code Quality & Review）
质量标准执行和同行评审机制，可作为自动化 hook 或 GitHub Actions 运行。
这类 Skill 可以是：“按我们团队的 code review checklist 审查这段代码”，或者是封装成 PreToolUse hook 在每次提交前自动触发的检查。
7. CI/CD & 部署（CI/CD & Deployment）
代码拉取、推送、部署编排，含监控和回滚能力。
给 Claude 一个 Skill，它就知道：从哪个环境拉代码、用哪个部署命令、部署后怎么验证、失败了怎么回滚。这把原本需要看 Runbook 才能执行的操作变成了可以代理给 Claude 的自动化任务。
8. Runbook
基于症状的调查协议，通过多工具生成结构化报告。
这是运维场景最典型的 Skill：“线上出现 P2 告警，按这个流程检查五个可能的原因，用指定的工具拉日志，最终给出一份结构化诊断报告”。
9. 基础设施操作（Infrastructure Operations）
常规维护过程，内置对危险操作的护栏。
清理旧镜像、轮换证书、缩容实例——这类操作有固定步骤、但容易手滑。Skill 的优势是可以在 SKILL.md 里明确写：哪些操作需要二次确认，哪些操作绝对禁止，通过 PreToolUse hook 在当前 Skill 激活时临时加护栏，会话结束自动解除。
让 Skill 真正好用的七个原则
这部分是 Anthropic 工程师在踩了足够多坑之后总结的，逐条都值得停下来想想。
原则 1：不要写显而易见的内容
Skill 的价值在于改变 Claude 的默认推理方向。如果 Claude 本来就会做这件事，你写进 Skill 只是浪费上下文。
反面案例：“始终写整洁、可维护的代码”——这种话 Claude 本来就会遵守，写进 Skill 没意义。
正面案例：“我们的 auth middleware 不通过 DI 注入，而是从 global store 拿——这和文档里的示例不同，别用注入的方式”。
原则 2：把"踩坑集"当成最高信号内容
gotchas 部分是 Skill 里信号密度最高的地方。每次 Claude 用你的 Skill 犯了一个错，把这个坑加进去。时间久了，这个部分会成为 Skill 最有价值的内容。
原则 3：用文件夹结构做渐进式披露
参考资料、脚本、模板放在子目录里，SKILL.md 只写摘要和指向子目录的路径。让 Claude 在需要时按需深入，而不是一次性塞入大量内容占满上下文。
原则 4：灵活而不过度规定
提供必要信息，但不要把每一步都写死。过于规定性的 Skill 会让 Claude 在遇到边缘情况时不知变通。
原则 5：描述即触发器
SKILL.md 开头的描述（description）是给模型看的，不是给人看的。它的作用是告诉 Claude"什么时候应该调用这个 Skill"，而不是"这个 Skill 能做什么"。
写法："当需要验证支付流程功能时调用" 比 "支付验证工具集" 更有效——前者告诉 Claude 何时用，后者只是标签。
原则 6：用 ${CLAUDE_PLUGIN_DATA} 持久化数据
如果 Skill 需要跨会话保存用户偏好或状态，用 ${CLAUDE_PLUGIN_DATA} 目录存储，这样数据在 Skill 升级后依然保留。
原则 7：提供可复用的代码，而不只是指令
Skill 目录里放一个现成的 Python 脚本或 shell 工具，比在 SKILL.md 里描述"Claude 应该写一个脚本来做这件事"效果好得多。前者是直接给 Claude 一把锤子，后者是让它自己去打铁。
规模化分发：内部市场和版本控制
Anthropic 指出，当 Skills 数量增长，按需安装比让每个人装所有 Skill 更重要——否则过多 Skill 的 schema 会占满上下文窗口。
几个实践：
- 把 Skills 放进独立的 git 仓库版本控制
- 建立内部市场，由质量验证过的 Skill 才能进
- 有机增长优先：让 Skill 先自然传播获得认可，再收入市场——这是天然的质量过滤
Skills 也可以互相引用，形成依赖链。
量化 Skill 使用
通过 PreToolUse hook 记录每个 Skill 被调用的次数，可以发现：
- 哪些 Skill 使用频率高、值得持续投入
- 哪些 Skill 触发率过低（可能是描述没写好、或者需要场景教育）
一个判断框架
每次想为一个重复任务写 Skill 时，可以问自己：
- 这件事 Claude 默认就会做，还是我需要告诉它特定于我们项目的做法？（如果是前者，不需要 Skill）
- 这个 Skill 属于九类中的哪一类？还是跨多类？（跨类越多越要警惕）
- 我的 gotchas 里记了什么？（如果这个 Skill 从没踩过坑，也许还没真正用起来）
原文：Lessons from building Claude Code: How we use skills，Anthropic 官方博客，2026 年 6 月 3 日。
关于
关注我获取更多资讯
