Skill 的回归不一定表现为“模型突然完全不会了”。更常见的是小改动改变了行为边界：description 变了，智能体不再触发；主提示词增加了一项要求，输出开始编造细节；引用文件换了路径，关键规则没有加载；模型升级后，原本稳定的行为开始漂移。
所以“文件能解析、静态检查通过”不能代替回归验证。
先按变更类型看影响
不同变化影响的运行时环节不同：
| 变更 | 可能影响 | 最小关注点 |
|---|---|---|
description | 发现、触发、选择 | 正向、异常、边界 |
SKILL.md 工作流 | 行为、输出、轨迹 | 行为、回归、必要时运行时 |
| 参考资料 | 知识、引用和边界 | 相关用例、引用完整性 |
| 脚本或模板 | 产物、副作用 | 脚本、产物、副作用 |
| 评测预期 | 证据解释和回归可信度 | 评测有效性、评判器校准 |
| 模型或智能体 | 触发和输出稳定性 | 多次运行、兼容性 |
变更范围决定回归范围。跑了全量静态检查，不代表覆盖了真正变化的行为。
把真实失败沉淀为回归用例
SQEM 建议把真实失败整理成可重复的回归用例：
观察到失败
-> 保存证据
-> 复现
-> 分类
-> 确认根因
-> 修复
-> 回归用例
-> 现有用例集
-> 发布证据这里的关键不是“失败出现过”，而是已经确认它是什么问题。没有根因的失败，可能来自 Skill、评测、基础设施或未知条件；直接加入回归套件只会把噪声保存下来。
用 skill-change-verification 选择最小验证
skill-change-verification 的职责是根据变更范围选择最小但足够的检查，并准确说明证据能支持什么结论。它要求把变更分为内容、元数据/目录、脚本、评测和运行时影响，再记录命令、结果、未执行项和残余风险。
一个实际变更可能是：只修改了 functional-testing 的 description，新增一个触发短语。合理的最小验证应关注：
- 结构和元数据仍然合法；
- 原有正向用例仍能触发；
- 异常和边界用例没有新增误触发；
- 如果缺少
skill.selection追踪记录，状态写成BLOCKED，不猜测； - 输出结论只覆盖真正运行过的智能体和模型。
没有必要因为改了一行 description 就重跑所有高成本基准测试，但也不能只看 git diff 就说“没有影响”。
拉取请求、发布和定期检查
变更验证可以按所需时间和成本分层：
拉取请求阶段
静态验证
关键评测
变更 Skill 的评测
回归冒烟检查发布阶段
全部相关评测
回归测试套件
选定的基准测试
选定的兼容性测试
证据报告定期检查阶段
跨模型测试
跨智能体测试
扩展基准测试
长期回归测试这样可以把低成本、确定性强的反馈留在拉取请求阶段，把成本更高、波动更大的检查放到发布或定期任务中。
回归报告应该写什么
一个可复核的报告至少说明：
- 变更版本和影响范围；
- 执行了哪些用例；
- 使用的智能体、模型、工具和环境；
- 每条结论的状态和证据等级；
- 哪些检查没有执行，以及为什么；
- 是否发现 Skill、评测、基础设施或原因未知的问题；
- 修复后新增了哪条回归用例。
“全量检查通过”不是完整报告。它没有告诉下一位维护者全量检查到底覆盖了什么。
回归测试和基准测试不是一回事
回归测试比较旧版本和当前版本，问的是“有没有破坏既有行为”。基准测试比较不使用 Skill 和使用 Skill，问的是“有没有带来增益”。
同一版本的回归测试可以通过，但基准测试仍未证明 Skill 有效；反过来，基准测试显示出增益，也不代表某次 description 修改没有漏掉边界用例。
把两个结果分开记录，讨论会简单很多。
怎样把一条回归用例写完整
一条真实失败记录，只有整理成别人可以重新运行的用例后，才有价值。至少把六件事放在一起：观察到的症状、发生变化的范围、已经确认的根因、能够暴露问题的最小输入、预期保持稳定的行为，以及证明结果的产物。
比如修改 description 后，一个常见请求不再触发目标 Skill，就保存这个请求和相邻的异常请求，记录旧版本与当前版本的选择结果，并说明边界为什么发生了变化。回归用例只覆盖最相关的部分，不要因为原始失败很复杂，就悄悄把它扩成一次完整的基准测试。
用例还需要维护规则。如果预期行为发生变化，就同时更新预期和变更原因；如果只是实现发生变化，但行为应该保持稳定，就保留用例并重新运行。没有负责人维护的回归套件，最后会变成堆满旧假设的博物馆。
安装与调用
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill skill-change-verification请使用 skill-change-verification Skill。
变更范围：修改 functional-testing 的 description，增加一个中文触发短语。
请选择最小但充分的静态检查、触发检查、边界检查和回归检查。
记录已执行的命令及结果、未执行项目、证据等级和残余风险。
没有 skill.selection 证据时标记为 BLOCKED，不要推断触发成功或失败。两个实际问题
只改参考资料，也需要回归吗？
需要。引用内容可能改变判断、边界和输出。先评估引用是否会影响核心行为，再选择相关用例，不必机械地跑所有项目。
回归全部 PASS，就能写“没有任何风险”吗？
不能。回归只覆盖已选择的历史和代表性行为。环境、模型、未执行用例和新输入仍然可能存在缺口。