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 的泛化能力，而不是在特定例子上过拟合。
评估的三个维度
Skill 的 description 字段决定了 Claude 什么时候会调用它。评估触发率需要准备两类测试用例：
应该触发的（should_trigger: true）
覆盖不同的表达方式：正式的、口语的、简略的 用户没有明确提到 Skill 名称但明显需要它的场景 边缘用例和非典型场景
不应该触发的（should_trigger: false）
关键词相似但实际需求不同的场景 与其他 Skill 有竞争关系但应该让给对方的场景 表面相关但实际不需要这个 Skill 的情况
关键是：不要写太明显的负例。"写个斐波那契函数"作为 PDF Skill 的负例没有任何测试价值，因为太明显了。好的负例应该是"差一点就该触发"的那种。
分为定量和定性两种评估：
定量评估（Assertions）
输出文件是否存在 格式是否正确 关键字段是否包含 数值是否在预期范围内
这些可以用脚本自动检查，结果是 pass/fail，没有主观性。
定性评估（Human Review）
内容是否符合预期 风格是否合适 细节是否到位
这需要人来看，因为很多东西没法量化。比如"写作风格是否自然"——你没法写一个断言来检查这个。
- Token 消耗：Skill 让模型多用了还是少用了 token？
- 执行时间：完成任务需要多久？
- 步骤数量：模型是不是在做无用功？
这些指标帮你发现 Skill 中拖后腿的部分。如果模型每次都花大量时间做同一件事，说明这部分应该被抽成脚本。
评估流程
写 2-3 个真实的用户 prompt，不是抽象的"处理数据"，而是具体的：
“ "我老板发了个 xlsx 文件（在我下载文件夹里，叫 'Q4 sales final FINAL v2.xlsx'），她要我加一列显示利润率百分比。收入在 C 列，成本在 D 列"
这种带上下文、有细节、甚至有错别字的 prompt 才是真实场景。
每个测试用例要跑两个版本：
- 有 Skill ：正常使用 Skill
- 基线版：没有 Skill / 旧版 Skill
这样才能知道 Skill 到底带来了什么改进。
让用户看输出结果，给反馈。空反馈 = 满意，有文字 = 有问题。
重点关注有具体抱怨的用例，而不是试图让所有用例都完美。
根据反馈改 Skill，但要注意：
泛化而不是过拟合。如果用户说"这个图表没有坐标轴标签"，不要加一条"必须给图表加坐标轴标签"的硬规则。要理解为什么会漏掉，从根本上解决问题。
解释 Why 而不是堆 MUST。当你发现自己在写"ALWAYS"和"NEVER"的时候，停下来想想能不能换个方式解释清楚背后的原因。模型很聪明，给它理由比给它命令更有效。
保持精简。看 transcript，如果模型在某个步骤上浪费时间，考虑删掉那部分指令。
常见的评估陷阱
"读取这个 PDF"这种 prompt 不会触发 Skill，因为 Claude 可以直接用基础工具处理。要测试复杂的、多步骤的、专业化的任务。
失败的用例才是改进的方向。如果所有测试都通过了，要么是测试太简单，要么是覆盖不够。
如果一个断言不管有没有 Skill 都能通过，那它没有任何测试价值。好的断言应该能区分出 Skill 带来的改进。
同一个 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 复杂得多。
应该触发的用例：
[
{\"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 写得太宽泛了。
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'\"
}
]
最终输出是一个 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)\"
}
]
最硬核的评估：生成的 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 数据
这是最难自动化的部分，需要人工判断：
用户说"我看好 AI"，生成的 universe 是否真的包含 AI 相关股票？ 用户说"保守一点"，stop loss 设置是否比默认值更紧？ 用户说"不想频繁交易"，rebalance 频率是否设成 monthly 或更低？
可以用 LLM-as-judge 做初筛：
judge_prompt = \"\"\"
用户原始需求: {user_request}
生成的策略配置: {strategy_yaml}
请判断策略配置是否合理反映了用户需求。
评分 1-5，并说明理由。
\"\"\"
跑完评估后，常见的改进点：
问题太多：模型把 7 个维度全问了一遍，即使用户已经给了很多信息。改进：让 Skill 先解析用户输入，只问缺失的字段。
默认值不合理：用户说"保守"，但 stop loss 还是用默认的 10%。改进：在 Skill 里加上语义映射，"保守" → 更紧的风控。
不支持功能的处理太生硬：用户要期权策略，Skill 直接说"不支持"就没了。改进：给出替代方案或手动实现指引。
生成代码有 bug：某些组合下代码跑不通。改进：加更多边界条件检查，或者换用更鲁棒的模板。
总结
评估 Skill 质量不是一次性的事，是一个持续迭代的过程：
- 写测试用例（真实、具体、有细节）
- 跑对照实验（有 Skill vs 没 Skill）
- 收集反馈（定量 + 定性）
- 分析问题（看 transcript，找根因）
- 改进 Skill（泛化，不过拟合）
- 重复
对于像 Strategy Builder 这样的复杂 Skill，评估维度更多：触发准确率、交互流程、配置完整性、代码可执行性、逻辑合理性——每个维度都要有对应的检查方法。
好的 Skill 是改出来的，不是一次写好的
