昨天（9 月 1 日），Skill 开发圈发生了两件事，表面上互不相干，放在一起看却很有味道。
一件是 Anthropic 工程师 Thariq 公开介绍了他们内部最近爆火的一个 Skill——ELI5，并且把它开源了。点开 GitHub 你会发现，这个 Skill 的 SKILL.md 正文只有 321 字节，核心就是一句提示词：把我当成一个对这个主题完全不了解的人，用大图和少量文字，做成一个 HTML 页面讲给我看。知乎没有流程图，没有 few-shot 示例，没有边界条件罗列。问它「后训练是什么」「RAG 怎么工作」，它直接生成一本技术绘本式的图文网页。
另一件是同日，阿里开源了一款叫 skill-up 的评测工具，专门解决一个问题：怎么验证一个 Agent Skill 在你改过之后还能正常工作。知乎
一个给出「好 Skill 可以短到极致」的样本，一个回答「怎么证明你的 Skill 还好使」。这两件事撞在同一周，其实是同一个缺口。
模型越强，Skill 越不需要「教」
先说 ELI5 反常识的地方。
如果你从春天开始关注 Skill 内容，大概记得三四月份流行的是什么：必装清单。《十个顶级 Claude Code Skills》《装完这 10 个 Skills，我彻底离不开 Claude Code 了》，还有教目录结构、渐进式披露的完全指南，收藏量动辄几百上千。六月又出现万字长文，手把手教你「怎么写 Claude 才会用」。主流方向一直是把 Skill 写得更丰富、更详细。
ELI5 却给了个反方向：这一句提示词没有教模型怎么写网页，模型本来就会写。它只定了三件事——默认读者零基础、内容要可视化、文字尽量少。至于页面分几块、画什么图、用什么颜色，全部交给模型自己判断。
这不是孤例。社区里另一个叫 grill-me 的 Skill 也是同款结构：把一个没想清楚的方案交给它，它会追着你问，一次只问一个问题，代码库里能查到的信息自己查。核心提示词同样只有几句，只给目标和关键规则，不锁步骤。
有篇讲 ELI5 开源的文章总结得挺准：当模型能力足够强时，好 Skill 不一定更长，而是更清楚。知乎
但极简有代价：你解释不了它为什么好使
转折在这里。
提示词越短，模型自由发挥的空间越大，行为就越「不可解释」。ELI5 这 321 字节今天好用，模型换个版本之后呢？改一个形容词，风格会不会漂移？没人能回答。
这正是眼下 Skill 圈普遍存在的焦虑。知乎上有人写得直白：Skill 的本质是提示词工程，SKILL.md 改一个字，行为就可能漂移。但现状是——写完跑两下，感觉没问题，发布。知乎软件测试的铁规是，绝不允许一个没有用例、没有回归、没有质量门禁的系统上线；到了 Skill 这件事上，几乎所有人都在裸奔。
方法不是没有。Agent Skills 官方网站的 evaluating-skills 指南，早就写好了正确的循环：写真实用例、带着 Skill 和不带 Skill 各跑一遍、给输出打分、汇总、迭代。知乎但整套流程全靠手工，坚持不了几轮。
而社区已经到了必须回答这个问题的体量。知乎上有作者晒出一年发布 80 个 skill 的成绩单，有团队把内部规范、运维流程封装成 Skill 分发给全员，科研方向的技能包已经做到 163 个 Skill、GitHub 四万星量级。知乎知乎当 Skill 变成一份多人共享的资产，「我感觉它还能用」就不够用了。社区里那个扎心的问题就是这么来的：一个 Skill 的「好坏」，到底由谁定义？
skill-up：把测试工程那套，整体搬进 Skill 世界
阿里给出的答案是 skill-up。开源大约两个月，Go 语言，Apache-2.0 协议，8 月下旬大约 655 星，更新挺活跃。
做过软件测试的人看它的项目结构会觉得很眼熟：cases/ 放测试用例，fixtures/ 放测试数据，eval.yaml 定义评测环境——在哪个引擎里跑、怎么判定。每个用例是一个 yaml 文件，定义「发什么 prompt」和「怎么验证结果」，要多轮交互的场景可以用 turns 写多轮输入。
它支持把 Skill 放进 Claude Code、Codex、Qoder CLI 这些真实 Agent 引擎里跑；判定器分三档，从零成本的规则判断、到自定义脚本、再到让大模型当裁判的 agent_judge（LLM-as-a-Judge），按用例复杂度选；报告输出 JSON、JUnit XML、HTML，可以直接挂进 CI 当质量门禁；它把 Anthropic 的兼容做成了双向——既能导入现成的 evals.json，也能输出 grading.json 接回官方评测工具链。仓库还提供现成的 GitHub Action，每个 PR 触发时自动跑一轮评测，跨引擎对比。知乎
我觉得最妙的是 skill-upper：它本身就是一个 Agent Skill，职责是给别的 Skill 做测试。装进 Claude Code，打开你的 Skill 项目，直接说「评测这个 Skill」，它会自己读 SKILL.md、识别核心行为、生成用例、跑完评测、给出失败分析。失败转化为修复，修复再沉淀成新的回归用例——官方管这个闭环叫 Eval-to-Evolution，测试左移加持续回归的 Agent 版。知乎
话说回来，也得泼点冷水：skill-up 还很早期，开源两个月、几百星，能不能成为事实标准未可知。值得第一批去试，但不必围绕它重构你全部的 Skill 资产管理。
阶段切换，对你意味着什么
把这两件事放回时间线，能看到一条挺清晰的生态演进线（按我们近期在知乎采集到的热门文章发布时间排）：
3-5 月：必装清单热。大家关心「有哪些 Skill」，清单文收割几百赞和上千收藏；
6-8 月：体系化与量产。万字图解教程、插件化讨论、一年 80 个 skill 的高产作者、科研和工程约束这类垂直技能包冒头；
9 月：评测与维护进场。ELI5 这样的极简范本、skill-up 这样的评测工具，社区开始讨论「不是每个提示词都值得做成 Skill」。小红书
连 ELI5 这样的极简 Skill，生成页面后都会自动补一句「页面已通过桌面、手机和互动检查」——验证意识已经渗进了最轻量的玩法里。
一句话：Skill 圈正在从「怎么装、怎么写」走向「怎么验、怎么维护」。就像消费决策里，一个品类从「求推荐」阶段进入「怎么挑、怎么验」阶段——东西够多了之后，筛选成本就开始大于获取成本。
那具体该做什么？按你的状态分开说：
<#&!53#&!>如果你只有一两个自用 Skill：先别急着上 CI。做一件事就够——给核心 Skill 留 3-5 条「黄金用例」：真实输入，加上你期望看到的关键输出点，每次改动前跑一遍。这能挡住大部分「改坏了但没发现」。顺便可以学学 ELI5 的思路，回头看看自己写得最长的那个 Skill：模型是不是本来就会做，你缺的只是一句清楚的目标和边界。
如果你或团队手里有十几、几十个 Skill：值得挑最核心的 1-2 个，用 skill-up 配 10-20 条用例先跑起来，再考虑接 CI。一个提醒：写 Skill 的人和验 Skill 的人最好分开，既当运动员又当裁判是测试行业的大忌，Skill 世界只会更严重。知乎
如果你只是装来用：这波信息正好拿来当筛子。选 Skill 时看两点——作者有没有版本纪律和评测手段；指令是不是很长但目标模糊。目标导向的极简 Skill 往往跟着模型升级越来越顺，因为它不跟模型的能力增长对抗；而长流程型 Skill，要留意作者改版本时会不会悄悄改变行为。
接下来值得盯的信号：官方 evaluating-skills 指南会不会工具化（skill-up 已经抢跑）、其他厂商会不会跟进 Skill 评测工具、极简派和重工程派会不会彻底分化为两种写法。
也在写 Skill 的朋友，评论区聊聊：你现在验证 Skill 还好不好使，靠的是什么——跑两下吗？
