如何评估你的 Skill 质量------从触发准确率到输出质量的系统方法
你写的 Skill 跑通了几个测试用例，不代表它好用。换个 prompt 就翻车的情况，比你想象的常见得多。
目录
- [为什么需要评估 Skill](#为什么需要评估 Skill "#%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81%E8%AF%84%E4%BC%B0-skill")
- 维度一：触发准确率
- 维度二：输出质量
- 维度三：效率指标
- 评估流程四步走
- 四个常见陷阱
- [深度案例：量化策略构建 Skill 的评估](#深度案例：量化策略构建 Skill 的评估 "#%E6%B7%B1%E5%BA%A6%E6%A1%88%E4%BE%8B%E9%87%8F%E5%8C%96%E7%AD%96%E7%95%A5%E6%9E%84%E5%BB%BA-skill-%E7%9A%84%E8%AF%84%E4%BC%B0")
- 迭代改进原则
- 工具推荐
为什么需要评估 Skill
你花了一个下午写了一个 Skill，测试了三五个 prompt，Agent 表现不错。你把它提交到仓库里，觉得大功告成。
然后上线后发现：换个说法就不触发了，触发了但输出格式不对，格式对了但 token 消耗比没用 Skill 还多。
问题出在哪？开发时的几个例子不能代表真实场景。 Skill 的价值在于被重复使用------你和用户在开发时只能测几个例子，但上线后可能被调用成千上万次。如果只在开发时"跑得通"，但换个场景就废了，那这个 Skill 就是废的。
用机器学习的术语来说，这叫过拟合：在训练集上表现很好，但泛化能力差。Skill 评估的核心目标就是确保泛化能力------不是在你精心构造的几个例子上过关，而是在真实用户的千变万化的表达下都能正确工作。
评估从三个维度入手：触发准确率、输出质量、效率指标。
维度一：触发准确率
Skill 的 description 字段决定了 Agent 什么时候会调用它。这个字段写得好，Agent 能精准识别需要这个 Skill 的场景；写得差，要么该触发不触发，要么不该触发乱触发。
评估触发准确率需要准备两类测试用例。
正例（should_trigger: true）
这些是应该触发 Skill 的 prompt。关键是要覆盖不同的表达方式：
- 正式表达："请按照 NVC 四步法评估这段对话的沟通质量"
- 口语化："帮我看看这段对话哪里说得不好"
- 简略："评分"
- 隐含需求：用户没有明确提到 Skill 名称，但需求明显指向这个能力------"我跟室友吵架了，帮我分析一下我的表达有什么问题"
用 NVC Practice 项目的 nvc-scoring-engine Skill 举例：
json
[
{"query": "帮我按照 NVC 四步法给这段对话打分", "should_trigger": true},
{"query": "分析一下我刚才的回复哪里需要改进", "should_trigger": true},
{"query": "评分", "should_trigger": true},
{"query": "我和女朋友吵架了，看看我的表达有什么问题", "should_trigger": true},
{"query": "观察、感受、需要、请求，我的回答每个维度多少分", "should_trigger": true}
]负例（should_trigger: false）
这些是不应该触发 Skill 的 prompt。负例的质量决定了测试的价值。 太简单的负例没有意义------"写个斐波那契函数"作为评分引擎的负例，任何 description 都不会误触发。好的负例应该是"差一点就该触发"的那种：
json
[
{"query": "NVC 理论的四个步骤是什么", "should_trigger": false},
{"query": "帮我写一段模拟对话，展示非暴力沟通的用法", "should_trigger": false},
{"query": "推荐几本关于非暴力沟通的书", "should_trigger": false},
{"query": "我的练习会话卡住了，一直在加载", "should_trigger": false},
{"query": "怎么在数据库里查询所有评分低于 60 的对话记录", "should_trigger": false}
]这些负例的难度在于：它们都和 NVC 相关，但需求分别是理论查询、内容创作、推荐、排障、数据库操作------都不是"评分引擎"该干的事。如果 Skill 在这些用例上错误触发，说明 description 写得太宽泛了。
维度二：输出质量
Skill 触发了，Agent 也按 Skill 的指引做了，但输出质量怎么样？这个维度分两种评估方式。
定量评估（Assertions）
有些输出质量可以用脚本自动检查，结果是 pass/fail，没有主观性：
- 输出文件是否存在：Skill 要求生成报告，报告文件产出了吗？
- 格式是否正确：JSON 能解析吗？YAML 的缩进对吗？
- 关键字段是否包含 ：评分结果里有没有
score、feedback、dimension这些字段？ - 数值是否在预期范围内：NVC 评分应该是 0-100 的整数，有没有出现负数或小数？
这些断言的价值在于可重复------同一个 Skill 跑 10 次，断言的结果应该一致。
定性评估（Human Review）
有些东西没法量化，必须人来看：
- 内容是否符合预期：评分的反馈是不是真的指出了用户表达的问题？
- 风格是否合适：反馈的语气是鼓励性的还是打击性的？
- 细节是否到位：改写示例是不是真的比用户原句更符合 NVC 原则？
"写作风格是否自然"------你没法写一个断言来检查这个。定性评估是必须的，但可以通过结构化的方式降低主观性：准备一份评分 rubric（评分标准），让评估者按维度打分，而不是笼统地说"好"或"不好"。
维度三：效率指标
Skill 让 Agent 变强了，但代价是什么？
- Token 消耗：用了 Skill 之后，Agent 的上下文窗口多了多少 token？如果 Skill 主文件就有 5000 token，但实际只用到了其中 500 token 的知识，剩下 4500 token 就是浪费。
- 执行时间：完成任务需要多久？如果 Agent 按照 Skill 的指引走了 12 步，但其实 3 步就能搞定，说明 Skill 里有冗余指令。
- 步骤数量：Agent 是不是在做无用功？看 transcript（执行日志），如果 Agent 在某个步骤上反复尝试，说明这部分指引不够清晰。
效率指标帮你发现 Skill 中拖后腿的部分。如果模型每次都花大量时间做同一件事，说明这部分应该被抽成脚本，让机器做机器擅长的事。
评估流程四步走
Step 1：准备测试用例
写 2-3 个真实的用户 prompt。不是"处理数据"这种抽象描述，而是具体的：
"我老板发了个 xlsx 文件（在我下载文件夹里，叫 'Q4 sales final FINAL v2.xlsx'），她要我加一列显示利润率百分比。收入在 C 列，成本在 D 列"
这种带上下文、有细节、甚至有错别字的 prompt 才是真实场景。用户不会按你 Skill 文档里的术语说话。
Step 2：跑对照实验
每个测试用例跑两个版本：
- 有 Skill：正常使用
- 基线版：没有 Skill / 旧版 Skill
这样才能知道 Skill 到底带来了什么改进。如果两个版本的结果差不多，要么是 Skill 没用，要么是测试用例太简单。
Step 3：收集反馈
让用户看输出结果，给反馈。一个简单的规则：空反馈 = 满意，有文字 = 有问题。 用户不说话说明结果可以接受，用户开口了说明有改进空间。
重点关注有具体抱怨的用例。"评分结果里没有改写示例"比"感觉不太好"有价值得多。
Step 4：迭代改进
根据反馈改 Skill，但要遵守三条原则（后面展开讲）。
四个常见陷阱
陷阱一：测试用例太简单。 "读取这个 PDF"不会触发任何专业 Skill，因为 Agent 可以直接用基础工具处理。要测试复杂的、多步骤的、专业化的任务。简单用例通过了不代表 Skill 好用，只代表 Agent 本身够聪明。
陷阱二：只看成功的用例。 失败的用例才是改进的方向。如果所有测试都通过了，要么是测试太简单，要么是覆盖不够。主动去找失败案例，比庆祝成功案例有价值得多。
陷阱三：断言没有区分度。 如果一个断言不管有没有 Skill 都能通过，那它没有任何测试价值。好的断言应该能区分出 Skill 带来的改进。比如"输出包含评分"这个断言太弱------没 Skill 的时候 Agent 也会给评分。"输出包含按 NVC 四个维度分别评分，每个维度有具体反馈和改写示例"才有区分度。
陷阱四：忽视方差。 同一个 prompt 跑多次，结果可能不一样。高方差意味着 Skill 不稳定。如果一个 prompt 跑 5 次，3 次很好、2 次翻车，说明 Skill 的指引有模糊地带，模型在某些路径上做出了不同的选择。
深度案例：量化策略构建 Skill 的评估
讲完通用方法，来看一个具体例子。
Strategy Builder 是一个把模糊的投资想法转化为可执行量化策略的 Skill。用户说"我想买几个 AI 股"，它会通过对话收集需求，最终输出一套完整的策略配置和可执行代码。
这个 Skill 的特殊之处在于：输出不是文档或代码那么简单，而是一整套交互流程加最终的策略配置加可执行代码。评估起来比一般 Skill 复杂得多，但它恰好覆盖了所有评估维度，适合做深度剖析。
维度一：触发准确率
正例：
json
[
{"query": "我想买 AXTI, IQE, LITE 这几只股票", "should_trigger": true},
{"query": "帮我搞一个 AI 光通信相关的策略", "should_trigger": true},
{"query": "想做一个动量策略，标普500成分股，每周调仓", "should_trigger": true}
]负例（难度要高）：
json
[
{"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 个维度让用户填）
- 是否提供了选项而不是开放式问题？
- 是否在用户模糊时给出了合理默认值？
- 是否在用户要求不支持的功能时明确说明而不是默默忽略？
- 是否定期总结已确定的内容？
自动化断言：
python
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 策略配置。必须验证关键字段：
python
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"
}
]最后一条断言检查的是仓位逻辑：最大持仓比例乘以最大持仓数量必须至少为 1，否则数学上就不可能满仓。这种逻辑错误人工很难发现，但断言一秒就能抓到。
维度四：代码可执行性
最硬核的评估：生成的 Python 代码能不能跑。
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（让另一个 LLM 当评审）做初筛：
python
judge_prompt = """
用户原始需求: {user_request}
生成的策略配置: {strategy_yaml}
请判断策略配置是否合理反映了用户需求。
评分 1-5，并说明理由。
"""完整测试矩阵
| 测试用例 | 触发 | 交互流程 | 配置完整 | 代码可执行 | 逻辑合理 |
|---|---|---|---|---|---|
| 模糊输入："想买几个 AI 股" | ✅ | 问了 universe、signal、weighting | ✅ | ✅ | 需人工 |
| 明确输入："RSI 均值回归 SP500" | ✅ | 只补充缺失字段 | ✅ | ✅ | 需人工 |
| 不支持请求："做个期权策略" | ✅ | 明确拒绝并给替代方案 | N/A | N/A | ✅ |
| 边缘情况："只给一个 ticker" | ✅ | 警告风险但继续 | ✅ | ✅ | 需人工 |
迭代改进原则
跑完评估后，根据反馈改 Skill。但改的时候要注意三条原则。
泛化而不是过拟合。 用户说"这个图表没有坐标轴标签"，不要加一条"必须给图表加坐标轴标签"的硬规则。要理解为什么模型会漏掉------是 Skill 里没有提到图表规范？还是提到了但不够具体？从根本上解决问题，而不是针对某一个用例打补丁。加一条硬规则可能解决了这一个 case，但下次用户换个需求又会漏别的。
解释 Why 而不是堆 MUST。 当你发现自己在写"ALWAYS"和"NEVER"的时候，停下来想想能不能换个方式解释清楚背后的原因。"必须用 HNSW 索引"不如"HNSW 在查询密集场景下延迟更低，RAG 的写入频率远低于查询频率，所以选 HNSW"。模型很聪明，给它理由比给它命令更有效。
保持精简。 看 transcript，如果模型在某个步骤上浪费时间，考虑删掉那部分指令。Skill 不是越长越好。每一条指令都有 token 成本------如果它不能显著提升输出质量，就不该存在。
工具推荐
Codex 生态 ：skill-creator 自带评估工具链------aggregate_benchmark 脚本自动聚合评估结果，generate_review.py 生成可视化的评估界面，run_loop.py 自动化优化 description 的触发率。
通用方案：手动跑测试用例，在对话中收集反馈。没有工具链也能做评估------准备 5 个测试 prompt，分别在有 Skill 和没有 Skill 的情况下跑一遍，对比结果。这比"跑通了就行"靠谱得多。
LLM-as-judge：让另一个 LLM 当评审，按评分标准打分。适合做初筛------把明显不合格的输出先过滤掉，减少人工审阅量。但不能完全替代人工，尤其是涉及风格、语气、业务逻辑合理性这些主观维度。
写在最后
好的 Skill 是改出来的，不是一次写好的。评估不是一次性的工作，而是一个持续迭代的过程：写测试用例 → 跑对照实验 → 收集反馈 → 分析问题 → 改进 Skill → 重复。
不要追求第一个版本就完美。追求第一个版本就有测试用例，然后在真实使用中不断发现盲区、修补漏洞。Skill 的质量曲线不是一条直线，而是一个阶梯------每次评估发现一个新问题，解决后 Skill 就上一个台阶。