大家好，我是顾北！

今天在刷 X 的时候突然看到 Anthropic Claude Code 团队的 Thariq 发了一篇很有料的总结文。

他们在内部已经跑了数百个 Skills，踩了不少坑，也摸索出了一套行之有效的方法论。

我读完之后觉得信息密度很高，拆开来讲一讲。如果你已经在用 Claude Code，或者打算深入用，这篇值得认真看。

---

先澄清一个误解：Skills 不是 Markdown 文件

很多人（包括我一开始）把 Skills 理解成「保存好的提示词」——写个 SKILL.md，放进去，完事儿。

但 Thariq 在文章里特别强调了这一点：

Skills 的本质是文件夹，不是单个文本文件。

一个完整的 Skill 文件夹可以包含：

my-skill/
├── SKILL.md          # 主指令文件
├── scripts/          # 可执行脚本（Python/Bash）
├── assets/           # 模板、数据、参考文件
└── references/       # 代码示例、API 文档片段

Claude 可以发现、探索并操作这个文件夹里的所有内容。

更强的是，Claude Code 的 Skills 支持注册动态 hooks——也就是说，你可以让 Skill 在特定事件触发时自动执行操作。

这一点把 Skills 从「高级提示词」变成了真正意义上的「可执行工作流」。

---

Anthropic 内部的 9 种 Skills 类型

他们把内部几百个 Skills 做了一次系统梳理，发现大多数都能归入以下 9 类。这个分类框架本身就很有价值——如果你的团队里某类 Skills 明显空缺，那就是改进空间。

1. 📚 Library & API Reference（库和 API 参考）

用途：教 Claude 正确使用某个库、CLI 或 SDK。

不只是贴文档，而是包含真正有用的东西：一个装满参考代码片段的文件夹，加上一份「踩坑清单」——告诉 Claude 写这个库时最容易犯哪些错。

示例：

• billing-lib — 内部计费库的边界情况和 footgun 列表

• internal-platform-cli — 内部 CLI 全部子命令 + 使用场景示例

• frontend-design — 让 Claude 的输出对齐你们的设计系统

对于任何有内部库的团队，这类 Skill 的投入产出比极高。

2. ✅ Product Verification（产品验证）

用途：描述如何测试和验证代码是否正常工作。

这类 Skill 通常和 Playwright、tmux 等工具配合使用。

Thariq 的原话很有意思：

验证类 Skill 直接影响 Claude 输出的质量。让一个工程师花整整一周专门打磨你的验证 Skill，这个投入是值得的。

两个具体技巧：

• 让 Claude 录制输出的视频，这样你能直接看到它测试了什么

• 在流程的每一步强制插入断言，验证状态是否正确

示例：

• signup-flow-driver — 用无头浏览器跑完注册 → 邮件验证 → 引导全流程，每步做状态断言

• checkout-verifier — 用 Stripe 测试卡驱动结账 UI，验证发票最终状态是否正确

• tmux-cli-driver — 专门用于需要 TTY 的交互式 CLI 测试

3. 📊 Data Fetching & Analysis（数据获取与分析）

用途：连接你的数据和监控体系。

这类 Skill 通常包含：带凭证的数据获取库、仪表盘 ID、常见数据分析工作流的步骤说明。

示例：

• funnel-query — 「哪几张表 join 在一起能看到注册→激活→付费漏斗」

• cohort-compare — 对比两个用户群的留存或转化，标记统计显著的差异

• grafana — 数据源 UID、集群名称、「出现这个问题查哪个看板」的查询表

4. 🤖 Business Process & Team Automation（业务流程与团队自动化）

用途：把重复性工作流压缩成一句命令。

这类 Skill 的指令通常比较简单，但依赖关系会更复杂（可能会调用其他 Skill 或 MCP）。

一个关键技巧：把历史执行结果保存成日志文件，让模型在下次执行时能回顾之前的输出，保持一致性。

示例：

• standup-post — 汇总 ticket tracker + GitHub 活动 + 昨天的 Slack，生成格式化站会消息，只输出变化的部分

• create-ticket — 强制执行 ticket schema（合法枚举值、必填字段），并自动完成创建后的工作流（ping 审核人、发 Slack 链接）

