售后服务 · 企业在用

在控制器报警之前，提前发现热泵的冷媒类故障

原来的问题

上万台热泵分布在北美各地，持续上报运行数据，十年间积累了数百万条报警，却从没被系统地分析过。

设备自身的诊断只有控制器里的几个超阈值保护：某个量越线就停机、报一个故障码，其余全靠售后工单。等用户打电话时，机器已经坏了，工程师已经在路上。

北美一次上门服务的成本很高，售后支出年年让业务头疼，但数据和售后之间没有任何东西接起来。

为什么先做这个

• 钱在哪儿：先找企业最贵的那个动作——北美上门服务，再看 AI 能不能减少它发生的次数。省的是外部现金和赔付，不是内部人时。
• 换不来：这条线的价值几乎全部来自企业独有的物理事实、固件特性和标签口径，买不到也抄不来，只能定制。通用的文档解析、分类、检索套标准能力就行，力气压到这条线上。

怎么做的

• 先钉死成功标准：唯一的核心指标是“比控制器现有保护提前多少天预警”，两个时间戳一减就是成绩，事后改不了口径。同时写下“不做”清单，判决类收窄到 4 类，运行数据不喂给任何外部大模型。
• 把数据完整搬到本地，并且能证明搬全了：发现导出会静默截断之后，重建了一条能和页面总数核对的数据通道，每日自动增量更新。第一版看板做成双击就能打开的单文件，不用等 IT 排期。
• 清理“物理世界里的脏数据”：找出固件、传感器口径、控制策略和安装差异带来的系统性偏差，规定每台设备只跟自己和同批次比，不做跨机的绝对值比较。
• 生产标签：按“故障事件”而不是单条报警计数；售后工单按证据强弱分五级，只有工程师写下的根因和修后数据恢复验证才进训练集。
• 不让 AI 自证正确：按设备切分训练集和验证集，按事件计指标；控制器报警只当对照基线，不当真值；规格冲突时停下来等人裁决；每条诊断都要带“反证”和“现场核查清单”。
• 隐私护栏放在数据库层：分析用的数据库角色查不到用户电话、姓名、地址，序列号做假名化，全流程本地运行。

结果

• 系统已落地，在企业里使用。
• 全量运行数据和报警打通到本地，每日自动更新。
• 建立了按故障事件计数、按证据强弱分级的标签体系。业务价值最高的冷媒泄漏类样本很少，所以验证必须格外克制。
• 核心指标“比控制器提前多少天预警”还在验证中，有可靠结论再公布。

结果只写有出处的事实；没有出处的数字不上站。

踩过的坑

• 成功标准只写了收益项，没写代价项：误报率的可接受上限，本该和提前量一起写进验收标准。
• 项目后半段拖住进度的不是算法，而是远端数据库连不上、对方排期和别人手里的文件格式。
• 怀疑上游之前先自查；但同一份代码跑两遍只能证明结果可重复，不能证明它对，应该换一条独立通道再核一次。
• 口径错了就公开作废，在报告里写更正声明，不悄悄改。
• 还没和更便宜的办法做过对照（比如把现有保护阈值下调一档），所以还证明不了这套方法一定更值。
• 预警报出来之后送到谁手上、由谁决定派不派车，必须接进工单流程，否则“提前 N 天”在业务上等于零。

适合谁复制

有大量在网设备运行数据、售后上门成本高的设备制造商（暖通、热泵、家电、工业设备），前提是能拿到原始运行数据和固件逻辑，故障是慢慢变坏的类型（如冷媒泄漏），而且要求全流程本地化。

用到的工具

AI 编码代理；本地分析数据库；物性残差特征与本地统计模型；单文件 HTML 看板。运行数据不调用任何外部大模型。