Claude Skills 2.0#技能基准A/B测试，你的技能可能正在悄悄“过期“
技能基准A/B测试：你的技能可能正在悄悄"过期"
你是否注意过，那些曾经让你引以为豪的技能，正在悄悄"变质"？
三个月前，你写了一个帮助 Claude 写 Landing Page 的技能。当时模型还不擅长这个，你的详细步骤确实让它表现得更好。
然后，Anthropic 发布了一个新模型。
这个新模型本身就非常擅长 Landing Page—— 甚至比你的技能指导下的表现更好。但你的旧技能还在那儿，顽固地告诉 Claude "按我说的步骤来"—— 即使那些步骤已经过时了。
结果呢？Claude 正在被你的技能拖累，而不是被帮助。
这种情况大多数人根本注意不到。你的技能没有报错，没有崩溃，它只是—— 悄悄地，让你的输出变差了。
这就是 AI 时代的"技术债务"：技能也会过期，而且你往往后知后觉。
Skills专项：如果没有自己的Skills，OpenClaw只能是一个玩具#Mixlab AI编程专项
两种技能的不同命运
理解技能为什么会"过期"，需要先理解技能有两种类型：
Capability uplift（能力提升型）：这类技能教 AI 做它本来做不好的事。随着模型能力变强，这些技能可能变得多余。
关键信号是：如果基础模型（不加载技能）就能通过你的 eval 测试，说明模型的默认能力已经"吸收"了你的技能技巧。这时候，技能不是"坏了"，而是"可以退休了"。
Encoded preference（偏好编码型）：这类技能记录的是"流程"——模型已经会做每一步，但需要按你团队的方式串联起来。这类技能更持久，但也有风险：流程变了，技能没跟上也等于失效。
无论是哪种类型，核心问题都是：你需要一个机制来"发现"技能何时失效。
A/B 测试：消除偏见的评判者
这就要说到 Anthropic 新引入的Comparator Agents（比较器代理）。
这个功能解决了一个根本问题：当你修改了技能，怎么知道修改真的"变好"了？
传统的做法是——凭感觉。你运行一次，有改善，开心；没改善，困惑。但这有个致命问题：人类有确认偏见，我们倾向于看到我们想看到的结果。
Comparator Agents 的做法完全不同：
它同时运行两个版本：技能 A vs 技能 B，或者"技能加载"vs"技能不加载"
评判代理不知道哪个版本是哪个，所以不存在先入为主
最后输出一个清晰结论：哪个版本更好，好多少
这就像在产品经理的世界里做 A/B 测试——数据说话，消除偏见。
《OpenClaw 蓝皮书》一份写给普通人的AI助手指南
跨学科视角：对比思维的源头
这种"对比"的思维方式，在多个领域都有深刻根源。
从产品思维看，A/B 测试是互联网产品的基石——上线两个版本，让用户用脚投票，用数据替代"我以为"。
从科学方法看，这是"控制变量"的精髓——只有一个因素不同，其他条件保持一致，然后观察结果差异。
从版本控制的角度看，这和"创建分支对比不同方案，测试后选择最优，删除其他分支"的思路一脉相承。
三种视角指向同一个结论：没有对比的优化是盲目的，没有基准的迭代是无方向的。
Agent Skill 的 Script 架构设计指南：平衡认知与执行
行动框架：技能体检的节奏
建议每个 Mixlab 读者建立自己的"技能体检"节奏：
- 每次模型大更新后
，运行基准测试
- 记录"技能加载"vs"技能不加载"的对比结果
- 判断结果
：
基础模型胜出 → 考虑退役技能
技能险胜 → 继续保留但持续监控
技能大比分胜出 → 保持并持续优化
- 关注趋势
：通过率变化趋势 > 单次分数
工具选择上，用 Skill Creator 的 benchmark 模式可以批量运行所有 eval，生成一份完整的"技能健康报告"。
新的Skill可以做的事情
致最先触达未来的那一小部分人
多数人还在为"技能数量"沾沾自喜时，聪明的玩家已经开始做"技能质量管理"。
你的 AI 工作流不是一次性的项目，而是需要持续维护的"数字资产"。就像代码需要重构，技能也需要定期"体检"和"升级"。
在这个 AI 能力指数级增长的时代，会维护技能的人，比会写技能的人更有价值。
因为真正的问题从来不是"能不能写"，而是"写了之后呢？"
Skills专项：如果没有自己的Skills，OpenClaw只能是一个玩具
参考文献
[1] AI编程版本控制
[2] Improving skill-creator: Test, measure, and refine Agent Skills.
[3] Agent Skills Overview - Claude API Documentation.
[4] A complete guide to building skills for Claude.
[5] Claude Code.