Agent Skills Systematically with Evals" class="rich_pages wxw-img" data-ratio="0.3685185185185185" data-type="png" data-w="1080" data-imgfileid="100006234" data-aistatus="1">

写完一个 Skill 之后，怎么知道它好不好用？靠感觉？靠运气？

不行。得有系统的评估方法。

为什么需要评估

Skill 的价值在于被重复使用。你和用户在开发时只能测试几个例子，但真正上线后可能被调用成千上万次。如果只在开发时的几个例子上"跑得通"，但换个场景就翻车，那这个 Skill 就是废的。

所以评估的核心目标是：确保 Skill 的泛化能力，而不是在特定例子上过拟合。

评估的三个维度

1. 触发准确率（Trigger Accuracy）

Skill 的 description 字段决定了 Claude 什么时候会调用它。评估触发率需要准备两类测试用例：

应该触发的（should_trigger: true）

• 覆盖不同的表达方式：正式的、口语的、简略的
• 用户没有明确提到 Skill 名称但明显需要它的场景
• 边缘用例和非典型场景

不应该触发的（should_trigger: false）

• 关键词相似但实际需求不同的场景
• 与其他 Skill 有竞争关系但应该让给对方的场景
• 表面相关但实际不需要这个 Skill 的情况

关键是：不要写太明显的负例。"写个斐波那契函数"作为 PDF Skill 的负例没有任何测试价值，因为太明显了。好的负例应该是"差一点就该触发"的那种。

2. 输出质量（Output Quality）

分为定量和定性两种评估：

定量评估（Assertions）

• 输出文件是否存在
• 格式是否正确
• 关键字段是否包含
• 数值是否在预期范围内

这些可以用脚本自动检查，结果是 pass/fail，没有主观性。

定性评估（Human Review）

• 内容是否符合预期
• 风格是否合适
• 细节是否到位

这需要人来看，因为很多东西没法量化。比如"写作风格是否自然"——你没法写一个断言来检查这个。

3. 效率指标（Efficiency Metrics）

• Token 消耗：Skill 让模型多用了还是少用了 token？
• 执行时间：完成任务需要多久？
• 步骤数量：模型是不是在做无用功？

这些指标帮你发现 Skill 中拖后腿的部分。如果模型每次都花大量时间做同一件事，说明这部分应该被抽成脚本。

评估流程

Step 1: 准备测试用例

写 2-3 个真实的用户 prompt，不是抽象的"处理数据"，而是具体的：

“

"我老板发了个 xlsx 文件（在我下载文件夹里，叫 'Q4 sales final FINAL v2.xlsx'），她要我加一列显示利润率百分比。收入在 C 列，成本在 D 列"

这种带上下文、有细节、甚至有错别字的 prompt 才是真实场景。

Step 2: 跑对照实验

每个测试用例要跑两个版本：

• 有 Skill ：正常使用 Skill
• 基线版：没有 Skill / 旧版 Skill

这样才能知道 Skill 到底带来了什么改进。

Step 3: 收集反馈

让用户看输出结果，给反馈。空反馈 = 满意，有文字 = 有问题。

重点关注有具体抱怨的用例，而不是试图让所有用例都完美。

Step 4: 迭代改进

根据反馈改 Skill，但要注意：

泛化而不是过拟合。如果用户说"这个图表没有坐标轴标签"，不要加一条"必须给图表加坐标轴标签"的硬规则。要理解为什么会漏掉，从根本上解决问题。

解释 Why 而不是堆 MUST。当你发现自己在写"ALWAYS"和"NEVER"的时候，停下来想想能不能换个方式解释清楚背后的原因。模型很聪明，给它理由比给它命令更有效。

保持精简。看 transcript，如果模型在某个步骤上浪费时间，考虑删掉那部分指令。

常见的评估陷阱

陷阱 1: 测试用例太简单

"读取这个 PDF"这种 prompt 不会触发 Skill，因为 Claude 可以直接用基础工具处理。要测试复杂的、多步骤的、专业化的任务。

陷阱 2: 只看成功的用例

失败的用例才是改进的方向。如果所有测试都通过了，要么是测试太简单，要么是覆盖不够。

陷阱 3: 断言没有区分度

如果一个断言不管有没有 Skill 都能通过，那它没有任何测试价值。好的断言应该能区分出 Skill 带来的改进。

陷阱 4: 忽视方差

同一个 prompt 跑多次，结果可能不一样。高方差意味着 Skill 不稳定，需要排查原因。

工具推荐

如果你在用 Claude Code 或 Cowork，可以用 skill-creator 自带的评估工具：

• aggregate_benchmark 脚本：自动聚合评估结果
• generate_review.py：生成可视化的评估界面
• run_loop.py：自动化优化 description 的触发率

如果在 claude.ai 上，就手动跑测试用例，直接在对话里收集反馈。

实战案例：如何评估量化策略构建 Skill

讲完通用方法，来看一个具体例子：Strategy Builder Skill——一个把模糊的投资想法转化为可执行量化策略的 Skill。

这个 Skill 的特殊之处在于：它的输出不是文档或代码那么简单，而是一整套交互流程 + 最终的策略配置 + 可执行代码。评估起来比一般 Skill 复杂得多。

评估维度 1: 触发准确率

应该触发的用例：

