一个 Eval Design 的真实实践案例：Asterline

前两篇写 Eval Design，我一直用了一个假设例子：

假设我做了一个 AI feedback 工具。它能吃进一批用户反馈，帮 PM 分类、聚类、总结，再输出下一步可以处理的产品问题。

这一篇，我想把“假设”两个字拿掉。

因为前段时间，我确实做了一个这样的 demo。

它叫 Asterline，是一个 public portfolio prototype。背景是一家我虚构的 B2B 稳定币支付公司 Vela Pay，用户反馈也是我自己写的合成数据。

公司是假的。数据是假的。但 eval 过程是真的。

这篇不是想介绍一个成熟产品。Asterline 还不是。

它只是一个实践案例：当一个 AI demo 已经能跑、能生成、看起来也像那么回事之后，我怎么检查它离“真的靠谱”还有多远。

Talk is cheap, show you the code.

Asterline Demo：asterline.liminzheng.comGitHub：github.com/zhenglimindesign-ing/asterlineCase Study：GitHub repo 里的 CASE-STUDY.md

Asterline 是什么？

Asterline 做的事，可以简单理解成：

feedback in, work pack out.

输入是一批原始用户反馈。

可能有人在抱怨付款失败。有人在问手续费。有人说上传文件没反应。有人只是表达不满。也有人提了一个像需求、但还没有说清楚的问题。

这些反馈如果直接丢给团队，其实还是很乱。

团队需要先判断：

这是 bug，还是需求？是单点抱怨，还是反复出现的问题？有没有触及政策、金额、时间承诺？有没有必要回复客户？下一步是找工程排查、补充文档、继续追问，还是暂时记录？

Asterline 想做的，就是把这些原始反馈整理成一组可以继续处理的 work packs。

每个 work pack 大概包括：

原始证据。问题摘要。建议任务。草拟客户回复。需要人工介入的 review flags。

这里要检查的，不是“AI 会不会总结”。

会总结只是 demo 的第一层。

真正要看的是：它生成出来的东西，能不能进入一个真实工作流。

PM/Tech/Ops 能不能看懂？能不能追溯到原始反馈？任务建议能不能继续往下做？客户回复有没有越界？涉及风险的地方，系统知不知道该交给人？

这些才是这次 eval 真正关心的问题。

这次 Eval Pack 里有什么？

我没有只靠肉眼 spot check。

Asterline 这次至少留下了五类东西：

固定测试样本。判断标准。人工 review 记录。失败类型。版本修改记录。

也就是更常见的说法：

Golden Set。Rubric。Review Log。Failure Types。Iteration History。

这些东西单独看都不复杂。

真正有用的是它们连成了一个循环。

Golden Set 让每次改动都回到同一组场景里比较。Rubric 把“好不好”拆成具体判断。Review Log 记录每次人工看到了什么。Failure Types 把“效果不好”拆成可修的问题。Iteration History 记录这一版到底变好、变差，还是只是看起来更顺。

所以 Eval Pack 不是给 Asterline 做一张成绩单。

它更像一个小型质量系统：让我知道这个 demo 哪里可以信，哪里不能直接信，哪里要改 prompt，哪里要改规则，哪里要交给人，哪里甚至不是 prompt 能解决的问题。

Golden Set：让每一版改动都有比较对象

Asterline 的 Golden Set 是从 25 条合成反馈里选出的 20 条。

我没有只放最容易处理的样本。

里面有一部分能对应到已知政策条款，也有一部分是全新问题。

这样设计，是为了同时检查两类能力：

有依据的时候，AI 能不能引用正确依据。没有依据的时候，AI 能不能承认没有依据，而不是编一个听起来合理的答案。

在 AI feedback 场景里，这个很关键。

最危险的往往不是 AI 完全答不出来，而是它没有依据，却依然生成一段流畅、完整、看起来很专业的话。

这种输出可能会让 PM 误以为某个问题已经被验证。也可能让客户收到一个过度承诺的回复。还可能把一个模糊反馈包装成一个确定需求。

