先证明评测可信再爬分：判分器、噪声先验过，每轮只改一处、靠留出集拦过拟合
好评测有四个可检验的要素：样本贴近生产、模型越强或思考越多分数越高、最强配置下离满分仍有余量、多次运行方差低。每个要素失效时都有可观测的征兆。
这四条本质上是评测的健康检查。如果换更强的模型或调高 effort 分数却不涨，通常说明任务有歧义，或者判分器没校准。如果某道题在所有重复运行里都失败，它多半是无解题或歧义题，不能当作真实的余量。环境残留（上一轮留下的文件、git 历史）可能直接把答案递给 agent；effort 没有被一致地应用，也会制造假方差。判断一道题合格的标准是：两位领域专家会给出相同结论，而且判分器检查的每一项都在题面里写明了。
“a common tell is that a task fails every evaluation run” ¶7
文章的原则 ¶6 说更强模型应该得分更高，可成本案例里 Sonnet 5 低 effort 和 Opus 5.5 低 effort 分数几乎一样，最终在 search 集上接近饱和。这说明该评测对模型能力可能不敏感，和文章自己的健康检查原则存在张力，但文章没有讨论。
专挑当前模型做错的题来出评测，测到的是这个模型自己的失败特征，而不是你的应用真正难做、真正值钱的部分。
模型能力分布是参差不齐的。按「当前模型做不对」来采样，等于只采了它能力曲面上的低谷；下一代模型的低谷位置一变，评测就失效了。文章的替代做法是：一道题纳入前，先说得出它为什么难（由人判断难度）；同时加入来自生产流量、bug 报告、工单的真实失败。但也不能全靠用户流量，因为用户倾向于尝试他们预期能成功的事，这样采出来的分布会偏简单。build-eval 的采样顺序是：生产对话记录（先问清保留期和敏感数据）、bug 报告和工单、手写五到十个用例、最后才从代码库合成。
“you are sampling the valleys of one model's capability surface” ¶9
这一点暂无对应的审视。
评测里最常见的配置错误出在判分环节，所以判分器必须先验证再使用。选判分器时，取能满足需求的最便宜的方案。
输出空间受限时用程序化校验，比如精确匹配、固定标签集、JSON schema、跑测试。输出开放时才用 LLM-as-judge，且有三点要求：rubric 写成可逐条核查的断言，不用 1 到 5 的打分量表；有基线时让 judge 在随机顺序、不知道哪个是基线的情况下二选一；judge 不能是被测模型。跑基线时还有三项诊断：同一份输出判两次，看结论是否一致；检查超时、API 报错和截断，避免基础设施噪声被当成模型方差（plumbing）；基线已经在 95% 上下时发出警告，建议转去优化成本或延迟。
“scoring failures are among the most common ways an evaluation is misconfigured” ¶21
判分器双判一致性、plumbing 检查、噪声地板这三项诊断，不依赖 skill 也能在自己的评测上复现，成本很低。
hillclimb 适合用在改起来便宜、分数变化能归因、目标边界清楚的对象上。评测饱和以后，「保持性能、压低成本」仍然是一个可以继续优化的目标。
prompt、skill 这类文本改起来和回滚都便宜；开放式地改 harness 代码，往往要动大量代码。可归因的典型例子是 skill 触发：评测指标是触发率，被修改的正是 skill 的 description，两者直接耦合。最常见的失败是在接近饱和的评测上提开放式的「提升性能」要求，这种情况容易停滞。文中的成本例子显示，在新模型上用低 effort 就能超过旧模型的默认 high 档，降档后成本还能继续下降。
“reduce cost while keeping performance at parity” ¶30
这篇文章是在推广自家 skill 和新模型。成本案例里有一部分节约直接来自 Opus 5.5 的定价：输入输出便宜 20%，缓存读便宜 60%，原文自己也承认这一点。所以「成本降到约五分之一」不能全部算作 hillclimb 方法的功劳。
防过拟合靠三条结构性约束：切分 train 和 test、不把失败内容直接粘进 prompt、让答案在结构上不可达。hillclimb 把这三条做成了自动的保留或回滚规则。
评测会通过 harness 渗进系统：为评测里的 OCR 题加一个 OCR 工具，为固定路径写死 cd /app，为特定措辞调 prompt，为读到的每个失败各打一个补丁，最极端的是直接 curl 公开仓库里的参考答案。hillclimb 的流程是：开跑前随机切分 train 和 test；第一轮之前先确认评测噪声小于你在意的最小改进幅度；每轮只读 train 的失败记录，只提一个从根因修复的 patch。如果 train 涨而 test 不动，判为疑似过拟合并回滚；任何一侧退步也回滚；两侧都涨才保留。结束时报告 test 相对基线的置信区间，增益落在噪声范围内就建议不要合并。
“If the train set scores improve while the test set scores stay flat” ¶34
hillclimb 每轮用 test 决定保留还是回滚，最后又留下 test 上表现最好的版本，test 集实际上成了验证集，存在适应性过拟合。文章没有提到需要一个从头到尾不参与任何决策的第三份留存集。
分数停滞两到三轮时，应该停止修改，先把剩余失败按原因分类（归因分桶）。很多残余失败其实来自模型的训练先验或评测本身的缺陷。
正常的一轮只针对最常见的失败改一处；反思这一步不做任何修改，只把全部失败按根因归类。在 skill 案例里，这一步发现内容其实已经写在 skill 里，问题是模型按训练先验写出了旧的 API 形态（例如固定 token 预算的 extended thinking，最近的 Opus 模型已经拒绝这种写法）。修法是在 skill 顶部加一张「旧写法 → 新写法」对照表，分数从 77% 升到 80%。同一步还揪出了两个评测缺陷：一道题的题面和判分器要求不一致；另一个判分器与官方文档矛盾，用真实 API 测试证明文档是对的。修掉这些后到约 88%。
“This step makes no edit; it only sorts every remaining failure by cause.” ¶57
skill 案例从 66% 到约 88% 的过程中，评测本身被改过：改写了题面，修正了判分器。前后用的不是同一把尺子，所以这段提升混合了 skill 的改进和评测缺陷的修复。
作者没有直接谈到这一点。
98.9% 是在被搜索过的 30 张工单上得到的。真正可以参考的是 14 张留出工单上 90.5% 对 78.6%，但样本只有 14 张，一张工单就会让分数变动好几个百分点，而原文没有给出这组数字的置信区间。
作者没有直接谈到这一点。
关于数据，文章只用一句「先问保留期和敏感数据」带过，没有讨论生产对话记录进入评测集、发给 judge 模型时涉及的合规边界。这对审计数据场景很关键。
每轮只改一处，看 test 是否随 train 一起上升来决定补丁去留，以此拦住过拟合。
好评测有四个可检验的要素：样本贴近生产、模型越强或思考越多分数越高、最强配置下离满分仍有余量、多次运行方差低。每个要素失效时都有可观测的征兆。
这四条本质上是评测的健康检查。如果换更强的模型或调高 effort 分数却不涨，通常说明任务有歧义，或者判分器没校准。如果某道题在所有重复运行里都失败，它多半是无解题或歧义题，不能当作真实的余量。环境残留（上一轮留下的文件、git 历史）可能直接把答案递给 agent；effort 没有被一致地应用，也会制造假方差。判断一道题合格的标准是：两位领域专家会给出相同结论，而且判分器检查的每一项都在题面里写明了。
a common tell is that a task fails every evaluation run
¶7 ↗
专挑当前模型做错的题来出评测，测到的是这个模型自己的失败特征，而不是你的应用真正难做、真正值钱的部分。
模型能力分布是参差不齐的。按「当前模型做不对」来采样，等于只采了它能力曲面上的低谷；下一代模型的低谷位置一变，评测就失效了。文章的替代做法是：一道题纳入前，先说得出它为什么难（由人判断难度）；同时加入来自生产流量、bug 报告、工单的真实失败。但也不能全靠用户流量，因为用户倾向于尝试他们预期能成功的事，这样采出来的分布会偏简单。build-eval 的采样顺序是：生产对话记录（先问清保留期和敏感数据）、bug 报告和工单、手写五到十个用例、最后才从代码库合成。
you are sampling the valleys of one model's capability surface
¶9 ↗
评测里最常见的配置错误出在判分环节，所以判分器必须先验证再使用。选判分器时，取能满足需求的最便宜的方案。
输出空间受限时用程序化校验，比如精确匹配、固定标签集、JSON schema、跑测试。输出开放时才用 LLM-as-judge，且有三点要求：rubric 写成可逐条核查的断言，不用 1 到 5 的打分量表；有基线时让 judge 在随机顺序、不知道哪个是基线的情况下二选一；judge 不能是被测模型。跑基线时还有三项诊断：同一份输出判两次，看结论是否一致；检查超时、API 报错和截断，避免基础设施噪声被当成模型方差（plumbing）；基线已经在 95% 上下时发出警告，建议转去优化成本或延迟。
scoring failures are among the most common ways an evaluation is misconfigured
¶21 ↗
hillclimb 适合用在改起来便宜、分数变化能归因、目标边界清楚的对象上。评测饱和以后，「保持性能、压低成本」仍然是一个可以继续优化的目标。
prompt、skill 这类文本改起来和回滚都便宜；开放式地改 harness 代码，往往要动大量代码。可归因的典型例子是 skill 触发：评测指标是触发率，被修改的正是 skill 的 description，两者直接耦合。最常见的失败是在接近饱和的评测上提开放式的「提升性能」要求，这种情况容易停滞。文中的成本例子显示，在新模型上用低 effort 就能超过旧模型的默认 high 档，降档后成本还能继续下降。
reduce cost while keeping performance at parity
¶30 ↗
防过拟合靠三条结构性约束：切分 train 和 test、不把失败内容直接粘进 prompt、让答案在结构上不可达。hillclimb 把这三条做成了自动的保留或回滚规则。
评测会通过 harness 渗进系统：为评测里的 OCR 题加一个 OCR 工具，为固定路径写死 cd /app，为特定措辞调 prompt，为读到的每个失败各打一个补丁，最极端的是直接 curl 公开仓库里的参考答案。hillclimb 的流程是：开跑前随机切分 train 和 test；第一轮之前先确认评测噪声小于你在意的最小改进幅度；每轮只读 train 的失败记录，只提一个从根因修复的 patch。如果 train 涨而 test 不动，判为疑似过拟合并回滚；任何一侧退步也回滚；两侧都涨才保留。结束时报告 test 相对基线的置信区间，增益落在噪声范围内就建议不要合并。
If the train set scores improve while the test set scores stay flat
¶34 ↗
分数停滞两到三轮时，应该停止修改，先把剩余失败按原因分类（归因分桶）。很多残余失败其实来自模型的训练先验或评测本身的缺陷。
正常的一轮只针对最常见的失败改一处；反思这一步不做任何修改，只把全部失败按根因归类。在 skill 案例里，这一步发现内容其实已经写在 skill 里，问题是模型按训练先验写出了旧的 API 形态（例如固定 token 预算的 extended thinking，最近的 Opus 模型已经拒绝这种写法）。修法是在 skill 顶部加一张「旧写法 → 新写法」对照表，分数从 77% 升到 80%。同一步还揪出了两个评测缺陷：一道题的题面和判分器要求不一致；另一个判分器与官方文档矛盾，用真实 API 测试证明文档是对的。修掉这些后到约 88%。
This step makes no edit; it only sorts every remaining failure by cause.
¶57 ↗
这篇文章是在推广自家 skill 和新模型。成本案例里有一部分节约直接来自 Opus 5.5 的定价：输入输出便宜 20%，缓存读便宜 60%，原文自己也承认这一点。所以「成本降到约五分之一」不能全部算作 hillclimb 方法的功劳。
98.9% 是在被搜索过的 30 张工单上得到的。真正可以参考的是 14 张留出工单上 90.5% 对 78.6%，但样本只有 14 张，一张工单就会让分数变动好几个百分点，而原文没有给出这组数字的置信区间。
skill 案例从 66% 到约 88% 的过程中，评测本身被改过：改写了题面，修正了判分器。前后用的不是同一把尺子，所以这段提升混合了 skill 的改进和评测缺陷的修复。
hillclimb 每轮用 test 决定保留还是回滚，最后又留下 test 上表现最好的版本，test 集实际上成了验证集，存在适应性过拟合。文章没有提到需要一个从头到尾不参与任何决策的第三份留存集。
文章的原则 ¶6 说更强模型应该得分更高，可成本案例里 Sonnet 5 低 effort 和 Opus 5.5 低 effort 分数几乎一样，最终在 search 集上接近饱和。这说明该评测对模型能力可能不敏感，和文章自己的健康检查原则存在张力，但文章没有讨论。
判分器双判一致性、plumbing 检查、噪声地板这三项诊断，不依赖 skill 也能在自己的评测上复现，成本很低。
关于数据，文章只用一句「先问保留期和敏感数据」带过，没有讨论生产对话记录进入评测集、发给 judge 模型时涉及的合规边界。这对审计数据场景很关键。