评估的护城河不在 AI，在人的品味
评估不能只靠 AI 自动生成：自上而下的标准它很擅长，但真正决定产品好坏的自下而上评估——从错误数据里提炼的品味——必须由人来提供，再借助 Claude Code 规模化执行。
核心论点 · 点时间戳可跳到原声
模型能替你写标准，替不了你的口味
Shreya 把评估分成两类：自上而下是根据任务本质预先设定的，比如长度、可执行性；自下而上则是浏览大量样本后，把直觉性不满沉淀成规则。Claude 对自上而下很在行，但自下而上必须由人来提供，因为模型无法凭空知道你的口味。这也是为什么评估必须迭代：每发现一个新失败模式就补一条规则，但要注意别过度拟合到单次访谈上。
— Shreya评估标准太长，模型会偷偷跳过
Shreya 建议把评估标准分成两组，让子代理分组评估，避免模型面对长清单时偷懒忽略。同时让技能自动生成一张电子表格（或透视表），列出每条标准的通过与失败情况，这样你能快速判断哪些标准对当前任务更重要，甚至手动加权，而不必盲从统一权重。
— Shreya15 分钟搭个界面，胜过盯着表格看
Shreya 演示了她的 error discovery skill：第一步读数据并判断语义类型（是文章、代码还是 trace）；第二步设计视觉编码，用颜色、间距、透明度凸显数据差异，让人更容易看；第三步用 HTML 和 Python 搭建审查界面；第四步由 AI 聚类并挑选多样化的样本；第五步进入交互循环——你在界面上给开放反馈，Claude Code 实时读取并把反馈整合成新样本或评估标准。整套流程约需 15 分钟，但换来的是远超表格的可读性。
— Shreya人只管说不喜欢，归类交给 AI
Hamel 解释这套交互背后的机制：人读样本时顺手给出开放式评论，比如「我不喜欢否定对比」「这很烦但说不清为什么」，后台的 Claude monitor 工具会持续消化这些评论，在积累到约十条后自动开始归纳主题，并主动扫描全部样本，把同类问题自动标注出来。核心哲学是：人类负责品味和判断，AI 负责规模化地发现和归类，而不是替人发明标准。
— Hamel错误分析的产物就是你的评估标准
Shreya 指出，错误分析产生的不只是问题列表——这些失败模式可以直接变成你的 rubric，也就是评估标准。她演示中自动生成的 361 条建议里，最常见的是少于四词的 staccato 碎片（249 条）。把这些标准写进技能，以后每次生成后就能用 LLM judge 逐条判定；同时，由于你已经有了人工标注的数据集，还可以反向验证这些评估标准本身是否可靠。
— Shreya自动评估工具漏掉的正是产品判断
Hamel 分享了他们对 Brain Trust、Arize、LangSmith 这类自动评估工具的基准测试：它们能捕捉工具调用失败、用户表达不满这类明显错误，但普遍漏掉需要产品判断的隐性错误——比如一个房产销售 bot 面对「你们没有这个房源」的异议时，只会说「抱歉没有了」，而不会推荐替代方案。更值得注意的是，Claude Code、Codex 等编码代理与这些工具表现相同，因为底层模型和提示词本质一致。
— Hamel精确率 90% 也不够，误报会歪曲方向
Shreya 补充说，自动化评估工具在最好情况下的精确率也只有 80%-90%，意味着 10%-20% 的报错其实是误报，如果盲目照做会歪曲产品方向。所以真正有效的做法是：用工具快速找出明显错误，再手动审查数据，验证工具的发现、补充它漏掉的地方，并确保你的品味注入产品。这才能和竞争对手拉开差距。
— Shreya用评估换便宜模型，成本能砍 100 倍
提到课程深度，Shreya 说除了错误分析与生产化，还覆盖了如何把评估接入 CI/CD、监控长期漂移、对抗性评估（防止租户数据泄露）等。最实用的部分是改进模块：用评估来指导模型切换——换便宜模型时，通过评估优化其准确率，他们实际帮学生和客户把成本砍掉了 100 倍。这是纯评估技能之外的工程能力。
— Shreya原话 · 已逐字校验
Now Claude is very very bad at coming up with bottomup evals. That's all you
Claude 非常非常不擅长提出自下而上的评估，这完全靠你。
Shreya6:03
we joke that writing is the final boss for LLMs
我们开玩笑说，写作是 LLM 的终极 Boss。
Hamel11:05
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 表格里查看数据。
Shreya16:08
the hardest part of eval is error analysis which is coming up with this rubric
评估最难的环节是错误分析，也就是想出一套评分标准。
Shreya34:22
There's there is no world in the future. Even if you have AGI, if you're building a product, you have to look at your data.
未来也不存在这样的世界。即使你有 AGI，只要在构建产品，就必须亲自看数据。
Hamel39:25
It's really hard for humans to upfront think of like from top down like what are all the things that are good and bad. It's like almost impossible.
要让人类预先从头想清楚什么是好什么是坏，真的很难，几乎不可能。
Hamel47:31
数字与实体
| 错误发现技能自动生成的建议总数 | 361 条 | 34:22 |
| staccato 碎片（≤4 词短句）数量 | 249 处 | 34:22 |
| 审查界面构建耗时 | 15 分钟 | 24:15 |
| 自动化评估工具最高精确率 | 80%-90% | 50:33 |
| 通过评估优化实现的成本下降 | 100 倍 | 52:35 |
| 触发自动标注所需的人工反馈数 | 约 10 条 | 28:19 |
术语
- bottom-up evals自下而上的评估
- 从大量真实输出中，由人提炼失败模式而形成的评估标准。
- top-down evals自上而下的评估
- 基于任务本质与领域知识预先设定的评估标准，与数据无关。
- LLM judgeLLM 评判器
- 让模型根据明确标准对输出做出通过/失败的判断。
- error discovery错误发现
- 通过审查数据找出失败模式并固化为评估标准的工作流。
- staccato fragments短句残片
- 少于四个词的破碎句，AI 写作常见的凑字数风格。
- slop废话/水词
- AI 生成中空洞、套路化、缺乏信息量的套话。
收听指南
用 LLM 构建产品（尤其聊天机器人、写作工具、Agent）的工程师与创业者，正在头疼怎么设计评估体系的人。
[08:04] 广告插播可跳过。