从"能运行"到"可交付"，Skill正在复刻软件工程二十年前走过的路
大家好，我是某互联网公司的测试架构师。
上个月，团队里一个同事跑来跟我说："老大，我那个测试用例生成的Skill，昨天还好好的，今天突然不行了。我没改任何东西啊。"
我问他："你换模型了？"
他愣了一下："哦，好像是自动更新了……"
他没改Skill，但模型变了。大模型版本从Claude Sonnet 4.0切到了4.5，Skill的行为就跟着漂了。
他没改一行代码，Skill却"退化"了。
这个问题让我想了很久：当一个Skill也需要回归测试的时候，我们是不是已经走到了软件工程二十年前的老路上？
然后，阿里开源了skill-up。
一、Skill的"质量裸奔"困境
2026年走到现在，Agent Skill已经成了AI领域的标配。把个人经验沉淀成SKILL.md，把团队最佳实践封装成可复用的技能包，这些都已经是很常规的操作了。
一份SKILL.md，配上脚本、工具声明和领域知识，就能让Agent获得一项相对完整的能力：代码审查、依赖升级、数据分析、发布计划、故障排查、测试执行。
但当越来越多Skill开始进入真实项目，问题也随之发生了变化。
过去大家关心的是：这个Skill能不能运行？
现在更应该追问：它能不能稳定运行？修改之后会不会退化？换一个Agent引擎还能不能正常工作？
一个Skill的行为通常受到多种因素影响：SKILL.md中的自然语言描述、工具名称和工具说明、Agent引擎的执行机制、大模型版本与参数、用户输入的具体措辞、上下文长度与历史会话、文件脚本和运行环境、外部API与MCP工具返回结果。
即使只是修改SKILL.md中的一句话，也可能改变Agent的工具选择、执行顺序和输出结果。
举个例子：一个发布计划Skill原本会调用工具创建计划，修改描述后却退化成了纯文本回复；一个文件清理Skill原本会在删除前询问用户，调整Prompt后却开始直接执行；一个代码审查Skill在Claude Code中运行正常，换到Codex后却漏掉了关键检查项。
这些问题很难通过传统代码Diff直接发现。没有评测集时，团队只能依靠开发者手工运行、肉眼观察和经验判断。
"依赖人工记忆维护质量"，往往正是工程失控的开始。
在测试领域，有一项铁规：绝不会允许一个没有用例、没有回归、没有质量门禁的系统直接上线。但到了Skill这件事上，几乎所有人都在裸奔。
原因也不复杂。Skill的本质是提示词工程，SKILL.md改一个字，行为就可能漂移。
二、skill-up：把软件测试的方法论完整平移
直到阿里开源了skill-up。
skill-up，用一句话来概括就是：The evaluation and evolution tool for Agent Skills。Go语言写的，开源两个月，更新很活跃。
它干的事，用测试人的话说，就是把软件测试那套方法论，完整地平移到了Skill上。
你可以用它验证Skill在真实Agent Engine（如Claude Code、Codex、Qoder CLI）中的功能正确性，把失败转化为有针对性的修复，并在本地或CI中持续回归。
skill-up的设计围绕两个互补的能力：
评测（Evaluation）：让Skill质量可度量、可复现。声明式YAML用例可在多个Agent Engine中运行，通过规则、脚本或Agent Judge评分，并在本地或CI中生成结构化报告。
演进（Evolution）：把评测结果变成下一轮改进。通过对话，skill-upper读取失败、自动修复或补充eval用例、重新运行skill-up，并与你持续迭代。
先看它给一个Skill项目规定的标准结构：
my-skill/
├── SKILL.md # Skill定义文档，被测对象
├── evals/
│ ├── eval.yaml # 评测入口配置（必须）
│ └── cases/
│ ├── basic-success.yaml
│ ├── edge-case-null.yaml
│ └── regression-001.yaml
├── fixtures/ # 测试资源（可选）
└── scripts/ # 评估脚本
眼熟吗？这就是一个标准的测试工程目录。cases/是你的测试用例集，fixtures/是你的测试数据和脚手架，eval.yaml是评测的全局配置，定义了"在什么环境中、用什么Engine、怎么评估"。
一个真正的"可交付"Skill，应该有自己配套的评测用例——就像一段线上代码有自己的单元测试一样。
三、三种Judge：规则、脚本、Agent
skill-up支持三种评测策略：
Judge类型
适用场景
rule_based
可量化验证：文件是否存在、正则匹配、退出码
script
需要自定义逻辑：调用外部脚本做复杂校验
agent_judge
需要语义判断：Agent输出是否符合预期行为
agent_judge是给AI评测AI——给Judge Agent一个rubric（评分标准），让它判断被测Agent的输出是否达标。这让评测覆盖了那些无法用规则和脚本判断的场景。
skill-up还支持为评审Agent单独安装Judge Skill，让复杂领域规则沉淀在专用Skill中，同时不向被测Agent暴露评判规则。这样可以减少被测Agent"迎合判题器"的风险。
四、四引擎支持 + CI集成
一个Skill应该在多个Agent引擎上都表现一致。skill-up内置支持四个引擎：
引擎
标识
Claude Code
claude_code
Codex
codex
Qoder CLI
qodercli
通义灵码
qwen_code
自定义
engine.custom
同一个eval suite可以跨引擎跑。GitHub Action里一行配置就能让PR同时检测Claude Code和Codex下的表现差异。
同一套流程既可在本地运行，也可接入CI，同时兼容Anthropic evals.json导入，并输出JSON、JUnit和HTML报告。
五、怎么上手？三步走
第一步：安装skill-up CLI
curl -fsSL https://raw.githubusercontent.com/alibaba/skill-up/main/install.sh | bash
第二步：安装skill-upper（推荐入口）
Claude Code，全局安装
npx skills add https://github.com/alibaba/skill-up/tree/main/skills/skill-upper -g -a claude-code -y
Codex，全局安装
npx skills add https://github.com/alibaba/skill-up/tree/main/skills/skill-upper -g -a codex -y
通常不需要提前安装skill-up。skill-upper运行时会检查CLI；如果缺失，它会引导Agent完成安装。
第三步：让Agent驱动评测
在AI Agent中打开包含SKILL.md的Skill项目，然后直接对话：
"使用skill-upper给这个Skill添加评测。添加这个评测用例：输入是'写一个hello world的程序'，评测是否包含hello和world打印。然后运行skill-up完成校验和评测。"
Agent会生成类似结构：
my-skill/
SKILL.md
evals/
eval.yaml
cases/
basic.yaml
my-skill-workspace/
iteration-1/
result.json
首次运行后，继续与Agent对话：
"使用skill-upper检查最近一次skill-up的评测结果。逐项诊断失败，修复SKILL.md或配套文件；如果评测覆盖不足，补充或改进eval用例，然后重新运行skill-up。"
持续迭代直到评测通过。每轮迭代都会让Skill实现和eval评测集保持同步，使修复沉淀为回归保障，而不是一次性补丁。
六、对测试从业者意味着什么
skill-up值得测试人员关注的原因，并不只是阿里又开源了一个AI工具。
Agent Skill正在从个人Prompt资产，逐渐变成需要版本管理、自动化测试和持续回归的软件工程资产。
软件开发早期同样追求"先跑起来"。功能能用、接口能通、页面能打开，就算完成了第一阶段目标。但系统规模扩大后，团队很快发现，仅仅能运行远远不够。代码改动有没有破坏原有行为？不同环境下的结果是否一致？新版本上线后有没有引入回归问题？
正是这些问题，推动了单元测试、接口测试、自动化回归、持续集成和质量门禁的发展。
Agent Skill现在也走到了相似的阶段。
对测试人来说，这意味着三件事：
第一，测试方法论有了新战场。 你写单元测试、做回归测试、建质量门禁的经验，在Skill评测领域可以直接复用。skill-up的整个设计——声明式用例、三种Judge、跨引擎验证——就是把软件测试的那套方法论平移到了Skill上。
第二，Skill评测本身需要测试思维。 NVIDIA在实验总结中强调，Skill评测是否可靠，很大程度取决于评测数据集的设计质量。评测集要覆盖正常路径、边界场景、异常场景、回归场景——这和你设计测试用例的逻辑完全一致。
第三，一个新的职业方向正在形成。 字节、阿里已经在招"Skill工程师"了。阿里"通义实验室-技术专家-测试开发"岗位要求熟练掌握机器学习算法原理和应用。这不是在招技术专家，这是在招能设计AI测试系统的人。
七、避坑指南
坑一：评测集只覆盖成功路径
很多团队写评测用例只会写"帮我生成一份发布计划"，然后检查是否输出了"发布计划"几个字。
解法： 评测集要覆盖失败场景、边界场景、异常场景。参数缺失时Skill怎么处理？工具调用失败时怎么降级？这些才是真正容易出问题的地方。
坑二：用agent_judge验证一切
agent_judge适合评估"输出质量"这类主观判断，但不适合验证"工具是否被正确调用"这类确定性行为。
解法： 确定性操作用rule_based或script验证，agent_judge只用于需要语义判断的场景。不要把确定性和非确定性混在一起测。
坑三：评测集建完就不管了
Skill在变、模型在变、业务在变，评测集也需要跟着变。
解法： 每发现一个Skill线上问题，补充一条对应的回归用例。评测集不是一次性工程，是持续积累的资产。
最后
从"能运行"到"可交付"，Skill正在经历软件工程二十年前走过的路。
不是我们故意把问题搞复杂了——是当Skill从"个人玩具"变成"团队基础设施"的时候，它自然就需要配套的质量保障体系。
一个人写一个Skill，可以靠手测。十个人维护五十个Skill，就必须靠自动化回归。
阿里开源skill-up这件事，本质上是在回答一个问题：Skill不能只靠"感觉"来维护，它需要被测试。
而测试人，恰好就是最擅长做这件事的人。
下次你写完一个Skill的时候，别急着说"做好了"。先问自己一句：
"这个Skill，有评测用例吗？"
如果没有，那它还不算"可交付"。
