用途：把评估当作基础设施而非事后补充，在编写提示词或任务逻辑之前先定义成功标准，让评估本身成为规格说明。适用于 LLM 调用、智能体工作流、MCP 管线的评估架构、执行与迭代。
框架：Data → Task → Scores，每个评估恰好包含三部分。Data 是输入的金标准数据集（测试用例）；Task 是被评估的操作；Scores 是把输出映射为 0–1 归一化值的分类评分标准。
第一步，定义 PRD（Data 与 Scores）。构建金标准数据集：收集或生成 10–20 个覆盖预期使用范围的代表性输入；无手工样例时可用高推理模型自动生成多样化测试用例；有意加入预期失败的输入以映射当前模型局限；以 JSON 或 JSONL 存储以保证可复现，格式见 references/golden-dataset-template.md。定义评分标准：使用分类评分（选项 A/B/C）而非原始数字，原始数值会随评估者与模型漂移；每个分数必须附书面理由；所有分数归一化到 0–1 以便跨模型比较，模板见 references/scoring-rubrics.md；运行 scripts/normalize_scores.py 把分类结果转为归一化值。示例分类评分：A（1.0）完全正确、结构良好、覆盖所有方面；B（0.5）部分正确或缺少关键要素；C（0.0）错误、跑题或有害。
第二步，配置任务（测试装置）。任务即被评估的操作。工具裁剪：使用 MCP 时只保留必要工具，选项过多会导致模型选错工具。系统提示：依据第一步的成功标准定义初始指令，例如“不要追问澄清问题”“以 JSON 回复”。隔离：每次评估运行必须独立，测试用例之间不共享状态。
第三步，执行飞轮循环。离线：在本地对金标准数据集运行，找出差距并改进提示词与工具。在线：把评分器部署到生产环境，监控真实用户日志。闭环：当在线分数（如 0.3）低于离线分数（如 0.75）时，找出生产失败案例并加入金标准数据集。
何时停止迭代：离线分数连续 3 次以上运行趋于平稳；在线与离线差距小于 0.1；剩余失败属于产品范围之外的边缘情况。
故障排查：所有分数为 0，多为评分标准过严，先人工感受检查，若不同意评分器则更新标准；分数总是 1.0，多为标准过松或测试用例过易，加入对抗性输入并收紧标准；在线远低于离线，多为金标准数据集不代表真实使用，把生产失败案例加入数据集；多次运行分数波动大，多为任务或评分器非确定性，固定 temperature=0 并增加更具体的评分标准。
关键原则：评估是持久资产。模型会变、提示词会演进、智能体框架会被替换，但构建良好的评估能经受这一切。切换模型时重新运行评估，而不是重做产品思考。
限制：资料未提供具体安装命令、依赖环境、支持的模型或平台、收费与价格信息，也未给出完整代码示例，相关细节暂未提供。