Skill QA

概述

核心理念

传统测试测"代码做了什么"。AI-native QA 测"Skill 理解了什么"。

Skill 是自然语言指令，AI 可以直接读懂它。你不需要执行它来判断是否正确——就像 senior engineer review PR 时不真的跑代码，而是读代码、理解逻辑、发现风险。

不用的方法：golden file、固定测试集、统计采样（跑 N 次取分布）。这些是把 AI 降维成代码再用旧方法测，方向不对。

用的方法：AI 读 diff → 理解变更 → 推理风险 → 定向探查 → 语义判定。每次从头理解，动态生成评估策略。零维护成本。

输入参数

从用户消息中提取以下参数，缺失时用默认值或主动询问：

执行流程

Phase 0: 前置检查

1. 确认 skill_path 存在且在 git 仓库内：

   cd {skill_path} && git rev-parse --show-toplevel

如果不在 git 仓库内，报错退出："该 Skill 不在 git 仓库中，无法获取 diff。"

1. 获取变更文件列表和行数统计：

   git diff {old_ref}..{new_ref} --stat -- {skill_path}

如果输出为空，报告"无变更"，结束。

1. 获取完整 diff：

   git diff {old_ref}..{new_ref} -- {skill_path}

1. 判断变更规模：
   • trivial：仅文档/措辞/注释变更，无逻辑改动 → review 模式，跳过 Phase 3-4
   • small：1-2 个文件，<50 行变更 → review 模式
   • medium：逻辑变更，50-200 行 → probe 模式
   • large：大规模重构/流程变更，>200 行 → probe 模式，增加探查数量

Phase 1: 理解变更

1. 读取新旧版本的完整 Skill 内容。对 SKILL.md 及 diff 中涉及的所有文件：

   git show {old_ref}:{relative_skill_path}/SKILL.md

新版本直接用 Read 工具读取。

如果 Skill 有 references/ 等子目录文件且在 diff 中，同样读取新旧版本。

1. AI 分析 diff，形成结构化理解：

   {
     "change_type": "logic | feature | refactor | docs | config",
     "change_summary": "一句话描述改了什么",
     "changed_areas": ["具体改动影响的逻辑区域"],
     "change_intent": "为什么改（从 commit message 或 diff 推断）",
     "risk_level": "low | medium | high",
     "scale": "trivial | small | medium | large"
   }

1. 如果 change_type 是 docs 且 risk_level 是 low，标记为 trivial，后续仅做 AI review（Phase 2 + Phase 5），跳过探查。

Phase 2: 生成变更假设

AI 基于理解，生成双向假设。这是整个 QA 的核心——假设质量决定探查质量。

预期变化（Targeted Hypotheses）：2-3 条

• 每条描述"这次改动应该导致什么行为变化"
• 必须关联到 diff 中的具体改动行
• 必须是可探查的（能构造输入来触发）

预期不变（Control Hypotheses）：1-2 条

• 每条描述"不应受这次改动影响的行为"
• 用于检测副作用/回归

风险区域：

• AI 推理出的潜在风险点，不一定有对应假设
• 包括：边界条件、未覆盖的路径、与其他 Skill 文件的交互

关键约束：如果只生成了 targeted 假设而没生成 control 假设，说明没想清楚爆炸半径——重新生成。

Phase 3: 设计探查输入（仅 probe 模式）

基于假设，设计具体探查。每个探查是一个自然语言任务输入，喂给 Skill 执行。

每个探查包含：

{
  "id": "T1",
  "type": "targeted | control",
  "hypothesis_ref": "对应的假设编号",
  "input": "给 Skill 的任务输入（如：'生成一个带用户登录的待办应用'）",
  "probe_style": "socratic | full_execution",
  "focus": "观察重点（如：'新版是否调用了新的认证步骤'）",
  "expected_delta": "targeted: 预期新旧版本有何差异 / control: 预期无差异"
}

探查风格选择：

