如何用 Claude Code 分 5 步做出更好的 AI 评测——Shreya Shankar、Hamel Husain

• Hamel 开场就把这一年的变化收成一句：基本功一条没变——"一切还是从看数据开始，还是要做错误分析，还是要有一套结构化的方法去看数据"；真正变了的是「让 agent 帮你更有章法地看数据」。他的原话是：你在前台看数据、agent 在后台跑着给你打配合，这样在「看数据」这第一步上，杠杆率能高很多。→ 详细
• 全片第一句话就是本期的题眼，也是最该记住的一句："你得先把自己的品味和判断标准外化出来，然后再动手写 evals。" 顺序不能反——先有你自己的判断，才谈得上把它固化成打分规则；反过来先让模型编一堆规则，等于把方向盘交给了一个不知道你要去哪的人。→ 详细
• 两位嘉宾的身份决定了这期的分量：Shreya Shankar（UC Berkeley 做 AI evals 研究）和 Hamel Husain（独立顾问，写过 LLM evals 的 FAQ），两人合开的 AI evals 课程主持人 Peter Yang 称是全网最火的一门，已教了 4500 多名学员。这期不是讲理论，是现场拿 Peter 自己的 skill 开刀。→ 详细

• Shreya 补的第一件事就是这个转变：LLM judge 指的是让一个 LLM 去看一条 trace（轨迹，即 agent 一次完整运行的逐步回放），只针对某一个非常具体的失败模式做判断——比如「这段输出是不是太长」「有没有按规定结构来」。她说现在的 judge 在评这类定义得非常清楚的标准时准确率高多了，所以「我们现在对 LLM judge 的态度，比以前正面得多」。→ 详细
• 注意限定词：变好的是窄而清晰的单条标准，不是「给这篇文章打个 1-10 分」——判断力的进步发生在「问题被切得足够小」的前提下，这条限定贯穿全片。这也呼应 Peter 上次做客学到的老规矩：别乱编一堆分数，直接用是/否、通过/不通过。→ 详细

• Peter 把自家的活儿摆上台面当解剖对象：他做了个播客后期制作的 skill，负责从访谈里挑出十条 takeaway（要点），再写一版 newsletter 初稿。eval 分两类，一类是硬指标（每条 takeaway 是不是落在 240–330 个字符之间），一类是软判断（不看那期节目能不能读懂、有没有给出朴素又有用的建议）。关键坦白是：这些 eval 是他让 Claude 帮着写的。→ 详细
• Shreya 追问的角度值得抄下来当自查题：「你当时是怎么想的？是那种『我就让 Claude 帮我编几条 eval』，还是说你看了一些输出、发现某些地方不对劲，然后才围绕这些问题去建 eval？」——这一问直接把「你的 eval 有没有根」摆到台面上。→ 详细
• Peter 演示了跑完 skill 之后的真实状态：拿 Anthropic 的 Thariq 那期做例子，skill 生成 takeaway 后他还得一顿反馈「这些地方全给我改掉」，改完再来一轮。他的结论也是本期最扎心的一句："不管我往里加多少东西、加多少条 eval，它就是没法一次到位"——因为每期访谈都不一样，总得来回磨几轮。而且他强调自己从不是「一贴了事」，人工过一遍是固定动作。→ 详细

• Shreya 给出全片最重要的分类法。自上而下（top-down）＝假设你处在真空里、手上只有一份任务描述，凭对这个任务本质的理解能想出哪些标准：字数长度、动词要用得对、必须是人真能落地的建议。她的判断是「Claude 在帮你做这半套上，表现非常好」。→ 详细
• 自下而上（bottom-up）＝当你把大量样本输出翻一遍之后，你的直觉、你的体感反馈是什么——就是你跟 Claude 来回磨稿时冒出来的那些判断。然后是那句该刻在墙上的话："Claude 特别特别不擅长想自下而上的 eval，那部分完全靠你自己"，这也是为什么它只能随时间一点点积累出来。→ 详细
• 两者的差别被 Shreya 压缩成两句："自下而上就是数据驱动的"；"自上而下跟数据无关，就是一个懂行的领域专家理解了这个任务之后的基本判断：他会去看哪些点。"→ 详细
• 她看 Peter 那份 skill 时脑子里跑的正是这个二分法：「自上而下那半套你有没有？看起来你确实有。自下而上那半套呢？我的问号就在这儿」——她想知道哪些条目是从数据里长出来的，以及有没有把握说它穷尽了做过好几期播客攒下来的所有反馈。这就是诊断任何一套 eval 的第一刀。→ 详细
• Shreya 也肯定了 Peter 说对的一点：eval 本来就是迭代出来的、永远是个半成品；你看的样本越多，就会发现越多失败模式、给出越多反馈，而这些反馈正是要外化进 eval 的东西。→ 详细

