How to Build Better AI Evals with Claude Code in 5 Steps | Shreya & Hamel

自动评测能找错，却找不到你的标准

Shreya 与 Hamel 是线上 AI eval 课程的讲师，课程已经教过超过 4,500 名学生。他们这次没有把 eval 讲成一套“写几个提示词、按下自动化按钮”的技巧，而是展示了一套开源的 error discovery skill：让 AI 帮你读数据、聚类、搭建审阅界面，再把人的修改习惯归纳成评测标准。Hamel 还拿 Braintrust Loop、Arize Alex、LangSmith 等自动 eval 工具做过人工标注数据集上的实测。这期真正讨论的是：当 AI 也会找错时，人还剩下什么工作。

这期回答了 7 个问题：

1. 为什么自动化 eval 能抓到错误，却未必能让产品胜过竞争对手？
2. 什么是 top-down 与 bottom-up eval，为什么后者不能交给 Claude 凭空生成？
3. 已有十几份人工修改后的成品，怎样反推出真正有用的评测标准？
4. 评测规则越来越多时，为什么单个模型反而更容易漏检？
5. 怎样让 AI 在后台归纳你的反馈，而不打断你阅读样本的节奏？
6. 为什么写作是 LLM 最难评测的任务之一，甚至无法一次调到“像你”？
7. 为什么一套好的 eval，最终应该改变产品给用户的交互界面？

被问到市面上“上传 traces、让 AI 自动做 eval”的工具到底是否有效时，Hamel 的回答不是泼冷水，而是先划清它们擅长的范围。他用已经由人工标注的数据集，测试了 Braintrust 的 Loop、Arize 的 Alex、LangSmith 等产品，也拿 Claude、Codex 一类编码 agent 作了对照。结论是：它们都能找回不少人工已经发现的错误，尤其是工具调用失败、用户直接表达不满、流程明显中断这类故障。

但在房地产或租房销售 agent 的案例里，自动工具会漏掉更关键的失误：用户说目标房源不可用，agent 回一句“没有了”，对话就结束。它没有继续提供替代房源，也没有处理用户的购买异议。机器看见的是“回答了问题”；业务真正需要的是“把可能流失的用户留在决策流程里”。Hamel 把竞争的分水岭说得很直接："how much taste can you infuse into your product beyond that"（真正重要的是：在此之外，你能往产品里注入多少自己的品味。）

这意味着，所有团队都能接入的自动 eval，迟早会成为卫生标准，像网页不该打不开一样。真正拉开差距的是：你能否定义那些不显眼、却直接影响业务体验的“本来可以做得更好”。边界也很现实：自动 eval 最佳精度大约是 80% 到 90%。也就是说，它标出的 10% 到 20%“错误”其实是误报。若团队把结果直接当事实，反而可能围绕假问题改产品。

被问到 Peter 为播客摘要 skill 写了长度、结构、可读性等 eval，是否已经够用时，Shreya 把评测拆成两半。第一半是 top-down eval，也就是自上而下的标准：不看任何历史数据，只根据任务和领域常识推导规则。比如单条 takeaway 控制在 240 到 330 个字符，内容应该独立可懂，应有可执行的建议。这些要求明确，Claude 也能帮忙起草。

另一半是 bottom-up eval，即自下而上从真实样本里长出来的标准。Peter 手里恰好有过去 10 到 20 场访谈的原始逐字稿，以及自己反复修改后认可的最终版本。把原稿、当前 skill 生成的摘要、人工最终稿放在一起，agent 才能观察到：人到底改掉了什么，保留了什么，为什么这一期删掉了某种表达、下一期却保留。对此 Shreya 的判断毫不含糊："Claude is very very bad at coming up with bottom up evals. That's all you."（Claude 极不擅长自己想出自下而上的评测标准；那完全得靠你。）

这意味着，评测资产不只是 prompt 文件，更包括编辑历史。每一次“这里不对”的人工修改，都是产品判断力的原材料。top-down 标准能让项目立刻开工，但它覆盖的是你事先想得到的事；bottom-up 标准贴近真实失败，却只能通过持续看样本获得。让模型凭空猜你的品味，通常只会得到一套听上去合理、却没经历过业务摩擦的规则。

