最近读到 Anthropic 公司 Claude Code 团队分享的一篇文章,讲的是他们在内部使用”技能”(Skills)的经验。读完之后觉得挺有意思,里面有不少思路和做事的方法论值得我们学习。我试着用大白话把他们的核心观点捋一捋。
简单来说,技能就是一套预先写好的指令,告诉 AI 在某个具体场景下应该怎么做。你可以把它想象成一本操作手册,AI 拿到这本手册之后,遇到对应的问题就知道该怎么处理了。
Claude Code 团队把他们内部积累的所有技能做了一次大盘点,发现这些技能大概可以分成九大类:
第一类是库和 API 参考,就是教 AI 怎么正确使用某个工具或者开发包,特别是那些容易踩坑的地方。第二类是产品验证,教 AI 怎么去测试代码有没有问题,比如模拟用户注册流程看看能不能跑通。第三类是数据获取和分析,帮 AI 连上各种数据源去查数据。第四类是业务流程自动化,把那些每天都要重复做的事情打包成一个命令。第五类是代码脚手架和模板,快速生成一个新项目的基本骨架。第六类是代码质量和审查,帮你检查代码写得好不好。第七类是 CI/CD 和部署,管理代码从写完到上线的整个流程。第八类是运维手册,出了故障按照步骤一步步排查。第九类是基础设施运维,做一些日常的清理和维护工作。
这个分类本身就挺有启发的。不管你做什么工作,其实都可以试着把自己日常的任务做一个类似的梳理。哪些是重复性的?哪些是容易出错的?哪些是每次都要从头来的?梳理清楚之后,你就知道哪些地方值得花时间去建立一套标准化的流程。
文章里有一个观点让我印象特别深:他们说在所有类型的技能里,验证类技能对 AI 输出质量的提升最明显,值得让一个工程师花一整周的时间专门去打磨。
什么意思呢?就是说,与其花大量时间教 AI 怎么写代码,不如花时间教它怎么检查自己写的代码对不对。比如让 AI 录一段它测试过程的视频,这样你就能看到它到底验证了什么;或者在每一步都加上程序化的断言,确保状态是对的。
这个思路放到我们日常生活里也成立。很多时候我们做一件事,花了大量精力在”做”上面,却很少花时间在”验证”上面。写完一篇文章不检查就发出去,做完一个方案不复盘就进入下一个。其实建立一套好的验证机制,往往比提升执行速度更能提高最终的质量。
他们给出的第一条写技能的建议就是:别说显而易见的东西。Claude 本身就会写代码,也能读懂你的代码库。如果你写的技能只是在重复 AI 本来就会做的事情,那就是在浪费上下文空间,没有任何增量价值。
真正有用的是那些能把 AI 从它的惯性思维里拉出来的信息。比如他们举了一个前端设计技能的例子,这个技能是专门用来纠正 AI 的”审美默认值”的,避免它总是用 Inter 字体加紫色渐变这种千篇一律的风格。
这一点对我们写任何形式的说明文档都有参考意义。写给别人看的东西,不要把对方已经知道的事情再说一遍,要把精力放在那些对方容易忽略或者容易搞错的地方。
文章里反复强调,一个技能里面最有价值的部分就是”踩坑记录”(Gotchas)。这些记录应该来自 AI 在实际使用中反复犯的错误,而且要随着时间不断补充。
他们举了几个例子:比如”subscriptions 这张表是只追加的,你要找的是版本号最高的那一行,不是创建时间最新的那一行”;再比如”这个字段在 API 网关里叫 request_id,在计费服务里叫 trace_id,其实是同一个值”。
这种东西看起来很琐碎,但恰恰是最能防止出错的。我们平时工作中其实也可以养成这个习惯,把自己踩过的坑、犯过的错记下来,形成一个持续更新的清单。时间长了,这份清单就是你最宝贵的经验资产。新人来了看一遍,能少走很多弯路。
他们提出了一个叫”渐进式信息披露”的概念。意思是,不要把所有信息都堆在一个文件里,而是把详细的参考资料、API 文档、示例代码分别放在不同的子文件里。主文件只告诉 AI 有哪些子文件可以参考,AI 需要的时候自己去读。
这样做的好处是避免信息过载。AI 的上下文窗口是有限的,一次性塞太多东西进去,反而会影响它的判断。
这个道理放到我们组织知识的方式上也一样。不管是写笔记、做文档还是搭建知识库,都应该有层次感。最上面是概览和索引,往下才是具体的细节。需要的时候再深入,不需要的时候保持简洁。
他们说,Claude 通常会严格遵守你给它的指令,所以如果你把指令写得太死板、太具体,它就会在不该死板的时候也死板。正确的做法是给它足够的信息,但同时留出灵活应变的空间。
这其实跟管理团队是一个道理。好的管理者会告诉下属目标是什么、边界在哪里、有哪些注意事项,但不会规定每一步具体怎么走。过度控制反而会扼杀创造力和应变能力。
他们提到一个很巧妙的做法:给技能加上记忆功能。最简单的方式就是用一个日志文件,每次执行完就把结果追加进去。这样下次再运行同一个技能的时候,AI 可以读到自己之前做过什么,就能知道哪些变了、哪些没变。
比如一个写每日站会报告的技能,如果它能看到昨天写的内容,今天就能自动对比出变化,而不是每次都从零开始。
这个思路对我们个人也很有用。做任何重复性的工作,都值得留下记录。不只是为了备忘,更是为了让每一次执行都能在上一次的基础上改进。
文章里还有一个很重要的观点:与其写一大堆文字告诉 AI 该怎么做,不如直接给它现成的脚本和工具函数。这样 AI 就可以把精力花在”决定做什么”和”怎么组合”上面,而不是每次都从头写重复的代码。
换句话说,把基础能力封装好,让 AI 专注于更高层次的思考和决策。这跟我们日常工作中”把重复劳动自动化,把精力留给创造性工作”是完全一样的逻辑。
还有一个容易被忽略的细节:技能的描述文字,目的是让 AI 判断什么时候该触发这个技能,所以要写得像触发条件一样精准,而不是写成给人看的摘要。
这提醒我们,在设计任何自动化系统的时候,都要站在”执行者”的角度去想:它需要什么信息才能做出正确的判断?而不是站在”观察者”的角度写一段好看的介绍。
文章最后说了一句很实在的话:他们最好的技能,大多是从几行简单的指令和一条踩坑记录开始的,然后随着 AI 不断遇到新的边界情况,一点一点补充完善起来的。
没有人能一开始就写出完美的技能。重要的是先动手,先有一个最小可用的版本,然后在实际使用中不断打磨。这个道理适用于几乎所有事情。别等到想清楚了再开始,先开始,再想清楚。
关于怎么把好的技能分享给团队,他们的做法也很值得参考。小团队直接把技能放在代码仓库里,大家都能看到。团队规模大了之后,就搞一个内部的技能市场,让每个人自己选择安装哪些。
他们没有设一个专门的委员会来审批哪些技能可以上架。而是让技能自然生长,谁觉得自己的技能好用,就先放到一个试用区让同事们试试,等到确实有人在用了,再正式上架。他们还会用钩子来统计每个技能的使用频率,看看哪些受欢迎,哪些没人用。
这种自下而上、用数据说话的管理方式,比自上而下的审批制度要高效得多。好东西自己会说话,让它在真实环境里被检验,比任何评审流程都靠谱。