反对“技能”:为什么你精心构建的 AI 技能库可能正在拖累模型

原文:https://every.to/context-window/the-case-against-skills


信号

你的“技能”可能正在让 AI 变得更糟

也许是时候审视一下你那精心构建的技能库了。所谓技能(Skills),是一套可重复使用的指令包——有时也包含示例和工具——只要它们与你给 AI 下达的任务相关,就会被加载。它们的初衷是提升 AI 智能体的表现。这种由 Anthropic 推广的模式在 X 平台上随处可见,在那里,庞大且定制化的技能库被当作一种身份象征。

Every 的技术咨询主管迈克·泰勒认为,每一项技能都应该用它能提升产出的证据来证明自己在库中的价值。他的核心论点是:前沿模型已经足够聪明,它们自身已经吸收了社交媒体上流行的大多数技能所要达成的需求。如果一个模型能够自行推理出某个结果——而 Fable 5 或 GPT-5.6 很可能就能做到——那么添加额外的指令只会制造混乱,而非清晰的指引。“你强迫模型按照你的方式做事,而不是按照它被训练的方式,这实际上是在与模型自身的权重作斗争,”迈克说道。任何时候,只要你与模型的训练逻辑产生冲突,出错的概率就会变大。此外,加载技能所带来的所有额外文本都会推高成本。所以,你应该确保你选择的每一项技能都物有所值。

迈克指出,技能依然有其用武之地,但仅限于你需要模型以一种非常特定的方式完成工作流时。例如,生成一个遵循你品牌风格指南的自定义 PowerPoint 模板,或者引用公司内部的数据。迈克最近在测试 Fable 5 时发现,一些 Opus 4.8 为了避免出错而必需的技能,实际上却损害了更新模型的表现。这让他想起了自己在 2023 年做提示工程师时的经历:“用 GPT-3 的时候,我们得用各种技巧和魔咒来让它生成有效的代码。当 GPT-4 出来时,它的指令遵循能力更好了,我们的锦囊妙计就变得不再必要了。”

为什么这很重要:

数据也支持了他的观点。一项名为 SWE-Skills-Bench 的研究基准测试,旨在检验智能体技能是否能让智能体在软件工程领域表现得更好。它测试了 49 个公开的软件工程技能,结果发现其中 39 个对表现没有影响,还有 3 个甚至让事情变得更糟。与此同时,相当大比例的技能导致模型消耗了更多的算力,却没有改善结果——表现最差的技能甚至让 token 消耗量增加了 451%。

只有 7 个技能改善了产出。根据研究人员的说法,这些成功技能的共性是,它们都提供了模型自身无法提供的专业指导,比如金融风险公式或交通管理指令。

这意味着什么:

技能的实用性是有保质期的。那些为了修补模型盲区的指令,在新版本的模型吸收了相关能力的那一刻,就可能变得多余——甚至会产生反效果。真正长盛不衰的技能,是那些为模型提供了它不可能知道的、关于你业务或工作方式的信息——因为它不是公开信息:比如你对写作风格的个人偏好、一个特定的公司模板、内部公司数据,或者一套精确的操作步骤。当你使用别人制作的技能时,需要确保它们的作者会定期进行更新和修剪。

本周尝试:进行一次技能审计。
  • 保留那些提供私人上下文、自定义工具访问、个人偏好或特定公司工作流的技能——也就是公司外部人士无法知晓的事情。
  • 重新测试那些为了弥补当前模型的普遍弱点或怪癖而生的技能——随着模型改进,它们很可能会有保质期。
  • 淘汰那些无法明显改善结果的技能。你可以让你常用的 AI 智能体在有无该技能的情况下各运行一次你的提示词,然后比较结果。

借鉴这个工作流

评估你的技能,确保你得到了想要的结果

“写一大堆技能不仅仅是生产力表演——你实际上可能正在损害性能,”迈克说。“如果你想创建一项技能,那就证明它有效。”

以下是他的实践方法:

第一步:通过识别理想产出的示例,来定义你的技能应该达到什么目标。 当迈克构建他的自定义 PowerPoint 技能时,他从两个真实世界中的、由人类制作的优秀演示文稿示例开始,作为参考。这个数量最终扩展到了 15 到 20 个。“这个就是黄金数据集,”他说。

