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，并说明理由。”””`
### 完整测试矩阵
| 测试用例 | 触发 | 交互流程 | 配置完整 | 代码可执行 | 逻辑合理 |
| — | — | — | — | — | — |
| 模糊输入：”想买几个 AI 股” | ✓ | 问了 universe、signal、weighting | ✓ | ✓ | 需人工 |
| 明确输入：”RSI 均值回归 SP500″ | ✓ | 只补充缺失字段 | ✓ | ✓ | 需人工 |
| 不支持请求：”做个期权策略” | ✓ | 明确拒绝并给替代方案 | N/A | N/A | ✓ |
| 边缘情况：”只给一个 ticker” | ✓ | 警告风险但继续 | ✓ | ✓ | 需人工 |
### 迭代改进方向
跑完评估后，常见的改进点：
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 是改出来的，不是一次写好的
