首页 › tutorials › Claude Code Skill评测基准与质量工程实战

Claude Code Skill评测基准与质量工程实战

概述

本教程面向已有Skill开发基础的用户,深入讲解Claude Code Skills 2.0引入的评测(Eval)、基准测试(Benchmark)和A/B测试体系。你将学会如何为自定义Skill编写数据驱动的测试用例、运行自动化基准测试、优化触发描述以提升召回率,以及建立持续质量保证流程。适合希望将Skill从"能用"提升到"生产级可靠"的开发者。

适用人群:已掌握SKILL.md基础编写、希望系统化验证和优化Skill质量的中高级开发者。

学习目标: - 理解Skills 2.0评测体系的三层架构(Eval → Benchmark → A/B Test) - 掌握eval用例的编写规范与数据集设计 - 学会使用skill-creator内置的基准测试工具链 - 能够通过trigger优化和description调优提升Skill触发精度 - 建立Skill版本迭代的质量门禁流程


前置条件

项目 要求
Claude Code v1.0.28+(支持Skills 2.0评测功能)
已有Skill 至少一个可运行的SKILL.md文件
skill-creator 通过/install-skill skill-creator安装
基础知识 YAML frontmatter、Markdown指令编写
测试数据 准备3-10组真实使用场景的输入样本

第一章:Skills 2.0评测体系全景

1.1 为什么Skill需要评测?

传统Skill开发流程存在一个核心痛点:"祈祷式发布"——写完SKILL.md,手动测一次,发布,然后祈祷它在各种场景下都能正确触发和执行。这种方式的致命缺陷:

2026年3月3日,Anthropic正式发布Skills 2.0,在skill-creator中集成了完整的评测工具链,彻底改变了这一局面。

1.2 三层评测架构

graph TB
    subgraph "第一层:Eval 单元测试"
        E1[测试用例编写] --> E2[输入-期望输出对]
        E2 --> E3[通过/失败判定]
    end

    subgraph "第二层:Benchmark 基准测试"
        B1[多场景数据集] --> B2[批量运行评估]
        B2 --> B3[量化评分报告]
    end

    subgraph "第三层:A/B Test 对比测试"
        A1[两个Skill版本] --> A2[盲测对比]
        A2 --> A3[统计显著性分析]
    end

    E3 --> B1
    B3 --> A1

    style E1 fill:#e1f5fe
    style B1 fill:#f3e5f5
    style A1 fill:#fff3e0

第一层:Eval(单元测试)——验证单个场景下Skill是否按预期工作。类似于软件工程中的单元测试,每个eval用例定义一组"输入→期望输出"的映射。

第二层:Benchmark(基准测试)——在多个场景上批量运行eval,生成量化评分报告。告诉你Skill的整体表现水平和薄弱环节。

第三层:A/B Test(对比测试)——将两个Skill版本(如原始版 vs 优化版)进行盲测对比,用统计数据判断哪个版本更好。


第二章:Eval用例编写规范

2.1 Eval用例的结构

每个eval用例是一个JSON对象,包含三个核心字段:

{
  "name": "simple-greeting-response",
  "input": {
    "user_message": "帮我写一个Python的快速排序函数"
  },
  "expected": {
    "triggered": true,
    "output_contains": ["def quicksort", "pivot"],
    "output_not_contains": ["bubble sort", "冒泡排序"],
    "behavior_checks": [
      "代码应包含递归调用",
      "应处理空列表和单元素列表的边界情况"
    ]
  }
}

2.2 字段详解

字段 类型 必填 说明
name string ✅ 用例唯一标识,使用kebab-case命名
input.user_message string ✅ 模拟用户输入的消息
expected.triggered boolean ❌ 是否期望Skill被触发
expected.output_contains string[] ❌ 输出必须包含的关键内容
expected.output_not_contains string[] ❌ 输出不应包含的内容
expected.behavior_checks string[] ❌ 语义级别的行为验证描述
expected.tool_calls string[] ❌ 期望调用的工具列表

2.3 设计高质量Eval用例的五条原则

原则一:覆盖正向和负向场景