第二步:用黄金数据集来指导你如何创建和修改技能。 深入挖掘你喜欢这些数据集的哪些方面,以便将“好”的标准编码到技能的指令中。持续输入相同的内容,看看你对技能的修改是否让产出更接近黄金数据集。

第三步:通过一次只关注一个问题来自动化评估过程。 迈克的 PowerPoint 技能总是把字间距搞错,这促使他创建了一个大语言模型评判官——该评判官基于间距良好和间距糟糕的演示文稿示例进行训练——专门就这一个指标对结果进行打分。你能将基于主观感受的评估分解成越精细的、可量化的指标,就能把越多的工作委派给模型去完成。

第四步:进行一次基准测试。 在有无技能的情况下,给模型相同的输入,看看使用该技能是否能带来有意义的改变。


技能分享

让自动审查来为你赢得好结果

Monologue 的总经理纳文·奈杜对技能的使用非常克制,主要是在他希望 AI 遵循某个自定义工作流时才用。他说,许多他曾经封装成技能的通用指令——比如一条指定何时添加注释的指令——如今已不再需要,“因为模型已经变得非常好了。”

然而,有一个公开技能在他的配置中赢得了一席之地:OpenClaw 的 autoreview(自动审查)技能。它会在代码被合并前进行审查。这个由 OpenClaw 创始人彼得·斯坦伯格创建的技能,会收集智能体修改过的代码,并将其发送给另一个独立的模型进行审查(目前,默认的审查者是 Codex,在“高”性能模式下使用 GPT-5.6 Sol)。

纳文在一次 9 小时的通宵运行中,为 Monologue Notes 发布了一项新功能,该功能允许用户将转录内容标记为“工作”、“个人”或其他任何标签,而 autoreview 在其中发挥了关键作用。更准确地说,在纳文睡觉时,Fable 在 GPT-5.6 Sol 的协助下,为 Monologue 的后端、Mac 应用、iPhone 应用和 Web 应用构建了这个功能,而 autoreview 正是其中的关键一环。

当 Fable 完成代码的第一版后,它会运行 autoreview 技能。这个技能会把 Fable 的更改打包并交给 Codex,Codex 则会返回一个问题列表。Fable 会检查每一条评论,修复它认为相关的问题,然后在修订后的代码上再次运行 autoreview。这个过程在数小时内反复进行,直到 autoreview 再也找不出任何障碍。当纳文醒来时,一份拉取请求已经在那里等着他了。

这是他第一次在没有要求重大修改的情况下,直接合并了 AI 生成的代码。以前,他需要亲自审查代码。而有了 autoreview,“Codex 取代了我亲自找 bug 的工作,”这让纳文得以专注于测试功能,并确保它符合自己的品味。

你自己来试试:

在 Codex 中安装 autoreview:

git clone https://github.com/openclaw/agent-skills.git
cd agent-skills
scripts/install-skills --mode copy --target ~/.codex/skills autoreview

然后在 Codex 中打开编程项目并使用以下提示词:

Use the autoreview skill to review this branch against origin/main. Verify every finding against the code. Fix only problems introduced by this change, rerun the relevant tests, and repeat the review until there are no accepted, actionable findings. Stop and ask me before making any fix that would expand the original task.

(对于尚未提交的工作,请将第一句替换为:“Use the autoreview skill to review my uncommitted changes.”)


每内部视角

过上“后技能”时代的生活

增长负责人奥斯汀·特德斯科已经“完全抛弃了技能”,只有一个例外:复合工程。这是一个插件,它为 AI 智能体提供了可复用的工作流,用于规划、完成、审查以及从工作中学习。

在我们 All-Access 上线前夕,奥斯汀通过在 Codex 中将编程智能体指向包含相关背景信息的 Slack 消息,并利用复合工程来打磨文案和结构,基本上是一次就完成了一系列营销邮件。

[图片:向 Codex 指明相关上下文,并告诉它“就这么干”,是奥斯汀的必杀技。(截图由 Austin Tedesco 提供。)]


最后一件事

我们正在关注的事态

Thinking Machines 发布了其首款模型

这款名为 Inkling 的模型是开源的,其定位是在成本和开发者可下载并定制的灵活性上进行竞争。由前 OpenAI 首席技术官米拉·穆拉蒂领导的 Thinking Machines,正将自己定位为“美国制造”的替代品,以对抗那些来自中国、更具成本效益的开源模型,而不是前沿实验室的直接竞争对手。

OpenAI 正在开发一款 AI 伴侣

