我所有的 skills 都是与 Agent 沟通清楚需求之后由 Anthropic 的 skill-creator 创建的
最近 anthropic 官方更新了 skill-creator 模板
这两天我重新刷了一遍 Anthropic 的 Skills 相关文档（居然有中文版），明显感觉：Skills 不再只是一个小功能，而是在被当成 Claude 的核心能力层来建设。
Anthropic 还有一个公开课，可以说把 Agent 相关内容事无巨细将透彻了（本身很多 AI Agent 概念就是 A 社发明的），市面上没有比这个更好的素材了
我先把结论放前面：
Anthropic 已经把 Skills 讲得越来越"工程化"了，不再停留在概念层。 GitHub 上的官方 skill-creator模板，也已经从"教你怎么写"升级成"教你怎么评测、迭代、优化触发效果"。如果你正在做个人工作流、团队知识沉淀、或者 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，不是一次性写完，而是要反复迭代。
它里面强调的流程非常像正经产品开发：
先定义 Skill 想解决什么问题 再写草稿 准备测试 prompt 跑"带 Skill"和"不带 Skill"的基线对比 看结果、做评估 改描述、改内容、继续迭代 最后还要做 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 里价值最高的一个功能。
它的原理是：
生成 20 条测试查询——一半应该触发 Skill，一半不应该触发 这些查询不是"读取 PDF"这种简单的，而是模拟真实用户的具体描述（带文件名、带背景、带口语化表达、甚至带错别字） 60/40 拆分：60% 用于训练，40% 用于验证（防过拟合） 每条查询跑 3 次取稳定触发率 Claude 根据触发失败的 case 提出 description 改进建议 重新评估新 description，最多迭代 5 轮 最终按验证集分数（不是训练集）选出最佳 description
这整个流程和机器学习的超参数调优一模一样。
迭代改进的四条心法
skill-creator 里还给出了改进 Skill 时的思维方式，非常值得分享：
从反馈中泛化：你只在几个测试用例上迭代，但 Skill 未来要用无数次。不要过拟合到特定例子上，不要写死板的 MUST/NEVER，而是用不同思路去解决顽固问题 保持 Skill 精简：去掉没起作用的部分，读测试过程的完整日志（不只看最终输出），看看 Skill 有没有让 Claude 做了很多无用功 **解释"为什么"**：不要只告诉 Claude "必须这样做"，而是解释为什么要这样做。今天的 LLM 很聪明，理解了 why 比记住 what 更有效 发现重复模式：如果多个测试用例中 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 的描述，至少要说清楚三件事：
它解决什么问题 用户在什么语境下提到它时应该触发 最终输出大概是什么
如果这三点写不清楚，Claude 很可能就"知道有这个 Skill，但就是不用"。
第三步：资源外置，不要把所有东西都堆在 SKILL.md 里
官方现在推荐的结构已经很清楚了：
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/
这个结构的好处非常直接：
SKILL.md负责规则和入口scripts/负责确定性执行references/负责大块知识assets/负责模板和素材
说白了，就是让 Skill 既能"会说"，也能"会干活"。
第四步：一定要做基线对比
这点是 GitHub 官方 skill-creator 给我的最大启发。
很多人做完 Skill，你至少要看两件事：
带 Skill 和不带 Skill，输出到底差了什么 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工作流
