我把里面最有价值的东西提炼出来，跟大家聊聊。
1、Skill 这东西，比你想的要强大得多
很多人对 Skill 的理解停留在“就是个 Markdown 文件嘛，写点提示词让 AI 照着做”。Anthropic 的人说，这是最常见的误解。
Skill 其实是一个文件夹。里面可以放脚本、数据文件、参考代码、模板，甚至 SQLite 数据库。Claude 能自己去翻这个文件夹，找到它需要的东西，然后用起来。
这就像你给一个新来的同事安排工作，如果你只给他一张纸条写着“去把这个功能做了”，他大概率会做得磕磕绊绊。但如果你给他一个完整的工具箱，里面有参考代码、常见问题清单、测试脚本、模板文件，他上手就快得多。Skill 就是这个工具箱。
想想看，我们平时做任何工作，效率最高的时候往往是手边有一套趁手的工具和参考资料。Skill 的设计思路其实跟这个道理一模一样，把你的经验、流程、工具打包成一个可复用的单元，下次再遇到类似的事，直接调用就行。
2、九种类型，覆盖了软件开发的方方面面
Anthropic 把内部所有的 Skills 梳理了一遍，发现它们基本可以归成九类。这个分类本身就很有参考价值，因为它相当于给你画了一张地图，告诉你 Skill 能用在哪些场景。
第一类是知识类，教 Claude 怎么正确使用某个库或工具。比如你们公司有个内部的计费库，各种边界情况和容易踩的坑，写成 Skill 之后 Claude 就不会再犯同样的错。
第二类是验证类，教 Claude 怎么测试和校验代码。Anthropic 的人特别强调这一类，说让一个工程师花一整周专门打磨验证类 Skill，绝对值得。他们甚至会让 Claude 把测试过程录成视频，这样你能看到它到底测了什么。这个思路挺有意思的，等于给 AI 的工作加了一层可追溯性。
第三类是数据类，连接你的数据源和监控系统。第四类是流程类，把重复性工作打包成一条命令。第五类是脚手架类，生成项目模板。第六类是代码审查类，保障代码质量。第七类是发布部署类。第八类是排查诊断类，从一个报错出发，走完整个排查流程，输出一份结构化的报告。第九类是运维类，处理日常维护。
这九个类型看下来，你会发现一个规律：它们覆盖了一个软件工程师日常工作的几乎所有环节。从写代码、测代码、查数据、做日报、部署上线、排查问题到日常运维，每个环节都能用 Skill 来提效。
这其实给了我们一个很好的思考框架。不管你是做什么工作的，都可以用类似的方式去梳理：我的日常工作有哪些环节？哪些环节是重复的？哪些环节容易出错？把这些环节整理出来，就是你应该优先做成自动化流程的地方。
3、写好一个 Skill 的关键：写 Claude 不知道的东西
这一条是整篇文章里我觉得最精辟的观点。
Claude 本身对编程已经很懂了，它有很多默认的偏好和习惯。如果你写的 Skill 只是在重复 Claude 已经知道的东西，那就是浪费。好的 Skill 应该聚焦在那些能把 Claude 从惯性思维里拽出来的信息上。
Anthropic 举了一个例子，他们有个前端设计的 Skill，专门用来纠正 Claude 的审美。因为 Claude 默认生成的前端页面总是那几个老套路：Inter 字体、紫色渐变。这个 Skill 就是通过反复跟客户迭代，把更好的设计品味“教”给了 Claude。
这个思路放到更广的场景里也成立。我们跟 AI 协作的时候，最有价值的输入往往是那些 AI 自己不容易想到的东西，比如你们团队独特的规范、行业里不成文的惯例、过去踩过的坑。这些东西才是你作为人类最不可替代的贡献。
4、踩坑清单才是一个 Skill 的灵魂
Anthropic 的人说，任何 Skill 里信息密度最高的部分就是踩坑清单，也就是 Gotchas。
这些内容应该从 Claude 使用你的 Skill 时反复犯的错误中积累起来。理想的做法是随着时间推移不断更新，Claude 每踩一个新坑，你就往清单里加一条。
这个做法特别实在。我们平时做项目也是一样，最宝贵的经验往往不是“怎么做对”，而是“怎么避免做错”。一个团队的核心竞争力，很大程度上就体现在他们踩过多少坑、记住了多少教训。把这些教训系统化地沉淀下来，就是在给团队建护城河。
5、给指令留灵活空间，别写成死板的操作手册
因为 Skill 是高度可复用的，所以你要注意别把指令写得太死。Claude 通常会严格遵循你的指令，如果你规定得太细，它在遇到稍微不同的情况时就会手足无措。
正确的做法是：给 Claude 它需要的信息，但也给它根据实际情况灵活应变的空间。
这跟管理团队是一个道理。好的管理者给方向和原则，差的管理者给步骤和流程。前者培养出能独立思考的人，后者培养出只会照本宣科的执行者。跟 AI 打交道也是如此，你越是把它当成一个有判断力的协作者来对待，它给你的产出就越好。
6、让 Skill 拥有记忆
有些 Skill 可以通过在内部存储数据来实现记忆功能。比如一个每天发站会汇报的 Skill，可以维护一个日志文件，记录每次生成的内容。这样下次运行时，Claude 读一下历史记录，就能知道跟昨天比有什么变化，只汇报增量。
这个设计很巧妙。它让 Skill 从一个无状态的工具变成了一个有上下文的助手。就像一个好的秘书，不只是帮你干活，还记得你之前干了什么，能帮你做前后对比和趋势分析。
7、给 Claude 现成的代码，而不是让它从头写
Anthropic 说，你能给 Claude 的最强大的工具就是代码。给它脚本和函数库，让它把精力花在组合和决策上，而不是重复造轮子。
比如你有一组从数据库取数据的函数，直接放到 Skill 里。当你问 Claude“周二发生了什么”的时候，它不需要从头写查询逻辑，直接调用你给的函数，把精力放在分析和组合上。
这其实揭示了一个更深层的道理：AI 最擅长的是组合和创造，最不擅长的是记住你们公司特有的那些细节。所以最高效的协作方式是你提供素材和工具，让 AI 来做组合和决策。
8、分享 Skill 的两种方式
小团队直接把 Skill 提交到代码仓库里就行，放在 .claude/skills 目录下。但随着团队变大，每多一个 Skill 都会给模型的上下文增加一点负担。这时候更好的方式是搭建一个内部的插件市场，让每个人自己决定装哪些。
Anthropic 内部的做法是让好的 Skill 自然浮现。有人做了一个觉得不错的 Skill，先放到 GitHub 的沙盒目录，在 Slack 里推荐一下。等用的人多了，再正式搬进市场。
他们特别提醒了一点：做出质量差或者重复的 Skill 太容易了，所以在正式发布前一定要有筛选机制。这跟任何工具生态的道理一样，数量不重要，质量才重要。
9、最后的感受
读完这篇文章，最大的感受是：Skill 这个东西的潜力远比大多数人想象的要大。
它表面上看是一个给 AI 写提示词的地方，但实际上它是一套完整的知识管理和流程自动化体系。你可以把团队的经验、规范、工具、流程全部沉淀进去，让 AI 成为一个真正了解你们团队的协作者，而不只是一个通用的聊天机器人。
Anthropic 自己内部有几百个 Skills 在运转，这个数字本身就说明了问题。当一个 AI 公司自己都在重度使用这套机制的时候，你就知道这东西是真的有用，不是花架子。
而且 Thariq 最后说了一句很实在的话：他们的大多数 Skill 一开始也就几行文字加一条踩坑提醒，后来是因为 Claude 不断遇到新的边界情况，大家才一点一点把它们完善起来的。
所以不用追求一步到位，先从最简单的开始，用起来，然后慢慢迭代。这可能是对待任何新工具最聪明的态度。
##