• Peter 的自建循环：拿原始转录跑 skill → 来回改到满意 → 然后对它说「回顾一下我们整段对话，看看该怎么更新 skill 和 eval，让我们下次不用再走一遍这么长的流程」。Shreya 的评价是「这个做法太对了，特别棒」。→ 详细
• 但 Peter 立刻指出这套闭环的副作用——过拟合：某期 takeaway 不够 MECE（咨询圈术语，「相互独立、完全穷尽」，即条目之间不重叠、合起来不漏），系统就加一条 MECE 的 eval；可下一期访谈里 MECE 可能根本不重要，规则就这么被上一期的偶然绑架了。→ 详细

• 第一条：在 skill 文件里就把 eval 明确分成自上而下和自下而上两组。 这不是文档洁癖——分开写你才看得见「自下而上那栏是不是空的」，也才知道哪些规则是从真实数据里长出来、值得长期留着的。→ 详细
• 第二条：标准一多就用 sub agent（子 agent，即主 agent 派出去干专项活的分身）分头去评，每个 sub agent 负责一条标准或一组标准。这样你才有把握说「每一条标准都真的被看过」，而不是被一次性糊弄过去。→ 详细
• 第三条：等 sub agent 跑完，让 AI 生成一张表格——用 Hamel 的话大概会叫「透视表」——每行一条标准，后面跟一个是/否、通过/不通过的标记。价值在于把判断权交回给你：你扫一眼就能按自己心里那套重要性排序拍板，比如 MECE 这条在别的场景下可能就没那么要紧。→ 详细
• Peter 顺势问「是不是该给标准加权重」，Shreya 的回答很务实："你都不用做到加权那一步，简单到只要在 skill 里让 AI 帮你生成一张表格，就够了。" 先把结果摊开给人看，比先建一套精巧的加权体系有用得多。→ 详细

• Hamel 把 fan out（扇出，把一件大活拆成多份并行的小活分派出去）的理由讲得很具体：如果你把一整份标准清单一次性丢给模型，"注意力就被稀释掉了，模型会开始漏掉一些、变懒"；而让它一次只盯一条，「它就真的会死盯着那一条」，你还能把要求提得更细。→ 详细
• 他举的例子朴素但有效：跟它说「去评第 2 条」，它就会真的死盯着第 2 条评。这条经验适用于所有「让 AI 按一份长清单做检查」的场景——清单越长，单次检查的可信度越低。→ 详细
• Hamel 特意点出这类活儿的普适性：「现在到处都有人在写 skill，谁都可以给自己的 skill 配一套 eval」——这不是大厂专属工程，是个人也能立刻上手的手艺。→ 详细

• Hamel 和 Shreya 常开的一个玩笑："写作是 LLM 的最终 boss——要让它写得像你、写到你满意，难度极高。" 难在标准多且主观，而且有时候你会想根据选题主动放宽某些标准。→ 详细
• 更根本的难点在创作本身的性质："东西没摆到眼前，你是不知道自己喜不喜欢的"，它得让你「感觉对了」——「嗯，这个点接到这儿正好」。既然判断只有在看到成品时才发生，eval 的作用就不是替你拍板，而是把该看的东西整齐地摆到你面前。所以 Hamel 强调工作流本身值得单独设计：你未必想要那种「跟它聊聊天、它给你一堆反馈或者直接动手帮你改」的形式。→ 详细
• Peter 用亲身教训佐证：他曾让 AI 直接改自己的博客文章，结果"我根本不知道它改了什么，而且它开始往里加各种 AI 味的废话"。所以现在他改成「让它跑 skill、把输出摆给我看，我自己手动跟我的稿子对比」——把 AI 从「代笔」降级成「摆证据的人」。→ 详细

• Peter 现场把自建的 anti-AI-slop（去 AI 味）skill 反用：「写几段话解释什么是 AI evals，不要有 AI 味的废话，但实际上要尽可能多地往里塞 AI 废话」。Hamel 一边看一边笑：「它现在满篇都是 AI 味，张口就是『事情是这样的』『这是一次范式转移』。」→ 详细
• Hamel 有一套攒了很久的同类 skill："不管是 Fable 还是什么 GPT 5.6，这些模型就是不停地在产出 AI 味的东西，我真是受够了"，所以他加了一大堆规则去砍，"我写的每一样东西都会过一遍这道工序"，说过段时间大概会开源。副作用他也照实说了："有时候它会用力过猛，把我文字里的个人风格也一并抹掉了"——去味和保个性是一对张力，不是单向优化。→ 详细
• Peter 的同类 skill 是开源的，叫 plain writing skill；两人一致的观感是「好多人手里都有这类 skill」，当场约定「应该把这两个 skill 合并了」。→ 详细

