上一篇我们讲了 Skills 的基础用法：它是什么、放在哪里、怎么创建第一个 Skill，以及一个好 Skill 应该怎么写。

如果说上篇解决的是我怎么写一个 Skill，那么这一篇要解决的是另一个更现实的问题：我怎么把 Skills 用稳、用大，甚至用到整个团队里？

因为真正用起来以后，你很快会遇到这些问题：这个规则应该放 CLAUDE.md，还是写成 Skill？一个复杂 Skill 太长了怎么办？能不能限制 Claude 只读文件，不要乱改？写好的 Skill 怎么让团队一起用？为什么我的 Skill 明明写了，却没有触发？

这些问题，比创建第一个 Skill更接近真实工作。所以下篇，我们主要讲 Skills 的进阶用法和团队化实践。

什么时候不该用 Skills？

很多人学完 Skills 后，会有一种冲动：什么都想写成 Skill。

这是很危险的。

Claude Code 里有很多定制能力，比如 CLAUDE.md、Skills、Subagents、Hooks、MCP。它们不是谁替代谁，而是各自负责不同事情。

可以简单记住这句话：CLAUDE.md 管长期规则，Skills 管专业经验，Subagents 管独立任务，Hooks 管自动流程，MCP 管外部工具。 

如果你把所有东西都塞进 Skills，最后一定会乱。

CLAUDE.md 和 Skills：一个管始终如此，一个管需要时再说

上篇已经简单对比过 CLAUDE.md 和 Skills，这里我们只讲实际判断。

凡是 Claude 每次都必须知道的内容，放 CLAUDE.md。比如：

CODE
项目使用 Next.js
统一使用 TypeScript
不要修改数据库 Schema
不要随便新增依赖
提交前必须先跑测试

这些是项目底线，无论你让 Claude 写代码、改 Bug、写文档，它都应该遵守。

但如果是某个特定任务才需要的详细流程，就更适合 Skills。比如：

CODE
PR Review 的检查清单
Commit Message 的格式
技术方案评审模板
性能排查流程
品牌文案规范

这些东西不需要每次都加载。你写代码的时候，不需要 PR Review 模板一直占着上下文。你调 Bug 的时候，也不需要品牌文案规范一直在旁边待着。

所以判断标准很简单：每次都要遵守，放 CLAUDE.md；偶尔才会用到，放 Skills。

这也是很多人优化 Claude Code 体验的第一步，把 CLAUDE.md 里那些又长又细、但不是每次都需要的内容，拆成 Skills。

Skills 和 Subagents：一个是技能，一个是分身

Skills 和 Subagents 也很容易混，但它们的区别其实特别清楚。

Skills 是给当前 Claude 增加一套专业知识。Subagents 是让 Claude 派一个独立角色出去干活。

举个例子。你说：帮我按照团队标准 Review 这次改动。这时候适合用 Skill，因为你只是希望 Claude 按照某套标准完成当前任务。但如果你说：帮我先分析整个项目结构，再找出可能影响这个需求的模块。这时候更适合 Subagent。 因为它可能需要大量搜索、阅读、总结。如果都放在主会话里，会占用很多上下文，也容易干扰你后续真正要做的事情。

一句话区分：Skills 是把经验带进当前对话；Subagents 是把任务丢到另一个上下文。

一个容易踩坑的点：Subagents 不会自动继承 Skills

很多人会以为： 我已经在项目里写了 Skills，那 Subagent 应该也能自动用吧？

不一定。

Subagent 是一个相对独立的执行上下文，尤其是自定义 Subagent，如果你希望它使用某些 Skills，需要在 agent 配置里显式声明。例如：

CODE
---
name: frontend-reviewer
description: Review frontend code for accessibility, performance and maintainability.
tools: Bash, Glob, Grep, Read, Skill
model: sonnet
skills: accessibility-audit, performance-check
---

这里的重点是： 

CODE
skills: accessibility-audit, performance-check

