用 Claude Code 写代码有一阵子了，一开始每次都是在对话里现场把上下文一股脑塞进去：”我们项目用的是 XX 框架，测试要跑 XX 命令，部署流程是先 XX 再 XX……”，这套话术几乎每次任务都要重新打一遍,烦是真烦,而且经常还漏东西,比如忘了提醒它这个仓库提交信息有固定格式,结果它自由发挥写了一版不符合规范的,还得回头改。用了 Skills 之后这类重复劳动基本消失了，记一下当初为什么决定花时间去整理这套东西。
Skills 本质上就是把一套”该怎么做某件事”的说明书写成文件放在项目里，需要的时候 Claude Code 自己去读，不用每次对话都手动重复。最开始动手写的是 code review 这个场景，团队里 review 的时候有一套约定俗成的检查点：命名要不要遵循现有约定、错误处理要不要覆盖边界情况、有没有引入不必要的抽象。这些东西以前是靠资深同事口头带新人,现在写成一个 skill 之后，不管谁在这个仓库里用 Claude Code 跑 review，都是同一套标准，不会因为忘了交代某个点就漏检查。
真正让我觉得这东西值得投入的是它和”每次对话里贴一遍要求”的本质区别：贴在对话里的说明只在这一次会话里有效，换个人、换个新会话，这套东西又得重新讲一遍，讲的时候用词还可能跟上次不完全一样，产出效果就跟着飘。写成 Skill 之后是版本化的、可以进 git 仓库跟着代码一起演进的东西,团队里谁改进了这个流程,提个 PR 大家都能同步用上新版本,这跟口头传帮带比起来完全是两种可靠性量级。
用下来感触比较深的一点是 Skills 不是用来教它”怎么写代码”的,这个它自己本来就会,真正有价值的是把项目里那些没写在代码里、只存在于团队脑子里的隐性规则显式化。比如我们有个仓库发布前必须先跑一个内部的兼容性检查脚本，这个步骤在文档里压根没提过,全靠老员工口口相传,写成 skill 之后新接手这个仓库的人（不管是人还是 Claude Code）都不会漏掉这一步。这算是意外的收获——整理 skill 的过程顺带把团队里一堆没写文档的隐性知识给挖出来落了地，这个价值比省下重复打字的时间更大。
也不是所有场景都适合抽成 Skill，抽象过度了反而是负担。试过把一个只用过一次的临时任务也写成 skill，结果维护成本比它带来的收益还高,后来的判断标准变成:这件事会不会在这个项目里反复发生、流程会不会被不同的人执行、有没有容易被遗漏的细节，三个条件占得越多，越值得写成 skill；一次性的、临时的事情就不用往这个方向使劲，直接对话里说清楚就行，没必要为了用而用。
另一个体会是 Skills 写多了之后要有意识地去重和维护，不然几个月下来会出现内容重叠、甚至互相矛盾的情况,比如一个是很早写的旧版部署流程说明，另一个是后来改了流程之后新写的，两个同时存在，Claude Code 读到的时候容易犯迷糊。这个说到底也是文档维护的老问题，Skill 只是换了个载体，该有的版本管理意识一点没少,写完不代表结束，得跟代码一样时不时回头看看是不是过时了。
回头看这半年最大的变化是不用再把自己当成 Claude Code 每次对话的记忆体了,以前总担心”这次是不是又得重新解释一遍项目规范”，现在这部分交给 Skills 之后，注意力能真正放在任务本身要解决的问题上，这才是省下来的时间里最值钱的那部分。