上个月我写过一篇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再有价值，如果它不能在正确的场景里被调出来，效果还是会打折。
Description写得好不好，直接决定了这个Skill会不会在该出现的时候出现。
好的description应该像一个精准的if条件：
当用户需要翻译英文文档（PDF/DOCX/EPUB/网页文章）为中文，包括学术论文、书籍、长文翻译、术语密集型内容时触发。不适用于日常短句翻译或口语化翻译。
第三：让Skill自己记住上次干了什么
这也是Thariq那条推里我觉得最被低估的一点：Skill可以有自己的记忆。
最简单的做法：就是在Skill目录下放一个日志文件，每次执行完往里面追加一条记录。下次执行的时候，AI先读一遍日志，就知道上次做了什么。
第四：Skill的威力不在那份markdown，在于整个文件夹
一份markdown写得再好，能承载的东西也有限。你没法在一段文字描述里把一个查询逻辑说清楚，也没法用文字精确定义一份报告该长什么样。
Thariq举了个例子。假设你做数据分析，经常需要从公司的事件系统里拉数据。每次你都要告诉AI：”先连这个数据库，用这个查询语句，然后按这个格式输出。”累不累？累。而且AI每次重新写查询，写出来的还不一定对。
但如果你把这些操作封装成几个Python函数，放在Skill的scripts/目录下。那AI在执行的时候就不需要从头写查询逻辑了。它只需要决定：先调哪个函数、传什么参数、结果怎么组合。
第五：但只有能力还不够，还要有边界和护栏
Thariq提到，Claude Code的Skill可以注册”on-demand hooks”，也就是临时钩子。这些钩子只在Skill被激活的时候生效，Skill结束就自动关闭。
比如你有一个叫/careful的Skill。激活之后，它会挂一个PreToolUse钩子，拦截所有危险操作：rm-rf、DROP TABLE、force-push、kubectl delete。你碰生产环境的时候开一下，它就像一个安全锁，AI想执行危险命令的时候会被拦住。
写Skill的正确顺序
- 第一步，别急着写说明书。先列出你们团队在这类任务上踩过的10个最大的坑，写进Gotchas。
- 第二步，把description当触发条件写，而不是当简介写。想清楚这个Skill该在什么场景下被自动调出来，什么场景下不该出现。
- 第三步，给脚本、给模板、给参考代码，而不只是给文字。让AI把精力花在判断和组合上，而不是花在重建轮子上。
- 第四步，加记忆。哪怕只是一个日志文件，让Skill知道上次做了什么，这次该做什么不一样的。
- 第五步，加护栏。不光告诉AI该做什么，还要告诉它什么绝对不能做。
模型决定AI能想多远。Skill决定AI能干多稳。而Skill的质量，取决于你往里面装了多少只有你才知道的东西。
来源：虎嗅
