先定义完成，再写第一行代码

Eval-first 不是先写测试，而是先回答「这套评估支撑什么产品决策」，再选指标与 Grader。

Eval-first 不是「先写测试」。它是先回答一个问题：这套评估支撑什么产品决策。决策不定，指标和 Grader 就无从选择，你会在一个没定义的目标上做优化——跑得越快，偏得越远。

先定决策，再定指标

GitHub 用 LLM 给 secret scanning 降误报时，真正的问题不是「模型能不能正确分类一个字符串」，而是「系统能不能在保住 recall 安全线的前提下削减噪声告警」。这是两件不同的事：前者可以用一个分类准确率打发，后者要求你先声明安全的下限在哪里。结果是误报削减 95%，recall 守住了护栏——注意两个数字的从属关系：recall 不是与精确度并列的另一个指标，它是破线即否决的约束。github-evaluate-llms

常见的失败顺序是反过来的：先攒一批样本、写一批 prompt、跑出一个分数，然后问「这个分数够高吗」。没有决策，这个问题没有答案。Anthropic 描述的正是这条断崖：早期靠手动测试、dogfooding 和直觉能走很远，一旦上了生产规模就崩——用户报「改完变差了」，团队只能猜，分不清真回归和噪声，debug 变成被动的「等投诉 → 手动复现 → 修 → 祈祷没引入新回归」。anthropic-evals

三层指标，不可互换

• 主要产出：直接驱动决策的那一两个指标，例如精确度的提升幅度。改进要体现在这里。
• 安全约束：只许在预定义阈值内劣化，破线即否决。recall 属于这一层。
• 运维护栏：延迟、成本、可靠性，决定这个改动能不能部署。

不可互换的意思是：一个让主要产出大涨但破了安全约束的实验，结论是「不推进」，而不是「权衡一下」。护栏之所以是护栏，就在于它不接受权衡。github-evaluate-llms

能力 Eval 与回归 Eval 分工不同

能力 Eval 回答「能做好什么」，起步通过率低是正常的，它给团队一座山爬；回归 Eval 回答「还能做以前能做的吗」，通过率应该接近 100%，任何下跌都是回归信号。两者生命周期相连：能力 Eval 的通过率爬到高位就「毕业」进回归套件，那个能力从此由回归套件守着，团队去爬下一座山。

混淆两者的代价是双向的：用回归的眼光看能力 Eval，早期的低分被当成项目失控；用能力的眼光看回归套件，95% 通过率被当成「还不错」。anthropic-evals

同一个成功率，两种口径

写完指标还不够，要写明这个数字是「至少中一次」还是「每次都不许错」。前者是 Pass@k：同一任务跑 k 次，至少一次通过即算通过（输出为连续得分时取最好一次，叫 Best@k）；后者是 Pass^k，读作 Pass consecutive k：连续跑 k 次，每一次都必须通过，且不能触发安全、合规、幻觉这类一票否决项。ai-agent-book

单次成功率 p=0.6、取 k=5 时，Pass@5 = 1 − 0.4⁵ ≈ 99.0%，看起来几乎总能至少成一次；Pass^5 = 0.6⁵ ≈ 7.8%，连续五次不出错仍然很难。同一个模型、同一个任务，两个数字差一个多量级：前一个量的是探索时的能力上限，也是「技术奇观」式 demo 的依据；后一个才接近支付、退款、权限变更、生产部署对可靠性的要求。

所以评估报告必须写清 k 的口径：是同一任务的 k 次独立采样，还是生产流水线上连续 k 个任务。对会产生副作用的操作，不能简单地「重试直到成功」，应当在沙盒或可回滚环境中采样，并把每一次失败都计入可靠性指标。日常场景看 Pass@1，关键操作看 Pass^k，探索性任务才看 Pass@k 或 Best@k——报表里那格「通过率」，得先说清它站在哪一档。

三类 Grader 各有适用范围

分工原则：硬指标一律交给确定性 Grader——数据库里有没有那条记录、JSON 是否合法、是否执行了禁止动作；LLM Judge 只评语义质量，不碰精确计数、数值计算和 Schema 合规。也要定期抽样「高置信」的 judge 输出查系统性错误，judge prompt 本身要版本化。github-evaluate-llms

确定性 Grader 怎么写，SWE-bench Verified 是个范本：它把「修复完成」拆成两组独立命题——FAIL_TO_PASS 要求测试修复前失败、修复后通过，证明问题确已解决；PASS_TO_PASS 要求前后均通过，证明没有引入新缺陷。只查前者，Agent 删改妨碍通过的断言就能蒙混；只查后者等于没查。两组同时成立，「已修复」和「未破坏」才分别是可证的结论。它还额外确认测试自身的稳定性，把时好时坏的不稳定测试排除在用例之外。ai-agent-book

一次只改一个主变量

prompt 修订和模型升级分开测再合测，并记录 prompt、模型、数据集版本和系统配置以保证可复现。用生产数据当评估集时先审标签来源：标签记录的常常是 workflow 结果而不是 ground truth——一个被标为 dismissed 的告警，可能是凭证轮换、风险接受或误分类，被归并成了同一类，直接当答案会得出荒谬的结论。

判定词的措辞也该当成工程项处理。阿里在自进化 SKILL.md 时实测：同一份文件只把「漏洞」换成「风险」，准确率从 89.3% 掉到 62.1%。一词之差 27 个百分点，因为「风险」的语义边界比「漏洞」宽得多。核心判定词用窄词，并为任务维护陷阱词表。

吴恩达把「推动纪律严明的评估 / 错误分析闭环」列为 AI 工程师最重要的特质——不是某项具体技术，而是反复把精力集中到最可能有效的方向，让进展系统化而非随机化。它还包括「评估你的评估」：确定性判定、LLM-as-judge、人工参与各用在哪一层，会随项目甚至项目阶段变化。andrew-ng-ai-skills