• Peter 自己意识到一件一直没做的事：他手上存着过去十期、二十期访谈的原始转录 + 最终人工成稿。完全可以拿十份原始转录去跑 skill，把机器输出跟自己编辑过的最终版逐一对比，然后问它「把这十组一起看，你能找出什么规律？」→ 详细
• Shreya 当场叫好："这就是典型的、直接从数据里长出来的自下而上。" 关键在于他手上有真实的标注（ground truth，即公认正确的参考答案）——也就是最终那版真正的 takeaway——所以可以让 AI agent 去反思「成稿和 skill 自动跑出来的那版，到底差在哪」。→ 详细
• 这一招的妙处是：你不需要额外标注数据，你日常返工的痕迹本身就是标注。改过的每一处，都是一条还没被写下来的 eval。→ 详细

• 演示的起手式简单到不像话：起一个 Claude 会话（她用 dangerously skip permissions 跳过权限确认，模型设成 Opus 4.8），然后输入一句指令——「用我的 error discovery skill 给我搭一个界面，帮我查看 AI 的输出并给出反馈」。剩下的它自己跑。→ 详细
• 她特意强调了这一步的价值主张："它做出来的界面，会比我在 Google 表格之类的东西里看数据好用太多，那种真的非常费眼睛。" 这句话是整个演示的商业逻辑——过去「自己看数据」之所以做不下去，很大程度上不是因为没决心，而是因为载体太难受。→ 详细
• 数据是她为课程造的合成写作样本（模拟「人们想让 AI 帮忙写文章」的场景），但她明说「也可以是端到端的 trace——你真正想做错误分析的任何东西都行」。她选这个例子的理由是：很多人是在公司内部做 AI 产品，要处理的不只是自己那点个人工作流。→ 详细
• 诚实到值得记一笔的细节：她坚持从零开跑，"好让你们知道我没有事先准备好来糊弄你们"；实际跑了 15 分钟（她原本估五分钟）。也就是说，这套「让 agent 现搭一个标注界面」的做法，成本是十几分钟机器时间，不是几天工程排期。→ 详细
• 顺带一个成本感知的细节：她说不用 Fable「因为看数据会一下子把额度烧光」——看数据这件事本身是吃 token 的大户，选模型时要为它单独留预算。→ 详细

• 第一步：读数据集，判断「语义类型」。 不是「字符串类型」这种没意义的类型，而是：这是一篇文章？是代码？还是一堆 trace？先认清对象，后面的呈现方式才有依据。→ 详细
• 第二步：决定怎么把数据渲染成人类读得轻松的样子，术语叫 visual encoding（视觉编码）。她在 skill 里写的原则是「这里用格式塔原理（Gestalt principles，人眼把零散元素自动归组成整体的一套感知规律）」——说白了就是：小心地运用颜色、间距、透明度，把数据里的差异呈现出来，目的是调动人的视觉皮层去干它最擅长的活。→ 详细
• 第三步：真把界面搭出来，她管它叫 review app（审阅应用）——Python 后端 + HTML 加一点 JavaScript 的前端，她本人的态度是「其实用什么都无所谓」。技术栈不重要，有一个专门给人看数据的地方才重要。→ 详细
• 第四步：决定该看哪些样本。 「你可能有几百条甚至几千条 trace 要做错误分析，那到底该看哪一条？」——这件事交给 agent：它做聚类，挑出一批多样性足够的初始样本给你标注，避免你把时间全花在互相重复的样本上。→ 详细
• 第五步：跑一个交互循环。 Claude Code（或 Codex）盯着你在界面上的动作，把这些动作汇总成开放式反馈，实时读取，然后要么给你推荐新的待标注样本，要么给你的 rubric（评分量表，一组说清「什么算好、什么算差」的判据）提出新的评判标准。→ 详细
• 这套 skill 的最终产出被 Shreya 说得很直白：它给出一套 rubric，定义什么是好输出、什么是差输出，"这本质上就是你希望在自己那套评分量表里拿到的东西"；Peter 接得也准——「它能帮你挖出更多自下而上冒出来的东西」，正好补上前半段诊断出的那个缺口。→ 详细
• 另外一个侧面信号：她打开 skill 时看到「哇，还真有不少人在用」——这套 error discovery skill 已经是公开可用、有人在跑的东西，不是只在演示里存在。→ 详细

• 界面有三个标签页：① 逐篇/逐条看的面板（一次只看一个样本，颗粒度随你）；② map 视图，展示 agent 把数据聚成了哪些语义上有意义的类别；③ progress 视图，根据你的审阅和标注，汇总出有哪些反复出现的失败模式——这一块由 agent 自动填。→ 详细
• 设计哲学是全片最该抄走的一条分工原则，她说得非常清楚：让人去读、去给开放式的反馈；而 agent 的职责"不是去发明新的开放式反馈，而是把这些反馈归类、提炼成可执行的 rubric 标准，这样人就不用干那么多苦活了"。 换句话说，AI 在这套流程里不产生判断，只搬运和整理判断——这跟前半段「Claude 特别不擅长自下而上的 eval」是同一枚硬币的两面：不是不用 AI，是把 AI 用在它真正强的那一侧。→ 详细

