内容来源：X 社区长文。https://x.com/trq212/status/2033949937936085378
作者：@trq212
原发布时间：2026-03-17

Claude Code Skills source cover

Claude Code Skills：把重复任务沉淀成团队能力

Claude Code 的扩展能力里，Skills 是最适合团队长期沉淀的一类。它不像一次性的提示词，也不只是某个命令别名；一个 Skill 可以包含说明文档、脚本、模板、示例、配置文件、静态资源，甚至配合 Hook 在特定任务期间改变 Claude 的行为。

可以把 Skill 理解成一份“给智能体使用的任务包”：它告诉 Claude 在某类任务里应该读什么、调用什么、避开什么坑、按什么格式交付结果。

这也是 Skills 容易被低估的地方。很多人以为它只是一个 Markdown 文件，但真正有价值的 Skill 往往是一个目录结构，里面放着 Claude 可以渐进读取和组合使用的材料。

什么时候值得做一个 Skill

不是所有知识都应该做成 Skill。判断标准很简单：这件事是否重复发生，并且每次都需要相同的上下文、脚本或验收方式。

如果只是偶尔一次的需求，写在当前会话里就够了。如果一个团队反复让 Claude 做相似任务，就适合沉淀成 Skill。

典型场景包括：

  • Claude 经常误用某个内部 SDK；
  • 每次做页面改版都要重新解释设计规范；
  • 每次上线都要跑固定检查；
  • 每次排障都要查同样几类日志；
  • 每次写 PR Review 都要遵守同样标准；
  • 每次生成业务报表都要连接同样的数据表。

这些都不是“提示词技巧”，而是团队流程资产。Skill 的价值在于把个人经验变成团队可复用能力。

9 类最常见的 Skills

原文把 Skills 大致归纳成 9 类。这个分类很适合内容团队和工程团队一起盘点：我们已经有哪些重复任务，可以先做成能力包？

1. 库、API 与 CLI 使用说明

这类 Skill 负责告诉 Claude 如何正确使用某个库、内部 CLI、SDK 或平台能力。

它不应该解释通用概念，而应该写项目里的特殊规则：

  • 内部 billing 库有哪些边界条件；
  • 平台 CLI 哪些子命令应该在什么场景使用；
  • 某个 SDK 常见错误参数是什么；
  • 哪些 API 看起来能用但已经废弃。

最有价值的部分通常是 gotchas：Claude 容易踩哪些坑，以及如何避开。

2. 产品验证

验证类 Skill 用来告诉 Claude 怎么确认自己真的做对了。它可以配合 Playwright、tmux、截图、测试脚本或状态断言。

比如一个注册流程验证 Skill，可以让 Claude：

  • 打开浏览器；
  • 走完注册、邮件验证、引导页；
  • 在每一步检查页面状态；
  • 记录截图或视频；
  • 最后输出验证结果。

这类 Skill 对 Claude Code 很关键。因为它把“我觉得写完了”变成“我运行了验证，并且证据通过了”。

3. 数据获取与分析

这类 Skill 让 Claude 能正确读取团队的数据、监控和分析系统。

它可以包含：

  • 数据源 ID；
  • 常用 SQL 模板；
  • 事件表之间的 join 关系；
  • 指标口径；
  • Grafana dashboard 对照表；
  • 常见问题和对应查询路径。

如果团队经常让 Claude 分析漏斗、留存、转化、告警趋势，这类 Skill 会比每次复制粘贴仪表盘链接稳定得多。

4. 业务流程和团队自动化

这类 Skill 适合把日常协作动作自动化，例如：

  • 汇总 standup；
  • 创建工单；
  • 生成周报；
  • 整理 PR、ticket、部署记录；
  • 把结果发到 Slack 或飞书。

它通常不需要复杂推理，但需要格式稳定、字段正确、流程可追踪。对于这类 Skill，保存历史执行结果很有帮助。Claude 下次运行时可以读取上次结果，只输出变化部分。

5. 代码脚手架和模板

如果团队创建新服务、新任务、新迁移、新页面时有固定结构，可以把模板放进 Skill。

这类 Skill 不只是“复制模板”，还可以处理自然语言要求。例如用户说“新增一个支付回调 handler”，Skill 可以让 Claude 读取模板、填入项目约定、补测试、补日志，并避开团队常见错误。

6. 代码质量和 Review

代码质量类 Skill 可以用于：

  • 代码风格检查；
  • 测试实践；
  • 安全审查；
  • 架构一致性；
  • 反向审查，也就是让一个新上下文的子智能体专门挑问题。

这类 Skill 最好配合确定性工具。能用 linter、测试、类型检查、静态扫描解决的，不要只靠自然语言要求。

7. CI/CD 和部署

部署类 Skill 可以帮助 Claude 跑构建、看 CI、处理冲突、开 PR、灰度发布、观察错误率、触发回滚。

这类 Skill 需要特别谨慎，因为它可能涉及生产环境。建议把破坏性动作拆出来，要求人工确认，并用 Hook 阻止高风险命令。

8. Runbook

Runbook Skill 用来处理告警、错误签名、线上异常或 Slack 讨论串。

一个好的 Runbook Skill 不只是“查日志”，而是把排查路径写清楚：

  • 先看哪个系统；
  • 根据什么字段关联；
  • 哪些现象代表已知问题；
  • 哪些指标能证明影响范围；
  • 最终报告应该包含什么。

它适合值班、客服升级、线上事故复盘等场景。