被问到如何让 Claude Code 协助审阅 AI 生成文章、发现写作错误模式时，Shreya 展示的重点并不是“让 AI 替人审完”，而是让 AI 先把数据变得可读。她的 error discovery skill 有五步：先识别数据的语义类型，判断它究竟是文章、代码还是端到端 agent trace；再决定如何呈现；然后生成 review app；接着挑选值得看的样本；最后运行人和 AI 的互动反馈循环。

这套 skill 不限定数据格式。面对数百甚至数千条 trace，agent 会先做聚类，从不同语义类别中挑出多样化样本，而不是随机甩给人一堆日志。演示中，Claude 大约运行 15 分钟，生成了三个页面：逐篇浏览文章的页面、展示样本聚类的地图页、汇总已发现问题的进度页。Shreya 说："the interface that it comes up with is going to be so much better than me looking at my data in say Google spreadsheets or something"（它生成的界面，会比我在 Google Sheets 之类的表格里看数据好得多。）

这意味着，错误分析的瓶颈常常不是数据不够，而是人眼在原始 trace、表格单元格和长日志中抓不住模式。AI 先负责重排信息，相当于先把散落在仓库里的零件摆上工作台；人才能更快作出判断。但界面不是替代品。Hamel 特意强调，即使未来有 AGI，做产品的人仍要亲自接触真实数据。因为“看见什么值得在意”这一步，不能外包给一个只理解通用错误的系统。

被问到播客摘要 skill 已经积累大量评测条件后，怎样避免某些条件过度拟合、另一些条件被忽略时，Shreya 的建议不是继续往一个 prompt 里加 bullet point。第一步，是在 skill 中明确区分 top-down 与 bottom-up eval，免得后来新发现的经验规则和基础规范搅成一团。第二步，是把评审拆给多个 sub-agent：每个 agent 只检查一条规则，或一组关系紧密的规则。

她还建议，让 AI 汇总出一个表格或 pivot table，逐项列出标准及 pass/fail，让人来判断优先级。比如 Peter 提到的 MECI——相互排斥、完全穷尽——在某一期播客摘要里可能重要，在另一期里未必值得为它牺牲叙事流畅性。Hamel 用“N2”作比喻：模型只接到“评 N2”这个任务时会聚焦；若面对一长串要求，它就会开始漏项。原话是："a model will tend to ignore something and get lazy."（模型往往会忽略某些东西，然后变懒。）

这意味着，规则增加不是可靠性线性增加。一个大而全的评审器，会发生注意力竞争：它表面上看过十项，实际只认真处理了几项。拆成 sub-agent，类似把一份含混的总任务分给不同质检员，能减少遗漏；但它不解决规则冲突。哪些标准更重要、何时应放松某条标准，最后仍是人的产品判断，而不是加权公式自动能替你定夺的事。

被问到怎样把阅读时的即时感受变成 rubric，Shreya 用一篇关于 sleep hygiene 的 AI 文章做了演示。她没有先坐下来给“好文章”写理论定义，而是在原文里即时标注。看到“not X, it’s Y”这种负向对比，她直接说不喜欢；看到 AI 常见的三项并列列举，也随手指出。甚至有一句她一时讲不清问题，只输入“this feels annoying”，要求 agent 结合后续反馈再推断原因。

这里的节奏很关键：她先人工阅读，累积大约 10 条反馈后，agent 才开始归纳分类、扫描其他记录。它不是抢在人前面发明审美，而是在后台消化人已经给出的信号。演示里，系统最后给出 361 条建议；仅“少于四个词的断裂短句”这一条规则，就命中了 249 处。Shreya 概括双方分工时说："human is the one driving the taste and the AI is the one like scaling up or giving superpowers to the human to apply that at scale."（人负责驱动品味，AI 则负责把人的判断放大，让它能大规模应用。）

这意味着，人不再需要逐篇、逐句机械查同一种毛病，但仍要提供最难被形式化的初始信号，包括模糊的厌烦感。AI 的工作是把已确认的判断扩展到全量数据，并让人抽查它是否理解正确。边界是，这一阶段仍然费劲。哪怕只有 8 到 10 条注释，人也必须认真读过足够多样本；AI 不会读心，它只能放大你已经表达过的标准。

