Skill 的局限和常见坑

装太多反而更差

一个很反直觉的事实：Skill 装得越多，AI 表现不一定更好。

Skill 本质是 system prompt 的一部分。每多一个 Skill，就多占一段上下文窗口。上下文被塞满后，模型留给"理解你的话"和"实际推理"的空间就变少了。

实测发现，全局 Skill 超过 30 个，执行质量会明显下降。表现包括：

• 跳过步骤、丢三落四
• 触发错误的 Skill
• 输出格式和预期不一致

建议这样控制：

少即是多。与其装 30 个半吊子的 Skill，不如留 10 个真正好用的。

全局 vs 项目 Skill

这是很多人会忽略的一个区分。

全局 Skill 放在 ~/.claude/skills/，每次对话都会加载。适合通用工具类——比如 commit 规范、代码简化、文档格式化。不管你写代码还是写文章，这些 Skill 都可能用到。

项目 Skill 放在 .claude/skills/（项目根目录下），只在该项目目录里生效。适合项目专属流程——比如某个项目的部署 checklist、特定的数据处理流程。

这有什么用？举个例子：

你同时在做两件事——写代码和写公众号文章。代码项目里装了 code review、release checklist 这些 Skill；内容项目里装了多平台适配、标题优化这些 Skill。它们互不干扰。

如果你把这些全塞进全局目录，每次写文章时 AI 也会"看到"代码审查的流程描述。浪费上下文不说，还可能触发错误的 Skill。

具体建议：

• 通用的放全局（5-10 个上限）
• 项目专属的放项目目录
• 定期清理：删掉一个月没用过的

Skill 不能替代思考

这点必须说清楚。

Skill 是"流程标准化"，不是"自动做对"。如果任务本身没想清楚，装再好的 Skill 也不会变好。

一个糟糕的 PRD 模板，只会更快地产出糟糕的 PRD。一个设计有缺陷的代码审查流程，Skill 化之后只是把"缺陷"执行得更标准了。

Skill 放大的是你的工作流程质量。流程好，放大后是效率；流程烂，放大后只会更乱。

更稳的顺序是：

1. 先手工把流程跑通、跑顺
2. 记录哪些步骤有效、哪些是废话
3. 优化到自己满意了
4. 再写成 Skill

不要跳过前面三步。

不同模型执行差异

同一个 Skill，在不同模型上的表现可能差很多。

复杂 Skill（步骤多、判断分支多、需要推理）在弱模型上容易走样。常见的问题：

• 漏掉中间步骤
• 理解错触发条件
• 输出格式不对
• 把可选步骤当必需的执行，反过来也一样

实际观察大概是这样：

Skill 和 CLAUDE.md 的冲突

CLAUDE.md 是项目级别的"全局指令"，告诉 AI 这个项目的规范、风格、偏好。Skill 是针对特定任务的流程。

两者如果打架，AI 会困惑。

举个例子：CLAUDE.md 里写"代码注释用中文"，但某个 Skill 里写"注释必须用英文"。AI 执行的时候听谁的？

避免冲突，可以这么做：

1. CLAUDE.md 写通用规范，不要写具体流程
2. Skill 里引用 CLAUDE.md 的规范，而不是重复写一套
3. 如果 Skill 需要覆盖 CLAUDE.md 的某个规则，在 Skill 里明确说明："此 Skill 中，注释统一用英文，覆盖项目默认设置"

简单说就是：定规范找 CLAUDE.md，定流程找 Skill。别让它们重叠。

版本更新的风险

Skill 通过 npx skills add 安装后，上游更新了，你本地不会自动跟着更新。

但如果你手动改过 Skill（比如调整了某个步骤），再运行更新，你的修改会被覆盖。

这两个问题叠在一起就很有风险：你以为自己改过的 Skill 还在，结果某次更新后全回原样了。

建议这样处理：

1. Fork 后自定义 — 从上游 fork 一份到自己的仓库，基于这个版本改
2. 标记改动 — 在自定义的 Skill 里加一行注释说明改了什么
3. 谨慎更新 — 更新前 diff 一下，看看上游改了什么，再决定要不要合入

# 查看上游变更
git log --oneline origin/main..HEAD

# 对比差异
git diff HEAD origin/main -- SKILL.md

对于团队项目，建议把 Skill 也纳入版本控制，和代码一起 review。

下一步

• 想了解怎么创建 Skill → 看 创建 Skill
• 想了解 Skill 和 MCP 怎么配合 → 看 Skills + MCP 组合
• 遇到具体问题 → 看 FAQ