2024 年 5 月，我们接手了一个管道泄漏识别的项目（项目周期至 2026 年 5 月）。
需求听起来并不复杂：通过声音判断管道有没有泄漏。
但真正做进去才发现，这是个典型的「工业 AI 陷阱」 —— 论文里可行，Demo 里漂亮，工程上一地鸡毛。
到项目尾声，这个项目没有变成一个更大的项目，而是长出了一套平台。
回头看，每一步都不是提前规划好的，而是被具体的工程问题一步步逼出来的。
01 第一个麻烦：信号比噪声还弱
管道泄漏的声音是什么样的？
不是「嘶嘶」的明显漏气声，而是埋在土层、水声、交通噪声、泵站振动之下的一段微弱宽频信号。信噪比极低，而且随环境、压力、管材变化。
当时市面上现成的方案基本是两条路：
传统声级计 / 阈值判定：简单，但在真实工况下误报率高到没法用
通用机器学习流程：需要大量标注样本，而泄漏样本根本没法大量采集 —— 你不可能为了训练模型，去管道上人为制造几十次泄漏
我们最后走的是声学信号谱减降噪的路线。
这个方向后来申请了发明专利《一种基于声学信号谱减降噪的管道泄漏检测方法》（公开号 CN 120667653 A，2025 年 9 月公开）。该专利即源自上述管道泄漏项目的工程实践，对外表述已确认。 这是全文可公开查证的硬佐证。
管道项目的延伸：从算法到系统
同一时期，围绕「管道」这个场景，我们还在解决另一件事——把泄漏检测从「听清一段信号」，扩成「管好一整条管路」。
后来的另一件发明专利《一种热蒸汽输送管路泄露风险健康监测方法及系统》（公开号 CN 120212438 A，2025 年 6 月公开）走的正是这个方向：在预设采集点部署监测设备，基于振动信号判断管路健康状态，并通过剩余电量管理与自动充电，让设备可以长期无人值守地运行。
这件专利同样源自管道监测方向的工程实践，对外表述已确认。它的视角已经不只是「怎么听清泄漏」，而是「怎么让一套监测系统长期、稳定、无需人工干预地跑下去」——这种从「算法」到「系统」的意识，后来成了平台架构的底色。
02 第二个麻烦：没有趁手的工具
技术方案想清楚了，接下来的问题很朴素 —— 没有工具可用。
当时要做的事，用现在的话说就是一整套声学 AI 工作流：采集大量现场音频、标注哪一段是泄漏、哪一段是干扰、提取特征、训练模型、验证、部署到现场设备。
但这些环节当时是散的：
采集要自己写脚本
标注要导进音频软件手动切分
训练要自己搭环境、调参数
部署要重写一遍 C 代码，再对接现场通信协议
我们花了不少时间把这些环节拼起来，做了一套仅供内部使用的工具链。
它很粗糙，但它让我们能把项目做完。
03 踩到那个坑：模型部署后精度掉了
工具链跑通之后，我们撞上了整个项目里最让人崩溃的问题。
模型在 Python 环境下验证得很好（准确率 98%），一旦部署到现场的边缘设备上，准确率掉到了 70%。
排查了很久才定位到：不是模型的问题，是特征提取的代码换了实现。
Python 端用 Librosa，设备端用 CMSIS-DSP。两边的 FFT 实现、Mel 滤波器公式标准（HTK vs Slaney）、DCT 精度、Log 计算方式都不一样。每一层差一点点，累积起来经过分类器映射，判决结果就翻转了。
解决办法后来成了我们的一项基本功：把「两端必须一致」当成不可妥协的红线，Mel 权重硬编码、DCT 查表、Log 查表、FFT 实例全局化，最终做到特征逐维误差小于 0.05%。
这件事的完整技术细节写在另一篇《Python 训练到 MCU 推理：精度是怎么掉的，又该怎么对齐》里，这里不重复。
但这次踩坑的意义不止于技术本身 —— 它让我们意识到，这些「被逼出来的经验」，可能比我们做的那个项目更值钱。
04 第三个麻烦：样本永远不够
管道项目还暴露了一个更根本的矛盾。
工业场景的样本分布，和消费互联网完全是两个世界：
异常事件本身就少（管道不会天天漏）
发生了也不一定采集得到（设备故障往往在停机检修时才被确认）
新场景上线时，历史数据基本为零
传统监督学习要求「先给我大量正负样本」，但在工业现场，这个前提几乎从来不成立。
我们当时的做法是反过来想：既然异常样本拿不到，那就只用正常样本。把「正常」的声音特征学透，凡是偏离这个模式的，一律报警。
这就是后来平台里「良品基线学习」的由来。
回过头看，这个限制反而催生了更适配工业场景的方法 —— 因为现实中工厂永远缺不良品样本，一个要求先攒半年不良品的方案，在立项阶段就已经被否掉了。
05 转折点：这套工具，别人是不是也需要？
项目做完后，那套内部工具链一直在用。
真正的转折发生在我们和同行交流的时候 —— 发现大家踩的是同一批坑：
算法工程师不懂产线工艺，产线工程师不懂模型调参
项目必须依赖算法团队全程参与，周期 2–4 周，费用几十万起步
中小工厂根本用不起，继续靠人耳听音
我们花了一年多才趟过去的路，为什么每个团队都要重走一遍？
于是开始认真考虑：把这套内部工具做成产品，开放出去。
但「开放」不是把内部工具加个界面就完事。横在面前的有三个硬门槛：
门槛一：使用者不会写代码
工厂里最终要操作这套系统的，是质检员。他不关心什么是梅尔频率倒谱系数，也不该被要求写 Python。
所以我们把「专家经验」固化进系统：标注做成时域 + 频域双视图的鼠标框选，训练参数由系统自动推荐，工程代码自动生成（含 Modbus 等工业协议对接）。
使用者不需要知道为什么这么设，但能得到正确的结果。
门槛二：没有算法团队就没法迭代
模型上线不是终点。设备老化、产线换型、来料变化，都会让基线漂移。
如果每次调整都要找供应商，那客户就被锁死了。所以我们把增量训练做成标准能力 —— 客户自己在平台上加样本、重新训练、一键同步到硬件，更新周期压缩到 1 个工作日。
门槛三：数据不能出车间
这一条是硬约束。工业客户普遍不接受产线数据上传云端，很多车间网络受限甚至物理隔离。
所以架构上做了个关键选择：模型同步到硬件后，硬件完全独立运行 —— 本地推理、不联网、不上云，声音数据不出车间。
06 关于「开放」，我们想清楚的三件事
决定做开放平台，内部是有过争论的：把能力全部开放给客户，客户学会了是不是就自己干了？
后来想清楚了三件事：
第一，壁垒不在功能列表，在工程深度。
平台功能是可以被模仿的，但「训练端和推理端特征逐维对齐」这种事，是踩过坑才知道要做。同行可以抄界面，抄不走这些被工程验证过的细节。
第二，客户要的不是一套软件，是解决问题的能力。
他们真正缺的是「在不增加算法团队的前提下，把质检做起来」。把工具给他们，他们解决的是自己的问题，我们解决的才是行业的问题。
第三，开放改变了信任关系。
封闭系统的本质是：客户必须持续依赖供应商。而在开放模式下，模型自己训、自己迭代，数据不出车间 —— 供应商从「不可替代的掌控者」变成「可替换的工具提供者」。
这是一种权力关系的重构。短期看我们似乎让渡了控制力，长期看，愿意这么做的供应商本来就不多，这本身就是差异。
07 现在和以后
从管道泄漏那个项目开始，到现在的产品形态，中间没有一次是「我们决定做一个平台」这样的宏大时刻。
真实的过程是：
遇到一个具体的工程问题
→ 没有工具，自己写一套
→ 发现工具里踩过的坑，同行都在踩
→ 把这些经验固化成产品能力
→ 为了让客户能独立用，必须做图形化和边缘独立
→ 于是它变成了一个平台
每一步都是被问题推着走的。
现在回头看，这个过程中沉淀下来的三样东西 —— 跨平台特征对齐、良品基线学习、固定式声学工程 —— 都不是来自技术预研，而是来自具体的、不得不解决的麻烦。
这大概也是工业 AI 和互联网 AI 最大的区别：这里的创新很少来自灵光一现，更多来自被现场反复教训之后的那句「这样不行，得换个办法」。
作者：贺中义 单位：上海创单电子科技有限公司（ISSAUTO） 职务：研发总监