被问到为什么 Peter 已经不断增加 prompt 和 eval，播客文章仍然无法一次生成到满意状态时，答案落在写作任务的特殊性上。Peter 说，每一期访谈不同，系统再多加内容、再多加 eval，也仍需要多轮往返。Hamel 把写作称为 LLM 的“最终 Boss”：有些规则会因主题而必须放松；很多时候，人不是先拥有完整标准再开始写，而是看见成品后才知道哪一句不对、哪一个连接突然顺了。

Peter 的去 AI slop skill 就暴露了这个矛盾。它能清理模型惯用的空话和套路，但有时清理过头，连 Peter 本人的写作人格也一起删掉。Hamel 对“写得像你”的难度说得很准确："To like have it right like you in a way that you are satisfied with is extremely difficult."（要让它以你满意的方式写对、写得像你，极其困难。）

这意味着，写作的目标函数不是一份永久固定的检查清单。它受题材、读者、语气和作者当下判断共同影响。同一条“不要三项并列”的规则，在一篇解释性文章里可能有用，在另一篇节奏更快的文章里可能碍事。因此嘉宾建议 error discovery 不要只看 5 个样本，最好像演示里那样审到约 18 个，直到错误模式接近饱和。但他们也没有承诺终局解法：越想用统一的“去 slop”规则驯服所有文本，越可能把作者真正的声音一并磨平。

被问到从错误模式生成 rubric 后，下一步如何真正用进写作产品时，Hamel 把话题从后台评测拉回用户界面。假设系统已经能识别 staccato fragments，也就是断裂、短促的碎片句；也能识别 negative contrast，即“不是 X，而是 Y”式对比。那么在真实写作场景里，这些发现不该只躺在 dashboard 里，而应像 IDE 的代码提示一样，出现在用户正在编辑的位置。

关键不是让 AI 直接覆盖原文。那样用户只会面对一份被改过的稿子，重新读一遍、猜一遍哪里变了。Hamel 的要求是："You want to accept and reject things."（你需要能够接受或拒绝这些建议。） 用户应能逐条接受、拒绝，或者保留原文。写作工具、客服 support bot、不同类型的 agent trace，界面也不该长成同一个样子。Shreya 的 skill 甚至允许用户发现 review app 缺少反馈入口时，直接回到 Claude 对话里修改界面，而不是受限于固定 UI。

这意味着，eval 一旦明确了“什么是问题”，就会反过来塑造产品交互。评测不再只是团队内部的质检分数，而成为用户与 AI 协商的语言：AI 提示原因，人掌握最终编辑权。但这种灵活性也有前提。团队得先弄清自己的工作流，知道用户在哪个节点需要什么判断。否则即使能随手 v-code 出一个界面，也只是更快地做出一个没有明确用途的界面。

这期的主线不是“让 AI 自动做 eval”，而是先把人的品味从零散修改中提炼出来，再让 AI 扩大它的覆盖范围。

“自动评测会把显性错误商品化，品味才是竞争壁垒”说的是外部竞争：每个人都能抓工具调用失败、用户抱怨和格式错误，真正稀缺的是业务语境里的判断。“人不必逐条执行规则，但必须持续定义什么算好”说的是内部协作：人不用亲手检查 249 个断裂短句，却必须先告诉系统，为什么这种句子破坏了自己想要的阅读感受。

两件事其实指向同一件事：AI 可以发现、聚类、扫描、执行，也可以把 10 条注释扩展成 361 条建议；但它不能替你决定一条建议是否值得采纳，更不能替你决定某次例外是不是恰好保留了产品的个性。于是，“标准一多，单一评审器反而会选择性失明”和“评测不应只产出分数，它应倒逼产品界面支持协商”，也就连了起来：规则要拆给机器，优先级和取舍要留给人。

对正在做 AI 产品、写作 skill 或 agent 的读者来说，最实际的起点不是再找一个自动 eval 按钮，而是保存那些你亲手改过的前后版本，挑一批真实样本重新读。你不需要一开始就说清全部标准；但你要能在看到“不对”的地方时留下信号。之后，才让 AI 帮你把这些信号变成可检查、可复用、也可被用户拒绝的建议。