Eval 测的是操作系统，不是模型排行榜。

产品评测问：这个代理能不能修这个 bug。pstack 的 Eval 问：我把这条原则写进 mode 之后，它是真的更早验证了，还是只会在回复里引用原则名字。

所以成功标准必须是可观察行为。具体：「加一个会跳过写入的 --dry-run」。含糊：「代码是对的」不能打分。

1. 候选看见的任何路径、文件、提示里，不能出现 eval、test、judge、experiment、rubric、score、compare、benchmark、candidate、arena。
2. 提示必须像真人任务。写「做一个小的 todo cli」，不要写「展示你如何遵循原则链」。
3. 不要诱导它列出用过的技能或原则。元提示会灌水引用行为。
4. 目录和 slug 用项目名，不用 candidate-1。
5. 不要告诉它还有别的候选。
6. Judge 可以知道自己在评，但只看见消毒标签，不看见模型名。
7. 两个变体用同一个 judge、同一次、同一把尺子。两次分开的 judge 不能比。

1. 01

   框定

   写下被测变体，以及什么行为算成功。给 judge 写 3 到 6 条具体标准。扣住，不给候选。

2. 02

   消毒环境

   每个候选自己的工作目录，变体已经就位。种上有机任务会有的上下文：骨架、它本来就会读的技能。

3. 03

   写一条有机提示

   用户会打的那种。不要泄漏你在测什么。

4. 04

   并行盲候选

   按 arena 的扇出方式，不同模型，同一提示，各写各的目录。

5. 05

   一个盲 judge

   不同模型家族。看见产出和 rubric，看不见模型名。

6. 06

   从 transcript 验链

   看它真正打开了哪些文件。引用原则不是读了叶子技能，读了也不是应用了。看代码形状，不看自我汇报。

7. 07

   你自己通读

   和裁决对照。分歧说明模型有偏，或尺子含糊。然后综合，决定升不升级这个变体。

先选一个你反复看到的失败。例如：它修症状不修根因。或它一上来就问人，不跑实验。

写两个变体。对照是你现在的 mode。处理是多了一条原则或改了 playbook 一步。

设计三到五个真人会真实发出的任务。每个任务有可检查的完成条件。

盲跑。一个 judge。你通读。只在裁决和你的阅读都指向同一方向时，才把变体升上去。

技能改动单独开 PR。不要把手册修改缠进功能分支。缠在一起就无法评，也无法审。