三周前我写了一篇"1400 个 Skills 筛了 5 个"的文章，评论区最多的问题不是"装哪个"——而是"装了之后怎么用"。用了三周后，我发现大多数人装 Skills 的方式，注定了它不会好用。

装了等于没装，这不是夸张

先看一个真实场景：你装了一个代码审查类的 Skill，然后兴冲冲地让 Claude Code 帮你 Review 一段 React 代码。

结果它给你一堆"变量命名不够语义化"、"建议加注释"这种废话。

你心想：这跟没装有什么区别？

问题不在 Skill 本身，而在你没告诉它你的项目是什么样的。同一个 Skill，在不同的项目配置下，表现天差地别。

三周踩坑下来，我总结了 5 条铁律。

铁律一：SKILL.md 的写法比选哪个 Skill 重要 10 倍

大多数人装 Skill 的方式是：找到一个看起来不错的 → 一键安装 → 期待奇迹。

但 Skill 本质上就是一段提示词。它的效果完全取决于它能拿到多少关于你项目的上下文。

看个对比：

# 差的SKILL.md（大多数人的状态）
---
name: code-review
description: Review code for issues
---

Review the code and find problems.

# 好的SKILL.md（效果翻倍）
---
name: code-review
description: Review React/TypeScript code following team conventions
---

## 审查范围
- React组件：检查hooks依赖数组、memo使用、重渲染风险
- TypeScript：检查any逃逸、类型断言滥用、泛型约束缺失
- 状态管理：检查props drilling深度、context滥用

## 项目约定
- 组件文件用PascalCase，hooks用use前缀
- API层统一用react-query，禁止在组件内直接fetch
- 错误处理统一用ErrorBoundary，不在组件内try-catch

## 忽略项
- 不检查样式类名（用了Tailwind，没有命名规范）
- 不检查import顺序（有ESLint规则自动处理）

区别在哪？第二个版本告诉了 Skill 三件事：

1. 检查什么（React/TS 的具体问题）
2. 项目约定（不用猜你的代码风格）
3. 不检查什么（避免输出废话）

同一个审查 Skill，第一种写法输出 10 条建议有 8 条是废话，第二种写法输出 5 条建议每条都能直接改。

核心原则：Skill 是你项目的"代入说明书"，不是一句话描述。

铁律二：3 个精配 > 20 个全装

Skills 生态已经有几十万个了。但我现在只保留 3-5 个。

原因很简单：Claude Code 的上下文窗口是有限的。你装的每一个 Skill 都会占用上下文空间。装太多，相当于让 AI 同时听 20 个人说话——它哪个都听不清。

我亲测的对比：

配置	装了多少	实际效果
全装型	15+ 个 Skill	回答变慢，经常答非所问，有时候互相矛盾
精选型	3-5 个 Skill	回答精准，速度快，几乎不出错

这就像手机装 APP——你装了 200 个，常用的也就那 5 个，剩下的都在后台占内存。

怎么选这 3-5 个？问自己一个问题：在我的日常开发中，哪 3 个场景我最频繁地需要 AI 帮忙？

对我来说是：

1. 新组件搭建（需要设计 + 代码）
2. 代码审查（需要按项目规范检查）
3. 调试疑难问题（需要系统性排查）

其他场景偶尔用到，但不值得常驻。

铁律三：自己写的 10 行 Skill 比装别人的 100 行好用（最反直觉）

这一条最反直觉，但也是我三周下来最大的收获。

Superpowers 有 2000+ 行配置，Frontend Design 有 500+ 行提示词。它们确实好用——但对你的项目来说，你自己写的 10 行 Skill 可能比它们更好用。

为什么？因为你最了解自己的项目。

举个例子。我的前端项目用了 React + TypeScript + Zustand + React Query 这套组合。我写了一个 10 行的 Skill：

---
name: component-scaffold
description: Scaffold React component with project conventions
---

新建组件时遵循以下结构：
1. 创建 ComponentName/index.tsx + ComponentName.types.ts + ComponentName.test.tsx
2. 状态管理：局部状态用useState，跨组件用Zustand store，服务端数据用useQuery
3. 样式用Tailwind，不写CSS文件
4. 导出类型和组件，类型文件独立
5. 测试文件用Testing Library，至少覆盖渲染和主交互

就这 10 行，比任何通用的组件生成 Skill 都好用。因为它精确匹配了我的技术栈和团队约定。

通用 Skill 再好，也得猜你用的是 CSS Modules 还是 Tailwind、状态管理用的是 Redux 还是 Zustand、测试框架用的是 Enzyme 还是 Testing Library。猜就意味着不精准。

