先说结论：MonitorAI 自称能覆盖 99.3% 的故障模式，SentryWave 自称 99.7%。三个月 POC 结束的时候，我在 Final Report 里用四张表证明，它们真实的故障模式覆盖率分别是 47.5% 和 39.3%。
差了一半。
整个事件最讽刺的部分是——拆穿它们不需要什么内部情报、渗透测试、黑产手段。我就要了一个只读数据管道，然后等了三个月。
故事从一个名片讲起。
FirmCore 的产线监控系统每个月故障一次，比闹钟还准。生产设备跑了快十年，老到哪种程度呢——替换零件的供应商都已经停产两代了，但产线停不得，停一小时的钱够请一年咨询。所以在某个季度会上，IT 老大说"我们要上 AI 监控平台"，没有任何人反对。
两家供应商入场：MonitorAI 和 SentryWave。一个声称 99.3% 故障覆盖率，一个声称 99.7% 覆盖率外加 7 天部署。标准的企业级 AI 推销话术，PPT 做得漂亮得不像话。
我当时的做法很朴素：不提问，不检查数据，不看架构，不要求演示。我只提了一个要求——给我三个月的观察期，把我接进它的只读数据管道，我不动任何配置。
还有一条，我没说出口：我不会提前告诉它们我评估什么指标。
这条规则后来被证明是整个 POC 里最重要的一条决定。
第一周，我花了两天过安全审查，拿到只读副本和配置注册表的访问权。然后我就开始搭并行管道——只读地复制流量日志、告警记录、模型元数据，完全不影响生产。画外音：偷看不叫偷看，叫并行验证。
第一个月底的时候，MonitorAI 的仪表盘显示 97.8% 的检测率，数字确实漂亮。
我拉了一份它声称覆盖的故障模式清单，对照 FirmCore 自己的维修记录——61 个已知故障模式，它连了 29 个对应的数据源。
注意，是"连了数据源"，不是"检测到了故障"。剩下 32 个模式，它的模型入口根本就没收到过信号。我把 29/61 做成一张表，真实覆盖率 47.5%。
SentryWave 那边更离谱。仪表盘写着 98.2%，我数了数它连的 34 个数据源，其中有 5 个阈值低到每天产生 200 多条误报——也就是说它所谓的"高覆盖率"是用假警报堆出来的数字。另外 5 个阈值保守得离谱，那种程度的振动幅值真的发生的时候，检测率可能连 50% 都没有。有效覆盖：24/61，真实覆盖率 39.3%。
两家我都是直接看配置明细算出来的，不需要任何花哨工具。唯一花时间的，是弄清楚它们的模型元数据里哪个字段对应哪个传感器。
第二个月，自然界的数据漂移把游戏推向了新的高度——不是我在搞它们，是生产数据自己在打脸。
MonitorAI 的误报率从 2.1% 爬到 7.4%，再爬到 15.2%，FirmCore 运维组一开始以为是新模型在学习期，后来直接静音了它的告警通道。一家 AI 监控公司，告警被客户手动静音——你们感受一下。
SentryWave 倒是积极，主动"优化"阈值，把误报数调到了零。代价是检测率从 98.2% 掉到 79.4%。零误报，79% 的检测率——这个数字拿去给销售看，大概会被老板骂。但它告诉 FirmCore 的是"我们调整了灵敏度"，仿佛这是什么值得表扬的事。
第三个月的剧情更有戏剧性。
FirmCore 一条产线的轴承故障，被整整 48 小时没发现，最后演变成 4 小时停机，粗算损失 4.7 万美元。而当时 MonitorAI 和 SentryWave 这两套系统都在正常跑着——MonitorAI 第二次模型更新后把误报率降到 6.8%，但同时检测率降到 83.1%；SentryWave 那边经历了配置变更引发的警报风暴——20 分钟内刷了 1400 多条告警，其中 1380 条是误报，当班工程师被从床上拉起来七次。
那个轴承故障，两套系统当时的表现分别是：MonitorAI 完全没告警，SentryWave 在故障发生 46 小时后发了一条低优先级通知。
最终报告我只做了四张表。一张是覆盖率对比，一张是告警质量，一张是 POC 期间停机事件，最后一张——
两家供应商都未覆盖的 12 个故障模式，在 FirmCore 过去两年的生产历史里，造成了 9 次 P0 事故。更魔幻的是，这两家在 61 个模式里覆盖的那 49 个模式，在这两年里从未真正触发过任何一次真实事故。
就是说，就算这两个 POC 双双"成功"，那 9 次关键停机也会在同样的位置如期而至。
我在报告里专门放了一张表：过去两年 89 起生产事故，AI 监控覆盖率 0/89。
FirmCore 在同一周终止了两家的 POC。没有预警，没有第二轮机会。理由是简单的一句话："你们自己的数据已经证明你们无法满足我们的需求。"
后来我上司的 VP 问我，为什么不早点介入、不早点让它们调整。
我说，如果我提前告诉你我要看什么指标，它们会把仪表盘调到那个指标上。它们的系统架构、数据连接深度、模型在真实生产数据上的行为——这些都是一眼看不出、但恰好是决定成败的东西。提前打草惊蛇，三个月后你只能拿到两个精心调校过的、互相矛盾的漂亮仪表盘。
他说我这是"以逸待劳"。我说这叫缴智商税交出了经验。
说起来，POC 结束后的清理阶段，我在存档的 POC 档案文件夹里发现了一张名片——Automated Compliance Lab 的。一个我没接触过的第三方合规审计公司。我没放那张名片进去，所以它是被人塞进去的。至于是谁、为什么，我不确定，但总觉得这跟我们这次 POC 的结局有什么关系。
真实覆盖率这件事，我后来想了很多。问题不在于供应商撒谎——统计口径不同嘛，99.3% 可能是它们在自己测试集上的准确率，也可能是有潜力的样本回放、甚至是测试集里"模型能认出这个故障类型"的百分比，而不是"系统在生产环境里能收到这个模式的信号"的百分比。真正的问题是"覆盖"这个定义本身。一个监控系统，数据源没接上那组传感器的信号，它的模型再强也是瞎的——就像监控摄像头没对着那扇窗户。但产品页上不会写这个。
同样的道理也适用于一切 AI 监控、AIOps 平台、可观测性供应商的"覆盖率"数字：它连了什么，比它声称能看什么，重要一百倍。它能不能收到那组信号，决定了它声称的一切。
后来我总结成了一条规则，贴在工位上了：凡是要验收 AI 监控系统，先给它一套真实的事故回放数据，干跑——数据漂移、阈值漂移、模式覆盖率分开看。凡是要求"看真实数据的反馈再调优"的，先确认你手里有干净的只读管道。
这条规则没有花哨方法论，就是套住了这次 POC 的全部学费。
本期缴税：99.3% 和让你相信它的那套话术，成本约等于一台产线停机四个小时。
至于那个名片——别问，问就是我也没想清楚。