Golden Set 的价值，就是让每次修改都有同一组场景可以回看。

否则很容易出现一种错觉：

这一版看起来更顺。这一版语言更自然。这一版好像更聪明。

但它到底有没有在同一组问题上变好，是另一回事。

Rubric：把“好不好”拆成具体判断

如果没有 rubric，review 很容易变成一句：

“这个输出感觉不错。”

或者：

“这个回复好像不太行。”

这种判断不是没价值，但太模糊，很难指导下一版怎么改。

所以 Asterline 的 eval 里，我把判断拆成了几个层面。

分类阶段要看：

intent 有没有分对。dimension 有没有分对。impact 和 urgency 是否合理。signal strength 是否能反映这一组反馈的重要程度。

生成 work pack 的阶段，要看：

summary 有没有基于原始证据。source quotes 是否真的支撑结论。task 建议是否可行动。draft reply 有没有越界。有没有编造不存在的流程信息。有没有在涉及金额、时间承诺、政策条款时触发 review flag。

这里面有些可以自动检查。

比如字段有没有缺。引用是否能对应到原始反馈。review flag 有没有触发。输出格式是否稳定。

但有些必须人工看。

比如：

这句道歉有没有道歉错对象。这句回复有没有承担不该承担的责任。这个 task 是不是真的能让 PM 或工程师继续行动。这个 draft reply 是在帮助沟通，还是在制造新的承诺风险。

这也是我觉得 Eval Design 很像产品工作的地方。

它不是把所有判断都自动化。

它是先说清楚：哪些判断适合交给代码，哪些可以让模型先处理，哪些必须人来看。

Work pack 这一层，最接近真实产品价值

一开始做 demo 时，很容易关注前面的分类和聚类。

它有没有把 bug 分成 bug。有没有把需求分成需求。有没有把相似反馈聚在一起。

这些当然重要。

但真正接近产品价值的，是最后生成出来的 work pack。

因为 PM 最后看的不是一堆标签。

PM 要看的是：

这个问题到底是什么？证据在哪里？下一步应该做什么？要不要回复用户？能不能直接回复？要不要先人工确认？

Asterline 里最麻烦的部分，其实是 work pack generation。

它不是生成一次就结束，而是反复迭代了多版。

问题也不是“写得不够好”这么简单。

比如，模型会对功能需求写：

“上线后我们会通知你。”

这句话看起来很自然，也像一个礼貌回复。

但问题是，这种承诺很难对每个客户兑现。

它还会在投诉类场景里先讲政策，再讲态度。

可很多时候，用户正在生气，回复应该先接住情绪，再解释规则。

它有时会编出不存在的工单编号。

看起来很专业，但其实是假的流程感。

还有一个 case 里，客户只是自己弄丢了验证设备。

模型却先道歉，措辞反而像平台承认自己做错了。

这些问题如果只写成：

“回复质量不好。”

其实没有什么用。

真正有用的是把它们拆成 failure types：

过度承诺。责任边界不清。编造流程信息。投诉场景没有先处理情绪。道歉对象不对。客户沟通风险没有被拦住。

拆到这一步，下一版怎么改才会变得具体。

乱承诺，就收紧回复规则。编工单编号，就明确禁止生成不存在的流程信息。道歉错对象，就补责任边界。投诉回复顺序不对，就调整 response structure。涉及金额、时间承诺、政策条款，就必须触发人工 review。

Failure Types 的价值不是告诉我“这个 AI 不够好”。

而是告诉我：它到底是哪一种不够好，以及下一版该改哪一层。

Traceability：证据不是装饰，是信任的基础

Asterline 里我很在意的一点，是 traceability。

AI 不能只输出一个漂亮结论。

它要能告诉我：这个结论来自哪些原始反馈。

比如它总结：

“批量上传在部分场景下会静默失败。”

那它就要能回到用户原话：

谁说页面卡住了。谁说上传后没有反馈。谁说不知道付款到底有没有发出去。

这不是为了让输出看起来更严谨。

而是因为没有证据的总结，很容易变成二手判断。

