Skill 的回归测试与质量基线
High Contrast
Dark Mode
Light Mode
Sepia
Forest
2 min read391 words

Skill 的回归测试与质量基线

Skill 的质量不是一次性的事——每次修改 Skill 文件（改进提示词、添加步骤、调整参数）都可能意外破坏之前正常工作的场景。建立回归测试机制，确保 Skill 在迭代中保持稳定。

什么是 Skill 的"回归"

Skill 的回归是指：修改 Skill 文件后，某个之前正常工作的测试用例开始失败。

典型回归场景：

原来：/review-pr 在没有 --focus 参数时做全面检查（预期行为）
修改后：在步骤中添加了"当 --focus 为 security 时，跳过性能检查"
结果：无意中改变了逻辑，导致没有 --focus 时输出为空
→ 这就是回归

建立质量基线

质量基线是一组参考输出，用于对比新版本的输出是否发生了不期望的变化。

创建基线文件

mkdir -p .claude/skills/tests/baselines

为每个重要场景保存一个基线文件 .claude/skills/tests/baselines/review-pr-normal.md：

# 测试基线：review-pr / 正常场景
## 测试输入
命令：/review-pr --branch feature/add-login
## 关键结构要求（必须包含）
- [ ] 包含 "## PR 审查报告" 标题
- [ ] 包含 "修改文件数" 信息
- [ ] 包含 "### 🔴 严重问题" 或 "### ✅ 通过检查" 至少其中一个
- [ ] 包含 "审查覆盖" 结尾行
- [ ] 不包含 "未知错误" 或 "无法执行" 等失败标志
## 关键内容要求（内容相关）
- [ ] 提到了被审查的分支名（feature/add-login）
- [ ] 有具体的代码文件被提及（不是空报告）
- [ ] 如果发现问题，问题有文件:行号定位
## 禁止出现的内容
- [ ] "我无法执行此操作"
- [ ] "我需要更多信息"
- [ ] 空的问题列表（如果分支确实有修改）
## 最后验证通过日期
2026-03-22
## 版本历史
| 日期 | 变更内容 | 是否通过 |
|------|---------|---------|
| 2026-03-22 | 初始建立基线 | ✅ |

回归测试的执行流程

graph LR A["修改 Skill 文件"] --> B["确定影响的测试用例"] B --> C["运行受影响的测试用例"] C --> D{"与基线对比"} D -->|结构/内容符合基线| E["✅ 无回归，可以提交"] D -->|发现差异| F["判断差异类型"] F -->|预期的改进| G["更新基线文件"] F -->|意外的回归| H["修复 Skill 或回滚修改"] G --> E H --> C style E fill:#e8f5e9,stroke:#2e7d32 style H fill:#ffebee,stroke:#c62828

Skill 版本管理

Skills 以文件形式存在于 Git 中，天然支持版本管理：

Git 工作流

# 修改 Skill 前，创建分支
git checkout -b skill/improve-review-pr
# 修改 .claude/skills/review-pr.md
# 运行测试（手动），验证无回归
# 提交时写清楚变更内容
git add .claude/skills/review-pr.md
git commit -m "skill(review-pr): add --depth parameter for dependency analysis
- Add --depth param (quick|full), default: quick
- quick: only analyze directly modified files
- full: also analyze import chain (1 level deep)
- All existing test cases verified with no regression"
# PR 审查：让团队成员确认 Skill 的变更
git push origin skill/improve-review-pr
# → 创建 PR 请求 review

CHANGELOG for Skills

在 .claude/skills/CHANGELOG.md 中记录重要变更：

# Skills CHANGELOG
## [2026-03-22]
### review-pr
- 新增 `--depth` 参数，支持 `quick`（默认）和 `full` 两种分析深度
- 修复：`--focus security` 时不再遗漏对 `.env` 文件的检查
### pre-deploy
- 优化：production 环境检查在测试失败时现在会立即终止（之前继续执行）
- 新增：生成检查报告时同时写入 `.claude/audit.log`
## [2026-03-15]
### standup（新增）
- 初始版本：生成 7 天内的 Git 提交摘要

Skill 质量评分卡

为团队建立一个标准化的 Skill 质量评估工具。创建 .claude/skills/quality-checklist.md：

# Skill 质量评估清单
在合并新 Skill 或重大修改前，使用此清单评估质量。
## 基础要求（必须全部满足）
### 文件结构
- [ ] Frontmatter 包含 `description` 字段
- [ ] `allowed-tools` 已声明且只包含必要工具
- [ ] 有清晰的"目标"/"背景"说明
- [ ] 有详细的"执行步骤"
- [ ] 有明确的"输出格式"
### 参数设计
- [ ] 所有必填参数有缺失检查和用法说明
- [ ] 所有枚举参数有值验证
- [ ] 所有可选参数有默认值说明
- [ ] 有调用示例（至少 2 个）
### 安全性
- [ ] 没有硬编码的 API 密钥或密码
- [ ] 高风险操作（删除、修改生产环境）有确认机制
- [ ] 错误情况下不会意外执行破坏性操作
- [ ] `allowed-tools` 中没有过多权限
## 质量要求（建议满足）
### 可靠性
- [ ] 至少有 3 个测试用例（正常/边界/错误场景）
- [ ] 所有测试用例通过
- [ ] 有基线文件
### 用户体验
- [ ] 错误提示清晰，有具体的修复建议
- [ ] 输出格式一致，不依赖 Claude 的随机创造性
- [ ] 执行时间合理（复杂分析说明预计时间）
### 团队协作
- [ ] 在 `.claude/skills/README.md` 中已添加索引条目
- [ ] Git commit message 清楚说明了变更内容
- [ ] 如果修改了现有 Skill，已更新 CHANGELOG
## 评分
满足所有"基础要求"：可以合并
满足所有"基础要求"+ 80% 的"质量要求"：高质量 Skill

本节记录清单

下一章：团队 Skills 库：组织、分发与版本管理——你的 Skill 已经稳定可靠，现在如何让整个团队都能用上它？