上次写完《从网页聊天到 Claude Code：一个 Skill 改变了什么》之后，又过了一个月。
这一个月里我没怎么再折腾什么新鲜玩意，而是我对”Skill 这个东西到底该怎么用”这件事，想法完全变了。
刚开始：觉得 Skill 就是”能跑命令的聊天框”的升级版#
刚接触 Claude Code 的 Skill 机制时，我第一反应其实挺平淡的——这不就是个写好的 Prompt 吗。
你把一段提示词保存下来，下次要用的时候贴进对话框，效果不是一样的？很多人估计也会这么想。
但真正上手写了几个之后，发现 Skill 跟 Prompt 根本不是一个东西。区别不在内容，在执行方式。
Prompt 的执行方式是一次性全丢出去。你把所有要求、步骤、注意事项写在一段话里，AI 收到之后一口气跑完。流程是预设死的——第一步做什么、第二步做什么、遇到什么怎么处理，全在发出去的那一刻就定好了。AI 只能按你写好的剧本走到黑，中间没法真正变通。
Skill 不一样。Skill 走的是多轮调用——它不是一次性把所有东西灌给 AI 然后等结果，而是让 AI 自己走一步、看一步、再决定下一步。
举个例子更清楚。假设我要 AI 帮我做一次代码审查——
用 Prompt 的思路：把需要检查的文件、检查标准、输出格式全写进去，AI 一次性跑完给我结果。但实际审代码的时候，问题往往是审着审着才发现的——看到 A 文件有个奇怪的写法，想去 B 文件确认一下是不是配套的；发现一个可疑的依赖，想查一下 CHANGELOG 看是不是有 Breaking Change。这些”半路发现的新线索”，Prompt 预设不了。
Skill 就可以。它先看项目结构，根据项目类型决定重点查什么；发现问题后主动去翻相关文件验证；该问我的时候停下来问；下一步审什么，取决于上一步发现了什么。
Prompt 是导演把剧本写好，演员照着演。 Skill 是给演员一个目标和原则，他自己在片场判断怎么走位、什么时候即兴。
所以 Skill 本质上不是”更长的 Prompt”，也不是”能跑命令的聊天框”。它是一套让 AI 能多步决策、动态调整的东西。你写的不是它要说什么话，而是它做判断的依据。
然后：开始疯狂找别人的 Skill#
理解了这个机制之后，我开始了典型的”插件党”行为——到处找别人写好的 Skill。
在 GitHub 上搜、在社区里翻、看到谁分享就拿过来试试。
这个阶段的体验可以用四个字概括：水土不服。
首先，大部分公开的 Skill 都是英文社区的产物。不是说英文 Skill 写得不好，而是很多时候它假定的工作流、命名习惯、甚至思维方式，跟我实际在做的事对不上。
其次，很多 Skill 试图解决的是”通用问题”。但真正让你每天花时间的，往往是那些特定的、流程性的、只有你自己在做的重复劳动。没有哪个公开 Skill 能知道你的项目目录怎么组织的、你的数据库命名规范是什么、你跟同事约定的提交流程是什么。
为了省时间去找别人的 Skill，结果花在适配上的时间和 token，比自己从头做一遍还多。
这件事发生过两三次之后，我开始重新想这个问题。
转变：最好的 Skill，是自己写的#
说到底，Skill 不是 App Store 里的应用——装上就能用。Skill 更像是工具。
顶级厨师的厨房里，每一把刀的位置、每一口锅的深浅，都是按自己的习惯来的。打铁的老师傅，锤子的重量和角度只有他自己用着顺手。
Skill 也是这种东西。它本质上是你把自己的工作方式、决策逻辑、重复流程，外化成一个 AI 可以执行的结构化文档。
想通这一点之后，我开始观察自己每天在做的事情——
- 哪些事情是每次都走同样的流程？
- 哪些决策我反复在跟 AI 解释？
- 哪些”看一眼就知道怎么做”的判断，其实已经刻在我的直觉里了，但 AI 不知道？
这些事情，只要重复的次数够多、每次重复的成本够高、用 Skill 解决的收益够大，就值得写成一个 Skill。
观念变了，事情还是那些事，但心态完全不同了#
这个东西妙就妙在——你实际做的事情没有任何变化，但整个人的心态会完全翻过来。
以前我的模式是：
遇到问题 → 打开 AI → 描述问题 → AI 帮忙解决 → 解决完了就完了
这是一种单兵作战的思路。AI 是工具，我是操作员。偶尔刷到什么”AI 取代程序员”的新闻，心里还会咯噔一下。
有了 Skill 的意识之后，心态变成：
这件事能不能让 AI 低成本地替我做？能的话，我把它提炼成 Skill，然后腾出精力去干别的。
就像以前的工厂主要靠有能力的老师傅，后面逐渐开始靠流水线和规模化。不是说老师傅不重要了，而是老师傅把自己的经验固化进了流水线里。
同样的道理——我开始主动去找”哪些地方 AI 可以替代我”。不只是”有没有替代我的能力”，而是”能不能低成本地替代我”。能低成本替代的部分，沉淀成自己的 Skill。不能的部分，才是我真正该花精力的地方。
这个心态转变对我来说非常关键：
- 以前焦虑 AI 会不会淘汰我 → 现在觉得 AI 就应该淘汰我那些重复性劳动
- 以前把 AI 当临时工用 → 现在把 AI 当可以持续训练和调教的助理
- 以前每次都要重新解释 → 现在解释一次，用无数次
Skill 是 AI 能力放大器#
AI 的能力越来越强，这没什么好争议的。
但是有 Skill 的 AI 和没 Skill 的 AI，能力是有高下之分的。
一个没有 Skill 的 Claude，就像一个能力很强但对你一无所知的新同事。他知道怎么编程，但不知道你的代码风格、你的项目结构、你的偏好。每次合作都得重新对齐。
一个有 Skill 的 Claude，就像跟你磨合了很久的搭档。他知道你的习惯，知道你的判断标准，知道你上次做类似决定时是怎么想的。
这就是放大器的意思——同样的底座模型，同样的能力上限。区别在于：你有没有把你自己的那部分东西，喂给了它。
我自己的 skillbox#
想清楚这些之后，我把写过的 Skill 整理成了一个公开仓库：skillbox ↗。
但我想说的不是”来用我的 Skill”。正相反——
我自己的 README 里也写了：不建议直接用别人的 Skill，鼓励大家建一个自己的 skillbox。
适合我的不一定适合你。我的账单分析可能是给微信支付宝导出的 CSV 写的，我的 Git 提交规范可能跟你团队的不一样，我的心理陪伴 Skill 可能嵌入了东亚文化的语境——这些都不是”通用”的东西。
但它们代表了一个人如何把自己的重复性工作，变成可复用的结构化知识。
如果你还没用过 Claude Code，可以先看看我之前写的这篇入门文章 ↗，把环境搭起来。
如果你已经在用了，但还没开始写自己的 Skill——我建议你今天就观察一下自己今天做了什么。有没有哪件事，是你这周第三次用几乎同样的方式再做一遍的？
那件事，大概率值得变成一个 Skill。
说到底#
Skill 不是”找到了就装”的插件。它是你自己工作流的镜子。
你越是了解自己的工作方式，就越能写出好用的 Skill。你写的 Skill 越多，就越清楚哪些事真正值得你的时间、哪些事早该交给 AI。
比起焦虑 AI 什么时候会淘汰自己，不如提前积累自己的 Skill，做 AI 能力的放大器。