用户说 A。AI 总结成 B。PM 理解成 C。最后产品做成 D。

每一层都偏一点，最后就不知道到底在解决谁的问题。

所以对这类 AI feedback 工具来说，source quotes 不是锦上添花。

它是 work pack 能不能被信任的基础。

Human review：不是安全声明，而是系统动作

很多 AI 产品都会说：

重要内容需要人工确认。

这句话本身不难说。

真正的问题是：它有没有变成系统里的动作？

在 Asterline 里，只要草拟回复涉及金额、时间承诺，或者可能触及政策条款，就会触发 review flag。

被卡住的是草拟客户回复。发送按钮会被禁用。人必须清掉审核标记，才能继续发送。

但任务清单不会被一起卡住。

该排查的、该记录的、该继续处理的，仍然可以往下走。

这个设计背后的判断是：

AI 可以先帮 PM 整理问题。但它不能在高风险客户沟通里自动承担责任。

这不是“AI 不够强”的解释。

而是产品边界。

好的 AI workflow，不应该只追求自动化更多。

它也应该知道：哪里不能自动化。

Eval 也会检查“尺子”本身

还有一个细节，对我很有提醒。

有一轮里，很多 cluster 被标记成“引用疑似编造”。

继续查下去才发现，模型引用其实是对的。

错的是 checker。

负责逐字核对引用的代码里，有一个转义字符写错了，导致跨行原文永远核对不上。

也就是说，不是模型在编。

是校验代码在误报。

这个例子说明一件事：

Eval system 自己也是系统的一部分。它也会出错。它也需要被检查。

AI 产品里的失败来源不只有模型。

可能是 prompt。可能是 taxonomy。可能是 checker。可能是测试数据。也可能是架构看不到必要上下文。

所以看到一个失败标记时，不应该立刻进入“再改 prompt”的惯性。

更重要的是先判断：

这个问题到底出在哪一层？

看起来更好的改动，也可能让系统变差

Asterline 里也出现过一版 regression。

有一版分类逻辑看起来更精细。

它把 impact 判断拆成更明确的几层：

用户完全被卡住，是高影响。有摩擦但能绕过去，是中影响。只是小问题，是低影响。

听起来很合理。

但跑完同一组 Golden Set 之后，结果反而变差了。

问题在于，“有摩擦但能绕过去”这个定义太宽，把一些原本应该是低影响的 case 也吸了进去。

所以那一版最后被撤回。

这件事不是这篇的重点，但它很能说明 Golden Set 和 Iteration History 的价值：

Eval 不服务于我的感觉。

它不管某个方案听起来是不是更聪明、更细致、更像完整规则。

它只问：

这一版在同一组 case 上，有没有真的变好？

如果没有，就撤回。

这对 AI 产品迭代很重要。

因为很多 prompt / workflow 的改动，主观上都会觉得更合理。

但只有跑过同一组 cases，才知道它是在进步，还是在制造新的问题。

这个例子真正想说明什么？

Asterline 不是成熟产品，数据也是合成的。

但它让我更具体地看到：Eval Design 落地以后，不是长成一张漂亮的评估表，而是一套质量语言。

它让你能说清楚：

这个输出哪里可以信。哪里需要证据。哪里可能越界。哪里必须人工确认。哪里是模型问题。哪里是规则问题。哪里是 checker 问题。哪里是 workflow 问题。哪一版真的变好了。哪一版只是看起来更顺。

所以这篇不是想说：我的这套 eval 方法应该被照抄。

它只是一个实践例子。

通过 Asterline，我更具体地理解了：

Eval Design 的价值，不是发现“AI 会错”这种常识，而是把“AI 可能会错”变成系统里的标准、证据、边界和迭代纪律。

下一篇，我想把视角从 Asterline 拉回 AI PM 本身：

为什么 Eval Design 不只是一个评估方法，而会成为 AI PM 很重要的一项产品能力？

因为 AI PM 要做的，不只是把 AI 功能做出来，还要定义它什么情况下算做对、错了怎么发现、哪些风险必须交给人，以及下一版怎么证明真的变好了。