• 演示的具体一幕：她在读一篇 AI 写的「睡眠卫生」文章，读到不顺眼的地方就顺手写下「我不喜欢我的文章里出现负向对比」——她讨厌的是 AI 那种「这不是 X，而是 Y」的句式。她把这种边读边写的方式叫 in situ（就地）反馈，"这个界面让我可以随时把脑子里冒出来的想法直接外化出来"。→ 详细
• 她一给反馈，Claude agent 就调用 monitor 工具去读、去反应，界面上能看到它复述「这是你在睡眠那篇文章上给我的第一条笔记」，然后在后台继续加工。她的关键要求是："让它在后台跑着就行——我只想保持在读稿子、给反馈的心流里。"→ 详细
• 她先声明「自上而下那些标准我假设 Claude 能搞定」，所以人在界面上花的每一秒，都只花在机器搞不定的那一半上。这是整套设计省人力的真正来源。→ 详细
• 第二条反馈同样琐碎而真实：看到「humble me（让我谦卑了一把）」这种说法，「我也觉得特别烦人」。品味就是由这种一条条说不出大道理的小反感构成的，而它们只有在读的当下才会浮现——这正是「就地」二字的分量。→ 详细

• Shreya：Fable 能干「更有分量的软件工程活儿」，但 Codex/GPT 新出的 Soul 啃硬任务也行、输出更好读——她吐槽 Claude 系爱说「让我先给服务器做个 smoke test」这类她日常不会用的黑话，常看得一脸懵。→ 详细
• Hamel 三条理由：① 移动端「完全是另一个级别」，手机上能看到所有设备的全部会话，功能不缩水（排队发消息、中途纠偏、切模型、看 artifacts）；② 很少有人聊的一点——可以让 Codex 去指挥 Codex：开线程、让线程互相对话、@ 一个正在跑的线程叫它「打前站」先做调研，「又不用真把自己整成一个代码工厂」；③ 经济账：额度限制少得多，前沿模型完全包在订阅里。→ 详细
• Peter 几个月前还是「彻头彻尾的 Claude 粉」，现在只留 Fable 做规划和找 bug；他最看重 Codex 的浏览器操作能力：「我用的东西里有一半压根没有 API，它就直接替我点来点去。」他常用的还有个逆向工程 skill——让 agent 监听任意无 API 网站的网络请求写成脚本，「我现在能把任何网站都变成 API」；同类工具还有 printing press CLI。→ 详细
• 对当下这轮补贴，桌上共识是句冷静的玩笑：我们正处在 AI 模型的「Uber / Lyft 时代」（还记得十年前 Uber 两美元吗），「补贴总有一天会停的」。另有一段对 Anthropic 对外沟通的吐槽：「我感觉 Dario 是不是讨厌 Twitter，把他们整个沟通策略全搞砸了。」→ 详细

• 这是全片最精妙的一个小动作。读到一处她本能反感、但说不出所以然的地方，她这样写反馈："这个读着就让人烦，但我也说不太清为什么。我现在还没法给你一个精准的标签，不过你可以结合我给过的其他反馈想一想，推理一下原因。"→ 详细
• 为什么这招重要：人的判断往往先于人的语言——你先感到不对，很久之后才说得清哪不对。传统标注流程要求你当场给出一个类别名，这一步就把大量真实信号卡死在门外。她的做法是把「命名」这件苦活留给 AI，人只负责报告那声「不舒服」。→ 详细

• Hamel 拆解了后台两条同时跑的线：① 多样化样本是从前面的聚类里抽出来的——多样性不是随机来的，是聚类保证的；② Claude 内置的 monitor 工具在后台盯着她给的每一条反馈。→ 详细
• 机制说得很具体：她在前台人工审阅，Claude 在后台反思每条反馈的性质（"比如它会判断这条是关于文风的还是关于事实的"）；攒到大约 10 条审阅之后，它就开始琢磨一套分类体系（taxonomy），再把你的判断批量应用出去——比如她标了两处「负向对比」，它就会去把所有出现负向对比的地方找出来自动打标。→ 详细
• 界面上有个可见的进度指标：suggestions（建议数）一开始是 0，等自动标注跑完就会涨上去；progress 视图里也已经能看到「不喜欢负向对比」被识别成一类问题。人给样例，机器做全量覆盖——这就是人的时间被放大的地方。→ 详细
• 关于「10 条」这个门槛，Shreya 的解释很有意思，是个刻意的行为设计："我挺喜欢『十条批注』这个设定的，它像根吊在前面的胡萝卜，能逼着你真的去读点东西。" Hamel 补刀："让你稍微出点汗，这对你有好处。" 门槛不是技术必需，是防止你偷懒跳过看数据这一步的机制。→ 详细
• 演示中她只给到八条就手动催它「现在就开始推建议，不等了」，然后 agent 开始用已经找出来的那些标准给每一篇文档做一遍标注。→ 详细

