AI Coding 指北开发者的 Agent 工程与 AI 编程实践站
工具库Claude Code2026/06/094 分钟

Anthropic 内部用了几百个 Skills 后，总结出这套实战指南

很多人第一次看到 Claude Code 的 Skills，会以为它只是一个更长的提示词。

Anthropic Skills 实战指南头图

很多人第一次看到 Claude Code 的 Skills，会以为它只是一个更长的提示词。

Anthropic 最近发了一篇官方博客，讲他们在内部大规模使用 Skills 的经验：几百个 Skills 已经在 Anthropic 内部活跃使用，而且它们成了 Claude Code 最常用的扩展点之一。

这件事有个很重要的信号：真正有价值的 AI 使用方式，不是每次都重新写 prompt，而是把团队经验沉淀成可复用的工作流。

Skill 不是提示词，是工作流资产

一个好的 Skill，不是在 Markdown 里写“请认真一点”“请遵守最佳实践”。

它更像一个小型工具包：可以包含说明、脚本、模板、示例、参考资料，甚至按需启用的 hooks。Claude 先读入口文件，需要细节时再打开对应资料或运行脚本。

普通 prompt 解决一次问题。Skill 解决一类反复出现的问题。

如果你在团队里重复解释过很多次“这个内部 CLI 怎么用”“发版前要查哪些指标”“支付流程改完怎么验收”，那它大概率就值得做成一个 Skill。

1. 不要写常识，要写模型总犯错的地方

Anthropic 提到一个很实用的原则：不要在 Skill 里写显而易见的内容。

Claude 本来就会写代码，也能读项目文件。真正值得写进去的，是模型默认不知道、但团队经验里非常关键的细节。

场景Skill 里应该写什么
内部 SDK初始化方式、废弃 API、容易踩坑的参数
支付流程测试卡号、真实状态查哪张表、哪些成功响应不可信
数据分析标准口径、事件 join 方式、字段命名差异
前端设计团队不接受的视觉套路、组件密度、验收标准

所以一个 Skill 里最有价值的部分，通常不是完整教程，而是 Gotchas：Claude 上次在哪里翻车，下次就不要再翻。

2. 一个 Skill 只解决一类问题

Anthropic 把内部 Skills 大致分成 9 类：库和 API 参考、产品验证、数据分析、业务流程自动化、代码脚手架、代码质量和 Review、CI/CD、Runbooks、基础设施运维。

分类本身不是重点。重点是：好的 Skill 通常边界很清楚；什么都想管的 Skill，反而容易让 Agent 困惑。

不要写一个 engineering-best-practices 巨无霸。更好的拆法是：

不推荐更推荐
team-dev-rulesapi-conventions、testing-practices、release-checklist
frontend-helperdesign-review、component-scaffold、playwright-verify
ops-assistantoncall-runner、cost-investigation、deploy-service

Skill 越具体，触发越准，Claude 越知道该调用哪些材料和工具。

3. 把文件夹当成渐进式上下文

很多人写 Skill，只写一个 SKILL.md。这当然能用，但没有发挥 Skills 的真正价值。

Skill 是一个文件夹，不只是一个 Markdown 文件。你可以让主文件保持很短，把详细内容拆出去。

checkout-verifier/
├── SKILL.md
├── references/
│   ├── stripe-test-cards.md
│   └── invoice-states.md
├── scripts/
│   └── verify-checkout.ts
└── assets/
    └── report-template.md

SKILL.md 只负责告诉 Claude：什么时候用、先做什么、资料在哪、脚本怎么跑、输出套哪个模板。

这样 Claude 不需要一开始就吞下所有上下文。需要测试卡号时读 references/，需要验收时跑 scripts/，需要交付报告时用 assets/。

这就是一种很朴素但有效的上下文工程。

4. 最值得优先做的是验证类 Skill

如果只能先做一个 Skill，我建议做验证类。

Anthropic 也提到，产品验证类 Skills 对 Claude 输出质量的提升最明显。原因很简单：Agent 最大的问题不是不会生成，而是生成之后不知道自己到底对不对。

一个验证类 Skill 可以要求 Claude：

这会把“模型觉得没问题”，变成“工具链真的跑过”。

对团队来说，最值得沉淀的不是“怎么写代码”，而是“写完以后怎么证明它能用”。

今天就能开始的最小版本

不用一上来搭 marketplace，也不用一次写几十个 Skills。先从一个最小版本开始：

  1. 找一个你最近重复解释过 3 次以上的流程，比如发版、验收支付、写测试、查日志。
  2. 新建一个 SKILL.md，只写触发场景、执行步骤、常见坑。
  3. 把长资料放进 references/，把可重复命令放进 scripts/。
  4. 用几次后，把 Claude 犯过的错补进 Gotchas。

Skill 不需要一开始就完美。Anthropic 的经验也很接地气：很多好的 Skills，最初只是几行说明和一个常见坑，后来因为团队不断补充边界情况，才慢慢变得好用。

所以，不要把 Skills 当成高级配置。它更像团队给 Agent 留下的一份工作手册。

当团队开始把经验写成 Skill，AI 助手就不再只是一个会聊天的模型，而是逐渐学会你们的工具、流程、口径和验收标准。这才是 Skills 真正有用的地方。

参考资料