eval-design 是做什么的？
你在设计的是测量方法，而不是产品。这项技能的输出，是一个能够在会议室里让人为之辩护的决策，而不仅仅是一个数字。
大多数情况下，决策内容是 下一步该修复什么。一个只能对系统进行排名的评估只是一份报告；而一个能指出最耗成本的两件事，并在重新运行时证明修复生效的评估，才是一个开发循环。请为后者构建——失败分类和每个准则的分解比总体得分更重要，因为这些才是人们可以采取行动的部分。
核心立场
四条规则。它们是观点，也是这项技能的核心。
1. 拒绝模糊感受。 “感觉更好了”不是结果。如果一个改动无法表现为在固定数据集上对已定义准则的数值变化，那它就没有被评估过。你可以直接发布——只是别声称它经过了测试。
2. 每个准则都必须具有可争议性。 如果一个准则，两位谨慎的评审者无法站在对立面，那它就什么也没衡量。“输出是否有帮助？”不是准则。“回复是否以天为单位说明了退款窗口？”才是。评估表中的每一条准则都承载着它被写出来要解决的具体分歧——参见 references/rubric-design.md。
3. 默认不采用LLM作为评判者。 评判者是一个自带错误率的系统，未经验证的评判者会将其错误混入你的初始分数中。先由人类进行标注，再将评判者针对这些标注进行校准，并且校准结果需与评判者生成的所有结果一同公布。参见 references/judges.md。
4. 报告基线，否则评估就是营销。 正则表达式、关键词规则、当前生产系统、或者什么都不做。大约三分之一已发布的AI功能在至少一个准则上输给成本为零的方案，你需要在招聘经理或VP发现之前就找出这一点。
由此引出两条结构性规则：
- 门槛是底线，而非权重。 安全、法律或信任准则不能被用来折抵平均性能。低于底线的系统无论价格如何都不是候选。加权平均值恰恰掩盖了这一点。
- 不提供置信区间则禁止排名。 当 n=150 时，3分的差异是噪声。在噪声范围内对系统进行排名，是评估工作误导读者的最常见方式。
工作流程
按此顺序工作。不要跳过步骤直接评分——每一次评估的失败都可以追溯到之前被跳过的内容。
- 找到决策点。 结果会改变什么？“我们发布哪个模型”、“这个是否可以无人监督”、“提示词的改动是否导致了性能下降”。如果什么都不会改变，就停下来并如实说明——这是整个过程中最有价值的一步，有时诚实的答案是“你根本不需要评估”。
- 先编写失败分类。 在编写准则之前。收集30-50个真实输出，阅读每一个，并将错误聚类。从观察到的失败中推导出的准则，每次都胜过凭空想象的准则。
→
references/failure-taxonomy.md - 将分类转化为准则。 每个准则都有权重、分歧描述，以及可选的底线门槛。 →
references/rubric-design.md - 构建黄金测试集。 分层、对抗性、有版本控制，并且小到人类能够实际标注。 →
references/golden-sets.md - 由人类进行标注，测量一致性。 如果两个标注者无法达成一致，是评估表有问题，而不是标注者。修复评估表并重新标注。
→
references/statistics.md - 只有现在才考虑评判者，且必须经过校准。 →
references/judges.md - 运行所有系统，包括非AI基线，写入
results.json，然后渲染。 →references/scorecard-spec.md - 亲自撰写结论。 记分卡显示数字；由人类陈述正在做的权衡以及什么会逆转决策。
渲染
python3 skills/eval-design/scripts/render_scorecard.py results.json --md
会生成一个自包含的 scorecard.html（无外部请求，支持浅色和深色主题）和一份用于在仓库中阅读的 SUMMARY.md。结构：references/scorecard-spec.md。
python3 skills/eval-design/scripts/validate_rubric.py results.json
会检查那些让记分卡不诚实的错误：权重之和不等于1、准则未标明分歧、门槛缺乏理由、缺少基线、或在置信区间内声称排名。
何时不应使用此技能
- 一次性的提示词调整，且没有关联决策。 直接看输出就好。
- 没有用户，也没有示例。 先获取30个真实输入。基于想象出的输入构建的评估，衡量的是你的想象力。
- 任务有程序可以检查的正确结果 —— 比如算术运算、合法的JSON、可编译的构建。编写检查代码，而不是评估表。
- 有人想要一个数字来证明已经做出的决定。 直接说出来，而不是去构建评估。
参考文件
按需加载，不要一开始就读完所有。
| 文件 | 何时阅读 |
|---|---|
references/rubric-design.md | 编写或修正准则时 |
references/failure-taxonomy.md | 从真实输出开始工作时 |
references/golden-sets.md | 选择和分层测试用例时 |
references/judges.md | 当有人提议使用LLM作为评判者时 |
references/statistics.md | 涉及样本量、置信区间、标注一致性和漂移分析时 |
references/scorecard-spec.md | 编写 results.json 时 |
references/antipatterns.md | 评审他人的评估时 |