该技能的核心主张是把评估视为基础设施而非事后补充：在编写提示词或任务逻辑之前先定义成功标准，让评估本身成为规格说明。
框架为 Data → Task → Scores 三部分。Data 是黄金数据集，即测试用例输入；Task 是被评估的操作，如 LLM 调用、Agent 工作流或 MCP 管道；Scores 是把输出映射为归一化 0–1 值的分类评分规则。
步骤一：定义 PRD（Data 与 Scores）。构建黄金数据集时，收集或生成 10–20 条覆盖预期使用范围的代表性输入；无手工样例时可用高推理模型自动生成多样化测试用例；有意纳入预期会失败的输入以映射当前模型局限；以 JSON 或 JSONL 存储以保证可复现。定义评分规则时采用分类评分（选项 A/B/C）而非原始数字，因原始数字在不同评估者与模型间会漂移；每个分数须附文字理由；所有分数归一化到 0–1 以便跨模型比较；可运行 scripts/normalize_scores.py 转换分类结果为归一化值。示例分类评分器：A (1.0) 完全正确、结构良好、覆盖所有方面；B (0.5) 部分正确或缺少关键要素；C (0.0) 错误、跑题或有害。
步骤二：配置 Task（执行载体）。若使用 MCP，应做工具剪枝，只保留必要工具，因为选项过多时模型会选错工具；系统提示词依据步骤一的成功标准定义初始指令，例如“不要追问澄清问题”“以 JSON 响应”；隔离性方面，每次评估运行必须独立，测试用例之间不共享状态。
步骤三：执行飞轮循环。离线阶段在本地对黄金数据集运行实验，识别缺口并优化提示词与工具；在线阶段将评分器部署到生产环境监控真实用户日志；闭环阶段当在线分数（如 0.3）低于离线分数（如 0.75）时，找出生产失败案例并加入黄金数据集。停止迭代的条件：离线分数连续 3 次以上运行趋于平稳；在线与离线差距小于 0.1；剩余失败属于产品范围之外的边缘情况。
故障排查：全部为 0 分通常因评分标准过严，应人工做感觉检查，若不同意评分器则更新规则；分数恒为 1.0 通常是标准过松或测试用例过易，应加入对抗性输入并收紧规则；在线远低于离线说明黄金数据集未代表真实使用，应把生产失败案例加入数据集；多次运行分数剧烈波动源于任务或评分器非确定性，应固定 temperature=0 并增加更具体的评分标准。
关键原则：评估是持久资产。模型会变、提示词会演进、Agent 框架会被替换，但构建良好的评估能穿越这些变化。切换模型时应重跑评估，而不是重做产品思考。