据彭博社的马克·古尔曼援引匿名消息源报道,这家前沿实验室的首款消费级设备将是一个无屏幕的智能音箱,充当一个类人的 AI 伴侣。该设备仍在开发中,它将使用更高级版本的 ChatGPT Voice Mode,能够执行管理智能家居设备、播放音乐、回答问题、处理邮件和短信等任务。

Siri 变好了

苹果的 iOS 27 测试版展示了其 AI 助手的一个全新改进版本。“我基本上被震撼了,”工程主管安德烈·加尔科表示。他发现 Siri 在语音识别方面比他在 iPhone 上试用过的任何其他本地模型都更出色、更聪明。“我认为苹果会做他们一直擅长的事:把好技术推向大众市场。”


核心启示:AI 技能的真正价值不在于通用技巧的堆砌,而在于提供模型无法从公开数据中学到的专有与个性化信息;随着模型进化,曾经必要的技能补救措施会迅速过时,甚至变得有害。

The Case Against Skills 的发芽报告

材料核心

Mike Taylor 提出一个反直觉的观点:随着大模型能力的提升,许多被热捧的 AI 技能包(Skills)正在从“性能增强器”变成“性能干扰器”。前沿模型已经内化了大量解决问题的能力,额外的指令反而会与模型训练权重冲突,增加错误率和计算成本。真正有价值的技能,是那些提供模型无法从公开数据中习得的私有信息——你的品牌指南、内部数据、工作流偏好,而不是试图“修正”模型通用能力的补丁。


发芽 01:当“最佳实践”比“模型本能”更糟糕

种子

材料揭示了一个根本性张力:人类试图通过外部指令控制 AI 的行为,但这些指令的质量永远滞后于模型自身进化的速度。这不仅仅是技能过时的问题,而是控制范式本身的局限性——我们试图用 2023 年的工程思维解决 2026 年的模型能力,就像是给一位大师级画家配了一本儿童简笔画教程。

故事:打字机时代的遗产

历史上有过一个精确的类比。19 世纪末,雷明顿公司为了推销打字机,设计了一个“科学化”的键盘布局:QWERTY。这个布局的逻辑不是提升打字速度,而是故意放慢打字员的手指,防止老式打字机连杆卡住。到了 1930 年代,德沃夏克(August Dvorak)博士发明了一种更符合人体工学的键盘,打字速度提升 30%,错误率降低 50%。美国海军在二战期间测试后发现,用德沃夏克键盘训练打字员的成本,10 天就能通过效率提升赚回来。

但 QWERTY 键盘没有消失。不是因为它的性能更好,而是因为它已经嵌入了整个系统——打字员的手指肌肉记忆、教材、考试标准、办公室文化。人类学会了服从工具的缺陷,而不是让工具服从人类的效率需求。

回到 AI 技能库的困境:2023 年,GPT-3 需要一系列“QWERTY 式”的提示词黑魔法——比如告诉模型“你是世界级的程序员”或者“深吸一口气再思考”——才能产出可用的代码。这些技能被封装、分享、积累,变成了社交媒体上的身份象征。但当 GPT-4 或 Fable 5 出现时,模型的“德沃夏克大脑”已经被训练好了,而人类还在强迫它回到 QWERTY 的节奏。

Mike Taylor 的发现——Opus 4.8 需要的技能反而损害了 Fable 5 的性能——就是这场冲突的临床诊断报告。SWE-Skills-Bench 的数据更冷酷:49 个公开技能中,39 个是噪音,3 个是毒素,只有 7 个是营养。

Aha 瞬间

"你正在和模型的权重搏斗,强迫它按你的方式而非它训练好方式工作——这场搏斗,你几乎不会赢。"


发芽 02:技能审计的真正对象不是技能,是人的执念

种子

材料建议进行技能审计,但这个审计的更深层对象不是技能本身,而是人类对“控制感”的执念。技能库的膨胀并不是因为模型需要它们,而是因为人类需要感觉到自己在“做工程”,需要可量化的生产力证明。这解释了为什么技能库在社交媒体上成为地位符号——它不是工具优化,是身份表演。

故事:谷歌的“OKR 泡沫”