[
  {
    "name": "positive-api-test-request",
    "input": { "user_message": "帮我写一个REST API的集成测试" },
    "expected": { "triggered": true }
  },
  {
    "name": "negative-unrelated-question",
    "input": { "user_message": "今天天气怎么样" },
    "expected": { "triggered": false }
  },
  {
    "name": "edge-case-ambiguous-request",
    "input": { "user_message": "测试一下" },
    "expected": {
      "triggered": false,
      "behavior_checks": ["不应在模糊请求时盲目触发"]
    }
  }
]

原则二:从真实用户输入取样,不要自己编造

真实用户的表述往往比开发者预期的更模糊、更口语化。从聊天记录、用户反馈中提取真实输入作为eval用例,比手工构造的"完美输入"更有价值。

原则三:用behavior_checks代替精确匹配

避免写output_contains: ["具体的某行代码"],这太脆弱。改用语义级描述:

{
  "expected": {
    "behavior_checks": [
      "生成的代码应包含错误处理逻辑",
      "应解释关键设计决策的理由",
      "代码应可直接运行而不需要额外依赖安装"
    ]
  }
}

原则四:边界条件必须覆盖

{
  "name": "edge-empty-input",
  "input": { "user_message": "" },
  "expected": {
    "triggered": false,
    "behavior_checks": ["空输入不应触发Skill"]
  }
},
{
  "name": "edge-very-long-input",
  "input": { "user_message": "帮我看这段[5000字代码]..." },
  "expected": {
    "triggered": true,
    "behavior_checks": ["应能处理长输入而不截断"]
  }
}

原则五:每个用例只验证一个关注点

不要在一个eval中同时验证触发逻辑、输出格式、工具调用。拆成三个独立用例,失败时能快速定位问题。


第三章:使用skill-creator运行评测

3.1 初始化Eval配置

在Skill目录下创建evals/文件夹,存放测试用例:

my-skill/
├── SKILL.md
├── evals/
│   ├── basic.json          # 基础功能测试
│   ├── edge-cases.json     # 边界条件测试
│   └── regression.json     # 回归测试用例
└── examples/               # 示例文件(可选)
    └── sample-output.md

通过skill-creator交互式创建eval:

# 在Claude Code中调用skill-creator
/skill-creator

# 选择 "Add evals to an existing skill"
# 然后指向你的SKILL.md路径

skill-creator会引导你完成: 1. 选择要评测的Skill 2. 定义测试场景(正向/负向/边界) 3. 自动生成eval JSON文件 4. 放入evals/目录

3.2 手动创建Eval数据集

你也可以手动编写完整的eval数据集文件evals/basic.json:

{
  "skill_name": "api-test-generator",
  "version": "1.2.0",
  "evals": [
    {
      "name": "rest-api-crud-test",
      "input": {
        "user_message": "为用户管理API的CRUD接口写集成测试,base URL是/api/v1/users"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["describe", "it(", "request"],
        "behavior_checks": [
          "应覆盖GET/POST/PUT/DELETE四个方法",
          "应包含状态码断言",
          "应使用测试框架的describe/it结构"
        ]
      }
    },
    {
      "name": "graphql-mutation-test",
      "input": {
        "user_message": "写GraphQL mutation的测试用例"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["mutation", "query"],
        "behavior_checks": [
          "应区分query和mutation的测试",
          "应处理GraphQL错误响应格式"
        ]
      }
    }
  ]
}

3.3 运行Eval

通过skill-creator的评测命令运行:

# 在Claude Code对话中
/skill-creator

# 选择 "Run evals on a skill"
# 输入Skill路径和eval文件路径

skill-creator会逐个执行eval用例,对每个用例:

  1. 注入input.user_message作为模拟用户输入
  2. 检测Skill是否被触发(如果expected.triggered已定义)
  3. 检查输出是否满足output_contains和output_not_contains
  4. 评估behavior_checks中的语义条件
  5. 生成通过/失败判定及详细理由

运行完成后,你会看到类似报告:

╔═══════════════════════════════════════════════════╗
║  Eval Report: api-test-generator v1.2.0          ║
╠═══════════════════════════════════════════════════╣
║  Total: 8 evals                                  ║
║  Passed: 6  ·  Failed: 1  ·  Warning: 1         ║
║  Score: 75/100                                   ║
╠═══════════════════════════════════════════════════╣
║  ✅ rest-api-crud-test        PASSED             ║
║  ✅ graphql-mutation-test     PASSED             ║
║  ✅ websocket-test            PASSED             ║
║  ❌ streaming-api-test        FAILED             ║
║     → output_missing: "应处理分块传输编码"       ║
║  ⚠️  authentication-test      WARNING            ║
║     → behavior_check不确定: 需要人工复核         ║
╚═══════════════════════════════════════════════════╝

3.4 常见Eval失败模式与修复

失败类型 根因 修复方案
触发失败(应触发未触发) description不够精确或trigger条件过窄 扩展description中的同义词和场景描述
误触发(不应触发却触发) description过于宽泛 添加NOT条件,缩小触发范围
输出内容缺失 SKILL.md指令不够具体 增加"必须包含"的明确指令
behavior_check不确定 检查描述太主观 用更具体的可观测条件替代
全部失败 Skill文件有语法错误 检查YAML frontmatter格式

第四章:Benchmark基准测试

4.1 什么是Skill Benchmark

Benchmark是Eval的升级版——它不在单一用例上判定通过/失败,而是在一组代表性场景上量化评估Skill的整体表现,并生成可比较的分数。

flowchart LR
    subgraph "Benchmark流程"
        A[准备数据集<br/>10-50个场景] --> B[运行所有Eval]
        B --> C[收集原始结果]
        C --> D[计算维度评分]
        D --> E[生成综合报告]
    end

    subgraph "评分维度"
        D1[触发准确率<br/>Trigger Accuracy]
        D2[输出质量<br/>Output Quality]
        D3[指令遵循度<br/>Instruction Adherence]
        D4[边界处理<br/>Edge Case Handling]
    end

    D --> D1
    D --> D2
    D --> D3
    D --> D4

4.2 运行Benchmark

# 通过skill-creator运行
/skill-creator

# 选择 "Run benchmark on a skill"
# 指定Skill路径和benchmark数据集

skill-creator内置了两层评测体系:

第一层:快速验证(Quick Check) - 使用5-10个核心场景 - 运行时间约2-3分钟 - 适合开发过程中快速迭代

第二层:深度评测(Full Benchmark) - 使用20-50个覆盖全面的场景 - 运行时间约10-20分钟 - 适合发布前的全面验证

4.3 理解Benchmark报告

╔════════════════════════════════════════════════════════════╗
║  Benchmark Report: api-test-generator v1.2.0              ║
║  Date: 2026-06-11  ·  Model: claude-sonnet-4-6           ║
║  Dataset: 25 scenarios (15 positive + 8 negative + 2 edge)║
╠════════════════════════════════════════════════════════════╣
║                                                           ║
║  📊 Trigger Accuracy:     88/100  (22/25 correct)        ║
║     True Positive:  14/15  ·  False Negative:  1/15      ║
║     True Negative:  8/8    ·  False Positive:  0/8       ║
║                                                           ║
║  📝 Output Quality:       82/100                          ║
║     Completeness:  85  ·  Accuracy: 80  ·  Clarity: 81   ║
║                                                           ║
║  🎯 Instruction Adherence: 91/100                        ║
║     Format compliance: 95  ·  Constraint respect: 87     ║
║                                                           ║
║  🔧 Edge Case Handling:   65/100  ⚠️                     ║
║     Empty input: PASS  ·  Very long: FAIL                 ║
║     Malformed: PASS    ·  Ambiguous: WARNING              ║
║                                                           ║
║  🏆 Overall Score:        81.5/100                        ║
╚════════════════════════════════════════════════════════════╝

关键指标解读:


第五章:Trigger优化——让Skill精准触发

5.1 Trigger精度的核心:description字段

Skill的description字段是触发系统的核心依据。Claude根据description判断何时激活Skill。一个经过评测优化的description通常经历这样的迭代:

初始版本(触发率68%):

---
name: api-test-generator
description: Generate API integration tests
---