9. 基础设施运维

基础设施类 Skill 可以处理孤儿资源清理、依赖升级、成本异常调查、容量检查等任务。

这类 Skill 往往有破坏性操作，所以必须有护栏：

  • 默认只读；
  • 先生成计划；
  • 明确列出影响范围；
  • 等待人工确认；
  • 执行后保留日志。

写 Skill 的几个关键原则

Claude Code Skills tips source image

不要写 Claude 本来就知道的内容

Skill 的空间应该留给高信号信息。不要告诉 Claude “React 组件是什么”“测试很重要”这类通用知识。它真正需要的是：

  • 这个团队为什么不用某个常见方案；
  • 这个项目哪里和开源默认实践不同；
  • 这个库有哪些反直觉行为；
  • 这个流程里哪一步最容易失败。

越具体，越有价值。

一定要有 Gotchas

Gotchas 往往是一个 Skill 最重要的部分。它应该来自真实失败记录：Claude 以前犯过什么错，人类反复纠正过什么，线上出现过什么事故。

一个 Skill 可以从很小开始，哪怕只有三条 Gotchas。后续每次 Claude 踩新坑，就把它补进去。这样 Skill 会随着团队使用逐步变强。

用目录结构做渐进披露

Skill 不应该把所有内容塞进一个超长文件。更好的结构是：

my-skill/
  SKILL.md
  references/
    api.md
    gotchas.md
  scripts/
    check.js
    fetch-data.ts
  assets/
    report-template.md
  examples/
    good-output.md

SKILL.md 只写入口说明和触发场景，详细 API、模板、脚本、示例放到子目录。Claude 需要时再读取，这就是一种上下文工程。

不要把 Claude 绑得太死

Skill 是可复用资产，不能写成只适合某一个固定任务的剧本。它应该给 Claude 足够约束，也保留根据任务调整的空间。

例如不要写“永远按这 12 步执行”。更好的方式是写：

  • 先判断任务属于哪种场景；
  • 如果涉及生产数据，先走只读检查；
  • 如果只是本地代码生成，可以直接使用模板；
  • 如果缺少配置，先向用户确认。

需要配置的 Skill 要设计初始化流程

有些 Skill 需要用户配置，例如 Slack 频道、默认仓库、数据源、环境名。可以在 Skill 目录里放一个 config.json。当配置不存在时，让 Claude 先询问用户，而不是猜。

这样可以避免 Skill 在不同团队、不同项目中硬编码环境信息。

描述字段是给模型看的

Skill 的 description 不是写给人类浏览的摘要，而是 Claude 判断“该不该触发这个 Skill”的依据。

所以 description 要写清楚触发条件，例如：

当用户要求排查注册转化、漏斗下降、激活率异常或 signup 相关指标时使用。

这比“注册分析 Skill”更容易被 Claude 正确调用。

可以存储记忆，但要放在稳定位置

有些 Skill 需要历史记录，比如 standup、周报、报表、排障结论。可以让它写日志、JSON 或 SQLite。

但要注意，Skill 本身升级时目录可能变化。持久化数据最好放在稳定的数据目录，而不是塞在会被覆盖的 Skill 目录里。

给 Claude 脚本，而不是只给说明

如果某个动作可以用脚本稳定完成，就把脚本放进 Skill。Claude 擅长组合工具，但不应该每次重新发明底层样板代码。

例如数据分析 Skill 可以提供 fetchEvents()、queryFunnel()、compareCohorts() 这类函数。Claude 只需要根据用户问题临时生成组合脚本，而不是每次从零写查询逻辑。

按需启用 Hooks

有些 Hook 不适合全局开启，但非常适合在某个 Skill 被调用时临时启用。

例如生产排障时，可以启用一个保守 Hook，阻止 rm -rf、DROP TABLE、强推、删除 Kubernetes 资源等命令。平时一直开可能影响效率，但在高风险任务里非常有价值。

团队如何分发 Skills

小团队可以把 Skills 放进仓库，例如 ./.claude/skills，让所有使用这个仓库的人自动受益。

团队规模变大后，更适合做内部 Skill 或 Plugin 市场：

  • 个人先在试验区提交 Skill；
  • 让同事试用；
  • 有真实使用量后再进入正式市场；
  • 定期清理重复、过时、低质量 Skill。

Skills 越多，不代表系统越强。缺少治理时，低质量 Skill 会污染上下文，也会让 Claude 触发错误能力。

如何衡量一个 Skill 是否有用

可以从三个角度看：

  • 是否被正确触发；
  • 是否减少了人类重复解释；
  • 是否让任务结果更稳定。

原文提到一种做法：通过 PreToolUse Hook 记录 Skill 使用情况，从而发现哪些 Skill 很受欢迎，哪些 Skill 明明应该触发却没有触发。

对内容平台或研发团队来说，也可以用更轻量的方式：记录每个 Skill 的使用次数、失败案例和人工修订次数。

小结

Claude Code Skills 最适合解决一个问题：把团队里反复出现的隐性经验，变成 Claude 可以主动发现和调用的能力包。

一开始不用追求完整。一个好 Skill 可以从几条规则、一个 Gotchas 文件、一个模板或一个检查脚本开始。真正重要的是持续迭代：每次 Claude 犯错，都把这个错误沉淀进 Skill；每次人工重复解释，都把解释变成可复用上下文。

当团队里的 Skills 足够成熟，Claude Code 就不再只是个人效率工具，而会变成团队工程流程的一部分。