也就是说，你不是只创建 Skill 就完事了。如果你希望某个自定义 Subagent 拥有这些能力，需要把它们写进这个 Subagent 的配置里。

这个组合很适合团队使用，比如你可以有：

CODE
frontend-reviewer
  + accessibility-audit
  + performance-check

backend-reviewer
  + api-security-review
  + database-risk-check

docs-reviewer
  + brand-tone-check
  + technical-writing-check

这时候，Subagent 不只是一个分身，而是一个带着特定技能的专家角色。

Skills 和 Hooks：一个靠请求触发，一个靠事件触发

Skills 是你提出需求后触发。比如：

CODE
帮我检查这段代码的性能问题。

Claude 判断这个请求和某个 Skill 匹配，于是加载 Skill。

Hooks 不一样，Hooks 是事件触发。比如：

CODE
Claude 每次保存文件后，自动运行 lint
Claude 每次修改代码后，自动执行测试
Claude 每次调用某个工具前，先做权限检查

你甚至不需要主动说，事件发生了，Hooks 就执行。

所以两者不要混用。如果你要的是让 Claude 按某套经验思考，用 Skills。如果你要的是每次发生某个动作后自动执行检查，用 Hooks。

一个管脑子，一个管流程。

Skills 和 MCP：一个提供方法，一个提供工具

MCP 更不是 Skills 的高级版。

Skills 解决的是：Claude 应该怎么做？MCP 解决的是：Claude 可以连接什么？

例如你让 Claude 根据 GitHub Issue 写开发计划，这里可能会同时用到两种能力：MCP 负责连接 GitHub，读取 Issue。Skill 负责告诉 Claude，开发计划应该按照什么格式写、要包含哪些风险、怎么拆任务。

所以 MCP 是工具箱，Skills 是方法论。 

两者可以组合，但不是同一类东西。

复杂 Skill 不要写成大杂烩

上篇我们讲过，一个 Skill 只解决一个问题。

但实际工作里，有些 Skill 确实会变复杂。比如性能排查 Skill，它可能包括：

CODE
排查步骤
常见原因
框架差异
命令脚本
历史案例
输出模板

如果你全部塞进一个 SKILL.md，最后这个文件可能变成几千行。这会带来两个问题：第一，占上下文。第二，自己也维护不下去。

更好的方式是使用多文件结构，例如：

CODE
performance-debug/
├── SKILL.md
├── references/
│   ├── react-performance.md
│   ├── node-performance.md
│   └── database-performance.md
├── scripts/
│   └── check-bundle-size.sh
└── templates/
      └── report-template.md

SKILL.md 只写最核心的内容：

CODE
你什么时候应该使用这个 Skill
你应该先做什么
什么时候读取 references
什么时候执行 scripts
最终输出格式是什么

详细资料不要一股脑塞进去。

需要 React 性能排查时，再读取 react-performance.md；需要检查包体积时，再执行 check-bundle-size.sh。

这就是 Skills 里很重要的思想：主文件保持克制，细节按需加载。

官方有一个很实用的建议：SKILL.md 尽量不要超过 500 行。

这不是硬性规定，但非常值得遵守。因为 SKILL.md 一旦被加载，就会进入上下文。如果你把所有案例、参考资料、脚本说明都塞进去，本质上又回到了上下文被垃圾信息占满的老问题。

比较好的写法是：

CODE
# Instructions
你负责进行前端性能排查。
## 工作流程
1. 先确认用户的问题属于加载慢、交互卡顿还是构建体积过大
2. 如果是 React 渲染问题，读取 references/react-performance.md
3. 如果是包体积问题，运行 scripts/check-bundle-size.sh
4. 最后按照 templates/report-template.md 输出结果

注意这里的关键：不是把所有资料都写进来，而是告诉 Claude 什么时候去看什么资料。

这才是多文件 Skills 的正确写法。

脚本不要让 Claude 读，要让 Claude 跑

