Claude Code 的 Skill 到底有什么用？我一开始也完全没搞懂

前几篇文章里，我一直在解决一个问题：怎么让 Claude Code 少犯错。

我写过 CLAUDE.md，也整理过 Rules，后来甚至加了 Hooks。

这些东西确实有用。Claude Code 不会再像以前那样，修一个小 Bug 顺手重构半个项目；也不会在命令连续失败三次之后，还继续像没事一样往下跑；更不会每次完成任务后，只留下一句“已经修复完成”就结束。

但过了一段时间，我发现了另一个问题。

它是不怎么乱来了，可它好像也没有变得特别能干。

这个感觉很微妙。以前 Claude Code 乱改代码的时候，我知道问题在哪里：它没有边界。可是当我已经给它加了边界，它还是做得不够专业时，我反而有点不知道该怪谁。

比如我让它修 Bug，它现在知道不能随便改很多文件，但它不一定会先复现问题。

我让它做一个新功能，它知道要先看上下文，但它不一定会先确认需求边界。

我让它帮我做代码审查，它能指出一些问题，但每次关注点都不一样。有时候看命名，有时候看结构，有时候只看语法，有时候又突然开始讲性能优化。

那时候我有一个很强烈的感觉：Claude Code 确实听话了，但还不像一个真正有经验的助手。

后来我才意识到，我前面做的很多配置，其实都在解决“约束问题”。

CLAUDE.md 让它知道项目大概是什么。

Rules 告诉它什么事情不要做。

Hooks 在关键节点直接拦住错误行为。

但这些东西并没有真正告诉它：遇到某一类任务时，应该按照什么专业流程做。

我一开始也没搞懂 Skill 是什么

我第一次看到 Skill 的时候，其实完全没理解它的价值。

当时我的第一反应是：这不就是把一段 Prompt 保存起来吗？

如果只是一些长期提示，那我放到 CLAUDE.md 里不就行了吗？

如果是规则，那我放到 Rules 里不就行了吗？

如果要强制执行，那 Hook 不是更靠谱吗？

所以很长一段时间，我虽然知道 Claude Code 有 Skill，但我没有真正用明白它。

我看到别人配置了一堆 Skill，也只是觉得很厉害，但不知道自己该从哪里开始抄，更不知道哪些东西适合写成 Skill，哪些东西不适合。

直到后来有一次修 Bug，我才真正想明白这件事。

那次问题其实不复杂。我把报错贴给 Claude Code，让它帮我看一下。它先搜了一圈代码，然后很快锁定了一个看起来相关的文件，接着就开始修改。整个过程看起来很顺，甚至有点让人放心。

但我跑了一遍，问题还在。

我让它继续修，它又找了另一个地方改。再跑，还是不对。第三次的时候，它开始怀疑是配置问题，准备继续扩大修改范围。

这时候我突然停下来想了一下：它到底是在修 Bug，还是在猜 Bug？

它不是完全没能力。它能读代码，也能分析报错，还能提出修改方案。

问题是，它没有一个稳定的调试流程。它每次都在现场决定下一步该干什么。

有时候先看日志。

有时候先改代码。

有时候直接猜原因。

有时候还没有复现，就开始动手。

这就像一个新人程序员，不是不努力，也不是完全不会，而是做事没有固定方法。遇到问题就凭感觉冲，运气好一次改对，运气不好就越改越乱。

Rules 只能让它别乱来，不能让它更专业

我以前试图用 Rules 解决这个问题。

比如我写：“修 Bug 前必须先分析。”

这句话当然有用，但它还是太粗了。

什么叫分析？

分析到什么程度可以开始改？

要不要先复现？

要不要先确认最小失败案例？

改完以后用什么方式验证？

如果验证失败，下一步是继续改，还是回到假设？

这些东西不是一句“先分析”能解决的。

后来我才明白，Skill 的位置就在这里。

Skill 不是一句提示词。

Skill 也不是一条规则。

Skill 更像是一套可以重复调用的专业工作流。

比如修 Bug，不应该只是告诉 Claude Code“认真一点”“先分析再修改”。

真正有价值的是告诉它：遇到 Bug 时，先建立反馈回路，先复现问题，确认错误现象，再缩小怀疑范围，提出最小修改方案，修改后用同一个方式验证。如果验证失败，不要继续盲改，而是回到新的假设。

这才是 Skill 的意义。

它不是让 Claude Code 记住一句话，而是让它在某一类任务里进入一套固定流程。

