Skill 到底值不值得认真对待？
打个比方：你写代码不用 linter，也能写，大部分时候也没 bug。但用了 linter 之后，整体代码质量的天花板会无声地抬高。Skill 的作用跟这个非常像。
它的价值不在于单次对话里让你惊艳，而在于——当你长期、重复地做某一类任务（写公众号文章、做落地页、处理数据报表、写邮件序列），一个好的 Skill 能把你的平均输出水平拉高 20%–40%。不是偶尔好，而是稳定地好。
但这里有一个巨大的前提：它得是一个真正好的 Skill。一个差的 Skill，不如没有 Skill。
那你怎么知道你的 Skill 是好的？这正是新版 Skill Creator 要解决的核心问题。
问题一：你根本无法证明 Skill 有效
过去所有 Skill 用户面对的最大困境是——没有度量手段。
比如你有一个写营销邮件的 Skill，规定了语气要"直接但不冷漠"，每封邮件必须以一个问题开头，正文不超过 200 字。你用它写了一封邮件，看着还不错，就觉得 Skill 在生效。
但你有没有想过：也许不加载这个 Skill，Claude 也会写出差不多的东西？也许那条"以问题开头"的规则在 60% 的场景下被无视了，但你只测了两次，恰好测到了遵守的那两次？
这就是观测者偏差——你看到的结果，未必能代表 Skill 的真实水平。
解法：结构化评估。 告诉 Claude：
use the Skill Creator to evaluate [你的 Skill 名字].
它会做三件事：
- 生成测试用例——读取你的 Skill 内容，理解它应该完成什么任务，然后自动生成一批覆盖不同场景的测试提示词。比如你的 Skill 是写博客文章的，它可能会生成"写一篇 500 字关于生产力的文章""写一篇面向初学者的 AI 科普长文""写一篇带争议性观点的行业评论"等不同任务。
- 执行测试——每个测试提示词都会在加载你的 Skill 的条件下运行，生成实际输出。
- 逐项检查——对每一份输出进行检查：语气有没有贯彻？格式规则有没有遵守？结构是不是你期望的？不是笼统地说"还行"或"不行"，而是告诉你：9 个测试过了 7 个，哪 2 个没过，分别因为什么。
以前：我觉得这个 Skill 应该有效吧。现在：我的 Skill 在格式遵循率上是 78%，主要失败场景是长内容（超过 1000 字时语气容易偏移），以及涉及技术类话题时会忽略"用比喻开头"的指令。从"感觉"变成了"数据"。
真正的杀手锏：迭代修复
评估本身不是终点，迭代才是。
拿到报告看到 7/9 通过、2 个失败，直接告诉 Claude：
update the skill to fix [具体问题].
比如"修复长内容场景下语气偏移的问题"，或者"强化技术类话题时使用比喻开头的指令"。修完再跑一遍评估，变成 8/9，继续修、继续测，直到 9/9。
每轮迭代可能只要 2–3 分钟，但它带来的确定性，是过去花再多时间靠感觉调都买不到的。
问题二：模型更新正在悄悄废掉你的旧 Skill
这是一个被严重低估的问题。
假设你三个月前做了一个 Skill，帮 Claude 写落地页文案。当时的模型在这方面确实比较弱，你写了一套非常详细的指令——先写抓人标题，然后用 AIDA 框架组织正文，每段不超过三行，结尾必须有清晰的 CTA。那时候，这套指令确实有用。
然后三个月过去了，新模型发布了。新模型默认就知道要用引人注目的标题，默认就会考虑内容节奏，默认就会在结尾放 CTA。但你的旧 Skill 还挂在那里。
问题在于：当 Skill 指令和模型自身能力产生冲突时，Claude 会优先遵循 Skill 指令。
这意味着 Claude 本来可以灵活地、根据上下文智能地选择最优表达方式，却被你那套三个月前的僵硬步骤绑死了。就像你请了一个已经学会自由泳的选手，还要求他按初学者教程一步一步来——先学憋气，再学打水，再学手臂动作。他会照做，但游得反而更慢。
而且这种退化是无声的。你不会收到任何警告，只会模糊地觉得"最近 Claude 好像没以前好用了"——但你绝对想不到，罪魁祸首是你自己三个月前引以为傲的那个 Skill。
解法：A/B 盲测对比。 告诉 Claude：
use the Skill Creator to benchmark [你的 Skill 名字].
它会把同一批测试任务跑两遍——一组加载你的 Skill，一组不加载任何 Skill，直接用原生 Claude。然后由一个独立的评估 Agent 进行盲测评分，这个 Agent 不知道哪份输出用了 Skill、哪份没用，只看内容质量，从多个维度打分。
最终结果只有三种可能：
- 原生 Claude 赢了——你的 Skill 已经过期，退役它。去掉之后输出质量反而会提升。
- Skill 赢了但优势不大——模型正在逼近你 Skill 的能力，暂时保留，但下次模型更新后需要再测。
- Skill 赢了很多——这个 Skill 仍然在创造显著价值，继续保留。
你也可以用这个功能比较同一个 Skill 的两个版本，改了之后不确定改得好不好？跑一次 benchmark，数据给你答案。
问题三：Claude 该用 Skill 时不用，不该用时乱用
如果说前两个问题是 Skill 本身的质量问题，这第三个问题更让人抓狂——触发逻辑问题。
为什么会这样？想象你的所有 Skill 是工具箱里的工具。Claude 在每次对话开始时，不会把工具箱里的所有工具都取出来，而是先看每个工具上的标签（也就是 Skill 的 description），然后根据你当前的请求判断该用哪个。
标签写得差，两种问题都会出现：
- 太模糊——比如写了个 "writing help"，Claude 觉得只要跟写作沾边的都该用。于是你写代码注释的时候，它也把你专门写营销文案的 Skill 调出来了。
- 太具体——比如写了 "Q4 2025 product launch email sequence"，除非请求里出现几乎一模一样的关键词，否则 Claude 根本想不到调用它。
这就像给你的扳手贴了一个标签："2025年10月17日下午3点在车库里修那辆本田思域左前轮螺丝用的扳手"——技术上没错，但下次需要扳手的时候，你根本找不到它。
解法：description 自动优化。 告诉 Claude：
use the Skill Creator to optimize the description for [你的 Skill 名字].
它会做一轮系统性的触发测试：正向测试（应该触发的场景有没有触发）和反向测试（不相关的场景有没有误触发），然后根据测试结果自动重写你的 description。
Anthropic 用这个方法测了自己的官方 Skills，6 个里有 5 个的触发效果在优化后都提升了。如果你手上有超过 3 个 Skill，这可能是投入产出比最高的单一优化动作。
一套完整的 Skill 维护流程
把上面三个功能串起来，就是一个你今天就能执行的流程：
- 清查——把现有所有 Skill 列出来，数一下，你可能会发现比记忆中的多
- 逐个评估——对每个 Skill 运行一次 evaluate，拿到通过率，记下失败项
- 修复——对通过率低的 Skill，根据失败项逐个修复，每修一次重新评估一次，循环到满意为止
- 基准对比——对每个 Skill 跑一次 benchmark，看它跟原生 Claude 比谁好，退役掉所有被模型超越的 Skill
- 优化触发——对保留下来的每个 Skill，运行一次 description 优化
- 建立节奏——每次 Anthropic 发新模型后重复第 4 步；每个月或每两个月重复第 2、5 步
第一次完整做一遍可能需要 1–2 小时，之后的常规维护每次只要 10–15 分钟。
写在最后
Skill 的本质是你和 AI 之间的一份协议——在这类任务上，按照这种方式工作。但任何协议都需要维护：模型在更新，你的需求在演进，甚至协议本身可能从一开始就有漏洞。
过去我们没有维护手段，只能靠猜、靠感觉、靠运气。现在评估、对比、优化三个动作构成了一个闭环。
那么问题来了：你现在手上有几个 Skill，有多久没回头看过它们了？