Skill Comparator

---
name: skill-comparator
description: 对比多个 skill 版本，通过独立实验找出最优版本。当用户提到"对比"、"比较"、"哪个更好"、"A/B 测试"、"评估性能"时使用。也适用于：用户有多个 skill 草稿想选一个、用户想验证 skill 改进是否有效、用户想量化不同 skill 的优劣。即使用户没有明确说"对比"，只要涉及多个 skill 的选择或评估，都应该使用此技能。不适用于：对比普通文件差异（用 diff 工具）、代码审查（用 code-review skill）。
---

# Skill 对比实验技能

## 为什么需要这个技能

手动对比 skill 版本有两个陷阱：

1. **上下文污染**：如果你在同一对话中依次测试多个版本，模型会"记住"前一个版本的行为模式，导致后面的测试结果不纯净。独立子智能体可以彻底隔离每个版本的运行环境。

2. **主观偏差**：人容易受"先入为主"影响——先看的那个版本会觉得"标准"，后面的都跟它比。多维度量化评分能把"感觉"变成"数据"，让对比更客观。

## 核心原则

1. **独立隔离**：每个 skill 版本在独立子智能体中运行。这不是可选的——如果两个版本共享上下文，对比就失去了意义。

2. **公平对比**：所有版本使用完全相同的测试用例和评估标准。测试用例的设计应该聚焦于版本间的差异点，而不是泛泛地"跑一遍看看"。

3. **量化评审**：用 10 分制打分，加权计算总分。主观感受要转化为可比较的数字。

4. **过程可追溯**：所有中间产物保存到 workspace，用户可以随时回溯查看每个版本的实际输出。

## 工作流程

### 阶段1：深度理解版本差异

**目标**：搞清楚每个版本"做了什么不同的事"，而不仅仅是"长得不一样"。

1. **确认对比目标**
   - 用户要对比几个 skill？目录路径是什么？
   - 对比的目的是什么？（选择最优版本、发现改进点、验证优化效果）

2. **读取所有 skill 的完整文件**
   - 逐个读取每个版本的 SKILL.md、references/、scripts/
   - 不只是看结构差异，要理解每个差异对用户意味着什么

3. **生成版本画像并识别差异**
   - 为每个版本写一段简要描述（100字以内）
   - 列出各版本的核心优势和劣势
   - **识别关键差异点**——这是最重要的一步。差异点不是"文件数量不同"这种表面差异，而是"skill-A 没有任务分类但 skill-B 有 A/B/C 分类"这种**行为差异**。

   常见的行为差异类型：
   - 任务路由：是否区分不同类型的任务，走不同工作流
   - 效率优化：是否有快速路径、智能初始化等减少交互的机制
   - 质量保障：是否有事实核查、逐阶段检查等机制
   - 过程管理：是否保存中间文件、是否有错误处理
   - 输出策略：输出的详细程度、格式、结构

### 阶段2：设计测试方案

**目标**：设计能"逼出"差异的测试用例。

1. **设计测试用例**（建议 3-5 个）

   好的测试用例应该让不同版本"暴露"差异。如果两个版本在某个测试上表现一样，这个测试就没有区分度，是浪费。

   设计思路：
   - 每个关键差异至少 1 个测试用例
   - 覆盖不同输入级别（简单输入 vs 详细输入）
   - 覆盖不同任务类型（如果 skill 有多种任务类型）
   - 包含边界情况（如用户只给了一句话、或要求做格式转换）

2. **定义评估维度和权重**

   根据 skill 类型选择 5-7 个最相关的维度，分配权重（总和 100%）。

   参考 `references/evaluation-dimensions.md` 获取通用维度定义和评分标准。根据 skill 类型调整权重：

   | skill 类型 | 重点维度 | 建议权重 |
   |-----------|---------|---------|
   | 内容生成类 | 输出质量、准确性 | 输出质量 25-30%，准确性 20-25% |
   | 效率工具类 | 交互效率、格式转换 | 交互效率 25%，格式转换 20% |
   | 多工作流类 | 任务路由、用户体验 | 任务路由 25-30%，用户体验 15% |

3. **输出测试方案给用户确认**
   - 列出所有测试用例（输入、预期输出、考察点）
   - 列出评估维度和权重
   - 等待用户确认或调整

### 阶段3：并行执行与评审

**目标**：独立执行、客观评审、生成报告。

#### 3.1 准备并启动子智能体

1. **创建 workspace 目录**
   ```
   eval-workspace/
   ├── test-data/              # 测试数据文件
   ├── skill-a-results/test1/ ...   # skill-A 结果
   ├── skill-b-results/test1/ ...   # skill-B 结果
   └── skill-c-results/test1/ ...   # skill-C 结果（如果有）
   ```