问题:太短,无法覆盖用户的各种表述方式。

第一轮优化(触发率82%):

---
name: api-test-generator
description: >-
  Generate integration tests for REST APIs, GraphQL endpoints,
  and WebSocket connections. Use when user asks to write API tests,
  integration tests, or endpoint testing.
---

改进:增加了具体的API类型和用户可能的表述。

最终版本(触发率94%):

---
name: api-test-generator
description: >-
  Generate integration tests for REST APIs, GraphQL endpoints,
  WebSocket connections, and gRPC services. Use when user asks to
  write API tests, integration tests, endpoint testing, route
  testing, or HTTP handler tests. Supports Jest, Mocha, pytest,
  and Go testing frameworks. Also handles test generation for
  authentication flows, rate limiting, error handling, and
  streaming responses. Do NOT trigger for unit tests, performance
  tests, or load tests.
---

关键改进: 1. 扩展了API类型覆盖(增加gRPC) 2. 增加了框架名称(Jest、Mocha等)作为触发关键词 3. 列出了更多用户可能的说法("route testing"、"HTTP handler tests") 4. 明确声明了不触发的场景(NOT trigger条件)

5.2 基于Benchmark数据的Trigger调优流程

flowchart TD
    A[运行Benchmark] --> B{分析False Negative}
    B --> |"有未触发的正向场景"| C[提取用户表述关键词]
    C --> D[将关键词加入description]
    D --> E[重新运行Benchmark]
    B --> |"无False Negative"| F{分析False Positive}
    F --> |"有误触发的负向场景"| G[添加NOT触发条件]
    G --> E
    F --> |"无False Positive"| H[Trigger优化完成]
    E --> I{触发率 ≥ 90%?}
    I --> |是| H
    I --> |否| J[检查Eval用例覆盖度]
    J --> C

实操步骤:

第一步:运行Benchmark,关注Trigger Accuracy的False Negative和False Positive。

第二步:对每个False Negative,记录用户原始表述,提取其中与Skill意图匹配但description中缺失的关键词。

第三步:对每个False Positive,分析为什么Skill在不相关场景被触发,在description末尾添加明确的排除条件。

第四步:更新description后重新运行Benchmark,对比前后差异。

第五步:如果触发率仍未达到90%,检查是否Eval用例的"期望"定义本身有误(有时候不是Skill的问题,而是测试期望写错了)。

5.3 Description写作的黄金法则

法则 说明 示例
开头一句定调 第一句话概括核心功能 "Generate integration tests for APIs"
列出触发场景 用自然语言列举用户可能的请求 "Use when user asks to..."
包含同义词 不同用户可能用不同术语 "tests / specs / test cases"
声明排除范围 明确什么情况下不触发 "Do NOT trigger for..."
提及技术栈 列出支持的框架和工具 "Supports Jest, Mocha, pytest"
控制在150词以内 过长的description反而降低触发精度 聚焦核心场景

第六章:A/B Test对比测试

6.1 何时需要A/B Test

当你对Skill做了一次较大的修改(重构指令、调整输出格式、更换工具调用策略),单凭Benchmark分数的变化不足以判断改进是否真实——因为分数波动可能是随机因素导致的。A/B Test通过多次重复运行消除随机性,给出统计上可靠的结论。

6.2 运行A/B Test

# 在Claude Code中通过skill-creator运行
/skill-creator

# 选择 "Run A/B test between two skill versions"
# 指定版本A(当前版本)和版本B(新版本)的SKILL.md路径
# 选择评测数据集
# 设定运行次数(推荐≥5次以获得统计显著性)

skill-creator会在相同的数据集上,对两个版本进行盲测——评测系统不知道哪个是A哪个是B,避免偏见。

6.3 解读A/B Test结果

