我用了三周Claude Code Skills——总结出5条铁律，第3条最反直觉

三周前我写了一篇"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？有没有自己写过？评论区聊聊你的配置方案。