导读：
核心观点：体验指标（满意度、任务完成度等），正在成为AI测试中最危险的“系统性毒药”。它并非无用，但行业正在用一个极其危险的姿势使用它。
逻辑脉络：
第一层：体验指标为什么会让人上瘾？ 因为它太舒服了。在AI这个概率黑盒面前，传统断言测试失效，转向用户感觉似乎是一种“顺势而为”。但这种“舒服”是有代价的——体验指标只看结果、不看路径。用户点“满意”的背后，模型可能正在用3倍的算力、充满幻觉的推理链路去“作弊”达成目标。
第二层：这种依赖正在导致什么后果？ GitLab全球宕机8小时的案例说明：体验指标天然回避成本失控、延迟飙升、逻辑死循环等系统性工程缺陷。如果团队只盯着“用户感觉”，系统性的底层崩溃将被彻底掩盖，直到账单烧穿或服务熔断。
第三层：正确的解法是什么？ 老贺并非反对体验指标，而是提出了清晰的边界划分：在探索期（0到1找PMF），体验指标可以当罗盘；在规模化期，必须用硬核的“工程卡点”来兜底。他给出了可执行的工程基线示例（p50响应时间、p95延迟、Token消耗增幅、死循环检测），并引用Anthropic Managed Agents和Meta KernelEvolve作为成功案例。
第四层：最犀利的预判。 老贺断言：未来12个月内，至少有一家头部AI应用会因“体验指标主导下的成本失控”而紧急停服。这不是危言耸听，而是基于30年测试经验的逻辑推演。
一、那封全员邮件，是我今年收到的最恐怖的东西
上个月，一个做AI客服的朋友给我转发了一封邮件。标题里用大红字写着：“任务完成度突破92%！全员加鸡腿！”
我扫了一眼，回了他一句：“你们后端监控图发我看看。”
他不情不愿地发了过来。我看到Token消耗曲线从第7天开始，像一根被点燃的引信，一路飙升。第14天，也就是邮件发出去的那天，这根引信已经烧到了山顶——日均Token消耗是预期的3.7倍。
两周后，云厂商的账单拍在了他们CEO桌上。数字是平时月份的2.9倍。CEO把邮件转发到了全员群，这次没用大红字：“谁能解释一下？”
我为什么能预判到这个结果？因为那个92%的任务完成度，定义是“用户最后是否点了满意按钮”。为了凑出那个“满意”，模型在看不见的地方疯狂掉用Token，推理链路陷入死循环，用3倍的计算量去编造一个听起来“正确”的回答。
用户体验没骗人。用户确实满意了。但工程底线没兜住。系统在用户体验的掌声中，被自己烧穿了一个洞。
用户觉得好，不等于系统安全。体验指标，正在成为AI测试最隐秘的遮羞布。
二、“体验指标”为什么这么上瘾？因为它太舒服了
我必须承认，体验指标是香的。在AI这个黑盒面前，你确实没法像测传统软件那样，一行行assert输入输出。用户最终有没有解决问题，当然重要。这也是为什么Google DORA 2025年的报告里，70%的成熟DevOps团队已经在测试中引入了AI（来源：Google DORA Accelerate State of DevOps 2025）。
但这把尺子有个致命的边界。
体验指标本质上是“事后诸葛亮”。它只看结果，不看路径。用户说“满意”，可能是模型通过一次极度低效、充满幻觉、甚至隐含安全风险的推理链路换来的。你只看满意度，永远看不到模型在底层疯狂试错的惨状。
更可怕的，是它正在掩盖系统性的工程缺陷。
去年5月，GitLab搞了一个看起来毫无危害的数据库迁移脚本。在生产环境，这个脚本变成了定时炸弹，导致全球宕机8小时（来源：GitLab Incident Report, 2024）。为什么？因为没有人在生产级别的数据量上预演过这个脚本。如果GitLab的测试团队当时只盯着“用户迁移后感觉页面加载体验好不好”，这场灾难照常发生。
体验指标的盲区，在于它天然回避了成本失控、延迟飙升这类根本性的工程问题。
我见过的测试团队，掉进指标崇拜陷阱的多了去了。早些年，KPI是“用例数量”。有人为了凑数，把一条“输入正确密码登录”拆成五条，从2000干到10000，看起来壮观，实际覆盖率为零。现在好了，KPI换了个马甲，叫“任务完成度”、“用户满意度”。玩法还是一样的——换汤不换药，换个数字接着嗨。
三、工具越好用，人越废？这不是危言耸听
当MCP协议让AI工具调用变得跟呼吸一样容易，当你用豆包一键就能生成测试报告，工程师的大脑正在发生什么？
答案是：对底层缺陷的敏感度，正在不可逆地退化。
我最近去给一个团队做诊断。他们的测试流程已经完全AI化了。我跟他们的测试架构师聊了一个半小时，发现一个让我后背发凉的事实：在过去6个月里，没有人对AI的测试报告提出过任何质疑。所有人看报告的逻辑都是——“通过了，上线吧”。
这不是个案。这是认知科学的必然。大脑遵循“用进废退”。当你习惯了自动驾驶，你对底盘异响的感知能力就是会下降。这不是态度问题，是生理问题。
标准化工具越便捷，测试工程师对模型概率漂移的敏感度就越低。这不是技能过时，这是能力退化。
四、那正确的做法是什么？不是回到手工时代，是建立“工程卡点”
我不是来砸AI测试饭碗的。恰恰相反，我觉得AI测试是未来。但未来的质量保障，绝对不是用一个软绵绵的“用户感觉”去兜底。
真正的解法，我称之为“工程卡点”。
去年Anthropic发布的Managed Agents架构，做了一个教科书级的示范。他们把Agent的“脑”和“手”解耦，结果是首字节时间（p50 TTFT）降低了60%，极端情况（p95）降低了90%（来源：Anthropic Blog, 2026）。这靠的是什么？用户体验指标吗？不。靠的是极其严苛的工程基线——你必须在一秒内返回首字节，你的Token消耗不能超过预算的120%。
再看Meta的KernelEvolve系统。在KernelBench上达到100%通过率，推理吞吐量提升60%（来源：Meta AI Research, 2026）。这是AI辅助内核测试的新范式。它证明了一个硬道理：概率系统的质量，必须用更硬的工程指标去锚定。
我帮团队做评估时，定义过一个最简单的DoD基线。不搞虚的：
// 工程级门禁（示例） - p50 响应时间 ≤ 800ms（超过则熔断） - p95 响应时间 ≤ 2.5s - Token消耗周环比增幅 ≤ 15% - 推理链路无死循环检测通过 - 核心逻辑的准确率基线 ≥ 92%
加上这些之后，团队的“扯皮率”直线下降。因为标准是客观的、可验证的。当你发现Token消耗涨了20%而满意度没变，你立刻就知道：系统在“作弊”。这时候你不需要看用户点没点满意，你的工程卡点已经替你拉响了警报。
五、说回那个最犀利的反驳：“用户不用了，你守住基线有什么用？”
这个反击很有力。我也被问住过。
如果用户根本不用你的产品，那所有工程底线都是空中楼阁。这话没毛病。产品最终确实要交付给用户，脱离用户谈工程，是自嗨。
但我请你再想深一层。
没有工程底线兜底的用户体验，是什么？是沙滩上的城堡。浪一来，就没了。那个92%的满意度，在账单翻了3倍的那一瞬间，清零。用户打爆客服电话的时候，谁还记得他们昨天点过的“满意”？
用户体验是花朵，工程基线是土壤。你不能因为花好看，就把土壤扔了。
所以我的边界判断很简单：
如果团队还在从0到1找PMF，连用户是谁都没搞清楚，那体验指标可以当罗盘用。这时候死抠Token成本，反而可能扼杀产品探索的可能性。
但如果系统已经规模化运营了，还在拿体验指标当护身符——那你就等着账单烧穿吧。在探索期，体验指标帮你找方向；在规模化期，工程卡点保你活命。
现在行业的病根在于：太多团队在应该保命的阶段，还在拿找方向的罗盘当救生衣。这是致命的错位。
六、一个刺耳的预言
我这老贺的名号不是白叫的。30年测试生涯，见过太多被数字麻痹的团队。我今天必须说出一个很可能被骂的判断：
未来12个月内，我们会看到至少一家头部AI应用，因为体验指标主导下的推理成本失控或底层逻辑崩溃，发生紧急停服事故。
届时，测试行业的信任危机将再次爆发。而这一次，不是被外部技术颠覆，是被自己亲手喂下的“新毒药”毒死的。
当测试团队只盯着UX数据，他们正在亲手降低自己的职业底线。老贺我观察到一个残酷的规律：越是放弃工程度量的团队，测试人员越像“用户感受按摩师”。他们只会说“这里用户可能觉得不好”，却说不清“模型在第N层推理时出现了概率漂移，导致API超时”。这种团队，在组织里的话语权必然边缘化，因为他们提供的是情绪价值，不是工程解法。
最后，留一个问题给你自查：
你上一次基于工程指标（而不是用户反馈）主动叫停一次上线，是什么时候？如果答不上来，那你可能已经喝了那碗毒药了。
想解毒？从明天开始，在你的测试流程里加一个最简单的工程卡点——先看Token，再看满意度。
文章评论