2. **为每个版本编写子智能体指令**

   指令结构示例：
   ```
   你是一个 {skill类型} 助手。请严格按照以下 skill 的指令执行任务。

   ## Skill 信息
   - 路径：{skill_path}
   - 名称：{skill_name}

   ## 任务要求
   请依次执行以下测试用例，每个用例独立运行：

   ### 测试1：{测试名称}
   用户输入：
   """
   {完整的用户输入内容}
   """
   
   输出要求：
   - 保存到：{output_path}/test1/
   - 记录执行日志到：{output_path}/test1/execution-log.md
   - 日志包含：交互轮次、任务类型识别、关键行为、遇到的问题

   ### 测试2：{测试名称}
   ...

   ## 重要提醒
   - 严格按照 skill 的指令执行，不要自由发挥
   - 每个测试用例独立执行，不要共享状态
   - 详细记录执行过程，便于后续评审
   ```

   关键要点：
   - 给子智能体明确的 skill 路径，让它自己读取 SKILL.md 和参考文件
   - 测试输入要完整原样给出，不要让子智能体自己编
   - 要求记录执行日志，包含交互轮次、任务识别等关键信息
   - 强调"按 skill 执行"，避免子智能体自由发挥

3. **并行启动所有子智能体**
   - 使用 Agent 工具，设置 `run_in_background: true`
   - 所有版本同时启动，不要串行

#### 3.2 收集结果并评审

1. **读取所有执行日志和输出文件**
   - 提取关键指标：交互轮次、任务类型识别、关键行为
   - 对比各版本的实际输出

2. **多维度评分**（10 分制）
   - 按照阶段2定义的评估维度逐项打分
   - 计算加权总分

3. **生成报告**
   - 评审报告（`review-report.md`）：详细的维度对比和分析
   - 最终报告（`final-report.md`）：实验总结、推荐、改进建议
   - 参考 `references/report-templates.md` 中的模板

4. **输出给用户审核**
   - 展示关键发现和推荐
   - 等待用户确认或提出异议

## 示例对话

**场景1：对比三个 skill 版本**

用户：帮我对比一下这三个 skill 哪个最好
- skill-A: /path/to/skill-alpha
- skill-B: /path/to/skill-beta  
- skill-C: /path/to/skill-gamma

Claude：好的，我来对比这三个 skill。首先我需要读取它们的完整内容，理解各自的工作流程和特性。

[读取三个 skill 的 SKILL.md 和参考文件]

分析完成，发现关键差异：
- skill-A：基础版，所有任务走统一流程，无任务分类
- skill-B：增加了 A/B/C 任务分类和快速路径优化
- skill-C：有逐阶段检查机制，但撰写方案过于精简

基于这些差异，我建议设计 5 个测试用例：
1. 低输入场景（<200字）→ 考察追问和智能初始化能力
2. 高输入场景（>500字）→ 考察快速路径是否生效
3. 优化任务 → 考察 B 类任务路由
4. 格式转换 → 考察 C 类任务路由
5. 事实核查 → 考察数据准确性

评估维度建议：
- 任务路由：20%
- 交互效率：15%
- 输出质量：25%
- 准确性：20%
- 格式转换：10%
- 用户体验：10%

这个方案可以吗？需要调整测试用例或权重吗？

用户：可以，开始测试

Claude：好的，现在启动三个独立子智能体并行执行测试...

[启动子智能体，等待完成]

测试完成！我生成了两份报告：
- review-report.md：详细的维度对比分析
- final-report.md：实验总结和改进建议

关键发现：
- skill-B 综合得分最高（8.93/10），主要优势在任务路由和交互效率
- skill-B 的快速路径将交互轮次从 12 轮降到 1-2 轮
- skill-B 的 B 类优化工作流是独有优势
- skill-C 的过程资产最完整，但缺少优化工作流

推荐采用 skill-B，建议从 skill-C 借鉴过程资产管理策略。

---

**场景2：只对比两个 skill 的效率**

用户：只有两个 skill，对比一下哪个更快
- skill-A: /path/to/skill-alpha
- skill-B: /path/to/skill-beta

Claude：好的，聚焦交互效率对比。先读取两个 skill 的内容...

[读取 skill 内容]

发现 skill-A 无快速路径，skill-B 有快速路径优化。

设计 3 个高输入场景测试用例（最能体现快速路径价值）：
1. 详细工作记录（5天日志）
2. 完整项目文档
3. 多模块复杂任务

评估维度调整：
- 交互效率：30%（提高权重）
- 输出质量：25%
- 准确性：25%
- 用户体验：20%

开始测试...

[执行测试]

结果：skill-B 平均交互轮次 1.3 轮，skill-A 平均 8.7 轮。skill-B 快 6.7 倍。

推荐 skill-B，快速路径优化效果显著。