Featured image of post Skill 从入门到精通——第四章 Anthropic 官方Skill解析—skill-creator Skill 解析

Skill 从入门到精通——第四章 Anthropic 官方Skill解析—skill-creator Skill 解析

skill-creator是 Anthropic 官方推出的**元技能(Meta-Skill)**,即用来创建 Skill 的 Skill——用于从创建、评估、优化到打包分发Skill的全流程。涵盖技能开发全生命周期:

Skill 从入门到精通——第四章 Anthropic 官方Skill解析—skill-creator Skill 解析

4.1.17 skill-creator Skill 解析—Skill 开发、评估与优化

一、技能概述

skill-creator 是 Anthropic 官方推出的元技能(Meta-Skill),即用来创建 Skill 的 Skill——用于从创建、评估、优化到打包分发Skill的全流程。涵盖技能开发全生命周期:

  • 从零创建新 Skill:从零引导用户明确使用意图、编写 SKILL.md 规范、组织目录结构。
  • 评估:通过子代理并行执行测试用例、量化评分结果。
  • 迭代改进:通过测试→评估→反馈→修改的循环,迭代优化技能内容,持续提升 Skill 的质量。
  • 描述优化:通过触发率评估 + 自动改进循环优化 description 字段,提升技能触发准确性。
  • 打包分发:将技能目录一键封装为 .skill 格式安装包,便捷部署复用。

该技能通过"创建 → 测试 → 评估 → 改进 → 重复迭代"的循环流程,将 Skill 的创建过程从"手工编写 Markdown"升级为"可测试、可衡量、可迭代改进的工程化流程"。

触发场景: 用户表达"创建技能"、“优化 Skill 描述”、“评估技能效果”、“改进现有技能”、“打包技能”等意图时自动激活。

二、项目文件结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
skill-creator/
├── SKILL.md                          # 核心指令文件,完整工作流指令
├── LICENSE.txt                       # 许可证
├── agents/                           # 子代理指令
│   ├── analyzer.md                   # 事后分析代理:盲比较结果归因 + benchmark基准模式分析
│   ├── comparator.md                 # 盲比较代理:对 A/B 输出进行无偏见质量裁决
│   └── grader.md                     # 评分代理:对断言进行 PASS/FAIL 判定,并评判 eval 本身
├── assets/
│   └── eval_review.html              # 触发率评估集审核模板(用户编辑后导出)
├── eval-viewer/
│   ├── generate_review.py            # 评估查看器生成器:扫描workspace、嵌入数据、启动HTTP服务
│   └── viewer.html                   # 查看器前端模板
├── references/
│   └── schemas.md                    # JSON Schema 定义
└── scripts/                          # 可执行脚本集
    ├── __init__.py                   # 空包初始化
    ├── aggregate_benchmark.py        # 基准聚合:从 grading.json 计算 mean/stddev/delta
    ├── generate_report.py            # HTML 报告生成:为描述优化循环输出可视化
    ├── improve_description.py        # 描述优化:基于 eval 结果调用 Claude 生成改进描述
    ├── package_skill.py              # 打包器:验证 + 压缩为 `.skill` 分发文件(ZIP 格式)
    ├── quick_validate.py             # 快速校验:YAML frontmatter 合法性、命名规范、长度限制
    ├── run_eval.py                   # 触发评估:通过 `claude -p` 测试 description 触发准确率
    ├── run_loop.py                   # 优化主循环:train/test 拆分评估 + 多轮迭代 + 自动报告
    └── utils.py                      # 共享工具:解析frontmatter 的 name/description

各目录说明:

  • agents/ :用于存放特定子代理指令。定义了三个子代理:事后分析代理、盲比较代理和评分代理;当 Claude 需要进行评估、对比、分析时,会读取这些文件来获得专业指导。

  • assets/:存放模板文件、图标、字体等静态资源。

  • eval-viewer/: 可视化工具。面向人类用户的可视化窗口,将枯燥的 JSON 评测数据转化为直观的网页界面,让用户可以方便地查看输出、对比结果、留下反馈。

  • references/:存放按需加载的参考文档。目前仅有一个文件 schemas.md,它定义了 skill-creator 中所有 JSON 数据结构的 Schema。

  • scripts/ :存放可执行的脚本代码。所有需要确定性执行(deterministic execution)的自动化任务都封装为脚本,而不是让 AI 自由发挥。

    脚本 功能 核心依赖
    run_loop.py 主循环编排器:编排"评估→改进描述→重新评估"的完整循环 run_eval.py, improve_description.py
    run_eval.py 运行触发评估测试:检测 Skill 描述是否能被正确触发 claude -p CLI
    improve_description.py 调用 Claude 来自动改进 Skill 描述 claude -p CLI
    aggregate_benchmark.py 将多次运行的评分数据聚合为统计汇总 grading.json 文件
    generate_report.py 从 run_loop 的输出生成可视化 HTML 报告 优化循环输出
    package_skill.py 将 Skill 目录打包为 .skill 文件(zip 格式) quick_validate.py
    quick_validate.py 快速校验 Skill 文件格式合规性 SKILL.md
    utils.py 共享工具函数(解析 SKILL.md frontmatter)

三、整体流程

image-20260527083109462

