如果让你在远离市政管网的场景下搭建一套供水系统你会怎么选传统思路是拉管线、建水塔、配增压泵但在很多偏远站点、应急场景和分布式能源环境下这套方案的工程成本会迅速失控。于是有人把目光投向另一种思路直接从空气里“挤”出液态水。空气制水系统Water-from-Air System听起来像概念产品但在“分布式供水基础设施”这个框架下它其实是一套集成了热力学、流体控制、水质处理、物联网监控和数据分析的完整技术体系。这篇文章想解决的不是“空气为什么能变水”这个科普问题而是更实际的工程问题一台空气制水设备如何从孤立的单机变成一个可远程监控、可自动控制、可数据驱动的分布式供水节点。也就是说真正值得技术人关注的不是蒸腾冷凝那点热力学而是设备如何联网、数据如何流转、故障如何提前发现、控制逻辑如何可靠执行。如果你正在做物联网、嵌入式、后端数据平台或智慧城市相关项目这套系统是一个非常适合用来练手的技术场景。我会从原理边界开始讲避免你被“免费取水”这类话误导然后把整个系统拆成分层架构再给出一套最小示例覆盖传感器采集、边缘控制、MQTT 上报和产水效率估算。你可以把这些代码直接跑在常见的 Wi-Fi 开发板上也可以只把后半部分的数据分析代码放到自己的服务器上做模拟。文章会尽量把技术选型背后的原因讲清楚而不是给你一堆设备清单就结束。1. 为什么“空气制水”值得进入基础设施视角集中式供水体系在人口密集的城市里效率很高但在部署分布式供水系统时它面临的瓶颈非常明显管网铺设成本高、施工周期长、中途漏损难以控制而且一旦某一段管线出现问题影响的是整条链路。相比之下分布式供水的基础思路是“在哪用水就在哪制水”把大型水厂和长距离管网拆成若干个靠近用水点的制水单元。这样做的代价是单个单元的设备复杂度上升但赢得的是部署灵活性和系统韧性。空气制水系统刚好是一种很典型的分布式制水单元。它不需要接入水源只要环境中有空气、有电就能生成液态水。早期这类设备主要用于除湿机场景后来逐渐被改造成应急饮用水设备。但如果你站在基础设施角度看单台空气制水机还远远不够一台设备放在偏远站点如果无人值守水箱满了没人处理、滤芯堵了没人发现、设备半夜停机只能等到下一次人工巡检那么它在可靠性上是完全不达标的。所以我的判断是空气制水的技术瓶颈不在“能不能制出水”而在“如何让分散在各地的小型设备变得可观测、可控制、可维护”。一旦设备具备远程数据上报能力、边缘自动保护逻辑和基于数据的预测性维护能力它才能真正从一台独立家电升级为分布式供水网络里的一个标准节点。这也是为什么我会把文章重点放在数据链路和控制逻辑上而不是去详细推演制冷循环。对于开发者来说这个场景足够复杂包含传感器采集、实时控制、网络通信、云端存储、数据分析等多个环节但又比工业级项目容易上手。你可以用一块几十块钱的开发板、几个传感器和一个继电器模块先跑通最小闭环再逐步扩展。2. 核心原理露点、相对湿度与产水潜力要把空气制水系统做成一个可工程化的设备首先要理解一个基本问题空气到底能“挤”出多少水这涉及两个关键的物理量相对湿度与露点。相对湿度描述的是空气中水蒸气含量相对于同温度下饱和水蒸气含量的比例。露点温度则是空气中水蒸气开始凝结成液态水的温度。当冷表面温度低于露点时空气中的水蒸气就会在冷表面凝结形成水滴。空气制水系统的基本原理就是让空气流过一个低温表面把表面温度控制在露点以下从而收集凝结水。决定产水潜力的首要因素不是温度而是“绝对湿度”也就是单位体积空气中实际含有多少克水蒸气。夏季高湿环境下每立方米空气中可能含有几十克水而冬季干燥环境下可能只有几克。这就是为什么空气制水设备在不同地区产水能力差异会非常大。低温干燥地区直接使用冷凝式空气制水单位电耗会急剧上升甚至可能因为冷表面结霜而无法工作。我们可以用工程近似公式来定量估算。饱和水汽压与温度的关系通常用 Magnus 公式近似露点温度也可以通过类似公式反推。下面这段 Python 代码可以同时计算露点和绝对湿度如果你在考虑项目选址可以用它快速评估这个地区到底适不适合空气制水。# 文件路径humidity_calc.py import math def calc_dew_point(temp_c, rh): 基于 Magnus 公式的露点温度近似计算。 temp_c: 空气温度单位摄氏度 rh: 相对湿度单位 % 返回露点温度单位摄氏度 a, b 17.625, 243.04 gamma math.log(rh / 100.0) (a * temp_c) / (b temp_c) dew_point (b * gamma) / (a - gamma) return dew_point def calc_absolute_humidity(temp_c, rh): 计算绝对湿度即单位体积空气中的水蒸气质量单位 g/m³。 es 6.1078 * math.exp((17.27 * temp_c) / (temp_c 237.3)) e es * (rh / 100.0) ah 216.7 * e / (temp_c 273.15) return ah if __name__ __main__: temp 30.0 rh 70.0 dew_point calc_dew_point(temp, rh) ah calc_absolute_humidity(temp, rh) print(f温度 {temp}°C相对湿度 {rh}%) print(f露点温度: {dew_point:.1f}°C) print(f绝对湿度: {ah:.1f} g/m³)运行结果会根据你输入的环境参数变化。以 30°C、70% 相对湿度为例露点通常会落在 23°C 到 25°C 之间绝对湿度大约在 20 g/m³ 以上。这意味着如果制冷表面温度远低于露点并且有足够的风量流过理论上是有可能收集到可观水量的。但要注意绝对湿度只是理论上限实际产水量还取决于多个因素空气流量越大与冷表面接触的水蒸气越多冷表面温度越低凝结效率越高但更低温度意味着更高功耗同时可能引发结霜。典型的空气制水系统需要在制冷功率、风量和目标产水量之间做平衡而不是简单追求“越冷越好”。从工程判断来看空气制水系统最适合的部署环境是温暖高湿地区或者有补湿条件的封闭空间。在干燥寒冷地区更稳妥的方案是优先考虑其他水源或者采用吸附式空气取水、除湿转轮等不同技术路线而不是直接套用冷凝式方案。3. 分布式供水架构下的技术分层把空气制水系统当成分布式基础设施的一部分就不能再按“家电”的逻辑来设计。家电只需要本地按键和简单指示灯基础设施节点需要远程监控、自动保护、数据留痕和可维护性。因此我建议先把它拆成分层架构每一层只负责自己的边界方便后期独立升级和故障定位。设备与感知层包括制冷模块、冷凝水收集盘、多级过滤、储水箱、消毒模块以及温湿度传感器、液位传感器、TDS总溶解固体水质传感器、水箱温度传感器等。这一层的核心任务是“产生数据”。没有数据上层一切都是空谈。控制层通常是一块 MCU 开发板负责周期读取传感器数据并根据预设规则控制继电器进而启停半导体制冷片或者压缩机、风机、UV 紫外灯、水泵等负载。控制层必须内置保护逻辑比如水箱溢出保护、制冷模块过热保护、异常断电后的恢复策略。网络层负责把设备数据传到远端。在节点相对密集、供电充足的地方Wi-Fi 是最省事的方案在偏远且分散的地方4G 或 LoRa 更适合。网络层需要处理的不只是“把数据发出去”还包括本地缓存、断线重连、消息重发和轻量级安全认证。平台层包括 MQTT Broker、规则引擎、时序数据库和可视化面板。设备上报数据后平台层负责判断是否需要告警比如液位长时间不变化、温湿度急剧下降、TDS 异常升高这些都应该能触发通知。更高级的应用层则可以做产水效率预测、滤芯寿命预测和维护工单自动生成。从数据流来看一次完整的上报链路是传感器 - MCU 读取并封装成 JSON - MQTT 客户端发布到主题 - Broker 转发给规则引擎 - 规则引擎写入数据库 - 前端面板实时展示。如果从控制链路反向看则是用户或规则引擎发布命令 - Broker 推送给设备 - MCU 校验后操作继电器。理解了这条双向链路后面写代码时就不会把数据格式和控制逻辑混在一起。分层架构带来的最大好处是故障定位清晰。设备不上报先查网络层上报数据异常先查感知层继电器不动作先查控制层。这种可观测性恰恰是分布式供水基础设施最需要的东西。4. 最小系统传感器选型与数据采集搭建空气制水系统的最小原型不需要一开始就追求工业级精度。你可以先选择一块常见 Wi-Fi MCU 开发板搭配一个数字温湿度传感器、一个液位传感器、一个继电器模块和一个半导体制冷片。先把数据采集和远程上报跑通再逐步加入水质传感器和更复杂的控制逻辑。4.1 硬件连接下面是一组常见的接线方式仅供学习原型参考DHT22 温湿度传感器DATA 引脚接 MCU 的 GPIO4VCC 接 3.3VGND 接 GND。液位传感器OUT 引脚接 ADC 引脚例如 GPIO35。如果你用的是数字输出型浮球传感器则不需要 ADC。继电器模块IN 引脚接 GPIO2用于控制半导体制冷片的电源通断。半导体制冷片必须通过继电器和外部 12V 电源供电不能直接用开发板供电。12V 风扇与制冷片并联或单独控制注意电流总和不能超过电源额定范围。这里最容易踩坑的是电源问题。半导体制冷片工作电流通常很大如果从开发板取电轻则电压跌落导致复位重则烧毁板载稳压器。所以务必把功率电路和信号电路分开供电继电器至少要做到物理隔离。此外DHT22 的数据线如果较长建议在 DATA 和 VCC 之间加一个 4.7kΩ 到 10kΩ 的上拉电阻否则可能读不到稳定数据。4.2 数据采集示例代码下面这段 MicroPython 代码实现的是周期读取传感器数据并把结果打印成 JSON 格式。这里使用 DHT22 作为温湿度传感器液位传感器接在 ADC 引脚上返回原始 ADC 数值。# 文件路径main.pyMicroPython 示例 from machine import Pin, ADC import dht import time import ujson sensor_dht dht.DHT22(Pin(4)) adc_level ADC(Pin(35)) adc_level.atten(ADC.ATTN_11DB) def read_sensor(): # DHT22 每次测量后需要间隔至少 2 秒 sensor_dht.measure() temp sensor_dht.temperature() humi sensor_dht.humidity() level_raw adc_level.read() return { device_id: awg-001, temperature: temp, humidity: humi, tank_level_raw: level_raw, ts: time.time() } while True: payload read_sensor() print(ujson.dumps(payload)) time.sleep(30)这段代码里有两个细节值得注意。第一tank_level_raw是 ADC 原始值不代表实际水位百分比。要在真实项目中把它转换成百分比需要先做两点校准空箱时记录一个值满箱时记录另一个值然后做线性映射。第二DHT22 的测量间隔不能太短代码里用 30 秒作为上报周期既符合传感器要求也不会让 MQTT 消息过于频繁。运行这段代码后通过串口监视器应当能看到类似下面的输出。实际数值取决于当前环境。{device_id: awg-001, temperature: 28.5, humidity: 67.3, tank_level_raw: 1280, ts: 1710000000}如果输出乱码或者长时间没有输出先检查串口波特率是否匹配再检查 DHT22 接线和上拉电阻。只要这一步能稳定读到数据后续的控制和联网就有基础了。5. 边缘控制逻辑从冷凝到净化的自动控制数据采集只是第一步空气制水设备必须有控制逻辑。控制逻辑可以很简单也可以做成带状态机的复杂流程。最小的可用版本至少需要解决几个问题什么时候启动制冷、什么时候停止制冷、什么时候开启 UV 消毒、什么时候进入保护状态。一个比较直观的控制策略是根据环境温湿度和水箱液位决定是否制水。湿度太低时启动制冷产水效率会非常差白白耗电水箱液位接近满时继续制冷会导致溢水。与此同时还要加上温度保护避免极端高温或低温导致设备损坏。下面这段 MicroPython 示例实现了一个简化控制逻辑把制冷片和 UV 灯绑定在一起满足条件时同时开启不满足时同时关闭。水泵在自动模式下不轻易启动避免因为误操作把没有处理的水排到储水区。# 文件路径control.pyMicroPython 示例 from machine import Pin import time import dht RELAY_COLD Pin(2, Pin.OUT) RELAY_UV Pin(16, Pin.OUT) def should_produce(temp, humi, tank_ratio): # 温度处于可工作区间 temp_ok 15 temp 45 # 湿度足够高避免低效运行 humi_ok humi 40 # 水箱未满 tank_ok tank_ratio 90 return temp_ok and humi_ok and tank_ok def run_control_loop(): sensor_dht dht.DHT22(Pin(4)) while True: sensor_dht.measure() temp sensor_dht.temperature() humi sensor_dht.humidity() # 这里假设 tank_ratio 由一个 ADC 转换函数得到 tank_ratio 50.0 if should_produce(temp, humi, tank_ratio): RELAY_COLD.on() RELAY_UV.on() else: RELAY_COLD.off() RELAY_UV.off() time.sleep(10) if __name__ __main__: run_control_loop()这个示例没有写入 ADC 转换函数因为真实项目中需要根据液位传感器类型做一次校准。你可以在前面read_sensor()函数的基础上把tank_level_raw映射为 0 到 100 的百分比再传入should_produce()。从工程角度看这个逻辑还有两个明显问题一是没有“滞回”概念温湿度在阈值附近波动时继电器会频繁启停严重影响寿命二是没有“最小运行保护时间”制冷片刚运行十几秒就被关掉既浪费前期冷却又容易损坏压缩机或半导体模块。实际项目中建议记录上次启动时间只有距离上次启动超过一定时间才允许再次切换状态。另一个容易被忽略的点是 UV 灯的控制。UV 灯本身有寿命频繁开关会降低寿命。更好的做法是制水过程中持续开启 UV制水停止后保持一段时间再关闭确保收集到的冷凝水有一定的杀菌时间。这个逻辑可以根据项目需求拆成独立状态而不是和制冷片完全绑定。边缘控制的意义在于即使网络断开设备仍然能自主保护。不要把所有决策都放到云端。网络不稳定时云端指令可能迟到设备必须依靠本地逻辑先判断能不能开机、能不能停机。6. 数据上报与云端监控用 MQTT 接入平台要让设备成为分布式供水网络中的节点还需要把本地的结构化数据上报到云端。MQTT 是物联网场景中最常见的消息协议非常契合这种小流量、低频次、需要远程控制的场景。它有发布/订阅机制设备只需要往某个主题发布消息平台端订阅该主题即可设备不需要知道平台端的 IP 和端口耦合度更低。在 MQTT 主题设计上我建议用层级结构区分不同设备和数据类型例如awg/{device_id}/telemetry用于上报传感器数据awg/{device_id}/command用于下发控制指令awg/{device_id}/event用于上报设备事件和维护日志这种设计在未来扩容时很有用。新增一台设备只需要替换 device_id不需要改动 Broker 和规则引擎的主题匹配逻辑。下面这段 MicroPython 示例演示了如何把 JSON 消息发布到 MQTT 主题。这里假设你已经安装了umqtt.simple库并把BROKER_HOST替换成自己的 MQTT Broker 地址。# 文件路径mqtt_report.pyMicroPython 示例 from umqtt.simple import MQTTClient import ujson import time CLIENT_ID awg-001 BROKER_HOST 192.168.1.100 BROKER_PORT 1883 TOPIC_TELEMETRY bawg/awg-001/telemetry def build_payload(temp, humi, tank_ratio): return { device_id: CLIENT_ID, temperature: temp, humidity: humi, tank_level_percent: tank_ratio, ts: time.time() } client MQTTClient(CLIENT_ID, BROKER_HOST, portBROKER_PORT, keepalive60) client.connect() payload build_payload(28.5, 67.3, 42.0) client.publish(TOPIC_TELEMETRY, ujson.dumps(payload).encode()) client.disconnect()通过 MQTT 上报后我们可以用命令行工具订阅同一个主题来验证数据是否到达。如果使用 mosquitto 客户端可以这样订阅mosquitto_sub -h 192.168.1.100 -p 1883 -t awg/awg-001/telemetry -v如果看到类似下面的输出说明端到端链路已经打通awg/awg-001/telemetry {device_id: awg-001, temperature: 28.5, humidity: 67.3, tank_level_percent: 42.0, ts: 1710000000}这里必须提醒一个安全问题生产环境不建议使用明文 1883 端口传输真实数据至少要启用 TLS并在设备端配置客户端证书。如果设备分布在公共网络还要在 Broker 上启用访问控制只允许特定客户端 ID 订阅和发布特定主题。最小权限原则同样适用于供水设备一台设备不应该能控制另一台设备的继电器。MQTT 解决了传输问题但监控系统还需要存储和历史查询能力。常见做法是让规则引擎订阅telemetry主题然后把数据写入时序数据库比如 InfluxDB、TDengine 或简单的 PostgreSQL。分布式供水节点数量不大时直接用关系型数据库也能扛住。7. 产水效率分析与运维预测当设备开始上报历史数据后最有趣的部分就来了如何用数据判断设备是否健康并预测产水量。在理想情况下我们可以根据进风温湿度、出风温湿度、空气流量和运行时间估算理论产水量。但在实际项目中出风温湿度传感器不一定每台设备都装齐冷凝效率也会随风道积灰、制冷片老化而变化。因此更实用的做法是先记录一段时间内的“产水量 环境温湿度 制冷能耗”数据用简单的回归模型拟合出这台设备的经验产水曲线再用后续新数据判断偏差。在还没有真实产水量数据时可以先计算环境中的理论产水潜力也就是单位体积空气里的绝对湿度。下面这段 Python 代码演示了如何把前面算出来的绝对湿度应用到一个简化产水估算公式中。这个公式当然不是精确模型但作为评估部署收益的参考已经足够。# 文件路径estimate_yield.py import math def absolute_humidity(temp_c, rh): es 6.1078 * math.exp((17.27 * temp_c) / (temp_c 237.3)) e es * (rh / 100.0) return 216.7 * e / (temp_c 273.15) def estimate_yield(air_flow_m3h, humidity_in, humidity_out, run_hours, efficiency0.5): air_flow_m3h: 进风风量单位 m³/h humidity_in: 进风绝对湿度单位 g/m³ humidity_out: 出风绝对湿度单位 g/m³ run_hours: 运行时长单位 h efficiency: 冷凝效率取值范围 0~1 delta max(0, humidity_in - humidity_out) mass air_flow_m3h * delta * run_hours * efficiency / 1000.0 return mass temp 30.0 rh 70.0 h_in absolute_humidity(temp, rh) h_out absolute_humidity(temp - 15.0, 100.0) # 假设出风接近饱和且温度降低 15 度 yield_kg estimate_yield(air_flow_m3h200.0, humidity_inh_in, humidity_outh_out, run_hours10.0, efficiency0.5) print(f进风绝对湿度: {h_in:.1f} g/m³) print(f理论每小时可处理空气量: 200 m³/h) print(f估算单日产水量: {yield_kg:.1f} L)这个代码里有一个重要假设出风绝对湿度按“温度降低 15 度且接近饱和”来计算。实际设备运行时出风是否接近饱和取决于换热面积和风速。如果设备没有安装出风温湿度传感器这个值只能靠经验标定。所以我建议你在部署现场先做一次标定实验记录一个修正系数而不是直接使用默认效率 0.5。有了产水估算值之后可以把它和实际水箱液位变化做对比。如果实际产水明显低于估算值可能的故障原因包括空气滤网堵塞、冷表面结霜、风机转速下降、制冷系统能力衰减。把这些异常判断固化到平台规则里就能实现比固定阈值告警更智能的预测性维护。更完整的做法是把历史数据采集到一个 CSV 文件然后用 Python 分析。下面是一个简单的读取示例假设 MQTT 接收端已经把数据保存为awg_telemetry.csv包含temperature、humidity、tank_level_percent等列。# 文件路径analyze_history.py import csv from humidity_calc import calc_absolute_humidity with open(awg_telemetry.csv, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: temp float(row[temperature]) rh float(row[humidity]) ah calc_absolute_humidity(temp, rh) print(f{row[ts]}: temp{temp:.1f}°C, rh{rh:.1f}%, ah{ah:.1f} g/m³)这段代码把历史记录里的每条温湿度数据换算为绝对湿度。如果你发现某台设备的ah一直不低但实际水箱液位不涨问题大概率在风道、制冷系统或液位传感器。数据分析的目的不是准确预测而是快速缩小故障范围。8. 常见问题与排查思路空气制水系统涉及机械、电气、水质、网络等多方面内容出了问题排查范围相对大。下面表格列出一些常见问题和排查方向便于现场快速判断。问题现象可能原因排查方式解决方案设备一直不进入制水状态环境湿度低于控制阈值查看本地日志中温湿度调整控制阈值或增加辅助加湿制冷开启但水箱液位不涨风道堵塞或集水盘漏水检查风道、集水盘和排水管清理风道重新固定集水盘水质 TDS 偏高过滤模块失效或水箱污染采样检测水质查看 TDS 传感器读数更换滤芯清洗并消毒水箱数据无法上报MQTT Broker 地址或主题错误用 mosquitto_sub 订阅主题检查设备网络和 Broker 配置设备能发数据但收不到控制指令设备未订阅 command 主题检查订阅回调日志增加命令主题订阅和回调处理继电器频繁通断控制逻辑缺少滞回或保护时间查看状态切换时间戳增加温度死区和最小运行时间半导体制冷片过热散热风扇故障或散热器面积不足测量散热器表面温度更换风扇增大散热面积网络不稳定时本地动作异常设备没有本地缓存和恢复逻辑模拟断网测试增加本地存储和断网恢复策略以上这些问题是原型阶段最容易碰到的。其中“继电器频繁通断”和“水质 TDS 偏高”最容易被忽视但它们在长周期运行中危害最大。继电器频繁通断会缩短功率器件寿命水质 TDS 偏高则直接关系使用安全发现问题后应优先处理。9. 工程最佳实践安全、节能、合规与可维护性无论空气制水系统做得多智能它本质上是“水电器”一体的设备。安全边界必须放在第一位。电气安全方面功率电路与信号电路必须隔离。半导体制冷片或压缩机的启动电流通常远大于 MCU 引脚能承受的电流必须通过继电器、MOSFET 或固态继电器驱动。供电线路上要加保险丝外壳要做好接地。水可能溅射到电路板的区域还要增加防水挡板和密封处理。水质安全方面冷凝水直接来自空气空中的灰尘、微生物、可挥发性污染物都有可能溶解或混入其中。因此冷凝水不能默认是干净饮用水。工程上至少需要多级过滤、UV 杀菌和必要的矿物调整。每次维护后要记录滤芯更换时间和水质检测结果。如果设备部署在工业区或空气质量较差的区域还需要评估进风过滤方案。对于“空气制水后能不能喝”这个问题必须以当地检测标准和设备实际净化能力为准不要在没有验证的前提下宣传直饮。节能设计方面空气制水系统的单位产水能耗通常高于传统供水所以更需要降低无效运行。可以基于本地预测模型提前判断未来几小时的产水潜力自动调整制冷功率。例如夜间气温下降、湿度升高时可以适当提高运行时长白天高温低湿时可以减少制冷输出。这样做还能避免水箱溢出减少水泵频繁启动。可维护性方面建议把传感器设计成可插拔模块并给每个结构件保留维护空间。水箱、过滤芯、集水盘都需要定期清洗如果结构上不方便拆装再智能的设备也会因为维护成本过高而被弃用。数据层面设备应支持本地日志缓存比如写到 SD 卡或 Flash网络恢复后再补传避免网络抖动导致数据断档。合规方面不同地区对分布式供水和再生水设备可能有不同要求。部署前应了解当地关于饮用水卫生、水质检验、电器安全等方面的规定而不是只关注技术指标。文章不涉及具体政策但这个环节在你的实际项目中不能跳过。10. 总结与后续学习方向空气制水系统作为分布式供水基础设施中的一个节点真正的难点不是把空气变成水而是让分散的设备变成可靠的网络化服务。一台不能远程感知、不能自动保护、不能数据留痕的空气制水机本质上还是一台除湿机只有当它接入数据链路、具备预测和维护能力才能承担基础设施的角色。如果你准备动手实践建议不要一上来就追求完整产水能力。最稳妥的路径是先搭一块开发板接上温湿度传感器和液位传感器用 MQTT 上报数据到本机 broker第二步加入继电器控制让设备根据温湿度自动开关制冷负载第三步把历史数据落库用 Python 对比估算产水量和实际液位变化。走完这三步你已经把空气制水系统里最核心的数据闭环跑通了。后续可以继续深入的方向包括设备影子与远程参数下发、基于历史数据的产水量预测模型、多设备集中管理面板、断网本地优先控制策略以及更精细的水质在线检测。对于同一个技术团队来说这个场景能锻炼到的能力非常综合从嵌入式到后端、从数据分析到运维都有足够多值得实践的地方。先从一条能上报的数据链路开始比什么都重要。