╔════════════════════════════════════════════════════════════╗
║  A/B Test Report                                          ║
║  Variant A: api-test-generator v1.2.0 (current)           ║
║  Variant B: api-test-generator v1.3.0 (candidate)         ║
║  Dataset: 25 scenarios  ·  Runs: 5  ·  Total: 250 evals  ║
╠════════════════════════════════════════════════════════════╣
║                                                           ║
║  📊 Overall Score:                                        ║
║     Variant A: 81.5 ± 2.3                                ║
║     Variant B: 87.2 ± 1.8                                ║
║     Delta: +5.7  ·  p-value: 0.023  ✅ Significant       ║
║                                                           ║
║  📊 Trigger Accuracy:                                     ║
║     Variant A: 88.0 ± 3.1                                ║
║     Variant B: 93.6 ± 1.5                                ║
║     Delta: +5.6  ·  p-value: 0.031  ✅ Significant       ║
║                                                           ║
║  📊 Edge Case Handling:                                   ║
║     Variant A: 65.0 ± 5.2                                ║
║     Variant B: 78.3 ± 3.7                                ║
║     Delta: +13.3  ·  p-value: 0.008  ✅ Significant      ║
║                                                           ║
║  🏆 Recommendation: DEPLOY Variant B                     ║
╚════════════════════════════════════════════════════════════╝

关键数据: - Delta:两个版本的分数差。正数表示B更好。 - p-value:统计显著性。小于0.05表示差异不太可能是随机波动。 - ±后面的是标准差:越小表示结果越稳定。

6.4 A/B Test的注意事项

  1. 只改一个变量:如果同时改了description和指令内容,无法归因。每次A/B Test只改一个维度。
  2. 运行次数要够:至少5次重复运行。1-2次的结果不可靠。
  3. 不要忽略负面结果:p-value > 0.05不是失败——它告诉你这次改动效果不显著,可能不值得发布。
  4. 关注标准差:如果标准差很大(>5),说明Skill行为不稳定,需要先解决一致性问题。

第七章:实战案例——从评测到优化的完整闭环

7.1 场景描述

假设我们有一个code-reviewer Skill,用于对代码进行安全审查。我们要通过完整的评测流程将它从v1.0优化到生产级别。

7.2 Step 1:创建初始Skill

---
name: code-reviewer
description: Review code for security vulnerabilities and best practices
---

You are a security-focused code reviewer. When the user provides code:

1. Analyze the code for security vulnerabilities (SQL injection, XSS, CSRF, etc.)
2. Check for common anti-patterns
3. Suggest fixes with explanations
4. Rate severity: CRITICAL / HIGH / MEDIUM / LOW

Output format:
- Use a table for findings with columns: Line, Severity, Issue, Fix
- End with a summary of total findings by severity

7.3 Step 2:创建Eval数据集

evals/security-review.json:

{
  "skill_name": "code-reviewer",
  "version": "1.0.0",
  "evals": [
    {
      "name": "sql-injection-detection",
      "input": {
        "user_message": "Review this code for security issues:\n```python\nquery = f\"SELECT * FROM users WHERE name = '{user_input}'\"\ncursor.execute(query)\n```"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["SQL injection", "parameterized", "CRITICAL"],
        "output_not_contains": ["看起来没问题", "安全"],
        "behavior_checks": [
          "应识别SQL注入漏洞",
          "应建议使用参数化查询",
          "应标记为CRITICAL或HIGH严重级别"
        ]
      }
    },
    {
      "name": "xss-detection",
      "input": {
        "user_message": "Is this React component safe?\n```jsx\n<div dangerouslySetInnerHTML={{__html: userContent}} />\n```"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["XSS", "dangerouslySetInnerHTML"],
        "behavior_checks": [
          "应识别XSS风险",
          "应建议替代方案如DOMPurify"
        ]
      }
    },
    {
      "name": "negative-non-code-input",
      "input": {
        "user_message": "帮我写一个产品需求文档"
      },
      "expected": {
        "triggered": false
      }
    },
    {
      "name": "negative-general-chat",
      "input": {
        "user_message": "你好,今天天气不错"
      },
      "expected": {
        "triggered": false
      }
    },
    {
      "name": "edge-hardcoded-secret",
      "input": {
        "user_message": "Review this config:\n```yaml\ndatabase:\n  host: prod-db.internal\n  password: admin123\n```"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["hardcoded", "password", "CRITICAL"],
        "behavior_checks": [
          "应识别硬编码密码",
          "应建议使用环境变量或密钥管理"
        ]
      }
    }
  ]
}