1999 年,谷歌从英特尔引入了 OKR(目标与关键结果)管理系统。起初,这个系统帮助谷歌的工程师聚焦于可衡量的输出,推动了 Gmail、Chrome 等产品的诞生。但随着公司扩张,OKR 从“目标导航仪”变成了“官僚主义竞技场”。2010 年后,内部逐渐形成了一个被称为“OKR 泡沫”的文化:团队设定越来越多的目标,不是因为业务需要,而是因为在季度评审中,一长串完成的关键结果看起来更“专业”、更有“生产力”。

结果是目标通胀:人们花 30% 的时间写 OKR、汇报 OKR、review OKR,而真正推动产品的精力被压缩。直到 2018 年谷歌内部改革,砍掉了大量冗余的目标设定流程,团队才重新获得喘息空间。

AI 技能库的膨胀走的是同样的路。创建技能的成本很低——写一段指令,打包,分享——而展示一个庞大的技能库带来的社交回报很高。这就形成了一个“技能通胀”回馈循环:人们创建技能不是为了提升模型输出质量,而是为了展示自己“掌握了 AI 工程”。SWE-Skills-Bench 的数据戳破这个泡沫:大部分技能的作用是让人类感到忙碌,而不是让 AI 变得更聪明。

Naveen Naidu 的坦白是清醒的——“以前要封装成技能的通用指令现在不需要了,因为模型本身足够好”。这是技能脱瘾的典型症状,就像谷歌员工发现砍掉三分之二的 OKR 后,产品反而交付得更快。

Aha 瞬间

"技能库的规模不是你的 AI 成熟度的衡量标准——它是一个反向指标,暴露你对模型能力的信任赤字。"


发芽 03:真正持久的技能是“你口袋里的秘密”

种子

材料划出了一条清晰的分界线:持久技能的共性不是“指令的巧妙”,而是“信息的排他性”——品牌指南、内部数据、个人品味、公司工作流,这些都是模型无法从公开互联网习得的东西。这背后隐藏着一个更底层的原则:AI 技能的价值函数已经从“你做不好这个,让我教你”转变为“你知道不了这个,让我告诉你”

故事:中世纪的“行会秘密”

14 世纪的佛罗伦萨,毛纺织业的行会(Arte della Lana)掌握着整个欧洲最高端的染色技术。行会不靠“一般性知识”维持垄断——如何纺织、如何处理羊毛的通用原理,任何有经验的工匠都能掌握。让行会不可替代的,是它的“秘密配方”:特定产地的明矾矿来源、传承三代的温度控制手感、只在特定季节采摘的植物染料。

这些秘密不是写在公共教科书里的“技能”,而是嵌入特定情境、特定人际关系、特定地理位置的隐性知识。行会从不担心德国或法国的工匠“学会纺织”,因为通用技能可以复制,但排他性信息不能。

AI 时代的“行会秘密”是 Austin Tedesco 在 Codex 中的操作:他不是写一个“邮件营销技能”,而是把 Slack 消息中的上下文直接喂给模型,用复合工程(compound engineering)这一条私有工作流来驱动输出。那条 Slack 对话里的语气、预算讨论、产品定位、团队共识——这些是模型无法从参数中重建的“特定产地的明矾矿”。

Mike 的 PowerPoint 技能持久,不是因为它知道“怎么排版”,而是因为它知道 Mike 公司的品牌指南——那个具体的主色调色号,那个老板偏爱的字体间距。SWE-Skills-Bench 中那 7 个有效的技能,提供的都是领域特定的、非公开的专业指导(金融风险公式、交通管理指令)。

Aha 瞬间

"通用的技能是 7-11 便利店——方便,但随时可替代。排他的技能是你家厨房的香料柜——别人无法复制,因为那是你几十年来积累的独门配方。"


你的思考空间

  • 如果你的技能库里 80% 的技能在下一个模型版本中失效,你真正需要保留的 20% 是什么?它们之间的共同特征能否提炼为一条“技能设计原则”?

  • 当技能证明自己的方式从“提升模型性能”变成了“提供模型缺失的信息”,这是否意味着 AI 产品经理和传统软件产品经理的技能树将彻底分化?

  • 材料中提到技能审核的自动化(用 LLM 判断输出质量),但如果 AI 已经在某些领域超越人类评价能力,我们如何避免陷入“用有缺陷的模型去评价另一个模型”的递归陷阱?

  • “技能通胀”本质上是人类在 AI 时代对“生产力表演”的需求——如果组织内部根本无法区分“真正有用的技能”和“地位展示的技能”,管理者应该用什么指标来判断团队的 AI 成熟度?