模型决定 AI 能想多远，Skill 决定 AI 能干多稳。Skill 的质量，取决于你往里面装了多少只有你才知道的东西。

这篇文章来自 Anthropic 工程师 Thariq 3 月 18 日发布的长推《Lessons from Building Claude Code: How We Use Skills》。Anthropic 内部已经有数百个 Skill 在活跃使用，这是他们踩坑后的经验总结。

---

核心观点：Skill 补的不是说明书，是语境

大部分 Skill 不好用的根本原因：写进去的东西是 AI 本来就知道的。

• 低语境知识：API 文档、代码示例、技术教程（模型自己查得到）

• 高语境知识：团队特有的坑、验收标准、"做久了就知道"的默认规则（只有你清楚）

好 Skill 的价值：把你脑子里的高语境经验翻译成 AI 能读取的格式。

---

5 个共性详解

1️⃣ 信息密度最高的是"坑点总结"

"一个 Skill 里信息密度最高的部分是坑点总结。"

错误写法：告诉 Claude"这个 SDK 的 init 方法接收三个参数"（它早就知道了）

正确写法：告诉它"这个审批流程文档里标的是可选，但实际上必须走，不走后面的权限审核会直接卡住"

自测问题：这里面有多少内容是 Claude 自己搜不到的？如果大部分都搜得到，这个 Skill 价值有限。

---

2️⃣ Description 字段是触发条件，不是简介

很多人随手写一句"这是一个翻译工具"就完事了。

Description 是给模型看的触发条件，决定 Skill 会不会在该出现的时候出现。

好的 Description 像精准的 if 条件：

当用户需要翻译英文文档（PDF/DOCX/EPUB/网页文章）为中文，包括学术论文、书籍、长文翻译、术语密集型内容时触发。不适用于日常短句翻译或口语化翻译。

该触发的场景列清楚，不该触发的场景排除掉。

---

3️⃣ 让 Skill 有自己的记忆

Skill 可以有自己的记忆，这是最被低估的一点。

实现方式：

• 简单：日志文件，每次执行完追加记录

• 中等：JSON 文件，记录结构化数据

• 复杂：SQLite 数据库

为什么重要：传统 AI 助手最抓狂的问题是"每次都像第一次见你"。有了记忆，Skill 能知道上次做了什么、今天有什么变化。

例子：站会日报 Skill 如果保留历史，第二天就能只写变化（新增什么、完成什么、卡了什么），而不是从零生成。

---

4️⃣ Skill 的威力不在 markdown，在于整个文件夹

一份 markdown 写得再好，承载的东西也有限。

正确做法：

• scripts/ 目录：放 Python 函数，AI 调用而不是从头写

• assets/ 目录：放模板文件，AI 填空而不是猜格式

• 参考代码：放 3 个写得好的文件，AI 一看就懂团队风格

核心思路：渐进式上下文披露。把详细内容拆到不同文件里，AI 在需要时自己读。让 Claude 把精力花在决策上，而不是重建轮子上。

---

5️⃣ 有能力还要有边界和护栏

如果 scripts、模板解决的是"AI 能不能做"，钩子机制解决的是"AI 会不会乱做"。

临时钩子（on-demand hooks）：只在 Skill 激活时生效，结束自动关闭。

例子：

• /careful Skill：拦截危险操作（rm -rf、DROP TABLE、force-push、kubectl delete）

• /freeze Skill：AI 只能编辑指定目录，其他地方碰都不让碰

设计巧妙之处：大多数人写 Skill 是"告诉 AI 该做什么"，临时钩子反过来是"告诉 AI 什么绝对不能做"。前者是引导，后者是护栏。

---

Anthropic 内部的 9 类 Skill

1. 库和 API 参考

2. 产品验证

3. 数据获取与分析

4. 业务流程自动化

5. 代码脚手架

6. 代码质量与审查

7. CI/CD 与部署

8. Runbook（报警→排查→报告）

9. 基础设施运维

关键判断标准：这个 Skill 是在补"知识差"还是补"执行差"？

• 补知识差：重点写坑、边界、反例

• 补执行差：重点给脚本、验证工具、自动化流程

---

写 Skill 的正确顺序

1. 先列坑：列出团队在这类任务上踩过的 10 个最大坑，写进 Gotchas

2. 写好 Description：当触发条件写，不是当简介写

3. 给工具：给脚本、模板、参考代码，不只是文字

4. 加记忆：哪怕只是一个日志文件

5. 加护栏：告诉 AI 什么绝对不能做

---

写在最后

Anthropic 内部的 Skill 管理模式像早期 App Store：先让数量爆发，再靠口碑和使用数据做淘汰。

但他们也警告：创建糟糕或冗余的 Skill 太容易了。确保你有某种策展机制再上架。

对普通开发者来说，这条信息的意义是：做 Skill 的门槛虽然低，但做好 Skill 的标准正在变高。

真正让 Skill 好使的，是高语境信息：你们团队特有的坑、你们自己的验收标准、那些"做久了就知道"的默认规则、"这个命令千万别在生产环境跑"之类的护栏。

这些东西没法从预训练里学到，没法从官方文档里抄到，只有你自己最清楚。