7.4 Step 3:运行初始Benchmark

假设初始结果:

Trigger Accuracy:  60/100  (3/5 correct)
  ❌ xss-detection failed to trigger
  ❌ edge-hardcoded-secret failed to trigger

Output Quality:    70/100
  ⚠️ sql-injection output missing severity rating

Edge Case:        50/100
  ❌ hardcoded-secret not detected

Overall:          60/100

7.5 Step 4:基于数据的优化

问题一:XSS场景未触发

根因:description只提到了"security vulnerabilities",未包含前端安全、React安全等关键词。

修复:更新description

description: >-
  Review code for security vulnerabilities and best practices.
  Use when user asks to review code, check for security issues,
  audit code, find vulnerabilities, or analyze code safety.
  Covers: SQL injection, XSS, CSRF, hardcoded secrets,
  insecure dependencies, misconfigurations, authentication
  flaws, and data exposure risks. Works with Python, JavaScript,
  TypeScript, Go, Java, YAML config files, and more.
  Do NOT trigger for non-code content like documentation,
  requirements, or general chat.

问题二:硬编码密码未检测到

根因:SKILL.md指令中未明确提到配置文件审查。

修复:扩展指令

You are a security-focused code reviewer. When the user provides code or configuration:

1. Analyze for security vulnerabilities:
   - Injection flaws (SQL, XSS, command injection, LDAP injection)
   - **Hardcoded secrets** (passwords, API keys, tokens in config files)
   - Authentication and authorization issues
   - Data exposure risks
   - Insecure defaults and misconfigurations
   - Dependency vulnerabilities

7.6 Step 5:A/B Test验证优化效果

将v1.0和v1.1进行A/B Test对比:

Variant A (v1.0): 60.0 ± 4.2
Variant B (v1.1): 88.5 ± 2.1
Delta: +28.5  ·  p-value: 0.004  ✅ Significant

Recommendation: DEPLOY Variant B

7.7 Step 6:建立持续回归测试

将每次优化的eval用例归档到evals/regression.json,确保未来修改不会破坏已修复的功能:

{
  "skill_name": "code-reviewer",
  "version": "1.1.0",
  "regression_suite": true,
  "evals": [
    {
      "name": "regression-xss-trigger",
      "input": {
        "user_message": "这个React组件安全吗?\n```jsx\n<div dangerouslySetInnerHTML={{__html: data}} />\n```"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["XSS", "dangerouslySetInnerHTML"]
      }
    },
    {
      "name": "regression-hardcoded-secret",
      "input": {
        "user_message": "Review this config:\n```yaml\napi_key: sk-1234567890abcdef\n```"
      },
      "expected": {
        "triggered": true,
        "output_contains": ["hardcoded", "secret"]
      }
    }
  ]
}

第八章:Skill质量工程工作流

8.1 完整的质量门禁流程

flowchart TD
    A[Skill代码修改] --> B[运行快速Eval<br/>~2分钟]
    B --> C{通过率 ≥ 80%?}
    C --> |否| D[修复问题]
    D --> B
    C --> |是| E[运行完整Benchmark<br/>~15分钟]
    E --> F{Overall ≥ 85?}
    F --> |否| G[分析薄弱维度]
    G --> H[针对性优化]
    H --> E
    F --> |是| I[A/B Test vs 上一版本]
    I --> J{B版本显著更好?}
    J --> |否| K[保留A版本<br/>记录测试结果]
    J --> |是| L[部署B版本]
    L --> M[归档regression eval]
    M --> N[更新版本号]

    style A fill:#e3f2fd
    style L fill:#c8e6c9
    style K fill:#fff9c4

8.2 质量评分标准

等级 Overall Score 发布建议
🟢 Production Ready ≥ 90 可发布到公共市场
🟡 Beta Quality 75-89 可团队内使用,标注Beta
🟠 Experimental 60-74 仅个人使用,需持续优化
🔴 Needs Work < 60 不建议使用,需大幅改进

8.3 自动化回归检测

利用Claude Code的cron/schedule功能,定期自动运行Skill评测:

# 设置每日回归测试(示例)
# 在.claude/settings.json的hooks中配置
{
  "hooks": {
    "post_prompt": [{
      "matcher": "skill-regression-check",
      "command": "claude -p 'Run evals on my code-reviewer skill using evals/regression.json and report results'"
    }]
  }
}

8.4 多模型兼容性测试

同一个Skill在不同Claude模型上的表现可能差异显著。建议在Benchmark中加入模型维度:

{
  "skill_name": "code-reviewer",
  "benchmark_config": {
    "models": ["claude-sonnet-4-6", "claude-opus-4-8", "claude-haiku-4-5"],
    "compare_across_models": true
  }
}

这可以帮助你发现: - 某些behavior_check只在Opus上通过(指令理解差异) - 触发行为在不同模型上一致性如何 - 输出格式在不同模型上的稳定性


第九章:高级调试技巧

9.1 诊断触发失败

当Skill应该触发但没有触发时,使用以下排查步骤:

方法一:直接测试触发

# 在Claude Code中输入
/skill-creator

# 选择 "Test skill triggering"
# 输入你的用户消息
# 查看哪些Skill被考虑以及为什么没被选中

方法二:对比测试

创建一个最小化的Skill,只包含name和description,看是否能触发。如果最小版本能触发,说明问题在SKILL.md的指令内容中。如果最小版本也不能触发,说明问题在description。

方法三:日志分析

# 启用debug模式查看Skill匹配过程
DEBUG=claude:skills claude -p "your test message"

9.2 诊断输出质量问题

问题:Skill触发了,但输出不符合预期。

排查路径:

  1. 检查指令是否明确:把"生成代码"改为"生成包含错误处理的Python 3.11代码,使用类型注解"
  2. 检查格式约束:如果期望表格输出,在SKILL.md中写明"必须使用Markdown表格格式"
  3. 检查示例:在SKILL.md中添加Few-shot示例比纯文字描述有效10倍
## Example Output

When reviewing code with SQL injection:

| Line | Severity | Issue | Fix |
|------|----------|-------|-----|
| 3 | CRITICAL | SQL Injection via string formatting | Use parameterized queries: `cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))` |

**Summary**: 1 CRITICAL, 0 HIGH, 0 MEDIUM, 0 LOW

9.3 诊断一致性差(标准差高)

如果A/B Test中标准差过大(>5),通常是因为:

  1. 指令有歧义:Claude在不同run中对同一指令有不同理解
  2. 缺少结构化输出格式:没有固定的输出模板,每次生成格式不同
  3. 工具选择不稳定:有时选择合适的工具,有时选择不当

修复方案:


第十章:Skill评测最佳实践清单

发布前必做检查

持续维护建议

频率 动作
每次修改后 运行快速Eval
每周 运行完整Benchmark
每次模型更新后 重新运行全套测试
每月 审查并补充eval用例
每季度 A/B Test当前版本 vs 最新最佳实践

延伸阅读


训练营适用性评估

维度 评估
适用训练营类型 AI工程训练营、Claude Code高级训练营、Skill开发者认证班
教学时长 3-4小时(含实操)
前置课程 Skills基础开发课程(Round 2入门篇)
实操占比 60%(eval编写 + benchmark运行 + A/B test分析)
难度等级 ⭐⭐⭐⭐ 中高级
分组建议 2-3人一组,每组负责一个Skill的完整评测优化闭环

参考来源

  1. Extend Claude with skills - Claude Code Docs — Anthropic官方Skills系统完整文档,涵盖创建、管理和分享
  2. Improving skill-creator: Test, measure, and refine Agent Skills - Anthropic Blog — 2026年3月3日发布的Skills 2.0评测体系官方公告
  3. Skill authoring best practices - Claude API Docs — 官方Skill编写最佳实践,包含YAML frontmatter字段规范
  4. How to Eval and Benchmark SKILL.md Skills (2026 Guide) - Agensi — 第三方深度评测指南,包含数据集设计方法
  5. Claude Code Skill Creator: How to Test and Benchmark Your Skills - Nathanonn — 实战导向的评测教程,含视频演示

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入