自定义 Skill 的写法模板：

---
name: [场景名，用kebab-case]
description: [一句话描述这个Skill做什么]
---

## 触发条件
[什么情况下激活这个Skill]

## 执行步骤
1. [第一步]
2. [第二步]
...

## 项目约定
- [你的技术栈]
- [你的代码规范]
- [你的文件结构约定]

三个字段就够了：什么时候用、怎么用、项目长什么样。

铁律四：Skill 之间要串联，不要各自为战

大多数人用 Skill 的方式是：需要 Review 就调 Review Skill，需要调试就调 Debug Skill。一个一个用，各干各的。

但真正高效的用法是把 Skills 串成工作流。

我的前端开发工作流：

需求 → [brainstorming] 明确方案
     → [component-scaffold] 生成组件骨架
     → 写业务代码（这步我自己写）
     → [code-review] 自动审查
     → [tdd] 补充测试用例

每一步的输出自然成为下一步的输入。brainstorming 确定了方案，scaffold 就知道要生成什么组件；代码写完，review 的上下文里已经有了完整的业务逻辑。

这比你一步步手动调用效果好得多。原因是：串联使用时，AI 积累了完整的上下文链——它知道你在做什么、为什么这么做、前面做了什么决策。

单独调用时，每次都是冷启动，AI 要重新理解你的意图。

速查表：常见前端场景的 Skill 串联方案

场景	推荐串联	效果
新功能开发	brainstorm → scaffold → code → review → test	全流程覆盖，不漏环节
Bug 修复	debug(系统性排查) → fix → review → test	避免"修了 A 炸了 B"
重构	review(找问题) → plan(确定范围) → refactor → test	不过度重构
Code Review	review → 逐文件检查 → 汇总报告	不漏文件，有结构化输出
新项目初始化	scaffold → 目录结构 → 基础配置 → 文档生成	10 分钟搭完项目骨架

铁律五：CLAUDE.md + Skills + .mcp.json 三位一体

这是最容易忽略的一条。

很多人以为装了 Skills 就完事了。但 Skills 只是三个配置中的一个：

CLAUDE.md     → 全局项目规则（"这个项目用TypeScript严格模式"）
Skills        → 特定场景的行为模式（"新建组件时这样做"）
.mcp.json     → 外部工具连接（"可以访问数据库/API文档"）

三者的关系是：

层级	文件	类比	作用
全局规则	CLAUDE.md	公司规章制度	"所有代码必须 TypeScript，禁止 any"
场景行为	Skills	岗位操作手册	"Review 时检查这 5 项"
外部能力	.mcp.json	工具箱	"可以查 API 文档、读数据库"

只装 Skills 不写 CLAUDE.md，就像给员工发了操作手册但没告诉他公司规定。 Skill 不知道你的项目用什么技术栈、什么代码规范、什么 Git 分支策略——这些是 CLAUDE.md 的活。

一个最小但完整的配置示例：

# CLAUDE.md
- 技术栈：React 18 + TypeScript 5 + Zustand + React Query + Tailwind
- 代码规范：ESLint + Prettier已配置，不需要AI检查格式
- Git：commit message用conventional commits格式
- 测试：Jest + Testing Library，覆盖率要求>80%
- 禁止：any类型、console.log提交、直接操作DOM

// .mcp.json（如果你的项目需要外部数据）
{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@anthropic/context7-mcp"]
    }
  }
}

CLAUDE.md 定规矩，Skills 定流程，MCP 接外部工具。三个配好，Skills 的效果至少翻一倍。

终极速查表：Skills 使用对照

错误用法	正确用法	差距
装了 15 个 Skill	精选 3-5 个，其余删掉	回答精准度↑↑
SKILL.md 只写一句话	写清楚检查范围 + 项目约定 + 忽略项	有效建议率从 20%→80%
只用别人写的 Skill	自己写 10 行项目专属 Skill	匹配度从 60%→95%
每个 Skill 单独调用	串联成工作流，上下文连贯	效率提升最明显
只装 Skills 不写 CLAUDE.md	CLAUDE.md + Skills + MCP 三位一体	解锁完整能力
装完不管，期待奇迹	每周根据使用情况调整配置	持续优化

---

三周前装了 Skills 的那天，我以为这东西装完就能用。三周后我才明白：Skills 不是即插即用的插件，而是需要调教的工具。

你花 5 分钟写一个项目专属的 SKILL.md，效果顶得上你翻遍整个 Skills 市场。

你的 Claude Code 装了几个 Skills？有没有自己写过？评论区聊聊你的配置方案。