内部试用 (Dogfooding) 你的 Agent 并不等于 QA

你的 Agent 内部指标看起来棒极了。任务完成率达到了 94%。#agent-feedback Slack 频道已经安静了三周。领导层正准备将其推向客户。接着外部用户进场了，不到一个月，数据全线崩溃：工单量激增，信任度降至冰点，复盘时每个人都会问：“Dogfooding 怎么会漏掉这些问题？”

Dogfooding 并没有漏掉问题，而是掩盖了问题。内部用户并不是客户群体的缩影 —— 他们是一群专家级操作员，在无声地修补 Agent 的错误，学习避开哪些提示词（Prompt），并在私信里分享变通方案而不是提交 Bug。每一次修补都让仪表盘（Dashboard）看起来更好，却让产品变得更难理解。你读到的清晰信号并非质量，而是补偿（Compensation）。

员工修补效应

研究工作场所自动化的社会学家对你同事们的行为有一个专门的称呼：修补劳动（Repair labor）。对自动化工作场所的研究描述了这种 “修补工作（Patchwork）” —— 即填补自动化系统承诺与实际交付之间鸿沟的隐形人类努力。它有几种表现形式：系统发生故障时进行补偿、为了防止故障而盯着它、以及悄悄调整输入以减少故障频率。

这些行为在你进行 Agent 的 Dogfooding 时都会出现，并且每一项都会腐蚀你的质量信号：

• 无声纠正。Agent 起草了一份退款金额错误的客户回复。你的支持主管在发送前修正了数字，因为修正只需 8 秒，而提交 Bug 需要 8 分钟。任务被记录为已完成。失败的痕迹荡然无存。
• 提示词规避。在 Agent 搞砸了两次多账户查询后，你的内部用户干脆不再问它多账户的问题。该类别的失败率降至零 —— 因为 “尝试” 率降到了零。你的流量分布在产品的弱点周围悄然变形。
• 民间知识。“噢，你必须说 ‘截至今天’，否则它会提取陈旧数据”。这种说法在 Slack、午餐谈话和入职伙伴之间流传。新员工继承了这些变通方案，却从未经历过产生这些方案的失败。这些知识从未进入评估套件（Eval suite）。

这并非懒惰或破坏。这是人们理性的行为，他们的工作是完成自己的任务，而不是给你的产品做 QA。关于工作场所 AI 透明度的研究发现，出于自我保护的原因，员工会少报 AI 的参与度和 AI 的问题 —— 他们不想显得效率低、没能力，或者像是在抱怨领导层刚刚压上路线图的工具。在每一步中，激励机制都偏离了诚实的失败报告。

外部用户颠覆了所有假设。他们不知道那些神奇的措辞。他们会问你的同事已经学会避开的问题。他们不会去修补退款金额 —— 他们会截图、发帖，然后流失。Klarna 广为人知的 AI 支持上线案例就是一个典型：在首席执行官看来，内部运行良好的指标在真正的客户带着真实问题进入系统后，转化成了 “更低的质量”，最终公司不得不重新雇佣人类员工。失败模式一直都在，只不过能容忍它们的人不在了。

为什么 Dogfood 信号看起来如此完美

有必要精确剖析其中的机制，因为 “内部用户有偏见” 这种说法低估了这种结构性的偏差。

首先，你的员工是世界上最宽容的用户群体。他们了解系统的架构，因此能预见哪里会失败。他们拥有组织背景，因此能瞬间发现错误答案。而且他们与开发团队有社交关系，这使得每一份 Bug 报告都变成了一种小小的批评行为。这些特性中的每一项都让他们更擅长使用 Agent，却更不擅长衡量 Agent。

其次，Agent 失败的方式会诱导用户参与掩盖。传统软件的失败是巨大的 —— 堆栈跟踪、500 错误、崩溃的标签页。Agent 的失败则是通过产生看似合理、自信且格式良好，但细微处有误的输出来实现的。对生产环境下 Agent 失败的现场分析一致发现，危险的失败不是崩溃；而是实际原因下游五步之外的流利错误。专家用户会发现错误并顺手修补，通常甚至没有意识到这是一个产品失败。而非专家要么直接发送错误，要么被它坑了。

第三，“对我们有用” 的标准本身就很低。麻省理工学院（MIT）对真实职业任务中的 AI 进行的大规模评估发现，在约三分之二的文本任务中，模型能产生 “最低限度合格” 的工作（9 分中的 7 分，无需编辑即可使用），而真正卓越的输出充其量只是碰运气。内部用户有动力让工具发挥作用，并擅长修饰其输出，他们将 “最低限度合格加上我的快速修补” 视为成功。客户则将 “最低限度合格” 视为平庸。同样的输出，相反的结论。

结果就是一个仪表盘，它衡量的是 Agent 加上一群隐形的专家修补工的共同表现 —— 并将一切功劳都归于 Agent。

修复工具，而非完成工具

修复方法并不是“加大‘吃狗粮’（dogfooding）的力度”，而是改变你衡量的内容。任务完成情况只能告诉你工作是否完成了，却无法告诉你是由谁完成的。你真正需要的信号是修复事件 (repair event)：即在 Agent 的输出与最终结果之间，人类干预的每一个瞬间。

