Evals 评估体系（AI 产品的测试学）
回答：怎么知道我的 AI 产品好不好？投多少精力做评估？
骨干方法论（Hamel Husain & Shreya Shankar 学派，最系统）：
†ai-evals-error-analysis-lifecycle（一切评估的起点：error analysis 而非指标仪表盘）→ error-analysis-open-axial-coding → llm-as-judge-binary-alignment + llm-judge-validation-tpr-tnr（让人敢信 LLM 裁判）→ eval-flywheel-ci-production。配套心智：criteria-drift（好坏标准只能边看数据边长出来）、benevolent-dictator（标注权集中于一人）、evals-effort-benchmarks（投入量级参照）。
入门与模板：†eval-workflow-four-phases、eval-four-part-formula、eval-approaches-comparison、eval-common-mistakes-and-quickstart（Aman Khan 系，PM 友好）。进阶场景：architecture-specific-eval-strategies（多轮/RAG/agentic 专项）、agentic-eval-per-step-decomposition。
簇内活跃分歧（写 skill 时保留两派）：严格派 vs vibes 派。†vibes-before-evals（Howie Liu：探索期上 evals 会锁死空间）、coding-agents-evals-special-case（Claude Code 团队自称只靠 vibes——但有隐含前提）、trusted-taster-panel-plus-few-evals（Cat Wu 折中方案）、eval-investment-roi-heuristic（Chip Huyen：产品越收敛越值得投 eval）、writing-evals-core-pm-skill（Kevin Weil：这是 PM 新核心技能）、evals-semantic-diffusion（先把词定义清楚再吵）。
LLM错误分析生命周期AI Evals Error Analysis Lifecycle
你的 LLM 应用出各种问题但不知从哪下手：改 prompt 靠猜、靠 vibe check，应用一变大就失控。这套流程是构建一切 evals 的起点——先系统性地发现、归类、量化产品的真实错误，再决定测什么。
Eval 工作流四阶段Eval Workflow Four Phases
写 evals 不是一次性动作，而是从产品开发到上线后持续改进的迭代工作流。不清楚从零开始该怎么一步步把 eval 建起来、跑起来、并持续监控。
直觉先于 EvalsVibes Before Evals
开发全新 AI 能力/形态时，evals 应该在哪个阶段引入——避免"一上来就建 eval"把探索空间过早锁死。
错误分析开放主轴编码Error Analysis Open Axial Coding
eval 仪表盘看着有用但没人理、不带来产品改进——因为指标与真实用户问题脱节。可评估的表面积是无限的，不知道该测什么。
LLM 裁判二元对齐框架LLM As Judge Binary Alignment
某个失败模式太主观、无法用代码断言检查（如"该不该把对话转接给人工"），想用 LLM 自动判断，但直接写个裁判 prompt 就当真会产出不可信的 evals——团队一旦发现 eval 不可信，就再也不信你的 evals。
LLM 裁判置信度验证法LLM Judge Validation Tpr Tnr
主观质量（语气、相关性、推理质量）无法用代码断言检查；随手写个"聪明 prompt"当裁判，分数没人敢信。需要一套让团队和老板信任 LLM judge 读数的验证流程。
Eval 飞轮与持续集成Eval Flywheel Ci Production
就算你已经建好了一套可信的评估器(code-based + LLM judge),它们只是工具,不是流程——怎么把这些评估器嵌入日常研发,变成一个能持续发现问题、持续把系统变得更健壮的飞轮,而不是一次性的项目?
评估标准漂移Criteria Drift
你以为可以在动手前把"什么是好输出"的评估标准/rubric 一次性定义清楚，然后照着写 evals 或 PRD——LLM 产品上这条路走不通。
仁慈独裁者Benevolent Dictator
团队做 error analysis / 数据标注时陷入委员会决策：人人参与打标、争论标准、追求全员共识，流程贵到根本做不下去，最后没人看数据。
评估投入精力基准线Evals Effort Benchmarks
给"做 evals 要投入多少"一组经验基准数字，用于排期、预期管理，以及反驳"evals 太贵做不起"。
Eval 四段式公式Eval Four Part Formula
不知道怎么写一条 LLM-as-judge 的 eval prompt，写出来的评判标准太模糊，导致判断结果不可靠、和人工标注对不上。
Eval 方法对比矩阵Eval Approaches Comparison
给 AI 产品的某个环节选评估方法时，不知道该用人工看、写代码检查、还是让另一个 LLM 来判分，以及各自的取舍是什么。
Evals 常见误区与速成Eval Common Mistakes And Quickstart
团队第一次上手 evals 时最容易踩的坑是什么，以及零基础的人具体第一步该做什么（而不是被"评估体系"这个大词吓退）。
AI 复杂架构评估策略Architecture Specific Eval Strategies
通用的"binary pass/fail + LLM judge"评估方法论,遇到多轮对话、RAG、agentic workflow 这几种更复杂的系统架构时不够用——这些系统的失败点更隐蔽,需要针对架构特点定制诊断策略,否则很难定位问题到底出在哪一步。
Agentic 评估分步拆解Agentic Eval Per Step Decomposition
对于像 deep research 这类多步骤 agentic 产品（搜索 → 聚合 → 再搜索 → 生成摘要），没有一个单一端到端指标能衡量好坏，该怎么设计 eval 体系。
编码 Agent 评估特例Coding Agents Evals Special Case
"Claude Code 团队说他们不做 evals、只靠 vibes，而它是最好的编码代理"——你的团队要不要效仿这种做法？
品鉴团与少样本评估法Trusted Taster Panel Plus Few Evals
新模型发布节奏极快(Anthropic 内部几乎每隔几个月就有一次能力跃升),团队需要快速判断"这个新模型到底哪里变好了、哪里还有问题",但海量使用数据本身很难第一时间提炼出洞察。这套打法给出一个低成本、可复用的快速评估组合拳。
评估投资 ROI 启发式Eval Investment ROI Heuristic
回应"AI 产品到底需不需要做 eval，还是靠 vibe check 就够了"这个业内常见争论；帮团队判断该把有限的工程精力投在打磨已有功能的 eval 上，还是投在做新功能上。
写 Evals 的 PM 技能Writing Evals Core PM Skill
做 AI 产品时无法回答三个问题：模型在我的场景里到底行不行？产品该按什么形态设计？什么时候能确认"我们手里有产品了"？Kevin 的论断：写 evals 正在成为产品经理（乃至所有产品建造者）的核心技能。
Evals 语义扩散现象Evals Semantic Diffusion
"evals"一词已被用滥（语义扩散），团队常因此争论错方向："要不要做 evals" vs "看生产信号就够了"。这张卡拆清楚概念，并给出评估与生产监控如何配合。