Dogfooding 不是一种评估策略

每个构建 AI 产品的团队都会得出同样安逸的结论：“我们每天都在用它，效果非常好。”这句话听起来像是证据。但它不是。它是房间里最具误导性的信号，而且你的团队越优秀，这个信号就越强烈——更具说服力，也更错误。

“吃狗粮”（Dogfooding）只能告诉你产品在运行。它不能告诉你产品是否奏效。这是两个不同的命题，而它们之间的差距正是你产品发布出问题的地方。从统计学上讲，构建系统的人是所有可能用户中最糟糕的样本。他们共享系统的心理模型，知道它的薄弱环节，并且已经花了几个月时间训练自己，用模型喜欢的方式来组织请求。这根本不是测试人群。这是你从未开展过的一项研究的对照组。

这对于 AI 产品来说比传统软件更重要，因为输入面是开放式的。一个按钮要么被点击，要么不被点击。而一个 Prompt 可以有一万种表达方式，你的团队却只发现了个别成功的表达方式。对 SaaS 仪表板进行内部试用可能会漏掉一些上手时的摩擦。而对 LLM 产品进行内部试用，则会漏掉绝大多数实际的输入分布。

专家用户的盲点

知识的诅咒是一道单行门。一旦你知道一个系统期望被如何对待，你就无法“撤销”这一认知，你的大脑会悄悄假设其他人也知道。对于一个在内部试用自己智能体（Agent）的工程师来说，这意味着你输入的每一个 Prompt 都是经过预修正的。你不会问模棱两可的问题，因为你已经知道这会干扰路由。你不会粘贴混乱的 4,000 token 文档，因为你知道上下文窗口的处理很不稳定。你会预先加载模型所需的约束条件，因为系统提示词就是你写的。

所有这些都不是有意识的行为。这正是其危险所在。你不是在通过作弊来通过评估——你真心认为自己是在正常使用产品。但对你来说，“正常”只是输入空间中一条狭窄、友好的走廊，经过数月的练习已被磨得光滑。而你的用户在没有地图的情况下到来，直接撞在了墙上。

这种效应会随资历增长而复合。你的团队越专业，他们的 Prompt 就写得越流利，他们的日常使用就越倾向于“快乐路径”（Happy Path）——正因为什么都没出问题，他们就越发自信。虚假的自信随着团队技能的提升而增长。一个较弱的团队至少会意外地陷入失败模式。而一个强大的团队绕过这些模式如此顺滑，以至于他们忘记了失败模式的存在。

这还有第二层原因。你的团队还知道哪些功能是脆弱的，并会无意识地避开它们。半成品的导出流程、在高负载下会超时的工具调用、针对短查询返回垃圾信息的检索路径——团队内部有一张“禁区”热力图。用户没有这样的地图。他们无处不去。吃狗粮系统性地减少了对产品中最容易失败区域的采样。

“吃狗粮”在结构上无法触及的失败类别

有些 Bug 不仅仅是你的团队不太可能发现——它们对你的团队来说是 不可能 发现的，因为发现它们的前提是“不是你的团队”。这些问题值得被命名，因为“增加测试量”无法解决它们。

首次运行的困惑。 资深的内部用户基本上从未体验过首次运行。他们几个月前就已经完成了上手（Onboarding），从此再也没有用全新的眼光看过空白状态。然而，首次运行才是用户决定是否留存的关键。关于 AI 产品的行业数据在这里非常残酷：很大一部分用户在第一周内就会放弃 AI 工具，而最常被提及的原因并非模型准确性，而是不知道该做什么。对于非专家来说，空白的 Prompt 输入框就是一堵墙。而你的团队从未见过这堵墙。

格式错误和幼稚的输入。 你的团队能写出格式规范的 Prompt，因为他们知道这个系统的规范是什么样的。真实用户会粘贴半个电子表格，编写单词长度的查询，在句子中间切换语言，包含电子邮件签名，并要求智能体“修好它”，而没有说明“它”是指什么。这并不是边缘情况。对于很大一部分用户群体来说，这 就是 他们的输入分布。如果你的评估集是基于内部使用生成的，那么它几乎不包含这些内容。

对抗性探测。 用户会做一些你的团队从未想过的事情，有时是出于好奇，有时是出于恶意。他们会尝试破解（Jailbreak）系统提示词，粘贴来自网页的 Prompt 注入载荷，要求智能体做一些显然超出其职责范围的事情，并截屏发生的任何奇怪情况。你的团队共享“产品是用来做什么的”这一构建者心理模型，而这恰恰是对抗性用户所不具备也不关心的心理模型。

加载中…