• socratic（默认）：不完整执行任务，而是问 Skill "如果收到这个输入，你会怎么做？第一步是什么？"——测理解，成本低
• full_execution：实际让子代理执行任务——测行为，成本高，仅用于高风险探查

数量限制：

• medium 变更：2 targeted + 1 control
• large 变更：3 targeted + 2 control
• 最多 5 个探查

输入设计原则（详见 references/probe-design.md）：

• 输入要尽量简单，降低执行成本
• 靶向输入要精准触发改动路径
• 控制输入要明确不触及改动路径

Phase 4: 执行探查（仅 probe 模式）

对每个探查，启动两个子代理分别执行新旧版本：

4.1 旧版本执行

通过 Agent tool 启动子代理（subagent_type: "general-purpose"，max_turns: 8）：

子代理 prompt 结构：

你是以下 Skill 的执行者。请严格按照下面的 Skill 指令来处理任务。

--- Skill 指令（旧版本 {old_ref}）---

{old_skill_full_content}

--- 任务 ---

{probe.input}

--- 要求 ---

请按照 Skill 指令的流程处理上述任务。
如果是 socratic 探查：描述你会如何处理这个任务，第一步做什么，用什么工具，预期产出什么。不需要实际执行。
如果是 full_execution 探查：实际执行任务，产出最终结果。
最后用一段话总结你的处理方式和关键决策。

捕获子代理返回的结果作为 old_behavior。

4.2 新版本执行

同样启动子代理，使用新版 Skill 内容。捕获结果作为 new_behavior。

4.3 语义对比

AI 对比 old_behavior 和 new_behavior：

• targeted 探查：
  • 新旧输出体现了预期差异？→ confirmed（改动生效）
  • 新旧输出没有差异？→ no_change（改动可能没生效，no-op）
  • 出现了预期之外的差异？→ unexpected
• control 探查：
  • 新旧输出语义等价？→ no_regression（安全）
  • 新旧输出有差异？→ regression（副作用，需关注）

成本控制

• 子代理 max_turns 限制为 8
• 如果前 2 个 targeted 探查都 confirmed，可跳过剩余 control 探查
• 如果任一探查发现 regression，继续完成所有探查以收集完整信息
• socratic 探查远比 full_execution 便宜，优先使用

Phase 5: 判定 & 报告

5.1 综合判定

5.2 生成报告

按 references/report-template.md 的格式，将所有 Phase 的结果汇总写入 {report_path}。

报告必须包含：

1. 变更摘要（diff 统计 + AI 理解）
2. 变更假设（targeted + control + 风险）
3. 探查结果（每个探查的输入、新旧行为、判定）—— probe 模式
4. AI review 结论 —— review 模式
5. 综合判定
6. 风险清单 + 可执行建议

5.3 展示报告

用 present_files 展示生成的报告文件。

重要约束

1. 不做统计采样：每个探查只跑一次。结果模糊时 AI 判断是否需要重跑，而不是默认跑 N 次。如果同一个输入跑两次结果不一致，那说明 Skill 指令有歧义——这本身是 bug，报告中标出。
2. 测理解不测措辞：探查评估 Skill 是否展示了正确的理解和流程，不是输出文本是否逐字匹配。两个版本用不同措辞但相同逻辑的输出视为等价。
3. 假设可追溯：每个探查必须关联到一个假设，假设必须关联到 diff 中的具体改动。不可追溯的探查是无效的。
4. 报告建议必须可执行：不写"建议关注 XXX"。写"在 SKILL.md 第 42 行的模板选择逻辑中增加对 Vue 项目的判断，否则会选错模板"。具体到文件、行号、行动。
5. 成本意识：review 模式零额外 LLM 成本。probe 模式最多 10 个子代理调用（5 探查 × 2 版本）。如果用户没指定模式，根据变更规模自动选择。
6. 不修改被测 Skill：这个 QA Skill 只读取和分析被测 Skill，永远不修改它。报告是唯一输出物。