Skills 里可以放 scripts，这很有价值。因为有些事情让 Claude 临时写，不如直接运行一个稳定脚本。比如：

CODE
检查环境
统计代码行数
分析 bundle size
生成目录结构
批量转换数据

但这里有一个小技巧——你应该在 SKILL.md 里告诉 Claude：

CODE
运行 scripts/check-bundle-size.sh

而不是： 

CODE
读取 scripts/check-bundle-size.sh 并理解它

区别很大。

读取脚本，会占上下文，运行脚本，只会把结果返回给 Claude。

这对长项目尤其重要，脚本负责稳定执行，Claude 负责理解结果。

用 allowed-tools 给 Skill 加安全边界

有些 Skill 是安全敏感的。比如：

CODE
代码审查
安全扫描
生产部署检查
数据库变更评估

这类任务里，你可能只希望 Claude 读取文件、搜索代码、运行检查命令，不希望它直接修改文件，这时候可以使用 allowed-tools。例如：

CODE
---
name: codebase-onboarding
description: Help new developers understand how the system works. Use when explaining project structure or onboarding to the codebase.
allowed-tools: Read, Grep, Glob, Bash
model: sonnet
---

这里的意思是，当这个 Skill 生效时，Claude 可以使用这些工具，但不会默认拥有所有操作权限。

对于只读分析类 Skill，allowed-tools 很有用。比如：

CODE
codebase-onboarding
architecture-review
security-audit
dependency-analysis

这些 Skill 最好不要一上来就能改代码，先读，先查，先分析，这会安全很多。

带副作用的 Skill，最好只允许用户主动触发

有些 Skill 不只是分析，而是可能带来真实影响。比如：

CODE
部署生产环境
删除临时资源
批量修改配置
生成并提交代码
发布版本

这类 Skill 不适合让 Claude 自动触发，因为一句话匹配错了，后果可能很麻烦。可以通过 disable-model-invocation、user-invocable 和工具白名单来控制 Claude 是否能自动调用某个 Skill。 

个人建议是，凡是有副作用的 Skill，都要更保守。比如：

CODE
---
name: production-deploy
description: Deploy the application to production. Use only when the user explicitly asks to deploy.
disable-model-invocation: true
user-invocable: true
allowed-tools: Bash
---

这类 Skill 的原则是：宁可麻烦一点，也不要自动误触发。

尤其是团队项目里，部署、删除、迁移、提交这类操作，都应该有明确边界。

Skills 怎么共享给团队？

Skills 真正有价值，不是你一个人用得爽，而是团队可以一起用。最简单的方法是把 Skills 放进项目目录：.claude/skills/ 然后提交到 Git。这样任何人 clone 项目，都能拿到同一套 Skills。适合放这里的内容包括：

CODE
团队代码 Review 标准
项目文档模板
组件设计规范
接口变更流程
测试用例生成规则

这比每个人自己写一套强很多。因为团队真正缺的，往往不是有没有 AI，而是大家对标准的理解是否一致。

Project Skills 的价值就在这里：它把团队经验变成项目资产。

Plugin 和 Enterprise：什么时候才需要？ 

如果只是一个项目使用，把 Skills 提交到仓库就够了。如果你有一套跨项目都能复用的 Skills，可以考虑 Plugin。比如：

CODE
前端可访问性检查
品牌文案检查
React 性能排查
API 文档生成

这些能力不依赖某一个项目，适合做成插件，在多个项目之间复用。

如果是公司级强制标准，就适合 Enterprise 管理。比如： 

CODE
安全合规检查
代码审计规范
隐私数据处理规范
统一品牌表达规范

Enterprise Skills 的优先级最高。 

如果企业 Skill 和个人 Skill 同名，企业 Skill 会覆盖个人 Skill。

所以如果只是个人偏好，不要上升到企业级。

Skill 不生效时，先别怀疑 Claude

写 Skills 最常见的问题不是 Claude 不聪明，而是 Skill 自己没写清楚。可以按下面这个顺序排查。