整体工作流程如下:

  1. 需求捕获 :从零引导用户明确意图、能力边界、触发场景、确定输出格式。
  2. 创建Skill :编写 SKILL.md 规范(含 YAML frontmatter + 指令主体),组织目录结构,准备辅助资源;编写2-3 条测试用例。
  3. 运行测试: 并行启动 with_skill 和 without_skill 两组子 Agent(A/B 测试) → 利用等待时间起草量化断言 → 捕获 timing 数据 。
  4. 评估与集合汇总: Grader 评分 → 聚合基准数据 → Analyzer 分析 → 生成 Eval Viewer。
  5. 用户反馈:用户在浏览器中评审 → 收集用户反馈feedback.json。
  6. 迭代改进: 分析用户反馈 + 量化数据 → 重写 SKILL.md→ 新迭代运行(新iteration-N+1/目录)→ 重复直到:用户满意 / 无新增feedback / 无明显进展。
  7. 盲评对比:并行运行两个 Skill 版本 → 输出 A / B → 盲评打分(读取agents/comparator.md) → Post-hoc Analyzer(事后归因分析) → 输出可落地改进建议。(当用户问如"新版本真的更好吗?“时执行)
  8. 优化描述: 生成触发评估查询( 生成 20 条 should-trigger + should-not-trigger)→ 用户审核(增删、修正) → 运行优化循环(python -m scripts.run_loop,迭代上限5轮:数据集拆分60% 训练集 / 40% 测试集→并行评估 → 失败归因 → 生成新 description) → 从JSON输出中获取best_description并更新技能描述。
  9. 打包发布: 调用 scripts.package_skill 打包 → 输出 .skill 文件。

四、SKILL.md 结构概览

SKILL.md 是 Skill 的唯一必需文件,是理解 Skill 设计的最佳范本。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
---
name: skill-creator                          # 【元数据】Skill标识符
description: Create new skills...           # 【元数据】触发机制(最重要!)
---

# Skill Creator                              # 【正文】标题

## 总体介绍                                  # 【正文】哲学与流程

## Communicating with the user               # 【正文】沟通风格指南

## Creating a skill                          # 【正文】创建流程
  ### Capture Intent                          # 捕捉意图
  ### Interview and Research                  # 调研访谈
  ### Write the SKILL.md                      # 编写指南
    #### Anatomy of a Skill                  # 目录结构
    #### Progressive Disclosure                # 渐进式披露
    #### Principle of Lack of Surprise         # 安全原则
    #### Writing Patterns                    # 写作模式
  ### Test Cases                              # 编写2-3条实际场景的测试用例,进入下一步运行评测

## Running and evaluating test cases         # 【正文】评测执行
  ### Step 1: Spawn all runs                 # 并行启动
  ### Step 2: Draft assertions               # 起草断言
  ### Step 3: Capture timing                 # 捕获计时
  ### Step 4: Grade, aggregate, launch       # 评分聚合
  ### What the user sees                     # 用户视角
  ### Step 5: Read feedback                  # 读取用户反馈

## Improving the skill                       # 【正文】改进循环
  ### How to think about improvements        # 改进哲学
  ### The iteration loop                     # 迭代流程

## Advanced: Blind comparison                # 【正文】盲测对比

## Description Optimization                  # 【正文】描述优化
  ### Step 1: Generate trigger evals         # 生成触发评测
  ### Step 2: Review with user               # 用户审查
  ### Step 3: Run optimization loop          # 运行优化循环
  ### Step 4: Apply result                   # 应用结果

## Claude.ai-specific instructions           # 【正文】Claude.ai平台适配
## Cowork-Specific Instructions              # 【正文】Cowork平台适配
## Reference files                           # 【正文】参考文件索引

五、核心工作流详细

1、工作流一:从零创建 Skill

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[用户] "帮我创建一个处理 CSV 数据清洗的技能"
[skill-creator] 触发
    ├──► 1. Capture Intent(捕捉意图)
    │       └── 确认 4 个核心问题:
    │           - 这个技能应让 Claude 做什么?
    │           - 何时触发?(用户表述关键词)
    │           - 期望输出格式?
    │           - 是否需要测试用例验证技能是否有效?
    ├──► 2. Interview & Research(访谈和研究)
    │       ├── 主动询问边界情况(edge cases)、输入/输出格式、示例文件、成功标准和依赖关系
    │       ├── 检查可用 MCP(如需要搜索文档)
    │       └── 并行调研(通过子代理subagent)
    ├──► 3. Write SKILL.md (编写SKILL.md)
    │       ├── name: 技能标识符
    │       ├── description: 包含触发关键词 + "pushy"策略
    │       ├── 编写 Markdown body(指令式语气)
    │       └── 遵循 Progressive Disclosure(<500 行)
    ├──► 4. Generate Test Cases (生成测试用例)
    │       └── 写入 evals/evals.json(仅 prompts,无 assertions)
    └──► 5. 进入【运行和评估测试】

其中第3步编Skill 编写指南,遵循Skill 的标准目录结构及渐进式披露(Progressive Disclosure)原则:

1
2
3
4
5
6
7
8
skill-name/
├── SKILL.md          (必须)
   ├── YAML frontmatter (name, description 必填)
   └── Markdown 指令正文
└── Bundled Resources (可选)
    ├── scripts/      可执行代码处理确定性/重复性任务
    ├── references/   按需加载的文档
    └── assets/       输出中使用的文件模板图标字体

写完技能草稿后,会设计 2–3 个真实业务场景的测试用例,并保存到技能目录下的 evals/evals.json 文件中。

暂不编写断言,断言将在下一步运行测试的过程中编写。

断言用于校验技能运行结果是否符合预期,如同软件开发中的编写测试校验规则。evals.json格式如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's example prompt",                   # 待执行的任务指令
      "expected_output": "Description of expected result", # 通俗易懂的成功结果描述
      "files": ["evals/files/sample1.pdf"],    # 可选输入文件路径列表(路径相对技能根目录)
      "expectations": [    # 可校验的判定条件列表。暂时不要写断言,在下一步运行测试的过程中编写断言。

      ]
    }
  ]
}

2、工作流二:运行和评估测试(Eval-Iterate Loop)

这是 skill-creator 的核心引擎,所有测试、评分、反馈均在此闭环内完成,共5个步骤:

Step 1:并行启动所有测试运行

对于每个测试用例,在同一轮中同时启动两个子代理(subagent):

  • with_skill:加载了 Skill 的子代理执行任务.
  • baseline(基线):没有使用Skill 的子代理执行同样的任务.

同时启动所有任务,这样它们会大致同时完成,避免等待偏差。

Step 2: 运行测试时,并行起草断言

在子代理运行期间(后台),skill-creator 不空闲,而是:

  • 为每个测试用例编写可验证的 assertions。
  • 断言编写完成后,更新eval_metadata.json文件和evals/evals.json
  • 向用户解释评估标准。

断言就是可以客观验证的检查项,例如"输出文件是否包含某个关键字段”。

evals.json 更新后示例如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
{
  "skill_name": "示例技能",
  "evals": [
    {
      "id": 1,
      "prompt": "用户示例指令",
      "expected_output": "预期结果说明",
      "files": ["evals/files/sample1.pdf"],
      "expectations": [
        "输出内容包含内容X",
        "该技能调用了脚本Y"
      ]
    }
  ]
}
Step 3: 实时捕获性能数据

子代理完成时,通知中包含 total_tokensduration_ms,需立即保存到 timing.json,后续用于统计分析:

1
2
3
4
5
{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}

⚠️ 关键机制:该数据仅通过任务通知传递一次,不持久化,错过无法恢复。

