请立刻升级你的所有Skills

我所有的 skills 都是与 Agent 沟通清楚需求之后由 Anthropic 的 skill-creator 创建的

最近 anthropic 官方更新了 skill-creator 模板

这两天我重新刷了一遍 Anthropic 的 Skills 相关文档（居然有中文版），明显感觉：Skills 不再只是一个小功能，而是在被当成 Claude 的核心能力层来建设。

Anthropic 还有一个公开课，可以说把 Agent 相关内容事无巨细将透彻了（本身很多 AI Agent 概念就是 A 社发明的），市面上没有比这个更好的素材了

我先把结论放前面：

1. Anthropic 已经把 Skills 讲得越来越"工程化"了，不再停留在概念层。
2. GitHub 上的官方 skill-creator 模板，也已经从"教你怎么写"升级成"教你怎么评测、迭代、优化触发效果"。
3. 如果你正在做个人工作流、团队知识沉淀、或者 Agent 自动化，现在就是认真做 Skills 的好时机。

做了一下测试，我常用的文章核心内容设计成高密度 svg 的 skills，本来也在逐步优化，但是依然不稳定，时常页面显示有 bug

然后我让最新的 skill-creator 重新设计了这个 svg skills

同样输入，得到的结果就改善不少

真诚建议：你的所有 Skills 都需要重新做一遍！至少我会逐步全部优化一遍

前面推荐的材料，如果你时间不多，我建议按这个顺序看：

1. 官方集合页：Features and capabilities

这是我这次最想推荐的入口页，集合页里已经收录了 26 篇能力说明文章，里面不光有 Skills，还有 Artifacts、Web Search、Research、Projects、Memory、Cowork、Excel、PowerPoint 等等。

最关键的是，这个集合页已经明确提供了 简体中文 入口 https://support.claude.com/zh-CN/collections/18031719-%E5%8A%9F%E8%83%BD%E4%B8%8E%E8%83%BD%E5%8A%9B

尤其不能错过这一篇：：如何创建自定义技能

2.公开课

https://anthropic.skilljar.com/

看前几个就行了

3. GitHub 官方 skill-creator（重点推荐！）

这个版本给我的最大感受是：

Anthropic 已经默认你做 Skill，不是一次性写完，而是要反复迭代。

它里面强调的流程非常像正经产品开发：

1. 先定义 Skill 想解决什么问题
2. 再写草稿
3. 准备测试 prompt
4. 跑"带 Skill"和"不带 Skill"的基线对比
5. 看结果、做评估
6. 改描述、改内容、继续迭代
7. 最后还要做 Description 触发优化

skill-creator 里最让我震撼的是它的评测体系。

不是让你"看看感觉对不对"，而是一套非常工程化的系统：

第一步：基线对比（A/B Test）

对每一个测试用例，同时跑两个版本：

• With-skill：带着你的 Skill 执行
• Without-skill（或旧版 Skill）：不用 / 用旧版执行

两组任务同时起跑（用 subagent 并行），结果分别存进 with_skill/ 和 without_skill/ 目录。

这是真正的 A/B Test 思维——不是"我觉得好了"，而是"有没有带来可量化的提升"。

第二步：量化断言（Assertions）

在测试跑着的同时，给每个用例写量化断言——这些断言是可编程验证的。比如：

• 输出文件里是否包含目录结构
• 图表是否有坐标轴标签
• 格式是否符合模板

好的断言有两个特点：客观可验证 + 描述性命名（一眼能看懂在检查什么）。

对于那些主观性强的维度（写作风格、设计美感），skill-creator 明确说了：不要硬塞断言，用人工评审。

第三步：Eval Viewer 可视化评审

skill-creator 自带了一个浏览器评审工具（eval-viewer/generate_review.py），打开后有两个标签页：

• Outputs 标签：逐个展示测试用例的输入和输出，你可以直接在里面写反馈
• Benchmark 标签：展示量化数据——通过率、用时、Token 消耗，带均值和标准差

迭代到第二轮以后，还能看到和上一轮的对比。

这套评审界面做得真的很用心。Anthropic 在 SKILL.md 里反复强调（甚至用了大写字母强调）：一定要先让人看结果，再改 Skill！

第四步：迭代改进

读完用户反馈后，改 Skill，重新跑所有测试用例到新的 iteration-N/ 目录，再次评审。循环往复，直到：

• 用户满意
• 反馈全部为空
• 改进幅度不再明显

skill-creator 甚至还提供了盲评机制——把两个版本的输出交给一个独立的 Agent，不告诉它哪个是新版、哪个是旧版，让它独立判断哪个更好。

然后再用 analyzer Agent 分析赢的那个为什么赢。

这是不是很像学术论文里的"双盲评审"？

Anthropic 把这套方法论塞进了一个 Skill 的创建工具里，格局之大，可见他们对 Skills 生态的重视程度。

核心：Description 触发优化

这可能是 skill-creator 里价值最高的一个功能。

它的原理是：

1. 生成 20 条测试查询——一半应该触发 Skill，一半不应该触发
2. 这些查询不是"读取 PDF"这种简单的，而是模拟真实用户的具体描述（带文件名、带背景、带口语化表达、甚至带错别字）
3. 60/40 拆分：60% 用于训练，40% 用于验证（防过拟合）
4. 每条查询跑 3 次取稳定触发率
5. Claude 根据触发失败的 case 提出 description 改进建议
6. 重新评估新 description，最多迭代 5 轮
7. 最终按验证集分数（不是训练集）选出最佳 description

这整个流程和机器学习的超参数调优一模一样。

迭代改进的四条心法

skill-creator 里还给出了改进 Skill 时的思维方式，非常值得分享：

