阿里开源了一套 skill 验证的全流程方法：Skill 不是文档，是可验证交付物

📝

阿里 skill-up 框架的验证方法论实战篇：expect 确定性门槛 + judge 语义判断双层测试、冒烟/边界/端到端三类用例、主路径+兼容路径双路径策略、with_skill/without_skill 基线对比，把「跑通一次」变成「可以交付」。

原文：微信公众号《阿里开源了一套 skill 验证的全流程方法》（作者：Willis）
本文转载自微信公众号，如有侵权请联系删除。

很多团队做 Skill 时，最容易把「跑通一次」当成「可以交付」。在自己的终端里，它读到了正确文件、调用了正确工具、答得也像那么回事；换一个 Agent、换一个模型，或者把输入稍微拧一下，结果就开始漂。

问题通常不只在模型。Skill 的触发描述、说明文件、工具边界、脚本、环境和最终产物，其实连成了一条执行链。没有可重复的测试，团队很难知道改动到底修好了什么，又把哪里弄坏了。

阿里开源的 skill-up，就是把 Agent Skill 当成一件要持续回归的交付物，而不是一份写完就放那里的说明文档。

先把「可用」改成可验证

对 Skill 开发者来说，最先要补的不是更长的 SKILL.md，而是一句能被检验的话：

在给定输入、运行环境和权限边界下，它应该产出什么，绝不能产出什么。

这不只是最后那句自然语言回复，也可能是一个文件、一段结构化数据、一次指定工具调用、一个退出码，或者一个不该被碰的目录。把这些写清楚，Skill 才有工程上的完成态。

skill-up 把测试拆成两层：

确定性的事实先交给确定性规则，语义判断只管它擅长的那一部分——CI 才不会把所有东西都压给另一个模型去「感觉一下」。

好的 Skill 测试集，一开始不需要大，但不能只测「标准输入成功」。更实用的起点，是把团队真遇到过的问题写成 case：输入缺字段、工具返回空结果、命令执行失败、目标文件已经存在、模型理解了任务却没守住输出格式。

这里的 eval.yaml 管运行环境、Agent engine、模型和用例集合；每个 case 放在 case.yaml 里，单独描述输入、期望结果和评分规则。重点不是 YAML 格式本身，而是把「大家默认会这么做」变成一份可以版本管理、重复执行、持续讨论的合同。

用例分三类：

不必每次改动都跑最重的一组——日常提交先跑冒烟和相关边界用例，发布前再跑端到端集，速度和风险都能顾住。

Agent 的差异不只来自底座模型。工具调用格式、上下文装配、权限确认、工作目录和默认提示词，都会改写同一份 Skill 的表现。skill-up 支持在 Claude Code、Codex、Qoder CLI、Qwen Code 等真实 Agent engine 里运行，也允许切换模型配置。

不是要团队无止境地拉组合矩阵，更稳妥的做法是先定主路径，再加一条有代表性的兼容路径：

如果同一个 case 只在某个组合里失败，先看工具、环境和输出协议，再去怀疑模型——把失败归因到可复现的组合，排查才不会变成「哪个模型更聪明」的争论。

skill-up 可以输出 JSON、HTML 和 JUnit XML，也会用退出码告诉你这次评测过没过。这就能接入现有 CI：PR 里先校验配置、跑选定 case、保留结果和产物；一旦失败，就回到失败用例去修 Skill，或者补边界。

如果团队还没有测试资产，可以先从一个真实 Skill 开始：挑 3 个主路径用例 + 2 个以前出过问题的边界用例，先让 expect 覆盖可确定的结果。等稳定下来，再为开放式质量补一小组 judge。每次修复都把 bad case 留下来——评测集会慢慢长成团队自己的可靠性资产。

skill-up 还有 with_skill / without_skill 的基线对比，适合回答另一个常被忽略的问题：这个 Skill 到底让 Agent 更稳定了，还是只是多了步骤和 token。

真正能上线的 Skill，不需要在所有模型、所有任务上都完美。它需要让团队知道：哪些输入和环境已经被覆盖，哪些失败会被拦住，哪些边界还没有承诺。能把这些说清楚、并且持续验证，才是从「看起来能用」走到「可以交付」的那一步。

原文：阿里开源了一套 skill 验证的全流程方法