• Peter 问了个好问题：让它边看边反思，跟你把反馈全给完它最后一次性反思，各有什么好处？Shreya 说最后再反思也 work，但她更喜欢实时——理由一是效率："不然的话，最后让它把你那一堆反馈反思一遍会花很久，你只能干等着"，而实时是「把人思考的时间和 AI 思考的时间交错起来」。→ 详细
• 理由二更深，关乎品味本身的形成方式："做这些标注通常是很迭代的——随着你看的例子变多，你的品味会被慢慢打磨，你会对自己到底想要什么冒出新的想法。" 而且很多时候看看 AI 是怎么想的也有帮助，能帮你找到一个参照。Peter 一句话总结：「就像有个思考搭子。」→ 详细
• 一个容易被演示误导的细节她主动澄清了：实际用的时候她并不会像屏幕上这样一直盯着 AI 那一侧，摆出来只是为了让观众看见 AI 在干活。真实工作状态是——人在读稿，AI 在视野之外。→ 详细

• Peter 确认了一遍「你还是在做人工审阅，没有让 AI 把所有东西都审一遍」——答案是「是的」。这是整期节目立场的核心，不是姿态，是方法论前提。→ 详细
• Shreya 说得毫不掩饰："你得明白这活儿真的挺难的。而且 AI 也没法替你读心。我写的这些批注，有一部分 AI 也许自己能想出来，但我觉得不可能全部都想到。" 她当时也只写了八条。→ 详细
• Hamel 直接承认这活儿的体感："给反馈这件事真的特别磨人。" 他能提供的加速手段也很朴素——语音输入。Shreya 的回应堵死了所有捷径："但说到底，你还是得把所有东西都通读一遍"，退一步至少「读一部分样本」。→ 详细
• 她还给了一句对新手很重要的宽慰兼提醒："大多数人都得先看过很多样本，才给得出反馈"——她自己因为写过很多东西，所以能张口就来；"也正因为这样，多看样本非常重要，尤其是一开始的时候。" 品味不是天赋，是看量看出来的。→ 详细

• 负向对比：「这不是 X，而是 Y」——她第一条反馈就冲着它去的，并且在后面又抓到第二处。→ 详细
• 三段式排比枚举（triadic parallel enumeration）："我真的特别烦这种『三点式清单』，感觉 AI 老这么写"，桌上另一人接了句「简直像树懒的寻宝游戏……到处都是」。→ 详细
• 报数式过渡句：动不动来「另外两三件需要知道的事」「有几点要记住」，她说这个 AI 也特别爱干。→ 详细
• 「humble me（让我谦卑了一把）」这类煽情套话、段落不用主题句开头（"段落要用主题句开头，别一上来就讲细枝末节"）、以及要求写完整句子。→ 详细
• 值得注意的是这些条目的性质：没有一条是「通用最佳实践」，全是她个人的偏好。这正是「自下而上」的样子——它长出来的不是真理，是你的品味。→ 详细

• Hamel 主动替观众问了那个问题并当场否掉："你可能会想，有没有哪个 SaaS 就是干这个的？但你看，你根本不需要那玩意儿。" 他强调的是灵活度：Shreya 把这套流程直接接进 Claude 之后，"她想怎么弄就怎么弄"——工具形态可以完全长成她这一个人的工作习惯的样子。→ 详细
• Peter 顺势放了句更狠的："这就是为什么我觉得 SaaS 真的有麻烦了——这种东西我自己 vibe code 一下就能做出来，那我干嘛还要花钱买 SaaS？"（vibe coding：不细究代码、靠跟 AI 描述需求把东西搓出来。）→ 详细
• 但 Hamel 立刻按住了这股兴奋，给出本期最清醒的一句限定："硬币的另一面是，你得对这个工作流有非常清楚的认识。很多没看过这期视频的人，根本不知道该从哪儿下手。" ——能自己搓工具的前提，是你先懂这个流程该长什么样；AI 降低的是实现成本，不是认知门槛。→ 详细

• 自动标注跑完的数字很有说服力：从她的 8 条人工批注，agent 生成了 361 条建议；其中光「少于四个词的短促句」这一条规则就命中了 249 处。人投入的是几分钟阅读，机器还回来的是全量覆盖。→ 详细
• 最终排名第一的失败模式是 staccato fragments（一顿一顿的碎句），其次是滥用冒号。Hamel 当场承认自己猜错了："我本来以为会是那种『不是 X，而是 Y』的句式，但看来还真是 staccato 碎句。我信了。" ——你以为最严重的问题，往往不是数据里最严重的问题，这正是「必须看数据」的实证价值。→ 详细
• 他顺势把整套哲学收成一句该背下来的话："品味由人来把握，AI 负责放大、给人超能力，让这份品味能规模化地用出去。"→ 详细
• 呈现方式也被 Hamel 单独夸了一句：文稿是「原位」呈现的，就是用户平时读到它的样子，而不是日志文件或 trace 查看器里那种形态，你就在文稿上就地标注。让人在最自然的阅读语境里做判断，判断的质量才高。→ 详细