1. 从反馈中泛化：你只在几个测试用例上迭代，但 Skill 未来要用无数次。不要过拟合到特定例子上，不要写死板的 MUST/NEVER，而是用不同思路去解决顽固问题
2. 保持 Skill 精简：去掉没起作用的部分，读测试过程的完整日志（不只看最终输出），看看 Skill 有没有让 Claude 做了很多无用功
3. **解释"为什么"**：不要只告诉 Claude "必须这样做"，而是解释为什么要这样做。今天的 LLM 很聪明，理解了 why 比记住 what 更有效
4. 发现重复模式：如果多个测试用例中 Claude 都独立写了类似的辅助脚本，那就说明这个脚本应该被打包进 Skill 的 scripts/ 目录，省得每次重新发明轮子

但这次官方文档反复在强调一个更准确的视角：

Skill 是把你的流程、标准、语气、工具使用方式，封装成 Claude 在合适时机主动调用的能力。

这里最重要的不是"内容多不多"，而是两个字：

触发。

官方文档这次明确强调，description 不是装饰字段，而是 Claude 判断"什么时候该用这个 Skill"的核心依据。

GitHub 上的 skill-creator 甚至直接建议：描述要写得更明确、更主动一点，避免 Skill 该触发的时候不触发。并且它还给出了一套完整的 Description 优化流程——自动生成测试查询、拆分训练集和验证集、跑 3 次取稳定触发率、迭代 5 轮找最优 description，这和机器学习调参一个思路。

这个细节非常关键。

因为现实里最好用的 Skill，往往不是写得最长的那个，而是触发最准的那个。

skill-creator 还揭示了一个很多人不知道的触发机制：Claude 对简单任务不会触发 Skill。如果它自己就能处理（比如"读这个 PDF"），它不会去查 Skill。只有复杂的、多步骤的任务才会激活触发逻辑。这意味着你测试 Skill 的时候，用过于简单的 prompt 是测不出来的。

2. 官方开始鼓励"小而专"的 Skill 设计

帮助中心里有一句我很认同，大意是：

不要把所有东西都塞进一个大 Skill 里，多个聚焦的小 Skill，组合起来反而更强。

这个思路和写程序很像。

函数越单一，越容易复用，越容易测，越不容易崩。

Skill 也是一样。

比如你可以拆成：

• 一个负责"技术文章撰写"
• 一个负责"PDF 翻译"
• 一个负责"本地视频转录"
• 一个负责"Obsidian 笔记归档"

这些 Skill 单独看都不复杂，但一旦 Claude 能根据场景自动组合，威力就很大。

3. 安全被提到了正式位置

这次官方文档还专门单独列了安全注意事项。

比如：

• 不要把 API Key、密码之类敏感信息硬编码到 Skill 里
• 下载别人的 Skill 之前先审查内容
• 如果要访问外部服务，优先走合适的 MCP 连接

如果你现在就想开始做 Skills，我建议这么干

第一步：只挑高频、重复、标准化的任务

比如这些就很适合：

• 根据几个固定链接写技术文章
• 固定格式总结会议纪要
• 读取 Obsidian 某类笔记并输出周报
• 把一份 PDF 翻成中文并保留版式
• 根据一篇文章生成短视频口播稿

这些任务有一个共同点：

步骤清楚，产出稳定，重复率高。

这类任务最值得先做成 Skill。

第二步：先把触发描述写对

这是很多人最容易忽略的地方。

一个好 Skill 的描述，至少要说清楚三件事：

1. 它解决什么问题
2. 用户在什么语境下提到它时应该触发
3. 最终输出大概是什么

如果这三点写不清楚，Claude 很可能就"知道有这个 Skill，但就是不用"。

第三步：资源外置，不要把所有东西都堆在 SKILL.md 里

官方现在推荐的结构已经很清楚了：

my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

这个结构的好处非常直接：

• SKILL.md 负责规则和入口
• scripts/ 负责确定性执行
• references/ 负责大块知识
• assets/ 负责模板和素材

说白了，就是让 Skill 既能"会说"，也能"会干活"。

第四步：一定要做基线对比

这点是 GitHub 官方 skill-creator 给我的最大启发。

很多人做完 Skill，你至少要看两件事：

1. 带 Skill 和不带 Skill，输出到底差了什么
2. Skill 触发率、稳定性、结构一致性有没有提升

如果没有明显提升，那这个 Skill 可能只是让你心理安慰更强了，并没有真正提升生产力。

具体怎么做？skill-creator 给出了一套可操作的方法：

• 准备 2-3 个真实场景的 prompt——不是"帮我写个报告"这种笼统的，而是带有具体背景、具体文件、具体要求的
• 同时执行带 Skill 和不带 Skill 的两组任务
• 写量化断言：输出里是否包含某个结构、格式是否一致、关键信息有没有遗漏
• 用 eval viewer 可视化对比：通过率、Token 用量、耗时一目了然
• 记录每一轮迭代：存到 iteration-1/、iteration-2/ 目录，跟踪改进趋势

听起来麻烦？其实不用自己折腾。直接在 Claude Code 里用 skill-creator，它会自动帮你跑完这一套。

最后一句

我越来越觉得，2026 年做 AI 提效，真正的分水岭已经不是"会不会写 Prompt"了。

而是你有没有能力把自己的工作流，沉淀成一套可以复用、可以组合、可以迭代的 Skills。

Prompt 是一次性的。

Skill 才是资产。

skill-creator 的 SKILL.md 里有一句话让我印象很深：

This task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over.

"思考时间不是瓶颈，认真想清楚才是关键。"

这句话不只是说给创建 Skill 的 Claude 听的，也是说给我们每一个用 AI 的人听的。

#ClaudeSkills #AgentSkills #Anthropic #Claude #AI工作流