Skill 升了版，你说不清楚哪里变好了吧？
winty约 8 分钟我每次跟人聊 Skill Hub，最难讲清的不是版本管理，也不是测试集设计，而是：
怎么"客观地"证明一个新版本比旧版本好。
听起来挺简单：跑一下测试，看看分数高了没。
但真做的时候你会发现：
这些问题，每一个都对应一种"看着像变好其实没变好"的陷阱。
我研究 Hermes Agent 之后，越来越觉得：版本对比不是"两个数字比大小"，而是一套需要严肃对待的工程动作。
这张图我画了 6 个常见的"假改进"陷阱：均值改善但分布退化、整体提升但 P0 翻车、主要场景持平边缘场景下滑、看似变好其实是测试集偏移、Token 暴涨换正确率、稳定性下降换正确率。每一个我都见过真实例子。
第一原则：永远多维度对比，不要只看一个数字
很多团队的版本对比报告长这样：
text
v1.3.0: 0.82
verdict: 变好了 ✅
这种"两个数字比大小"的判断，是非常危险的。
我建议的对比维度至少有 8 个：
每一个版本对比，都应该跨这 8 个维度看。
任何一个维度明显回退，都不能简单宣布"v2 比 v1 好"。
我自己做对比报告时会把这 8 个维度全列在一张表里，哪一项绿、哪一项红一目了然。这种结构化展示比"总分 +0.04"有信息量得多。
第二原则：分场景看，不要只看均值
均值最容易骗人。
举个真实例子：
text
按场景拆：
P0 cases (n=10): 0.65 → 0.50 (-15 pt) ❌
P1 cases (n=20): 0.78 → 0.85 (+7 pt) ✅
P2 cases (n=70): 0.81 → 0.87 (+6 pt) ✅
总体 +4pt，但 P0 场景回退 15 pt。
P0 是最关键的场景，回退就是事故。
这种 v2 你绝对不能因为"均值变高"就上线。
所以企业级 Skill 版本对比，必须按场景分层看：
每一类都要单独看。每一类都不能明显回退。
第三原则：失败 case 必须人眼复核
跑完评估之后，最有价值的不是"分数提升了多少"，而是：
v2 比 v1 多失败了哪些 case？少失败了哪些 case？
这个差集是版本升级的真正信号。
我的标准做法：
找出 v1 通过、v2 失败的 case（regression set） 找出 v1 失败、v2 通过的 case（improvement set） 找出 v1、v2 都失败但失败方式不同的 case（drift set）
每一组都让人眼看一遍。
text
- case-021: P0 支付故障，v1 正确定位 SLB，v2 误判为 Redis
- case-038: P1 数据库慢查询，v1 给出索引建议，v2 给出错误的 EXPLAIN 解读
Improvement (v1 ❌ → v2 ✅):
- case-014: P0 缓存穿透，v1 漏检查 Redis，v2 检查到了
- case-029: P1 接口超时，v1 没考虑下游，v2 正确分析了下游
Drift (✗ → ✗ but different):
- case-052: 同样失败，但 v2 失败方式不同（v1 死循环，v2 给出错误结论）
这种 diff 报告，比任何分数都有价值。
特别是 Regression 那一组，是判断 v2 能不能上线的关键。
如果 Regression set 有任何 P0 case，原则上不能上线。
第四原则：用统计方法，不要凭感觉
很多对比的"差距"其实在噪声范围内。
跑一次评估和跑 5 次评估，结果可能差好几个百分点。
如果你看到 v2 比 v1 高 2 个百分点，但每次跑结果都在 ±3 个百分点范围内波动，这个 2 个百分点根本不能说明问题。
我的实践：
每个版本至少跑 3 次评估 计算每次评估的 mean 和 std 用简单的统计判断差异是否显著
python
v1_mean, v1_std = A6E22E">mean(v1_runs), A6E22E">std(v1_runs)
v2_mean, v2_std = A6E22E">mean(v2_runs), A6E22E">std(v2_runs)
diff = v2_mean - v1_mean
pooled_std = (v1_std + v2_std) / AE81FF">2
F92672">return diff > AE81FF">2 * pooled_std
这是最简单的版本，更严肃可以用配对 t 检验之类。
但即便最简单的版本，也比"两个数字比大小"靠谱多了。
第五原则：Token 与时延必须纳入对比
很多团队只盯着正确率，忽略 Token 和时延。
这是大问题。
举个例子：
text
v1.3.0: overall 0.82, avg_tokens 14000, avg_latency 21s
正确率涨了 2 个百分点，但 Token 涨了 75%，时延涨了 75%。
这种 v2 在生产里的"实际收益"是负的：
不能算改进，应该回头优化。
我的经验：在企业级 Skill Hub 里，Token 和时延必须纳入版本门禁。
判断标准建议：
这两个数字可以根据业务调，但门禁必须存在。
一份完整的版本对比报告应该长什么样
把上面所有原则整合，一份合格的对比报告大致长这样：
yaml
comparison: v1.2.0 → v1.3.0
evaluation_date: 2026-04-30
evaluator_model: gpt-4-2026-04
runs_per_version: 3
overall:
v1_mean: 0.781
v2_mean: 0.823
diff: +0.042
significant: true (>2σ)
by_layer:
L1: 0.98 → 0.98 (no change)
L2: 0.72 → 0.88 (+16 pt) ✅
L3: 0.61 → 0.79 (+18 pt) ✅
L4: 0.92 → 0.94 (+2 pt) ✅
by_severity:
P0 (n=10): 0.65 → 0.62 (-3 pt) ⚠
P1 (n=20): 0.78 → 0.85 (+7 pt) ✅
P2 (n=70): 0.81 → 0.87 (+6 pt) ✅
stability:
consistency_score: 0.86 → 0.92 (+0.06) ✅
robustness_avg: 0.74 → 0.78 (+0.04) ✅
cost:
avg_tokens: 8200 → 8800 (+7%)
avg_latency: 11.2s → 12.0s (+7%)
regression_cases:
- case-021: P0 支付故障，v1 正确，v2 误判 Redis（必须修）
- case-027: P1 数据库慢查询，v1 正确建议，v2 给出错误 EXPLAIN
total: 2
improvement_cases:
- case-014: P0 缓存穿透 → v2 修复
- case-018: P0 SLB 检查 → v2 修复
- case-029: P1 下游分析 → v2 修复
- 其他 8 例 P2 改善
total: 11
verdict:
overall: "Improvement, but P0 regression must be fixed first"
blockers:
- case-021 必须修复
- case-027 必须修复
recommended_actions:
- 修复两个 P0 regression
- 修复后重新跑评估
- 通过后灰度 7 天再全量
这种报告才是 PR review 时该贴在评论里的东西。
reviewer 一眼就能看到关键信息：
真实场景：v2 上线被拦在了 P0 回退上
我讲一个真实案例。
某团队的 db-query Skill v2.0.0 评估结果总分提升 6 个百分点，团队很高兴，准备上线。
我让他们跑了一遍按场景拆分的对比报告：
text
SELECT (n=40): 0.85 → 0.92 (+7 pt) ✅
INSERT (n=20): 0.80 → 0.88 (+8 pt) ✅
UPDATE (n=20): 0.78 → 0.85 (+7 pt) ✅
DELETE (n=10): 0.70 → 0.40 (-30 pt) ❌
DDL (n=10): 0.65 → 0.30 (-35 pt) ❌
整体涨了，但 DELETE 和 DDL 直接腰斩。
DELETE 和 DDL 在他们公司里是高风险场景，绝对不能在这两类上回退。
补查原因：v2 改了个新 prompt，让 Agent 在写 query 之前更"激进"地考虑性能。
但激进之后，Agent 在 DELETE / DDL 这种本就该谨慎的场景上反而过度乐观。
最后这个 v2 没上线，回去改 Skill：在 DELETE / DDL 场景上保留 v1 的"先确认再执行"逻辑。
新版 v2.0.1 跑出来：
text
SELECT (n=40): 0.85 → 0.92 (+7 pt) ✅
INSERT (n=20): 0.80 → 0.88 (+8 pt) ✅
UPDATE (n=20): 0.78 → 0.85 (+7 pt) ✅
DELETE (n=10): 0.70 → 0.78 (+8 pt) ✅
DDL (n=10): 0.65 → 0.72 (+7 pt) ✅
这次全部场景都改进，才上线。
如果当时没拆按场景看，纯看总分，这个 v2.0.0 直接灰度上去，DELETE 翻车几次就是事故了。
让对比变成 PR 必经流程
最后一句务实建议：
不要让 Skill 对比报告成为"PR 作者愿意贴才贴"的东西。
我建议把它作为强制 CI：
PR 提交后自动触发评估 跑完之后自动生成对比报告 报告自动贴回 PR 评论 任何指标回退 > 阈值的 PR 自动加 regression标签带 regression标签的 PR 不能 merge 除非有特殊审批
这套机制看着重，但落地之后会发现：写 Skill 的人会明显谨慎很多，因为他们知道自己的改动会被客观度量。
这种"客观度量"的存在感，是企业 AI 系统从"靠人盯着"走向"流程化治理"的关键一步。
我的判断
很多人觉得"Skill 改进很难判断"，本质上是因为没把它当工程问题看。
把它当工程问题之后，工具其实都是现成的：
每一步都不复杂，但每一步都有人偷懒。
最容易偷懒的是"分场景看"。一个均值很容易骗人，一拆分就露馅。
下一篇我会把这一切串成一个 Skill 质量门禁 系统：什么样的 Skill 才能进入 Hub，什么样的版本升级才能上线，什么样的发布才允许全量。