1、没有触发：先看 description 

如果 Skill 没触发，十有八九是 description 太虚。比如：

CODE
description: Help with performance.

这就很模糊，可以改成： 

CODE
description: Analyze performance issues in frontend or backend code. Use when the user asks why something is slow, how to make it faster, profile performance, reduce bundle size, or optimize runtime speed.

记住把用户真实会说的话写进去，比如：

CODE
为什么这么慢
怎么优化
帮我看性能问题
包体积太大了
页面卡顿

这些词越贴近真实表达，越容易触发。

2、没有加载：检查目录和文件名 

正确结构是：

CODE
.claude/skills/my-skill/SKILL.md
或者：
~/.claude/skills/my-skill/SKILL.md

常见错误是：

CODE
.claude/skills/SKILL.md

少了一层目录。

还有一个细节：文件名必须是：SKILL.md ，不要写成：

CODE
skill.md
Skill.md
skills.md

这些都可能导致 Claude 找不到。 

3、用错 Skill：说明描述太像了

如果 Claude 总是调用错 Skill，通常是因为几个 Skill 的 description 太接近。比如你有：

CODE
frontend-review
backend-review
code-review

但 description 都写成： 

CODE
Review code quality.

那 Claude 当然会混。应该写得更具体：

CODE
frontend-review: Review frontend UI code, React components, CSS, accessibility and browser performance.
backend-review: Review backend API code, database access, authentication, error handling and service performance.

Skill 越多，description 越要具体。

4、被覆盖：检查优先级 

如果你发现自己的个人 Skill 怎么都不生效，有可能是被更高优先级的 Skill 覆盖了。Skills 的优先级大致是：

CODE
Enterprise
Personal
Project
Plugins

也就是说，如果企业里有一个叫 code-review 的 Skill，你自己也写了一个 code-review，那企业版本会优先。

最简单的解决方法是改一个更具体的名字。比如：

CODE
my-frontend-review
mobile-ui-review
project-a-code-review

不要和已有 Skill 抢通用名称。 

5、运行报错：检查依赖、权限和路径

Skill 能加载，不代表一定能跑通。如果里面调用脚本，经常会遇到：

CODE
依赖没装
脚本没有执行权限
路径写错
Windows 和 macOS 路径分隔符不一致

几个实用建议：

脚本要加执行权限：

CODE
chmod +x scripts/check.sh

路径尽量使用：

CODE
scripts/check.sh

不要写成： 

CODE
scripts\check.sh

即使在 Windows，也尽量使用正斜杠。

如果脚本依赖某些工具，也要在 SKILL.md 里说明：

CODE
Before running this script, make sure pnpm is installed.

不要默认每个人电脑环境都一样。

刚开始不要贪多。 不要一上来就做十几个 Skill。 更好的方式是先做一套小而稳的组合：

CODE
commit-message
pr-description
code-review
bug-analysis
tech-plan

然后每次实际使用后，持续微调 description 和 Instructions。

一个 Skill 不是一次写完的。它更像团队流程文档，用一次，发现问题，改一次。 慢慢它就会越来越稳定。

上篇我们说，Skills 的本质不是增强 Claude，而是沉淀你的工作方法。到了下篇，其实还要再往前走一步——当 Skills 只属于你一个人时，它是个人效率工具。 当 Skills 放进项目、绑定 Subagents、配合 Hooks、连接 MCP，它就开始变成团队工作流的一部分。

真正成熟的 Claude Code 使用方式，不是把所有东西都写进一个超长 Prompt，也不是把所有问题都塞进 Skills。而是让不同能力各自站在合适的位置上。

CLAUDE.md 负责底线，Skills 负责经验，Subagents 负责分工，Hooks 负责流程，MCP 负责连接外部世界。

当这套系统搭起来以后，Claude Code 就不再只是一个会写代码的助手，而是一个能够承载经验、复用标准、协同工作的数字化团队成员。