Every 的新提醒：AI skills 不是越多越好
Every 这篇 7 月 16 日文章提醒：skills 只有在补充私有上下文或固定工作流时才值得长期保留，通用能力补丁必须用结果和成本反复验证。
Skills 先解决「模型不知道什么」
Every 7 月 16 日发表的文章《The Case Against Skills》，把矛头对准了 AI 使用中的一个流行习惯：给代理堆一层又一层 skills。Every 把 skill 定义为一组会在相关任务中加载的可复用指令，有时还包括示例和工具。它们原本是为了让模型做得更好，但文章的结论很克制：如果模型已经会做这件事，额外指令可能只会增加干扰和成本。1
Every 的技术咨询负责人 Mike Taylor 主张，每个 skill 都应该拿出结果证明自己值得留在库里。文章提到，他测试 Fable 5 时发现，一些曾经帮助 Opus 4.8 避免错误的 skills，放到更新的模型上反而伤害了表现。原因不难理解：模型能力变了，旧的提示技巧可能从补充信息变成了与模型既有判断冲突的额外约束。1
一项基准测试给出的警告
Every 引用的 SWE-Skills-Bench 研究，专门比较了有无 skill 注入时软件工程代理的表现。研究把 49 个公开软件工程 skills 与真实 GitHub 仓库、固定版本代码和带验收标准的任务配对，覆盖约 565 个任务实例和六个软件工程子领域。2
结果并不支持「skill 越多，代理越强」：
- 49 个 skills 中有 39 个没有带来通过率提升，平均提升只有 1.2%。
- 只有 7 个专业化 skill 带来有意义的收益，最高提升 30%；另有 3 个让表现下降，最高下降 10%。
- token 开销从略有节省到增加 451% 不等，最坏的情况是在通过率没有变化时消耗更多 token。2
这项研究测的是软件工程任务，不能直接推出所有领域的 skill 都无效。它更准确的含义是：skill 的价值必须落到具体任务、具体模型和具体验收结果上，不能拿「看起来专业」代替测试。
什么样的 skill 更可能留下来
文章给出的分界线很实用：模型不可能凭空知道的内容，才值得长期写进 skill。比如公司的内部资料、品牌规范、个人写作偏好、定制工具权限，或者一套必须按固定顺序执行的工作流。它们不是在教模型一个通用技巧，而是在补充任务所需的私有上下文。1
相反，专门弥补某个通用模型弱点的 skill 需要定期重测。模型升级后，它可能已经不需要这层帮助，甚至会被旧规则带偏。Every 的建议可以直接变成一张清单：
- 保留：提供私有上下文、定制工具、个人品味或公司专属流程的 skills。
- 重测：用来修补当前模型通用能力缺口的 skills，每次换模型都重新比较有无它的结果。
- 退出：没有稳定改善结果的 skills。可以用同一个 prompt 分别运行两次，再比较输出质量、通过率和 token 消耗。
Every 正在把「会用 AI」改写成「会验证 AI」
这篇文章没有推出一个新产品，它在处理的是 Every 自己的生产方法：不要把配置文件的数量当成能力，把模型生成的结果放回任务目标和验收标准里检查。对正在搭建 AI 工作流的团队来说，真正需要管理的不是一座越来越大的 skill 图书馆，而是一组经过验证、知道何时失效的工作规则。
这也给「AI 原生公司」一个更具体的观察角度。工作流的竞争力不只来自有没有把模型接进来，还来自团队能不能识别哪些指令是自己的知识，哪些只是过时的模型补丁。前者会沉淀成组织资产，后者应该随着模型升级被删掉。
读者今天就可以做一次小型审计：挑一个最常用的 skill，保留任务和验收标准不变，分别运行「有 skill」和「无 skill」两个版本，记录结果质量、是否通过以及 token 用量。如果差异说不清，这个 skill 暂时就没有资格继续占据你的上下文窗口。
관련 콘텐츠
- 로그인하면 댓글을 작성할 수 있습니다.