这个认知对我影响挺大的。

因为我以前总想让 Claude Code “多记住一些规则”。

后来我发现，更重要的是让它“进入正确流程”。

Prompt、CLAUDE.md、Rules、Hooks、Skill 到底有什么区别？

我后来给自己做了一个很简单的区分。

Prompt 解决的是：这一次，我希望你怎么做。

CLAUDE.md 解决的是：长期来看，你要知道我是谁、项目是什么、基本原则是什么。

Rules 解决的是：你不能怎么做。

Hooks 解决的是：你做错了，我直接拦住。

Skill 解决的是：遇到某一类任务时，你应该按哪套专业流程做。

这个区分很重要。

比如“不要顺手重构”，这是 Rule。

比如“修改 .env 文件前必须确认”，这更适合 Rule 或 Hook。

比如“修 Bug 时必须先复现、再定位、再最小修改、再验证”，这就很适合 Skill。

再比如“做新项目时，不能用户说一句想法就直接开始写代码，而是要先压力测试需求、确认目标、拆分范围、建立目录结构、再进入实现”，这也适合 Skill。

因为它不是一条禁止事项，而是一套工作流程。

Rules 解决的是边界问题。

Hooks 解决的是强制执行问题。

Skills 解决的是流程复用问题。

这就是我后来真正理解 Skill 的地方。

什么东西适合写成 Skill？

我后来给自己总结了一个判断标准：一个任务适不适合写成 Skill，主要看三个条件。

第一，它是不是经常重复出现。

第二，它每次的流程是不是相对稳定。

第三，Claude Code 是不是经常在这个任务里的某一步翻车。

如果三个条件都满足，那它就很适合写成 Skill。

比如修 Bug 就很适合。

因为它高频，流程也相对稳定，而且 Claude Code 很容易在“没有复现就开始改”这一步翻车。

比如从一个想法开始做项目，也很适合。

因为用户经常只会说“我想做一个什么东西”，但 Claude Code 如果直接进入实现，很容易做出一个方向正确但根本不好用的东西。这个时候就需要一个 idea-to-project 之类的 Skill，让它先把想法变成需求，再把需求变成方案，最后才进入代码。

比如验证交付也适合。

因为 Claude Code 最喜欢说的一句话就是“已经修复完成”。

但完成不等于验证通过。

一个 verification-loop 类型的 Skill，就可以把 Build、Type、Lint、Test、Security、Diff 这些检查变成固定流程，而不是每次都靠我提醒。

但不是所有东西都应该写成 Skill

我以前最容易犯的错误，就是把所有东西都往一个地方塞。

看到 CLAUDE.md，就想把所有要求写进去。

看到 Rules，就想把所有经验都写进去。

看到 Hooks，又想把所有错误都拦住。

看到 Skills，又想把别人的 Skill 全部复制过来。

但这样做的结果往往不是系统更强，而是系统越来越乱。

比如“回答要简洁”，这不是 Skill，更像个人偏好。

比如“不要删除文件”，这不是 Skill，更像红线规则，甚至应该交给 Hook。

比如“这个项目使用 React 和 Tailwind”，这也不是 Skill，它只是项目上下文。

比如“我喜欢你先给结论再解释”，这也不是 Skill，而是交流风格。

真正有效的配置，不是越多越好，而是每一层各自解决自己的问题。

CLAUDE.md 像入职手册，告诉 Claude Code 这个项目是什么，我是谁，基本原则是什么。

Rules 像规章制度，告诉它哪些事情不要做，哪些边界不能碰。

Hooks 像保安系统，在关键节点强制检查，发现危险行为就拦住。

Skills 像专业岗位培训，告诉它遇到某一类任务时，应该按什么流程完成。

这样一看，Skill 的位置就清楚了。

它不是用来替代 Prompt 的，也不是用来替代 Rules 的，更不是用来替代 Hooks 的。

它解决的是“专业流程复用”的问题。

很多人不是不会用 Claude Code，而是每次都让它临场发挥

这也是我后来觉得 Skill 很重要的原因。

很多人用 Claude Code 不稳定，不一定是模型差，也不一定是 Prompt 写得不够长，而是每次都让它临场发挥。

今天修 Bug，让它自己想怎么修。

明天做项目，让它自己想怎么拆。

后天做审查，让它自己想看哪些问题。

每次看起来都在用 AI，但其实每次都在重新训练一个临时工。

而 Skill 的价值，就是把你已经验证过的工作方法沉淀下来，让 Claude Code 下次遇到同类任务时，不是从零开始猜，而是直接进入一套你认可的流程。