• weekly-recap — 合并 PR + 关闭的 tickets + 部署记录 → 格式化周报

5. 🏗️ Code Scaffolding & Templates（代码脚手架与模板）

用途：为代码库中特定功能生成框架样板。

在你的脚手架有自然语言描述的时候尤其好用——你只需说「给这个模块生成标准结构」，Claude 就能按照团队规范来。

可以配合脚本组合使用，把模板生成和后续的文件操作打包在一起。

6. 🛠️ Environment Setup（环境配置）

用途：帮助开发者（或 Claude）快速把开发环境跑起来。

对于新成员上手或者在新机器上恢复开发环境特别有用，把那些「README 里写了但总有人漏掉某一步」的配置流程固化下来。

7. 🔍 Debugging（调试）

用途：系统化的调试流程。

好的调试 Skill 包含完整的步骤：复现 → 隔离 → 定位根因 → 建议修复方案，避免 Claude 上来就乱改代码。

8. 👀 Code Review（代码审查）

用途：对变更进行多维度审查。

可以覆盖：安全漏洞、性能问题、错误处理、类型安全、代码规范、边界情况。

把团队的代码审查标准写进 Skill，确保每次都能对齐最高标准，不会因为审核人不同而漏掉某类问题。

9. 🔗 Workflow Orchestration（工作流编排）

用途：将多个 Skills 组合成复杂的多步骤任务流。

这是最高阶的玩法——把前面几类 Skill 像积木一样拼起来，处理涉及多个系统的复杂任务。

写好 Skill 的几条核心原则

从 Thariq 的总结里提炼出来的实操建议：

1. 最好的 Skill 只属于一个清晰的类别

上面列了 9 类，好的 Skill 应该干净地落在其中一类里。如果你发现一个 Skill 横跨好几类，它大概率是在尝试做太多事——拆开会更好用。

• 验证类 Skill 值得重点投入

在所有类型里，验证类 Skill 对整体质量的影响最大，也最值得专门花时间打磨。不要让它成为一个草草了事的检查清单。

• 用日志保存历史执行结果

对于业务流程类 Skill，让 Claude 把每次执行的结果写入日志文件。下次运行时，它能参考之前的输出，保持输出格式和内容的一致性。

• 充分利用 hooks 和文件夹结构

不要只用 SKILL.md 一个文件。Anthropic 内部最有趣的 Skills，都是那些创造性地使用了配置项和文件夹结构的——动态 hooks、脚本、资产文件一起上。

---

如何在团队里推广 Skills

单人用 Skills 提效是一回事，团队共享才是真正的乘法效应。

步骤很简单：

1. 先在本地验证有效性 — 自己用几天，确认它真的好用再推给别人

2. 通过 Git 共享 — 把 Skills 纳入代码库版本管理，和代码一起演进

3. 团队共同维护 — 多人使用、多人优化，Skills 的质量会快速提升

最后一点尤其重要。当团队里每个人都在用同一套 Skills，他们发现的问题、提出的改进都能沉淀下来，形成一套越来越强的「团队集体经验」。

---

我的看法

看完这篇总结，最让我印象深刻的不是某一个具体技巧，而是 Anthropic 内部对 Skills 的整体认知：Skills 是把人类的专业知识转化为 AI 可以调用的结构化资产。

9 种分类本质上是 9 种「知识形态」——有操作手册、有测试规范、有数据路径、有流程自动化。当你把这些一个个建起来，你不是在「教 AI 用工具」，你是在把团队的隐性经验系统化。

这件事的价值，我觉得还没有被充分讨论。

你们团队现在在用 Skills 吗？哪一类是你觉得最有价值的？欢迎评论区聊聊。

我是顾北，我们下期再见！

---

版权声明

本文内容整理自 Thariq Shihipar（@trq212）发布的原创推文及博客文章：

• 原文标题：Lessons from Building Claude Code: How We Use Skills

• 原文作者：Thariq Shihipar，Anthropic Claude Code 团队

• 原文链接：https://x.com/trq212/status/2033949937936085378

• 作者主页：https://x.com/trq212

本文为原文内容的中文翻译整理与二次创作，仅供学习交流，著作权归原作者所有。如有侵权，请联系删除。