上个月我写过一篇Skill的实测文章，从翻译两本书的实战出发，讲了”做完打包”这件事有多重要。
但依旧有小伙伴反馈，”我写出来的Skill就是不好使”。
说实话，这个问题我自己也遇到过。有的Skill写完就是越用越顺，有的怎么调都差点意思，一直说不上来到底差在哪。
3月18日，Anthropic工程师Thariq发了一条长推，标题就叫《Lessons from Building Claude Code: How We Use Skills》。他们内部已经有数百个Skill在活跃使用，踩过的坑和总结出来的经验，终于公开讲了一次。
我看完之后有一个很大的触动。不是某个具体技巧，而是让我意识到，大部分写Skill的时候，写进去的东西压根就不是AI需要你告诉它的。
第一：Anthropic内部最看重的，是”坑”
那应该写什么？
Thariq在推文里说了一句话，我觉得含金量很高：”一个Skill里信息密度最高的部分是坑点总结。”
因为Claude本身已经知道很多东西了。你写一个Skill告诉它”这个SDK的init方法接收三个参数”，大概率它已经知道了，这种信息它在预训练数据里见过无数遍。
但如果你告诉它：”我们这个审批流程，文档里标的是可选，但实际上必须走。不走这一步，后面的权限审核会直接卡住。”——这种信息它查遍全网也查不到。因为这根本就是你们自己定的规矩，不在任何公开文档里。
这就是坑。这就是高语境知识。
第二：Description字段非常重要
只把经验写进去还不够。一个Skill再有价值，如果它不能在正确的场景里被调出来，效果还是会打折。
这也是为什么Thariq特别强调：description字段非常重要。
很多人写Skill，花了很多心思在正文内容上。流程写得很详细，步骤列得很清楚，参考文档也附上了。但description字段随手写了一句”这是一个翻译工具”就完事了。
问题是，description字段不是给人看的摘要，是给模型看的触发条件。Claude Code启动的时候，会扫描所有可用的Skill，读的就是这个，然后根据用户当前的请求，判断要不要激活某个Skill。
第三：让Skill自己记住上次干了什么
不过，能在对的时候被触发，仍然只是第一步。
一个助手真正开始”顺手”，不只是因为它知道你们怎么做事，还因为它记得上一次已经做到哪一步。
这也是Thariq那条推里我觉得最被低估的一点：Skill可以有自己的记忆。
第四：Skill的威力不在那份markdown，在于整个文件夹
这一条是我自己体会最深的。
你用过一段时间Skill就会发现，一份markdown写得再好，能承载的东西也有限。你没法在一段文字描述里把一个查询逻辑说清楚，也没法用文字精确定义一份报告该长什么样。
第五：但只有能力还不够，还要有边界和护栏
不过，一个真正可用的工作环境，不能只有能力，没有约束。
如果scripts、模板、参考代码解决的是”AI能不能做”，那钩子机制解决的就是”AI会不会乱做”。
Thariq提到，Claude Code的Skill可以注册”on-demand hooks”，也就是临时钩子。这些钩子只在Skill被激活的时候生效，Skill结束就自动关闭。
回到最初的问题：为什么你的Skill不好使？
把Thariq的经验总结和高低语境的框架放在一起，答案其实很清楚了。
不好用的Skill，写的是低语境信息。功能介绍、API文档、操作步骤。这些东西模型本来就知道，你多写一遍它也不会做得更好。
真正让Skill好使的，是高语境信息：你们团队特有的坑、你们自己的验收标准、那些”做久了就知道”的默认规则、”这个命令千万别在生产环境跑”之类的护栏。
来源：虎嗅
