关于 ai-evals
面向 AI 产品团队的评估策略技能，用于衡量产品质量与可靠性。它帮助分析失效模式、选择人工、代码或 LLM 评估方法、构建参考数据集，并将评估纳入 CI/CD。
主要功能
- 01基于追踪记录分析失效模式
- 02选择人工、代码或 LLM 评估
- 03创建参考数据集
- 04制定结构化 LLM 评审标准
- 05将评估接入 CI/CD
适用场景
- 01定位线上 AI 工作流的故障环节
- 02比较模型或提示词变更
- 03分别评估检索器与生成器
- 04通过可重复测试跟踪质量
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/ai-evals确认已加载。
附带文件references/artifacts.mdreferences/guest-insights.md
详细介绍
AI 评估策略
超越凭感觉评估，以系统化、实证的方式衡量 AI 产品的质量与可靠性。
结合 Lenny's Podcast 和 Newsletter 中 11 位嘉宾及文章的见解，为用户提供 AI 评估策略方面的帮助。
如何提供帮助
- 识别故障模式 - 帮助用户分析真实追踪记录中的错误，找出系统具体在哪些地方出问题。
- 选择评估方法 - 根据具体技术用例，推荐合适的人类评审、代码评估和大模型评审组合。
- 构建黄金数据集 - 协助整理高质量示例参考数据集，作为应用的真实标准。
- 落地实施 - 指导用户将这些评估整合到 CI/CD 流水线中，以持续提升质量。
核心原则
自动化价值链
Brendan Foody：“我认为，尤其对于企业来说，核心思路是：如何构建测试或系统化的方法，衡量 AI 对核心价值链的自动化效果？比如，一家建筑设计公司会为终端客户制作建筑设计图，那么它该如何有效衡量这项工作的自动化效果？每家公司都有自己的价值链；如果是多产品公司，可能还会有几条价值链。”
明确业务中独有的核心交付成果，并开发系统化测试，衡量 AI 复现这些特定任务的准确度。
优先追求主观卓越
Edwin Chen：“我们追求的是诺贝尔奖级别的诗歌。这首诗是否独特？是否充满细腻的意象？是否让你感到惊喜、触动你的内心？是否让你领悟到月光的本质？”
真正的数据质量取决于深层次、主观的人类卓越表现，例如情感共鸣和独特性，而非表面化的二元检查。
摒弃凭感觉评估
Hamel Husain 和 Shreya Shankar：“评估能帮你创建用于衡量应用表现的指标，也能让你有信心地改进应用。它能提供一种反馈信号，供你据此不断迭代。”
创建系统化指标，持续追踪应用质量，让团队能够像改进传统软件那样，有把握地迭代提示词或模型。
结构化评审逻辑
摘自《Beyond vibe checks: A PM’s complete guide to evals》：“清晰说明你希望评审大模型衡量什么，不只是流程中的一个步骤，更是打造平庸 AI 与持续带给用户惊喜的 AI 之间的关键区别。要掌握这项写作技能，需要练习并用心打磨。”
编写有效的自动化评估时，应使用结构化提示词，定义评审者的角色、数据、成功标准和具体标签。
模板与框架
- LLM-as-a-Judge 实战指南（构建能改进 AI 产品的评估系统）- 一个系统化的三步流程，用于构建、验证和衡量 LLM 评审器，为主观 AI 质量提供可信的二元通过/失败指标
- 三种评估方法（人工、基于代码、基于 LLM）（超越凭感觉检查：PM 的完整评估指南）- 一个决策框架，根据你的使用场景选择合适的评估方法，并列出每种方法的优缺点。
- 评估公式（四部分结构）（超越凭感觉检查：PM 的完整评估指南）- 一个由四部分组成的公式，用于编写有效的基于 LLM 的评估提示词，任何 PM 都可以用它来构建 LLM 评审提示词。
- AI 错误分析的开放式编码与主轴编码（构建能改进 AI 产品的评估系统）- 一种针对 AI 产品评估改编的定性研究方法，用于从用户交互数据中发现并分类故障模式。
- RAG 评估框架（检索器 + 生成器）（构建能改进 AI 产品的评估系统）- 一种分为两部分的 RAG 系统评估方法，分别评估检索器和生成器组件，并为每个组件设置特定指标。
- AI 评估改进飞轮（构建能改进 AI 产品的评估系统）- 一个闭环流程，将 CI 安全网与生产环境发现引擎结合起来，持续改进 AI 产品。
- 参考数据集结构（为什么你的 AI 产品需要不同的开发生命周期）- 一个用于构建初始参考数据集（20-100 个示例）的模板，帮助打破冷启动并为 AI 系统评估提供基准。
- Agent 工作流的转移故障矩阵（构建能改进 AI 产品的评估系统）- 一种诊断工具，用于准确定位 Agent 多步骤工作流中的故障环节，从而支持数据驱动的调试。
完整列表及详情请参阅 references/artifacts.md。
帮助用户思考的问题
- “目前用户在生产环境中遇到的 3 到 5 个主要故障模式是什么？”
- “你是否有一位领域专家或全权负责人来定义此功能的质量标准？”
- “目前你的评估流程中，人工与自动化各占多少比例？”
- “你的系统非确定性主要出现在检索阶段还是生成阶段？”
- “你是否已经建立了一个至少包含 20 到 50 个人工标注示例的黄金数据集？”
- “切换模型或更改系统提示词时，你目前如何衡量性能变化？”
需要指出的常见错误
- 依赖凭感觉检查 - 人工且基于个例的测试会导致质量不一致，并产生难以察觉的回归问题，长此以往会损害用户信任。
- 过度关注提示词工程 - 只关注提示词而忽视底层评估系统，会妨碍团队扩展或系统性地逐步改进。
- 使用通用指标进行产品报告 - 现成的评分适合用于筛选，但往往无法反映业务逻辑特有的价值或故障。
- 忽视组件隔离 - 在 RAG 系统中未单独评估检索器和生成器，就无法判断技术栈中的哪个部分出现了问题。
- 忽视非确定性 - 未考虑 LLM 的随机性，会让人对结果产生错误的信心，而这些结果在生产环境中可能无法复现。
深入了解
11 位受访者的全部 33 条资料洞见，请参阅 references/guest-insights.md
相关技能
- AI 产品战略
- AI 原生 UX