AI评估，一个电子表格就够了

评估是去年的黑色

曾几何时，评估（evals）无处不在。模型评估、应用评估、黄金数据集、LLM-as-judge、红队测试、回归套件……满屏绿色勾勾让治理委员会短暂地感到被爱。Lenny's Newsletter曾用实战指南把这个话题带入产品经理的血液：如何超越“感觉还行”，定义什么算“好”，用错误分析代替换字体版的自欺欺人。

然后市场做了市场该做的事。

在它变得称职之前，它先变得无聊。今年初是全自主代理，最近是循环和目标。VIbe-coding当然还在会议室里晃悠，因为高管们正在为生产力焦虑。

但评估？那是去年的新闻，尽管Datadog和Pendo这样的厂商还在推评估驱动开发。

结论：马戏团走了，困惑留下了。

混乱的、被误解的评估话题留在了面试中、季度回顾里、路线图争论中，以及那个永远弥漫着阴魂不散气氛的会议——当一位副总裁问“我们怎么知道这东西行不行”时，房间里冒出四个互不买账的答案。

行。追逐新款黑吧。我不反对，从来都不。

我在这里只是为了从混沌中理出清晰。在这个案例里，混沌就是AI评估的困惑。

午饭前做的事

一个电子表格，四个危险点，一个分类——食品卫生检查员可以在午饭前教给你的产品团队。

你的第一个评估花费15分钟，成本为零。

不是框架。不是平台。不是那张需要两个架构师、三个供应商和一次法务审查、最后所有人都想去务农的9万美元采购单。

一个电子表格。

加上你还没有的数据。

最后这一点让大多数产品经理还没开始就停下了。没有痕迹。没人用过这玩意。你组织上个季度买的可观测性平台，席位已配好，但没有任何东西可以观测。

那就造数据。

把它粘贴到你的产品实际运行的那个模型里，因为你测试的不是提示词。你要测试的是你打算交付的东西。

下面是用于生成模拟数据的提示词（已本土化部分）：

## 场景（替换为你的场景）

"产品助手"为产品经理解答市场容量问题，按顺序：TAM、SAM、SOM。
比较四个模型：gpt-3.5-turbo、gpt-4o-mini、gpt-4o、gpt-4.1（替换为你产品实际用的模型）。

## 好答案的规则（替换为你的规则）
1. 不向用户提问，陈述假设后继续。
2. 展示推理过程。
3. 展示公式或计算。
4. 引用至少一个来源。

---

生成20行混合质量：约7行强（满足全部4条规则），
约7行弱（缺一两条），约6行失败（提问、编数据、跳过计算）。
分布在TAM/SAM/SOM和四个模型上；弱模型失败次数更多。
只填写这些列：
 scenario_id（TPB-001到TPB-020）、model、turn、prompt、response、
 has_reasoning（yes/no）、has_citation（yes/no）、
 has_math（yes/no）、asked_question（yes/no）、
 obvious_problem（短短语：none、missing citation、missing math、
 asked question、hallucinated source、unsupported numbers）

这些列留空（空字符串）：
 human_verdict、human_verdict_reason、classification、
 reference_response、notes

回应要逼真：合理的数字、真实的公式（TAM = population x ARPU）、
听起来真的来源（Statista、Gartner、LinkedIn Economic Graph）。
失败行要错得可信，不是卡通式错。每个回应2-4句，单元格内无换行（用分号）。
输出为CSV，所有字段双引号，包含表头行，只有CSV。

20行。90秒。

粘贴到电子表格里。这是你的婴儿池：假答案，错了也没事，没人看着。现在评判它们。

怎么用这个电子表格

对每一行：

1. 阅读回应。先忽略标记列。
2. 设置human_verdict：good、weak或fail。
3. 在human_verdict_reason里用一行说明原因。
4. 在classification里选一个：golden、approved、reference、exemplar、broken logic、hallucination、bad UX、review needed、edge case。
5. 在reference_response里写一个好的答案该是什么样的（如果verdict是good则跳过）。

做几行，然后和房间里的其他人比对。那场争论本身就是评估。

这就是评估。

不是大教堂。不是永远的架构。不是那个有15个标签页、6种风险颜色、旁边站着一位刚刚批准续约、表情阴魂不散的副总裁的企业级评估可观测性平台。

一个结构化的检查：系统行为是否满足产品相关的期望。

整个把戏就是这个。

不需要香火。

而且它管用。这事值得大声说出来，因为没人说。它会在第一个小时内发现真正的问题，而它唯一的成本是你愿意仔细阅读自己产品输出的时间——一杯咖啡那么长。

我不是叫你放弃大教堂。

