新版 Prompt 的平均分从 82 提升到 85，能不能宣布优化成功？
只看这两个数字，不能。
差异可能来自随机输出，也可能来自两次使用了不同任务、不同模型参数或不同评分标准。即使整体平均分真的提升，某个高风险场景也可能已经明显退化。
要证明 Prompt、Skill 或模型变好了，需要同时处理四件事：
- 建立可比较的旧版基线；
- 在相同任务上做新旧版对照；
- 通过重复运行和分组结果排除误导；
- 把质量、成本、速度和适配范围放到同一决策里。
先说明这次修改想解决什么
一次迭代里同时改 Prompt、换模型、调整 Skill 描述、增加工具，再看到结果提升，团队很难知道是谁产生了作用。
更可控的做法是先写一条修改假设。
例如：
当前版本在输入信息不完整时会直接编造缺失内容。新版 Prompt 增加“缺失信息标记 TODO”的规则，预期降低编造，同时不降低正常任务的完整性。
这条假设说明了：
- 当前失败是什么；
- 修改发生在哪里；
- 预期改善哪个指标；
- 最担心造成什么副作用。
然后保存旧版完整配置：
- Prompt 与 Skill 版本；
- 模型及参数；
- 上下文、知识库和工具；
- 数据集与评分规则；
- 执行时间和运行环境。
旧版不是一个记忆中的印象，而是一套能够重新运行的可复现基线。
让新旧版在同一批任务上比较
最公平的比较，是让两个版本处理同一案例。
同一个 Case 使用相同输入、上下文、工具权限、运行次数和评分规则。这样可以减少任务难度差异对结论的干扰。
对开放性内容，除了绝对分，还可以做成对判断：
- 新版更好；
- 两者相当；
- 旧版更好。
成对比较更接近产品决策。团队真正想知道的不是新版得了多少分，而是在同一个用户任务上，哪个版本更值得保留。
如果使用 AI 裁判，应隐藏版本信息，并注意候选顺序可能影响判断。可以交换顺序后复评，争议案例再交给人工。
同一个案例为什么要多跑几次
大模型输出具有随机性。
旧版第一次失败、新版第一次成功，并不一定代表新版能力更强。它可能只是这一次采样更幸运。
重复运行能回答两个不同问题。
至少有一次能成功吗
有些探索型任务允许用户或系统重试。此时可以关注多次尝试中能否得到一个可用结果。
每一次都可靠吗
自动发布、数据修改或高风险执行通常不允许“多试几次总会成功”。这类任务更关心连续运行是否稳定。
运行次数没有统一标准。差异越小、波动越大、风险越高，越需要更多案例或更多重复运行。
对首次内部评估，关键案例运行三次可以帮助暴露明显波动，但它同样只是启动建议，不是统计充分性的保证。
不要让平均分隐藏退化
假设新版在 100 个案例中有 90 个轻微改善，但在 2 个高风险案例中发生严重越权。
平均分可能仍然上升，产品却显然不应发布。
结果至少需要从四个角度拆开看。
硬门
安全、权限、严重事实错误、虚假完成和不可恢复副作用单独计数。
这类问题通常不能被其他能力抵消。
核心任务
检查最重要的用户任务是否达到最低成功标准。新增能力不能以牺牲核心任务为代价。
关键分组
按照任务类型、风险、难度、语言、输入完整度或用户群体查看结果。
重点关注最差分组，而不是只看总体平均。
坏案例
保留新版胜出、旧版胜出和两者都失败的代表案例。判断差异来自指令、模型、工具、数据还是评分问题。
平均分适合概览，分组和坏案例决定能否上线以及下一步修改什么。
跨模型不是为了找“榜一”
同一个 Prompt 或 Skill 在不同模型上的表现可能不同。
有的模型更容易遵循格式，有的模型工具调用更稳定，有的模型质量更高但成本也更高。跨模型评估的目标不是选一个所有榜单上最强的模型，而是判断目标场景中的适配关系。
先定义模型范围：
- 必须支持的主模型；
- 可以降级使用的备选模型；
- 仅用于特定高价值任务的模型。
然后按模型分别报告：
| 维度 | 需要观察的内容 |
|---|---|
| 质量 | 正确性、完整性、任务完成 |
| 兼容 | 指令遵循、Skill 触发、工具调用 |
| 稳定 | 重复成功率、结果波动 |
| 安全 | 严重失败、越权和拒绝边界 |
| 效率 | 延迟、Token、工具调用和单次成本 |
不要把不同模型合并成一个平均值。主模型退化时，备选模型的高分不能替它通过。
如果新版只对一个模型有效，需要决定是接受模型特定版本，还是继续寻找更通用的设计。模型特定适配会带来额外维护和回归成本，也应进入产品决策。
怎样判断“真的变好”
一个较完整的版本结论可以按顺序判断。
第一步：结果是否有效
运行是否完整？数据集、评分器和配置是否一致？是否存在大量工具异常或丢失结果？
实验本身无效时，不应继续解释分数。
第二步：硬门是否通过
严重安全、权限和任务底线是否满足？
任何关键硬门失败，都不应用总分补偿。
第三步：核心能力是否改善
新版在同案例上是否稳定胜出？差异是否集中在目标失败模式？核心任务和关键分组有没有退化？
第四步：改善是否值得
质量提升是否足以覆盖额外成本、延迟和维护复杂度？
统计上存在差异，不等于用户一定能感知，也不等于商业上值得。
第五步：结论适用于哪里
写明支持的模型、场景、风险范围和仍未覆盖的情况。不要把小型内部数据集的结论外推成“全面提升”。
最终决策可以是：
- Go：硬门通过，核心能力可信改善，成本可接受；
- 灰度：结果有希望但仍有不确定性，需要真实流量验证；
- 补测：样本不足、波动较大或评分分歧明显；
- No-Go：严重退化，或者提升不足以覆盖成本与风险；
- 分模型发布：只对部分模型保留新版，并承担额外维护。
证明一个版本变好，不是找到一个更高的分数，而是建立一条其他人可以复查、重复并据此做决定的证据链。
下一篇将解决效率问题：哪些检查适合规则自动化，怎样用大模型做 AI 裁判，以及常见工具分别替团队省下哪一步。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好（本文）
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