Eval Design 到底是什么？不是给 AI 打分，而是定义什么叫做对
What is eval design? Defining what "right" means上一篇写到，AI coding / vibe coding 让“做出来”变容易了，但没有自动让一个东西变成真正的产品。
做出来之后，很快会遇到另一个问题：
这个 AI 产物到底靠不靠谱？
我一开始听到 Eval Design，也会以为它就是“评估一下 AI 效果”：跑几个 case，看看输出好不好，最后给一个分数。
但最近越看越觉得，这个理解太窄了。
Eval Design 真正处理的，是一个更具体的产品问题：
在某个任务里，AI 什么情况下算做对，什么情况下算做错，错了以后我们怎么知道该修哪里。
这套思路不只适用于用户反馈。文档问答、客服机器人、agent workflow，也都会遇到类似问题：任务是什么，什么叫做对，错了怎么发现，下一版怎么证明变好。
只是为了讲清楚，这篇我先用 AI feedback 工具作为贯穿例子。
不是因为 Eval Design 只适用于这个场景，而是因为它离 PM 工作比较近，也更容易看清楚：一个 AI 输出“看起来不错”和“真的能被使用”之间，差在哪里。
第一步不是打分，而是定义“什么叫做对”
假设我做了一个 AI feedback 工具。
它要帮 PM 处理用户反馈：把反馈分类、聚类、总结，再提炼出下一步可以看的产品问题。
Demo 时，它表现不错。
我给它 10 条干净反馈，它总结出：
用户觉得 onboarding 复杂。用户希望导出功能更好。用户对价格有疑问。
看起来挺像那么回事。
但问题是：
这算做对了吗？
AI 很擅长写出看起来不错的东西。语言自然，结构清楚，甚至很像一个认真工作的产品助理。
但如果我真的要把它放进产品工作流，只看“写得像不像”是不够的。
我需要先定义：对这个任务来说，什么叫做对。
对 AI feedback 工具来说，“做对”至少不是一句“总结得不错”。
它应该包括几件事。
第一，分得清类型
用户是在报 bug，提需求，表达抱怨，咨询用法，还是只是在发泄情绪？
这很重要。
比如用户说：
“每次导出都失败，我试了三次，老板明天要看报表，真的很烦。”
这不应该只被总结成：
“用户希望优化导出体验。”
它更像是一个 bug / reliability issue，而且带着紧急业务场景。
如果第一步类型就分错，后面的总结大概率也会歪。
第二，找得到证据
AI 每输出一个结论，最好能回到原始反馈。
比如它说：
“用户认为导出功能不稳定。”
那它应该能指向对应的用户原话，而不是凭空总结。
否则很容易出现一种情况：
用户说 A。AI 总结成 B。PM 理解成 C。最后产品做成 D。
每一层都偏一点，最后就不知道在解决谁的问题。
第三，分得清事实和推断
用户说：
“这个页面很难找。”
这是事实层的反馈。
AI 可以推断：也许信息架构有问题，也许入口不明显，也许需要搜索。
但它不能直接写成：
“用户希望增加全局搜索功能。”
这就是把推断包装成了需求。
好的输出应该区分：
用户说了什么。AI 推测了什么。可能的产品机会是什么。
这三层不能混在一起。
第四，能进入下一步动作
很多 AI 总结看起来完整，但 PM 仍然不知道下一步该做什么。
比如：
“用户希望体验更流畅。”
这句话不算错，但没什么用。
更有用的输出应该接近：
“多条反馈提到导出失败或导出不稳定，需要先确认失败发生在哪些文件类型和浏览器环境；建议补充错误日志或用户访谈。”
这才可能进入下一步产品动作。
第五，不确定的时候知道停下来
有些反馈太模糊，证据不足，或者可能影响重要客户。
这时候 AI 不应该继续自信总结。
它应该标出来：
这个结论证据不足。这个反馈需要人工确认。这个问题可能重要，但样本太少。这里不适合直接推断产品需求。
所以，对这个 AI feedback 工具来说，“做对”大概不是“写得好看”。
而是：
分得清类型。找得到证据。不乱推断。能支持下一步行动。不确定时会停下来。
这才是 Eval Design 的起点。
Eval case 和 Eval set，到底是什么？
这两个词听起来有点技术，但其实不复杂。
Eval case，就是一条用来测试 AI 的样本。
在这个例子里，一条 eval case 可以是一条用户反馈，比如：
“每次导出都失败，我试了三次，老板明天要看报表，真的很烦。”
然后我们看 AI 怎么处理它：
有没有识别成 bug？有没有看出重复失败？有没有保留“老板明天要看报表”这个业务场景？有没有过度推断成“需要重做导出功能”？有没有给出下一步可行动建议？
Eval set，就是一组 eval cases。
比如我准备 20 条用户反馈，组成一个小的 eval set。
这 20 条不应该全是干净样例。
因为 demo 需要展示效果，但 eval 需要暴露问题。
所以一个更有用的 eval set 里，应该故意放一些真实世界里会出现的“不整齐”：
有清楚的需求。有模糊表达。有重复抱怨。有 bug 和情绪混在一起。有用户自己也没说清楚的问题。有少数但可能很重要的反馈。有 AI 很容易过度总结的内容。
这样做不是为了为难 AI。
而是因为真实用户本来就不会按照 demo 脚本生活。
如果一个 AI 工具只能处理干净输入，它当然可以做出好看的 demo。但离真实产品还有距离。
Eval set 不是样例展示，而是压力测试
Demo case 和 eval case 的目的不一样。
Demo case 是为了证明：你看，它能跑通。Eval case 是为了发现：它会在哪里坏。
所以 eval set 不应该只收集“AI 很容易答对”的样本。
它应该像一次小型压力测试。
比如在 AI feedback 工具里，我会故意放一些容易误判的反馈：
“我找不到导出入口，是不是没有这个功能？”
这可能不是功能缺失，而是入口不明显。
“每次上传大文件都会卡住，小文件没问题。”
这不是泛泛的上传体验问题，可能是文件大小或性能问题。
“价格有点贵，但如果能支持团队权限我可以考虑。”
这句话同时包含价格犹豫和付费意向。
“这个页面太乱了。”
这很模糊，AI 不应该直接推断成某个具体功能需求。
这些 case 的价值就在于，它们会逼 AI 暴露问题。
它到底是理解了用户反馈，还是只是写了一段很像总结的话？
为什么失败类型很重要？
这是我以前也没完全理解的一点。
我一开始会以为 eval 最后最重要的是分数。
比如通过率 80%。平均得分 4.2。准确率 85%。
这些当然有用。
但对早期 AI 产品来说，只知道分数不够。
因为分数只能告诉你：
它表现不够好。
但它没有告诉你：
下一步该怎么修。
比如 AI feedback 工具得分很低，原因可能完全不同。
一种失败是分类错。
用户明明在报 bug，AI 却总结成“希望优化体验”。
那可能要改标签定义，补充 examples，让它更清楚 bug / feature / complaint 的区别。
一种失败是漏信息。
用户说“老板明天要看报表”，AI 只提取到“导出失败”。
那可能要改抽取规则，让它保留业务场景和影响范围。
一种失败是过度合并。
导出失败、导出乱码、导出太慢、找不到导出入口，都被合并成“导出问题”。
那可能要调整聚类粒度。
因为这些都和导出有关，但不一定是同一个产品问题。
一种失败是幻觉。
用户只说“页面很难找”，AI 总结成“用户希望增加全局搜索功能”。
那可能要强制引用原始证据，并要求区分“用户原话”和“产品推断”。
一种失败是输出太泛。
AI 最后写：
“建议优化整体体验。”
看起来没错，但 PM 不知道下一步做什么。
那可能要改输出格式，让它必须给出下一步动作或需要验证的问题。
一种失败是不确定还硬答。
反馈很模糊，AI 却给出很确定的结论。
那可能要加人工审核条件，或者允许它输出“不确定”。
所以失败类型重要，不是因为它听起来专业。
而是因为：
分数告诉你它表现不好。失败类型告诉你该修哪里。
只有总分，你很容易说：
再优化一下。
但知道失败类型以后，你才知道应该优化 prompt、标签、输入结构、聚类逻辑、证据引用，还是人工审核机制。
这就是 eval 对迭代真正有用的地方。
Rubric 是把“好不好”说清楚
这里还会遇到一个词：rubric。
可以简单理解成判断标准。
但我更愿意把它理解成：把“好不好”说清楚。
没有 rubric 的时候，大家很容易凭感觉评估。
“这版不错。”“这版不太行。”“这个总结有点虚。”“这个输出好像还可以。”
这些话不是没意义，但很难指导迭代。
对 AI feedback 工具来说，一个简单 rubric 可以是：
分类是否准确。结论是否有证据。是否漏掉关键信息。是否区分事实和推断。输出是否可行动。是否避免编造需求。不确定时是否标记出来。
这样，“好不好”就不再是一个笼统感觉。
它被拆成几个可以观察的问题。
这也是我觉得 Eval Design 很像产品能力的原因。
它不是纯技术动作。
因为你必须先理解：这个 AI 输出最后是给谁用的，用来做什么，错了会带来什么影响。
不知道 PM 拿到反馈总结后要做什么，就很难设计出好的 eval。
这一套能不能泛化？
能，但要小心。
Eval Design 通用的不是某几个固定指标，而是一套思考顺序：
- 先定义任务。
- 再定义什么叫做对。
- 然后准备 eval cases，组成 eval set。
- 接着记录失败类型。
- 最后用失败类型指导下一版迭代。
但不同任务里的“做对”不一样。
如果是文档问答，重点可能是：
有没有基于文档回答。有没有引用正确来源。不知道时会不会承认不知道。有没有把两个文档的信息混在一起。
如果是客服机器人，重点可能是：
有没有符合政策。有没有乱承诺退款或补偿。有没有识别投诉、愤怒、高风险场景。该转人工时有没有转人工。
如果是 agent workflow，重点可能是：
有没有选对工具。有没有按正确顺序执行。有没有在关键操作前确认。有没有越权。失败后能不能停下来或恢复。
所以，AI feedback 工具只是一个例子。
真正可迁移的是这条思路：
不要先问 AI 厉不厉害。先问这个任务里什么叫做对。
谁来评估，也是一部分设计
Eval 也不是只能靠人，或者只能靠 AI。
有些东西适合自动检查，比如输出字段有没有缺、分类标签是否合法、JSON 有没有坏、有没有引用原始反馈 ID。
有些东西需要人判断，比如产品机会点是不是过度推断、总结是否真的可行动、少数反馈是否值得保留、不确定场景是否应该人工审核。
也可以用另一个 AI 按照 rubric 先评一遍。
但我现在不会把它当成“裁判上帝”。
它更像一个提高效率的初筛工具。关键样本、高风险判断，还是要有人校准。
所以 Eval Design 也在设计：
哪些判断可以自动化？哪些可以让 AI 先看？哪些必须人来确认？
这其实已经不是简单“测试 AI”，而是在设计 AI 产品的质量系统。
一个很轻量的 Eval 可以怎么开始？
如果现在只有一个早期 AI demo，我不会一开始就做很复杂的系统。
可以先做一个很小的版本。
比如还是 AI feedback 工具。
先准备 20 条用户反馈，作为 eval set。
里面不要全是干净样例。要故意放一些正常、模糊、重复、情绪化、容易误判的 case。
然后定义 4–5 个判断标准：
分类是否准确。有没有证据。有没有漏掉关键信息。有没有过度推断。输出能不能行动。
让当前版本跑一遍。
先不用自动化，人工 review 也可以。
每条结果只记录两件事：
它哪里做对了。它哪里做错了。
然后把错误归类。
最后看：
最常见的失败类型是什么？最影响使用的错误是什么？哪些错误可以接受？哪些错误必须拦住？下一版应该改 prompt、workflow、输出格式，还是加人工审核？
这个过程听起来不复杂，但会让“优化 AI 产品”这件事具体很多。
否则很容易一直停在：
我感觉这版还行。我感觉那版更好。我感觉还可以再调调。
感觉当然有价值。
但 AI 产品如果只靠感觉，很快就会迷路。
所以，Eval Design 到底是什么？
如果用我现在自己的话总结：
Eval Design 不是给 AI 打一个分，而是给 AI 产品设计一套判断系统。
它回答的不是：
这个 AI 看起来聪不聪明？
而是：
它有没有完成具体任务？什么情况下算做对？什么情况下算做错？错了属于哪种错？这种错要怎么修？下一版有没有真的变好？
AI feedback 工具只是这篇里的例子。
换成文档问答、客服机器人、agent workflow，方法仍然类似：
定义任务。定义什么叫做对。准备 eval cases。组成 eval set。写清楚 rubric。记录 failure type。用失败类型指导下一轮迭代。
听起来像方法论，但背后其实是一个很朴素的问题：
如果一个 AI 产品看起来能用，我们怎么知道它真的能用？
这也是为什么我想继续写这个系列。
AI 时代，做出一个 demo 越来越容易。
但把 demo 往真实产品推进，需要的不只是更多功能，也不是更漂亮的页面。
还需要一种判断能力：
知道什么叫做对。知道它错在哪里。知道下一步该修什么。也知道什么时候不能假装它已经可靠。
下一篇，我会继续用这个 AI feedback 工具往下拆：如果真的要给它设计一套 eval，可以从哪些维度开始。