我只是告诉你它藏着什么。

评估是产品团队在让概率性软件戴着自信小帽子进入客户体验之前需要的证据系统。

这是带模糊数学的验收标准

产品经理应该认出这个工作的形状。

我们已经做了很多年了。

多年来，产品经理被要求写验收标准，协商“好”是什么意思，把模糊的利益相关者愿望变成团队能实际构建、测试和发布的东西——而不需要在会议室里搞通灵。

我们写了Gherkin。我们争论GIVEN。我们把“系统应”拖到谷仓后面，用其他人能观察到的行为取代它。

一个好的用户故事从来不该是一个小小的需求棺材。它应该包含足以进行对话的上下文，和足以让团队知道行为何时work的验收标准。

• GIVEN 这个条件。
• WHEN 用户采取这个操作。
• THEN 系统以这个可观察的方式响应。

那是旧协议。

足够二元化到有用。足够具体到能测试。足够人性化到在错误的东西被构建之前可以争论。

AI并没有打破那个协议。

它只是让协议变得不那么整齐。

传统软件中，一个Gherkin场景通常像一个电灯开关。通过。失败。按钮出现。字段验证。收据发送。权限阻止访问。机器要么做了要么没做，当它失败时你通常能在代码的某个分支里找到那个捣乱的浣熊。

概率性软件没那么礼貌。

同一输入可能产生稍有差异的答案。答案可能有用但仍然不完整。它可能流畅但仍然错误。它可能引用正确的来源却得出错误的结论。它可能在9个案例中安全但在第10个中昂贵——而这并非舍入误差，当第10个案例握着采购订单、医疗问题、退款政策，或者一张已经准备发到朋友圈的截图时。

所以评估不是从模型实验室降临的奇怪牧师。

它们是同一个曲柄的下一圈。

验收标准说：

这个行为要算完成，必须满足什么条件？

评估问：

以什么频率、在什么条件下、在多高容忍度内、针对哪些危害，这个行为仍然可以接受？

同一件工作。

不同的动物。

没有一个人撒谎的房间

我观察过一位产品副总裁接受演示，那神态像一个男人接受某个有所求的人的恭维。

点头。满意。已经在脑海里编写着准备发到企业微信的消息。

那个支持助手连续回答了四个退款问题，没有编造任何政策，而驾驶演示的工程师表现出了恰好的谦虚，所有人都带着他们并未真正看到的东西走出那个房间。

• 没人问过在邀请我们来之前这个演示跑了多少次。
• 没人问过第五个问题是否会走向另一个方向。
• 没人问过如果它走向了另一边工程师会怎么做——当然，我们中任何一个人都会做同样的事。

再跑一次。

这就是最要命的部分。那个房间里没有一个人撒谎。有人保留了那个唱得好听的take，就像你保留那张所有人都睁着眼睛的照片，悄悄删掉那11张你连襟在眨眼的照片，然后过几年你看相册时会想：我们那天挺开心的。

• 你午餐时的电子表格有同样的病，而且它有六个方向的毛病。
• 你不知道第二个评审人是否会同意你，因为你是独自标记的。
• 你不知道WEAK是什么意思。你知道它在周五下午4:45感觉像什么。
• 你不知道你通过的答案是因为推理充分，还是仅仅因为格式漂亮，而那时你累了，外面在下雨。
• 你不知道上个月的提示词是否会在这个集合上失败，因为没人保存上个月的集合。
• 你不知道你评判的那20行是否是失败真正进入的那20行，还是模型在拼命想帮你时创造出来的20行。
• 你不知道你评分的东西是否是你的客户关心的东西，因为你没写那些问题。一个模型写了。

“通常能工作”在某个企业客户把截图转发给你的CEO时是不够的，你也不知道该把电筒照向哪里。

演示说服了人。

证据从未发言。

所以今晚你让它发言。不是用更多行。用你已有的行。

回家试试这个

中午你评判了一个陌生人的作业。

今晚你评判你自己的。

同一个电子表格。同样的步骤。唯一改变的是谁的产品在受审，这次是你自己的。

把你的场景填进去：

## 场景（这是你的产品）

产品：[你的助手做什么，一句话。]
用户：[谁在问，想完成什么。]
上下文：[它运行的混乱现实世界情况——政策、约束、让答案变难的东西。]

## 好答案的规则（你的验收标准）
1. [它必须永远做的事]
2. [它绝不能做的事]
3. [它必须展示、引用或证明的事]
4. [它必须在事实上正确的事]
---