Step 4: 评分、聚合基准汇总、可视化
  • 对每个运行评分——启动评分代理(读取 agents/grader.md)根据测试输出评估每个断言,给每个断言打分,将结果保存到每个运行目录中的grading.json。grading.json的expectations数组必须使用textpassedevidence字段。

    grading.json示例:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    
    {
      "expectations": [
        {
          "text": "输出包含姓名'John Smith'",
          "passed": true,
          "evidence": "在执行记录第3步发现:'提取的姓名:John Smith, Sarah Johnson'"
        }
      ],
      "summary": {"passed": 2, "failed": 1, "total": 3, "pass_rate": 0.67},
      "execution_metrics": {...},
      "timing": {"executor_duration_seconds": 165.0,...},
      "claims": [...],
      "eval_feedback": {
        "suggestions": [
          {
            "assertion": "输出包含姓名'John Smith'",
            "reason": "一个幻觉文档提到这个名字也会通过——建议检查它是否作为主要联系人出现"
          }
        ]
      }
    }
    
  • 汇总到基准(Benchmark )——从skill-creator目录运行聚合脚本:

    1
    
    python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
    

    这会读取并聚合评分数据(grading.json),生成benchmark.jsonbenchmark.md,包含每个配置的通过率、时间和令牌使用情况,以及统计均值(mean)、标准差(stddev)和差值(Delta )。

    benchmark.json格式示例如下:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    
    {
      "metadata": {
        "skill_name": "pdf",
        "skill_path": "/path/to/pdf",
        ...
      },
      "runs": [
        {
          "eval_id": 1,
          "eval_name": "Ocean",
          "configuration": "with_skill",
          "run_number": 1,
          "result": {"pass_rate":0.85,"passed":6,"failed":1,"total":7,"time_seconds":42.5,"tokens":3800,"tool_calls":18,"errors":0},
          "expectations": [{"text":"...","passed":true,"evidence":"..."}],
          "notes": ["使用2023年数据,或已过时","非可填字段采用文本叠加处理"]
        }
      ],
      "run_summary": {
        "with_skill": {
          "pass_rate": {"mean":0.85,"stddev":0.05,"min":0.80,"max":0.90},
          "time_seconds": {"mean":45.0,"stddev":12.0,"min":32.0,"max":58.0},
          "tokens": {"mean":3800,"stddev":400,"min":3200,"max":4100}
        },
        "without_skill": {
          "pass_rate": {"mean":0.35,"stddev":0.08,"min":0.28,"max":0.45},
          "time_seconds": {"mean":32.0,"stddev":8.0,"min":24.0,"max":42.0},
          "tokens": {"mean":2100,"stddev":300,"min":1800,"max":2500}
        },
        "delta": {"pass_rate":"+0.50","time_seconds":"+13.0","tokens":"+1700"}
      },
      "notes": [
        "「输出为PDF文件」校验项全量通过,无法体现技能差异",
        "测试用例3波动大,运行不稳定或受模型影响",
        "未启用技能时,表格提取校验均失败",
        "技能平均耗时增加13秒,通过率提升50%"
      ]
    }
    
  • 分析——Analyzer Agent 阅读基准数据,找出汇总统计数据可能隐藏的模式。读取agents/analyzer.md(“分析基准结果"部分),了解分析的准则。

  • 启动查看器,执行eval-viewer/generate_review.py,同时显示定性输出和定量数据,HTML 交互界面(Outputs + Benchmark 双标签)。

    告知用户:“我已经在你的浏览器中打开了结果。有两个选项卡——‘输出’让你可以点击查看每个测试用例并留下反馈,基准显示定量比较。完成后回到这里告诉我。”

Step 5: 人工审查并反馈

用户通过浏览器查看:

  • Outputs 标签:逐条查看测试用例输出,对比前一次迭代。
  • Benchmark 标签:查看通过率、耗时、token 消耗的统计对比。

在 feedback 文本框中输入改进意见,点击"提交所有评论”,反馈保存为 feedback.json。空反馈意味着用户认为没问题。

feedback.json内容示例:

1
2
3
4
5
6
7
8
{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "图表缺少坐标轴标签", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "完美,我喜欢", "timestamp": "..."}
  ],
  "status": "complete"
}

3、工作流三:迭代改进技能

Step 1: 改进技能

本环节是整个流程的核心闭环。你已经运行了测试用例,用户已经审核了结果,现在需要根据用户的反馈(feedback.json)改进技能,遵循 4 条改进原则:

  1. 原则1—Generalize(从反馈中泛化,而非过拟合)

    we’re trying to create skills that can be used a million times across many different prompts

    从具体反馈抽象出通用模式,避免过拟合。目标不是让技能在这三五个测试用例上表现完美,而是要提炼出能扛住百万次不同提示的通用模式。如果某个问题反复出现,不要堆砌越来越多的 MUST/NEVER 硬规则去"堵漏洞"——这会让技能越来越僵化。更好的做法是尝试扩展思路,使用不同的隐喻,或者推荐不同的工作模式。

  2. 原则2—Keep lean(保持精简,移除无效指令)

    Remove things that aren’t pulling their weight

    阅读测试的完整执行过程(transcript),识别浪费时间的行为。如果看起来技能让模型浪费了大量时间做无效率的事情,尝试删除技能中导致这种情况的指令。

  3. 原则 3 — Explain the why(解释"为什么")

    现代大模型有很强的心理理论和推理能力。解释"为什么"比命令"做什么"更有效。如果发现自己要写 ALWAYSNEVER,或者设计极其死板的结构,这是一个黄色警告——如果可能的话,重新表述并解释原因,让模型理解你要求的事情为什么重要,这是一种更人性化、更强大、更有效的方法。

  4. 原则 4 — Bundle repeated work(整合重复工作)

    如果发现多个子代理都在写同一个辅助脚本(比如 create_docx.pybuild_chart.py),这就是强烈的信号:这个公共逻辑应该被提取出来,作为技能自带的工具脚本,放在 scripts/ 目录下

Step 2: 迭代循环

改进技能后:

  1. 应用改进到技能上。
  2. 在新的iteration-<N+1>/目录中重新运行所有测试用例,包括基线运行:如果你创建新技能,基线始终是without_skill(不使用技能);如果正在改进现有技能,根据你的判断选择合适的基线:用户提供的原始版本,或上一次迭代的版本。
  3. 继续直到:
    • 用户说他们满意。
    • 所有反馈都是空的(一切看起来都很好)。
    • 你没有取得有意义的进展。

每次迭代的工作区按以下结构组织:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
<skill-name>-workspace/            # 与 skill 目录同级
├── iteration-1/
   ├── eval-descriptive-name-1/   # 每个评测用例一个目录
      ├── with_skill/
         ├── outputs/           # Skill 版本的输出文件
         ├── grading.json       # 评分结果
         └── timing.json        # 计时数据
      ├── without_skill/         # 基线版本
         ├── outputs/
         ├── grading.json
         └── timing.json
      └── eval_metadata.json     # 评测元数据 + 断言
   ├── eval-descriptive-name-2/
      └── ...
   ├── benchmark.json             # 本轮聚合统计
   ├── benchmark.md               # 人类可读报告
   └── feedback.json              # 用户反馈
├── iteration-2/
   └── ...同上结构
└── skill-snapshot/                 # 改进现有 Skill 时保留的原始快照

3、工作流四:描述优化(Trigger Optimization)

描述优化是专门针对 Skill 的触发准确率进行调优,解决:如何让 Skill 的 description 字段更精准地触发?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
生成 20 条评估查询
    ├── 8-10 条 should-trigger(覆盖不同表述、隐含需求、竞争场景)
    └── 8-10 条 should-not-trigger(近义词干扰、相邻领域、歧义表述)
用户审查(HTML 交互编辑)
运行优化循环(scripts/run_loop.py)
    ├── 60% train / 40% test 分割
    ├── 每条查询运行 3 次计算可靠触发率
    ├── Claude 基于失败案例提出 description 改进
    ├── 最多 5 次迭代
    └── 选择 test 集表现最好的 description(非 train,防过拟合)
应用最优 description 到 SKILL.md frontmatter

优化流程分四步:

  1. 生成评估查询:创建 20 条测试查询(约一半应该触发、一半不应该触发),要求查询尽量真实、具体、覆盖各种边缘情况。

    创建20个测试查询,保存为JSON:

    1
    2
    3
    4
    
    [
      {"query": "用户提示词", "should_trigger": true},
      {"query": "另一个提示词", "should_trigger": false}
    ]
    
  2. 用户审核:通过 HTML 页面(assets/eval_review.html)让用户审核和修改查询集。

  3. 运行优化循环:通过 scripts/run_loop.py 自动执行"评估→改进→重新评估"循环。按60% train / 40% test 分割查询集,每条查询运行 3 次计算可靠触发率,最多5 次迭代。

  4. 应用最佳结果:取测试集上得分最高的描述(而非训练集,以避免过拟合)