[
  {\"query\": \"我想买 AXTI, IQE, LITE 这几只股票\", \"should_trigger\": true},
  {\"query\": \"帮我搞一个 AI 光通信相关的策略\", \"should_trigger\": true},
  {\"query\": \"I'm bullish on semiconductors, how do I build a strategy?\", \"should_trigger\": true},
  {\"query\": \"这几个票 NVDA AVGO MRVL 怎么配比比较好\", \"should_trigger\": true},
  {\"query\": \"想做一个动量策略，标普500成分股，每周调仓\", \"should_trigger\": true}
]

不应该触发的用例（难度要高）：

[
  {\"query\": \"NVDA 现在多少钱\", \"should_trigger\": false},
  {\"query\": \"帮我分析一下苹果的财报\", \"should_trigger\": false},
  {\"query\": \"我已经有策略了，帮我下单买入 AAPL 100股\", \"should_trigger\": false},
  {\"query\": \"做一个 BTC/ETH 的套利策略\", \"should_trigger\": false},
  {\"query\": \"帮我写个期权 covered call 策略\", \"should_trigger\": false}
]

最后三个是关键负例：

• 第三个看起来像策略相关，但用户要的是执行，不是构建
• 第四个涉及 crypto，这个 Skill 不支持
• 第五个涉及 options，也不支持

如果 Skill 在这些用例上错误触发，说明 description 写得太宽泛了。

评估维度 2: 交互流程质量

Strategy Builder 是对话式的，要评估的不只是最终输出，还有中间交互是否合理。

定性检查清单：

• 是否一次只问一个问题？（不能一下子抛出 7 个维度让用户填）
• 是否提供了选项而不是开放式问题？
• 是否在用户模糊时给出了合理默认值？
• 是否在用户要求不支持的功能时明确说明？
• 是否定期总结已确定的内容？

自动化断言（可脚本检查）：

assertions = [
    {
        \"name\": \"single_question_per_turn\",
        \"check\": \"count('?') <= 2 in each assistant turn\"
    },
    {
        \"name\": \"offers_options\",
        \"check\": \"contains numbered list or bullet options when asking\"
    },
    {
        \"name\": \"acknowledges_limitations\",
        \"check\": \"if user asks for options/crypto/shorts, response contains 'not supported' or 'limitation'\"
    }
]

评估维度 3: 策略配置完整性

最终输出是一个 YAML 配置。必须验证：

assertions = [
    {
        \"name\": \"has_universe\",
        \"check\": \"yaml.universe is defined and has at least 1 ticker\"
    },
    {
        \"name\": \"has_signal\",
        \"check\": \"yaml.signal.type in ['momentum', 'mean_reversion', 'trend', 'fundamental', 'event']\"
    },
    {
        \"name\": \"has_weighting\",
        \"check\": \"yaml.weighting.method is defined\"
    },
    {
        \"name\": \"has_execution\",
        \"check\": \"yaml.execution.rebalance_freq is defined\"
    },
    {
        \"name\": \"position_math_valid\",
        \"check\": \"yaml.weighting.max_position_pct * yaml.risk_management.max_positions >= 1.0\"
    },
    {
        \"name\": \"top_n_valid\",
        \"check\": \"if momentum_top_n defined, top_n <= len(universe.tickers)\"
    }
]

评估维度 4: 生成代码的可执行性

最硬核的评估：生成的 Python 代码能不能跑。

def test_generated_code(code_path):
    # 1. 语法检查
    import ast
    with open(code_path) as f:
        ast.parse(f.read())  # 如果语法错会抛异常
    
    # 2. 导入检查
    import subprocess
    result = subprocess.run(
        ['python', '-c', f'import {code_path.stem}'],
        capture_output=True
    )
    assert result.returncode == 0, \"Import failed\"
    
    # 3. 回测能跑（用历史数据）
    # 这个要小心，可能很慢，考虑用 mock 数据

评估维度 5: 策略逻辑合理性

这是最难自动化的部分，需要人工判断：

• 用户说"我看好 AI"，生成的 universe 是否真的包含 AI 相关股票？
• 用户说"保守一点"，stop loss 设置是否比默认值更紧？
• 用户说"不想频繁交易"，rebalance 频率是否设成 monthly 或更低？

可以用 LLM-as-judge 做初筛：

judge_prompt = \"\"\"
用户原始需求: {user_request}
生成的策略配置: {strategy_yaml}

请判断策略配置是否合理反映了用户需求。
评分 1-5，并说明理由。
\"\"\"

完整测试矩阵

迭代改进方向

跑完评估后，常见的改进点：

1. 问题太多：模型把 7 个维度全问了一遍，即使用户已经给了很多信息。改进：让 Skill 先解析用户输入，只问缺失的字段。

2. 默认值不合理：用户说"保守"，但 stop loss 还是用默认的 10%。改进：在 Skill 里加上语义映射，"保守" → 更紧的风控。

3. 不支持功能的处理太生硬：用户要期权策略，Skill 直接说"不支持"就没了。改进：给出替代方案或手动实现指引。

4. 生成代码有 bug：某些组合下代码跑不通。改进：加更多边界条件检查，或者换用更鲁棒的模板。

总结

评估 Skill 质量不是一次性的事，是一个持续迭代的过程：

1. 写测试用例（真实、具体、有细节）
2. 跑对照实验（有 Skill vs 没 Skill）
3. 收集反馈（定量 + 定性）
4. 分析问题（看 transcript，找根因）
5. 改进 Skill（泛化，不过拟合）
6. 重复

对于像 Strategy Builder 这样的复杂 Skill，评估维度更多：触发准确率、交互流程、配置完整性、代码可执行性、逻辑合理性——每个维度都要有对应的检查方法。

好的 Skill 是改出来的，不是一次写好的