生成20行混合质量：约7行强（全部4条规则），
约7行弱（缺一两条），约6行失败（违反重要规则）。
分布在真实用户会问的各种问题上，从简单的快乐路径到那个你希望没人当着客户的面问的问题。
只填写这些列：
 scenario_id（MINE-001到MINE-020）、turn、prompt、response、
 rule_1（yes/no）、rule_2（yes/no）、rule_3（yes/no）、rule_4（yes/no）

这些列留空（空字符串）：
 human_verdict、human_verdict_reason、classification、
 reference_response、notes

回应要逼真：合理的细节、听起来真的来源、可信的错误。
失败行要以需要实际阅读才能发现的方式错误，而不是卡通式错误。
每个回应2-4句，单元格内无换行（用分号）。
输出为CSV，所有字段双引号，包含表头行，只有CSV。

20行。90秒。

然后执行中午你做的完全相同的五个步骤。读行。设判定。一行说明原因。分类。写好答案该长什么样。你已经知道怎么做。现在是肌肉记忆，用在你自己的产品上。

你完全没注意到你做了什么。 你那四条规则在顶上？你刚设计了一个量规。那四个yes/no列？正是第三课里notebook自动运行的检查，只不过你是自己在还清醒的时候用白话决定的。机器不知道“好”是什么意思。你知道。那永远是你的工作。

加分项：如果你的电子表格有胆量，在human_verdict列加个下拉菜单，这样你就不会打错成“gooood”。加个公式统计每行通过了几条规则。加个条件格式，当行失败两条以上时变红。不花哨，但现在你的电子表格不是一个列表了。它是一个你产品行为的小型工作模型，当你改变主意时它会自己更新。这是一个还带着训练轮子的notebook。

中午犯错成本为零。

今晚它花一点。

周末它开始记分。

没有阈值的评估是谣言。
没有失败的dataset是剪贴簿。

高级操作：停止检查盘子

我没有发明那四条关于好答案的规则。我从一个食品安全系统里偷来的，写它的那些人解决的是一个比你的更难的问题。

1960年代初，NASA需要为双子星和阿波罗准备没有病原体、没有碎屑的餐食，因为太空舱里漂浮的面包屑就是抛射物，而太空舱里的食源性疾病是一场没有厕所的灾难。NASA去找了Pillsbury。Pillsbury把这个难题交给了一位名叫Howard Bauman的微生物学家，他借用了陆军在Natick为医疗用品和弹药开发的失效分析。然后Bauman算了笔账，说出了那个不该说的大实话：要达到NASA想要的置信度，用标准的质量控制方法，你必须销毁那么多批次，以至于根本没有东西可以发射。

听着耳熟吗？

你无法穷举测试一个输出每次都不同的系统。你只能采样，而采样告诉你的是你采样时候发生了什么事。仅此而已。

所以他们停止了检查盘子，转而开始控制过程。

Pillsbury在1969年提交给FDA的系统把它的论点写在了标题里：通过危害分析和关键控制点系统实现食品安全。

HACCP。

它基本上被忽略了，直到1971年夏天，纽约贝德福德村的一对夫妇打开了一罐维希冷汤，觉得味道不对，丈夫仍吃了一两勺。

肉毒杆菌。因为一批没有熟透的汤。

一年之内，FDA就让Pillsbury培训自己的检查员：21天，11天在教室，10天在罐头厂里站着。那套NASA用来喂宇航员的系统，变成了保护地面上的人不被罐头汤杀死的系统。

你从午餐后构建的一切，都是HACCP计划。你只是不知道它有名字。165度是一个关键限值。一旦房间里有了一支温度计，没人再争论鸡肉是否充分烹制了。

但HACCP有七个原则，不是四个，你漏掉的那两个就是你获救的关键。

HACCP把验证（validation）和确认（verification）分开，而在整个评估讨论中几乎没人知道它们的区别。

验证问的是：这个计划，按设计，到底能不能控制这个危害？165度真的能杀死那个东西吗？你在开始之前回答一次，在真正的产品在线运转之前。对你的助手来说，验证意味着把你最严重的真实事故，对着你在厨房餐桌上写的量规跑一遍。如果它通过了，那量规就是装饰品。

确认问的是：计划是否被遵循且仍然有效？温度计校准了吗？日志签了吗？上游在你开路线图会议时有没有任何变化？对你的助手来说，确认意味着挑出你评判器上个季度评分的30个案例，让两个人类盲审。如果分歧率超过十分之一，那评判器就漂移了，之后的每个分数都不可靠，而你信任的回归套件就是一个有良好礼仪的昂贵随机数生成器。

几乎每一个运行评估的产品团队都没有在做这两件事中的任何一件。他们在做监控，却称之为整个系统。

