Agent Skills用错比不用更坑，这份自救指南请收好
Agent Skills被大量滥用，最典型错误是让不会解决问题的Agent凭空生成技能文档。正确用法是从实战问题中提取知识缺口补成Skills，或把高频重复动作封装成Skills。
Claude Code这个生态圈乱得像菜市场，命名规则天天变，更新速度快到离谱。但其中被玩坏最惨的就是Skills。我上班天天看同事用错，然后HN上又蹦出篇论文说自生成的Agent Skills没用。我看完直接坐不住了，因为我自己用Agent写的Skills明明香得不行。论文里那个所谓自生成，其实就是让模型先写一堆废话再去做题，这不就是换皮版的思考块么。今天我就来好好掰扯这玩意儿到底该怎么用。
论文里那个测试方法直接把我看笑了
SkillsBench这篇论文搞了86个任务横跨11个领域，还整了7种Agent配置跑了七千多条轨迹。他们说精心设计的Skills能把通过率拉高16.2个百分点，医疗领域甚至能飙到51.9个百分点，听着挺唬人对吧。但软件工程这边就惨了，只有4.5个百分点，还有16个任务用了Skills反而更差了。
看到自生成Skills那块我直接笑出声。他们所谓的自生成Skills，就是不给任何参考资料，直接让Agent在解题前先写一通相关知识。这不就是让一个本来就不会做这道题的人，先写一遍解题思路然后再去解题吗。那他能写出来个啥啊，他脑子里本来就没货，强行挤出来一堆废话有个毛用。
我就好奇了，这跟思维链或者思考块有什么区别。你让模型先想一遍再回答，它本来就会那么干，只不过现在把中间过程单独拎出来存成个文件，还非得叫Skills。这不是脱裤子放屁多此一举吗。怪不得他们测出来自生成Skills平均下来屁用没有，这结果不是明摆着的嘛。
他们要是把这玩意儿真当成Skill来用，那只能说研究设计本身就有问题。真正好用的Skills得从实践中长出来，不是让模型对着空气瞎编就能搞定的。就像你让一个从没做过饭的人写菜谱，他能写出个啥，顶多就是百度一下抄一抄。
反模式就是让不会的Agent教自己怎么变会
我天天看同事犯这个毛病，Agent搞不定某个任务，他第一反应就是让同一个Agent写个Skill教自己怎么搞定。这不就是让学渣写学习指南给学渣自己看吗。他本来就不会，你逼他写出来的东西能有个鬼用。
这就跟大学里那些小组作业一样，组里没人会做，然后大家一合计说我们写个分工方案吧。写来写去不就是把没人会做的事情强行分给几个人，最后交出来的东西还是一坨翔。你指望一个不会的人写出来的教程能教会另一个不会的人，这不是开玩笑吗。
真正的问题在于Agent看不到自己的知识缺口在哪。它不知道什么信息对它来说是缺失的，所以它写出来的东西要么是废话，要么就是它已经知道的东西。这跟编程入门课那个经典案例一模一样，让学生写怎么做花生酱果酱三明治，你只有真正动手做过才知道坑在哪。
你让Agent自己凭空生成Skills，它压根没踩过坑没遇到过障碍，它能写出个啥有用的东西来。顶多就是把它训练数据里的通用知识抄一遍，这些玩意儿对你具体项目有个蛋用。所以别偷懒了，别想着让Agent自己教自己，它没那个本事。
Skills到底是个啥玩意儿
先别急着用，咱们搞清楚这东西到底长啥样。Skills本质上就是一些Markdown文件，顶部带点元数据告诉Agent什么时候该用它，剩下的内容就是具体的技能说明。每个技能独占一个文件夹，不仅能教Agent怎么做，还能给它配更好的工具。
我举个例子你们就明白了。我之前写了个监控GitLab CI的Skill，文件夹结构是这样的：
.claude/skills/ |
SKILL.md里写清楚了这个项目的测试环境怎么搭，Agent需要盯着CI跑直到成功或者失败。那个monitor_ci.sh是个简单脚本，省得Agent每次自己写代码去轮询API。references文件夹里还放了各种边缘情况的处理方案。
这么一搞，Claude再碰上GitLab CI的任务就知道该怎么弄了，不用每次都重新摸索一遍。而且有了那个脚本，它就不需要自己瞎写一堆监控代码，直接用现成的就行。
Skills能补上Agent失忆的坑
Agent这玩意儿是完全无状态的，每次新开对话都像是第一次见到你和你的项目。你十分钟前跟它聊了啥，它转头就忘得一干二净。CLAUDE.md能解决一部分问题，但项目一大起来那文件根本就装不下所有东西。
我要是打开一个巨型代码仓库，然后让Claude去跑个SIL测试，它就懵了。它得先搞清楚这项目用的啥编程语言，然后去找那个语言常见的测试套路，接着看到一堆复杂的Docker Compose配置，再发现容器要x86架构但我Mac是ARM的，还得去翻CI配置看人家怎么解决的。
这一通操作下来光token费就能干掉我几十块钱，还容易跑偏。但要是事先给它写个测试相关的Skill，告诉它这个项目的测试环境怎么搞，那些坑在哪，它一次就能搞定。
你只要在项目里发现某个事情Agent做得特别费劲，但你自己知道其实挺简单挺基础的，那就让它把缺的知识点做成一个Skill。下次再来就顺了。
重复劳动就应该交给Skills去记
还有个贼简单的用法，就是把你经常让Agent干的事情写成Skills。我总让Agent帮我检查文档、MR描述、Issue和代码库这四样东西是不是对齐的。每次都要敲一大段话跟它说检查这个检查那个，烦得要死。
后来我干脆写了个简单的Skill，叫它"对齐检查"。现在我就说一句"跑一下对齐检查"，它就自己把那一套流程全走完了。省下来的时间够我喝杯咖啡摸会儿鱼了。
你想啊，那些你每周都要让Agent干三五次的事情，每次都要重新描述一遍需求，这效率低得令人发指。写个Skill存着，下次直接叫名字就行。就像你给常用联系人设了个快捷拨号，不用每次都翻通讯录找号码。
硬骨头让Agent啃完再总结成Skills
Claude确实能解决一些特别难的问题，但代价可能是烧掉你五百美金的token，期间你还得吼它好几次别搞奖励黑客那一套。基本上只要我不得不出手干预的问题，等Agent被救回来之后，我都会问它刚才卡在哪了。
有时候答案是些特别蠢的东西，比如忘了导入某个库。但有时候它给出的解释真能让我眼前一亮，原来有个细节我一直没注意到。这种时候我就会让Claude把那个知识缺口写成Skill，下次再碰上类似的问题它自己就能搞定。
我有个项目里Claude老是搞不定一个复杂的权限校验逻辑，绕来绕去就是过不去。后来我发现它不知道那个权限系统的设计文档在哪里，每次都要去翻代码猜规则。我把那个设计文档的关键信息抽出来做成一个Skill，从此它再也没在这上面翻过车。
这招最好用的地方在于，Agent帮你把那个知识盲区给定位出来了，然后你再让它自己填上这个坑。这就不是让它教自己不会的东西，而是让它把刚学会的东西记下来。
我按自己的玩法测了一遍效果拔群
论文那套方法我看着就来气，干脆自己重新跑了一遍测试。我把流程改成先让Agent去解决任务，解决过程中遇到障碍了就记下来，最后根据这些障碍记录生成Skills。然后带着这些Skills再跑一遍同样的任务。
结果跟我预想的一模一样，有了实战经验的Agent带着Skills上场，表现直接起飞。虽然我钱不够把全部86个任务都跑完，但第一批结果已经足够说明问题了。那些在论文里用通用Skills表现拉胯的任务，换成我这种从实践里长出来的Skills，通过率蹭蹭往上蹿。
其实我这么做相当于把整个测试的数据集规模翻了一倍。先跑一遍收集障碍点，再跑一遍验证Skills效果。论文作者们不这么干我猜要么是经费不够，要么是没想过这个方法。但我觉得这才是Skills的正确打开方式。
你得先让Agent去撞墙，撞完了才知道墙在哪，然后再给它把墙拆了。你要是连墙在哪都不知道就让它凭空写攻略，那不是搞笑么。
别让Agent凭空编Skill浪费大家时间
现在AI圈有个最大的忌讳，就是别人问你个问题，你当场开个新会话让LLM生成答案，然后直接把输出贴过去当自己的回复。这行为low穿地心。要是有人问我怎么用Agent搞了个酷炫的东西，然后他当场让他的Agent给我生成一个SKILL.md，我真的会想打人。
这种行为跟Skills滥用是一个毛病。你不去实际解决问题，光想着让模型凭空生成点东西糊弄过去。Skill不是这么用的，它是用来记经验的，不是用来编经验的。
你要真想做出有价值的Skills，就得让Agent经历真实的解决问题的过程。让它在你的项目里摸爬滚打，碰壁了找原因，搞定了记下来。这样沉淀下来的东西才值钱。
到底什么时候该让Agent写Skill
总结一下，只有两种情况值得写Skill。第一种是记住新问题，就是那些Agent第一次遇到搞不定，你帮它搞定之后它学到的新东西。第二种是避免重复劳动，就是那些你老让Agent干的破事，写成Skill以后一键调用。
你要做的就是开个新会话，让Agent去解决你的真实问题。等它解决完了，问问它过程中缺了啥信息，卡在哪了，然后把那些缺口补上做成Skill。或者你在日常工作中发现某个流程老是要让Agent做，就直接把它封装成Skill。
千万别搞那种开个新会话直接说"给我写个关于X的Skill"，这种操作基本没价值。Agent不知道你的项目具体啥样，不知道那些隐形的坑在哪，写出来的东西要么太空泛要么就是错的。
真正的Skill得长在你的项目土壤里，从实际问题中冒出来。就像学游泳得下水扑腾几回才能学会，你在岸上看再多教学视频一下水还是得呛。让Agent先去游，呛几口水了就知道该学啥了。
总结：Skills是记经验的工具不是瞎编经验的工具。让Agent先解决真问题再补缺口，或把常干的事存成快捷方式。别开新会话让它凭空编Skill。