Anthropic 内部，有数百个 Skills 每天在运行。
这个数字，第一次出现在公开渠道里，是 Anthropic 的 Thariq Shihipar（DevRel）在最近一篇长文里披露的。他的身份不是普通的布道者，而是深度参与 Claude Code 推广和实践的 Anthropic 内部人员——他讲的不是“你应该怎么用”，而是“我们自己就是这么用的”。
这个数字震撼我的，不是它的量级，而是它背后的含义：Skills 在 Anthropic 内部，已经不是 Claude Code 的一个功能，而是工程团队的核心基础设施。 他们用自己的工具，验证了一套外部开发者还没看懂的范式，并且跑出了数百个活跃案例。
而绝大多数正在用 Claude Code 的开发者，还把 Skills 当成“存 Prompt 的地方”——写几行 Markdown，告诉 Claude 你是谁、做什么风格的代码。把瑞士军刀当开瓶器在用，没出错，但你只用了一个功能。
这就是认知差距的起点，也是这篇文章想打破的东西。
Thariq 的这篇文章，是 Anthropic 内部 Skills 实践的第一次系统性公开。他们到底是怎么用的？这套范式，会怎样重新定义工程团队的竞争力？
一、先破除最大的误解
Thariq 在文章开头就点名了：“Skills 是一个常见的误解，大家以为它们只是 Markdown 文件。”
这个误解的代价是巨大的。
Skills 本质上是一个文件夹，不是一个文件。 这个文件夹里可以有脚本、静态资源、数据文件、配置文件、代码库……代理可以发现、读取、调用、操作这里面的一切。更关键的是，Skills 还可以注册动态 Hook——在特定的工具调用时机触发特定行为。
这意味着什么？
意味着 Skills 不只是“给 Claude 的知识”，而是给 Claude 的工具、给 Claude 的记忆、给 Claude 的行为约束体系。把它理解成 Markdown，就像把瑞士军刀当成开瓶器在用——没出错，但你只用了一个功能。
二、Anthropic 内部把 Skills 分成了 9 类
在整理了内部数百个 Skills 之后，Thariq 发现它们自然聚类成 9 种类型。这份分类清单非常值得每个开发团队对照着检查一遍——因为你很可能少做了几类。
- 库与工具使用（Library / CLI / SDK Skills）
帮助 Claude 正确使用特定库、CLI 或 SDK。不是官方文档的复制，而是你们内部使用该工具时踩过的坑、正确的调用模式、危险操作的警示。
示例：billing-lib（内部计费库的边界情况与陷阱）、frontend-design（你们的设计系统风格指南，让 Claude 写出符合 UI 规范的代码）
- 验证技能（Verification Skills）
告诉 Claude 如何验证代码是否正确运行。通常配合 Playwright、tmux 等外部工具。
Thariq 说了一句很重的话：“花一周时间专门打磨你的验证 Skills，是值得的。” 考虑在 Skill 里内置录像功能，让 Claude 自己录下操作过程；或者在每一步强制做程序化的断言。验证 Skills 的质量，直接决定了 Claude 输出的可信度上限。
示例：signup-flow-driver（完整走完注册→邮件验证→引导流程，带状态断言）、checkout-verifier（Stripe 测试卡驱动结账 UI 验证）
- 数据访问（Data Access Skills）
连接你的数据仓库和监控系统。包括获取数据的脚本、凭据配置、常用查询模式、看哪个 Dashboard 看什么问题。
示例：funnel-query（哪些事件表 JOIN 在一起能看到从注册到激活到付费的完整漏斗）、grafana（数据源 UID、集群名、问题→仪表盘的对照表）
- 工作流自动化（Workflow Automation Skills）
把重复性工作流封装成一条命令。可以保存历史运行记录，让 Claude 在下次执行时参考上次的结果，保持一致性。
示例：standup-post（聚合 Jira、GitHub、Slack → 生成站会更新，只展示 delta 变化）、weekly-recap（合并 PR + 关闭 Ticket + 部署记录 → 格式化周报）
- 脚手架生成（Scaffolding Skills）
生成框架样板代码，专门用于你们代码库的特定模块类型。在纯代码无法覆盖的地方，用自然语言描述约束条件。
示例：new-migration（你们的迁移文件模板 + 常见陷阱）、create-app（预置鉴权、日志、部署配置的新应用脚手架）
- 代码质量（Code Quality Skills）
执行你们团队的代码规范，也可以做代码审查。可以包含确定性脚本，增加鲁棒性。配合 Hook 在代码提交时自动触发。
示例：adversarial-review（启动一个独立子 Agent 扮演挑剔的审查者，反复迭代直到问题降级为小改动）、code-style（强制执行 Claude 默认风格下不擅长的那些规范）
- DevOps 操作（DevOps Skills）
拉取、推送、部署代码，可以引用其他 Skills 来收集数据。
示例：deploy-（构建→冒烟测试→渐进式流量切换→与错误率对比→超阈值自动回滚）、babysit-pr（监控 PR → 重试 Flaky CI → 解决合并冲突 → 开启自动合并）
- 调试与运维（Debug &； Ops Skills）
给定一个症状（Slack 线程、告警、报错特征），自动走完多工具调查流程，产出结构化的排查报告。
示例：oncall-runner（拉取告警 → 检查常见嫌疑 → 格式化发现结论）、log-correlator（给定 Request ID，从所有可能处理过它的系统拉对应日志）
- 维护与运维（Maintenance &； Ops Skills）
执行例行维护和运维操作——其中有些是破坏性操作，需要内置安全护栏。这类 Skills 的价值在于：把高风险操作规范化，让工程师在执行关键操作时有明确的最佳实践可循，而不是全靠个人经验和胆量。
示例：<；resource>；-orphans（查找孤立的 Pod/Volume → 发到 Slack → 等待确认期 → 用户确认 → 级联清理）、cost-investigation（「为什么我们的存储/出口账单暴涨」，带具体的桶名和查询模式）
对照这份清单，你们团队现在有哪几类？我猜大多数团队只有第一类。
三、让 Skills 真正强大的 8 个核心原则
有了分类框架，下一步是怎么写好一个 Skill。Thariq 给出了 7 条经验，每一条背后都是内部踩坑踩出来的。
原则一：只写 Claude 不知道的东西
Claude 本身已经非常了解代码，也有很多默认观点。如果你的 Skill 是通用知识，它基本上已经内化了。真正有价值的 Skill，是把 Claude 从它的“默认路径”推出去，引导它进入你们的特定路径。
frontend-design 这个 Skill 就是典型：一个 Anthropic 工程师通过跟客户迭代，专门打磨了 Claude 对 UI 设计的品味——避开经典的 Inter 字体和紫色渐变，让它符合更有质感的设计标准。
原则二：Gotchas 是 Skill 里含金量最高的部分
每个 Skill 都应该有一个“踩坑记录”章节。这里记录的是 Claude 在使用这个 Skill 时反复触发的失败模式。每次 Claude 踩了新坑，就更新进去。
这个章节不是文档，它是你们团队与 AI 协作经验的活体积累。
原则三：把 Skill 当文件系统工程来做
Skills 是文件夹。充分利用文件结构做“渐进式上下文披露”——告诉 Claude 里面有哪些文件，它会在合适的时机按需读取，而不是一次性把所有内容塞进上下文。
references/api.md 放详细 API 文档；assets/ 放模板文件；scripts/ 放可执行脚本。Claude 自己会决定什么时候读哪个文件。
原则四：给 Claude 自由度，不要过度指令化
Skills 会被反复复用。如果指令太刚性，Claude 在不同情境下都会用同一种方式处理，效果会很差。给它足够的信息，也给它足够的灵活性去适应每次不同的上下文。
原则五：用 Config 文件做动态初始化
有些 Skill 需要用户在第一次运行时提供配置信息（比如 Slack 频道）。把这些配置存在 config.json，如果文件不存在，Claude 会自动引导用户填写。这是一个非常干净的交互模式。
原则六：Skill 的 Description 是触发器，不是摘要
Claude Code 启动时会扫描所有 Skill 的 Description 字段，决定什么请求该用哪个 Skill。所以 Description 不是用来给人看的介绍，而是用来告诉 Claude“在什么情况下触发我”。这个字段的措辞直接决定了 Skill 的触发率。
原则七：给 Skill 配记忆，让它越用越聪明
Skill 可以用文件存储历史状态——追加日志、JSON 文件，甚至 SQLite 数据库。standup-post 保存历史 standup 记录，让 Claude 下次运行时自动对比变化，只输出 delta。这种“记忆”把一次性工具变成了真正的长期助手。
原则八：给 Claude 配脚本，让它把精力花在决策上
这是最容易被忽视、也最有技术深度的一条。Claude 很擅长组合和推理，不擅长的是从零重建样板代码。在 Skill 里预置好脚本和 helper 函数库，Claude 就能把每一个 Token 花在“做什么”而不是“怎么取数”上。
举个具体例子：你的数据分析 Skill 里预置了一套从事件数据源取数的 helper 函数。当你问 Claude「上周二发生了什么」，它不需要重新写取数逻辑，直接调用 helper 组合出分析脚本，把精力全放在解读数据上。这个差距，用了才知道有多大。
好的 Skill，是你们团队与 AI 协作经验的活体积累——写进去的每一条 Gotcha、每一个脚本，都在持续放大 Claude 的实际能力上限。
四、Skills 正在重塑工程团队的协作方式
到这里，大多数文章会就此结束——介绍完了，收工。但我觉得最重要的一层还没说到。
Skills 不只是工程效率工具，它正在改变团队的知识流动方式。这个变化的意义，比你想象的深得多。
想象一下过去的情况：一个高级工程师花了两周搞清楚了内部计费库的所有陷阱。这些知识存在哪里？存在他的脑子里，或者一个没人维护的 Confluence 页面里。下一个接手的工程师，大概率要重新踩一遍同样的坑。知识在人与人之间传递，但传递效率极低，而且每次传递都有损耗。
现在呢？他把这些知识写进 billing-lib Skill，推到团队的内部插件市场。每个用 Claude Code 的工程师，都自动获得了他两周积累的经验，并且每次踩新坑都会迭代进去。Anthropic 内部没有一个集中的团队来维护所有 Skills，而是由各个工程师自己上传、分发、迭代。当一个 Skill 在 Slack 里获得了足够的关注和使用，它就会被 PR 进正式的 Marketplace。
经验，第一次有了可以复用的载体。
这句话的含义，在个人和组织两个层面都值得细想。
个人层面：会不会系统性地建设 Skills 库，正在成为工程师的新能力分水岭。不是“加分项”，而是“基础门槛”。就像十年前，在很多团队中，会不会用 Git、会不会写单元测试，曾经是区分工程师水平的标志——今天，会不会把自己的经验沉淀成高质量的 Skills，会成为下一个分水岭。一个把踩坑经验系统化进 Skills 的工程师，和一个把经验装在脑子里的工程师，在 AI 协作效率上的差距会越来越大。
组织层面：Skills 库的质量，正在成为工程团队的隐性资产。两个规模相同的团队，一个有 200 个高质量 Skills，一个只有 10 个——在我看来，他们的 AI 协作效率差距，不是 2 倍，可能是 10 倍。更关键的是，这种差距是复利式的，而且是不可见的。高质量 Skills 库会吸引更多工程师贡献新 Skills，新 Skills 又进一步放大团队效率，形成飞轮。而旁观者什么都看不到——他们看到的只是“这个团队的 AI 用得特别好”，却不知道背后跑着多少隐形的基础设施。
这就是 Thariq 说的“插件市场”背后真正的价值逻辑：它不是工具的分发，而是组织智慧的结晶与传承。 好的 Skills 库，是一个团队与 AI 协作经验的活体积累——它会生长，会迭代，会在每次踩坑之后变得更强。
那些在今天开始系统性建设 Skills 库的团队，正在积累一种别人追不上的先发优势。而那些依然把 Skills 当成“偶尔用用的 Prompt 存档”的团队，差距正在以你看不见的速度拉开。
结语：你们团队的 Skills 库，今天有几个？
Thariq 在文章末尾说了一句很诚实的话：“我们还都在摸索怎么用好 Skills，这更像是一把有用的技巧，而不是最终答案。”
这种坦诚，反而更有说服力。
Skills 不是魔法，也没有标准答案。但有一点已经被 Anthropic 内部实践验证：当你把工程经验系统性地沉淀进 Skills，它就不再只是你一个人的资产，而是整个团队的基础设施。 这是工程知识第一次有了可以复利增长的载体。
这不是程序员的威胁，而是工程团队的新机遇。第一次，你们踩过的坑、趟过的路、积累的判断力，可以被系统性地编码、分发、传承——不再依赖老手带新手，不再依赖文档被动等人来读，而是直接嵌入每一次 AI 协作的过程里。
从今天开始，建议每个使用 Claude Code 的团队做一件事：对照上面的 9 类 Skills，检查你们缺了哪几类，从最痛的那个地方开始补。
会用 Skills 的工程师和团队，与不会用的，正在快速分化。
你们团队的 Skills 库，今天有几个？
参考来源：
Thariq Shihipar， “Lessons from Building Claude Code： How We Use Skills”， X (Twitter)， 2026
