标准回答
Eval-Driven Development：先有评测，再谈迭代
LLM 应用是非确定性的，「感觉变好了」不可靠。EDD 把评测当成开发的方向盘，类似测试驱动开发 TDD。
1. 先定义评测集与指标
- 收集有代表性的输入 + 期望输出/验收标准，覆盖典型用例、边界与历史 bug。
- 选指标：任务成功率、忠实度/幻觉率、格式合规率、相关性等。
2. 三种打分方式组合
- 确定性规则：能精确判定的用断言（JSON 是否合法、是否含必需字段、数值是否在范围）。
- LLM-as-judge：开放生成用强模型按 rubric 打分，需校准并人工抽检。
- 人工标注：关键/争议样本由人复核，作为金标准。
3. 迭代闭环
- 改提示词、换模型、调 RAG 后跑同一评测集对比分数，用数据决定是否采纳。
4. 接入 CI 防回归
- 把评测做成可在 CI 运行的任务，PR 触发，分数低于阈值则阻断合并。
5. 数据飞轮
- 把线上失败 case 持续回灌评测集，评测集越用越强。详见 LLM 评测：基准测试与对齐评估。
常见误区
⚠️ 常见踩坑
凭感觉调提示词、无固定评测集，改 A 修好却让 B 变差却不自知；或只用 LLM-as-judge 不校准、不抽检，把不可靠的分数当真理。
追问
追问 1：EDD 和传统 TDD 有什么异同？
相同点：都先写「验收标准」再开发、用自动化跑、防回归。不同点：LLM 输出非确定，难以精确断言，评测需结合规则、LLM-as-judge 与人工，指标是分布/通过率而非单次 pass/fail，且评测集需持续扩充。
追问 2：评测集应该怎么构建和维护？
初版从真实用例、产品需求、边界条件采样，规模够覆盖关键场景即可；上线后把用户反馈和失败样例持续回灌，定期人工复核标注质量，并对评测集本身做版本管理，使其随业务演进。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。