注意:Skills 的触发机制是 Claude 基于 available_skills 列表中的 name + description 做意图匹配。简单查询(如"读取 PDF")可能不会触发 Skill,因为 Claude 可直接用基础工具处理;复杂、多步骤、专业化查询才会可靠触发。

关于触发机制的注意事项:

Claude only consults skills for tasks it can’t easily handle on its own

Claude 只会在遇到自己不容易处理的复杂任务时才会去"查阅" Skill。简单查询(如"读取 PDF")可能不会触发 Skill,因为 Claude 可直接用基础工具处理。因此,评估查询需要足够具体、多步骤、专业化。

4、工作流五:盲比较

1
2
3
Skill A ──► Output A ──┐
                       ├──► Comparator Agent(匿名评分)──► Analysis Agent(归因改进)
Skill B ──► Output B ──┘

执行细节

  • comparator 严格不知晓A/B 对应哪个 Skill,仅依据 rubric(Content + Structure,各 1-5 分)和 assertions 裁决。

    双维度评分体系(综合为 1-10 的总分):

    • Content (内容维度):正确性、完整性、准确性(各 1-5 分)
    • Structure(结构维度):组织性、格式化、可用性(各 1-5 分)
  • analyzer 在 Comparator 完成评分后进行“揭盲”,读取双方 SKILL.md 文档、运行记录(transcripts)等数据,深入分析差异点,最终生成按 priority(优先级)+ category(类别)组织的可落地改进建议,明确优化方向。

核心原则:在完全不知道哪个输出来自哪个 Skill 的前提下,判断两者优劣。

六、核心机制解析

1、Progressive Disclosure(渐进式披露)

skill-creator 自身就是 Progressive Disclosure 架构的最佳实践:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Level 1: Metadata(始终加载)
    ├── name: "skill-creator"
    └── description: 100 token左右的触发描述

Level 2: SKILL.md Body(触发时加载)
    ├── 完整工作流指令(<500 行)
    └── 仅在用户表达相关意图时进入上下文