具体来说，这意味着要记录大多数团队都会忽略的内容：

• 使用前的编辑距离 (Edit distance)。 当 Agent 起草内容时——无论是回复、查询还是配置更改——请对比它生成的原始版本与人类实际发送或运行的版本之间的差异。GitHub 的 Copilot 团队公开吸取了这个教训：原始接受率（raw acceptance rate）会奖励大量琐碎的建议，因此他们转而衡量被接受的代码中有多少存留了下来——即在开发者继续工作后，那些字符是否仍然存在。人类接触后的存留率是一个关注修复的指标，而接受率则不是。
• 接管点与放弃点。 在一个多步骤任务中，人类在哪个环节接管了控制权？如果一个用户让 Agent 完成第一步到第四步，却总是手动完成第五步，那么他们通过自己的行为提交了一份精确的 Bug 报告。请将其记录为一个 Bug。
• 查询形状漂移 (Query-shape drift)。 将内部请求的分布与早期外部测试中新手用户的提问进行对比。那些内部用户不再行使的类别——或者措辞显得异常统一的类别——正是由于产品质量不佳而导致民间规避方案（workarounds）取代了产品功能的类别。
• “重试后改写”序列。 一个提问、得到错误答案并立即重新组织措辞的内部用户，经历了一次永远不会出现在你的反馈渠道中的失败。即使人类没有主动报告，对话记录也会将其记录下来。
• 规避方案考古。 定期在自己的 Slack 中搜索关于 Agent 且包含“你必须”、“确保你”、“如果……就不起作用”以及“直接手动操作”等关键词的消息。每一次搜索结果都是一个未记录的已知问题。这种方法虽然原始，但非常奏效。

注意这些方法的共同点：它们将 Agent 周围的人类行为视为衡量标准，而不是信任人类会将他们的体验转化为报告。毕马威 (KPMG) 和墨尔本大学 (University of Melbourne) 的研究发现，大约三分之二的员工在不经核实的情况下直接接受 AI 输出，这具有双重影响——不核实的人发现不了失败，而核实的人会默默修复。这两个群体都不会告诉你。你的遥测系统 (telemetry) 必须能够识别这一点。

“它能用”与“我们的员工学会了如何规避它”

一旦你开始记录修复事件，几个衍生指标就能将真正的质量与习惯性补偿行为区分开来：

• 单独衡量新手用户的成功率。 运行一个对内部“套路”零接触的用户群体——比如入职第一周的新员工、承包商或轮换的“冷启动用户”小组——永远不要将他们的数据与资深员工的数据混在一起。冷启动用户与资深用户成功率之间的差距就是你的“经验债”，这是预测外部发布体验的最有效指标。
• 单个完成任务的修复率。 在标记为成功的任务中，有多少比例涉及人类的编辑、接管或重新措辞？如果完成率是 94%，但 40% 的完成都带有修复事件，那么你的自主成功率就不是 94。
• 规避方案形成时间。 当一个新的失败模式出现时，内部流量需要多长时间会绕过它而不是报告它？规避方案的快速传播意味着你的反馈渠道已经输给了你的 Slack 文化。
• 故障报告半衰期。 跟踪每个活跃内部用户的 Bug 报告是否随时间推移而减少，而每个用户的修复事件是否保持不变。报告下降而修复持续存在，这是“员工修复效应”的特征：人们并没有停止遇到失败，只是停止了向你汇报。在只绘制报告数量的图表上，这种衰减曲线看起来与“产品变好了”完全一致。

这些指标也会改变上游的行为。一旦“修复率”出现在“完成率”旁边的仪表盘上，那八秒钟的沉默修复就不再隐形，构建 Agent 的团队将开始看到他们的用户一直在承担的工作量——即自 ERP 以来，每一波自动化浪潮所产生却未能被计入的“新的人力工作层”。

“吃狗粮”仍然重要——作为一种不同的工具

这并不意味着你应该跳过“吃狗粮”环节，而是意味着你应该停止向它询问它无法回答的问题。内部使用在专家用户所擅长的领域表现出色：捕捉架构缺陷、压力测试集成、揭露那些连宽容的用户都无法通过修复来规避的严重失败。严谨的评测 (eval) 实践也从另一个角度证明了这一点——在早期开发阶段，手动测试和直觉能带你走得非常远，这正是因为专家判断是高密度的信号；而当用户群体不再像开发者时，这些方法就会失效。

因此，将你的发布过程视为三种不同的工具，每个工具都有自己的问题。“吃狗粮”回答的是“这在架构上是否稳健，且能让专家生存下来？”；修复遥测回答的是“有多少人力在支撑成功指标？”；冷启动用户群体回答的是“陌生人的实际体验会是如何？”。当这三者达成一致时再发布，而不是当第一个声音消失时。

这种不舒服的纪律在于拒绝为静默的反馈渠道而庆祝。来自内部用户的沉默是你整个遥测堆栈中最模糊的信号：它要么意味着 Agent 停止了失败，要么意味着人类停止了诉说。这两种状态之间的区别就是“发布”与“事故”的区别，而判断你面对的是哪种情况的唯一方法，就是对那些你的员工因太忙、太善良或太适应而未报告的修复行为进行遥测。