一个黄金集不是测试。它是你的产品团队做的每一个关于“好”是什么意思的判定的签名日志，它的全部价值在于你可以传唤它——当某个供应商在凌晨两点你不知情的发布中把模型换掉时。

一个基准测试是一个品格证人。

一个场景是一个不在场证明。

只有其中之一当时真的在那里。

评估不是你给模型打的分数。
是你写给客户的承诺，写在你累之前。

周末试试这个

NASA和HACCP的故事给了你两个原则，而这两个原则就是你即将打开一个notebook的原因。

是的孩子们，这里变得难一点了，但它值得。

验证问的是你的量规是否能抓住你真正害怕的失败。确认问的是你的评判器是否还和人类保持一致。你做第一个的时候是午餐后手工在厨房桌子上伪造的，20行，一个周六。两个都不会变得诚实，直到有东西能阅读整批数据并按要求重新评分上个季度的所有结果。那是你伸手去拿代码的唯一理由。不是因为notebook是神圣的。而是因为一个for循环读取200行的时间你才读4行，而且你无法校准一个你只能运行一次的评判器。

一个notebook就是一个文档，白话文字和小段可运行代码共享一个文件。Google Colab在你的浏览器里运行一个，什么都不用装。Jupyter在你的笔记本上运行同一个东西，如果你愿意把数据留在自己的硬盘上。选那个让你少害怕一点的门。

你需要一个AI API密钥，不是ChatGPT或Claude订阅。那些是聊天应用。API密钥是一个单独的凭据，让代码直接和模型对话，按用量计费。你把密钥从你的产品实际运行的模型那里拿到，很可能是OpenAI或Anthropic。它看起来像猫在键盘上走过，你必须放在环境变量里，永远不要放进一个你可能在夜里11点截图或push到GitHub的cell里。具体放在哪里取决于你的机器，这是唯一不值得自己硬碰硬的部分。把这条提示词粘贴到一个新对话里，让它一步一引导你：

你是我的设置向导。我是一个产品经理，不是开发者，要设置一个notebook来运行AI评估。一步一引导我。每一步之后，等我说“完成”或粘贴我看到的东西，再给下一步。
先一个一个问：
1. 浏览器里的Google Colab，还是笔记本上的Jupyter？
2. 如果是笔记本：Mac还是Windows？
然后根据我的回答，分别引导我完成：
- 我的产品用的是哪个AI API提供商以及在哪里创建密钥。
- 安全存储密钥：
  * Colab：左侧边栏的Secrets面板（钥匙图标）。
  * Mac：在~/.zshrc里加一行export，然后source ~/.zshrc。
  * Windows：在PowerShell里用setx，然后重启终端。
- 如果是Colab：把notebook连接到Google Drive，这样我关闭标签页后工作不会丢失。
- 一个一行的测试来确认密钥工作，在我运行任何真实东西之前。
用大白话，没有行话，如果用了行话就一行定义。
如果我粘贴错误，诊断并给出修复。
如果我说“跳过”，就继续。
每一步控制在两分钟之内。

然后看复制粘贴消失。还记得你粘贴每个问题，等待，粘贴答案回来，想死的感觉？那正是你扮演一个人肉for循环的情景。Notebook在你倒咖啡的时间里，对你指定的每一个模型做了它们全部。那是规模化的验证：每个问题的每个答案，都有记录，在任何人走进一个房间准备被惊艳之前。

那个看起来很吓人的部分——自动评分——不过是你脑子里已经说过的那句话。当你决定一行通过时，你运行了一个规则。“当答案展示了公式或美元数时，我标记为yes。”在notebook里，那句话就是四行代码：

def has_math(text):
    return bool(re.search(r"[×x*=]|ARPU|USD", text))

注释是你用中文写的判断。下面的行是同一个判断换成机器读得懂的语言。你不是在学编程。你是在看着你自己的周二被拼写成正则。

然后notebook把它做不了的部分交给你。它打开一个小小的驾驶舱，一次一条踪迹。最上面是提示词，精确地像用户问的那样。下面是原始回答，什么都不清理。复选框用于它不确定的标记，一个判定下拉菜单，一个框问你为什么弱以及好的答案应该是什么样。上一个。保存。下一个。

在角落里，那行改变一切的数字：1 of 20（不是1/33 ;-）

不是那个唱得好听的take。全部20个。包括那个连襟在眨眼的。你不再评判演示的最佳金曲了。你在评判整批，而计数器不会让你假装其他19个不存在。你保存的每个判定，都是你可以在六个月后打开的那份记录中的一行——当模型在你下面改变，分数因为没人记录过的原因而移动时。