Level 3: Bundled Resources(按需加载)
    ├── agents/*.md(需要评分/对比/分析时读取)
    ├── references/schemas.md(需要查数据结构时读取)
    └── scripts/*.py(执行时不加载到上下文,直接运行)

工程意义

  • 即使安装 50 个 Skill,启动时仅加载 50 × ~100 tokens = 5000 tokens 的元数据。

  • 避免上下文窗口被不相关技能挤占,保障主任务可用 token 空间。

2、总体哲学

SKILL.md 开篇以通俗语言介绍了 skill-creator的核心工作流程:

At a high level, the process of creating a skill goes like this:

  • Decide what you want the skill to do and roughly how it should do it
  • Write a draft of the skill
  • Create a few test prompts and run claude-with-access-to-the-skill on them
  • Help the user evaluate the results both qualitatively and quantitatively
  • Rewrite the skill based on feedback
  • Repeat until you’re satisfied
  • Expand the test set and try again at larger scale

解读:该流程类似文稿打磨,先出初稿、然后请人看看,结合反馈修改,迭代直到满意;不同之处在于本流程搭配自动化工具完成评测与对比。

安全原则(Principle of Lack of Surprise)

“skills must not contain malware, exploit code, or any content that could compromise system security”

(Skill 的内容不应该让用户感到意外——它做的事情应该与描述一致,不能包含恶意代码。)

3、沟通风格指南(人性化设计的典范)

skill-creator 开篇就强调了一个非常现实的问题:

“there’s a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google ‘how to install npm’”

(如今出现了一个有趣的现象:得益于 Claude 强大的能力,水管工开始尝试使用命令行,父母和长辈也主动上网搜索 “如何安装 npm”。)

核心要点

  • evaluationbenchmark 属于"边界词汇"——可以直接用,但最好确认用户理解。
  • JSONassertion 属于"技术词汇"——必须先确认用户懂这些术语,或附上简短解释。

设计价值:这教会我们在设计 Skill 时,要考虑目标用户的多样性,而不是假设所有人都是技术专家。

4、多代理协作架构

skill-creator使用子代理(subagent )能力,实现隔离上下文、并行化执行。主要包含四个子代理:

  • Executor (执行代理)

    对于每个测试用例,在同一轮中生成两个子代理——一个使用该技能,一个不使用。同时启动所有任务,这样它们会大致同时完成。

    1
    2
    3
    4
    5
    6
    
    执行此任务:
    - 技能路径:<path-to-skill>
    - 任务:<eval prompt>
    - 输入文件:<eval files if any, or "none">
    - 保存输出到:<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
    - 要保存的输出:<用户关心的内容——例如,"docx文件"、"最终CSV">
    

    基线运行(相同的提示词,但基线取决于上下文),分两种情况:

    • 创建新技能:完全不使用技能。相同的提示词,没有技能路径,保存到without_skill/outputs/
    • 改进现有技能:使用旧版本。编辑前,快照技能(cp -r <skill-path> <workspace>/skill-snapshot/),然后将基线子代理指向快照。保存到old_skill/outputs/
  • Grader Agent (评分代理)

    对每个运行评分,读取agents/grader.md根据输出评估每个断言。将结果保存到每个运行目录中的grading.json

    职责:评审执行结果,判断每个"断言"(assertion)是通过还是失败,并为每项判断提供清晰的证据。

    输入

    • expectations:要检查的断言列表(如"输出包含姓名’John Smith’")
    • transcript_path:执行过程的完整记录
    • outputs_dir:输出文件目录

    工作流程(8步)

    1. 读取Transcript(执行记录)。
    2. 检查输出文件。
    3. 逐一评估断言(判定结果:PASS/FAIL、引用证据)。
    4. 提取并验证隐含声明
    5. 阅读用户备注(若{outputs_dir}/user_notes.md 存在)
    6. 批判性审视评测本身(这是亮点!)
    7. 撰写评分结果 ,写入 grading.json
    8. 读取执行指标和计时数据,输出结构的 JSON 文件(结果保存到 {outputs_dir}/../grading.json)。

    “关键设计—自我批评

    “A passing grade on a weak assertion is worse than useless — it creates false confidence. When you notice an assertion that’s trivially satisfied, or an important outcome that no assertion checks, say so..”

    对薄弱断言给出"通过"的评级,其危害比毫无用处还要糟糕——它制造虚假信心。当你注意到某个断言被轻易满足,或某个重要结果没有任何断言检查时,请指出来。

    Grader 不仅评分,还会指出评测设计的问题:

    • “这个断言太弱,即使输出明显错误也会通过”
    • “有个重要结果没有任何断言覆盖”

    输出格式(grading.json)

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    
    {
      "expectations": [
        {
          "text": "输出包含姓名'John Smith'",
          "passed": true,
          "evidence": "在执行记录第3步发现:'提取的姓名:John Smith, Sarah Johnson'"
        }
      ],
      "summary": {"passed": 2, "failed": 1, "total": 3, "pass_rate": 0.67},
      "execution_metrics": {...},
      "timing": {...},
      "claims": [...],
      "eval_feedback": {
        "suggestions": [
          {
            "assertion": "输出包含姓名'John Smith'",
            "reason": "一个幻觉文档提到这个名字也会通过——建议检查它是否作为主要联系人出现"
          }
        ]
      }
    }
    
  • Comparator Agent (盲评对比代理)

    对于严格比较两个版本技能的情况(例如,用户问"新版本真的更好吗?"),读agents/comparator.mdagents/analyzer.md。基本思路:将两个输出交给独立代理,不告诉它哪个技能产生哪个输出,让它判断质量;然后分析获胜者获胜的原因。

    **角色:**盲测比较器,负责在不知道哪个技能产生哪个输出的情况下,判断哪个输出更好。目的是防止对特定技能或方法产生偏见。

    工作流程

    1. 读取输出 A 和输出 B(只知道代号,不知道对应哪个 Skill)
    2. 理解任务要求.
    3. 生成评分量表(Rubric),双维度评分体系(综合为 1-10 的总分):
      • Content(内容维度):Correctness(正确性)、Completeness(完整性)、Accuracy(准确性)
      • Structure(结构维度):Organization(组织性)、Formatting(格式)、Usability(可用性)
    4. 按量表评分(1-5分制)
    5. 检查断言通过率(辅助证据)
    6. 判定胜者(A、B 或平局)

    输出格式(comparison.json)

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    
    {
      "winner": "A",
      "reasoning": "输出A提供了完整解决方案...",
      "rubric": {
        "A": {"content_score": 4.7, "structure_score": 4.3, "overall_score": 9.0},
        "B": {"content_score": 2.7, "structure_score": 2.7, "overall_score": 5.4}
      },
      "output_quality": {
        "A": {
          "score": 9,
          "strengths": ["Complete solution", "Well-formatted", "All fields present"],
          "weaknesses": ["Minor style inconsistency in header"]
        },...
      },
      "expectation_results": {
        "A": {
          "passed": 4,
          "total": 5,
          "pass_rate": 0.80,
          "details": [
            {"text": "Output includes name", "passed": true}
          ]
        },...
      }
    }
    
  • Analyzer Agent(分析子代理)

    包含两大角色:

    角色 A — 盲测后分析器:在盲测比较后"揭盲”,目标是提取可操作的洞察:是什么让获胜方表现更好,以及如何改进落败方?

    • 对比两个 Skill 的指令差异和执行模式差异。

    • 最终生成按 priority(优先级:high / medium / low)+ category(类别:instructions、tools、examples、error_handling、structure、references)组织的可落地改进建议,明确优化方向。

      改进建议分类

      类别 说明
      instructions 修改 Skill 的文本指令
      tools 添加/修改脚本、模板
      examples 添加示例输入/输出
      error_handling 添加失败处理指南
      structure 重组 Skill 内容
      references 添加外部文档

      输出analysis.json 格式示例如下:

       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      
      {
        "comparison_summary": {
          "winner": "A",
          "winner_skill": "path/to/winner/skill",
          "loser_skill": "path/to/loser/skill",
          "comparator_reasoning": "选择优胜方的简要原因"
        },
        "winner_strengths": [
          "针对多页文档提供清晰分步指引",
          "内置校验脚本,可识别格式错误"
        ],
        "loser_weaknesses": [
          "指令表述模糊,执行结果不一致",
          "无校验脚本,只能临时应对"
        ],
        "instruction_following": {
          "winner": {
            "score": 9,
            "issues": ["小问题:省略可选日志步骤"]
          },
          "loser": {
            "score": 6,
            "issues": [
              "未使用指定格式模板",
              "未按第三步要求,自行改用其他方式"
            ]
          }
        },
        "improvement_suggestions": [
          {
            "priority": "high",
            "category": "instructions",
            "suggestion": "将模糊指令改为明确操作步骤",
            "expected_impact": "消除歧义,统一执行效果"
          }
        ],
        "transcript_insights": {
          "winner_execution_pattern": "读取技能 → 按五步流程执行 → 调用校验脚本",
          "loser_execution_pattern": "读取技能 → 思路不明确 → 尝试多种方式"
        }
      }
      

    角色 B — 基准分析器:在测试评估后,分析基准测试结果,基准分析器的目的不是提出技能改进建议,而是揭示多次运行中的模式和异常

    • 哪些断言在两种配置下始终(100%)通过吗?(可能无法区分技能价值)。

    • 哪些断言在两种配置下始终(100%)失败吗?(可能已损坏或超出能力范围)。

    • 是否有技能时始终通过,无技能时始终失败?(技能在此处明显增加了价值)。

    • 是否有技能时始终失败,无技能时始终通过?(技能可能正在造成损害)。

    • 是否高度不稳定?(不稳定的预期或非确定性行为)。

    输出格式为 JSON 字符串数组:

    1
    2
    3
    4
    5
    6
    
    [
      "断言‘输出是 PDF 文件’在两种配置下 100% 通过——可能无法区分技能价值",
      "评估 3 显示高方差(50% ± 40%)——运行 2 出现了异常失败",
      "无技能运行始终在表格提取预期上失败",
      "技能平均增加 13 秒执行时间,但将通过率提高了 50%"
    ]
    

5、盲测比较的方法论

agents/comparator.mdagents/analyzer.md 构成了一套因果推断框架

  • Comparator(盲测):消除"先入为主"和"作者偏见"。输出必须包含 rubric(量化评分)+ output_quality(定性总结)+ expectation_results(断言通过率)。
  • Analyzer(归因):揭盲后执行反事实分析。对比双方执行记录(transcripts),检查 instruction following 得分(1-10),识别 winner 的优势(提取可操作的洞察:是什么让获胜方表现更好)和 loser 的可改进点。

关键设计:Analyzer 的 improvement_suggestionspriority(high/medium/low)和 category(instructions/tools/examples/error_handling/structure/references)分类,确保建议可操作、可度量。

6、反过拟合机制

skill-creator 内置多层防过拟合设计:

  1. 从反馈中归纳:Skill 要在许多不同提示词中使用百万次,如果只为测试用例做针对性修改,skill 就废了。遇到顽固问题,尝试扩展思路,使用不同的隐喻,或者推荐不同的工作模式,而不是加更多死板约束。

  2. Train/Test 分割:Description 优化时 60训练集/40测试集分割,选择 test 分数最高的描述。

  3. Baseline 对照:每次迭代必须对比无 Skill 或 旧版本 Skill 的表现,确保改进真实有效。

  4. Blind Comparison:可选的 A/B 盲评,消除评估者偏见。

7、数据流与 Schema 约束

所有评估数据遵循 references/schemas.md 的严格结构,形成完整的数据管道:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
evals.json          ─── 定义测试用例(prompt + expectations)
timing.json         ─── 运行计时(来自子 Agent 完成通知)
metrics.json        ─── 执行指标(工具调用次数、文件数等)
grading.json        ─── 评分结果(断言通过/失败 + 证据,字段名严格:text/passed/evidence)
benchmark.json      ─── 聚合统计(with_skill vs without_skill 的 mean/stddev/delta)
feedback.json       ─── 用户定性反馈(reviews 数组)
comparison.json     ─── 盲比较结果(A/B 评分 + 赢家)
analysis.json       ─── 事后分析(改进建议 + 执行模式洞察)
history.json        ─── 版本追踪(迭代历史 + 当前最佳)

关键约束

  • grading.json 的 expectations 数组必须使用字段 textpassedevidence,viewer 依赖这些精确字段名。
  • benchmark.json 的 configuration 必须是 "with_skill""without_skill"(viewer 硬编码匹配)。
  • timing.json 的数据必须在子代理完成通知中实时捕获,过后不可恢复。

8、scripts/ —— 自动化脚本详解

1)run_loop.py —— 主循环编排器

职责:编排整个"描述优化"的自动化循环。

工作流程:

  1. 将评估查询集按 60:40 分为训练集和测试集(分层采样,保持正负样本比例)。
  2. 对当前描述运行评估(每条查询运行 3 次取可靠触发率)。
  3. 调用 improve_description.py 让 Claude 改进描述。
  4. 对新描述重新评估
  5. 最多迭代 5 轮,选取测试集得分最高的描述(而非训练集,防止过拟合)
  6. 生成实时 HTML 报告。

run_loop.py核心代码:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
def run_loop(eval_set, skill_path, max_iterations=5, holdout=0.4, ...):
    # 划分训练集/测试集(防止过拟合)
    train_set, test_set = split_eval_set(eval_set, holdout)

    for iteration in range(1, max_iterations + 1):
        # 评估当前description
        results = run_eval(all_queries, current_description)

        # 分离train/test结果
        train_results = [r for r in results if r.query in train_set]
        test_results = [r for r in results if r.query not in train_set]

        # 早停条件:train全部通过
        if train_failed == 0:
            break

        # 基于train结果改进description(**看不到test结果,防止过拟合**)
        new_description = improve_description(
            eval_results=train_results,  # 只给train结果!
            history=blinded_history       # 隐藏test分数的历史
        )
        current_description = new_description

    # 选择最佳description(按test分数,而非train分数)
    best = max(history, key=lambda h: h["test_passed"])
    return best["description"]

关键设计——防止过拟合:

  • 类似机器学习的 Train/Test 分离。
  • 改进时看不到测试集结果
  • 最终选择按测试集选择最佳description而非训练集。
2)run_eval.py —— 触发评估运行器

职责: 测试 Skill 描述是否能正确触发。

核心机制:

  1. .claude/commands/ 目录创建临时命令文件
  2. 运行 claude -p(Claude CLI)并使用 --stream-json --include-partial-messages 参数
  3. 通过流式事件检测 Claude 是否触发了该 Skill(早期检测)
  4. 支持通过 ProcessPoolExecutor 并行执行多条查询
3)improve_description.py —— 描述自动改进

职责: 调用 Claude 来生成改进后的 Skill 描述。

核心流程

  1. 分析失败案例:
    • Failed triggers:应该触发但没触发(漏召)
    • False triggers:不该触发但触发了(误召)
  2. 构建 Prompt 让 Claude 生成新描述:
    • 包含当前描述
    • 包含失败案例(具体查询+触发次数)
    • 包含历史尝试(避免重复)
    • 包含 Skill 完整内容(上下文)
  3. 关键约束
    • “不要产生越来越长的具体查询列表”
    • “要泛化到更广泛的用户意图类别”
    • “描述不超过100-200词,硬限制1024字符”
    • “用祈使句,聚焦用户意图而非实现细节”
  4. 安全网:如果生成超过1024字符,自动调用缩短流程

Prompt 工程亮点

1
2
3
4
"The description competes with other skills for Claude's attention 
— make it distinctive and immediately recognizable."

(描述要与其他 Skill 竞争 Claude 的注意力——让它独特且一眼可识别。)
4)aggregate_benchmark.py —— 基准聚合脚本

职责: 将分散的评分数据汇总为统计报告。

输出:

  • benchmark.json:结构化的完整基准数据
  • benchmark.md:人类可读的 Markdown 格式报告
  • 计算每个配置(with_skill / without_skill)的均值、标准差、最小值、最大值
  • 计算两者之间的 delta(差异)。
5)package_skill.py —— Skill 打包器

职责: 将 Skill 目录打包为可分发的 .skill 文件。

工作流程:

  1. 调用 quick_validate.py 校验 Skill 格式。
  2. 创建 zip 格式的 .skill 文件。
  3. 排除无关文件:__pycache__node_modules.pyc.DS_Store、根级 evals/
5)quick_validate.py —— Skill 格式校验

职责: 检查 Skill 是否符合规范。

校验项:

  • SKILL.md 是否存在且包含有效的 YAML frontmatter。
  • name 字段是否为 kebab-case 格式,不超过 64 字符。
  • description 字段是否不超过 1024 字符且不含尖括号。
  • compatibility 字段(如果有)不超过 500 字符。
  • 只允许规定的 frontmatter 属性。

9、评测与迭代系统:evals/ 与 eval-viewer/

1) 评测数据流
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
用户定义测试用例 (evals.json)
Claude 并行执行(with_skill vs without_skill)
Grader 对执行结果评分 → grading.json
aggregate_benchmark.py 聚合 → benchmark.json + benchmark.md
Analyzer 分析 → 发现隐藏模式
generate_review.py + viewer.html → 可视化界面
用户查看并留下反馈 → feedback.json
Claude 读取反馈并改进 Skill
[循环回到第一步]
2) evals.json 结构
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,                              #唯一整型标识
      "prompt": "用户的任务提示(真实场景)",   #待执行的任务指令
      "expected_output": "预期结果的描述",    #用通俗文字描述预期达标效果
      "files": ["evals/files/sample1.pdf"], #可选,输入文件路径列表(路径相对于技能根目录)
      "expectations": [                     #可核验的判定条目列表
        "输出包含X",
        "Skill使用了脚本Y"
      ]
    }
  ]
}

设计要点

  • prompt 必须是真实用户会说的,不是抽象描述。
  • expectations 必须是客观可验证的,避免主观判断。
3) eval-viewer可视化系统

skill-creator 提供了一个完整的浏览器端评测查看器:

技术栈

  • generate_review.py:Python 后端,读取评测数据并注入 HTML 模板
  • viewer.html:纯前端 HTML(内嵌 CSS/JS),无需服务器即可运行

功能

  • Outputs 标签页:逐个查看测试用例
    • 显示 Prompt、输出文件、上一轮输出(折叠)
    • 正式评分结果(折叠)
    • 反馈文本框(自动保存)
    • 上一轮反馈(迭代时显示)
  • Benchmark 标签页:统计摘要
    • 通过率、时间、Token 消耗的均值±标准差
    • 配置间差异(Delta)

Cowork/无浏览器环境适配

“use --static to write a standalone HTML file instead of starting a server”

(使用 --static 参数生成独立 HTML 文件,而非启动服务器)

七、完整执行流程与数据流转

1、完整执行流程

下面是用户触发 skill-creator 到最终输出的完整流程:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
┌─────────────────────────────────────────────────────────────────────┐
                        用户触发 Skill                               
   "帮我创建一个处理 CSV 数据清洗的技能"                          
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 1意图捕获Capture Intent                                   
                                                                     
  Claude 询问确认4个核心问题::                                            
  1. 这个技能应让 Claude 做什么                                        
  2. 何时触发?(用户表述关键词                                         
  3. 期望输出格式                                                
  4. 是否需要测试用例验证技能是否有效                                    
                                                                     
  如果当前对话中已有工作流直接从中提取信息                               
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 2深度访谈与调研Interview and Research                       
                                                                     
  - 主动询问边界情况edge cases)、输入/输出格式示例文件成功标准和依赖关系 
  - 检查可用 MCP 工具如需要搜索文档                                    
  - 并行调研通过子代理subagent                                        
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 3编写 SKILL.md 草稿                                           
                                                                     
  根据访谈结果填写                                                    
  - name: skill 标识符                                                
  - description: 触发描述稍微激进以对抗触发不足                       
  - 编写 Markdown body指令正文):步骤示例注意事项                   
  - 如需要创建 scripts/references/assets/ 等辅助文件               
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 4生成测试用例                                                  
                                                                     
  - 构思 2-3 个真实的用户 prompt                                       
  - 与用户确认测试用例是否合适                                           
  - 保存到 evals/evals.json prompts assertions                
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 5运行测试五步评测法                                         
                                                                     
  ┌──────────────────────────────────────────────────────────┐       
   Step 1: 并行启动所有测试运行                                      
                                                                   
     测试用例 1 ──┬── with_skill 子代理 ──▶ outputs/               
                 └── baseline 子代理   ──▶ outputs/               
     测试用例 2 ──┬── with_skill 子代理 ──▶ outputs/               
                 └── baseline 子代理   ──▶ outputs/               
     测试用例 3 ──┬── with_skill 子代理 ──▶ outputs/               
                 └── baseline 子代理   ──▶ outputs/               
  └──────────────────────────────────────────────────────────┘       
                         │(同时进行                                  
  ┌──────────────────────────────────────────────────────────┐       
   Step 2: 在等待期间起草量化断言                                     
    - 编写可客观验证的检查项                                           
    - 更新 eval_metadata.json  evals.json                         
  └──────────────────────────────────────────────────────────┘       
                                                                    
  ┌──────────────────────────────────────────────────────────┐       
   Step 3: 子代理完成时立即捕获 timing 数据                           
    - total_tokens, duration_ms  timing.json                       
  └──────────────────────────────────────────────────────────┘       
                                                                    
  ┌──────────────────────────────────────────────────────────┐       
   Step 4: 评分  聚合  分析  启动可视化                           
                                                                   
    4a. 评分代理(grader.md)  grading.json                          
    4b. aggregate_benchmark.py  benchmark.json                     
    4c. 分析代理(analyzer.md)  检查模式洞察                             
    4d. generate_review.py  浏览器评审页面                          
  └──────────────────────────────────────────────────────────┘       
                                                                    
  ┌──────────────────────────────────────────────────────────┐       
   Step 5: 用户在浏览器中查看结果编写反馈                            
    - 点击 "Submit All Reviews"  feedback.json                     
  └──────────────────────────────────────────────────────────┘       
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 6迭代改进核心循环                                          
                                                                     
  ┌────────────────────────────────────┐                             
   读取 feedback.json                                              
   聚焦有具体投诉的测试用例                                         
   遵循四大原则改进 SKILL.md                                        
  └─────────────┬──────────────────────┘                             
                                                                    
                                                                    
  ┌────────────────────────────────────┐                             
   重新运行所有测试  iteration-N+1/                               
   启动评审--previous-workspace                                
   等待用户反馈                                                    
  └─────────────┬──────────────────────┘                             
                                                                    
                                                                    
        用户满意 ────  ──▶ 回到循环顶部                            
                                                                    
                                                                   
                                                                    
└────────────┼────────────────────────────────────────────────────────┘
             
             
┌─────────────────────────────────────────────────────────────────────┐
 阶段 7描述优化可选                                              
                                                                     
  1. 生成 20 条触发评估查询应触发 + 不应触发                         
  2. 用户审核assets/eval_review.html                               
  3. python -m scripts.run_loop自动化优化循环最多 5              
  4. 应用最佳描述到 SKILL.md                                          
└──────────────────────────────┬──────────────────────────────────────┘
                               
                               
┌─────────────────────────────────────────────────────────────────────┐
 阶段 8打包发布                                                      
                                                                     
  python -m scripts.package_skill <path/to/skill-folder>             
   输出 .skill 文件zip 格式                                       
└─────────────────────────────────────────────────────────────────────┘

2、数据流转生命周期

理解数据在各阶段之间如何流转,有助于理解整个系统的协作机制:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
evals.json (手动编写)
    
    
[并行测试运行]
    
    ├──▶ outputs/各测试用例的输出文件
    ├──▶ evals/evals.json prompts assertions
    ├──▶ eval_metadata.json每个测试用例的元数据 + 断言
    └──▶ timing.json每次运行的计时数据
           
           
    [评分代理]
           
           └──▶ grading.json各断言通过/失败 + 证据
                     
                     
              [aggregate_benchmark.py]
                     
                     ├──▶ benchmark.json结构化统计数据
                     └──▶ benchmark.md人类可读报告
                               
                               
                     [generate_review.py]
                               
                               └──▶ 浏览器评审页面
                                         
                                         
                               feedback.json用户反馈
                                         
                                         
                               [改进 SKILL.md  新一轮迭代]

八、设计通用启示

  1. 评估即工程(Evaluation as Engineering)

    skill-creator 将评估流程工程化为严格的 Schema 契约、并行实验、统计聚合和可视化审阅。好的 Skill 不是写出来的,而是测出来、比出来、迭代出来的

  2. 人机协同的反馈回路

    Eval Viewer 的设计体现了"人类审阅优先"的原则:Claude 不直接根据评估结果修改 Skill,而是先将 outputs 和 benchmark 呈现给用户,收集 feedback.json 后再做改进。这防止了自动化系统对量化指标的过度优化。

  3. 盲测与因果归因的方法论

    在 Skill 改进场景中,“新版本是否更好"是一个容易被偏见污染的问题。Blind Comparison 引入了一种准实验设计:匿名输出 → 量化裁决 → 结构化归因。这套方法论可直接迁移到任何 A/B 评估场景。

  4. 解释"为什么"而非堆砌"必须”

    SKILL.md 明确反对过度使用 “ALWAYS / NEVER” 和 “super rigid structures(超刚性结构)",主张用的心智理论( theory of mind) 向模型解释为什么某个做法重要。反映了 Anthropic 对当代 LLM 能力的洞察:足够智能的模型在理解意图后,比遵循死板规则表现更好。

  5. 提取重复工作到脚本

    如果多个 test case 都导致子代理独立写出类似的辅助脚本,这就是强烈的信号:该逻辑应被提取为 Skill 的 bundled script。这是从 prompt engineering 向软件工程过渡的关键实践。

  6. 泛化而非过拟合

    Skill 要被使用无数次、面对无数种 prompt。如果只为测试用例做针对性修改,skill 就废了。如果某个问题反复出现,不要堆砌越来越多的 MUST/NEVER 硬规则去"堵漏洞”,尝试换个隐喻或推荐不同的工作模式,而不是加更多死板约束。

  7. 保持提示精简

    删除没有实际作用的内容——如果看起来技能让模型浪费了大量时间做无效率的事情,你可以尝试删除技能中导致这种情况的部分,看看会发生什么。

九、使用示例

场景 A:从零创建 Skill

1
2
3
我想创建一个 Skill,用于把用户提供的 CSV 数据自动清洗后生成带图表的 Excel 报告。
清洗规则包括:去除空行、标准化日期格式、检测异常值。
图表需要自动判断最合适的类型(柱状图/折线图/饼图)。

image-20260516134156892image-20260516134141138

确认细节:异常值检查规则、图标选择逻辑、输出格式、依赖库、是否需要构造测试用例。

image-20260516134411175

创建脚本文件

image-20260516134529660

生成测试数据:

image-20260516134813440

image-20260516134837768

生成评估数据,保存为evals.json

image-20260516134916683

创建测试工作目录

image-20260516135031768

运行测试评估

image-20260516135226140

测试评估期间保存timing.json 文件

image-20260516135540381

生成分析可视化报告review.html

image-20260516135725416

回车yes,claude 会自动调用浏览器打开review.html页面,可以看到一共6个页面,分别是:sales_data.csvcategory_data.csvemployee_data.csv 三个文件的各with skillwithout skill 测试报告。

image-20260516140251097

image-20260516140808707

若发现问题或,不满意的地方,拉到下方,可以输入反馈。

image-20260516142312922

点击按钮Submit All Reviews ,下载feedback.json文件

image-20260516141938582

反馈文件feedback.json展示如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
{
  "reviews": [
    {
      "run_id": "sales-eval-with_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    },
    {
      "run_id": "sales-eval-without_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    },
    {
      "run_id": "category-eval-with_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    },
    {
      "run_id": "category-eval-without_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    },
    {
      "run_id": "employee-eval-with_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    },
    {
      "run_id": "employee-eval-without_skill",
      "feedback": "",
      "timestamp": "2026-05-16T06:19:12.803Z"
    }
  ],
  "status": "complete"
}

完成后,claude code 命令窗口展示:

image-20260516141141266

最终生成技能csv-excel-report目录如下:

image-20260516142718031

评测目录如下:

image-20260516141729623

创建的技能csv-excel-reportSKILL.md文件如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
---
name: csv-excel-report
description: >
  自动将用户提供的 CSV 数据清洗后生成带图表的 Excel 报告。
  当用户提到 CSV 清洗、CSV 转 Excel、数据清洗报告、自动图表、异常值检测、日期格式标准化、生成 Excel 报告、数据可视化报告时,务必使用此 Skill。
  即使用户没有明确说 "CSV",只要涉及"把数据清洗后做成 Excel 报告"或"给数据加图表",也应使用此 Skill。
compatibility: Python 3, pandas, openpyxl
---

# CSV 清洗与 Excel 报告生成

## 目标

帮助用户将 CSV 数据自动清洗并生成结构化的 Excel 报告,包含:
- 清洗后的数据(去除空行、标准化日期格式)
- 统计摘要(异常值统计等)
- 自动选择的图表(柱状图 / 折线图 / 饼图)

## 工作流程

1. **读取 CSV**:使用 pandas 读取用户提供的 CSV 文件。
2. **数据清洗**:
   - 去除完全为空的行(`dropna(how="all")`)。
   - 去除所有非空值仅为空白字符的行。
   - 标准化日期格式:检测日期列(≥50% 的值可解析为日期),统一转为 `YYYY-MM-DD` 格式。
   - 异常值检测:对数值型列使用 IQR 法(1.5×四分位距)标记异常值。
3. **生成 Excel 报告**:
   - Sheet 1 `清洗后数据`:包含清洗后的全部数据,异常值单元格以红色背景高亮。
   - Sheet 2 `统计摘要`:包含行数、日期列列表、各列异常值数量。
   - Sheet 3 `图表`:根据数据特征自动选择最合适的图表类型嵌入。
4. **图表自动选择规则**:
   - 若 X 轴列 ≥70% 为日期 → **折线图**
   - 若 X 轴为离散类别且类别数 ≤10 → **饼图**
   - 其他情况 → **柱状图**

## 使用方法

优先使用 bundled 脚本 `scripts/generate_report.py`:

```bash
python scripts/generate_report.py <input.csv> <output.xlsx>
```

如果环境未安装依赖,先安装:

```bash
pip install pandas openpyxl
```

如果用户的数据需要额外定制(如自定义异常值阈值、指定图表类型、多列同时绘图),可以基于脚本逻辑修改或重写 Python 代码。

## 输出格式

生成的 `.xlsx` 文件包含以下工作表:

| Sheet 名称 | 内容 |
|---|---|
| 清洗后数据 | 清洗后的数据表,表头蓝色背景,异常值红色高亮 |
| 统计摘要 | 数据概览:行数、日期列、异常值统计 |
| 图表 | 自动生成的图表(折线/柱状/饼图) |

## 注意事项

- 日期检测支持多种常见格式:`YYYY-MM-DD`、`YYYY/MM/DD`、`DD-MM-YYYY`、`DD/MM/YYYY` 等。
- 异常值仅做高亮标记,不会删除原始数据。
- 图表自动选择基于第一组合适的列(优先非数值列作为 X 轴,数值列作为 Y 轴)。
- 如果数据中没有合适的数值列,图表 Sheet 会显示提示信息。

还有其它skill-creator的使用场景功能,可以自行试下哦。以下是使用技能的提示词示例。

场景 B:改进现有 Skill

1
2
我已经有一个处理 PDF 的 Skill,但发现它在处理扫描版 PDF 时经常失败。
请帮我运行一些测试,找出问题所在,并改进 Skill 的指令或添加辅助脚本。

场景 C:量化评估 Skill 效果

1
2
我优化了我的 xlsx-skill,想确认新版本是否真的比旧版本更好。
请帮我做一组盲测对比,看看在相同的 5 个测试用例上,新版和旧版谁的表现更好。

场景 D:优化 Skill 触发率

1
2
我发现我的 dashboard-skill 有时候用户提到"数据可视化"时不会被触发。
请帮我优化 SKILL.md 里的 description,提高触发准确率。

场景 E:打包分发

1
我的 Skill 已经测试好了,请帮我打包成 .skill 文件,。

补充学习资源

如您想要系统建立 AI Agent 全栈开发能力,从概念认知到企业级项目落地、线上迭代优化,可以参考《栖微 AI Agent 工程师实战成长营》专栏。专栏以六阶成长路径组织内容,配套实战源码与持续更新的前沿案例,补齐 Demo 到生产环境之间的工程化短板。

更多介绍:《栖微 AI Agent 工程师实战成长营》

Github 项目 :https://github.com/tinyseeking/tidy-agent-practice

欢迎大家一起探讨智能体开发相关问题。

Licensed under CC BY-NC-SA 4.0