在谈智能化改造时，最常见的开场白是「我们想上一套 AI 系统，用哪个模型比较好」。但把项目真正推进下去就会发现，决定成败的很少是模型，而是一个更靠前的问题：现场的数据，到底能不能稳定地、按统一口径地流出来。
接入被低估，是因为它看起来不像「智能」
接入工作的产出是什么？是一条能用的数据链路、一份清晰的协议映射表、一个设备在离线时不会丢数的边缘程序。这些东西在演示环节完全不出彩，甚至很难放进 PPT。但如果这一步没做好，后面所有环节都会以各种形式返工。
- 模型训练缺少足够样本——因为数据采集断断续续，采样率也参差
- 上线后效果不稳——因为现场数据分布和训练集不一致，而没人发现
- 系统频繁误报——因为设备掉线被当作状态异常，没人做链路健康判断
- 验收扯皮——因为「数据准不准」这件事从来没有被明确定义过
接入阶段真正要解决的三件事
我们把接入拆成三个必须完成的目标，缺一个都不算走完这一步。
| 目标 | 具体含义 | 验收方式 |
|---|---|---|
| 数据取得到 | 设备协议解析完整，关键字段都能读出来 | 连续采集中，字段缺失率低于约定阈值 |
| 数据流得稳 | 网络波动、设备重启后能自动恢复，不丢关键数据 | 人为断网，数据在边缘侧缓存并在恢复后补齐 |
| 口径说得清 | 每个字段的含义、单位、精度、采样周期都有明确定义 | 输出数据字典，业务方与实施方对同一字段理解一致 |
为什么这一步值得单独作为一个阶段交付
因为它的价值可以独立成立。做一个项目时，即便客户后来决定暂缓模型部分，接入阶段做完的东西依然在产生价值：数据自动采集取代了人工抄录，设备状态从不可见变成可见，异常从「事后回溯」变成「当时知道」。
这也是我们把技术路线按阶段拆开的原因——每一阶段都应当是能独立交付价值的最小单元，而不是必须走到终点才有意义的半成品。
如果一件事做到一半停下来就没有任何价值，那它的阶段划分从一开始就是错的。
一个判断接入是否准备就绪的简单标准
在推进模型相关工作之前，先回答一个问题：如果现在把现场数据导出成一张表格，业务方能不能看懂每一列是什么、以及为什么是这个值？
如果答案是「要问一下负责的同事」，说明接入还不到可以往上叠能力的程度。这时先把口径和链路收干净，后面的每一步都会更快。