需要系统化衡量、监控并迭代 AI 产品质量时，用人类…

适用于 AI 产品团队要从主观感觉转向系统化评估、定位失败模式并持续提升质量时。

适用场景

解决思路

1. 对真实 trace 做错误分析，找出系统具体在哪些地方失效。
2. 根据具体技术用例，选择人类、代码和 LLM 裁判的合适组合。
3. 整理高质量样例作为参考数据集（gold set），作为应用的 ground truth。
4. 将评估集成到 CI/CD pipeline，持续改进质量。
5. 自动化价值链：识别业务独有的核心交付物，建立系统化测试，衡量 AI 多准确地复现这些具体任务。
6. 优先主观卓越：用深度、主观的人类卓越标准定义数据质量，如情感共鸣和独特性，而非表面的二元检查。
7. 消除 vibe checks：创建系统化指标持续跟踪应用质量，使团队能像传统软件一样有信心地迭代 prompt 或模型。
8. 结构化 judge 逻辑：用结构化 prompt 编写自动评估，明确定义 judge 的角色、数据、成功标准和具体标签。
9. 使用 LLM-as-a-Judge Playbook：按三步流程构建、验证和测量 LLM judge，为主观 AI 质量提供可信的二元 pass/fail 指标。
10. 使用 Three Eval Approaches（Human、Code-based、LLM-based）：按用例选择正确评估方法，并权衡每种方法的优缺点。
11. 使用 The Eval Formula（四部分结构）：用四部分公式编写有效的基于 LLM 的 eval prompts，PM 可用它构建 judge-LLM prompts。
12. 使用 Open Coding 和 Axial Coding 做 AI 错误分析：把定性研究方法适配到 AI 产品评估，从用户交互数据中发现并归类失败模式。
13. 使用 RAG Evaluation Framework（Retriever + Generator）：分别评估 retriever 和 generator 组件，并为每部分设定具体指标。
14. 使用 AI Eval Improvement Flywheel：把 CI safety nets 和 production discovery engines 组成闭环流程，持续改进 AI 产品。
15. 使用 Reference Dataset Structure：构建初始参考数据集（20-100 个样例），打破冷启动并为 AI 系统评估提供 baseline。
16. 使用 Transition Failure Matrix for Agentic Workflows：诊断 agent 多步工作流中具体哪一步崩掉，实现数据驱动调试。
17. 查看 references/artifacts.md 获取完整模板与框架列表及细节。
18. 问用户：当前生产环境中用户遇到的 top 3 到 5 个 failure modes 是什么？
19. 问用户：是否有一个领域专家或 benevolent dictator 定义该功能的质量标准？
20. 问用户：当前评估流程中手动与自动各占多少百分比？
21. 问用户：系统的非确定性主要发生在 retrieval 还是 generation 阶段？
22. 问用户：是否已建立至少 20 到 50 个人工标注样例的 golden dataset？
23. 问用户：切换模型或修改 system prompt 时，当前如何测量性能差异？
24. 标记并纠正依赖 vibe checks：手动和轶事式测试会导致质量不一致和隐藏回归，长期损害用户信任。
25. 标记并纠正痴迷 prompt engineering：只关注 prompt 而忽视底层评估系统，会阻止团队扩展或系统化 hill-climbing。
26. 标记并纠正用通用指标做产品报告：现成分数适合过滤，但通常无法捕捉业务逻辑独有的价值或失败。
27. 标记并纠正忽略组件隔离：RAG 系统中不分别评估 retriever 和 generator，就无法知道栈中哪部分失败。
28. 标记并纠正忽视非确定性：不考虑 LLM 的随机性，会对生产中可能不复现的结果产生虚假信心。
29. 查看 references/guest-insights.md 获取来自 11 位嘉宾的 33 条有来源洞见。

适用边界 · 注意事项

• 当产品仍在早期探索、没有稳定用例或真实用户 trace 时，不适合先投入完整评估基础设施。
• 当没有领域专家或人工标注资源定义质量与构建 gold set 时，主观评估可能不可靠。
• 当只需一次性原型验证、不准备持续迭代 prompt/模型或接入 CI/CD 时，完整 eval flywheel 可能过重。