• Peter 问「全部接受之后呢」，Hamel 给出这条链路的终点：把你找出来的所有失败模式变成一份 rubric——"这就成了你的 evals"。然后你可以：做成一个 skill 来用；给每一条标准配一个 LLM-as-Judge；做成一块 dashboard；甚至让它实时监控 agent 的 trace 或输出。→ 详细
• 这句是全片对「难在哪」最直接的定位："做 eval 最难的部分其实就是 error analysis（错误分析），也就是把这份 rubric 弄出来。" 后面的 judge、dashboard 都是工程活；难的是知道该量什么。→ 详细
• 顺带的副产品被 Hamel 特意点名："因为做过这一轮标注，你顺带还有了一份数据集。" 这份数据集不是白来的档案，它有硬用途——见下一条。→ 详细

• Shreya 点出闭环的最后一环："等你的 evals 建好之后，你就可以拿这份数据集去检验这些 evals。" 你的人工标注就是标准答案，用来看 judge 判得准不准。→ 详细
• Hamel 把这层意思说透："eval 不只是一份 rubric——你还得能去衡量这份 rubric，判断它到底好不好。正因为这些数据都被标注过了，你才有东西可以拿来做基准比对。" 换句话说，一套没被验证过的评分标准，本身就是个未经检验的假设。→ 详细

• 具体操作简单到一句话：在同一个会话里写「根据发现的失败模式，写一个评估「AI 辅助写作」的 skill」，skill 就出来了，里面自带一份 rubric。以后每拿到一份写作样本跑一遍，rubric 会输出类似「这份样本里有一大堆 staccato 碎句」的结果。→ 详细
• 但 Shreya 特意加了一句强调，这是本段最该记住的纪律："错误发现这一步你应该多花几个小时，别只看五条就完事，真的把 18 条全过一遍，感觉自己确实挖饱和了再说。"（饱和：继续看下去也冒不出新的失败模式了。）→ 详细
• Hamel 用 Peter 熟悉的东西做类比来定位这个产出："你想想你那个播客评估 skill，那本身就是一份包含很多条标准的 rubric。staccato 就是它总结出来的五条标准之一。" 也就是说，Peter 一直在做的事没错，只是那份 rubric 的来源该换成数据。→ 详细

• 这是 Hamel 抛出的一条产品设计原则，对做产品的人价值最大："你怎么 eval 一个东西，往往应该反过来决定你一开始该怎么给用户设计界面。"→ 详细
• 他给的推演很具体：标注流程里 AI 会主动给出各种标注建议；那么如果你是真的在写东西，你会希望有个 IDE 也这样给你提示，并告诉你为什么——「这里是 staccato 碎句」「这里是负向对比」。产品形态就这么从评测流程里长出来了。→ 详细
• 背后的价值主张是「接受/拒绝」优于「整段覆盖」："这样你就不用让 AI 直接把内容整段覆盖掉，也不用一遍遍回头重读。你想要的是能一条条接受或拒绝。" 这跟前面 Peter 抱怨「它改了什么我都不知道」是同一个病的解药。→ 详细
• 所以走一遍 eval 流程"其实会逼着你做一些像样的设计思考"——因为每种场景的界面都不一样：写作是这样，客服机器人的界面会完全不同。Shreya 补充说，连错误发现界面本身也不固定，她的 skill 会让 agent 先琢磨数据的性质、再为它设计视觉呈现，"所以做出来不会跟这个长得一模一样"。→ 详细

• 第一个作用是覆盖：这是 agent 拿已知的失败模式去把全部记录扫一遍，而且扫的都是她本人没有标注过的记录。→ 详细
• 第二个作用更妙，是反向校验：她说实际操作中总是先快速扫一眼再一键全部接受，"我拿它来确认 AI 是不是真的理解了我说的比如『负面对比』是什么意思"——现场看完的结论是「完全没错，它确实理解了。干得好，接受」。你不只在检查数据，你在检查你和 AI 之间的词汇表有没有对齐。→ 详细
• Hamel 补了一条自搓工具才有的自由度：万一界面哪里不对劲、或者她想给的反馈这里给不了（比如发现有个主题 AI 漏掉了），她可以直接在左边跟 Claude 说一声就改掉——"你不会被这个 UI 框死。" Peter 顺着说：自己做的产品比 SaaS 灵活太多，「你会有一堆用例，是通用 SaaS 根本想不到的」。→ 详细