这件事听起来不复杂，但真正做起来会改变很多体验。

以前我让 Claude Code 修 Bug，我更关注它“有没有找到答案”。

现在我会先看它“有没有进入正确流程”。

它有没有先复现？

有没有确认错误现象？

有没有说明怀疑范围？

有没有做最小修改？

有没有给出验证命令？

如果这些步骤没有出现，我就知道它又开始凭感觉做事了。

这个判断比单纯看结果更重要。

因为 AI 很容易给出一个看起来像结果的结果。

它会说修好了，会说已完成，会说问题已解决。

但如果过程不可靠，结果就很难信任。

Skill 的本质，其实是在提高过程的可靠性。

第一个 Skill 应该怎么开始？

我现在也不觉得一个人一开始就应该写很多 Skill。

刚开始最好的方式不是抄一堆别人的配置，而是回头看自己最近三次被 Claude Code 坑到的经历。

它是不是总在修 Bug 时乱改？

那你的第一个 Skill 就应该是 debugging。

它是不是总在新项目开始时跳过需求澄清？

那你的第一个 Skill 就应该是 idea-to-project。

它是不是总说完成了，但你一跑就报错？

那你的第一个 Skill 就应该是 verification-loop。

Skill 不应该从“我想拥有一套很酷的配置”开始。

它应该从“我被同一个问题折磨了很多次”开始。

这也是我对 Claude Code 配置最大的一个变化。

以前我想的是：我能不能写一套很完整的规则，让它一次性变聪明？

现在我更愿意问：我最近最常重复的任务是什么？这个任务最容易在哪一步翻车？如果让我自己认真做，我会按什么流程做？能不能把这套流程写成 Skill？

这个思路比盲目堆配置有效得多。

因为它不是在幻想 AI 一夜之间变成专家，而是在一点点把自己的工作方法交给 AI。

为什么别人用 Claude Code 像开挂？

后来我也开始理解，为什么有人用 Claude Code 像开挂。

不一定是他的模型更强。

也不一定是他的 Prompt 更神秘。

很多时候，是他已经把高频任务拆成了一套套稳定流程。

修 Bug 有修 Bug 的流程。

做项目有做项目的流程。

搜索资料有搜索资料的流程。

验证交付有验证交付的流程。

Claude Code 不是每次都重新思考“我该怎么做”，而是直接进入对应的工作流。

这才是 Skill 真正有价值的地方。

至于 MCP，我现在会把它理解成下一层问题。

如果 Skill 解决的是“Claude Code 应该怎么做事”，那 MCP 更像是解决“Claude Code 能接触到什么工具和数据”。

Skill 是工作流。

MCP 是外部连接。

一个告诉它怎么做，一个让它能接触到更多真实环境。

但对大多数刚开始配置 Claude Code 的人来说，先理解 Skill，已经能让体验发生很大变化。

因为你会从“提醒 AI”变成“训练流程”。

以前你可能会反复说：

你先分析一下。

你不要乱改。

你改完要验证。

你不要只看表面。

你先确认需求。

这些话说一次有用，说十次就很累。

而 Skill 的意义，就是把这些反复出现的提醒，整理成一套可复用的任务流程。

不是每次重新教育它，而是让它下次直接进入这个流程。

Skill 不是高级 Prompt，而是一套方法

我现在越来越觉得，AI 使用能力的差距，不只在于会不会提问，也在于会不会沉淀流程。

Prompt 是一次对话。

Skill 是一套方法。

一次好的 Prompt 可以解决一次问题。

一个好的 Skill 可以减少一类问题。

这就是我后来真正理解 Skill 的地方。

它不是 Claude Code 里一个很酷的高级功能，也不是给高手炫配置用的东西。

它其实很朴素。

你在哪类任务上反复踩坑，就把那类任务的正确流程写下来。

你希望 Claude Code 下次不要再临场发挥，就给它一个可重复执行的工作流。

你希望它从“听话”变成“专业”，就不能只给它规则，还要给它方法。

Rules 让 Claude Code 别乱来。

Hooks 让 Claude Code 错了也过不去。

Skills 才开始让 Claude Code 真正像一个有工作方法的助手。

这也是我最近最大的一个收获。

AI 不会凭空拥有你的工作流。

你必须先把自己的工作方式想清楚，再把它交给 AI。

欢迎来到我的成长实验。

AI 不会替你成长。

但它能让成长更快发生。