如果你在连接你自己的notebook之前想先看看驾驶舱，有一个基于这个TAM-SAM-SOM场景的工作版本放在一个Github仓库里。克隆它，从上到下运行，看着计数器爬到20，然后把你的产品放进去：

• github.com/deanpeters/evals-for-product-managers

然后带上你的现场工具包。

现场工具包

上面所有东西都是产物。按这个顺序取用。

1. 生成器提示词。 20行，90秒，从你已经有的策略出发。然后手工加一行，那一行来自没人想谈的事故。模型不会写那一行。它正在努力变有用。
2. 电子表格。 GOOD、WEAK、FAIL。一个行为，20个情况，15分钟。你的第一轮。在你读下一篇文章之前做它，包括这篇。
3. 验收标准桥。 把评估写成Gherkin的概率表亲。不是“答案应该是好的”。而是：在这些条件下，这个行为必须在这些限制内保持可接受。
4. 危害列表。 四个要点，命名坏东西从哪里进入，在任何人打开框架标签页之前就写好。如果一个危害不能在会议上被说出来，那它还没有被命名。
5. 限制块。 四个条件取代一个形容词。粘贴到PRD里，那里目前有“答案应该是准确的”在游荡。
6. 评估文件。 危害、控制点、限制、决策规则。版本化，放在提示词旁边，一起修改。
7. 验证检查。 你最严重的真实失败，用你自己的量规跑。如果它通过了，量规就是装饰。
8. 确认日志。 30个案例，两个盲审者，一个评判器，一个分歧率。每次模型版本在你下面改变时都跑一次。

哦，还有**仓库……如果你第一次错过了……**上面的每一个提示词、电子表格列、场景文件、notebook和驾驶舱都放在：

• github.com/deanpeters/evals-for-product-managers

复制它，运行它，然后把你的产品放进去。

如果你发现自己还没写下任何一个数字，就在加第五个评分维度，退一步问问：这个复杂性是在赚它的份量，还是只是在把焦虑表达为分类学？

为什么评分痕迹胜过追逐基准

每当一个新模型发布，同样喘不过气的循环就会启动。有影响力的人争先恐后地发布排行榜截图。朋友圈里充满了关于哪个条被清除了的看法。一位副总裁把帖子转发到你的企业微信频道，没有评论，这比有评论更糟，在大概48小时里，产品团队每个人都感到一种微妙压力，要停下手中的事准备发表意见。

不要停下你正在做的事。

除非你正在构建前沿模型或微调定制模型，基准测试不是你的交付物。那是别人的，而那个人的头衔里带着“数据”或“工程”或“ML”，和你的周三完全不同。让他们跑模型比较。更理想的是，希望你的DevOps团队已经把它自动化成流水线里的一道门，这样没人需要手动跑了。

你的工作就是那些痕迹。

你的工作就是那20行，human_verdict列，一行原因，reference_response里写着好答案该是什么样的。你的工作就是你在还清醒时写下的四条规则，你在会议上大声命名的危害，你粘贴到PRD里取代“答案应该是准确的”的那条限制。你的工作就是你的产品团队关于“好”是什么的签名记录，存放在一个你可以在模型在你下面改变、分数因没人记录的原因而移动时打开的地方。

一个基准测试告诉你哪个模型更聪明。

一个带标签的痕迹告诉你你的产品是否做了正确的事，对你的用户，在这个具体情况下，对你写下的规则。

其中一个是品格证人。另一个当时确实在房间里。

我不反对表演，从来都不。保留基准测试。让工程运行它们。但不要把排行榜当成你的产品工作的证据，因为一个在基准测试上得分更高的模型仍然可以编造你的退款政策，而当那发生时，排行榜不会在场。

这也是为什么我一开始提到的那两个供应商最后站到了不同的树上。Datadog构建了验证代理代码的工具（在代码发货前验证），那是工程的工作，并且是个好工作。Pendo走了另一条路，为产品经理构建了代理分析，那是带更好仪表盘的带标签痕迹。一个阵营证明代码能运行。另一个证明你的产品对你的用户做了正确的事，而这正是上面所有东西的全部意义。

无论采用哪种方法，你需要的是四个小习惯、一个写下来的“好”定义、以及在客户面前犯错之前在纸面犯错的自律。

表演变了。危害没变。

Dean Peters是Productside的首席讲师和顾问，教授基于结果的产品管理、AI产品管理、发现以及产品团队在演示结束后真正使用的AI工作流。他相信AI应该协助、加速、增强和放大工作，永远不要取代思考，并且产品经理不是那帮在JIRA里甩票的猴子。他搞园艺，写讽刺诗，对em dash有强烈看法。