• Peter 总结说「AI 主动帮我找主题，等于把那一整步给省了」，Hamel 当场纠正——这是全片立场最硬的一段："我倒不会说是『省掉』这一步。你还是得看数据。未来不存在那样的世界——就算有了 AGI，只要你在做产品，你就必须看你自己的数据。不然根本行不通。"→ 详细
• 理由不是苦行主义，而是逻辑必然："你总得有办法把自己的品味注入到产品的开发里。" 数据是品味唯一的入口。他强调这套演示的定位是：同一件必须由你做的事，怎么在 AI 的帮助下做得又快又高效。→ 详细

• Peter 现场问「我想把它用到播客 takeaway 上该怎么做」，Shreya 给了一份可以照抄的配方：建一个文件夹，把你现在的 skill 原样放进去，再放播客转写稿的例子、以及你认为好的那些 takeaway（也就是你的标准答案）。→ 详细
• 然后调用 skill，说一句："帮我对我的播客 takeaway skill 做一次错误分析——先用这个 skill 生成一批 takeaway，再给我搭一个界面来审阅这些 takeaway，尤其是拿它们跟那些输出对照着看。" 一句话就把「跑一遍 + 搭界面 + 对照人工成稿」三件事包了。→ 详细
• Peter 想手动改界面做成「AI 输出在一边、ground truth 在另一边」，Shreya 说不用：你把 skill 用在自己的数据上时界面会不一样，agent 会去读你的 takeaway、自己设计一套适配的视觉呈现再渲染出来——这正是五步里的第二步。→ 详细
• 时间成本与最终目的她也说清了：搭界面大概 15 分钟，但你过起来会很快；而"说到底，这件事的意义就是『有底气』——我最后要的是对自己这个 skill 有信心，是我清楚地知道 LLM 到底表现出了哪些行为。这就是 error analysis 的全部意义。"→ 详细
• Peter 替观众确认了一件实际的事：据他所知这套 error discovery skill 是免费的，Shreya 当场确认「对，没错」。→ 详细

• Peter 注意到 Shreya 的界面上大方留着「这部分是 Claude 帮我想的」，还自嘲："我一般都会把那段删掉，好假装整个东西都是我自己做的。"→ 详细
• Shreya 的回应划出了一条很清楚的功劳边界："Claude 特别擅长给 Claude 自己写 skill。我本来也不知道该怎么跟 AI 讲话，所以这挺好的。不过 readme 是我自己写的嘛——这套流程是我想出来的，所以我对它还是挺有底气的。" ——措辞交给 AI，流程归你，这才是这类合作里真正值钱的分工。→ 详细

• 起因是过去几个月冒出一批厂商，号称能帮你把 evals 全包了：Braintrust 的 Loop、Arize 的 Alyx、LangSmith 的同类功能——用法都一样，把 trace 传上去，然后跟一个 AI 聊天说「帮我把 evals 做了」。他把这个抉择画成一张梗图：作为开发者或产品经理，你是直接按下那个「自动 eval」按钮（听着可太省事了），还是老老实实自己去看 trace？「按按钮的诱惑真的很大。」→ 详细
• 实验设计很直接：拿一份人工标注过的数据集当标准答案，看这些工具能抓回多少人类抓到的错误。第一个结论是正面的——"这些工具确实能把人能找出来的错误召回相当一部分。"→ 详细
• 但第二个结论是本段的重点：它们无一例外漏掉了同一类东西——那些不明显、需要产品判断力和品味才能看出来的问题。 一眼可见的错（tool call 失败、用户明显在表达不满）AI 抓得非常好，因为判断这些根本不需要产品经验。→ 详细
• 两个具体例子极有说服力。测试对象是一个房产/租房销售 agent：① 销售异议处理被一致漏掉——客户问了，它回一句「不好意思我们没有这个房源，祝你愉快」，而不是「这边还有别的选择可以给你」；② 这个 agent 是多渠道的（网页、短信、电话），而 eval 不知道这件事，所以没抓到「不该在短信里放 markdown，那东西在短信里根本不生效」。→ 详细
• Hamel 由此点出一个几乎无法绕开的先后关系："你当然可以把这些上下文喂给 LLM，但这不是你一开始就能想到要写进评判标准里的东西——你得先亲眼看见那次失败才行。" 而「让人一上来就自顶向下地想清楚所有好与坏的情况，几乎是不可能的」。→ 详细

• 对照实验里还测了 coding agent（Claude Code、Codex 等），结果「效果基本一样」。Hamel 的解释很关键："这层 harness（承载 agent 运行的那层脚手架/框架）其实挺薄的，无非就是别人写好的一段 prompt" ——你在这些工具里跟 AI 聊天，调用的其实就是同样那几个模型，背后一段 prompt 在做同一件事。→ 详细
• 既然如此，"你真正该做的，是更主动地去牵引这个 agent"——不管是自己的 coding agent 还是这些 eval 工具，让它变好的办法都是告诉它什么叫好、什么叫坏。唯一的问题是："除非你做一遍 Shreya 刚才演示的那套，否则你根本不知道什么算好、什么算坏。" 这一句把整期节目的两半缝在了一起。→ 详细
• 那这些工具还该不该用？该。Hamel 说它们唯一的真优势是「跟你整套技术栈是打通的」：「如果你的数据和 trace 本来就存在 LangSmith，那你完全应该用它，这根本不用犹豫。」→ 详细
• 但他给了一句竞争视角的提醒："你的竞争对手也都会用这套东西。这只是一条基线。" 你能把 Claude 指向产品说「把所有错误找出来」，对手也能。所以最后真正拉开差距的，是"在这之上你还能往产品里注入多少『品味』，去定义什么才算好"。→ 详细

