本文作者：Gorden Sun（@Gorden_Sun）。版权归作者所有，未经授权禁止转载。
现在有一种新型炫富：晒自己的skill库。几十个精心编写的skill整整齐齐码在文件夹里，像手办墙一样供人参观，评论区一片"求分享"。攒skill成了一种身份象征，仿佛库越大，你就越懂AI。
实际上，现在你库里的大部分skill，八成没用，有些还在帮倒忙。
有个叫SWE-Skills-Bench的基准测试，专门测skill到底能不能让agent写代码写得更好。研究人员拿49个公开的软件工程skill挨个试了一遍，结果是：39个对性能没有任何影响，3个反而让结果变差了。真正带来提升的只有7个。但成本却实打实的提升了：一大批skill什么忙都没帮上，却让模型烧掉了更多算力，最离谱的一个把token消耗抬高了451%。
你花一晚上写的skill，很可能就是在花钱买寂寞。
为什么会这样？
因为前沿模型已经强到把流行的skill内容全都"吃"进训练里了。Fable 5、GPT-5.6这个级别的模型，靠自己就能推理出这些东西。你再往上叠一层指令，等于逼着一个已经会开车的老司机按你手写的驾驶手册开车。
"你在跟模型的权重较劲，强迫它按你的方式做事，而它本来被训练成另一种做法。"每一次这种较劲，都在增加模型犯错的概率。
一些测试案例发现，Opus 4.8时代必须靠skill才能避免的错误，到了新Fable 5这里，同样的skill反倒把表现拉低了。这让人想起2023年当prompt工程师的日子：那会儿伺候GPT 3.5得念咒语、用各种黑话hack，才能哄它吐出能运行的代码。GPT 4一出来，指令跟随能力上了台阶，prompt小技巧一夜之间变成了废纸。
Skill也一样，它是有保质期的。你写的每一条指令，本质上都在给模型的某个盲区打补丁。可模型每升级一次，就有一批盲区自己愈合了，那些补丁就从药变成了毒。
那什么skill值得留？
答案很简单：模型不可能知道的东西。
你公司的品牌规范和PPT模板、内部数据、你个人的写作口味、一套只在你们团队内部流转的工作流程。这些信息不在公网上，模型再聪明也猜不出来，skill在这里才有存在的价值。SWE-Skills-Bench里那7个有效的skill，恰好也印证了这一点：它们提供的都是模型自己给不出的专业指引，比如金融风险的计算公式、交通管理的具体规则。
Monologue的总经理Naveen Naidu有好例子。他现在用skill用得很克制，很多以前打包成skill的通用指令（比如什么时候该加注释）早就删了，理由就一句话："因为模型变得太好了。"但有一个公开skill在他的工具箱里站稳了脚跟：OpenClaw的autoreview，作用是在代码合并前把agent改动的部分打包，丢给另一个模型做审查。
这个skill帮他干成了一件挺科幻的事。某天晚上他给Fable布置了一个新功能，涉及Monologue的后端、Mac应用、iPhone应用和网页端四个板块，然后就去睡觉了。Fable写完第一版代码后跑autoreview，把改动交给Codex审查，Codex返回一串问题清单，Fable逐条核对、修掉认为合理的部分，再跑一遍审查。如此循环了几个小时，直到Codex挑不出毛病为止。九个小时后Naveen醒来，一个pull request安安静静躺在那里等他。这是他第一次合并AI生成的代码时没有先要求大改。他的总结是，"Codex取代了我自己去找bug"，他只需要测试功能、把关品味。
我的建议
所以我的建议是：给你的skill库做一次审查。
- 提供私有上下文、公司模板、个人口味的skill，留下。
- 用来弥补模型通病的skill，重新测一遍，它们多半正在过期的路上。
- 剩下那些说不清到底有没有用的，让AI拿同一个任务跑两遍，一次带skill一次不带，对比结果，没有显著提升效果的可以大胆删掉。
写Skill越来越像是“表演式生产力”，该删就删。就像以前的提示词工程、MCP一样，Skill也会逐渐退出主要舞台。顺便提一下，现阶段新兴的工程是Loop Engineering，不过这个概念复杂，我建议咱们普通人坐等模型和Harness升级即可。
以上，我是Gorden，X上5万粉丝的AI博主（ID：Gorden_Sun），如果你想加入我的微信交流群（免费）、或者有其他问题，可以加群或者加我微信。
