Claude Code Skills 2.0 真正升级的，不是提示词，而是可评测的工作流资产

你真正该关心的，不是“skill 是什么”，而是 Claude Code 这一代 skill，到底跟一代差在哪。

如果只把它理解成“更高级的提示词模板”，这次更新基本就看偏了。

Skills 2.0 最大的变化，不是更方便写 prompt，而是 skill 开始从经验文本，变成可评测、可迭代、可分发的工作流资产。

这不是说 Anthropic 官方 headline 就写着“测试集化”。官方讲得更直接的，其实是另一套词：

• custom commands 并进了 skills
• skills 可以自动触发，也可以手动 /skill-name
• skill 不再只有一段说明，还可以带 supporting files、脚本、工具边界
• 复杂任务可以放进 context: fork 的 subagent 里跑

但把这些点放在一起看，你会发现它已经不是“写一段 prompt 教模型做事”那么简单了。

先澄清：什么是单个 skill，什么又叫 Skills 2.0

单个 skill，就是一个以 SKILL.md 为入口的能力包。

官方文档现在讲得很直白：一个 skill 至少有名字、description 和正文说明；再往上，可以带 references、examples、scripts，必要时还能加 invocation control、allowed-tools、dynamic context、subagent execution。

也就是说，一个 skill 是能力单元。

那 Skills 2.0 是什么？

更准确地说，它不是 Anthropic 官方统一命名的产品名，更像社区对“这一代 skill 体系升级”的简称。这个“2.0”主要指的不是某一个字段，而是一整套能力形态变了：

• 从 .claude/commands/xxx.md 那种命令说明，过渡到 .claude/skills/<name>/SKILL.md
• custom commands 被官方明确并进 skills
• skill 支持目录化组织，而不是一页孤立 markdown
• skill 可以被 Claude 按 description 自动匹配，而不只是你手动敲 /deploy
• skill 可以限制调用工具，也可以在 forked subagent 里隔离执行
• skill 遵循 Agent Skills 开放标准，开始具备跨工具分发的基础

所以单个 skill 是“能力包”，而 Skills 2.0 是“能力包这套工程形态终于成立了”。

一代和二代，差别到底在哪

最容易看懂的方式，不是继续讲概念，而是正面对照。

一代 / 早期形态	二代 / Skills 2.0
更像把经验写进 prompt、命令说明、wiki 片段	更像一个目录化能力包
入口分散：命令是命令，说明是说明，脚本是脚本	入口统一：SKILL.md + supporting files
主要靠人记得去调用	可以手动调用，也可以按 description 自动触发
上下文常常直接塞进主会话	可以按需加载，还能放进 forked subagent 隔离执行
很难定义边界，越写越长	可以拆正文、引用资料、脚本、工具权限
复用更多靠复制 prompt	可以按目录分发、按标准迁移、按团队治理
结果好坏很难复盘	已经开始具备 with/without、触发准确率、回归测试的条件

如果你只看“能写 markdown 说明”这一层，那一代和二代确实都能干。

但一旦把它放进真实工作流里，你会发现差别非常大。

一代，本质上还是“经验文本”

一代不是没价值。

它解决的是：把你脑子里的做事方法，先写给模型看。比如：怎么 review、怎么发版、怎么解释代码、怎么按团队约定改 API。

问题在于，这一代 skill 更像：

• 一段 prompt
• 一页说明书
• 一个 slash command
• 再加一些散落在别处的文档和脚本

能不能稳定触发、会不会污染上下文、脚本和说明是不是同版本、团队能不能迁移复用，很多时候都靠人肉维持。

所以它更像聊天技巧的工程化边缘版本，而不是完整资产。

二代，开始像“可治理的能力包”

Claude Code 官方这次最重要的一步，是把原来分散的几层东西收口了。

custom commands merged into skills 这句话很关键。

因为它意味着：以后你别再把“命令”理解成快捷键、把“skill”理解成附注说明。对 Claude Code 来说，它们正在被统一成同一种东西：可复用工作流单元。

这个单元现在至少有四个工程特征。

1）目录稳定

skill 不是一段游离文本，而是一个目录。

里面谁是入口，谁是补充文档，谁是示例，谁是脚本，都有固定位置。模型先看到 name 和 description，需要时再读 SKILL.md，需要更细内容时再去读 supporting files。

这就是从“全文塞 prompt”变成“按需加载”的关键。

2）触发机制稳定

description 不再只是简介，而更像一条路由规则。

Claude 会先根据 description 判断要不要加载这个 skill。你手动 /skill-name 是一条路，自动匹配是另一条路。

这件事一稳定，skill 就第一次不只是“内容”，而是“可被测的触发器”。

3）执行边界稳定

allowed-tools、disable-model-invocation、context: fork 这些能力看起来像配置项，但工程意义很大。