• Shreya 说这篇博客她没参与写，看到结果反而是个惊喜——「发现这些现成工具居然这么好用的时候特别开心」。所以她的立场是该用就用，用它们把数据里的错误捞出来。→ 详细
• 但她补的这条数据是很多人会忽略的另一半：这些工具的 precision（精确率，即报出来的问题里真正是问题的比例）最好也就 80%–90%，也就是说自动 eval 报出的错误里有 10%–20% 根本不是错误，纯属干扰项（red herring）；「你要是无脑照单全收，反而会把产品带偏」。→ 详细
• 所以她的用法是三件事一起做：用工具找错 + 你自己看数据找它们没找到的错 + 回头核对工具报出来的错、确认你同意它的判断。一句话总结："recall（召回率，即真问题里被抓到的比例）和 precision 这两头都得看。"→ 详细
• Hamel 给的行动建议同样是「都要」："自动化工具照用，同时你自己也要看数据。这是一场竞争嘛，你得比你的竞争对手做得更好。"→ 详细

• Peter 把结论说成一句大白话："说到底，真的动手去『看』东西才是那个优势所在。真的去读、去看。" 桌上的回应是一个字：「永远都是。」→ 详细
• 他解释了这条优势为什么真实存在——因为它反人性："面对这些 AI 生成的东西，你很容易就撒手不管、随它去了。" 而他从另一位嘉宾那里学到的正是「你真的得去读 AI 到底产出了什么」。别人越是不读，你读就越值钱。→ 详细
• 这条结论被顺手推广到写代码："有时候连代码也一样，这就是优势所在……你得有选择地去读代码，这绝对是一种优势。" 注意那个限定词——有选择地读，不是全读。→ 详细

本期没有闪电问答环节，收尾是 Peter 当场做的两条自我小结：

• 收获一：真的去用 Shreya 那个 skill。 他的原话是「喂给它一堆例子，然后让它帮你归纳出错误的共性主题」——重点在「一堆例子」和「共性主题」，不是让它替你下判断。→ 详细
• 收获二：各种编码 harness、eval 工具都用起来，但同时也要自己去读那些东西。 两件事是「都做」，不是二选一。→ 详细
• 收尾的玩笑话也值得记：Peter 说「从今往后我要采访就得把 Shreya 和 Hamel 一起请来，绝不再单独请 Hamel 一个人了，因为这样我学到的东西多太多了」；Hamel 回敬一句「我现在可是全职做教育的人了」。最后 Peter 说自己这就下播去用那个 skill，「看看效果怎么样」。→ 详细

节目里没有留个人联系方式，提到的资源有这些：

• error discovery skill（Shreya 的错误发现 skill，本期演示主角）——在 GitHub 上搜 error discovery skill 可找到，Peter 也放了链接在视频简介里；据 Peter 确认是免费的。→ 详细
• 《Do Automated Evals Work?》——Hamel 的博客文章，即本期第三十一节讲的那份实测（Braintrust Loop / Arize Alyx / LangSmith 对照人工标注数据集），链接也在视频简介里。→ 详细
• plain writing skill——Peter 自己开源的「去 AI 味」写作 skill；Hamel 有一套同类但没开源的，说过段时间大概会开源，两人当场约定「应该把这两个 skill 合并了」。→ 详细
• printing press CLI——桌上提到的一个把无 API 网站逆向成可调用接口的工具，功能类似 Hamel 那个自制的「逆向工程 skill」。→ 详细
• 两人合开的 AI evals 课程（链接在视频简介）——Peter 说已教过 4500 多名学员。Shreya 介绍课程共 五个模块，为 agentic AI 时代彻底重做过，除错误分析理念之外还讲：① 怎么产品化并放大到公司内部（多人做同一产品时如何在评判标准上对齐、怎么接进 CI/CD——持续集成/持续交付，即代码每次改动自动跑检查再上线的流水线）；② 长期监控 drift（漂移，指上线数月后模型/数据分布悄悄变化导致效果走样）；③ 安全与对抗性评测（比如怎么确保没泄露租户数据）；④ 改进模块——成本与准确率一起优化：有了 eval 就能把它丢进一个自动化的「研究循环」里跑，他们在咨询项目和学员身上把成本砍到原来的百分之一（对比使用 Opus，换 Fable 省得更多）。→ 详细