因为它们回答的是三个老问题：

• 这个 skill 到底该不该自动触发
• 触发后它最多能用哪些工具
• 这件事应该在主会话做，还是在隔离上下文里做

这已经不是提示词范畴了，这是工作流治理。

4）分发形态稳定

当 skill 遵循 Agent Skills 开放标准，又能挂到 plugin、marketplace、仓库里复用时，它就开始具备“跨工具迁移”的可能。

你可以不夸张地说：skill 第一次像 package，而不是聊天记录里的一个高光 prompt。

为什么这会让 skill 第一次开始“可评测”

这里就是这次最容易被轻描淡写、但其实最值钱的点。

官方现在并没有把“可量化测试集”当成产品 headline 来卖。

但二代 skill 的工程结构，第一次让这件事真的成立了。

为什么？因为评测最怕对象不稳定。

如果一个 skill 只是散落在聊天记录、命令文件、团队 wiki 和口头经验里的混合体，你很难定义“到底在测谁”。

而二代 skill 一旦变成稳定目录，很多以前没法认真做的事，现在都能做了。

1）可以做 trigger eval

既然自动触发主要依赖 description，那你就能设计一组任务样本，看它：

• 该触发的时候有没有触发
• 不该触发的时候会不会误触发
• 哪些描述写法命中率更高

这本质上就是 trigger eval。

以前很多人会把 description 当副标题来写；现在它更像分类器的标签定义。

2）可以做 with-skill / without-skill 对比

skill 目录稳定以后，你就能拿同一批任务分别跑：

• 不加载 skill
• 加载旧版 skill
• 加载新版 skill

然后比输出质量、步骤完整性、耗时、是否漏项、是否误用工具。

这就是最朴素、也最实用的 with skill / without skill benchmark。

3）可以做 grading 和 regression

只要任务集固定，评分标准固定，skill 又是版本化目录，你就能继续往前走：

• 用 rubric 做人工 grading
• 用 judge 或脚本做半自动评分
• 每次改 description、改脚本、改 references 后跑一遍 regression

到这一步，skill 才第一次有点像代码资产。

因为你终于可以回答一句以前很难回答的话：

这次改 skill，到底是真的更好了，还是只是作者自己觉得更好了？

4）可以把“经验”变成团队资产，而不是写作者手感

一代 skill 最依赖的是写的人。

二代 skill 更依赖的是结构。

只要结构稳定，团队就能围绕它做三件事：

• 把高频流程沉淀出来
• 用任务集验证是否真有 uplift
• 在模型原生能力进步后，决定这个 skill 是继续迭代，还是应该退休

可评测性，正是这次升级里最有价值的工程结果之一。

不是因为官方 slogan 这么写，而是因为只有到了二代，这件事才从口头愿望变成可执行流程。

但边界也得说清

说 skill 开始可评测，不等于说它已经天然可评测。

这里至少还有三个边界。

第一，它不是官方唯一主卖点

官方一手文档强调得更明确的，还是 merged commands、supporting files、subagent execution、dynamic context、invocation control。

所以如果有人说“Anthropic 这次更新的官方 headline 就是把 skill 变成测试集”，这话说重了。

第二，可评测性更多是工程延长线

准确的表述应该是：官方给出了结构，开放标准给出了可迁移格式，而“eval-driven iteration”是这套结构自然长出来的工程能力。

它有官方基础，但更多是开发者和团队真正落地后，最应该抓住的价值。

第三，不是所有 skill 都值得长期保留

Anthropic 自己也提醒过，随着模型原生能力增强，一部分 skill 会被吞掉。

所以 skill 不该无限增长。

真正成熟的做法不是“多写几个”，而是：

• 有收益就留下
• 没收益就删除
• 收益下降就重测

这跟维护代码资产，其实已经很像了。

你如果是开发者或团队负责人，现在为什么该认真看

因为这次升级影响的不是“你会不会多一个命令”，而是 你能不能把团队工作流沉淀成可治理资产。

如果你已经遇到下面这些问题，就该认真看了：

• 同类任务一直重复做，但结果总不稳
• 团队经验散在群聊、文档、老人脑子里
• 主会话一做复杂任务就被上下文污染
• prompt 经常复制来复制去，没人知道哪个版本最好
• 你希望一套方法以后能迁到别的 agent 工具上

Skills 2.0 给你的，不只是“再写一个 prompt 的地方”。

它给的是一个更像软件工程的起点：

• 能封装
• 能加载
• 能隔离
• 能分发
• 能测试
• 能回归

一句话收口：一代 skill 更像把经验写给模型看，二代 skill 更像把工作流做成可以维护的资产。

所以，这次升级值得按“代际变化”去看，而不是继续按“提示词技巧”去理解。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

---

关注微信公众号

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。