企业官网建设流程全解析

1. 项目缘起与整体设计思路

1.1 这个系统到底在解决什么问题

先说说我做这个项目的出发点。身边不少朋友初为父母，夜里最头疼的事情就是反复起身查看宝宝的状态——被子有没有捂住口鼻、睡姿是不是趴着、房间温度湿度是否合适、有没有突然惊醒哭闹。市面上确实有一些婴儿监视器，但大多数要么只是单纯的摄像头加对讲，要么就是靠一个简单的麦克风做声音触发，误报率高得离谱，半夜被吵醒一看宝宝睡得好好的，那种崩溃感相信很多家长都懂。

我想要的是一套真正能“看懂”和“听懂”宝宝状态的系统。所谓多模态，就是把视觉、听觉、环境传感这几路信息融合在一起做综合判断，而不是单靠某一路信号就下结论。视觉负责看姿态、看覆盖物、看是否有人进入危险区域；听觉负责识别哭声、咳嗽、异常响动；环境传感器负责监测温湿度、光照、空气质量。三路信息交叉验证之后，误报率能压下来一大截。

硬件平台我选了RK3588这颗芯片，原因后面会详细讲。整套系统跑在本地边缘端，不依赖云端推理，隐私性好，响应也快。适合谁来参考呢？我觉得有三类人：一是想做嵌入式AI项目但不知道从哪下手的开发者；二是对多模态融合感兴趣、想找个完整案例练手的学生或工程师；三是家里有宝宝、自己又懂点技术、想折腾一套定制化监测方案的家长。哪怕你只是对RK3588的NPU怎么用感兴趣，这个项目里的很多细节也能直接拿去用。

1.2 为什么选RK3588而不是别的方案

选主控芯片这件事我纠结了挺久。一开始考虑过用树莓派加一个USB加速棒，也想过用Jetson Nano。最后定在RK3588，核心原因有三个。

第一是算力够用且接口丰富。RK3588是八核架构，四核A76加四核A55，内置的NPU算力标称6TOPS，跑个轻量级的姿态估计模型和目标检测模型完全不在话下。更关键的是它原生支持多路摄像头输入，MIPI CSI接口有好几路，我可以同时接一个广角摄像头看全景、一个近红外摄像头看暗光下的细节，不用额外加采集卡。

第二是编解码能力强。婴儿监测需要长时间录像，如果全靠CPU软编码，功耗和发热都受不了。RK3588自带VPU，支持H.264/H.265硬编码，我可以把视频流压缩后再存本地或者推流，CPU占用率能降一大截。

第三是功耗和成本平衡得好。Jetson Nano算力也不错，但功耗偏高，长时间运行散热是个问题，而且价格波动大。RK3588的整板方案在功耗控制上更友好，适合7x24小时常开。

这里插一句，选型的时候一定要想清楚你的模型规模。如果你打算跑很大的Transformer模型，那RK3588的NPU可能吃不下，得考虑更高阶的方案。但婴儿监测这个场景，姿态估计用轻量级的MoveNet或者自己裁剪的MobileNet骨干网络就够了，检测任务用YOLOv5s级别的模型也完全跑得动。所以算力是匹配的，没有过度设计。

1.3 多模态融合的架构怎么搭

整体架构我分成了四层，从下往上分别是感知层、预处理层、推理层和决策层。

感知层就是各种传感器和摄像头。视觉这块我用了两路：一路RGB摄像头负责白天和光线充足时的监测，一路红外摄像头配合红外补光灯负责夜间。听觉用一个MEMS麦克风阵列，之所以用阵列而不是单麦克风，是为了后续做声源定位，能判断哭声大概来自哪个方向。环境传感器我选了温湿度传感器、光照传感器和一个简易的空气质量传感器，通过I2C和UART接入。

预处理层负责把原始数据整理成模型能吃的格式。视频流要抽帧、缩放、归一化；音频流要做分帧、加窗、提取梅尔频谱特征；传感器数据要做滤波和平滑，去掉毛刺。这一层看起来不起眼，但实际上决定了后面推理的稳定性。我踩过的坑里有一大半都出在预处理没做好。

推理层就是各个模型各司其职。视觉这边跑两个模型，一个做人体检测和姿态估计，判断宝宝的位置和睡姿；另一个做区域分割，判断口鼻区域是否被遮挡。听觉这边跑一个声音分类模型，区分哭声、咳嗽、正常呼吸声和环境噪声。这些模型都通过RKNN工具链转换后在NPU上运行。

决策层是整套系统的大脑。它接收推理层的输出，做时序上的平滑和逻辑上的融合。比如视觉判断宝宝趴着，同时听觉检测到哭声，环境传感器显示温度偏高，那系统就会判定为高风险状态，触发告警。如果只是视觉判断趴着但其他信号都正常，那可能只是宝宝翻了个身，告警级别就低一些。这种多信号交叉验证的思路，是降低误报的关键。

2. 核心细节解析与实操要点

2.1 视觉模块：姿态估计与遮挡检测怎么做

视觉模块是整个系统里最复杂的部分，我拆成两个任务来讲。

第一个任务是人体检测和姿态估计。我用的方案是先跑一个轻量级的人体检测模型把宝宝框出来，再在框内跑姿态估计。为什么要两步走而不是直接端到端？因为直接在全图上跑姿态估计，背景干扰太大，床上用品、玩具都可能被误识别成关节。先检测再估计，准确率明显更高。检测模型我选了YOLOv5s的裁剪版，输入分辨率降到320x320，在RK3588的NPU上单帧推理能跑到30毫秒以内。姿态估计用的是MoveNet的轻量版，输出17个关键点，足够判断仰卧、侧卧、俯卧这几种基本姿态。

判断睡姿的逻辑是这样的：取双肩和双髋这四个关键点，计算肩髋连线的夹角。如果双肩连线与双髋连线近似平行且都在画面中轴附近，判定为仰卧；如果一侧肩髋明显高于另一侧，判定为侧卧；如果头部关键点低于肩部且面部朝向画面下方，判定为俯卧。这里要注意，关键点本身会有抖动，所以我在时序上做了一个滑动窗口的投票机制，连续15帧里超过10帧判定为同一姿态才最终确认，避免宝宝动一下就被误判。

第二个任务是遮挡检测，这个更关键。我的做法是在检测到宝宝面部区域后，单独裁剪出面部ROI，然后跑一个轻量级的分割模型，判断口鼻区域是否被被子、枕头或者衣物覆盖。分割模型我用的是基于MobileNetV3骨干的DeepLabV3简化版，输出一个二值掩码。如果掩码显示口鼻区域被非皮肤类物体覆盖超过一定面积比例，就触发遮挡告警。

注意：遮挡检测最容易出的问题是把宝宝的自己的手或者安抚奶嘴误判为遮挡物。我的处理办法是在训练数据里大量加入这些负样本，同时在逻辑上做一个判断——如果覆盖物区域与手部关键点的距离很近，就降低告警级别，先观察几帧再说。

实操中还有一个细节：红外摄像头在夜间拍摄时，画面是灰度的，而且红外补光灯会在宝宝眼睛上形成反光点。如果不处理，这些反光点会被误认为是高亮区域，影响分割。我的做法是在预处理阶段加一个自适应阈值处理，把过亮的像素点先抑制掉，再做后续推理。

2.2 听觉模块：哭声识别与异常声音分类

音频这块我踩的坑比视觉还多。最开始我直接用麦克风采集原始波形丢给模型，结果发现环境噪声一大，识别率就崩了。后来改成先提取梅尔频谱特征，再送给一个轻量级的CNN分类器，效果稳定了很多。

具体流程是这样的：麦克风以16kHz采样率采集音频，每帧取1秒的长度，帧与帧之间重叠0.5秒，保证不会漏掉短促的哭声。然后对每帧做预加重、分帧、加汉明窗，再做FFT得到频谱，最后通过梅尔滤波器组得到梅尔频谱图。这个频谱图就是模型的输入，尺寸我设成64x64，既能保留足够的信息，又不会让模型太大。

分类模型我设计了五个类别：哭声、咳嗽、正常呼吸声、环境噪声、静音。模型结构很简单，三个卷积块加两个全连接层，参数量控制在50万以内，在NPU上跑一次不到10毫秒。训练数据一部分来自公开的婴儿哭声数据集，一部分是我自己录的（当然是用玩具发出的声音模拟的，不可能真去录别人家宝宝）。

这里有个经验值得分享：哭声识别最大的难点不是区分哭声和静音，而是区分哭声和环境中的高频噪声，比如吸尘器、吹风机、水龙头的声音。这些噪声在梅尔频谱上的表现和哭声有相似之处。我的解决办法是在训练时做数据增强，把各种环境噪声以不同信噪比混入哭声样本中，让模型学会在噪声中找哭声。实测下来，加了噪声增强之后，误报率从每小时好几次降到了每天一两次。

另外，我还加了一个简单的声源定位逻辑。麦克风阵列有四个麦克风，通过计算声音到达不同麦克风的时间差，可以粗略估计声源方向。如果哭声来自宝宝所在区域，告警级别高；如果来自房间外，就只记录不告警。这个逻辑虽然简单，但很实用，能过滤掉不少房间外的干扰。

2.3 环境传感器：数据采集与融合策略

环境传感器这块相对简单，但也不能马虎。我用了三类传感器：温湿度传感器走I2C接口，光照传感器走I2C，空气质量传感器走UART。

温湿度我设定的舒适区间是温度22到26摄氏度，湿度40%到60%。超出这个区间就记录并提示。光照传感器主要用来判断白天还是夜间，辅助切换摄像头模式——光照低于一定阈值就切到红外摄像头。空气质量传感器监测CO2和TVOC浓度，浓度过高说明房间通风不好，提示开窗通风。

传感器数据最大的问题是噪声和漂移。温湿度传感器读数会有小幅波动，如果直接拿原始值做判断，会频繁触发告警。我的做法是做一个滑动平均滤波，窗口大小设为30个采样点，采样间隔10秒，相当于5分钟的平滑。这样既能反映真实趋势，又不会被瞬时波动干扰。

多传感器融合的策略我采用的是加权投票加规则引擎。每个传感器输出一个状态值，比如温度正常/偏高/偏低，湿度正常/偏干/偏湿。然后规则引擎根据这些状态组合做判断。比如温度偏高且湿度偏低，可能是空调开太猛了，提示调整；温度正常但CO2偏高，提示通风。规则引擎的好处是逻辑透明，容易调试，不像神经网络那样是个黑盒。

提示：传感器选型时一定要注意接口电平匹配。RK3588的IO电平是1.8V和3.3V可配置的，但有些传感器是5V电平，直接接上去可能烧掉。我一开始就因为这个烧了一个温湿度传感器，后来加了电平转换模块才搞定。

2.4 模型转换与NPU部署的关键步骤

RK3588的NPU不是直接吃ONNX或者PyTorch模型的，需要用RKNN工具链做转换。这一步是整个项目里最考验耐心的环节，我详细说一下。

首先是在PC端训练好模型，导出成ONNX格式。导出的时候要注意，有些算子RKNN不支持，比如某些自定义的激活函数或者特殊的reshape操作。我的经验是尽量用标准算子，如果非要用特殊算子，就在导出前把它替换成等价的组合。比如Swish激活函数，如果RKNN不支持，可以替换成SiLU或者直接用ReLU加一个缩放。

然后是量化。RKNN支持FP16和INT8两种量化方式。FP16精度高但速度慢一些，INT8速度快但会有精度损失。我的做法是视觉模型用INT8量化，因为对速度要求高；音频模型用FP16，因为音频特征对精度更敏感。量化的时候需要提供校准数据集，我一般从训练集里随机抽200到500张图或者音频帧做校准。校准集的选择很关键，要覆盖各种场景，否则量化后的模型在某些场景下会崩。

转换命令大概长这样：

python3 rknn_convert.py \ --model_path ./model.onnx \ --dataset ./calibration_dataset.txt \ --output_path ./model.rknn \ --target_platform rk3588 \ --quantize_dtype int8

转换完成后，在板子上用RKNN Runtime加载模型。这里要注意内存管理，RK3588的NPU内存是有限的，如果同时加载太多模型会报错。我的做法是按需加载，视觉模型常驻，音频模型和分割模型交替加载，用完就释放。

还有一个坑是输入输出的维度顺序。ONNX的默认是NCHW，但RKNN有时候会期望NHWC。转换的时候要仔细核对，不然推理结果会完全错乱。我一开始没注意这个，调了两天才发现是维度顺序搞反了。

3. 实操过程与核心环节实现

3.1 硬件搭建与系统烧录

硬件清单我先列一下，方便你照着准备：

接线的时候注意几点：MIPI CSI排线很脆弱，插拔的时候要轻，卡扣要扣紧，否则接触不良会导致摄像头时好时坏。I2C设备要接上拉电阻，一般开发板上已经集成了，但如果你外接的传感器多，可能需要额外加上拉。麦克风阵列的I2S时钟线要尽量短，避免干扰。

系统烧录我用的是官方提供的镜像，基于Ubuntu 20.04。烧录工具用RKDevTool，把镜像写到eMMC或者SD卡上。烧录完成后第一次启动会比较慢，因为要初始化文件系统。启动后先更新系统，装好必要的依赖库，包括OpenCV、FFmpeg、RKNN Toolkit Lite等。

sudo apt update && sudo apt upgrade -y sudo apt install -y python3-pip python3-opencv ffmpeg cmake build-essential pip3 install rknn-toolkit-lite2 numpy scipy

装OpenCV的时候要注意，最好用系统包管理器装的版本，自己编译的话容易和RKNN的库冲突。如果非要用特定版本的OpenCV，建议用虚拟环境隔离。

3.2 视频采集与预处理流水线

视频采集我用的是V4L2接口，OpenCV的VideoCapture可以直接调用。但有个细节要注意，RK3588的MIPI摄像头在OpenCV里默认可能走的是软解码，CPU占用很高。我的做法是用GStreamer管道来采集，利用硬件解码。

import cv2 # 用GStreamer管道采集，走硬件解码 pipeline = ( "v4l2src device=/dev/video0 ! " "video/x-raw,width=1920,height=1080,framerate=30/1 ! " "videoconvert ! appsink" ) cap = cv2.VideoCapture(pipeline, cv2.CAP_GSTREAMER)

采集到的帧先做缩放，从1080P降到640x640，因为模型输入就这个尺寸，提前缩放能省不少算力。缩放用OpenCV的resize就行，插值方式选INTER_LINEAR，速度和质量的平衡比较好。

然后是归一化，把像素值从0到255映射到0到1。这里要注意，有些模型期望的是ImageNet的均值和方差归一化，有些期望的是简单的除以255。一定要看清楚模型训练时用的是什么方式，不然推理结果会偏。

夜间模式切换的逻辑是这样的：光照传感器读数低于50lux时，切换到红外摄像头，同时打开红外补光灯。红外摄像头出来的画面是灰度的，需要复制成三通道再送给模型，因为模型输入是三通道的。这个复制操作看起来多余，但如果不做，模型会报错。

注意：红外补光灯的亮度要可调，太亮会刺眼，太暗又看不清。我一开始用的是固定亮度的补光灯，后来换成了PWM调光的，根据环境光照自动调整亮度，效果好很多。

3.3 模型推理与结果后处理

模型推理这块，我用的是RKNN Toolkit Lite的Python接口。加载模型、初始化运行时、设置输入输出，这几步是固定的。

from rknnlite.api import RKNNLite rknn = RKNNLite() rknn.load_rknn('./pose_model.rknn') rknn.init_runtime(core_mask=RKNNLite.NPU_CORE_0) # 推理 outputs = rknn.inference(inputs=[input_data])

这里有个性能优化的点：RK3588有三个NPU核心，可以并行跑不同的模型。我把姿态估计模型放在核心0，遮挡分割模型放在核心1，音频模型放在核心2，三个模型同时跑，互不干扰。这样整体延迟能控制在100毫秒以内，满足实时性要求。

后处理这块，姿态估计的输出是17个关键点的坐标和置信度。置信度低于阈值的点要丢弃，然后用剩下的点做姿态判断。遮挡分割的输出是一个掩码图，要做二值化，然后计算口鼻区域被覆盖的比例。

后处理里最容易出问题的是坐标映射。模型输入的640x640图像是从原始1080P图像缩放来的，关键点坐标要映射回原始尺寸才能做后续的ROI裁剪。映射公式很简单，就是按比例缩放，但要注意缩放是等比的还是非等比的。如果原始图像不是正方形，缩放时做了padding，那映射的时候还要把padding去掉。我一开始就是忘了去padding，导致关键点位置整体偏移。

3.4 告警逻辑与通知机制

告警逻辑我设计了三档：提示、警告、紧急。

提示级别是环境参数轻微偏离舒适区，比如温度26.5度，略高于设定上限。这种只在日志里记录，不主动通知。

警告级别是检测到潜在风险，比如宝宝趴着睡但呼吸声正常，或者湿度低于35%。这种会通过手机推送一条通知，但不发出声音。

紧急级别是检测到明确危险，比如口鼻被遮挡超过10秒，或者哭声持续超过30秒且伴随异常姿态。这种会触发本地声光报警，同时推送高优先级通知，还会自动录制一段视频存证。

通知机制我用的是MQTT协议，板子作为客户端把告警消息发到本地的MQTT Broker，手机App订阅对应主题接收消息。为什么不用HTTP轮询？因为轮询有延迟，而且费电。MQTT是长连接，消息推送实时性更好。

import paho.mqtt.client as mqtt import json client = mqtt.Client() client.connect("localhost", 1883, 60) def send_alert(level, message): payload = { "level": level, "message": message, "timestamp": time.time() } client.publish("baby_monitor/alert", json.dumps(payload))

告警去重也很重要。如果宝宝持续趴着，不能每帧都发告警，那样手机要被轰炸。我的做法是设置一个冷却时间，同一类型的告警在5分钟内只发一次。如果状态升级了，比如从警告变成紧急，那可以立即发新的告警。

4. 常见问题与排查技巧实录

4.1 模型推理报错与精度异常排查

问题一：RKNN加载模型时报错“invalid model”。

这个错误一般是模型转换时出了问题。排查步骤：先检查ONNX模型本身能不能正常推理，用ONNX Runtime跑一下，确认模型没问题。然后检查RKNN转换时的日志，看有没有算子不支持的警告。如果有，就替换算子重新导出。还要检查RKNN Toolkit的版本和板子上Runtime的版本是否匹配，版本不一致也会报这个错。

问题二：推理结果全是乱码或者置信度极低。

最常见的原因是输入数据的预处理和训练时不一致。检查归一化方式、通道顺序、图像尺寸。我遇到过一次，训练时用的是BGR，推理时用了RGB，结果所有关键点都偏了。还有一个可能是量化校准集选得不好，导致量化后的模型精度崩了。解决办法是重新选校准集，覆盖更多场景。

问题三：NPU推理速度比预期慢很多。

先确认模型是不是真的跑在NPU上。可以在推理时查看CPU占用率，如果CPU占用很高，说明模型可能回退到CPU跑了。原因可能是某些算子NPU不支持，自动回退了。用RKNN Toolkit分析一下模型，看哪些层跑在NPU上，哪些跑在CPU上。如果关键层在CPU上，就要想办法替换算子。

4.2 摄像头与传感器常见故障处理

摄像头画面卡顿或者花屏，一般是排线接触不良或者带宽不够。先重新插拔排线，确认卡扣扣紧。如果还不行，降低分辨率或者帧率试试。MIPI CSI的带宽是有限的，同时跑两路1080P可能会超带宽，降到720P就正常了。

红外摄像头夜间画面过曝，是红外补光灯太亮或者摄像头光圈太大。解决办法是调低补光灯亮度，或者在摄像头前加一个红外滤光片。我用的是PWM调光，根据画面平均亮度自动调整，效果不错。

温湿度传感器读数跳变，一般是I2C总线干扰。检查I2C线是否过长，有没有和电源线捆在一起。如果线太长，加一个I2C缓冲器。软件上做滑动平均滤波也能缓解。

麦克风阵列采集不到声音，先检查I2S时钟是否正常。用示波器量一下时钟线，看有没有波形。如果没有，可能是设备树里I2S节点没配置对。RK3588的设备树配置比较绕，建议参考官方文档仔细核对。

4.3 系统稳定性与长时间运行优化

系统跑几个小时就卡死，最常见的原因是内存泄漏。Python里如果用OpenCV的VideoCapture没有及时释放，或者RKNN的推理结果没有释放，内存会慢慢涨上去。我的做法是定期重启采集线程，比如每12小时重启一次，释放所有资源。

散热也是个大问题。RK3588满载运行时发热不小，如果散热不好会降频，推理速度就下来了。我加了一个小风扇，配合散热片，核心温度能控制在60度以内。风扇的转速用PWM控制，温度低的时候低速转，噪音小。

日志管理也要注意。长时间运行会产生大量日志，把磁盘写满。我用了logrotate做日志轮转，每天切一次，保留最近7天。告警视频也设了上限，最多保留最近100条，超出的自动删除。

提示：建议加一个看门狗机制。用一个独立的线程定时检查各个模块的心跳，如果某个模块超过一定时间没响应，就重启整个系统。我用的是硬件看门狗加软件看门狗双重保护，实测下来连续运行一个月没出过问题。

4.4 常见问题速查表

5. 多模态融合的进阶优化思路

5.1 时序融合：让判断更连贯

单帧判断最大的问题是抖动。宝宝翻个身，可能连续几帧被判定为俯卧，但实际上只是过渡动作。我的解决办法是引入时序融合，不只看当前帧，而是看一个时间窗口内的综合表现。

具体做法是维护一个长度为30帧的队列，每帧的姿态判断结果入队。然后对队列做投票，如果超过60%的帧判定为俯卧，才最终确认。同时还要看姿态的持续时间，如果俯卧状态持续超过10秒，才升级为警告。这样能过滤掉绝大部分的过渡动作误报。

音频这边也类似，不是检测到一声哭声就告警，而是看一个5秒窗口内的哭声占比。如果占比超过50%，才判定为持续哭闹。如果只是偶尔一声，那可能只是宝宝在睡梦中哼唧了一下，不需要打扰。

5.2 跨模态验证：降低误报的关键

跨模态验证是我觉得这个项目里最有价值的设计。单靠视觉判断遮挡，容易被被子颜色和光照影响；单靠音频判断哭声，容易被环境噪声干扰。但两者结合起来，准确率就上来了。

举个例子：视觉检测到口鼻区域被覆盖，同时音频检测到哭声，这两个信号同时出现，那基本可以确定是危险情况，直接触发紧急告警。如果只有视觉检测到覆盖，但音频显示呼吸声正常，那可能是被子搭在脸上但没捂住口鼻，告警级别降为警告，先观察几秒。

再比如：视觉判断宝宝趴着，但音频显示呼吸平稳，环境传感器显示温湿度正常，那可能只是宝宝自己翻了个身，趴着睡而已，不需要过度反应。但如果趴着的同时哭声异常，或者呼吸声变得急促，那就要高度重视了。

这种交叉验证的逻辑，我是在规则引擎里实现的。每条规则就是一个if-then组合，比如“if 遮挡 and 哭声 then 紧急告警”。规则可以灵活调整，不需要重新训练模型。

5.3 个性化适配：让系统更懂你的宝宝

每个宝宝的习惯都不一样，有的宝宝睡觉爱动，有的宝宝安静。如果系统用一套固定参数，要么对爱动的宝宝误报太多，要么对安静的宝宝漏报。所以我加了一个个性化适配的机制。

系统运行第一周是学习期，记录宝宝的各种行为模式：平均每小时翻几次身、哭声的频率和时长分布、睡眠时的呼吸频率范围。一周之后，系统根据这些数据自动调整告警阈值。比如宝宝平时每小时翻5次身，那阈值就设成8次，超过才告警。如果宝宝平时很少哭，那哭声检测的灵敏度就调高一些。

这个适配机制我是用简单的统计方法实现的，没有用复杂的机器学习。因为数据量不大，而且可解释性很重要。家长需要知道系统为什么告警，而不是一个黑盒给个结果。

6. 项目扩展方向与个人体会

6.1 还能怎么扩展

这套系统的框架其实可以扩展到很多场景。比如把视觉模型换成跌倒检测，就可以用于老人监护；把音频模型换成异常声音检测，就可以用于家庭安防。核心的多模态融合逻辑是通用的，换的只是具体的模型和规则。

硬件上也可以升级。比如加一个毫米波雷达传感器，可以非接触地监测呼吸和心率，比摄像头更隐私，而且不受光线影响。雷达数据和视觉数据融合，能进一步提升监测精度。

软件上可以做一个手机App，把告警通知、视频回放、数据统计都集成进去。我现在用的是MQTT加简单的Web界面，功能比较简陋，但够用。如果想做得更完善，可以用Flutter或者React Native开发一个跨平台App。

6.2 我踩过的那些坑

最后分享几个我踩过的坑，希望能帮你省点时间。

第一个坑是低估了预处理的复杂度。我一开始觉得预处理就是缩放和归一化，很简单。结果实际做的时候，光是处理不同光照条件下的白平衡就花了好几天。后来我干脆在预处理里加了一个自动白平衡的步骤，用灰度世界算法做校正，效果立竿见影。

第二个坑是模型量化。我一开始为了追求速度，把所有模型都做了INT8量化，结果音频模型的精度掉得厉害，哭声识别率从95%降到了80%。后来改成音频用FP16，视觉用INT8，才找到平衡点。所以量化不是越激进越好，要根据任务特点来。

第三个坑是散热。我一开始觉得RK3588功耗不高，没加风扇。结果跑了一下午，板子烫得手都摸不得，推理速度直接减半。加了风扇之后，温度降了20多度，速度也恢复了。所以如果你打算长时间运行，散热一定要做好。

第四个坑是告警疲劳。系统刚跑起来的时候，我设的阈值太敏感，一晚上发了十几条告警，根本没法睡。后来加了时序融合和跨模态验证，告警数量降到了每天一两次，而且每次都是真的有情况。所以告警逻辑一定要反复调，宁可漏报也不能误报太多，不然用户会直接把系统关掉。

这套系统我断断续续做了大半年，从选型到调试到优化，中间推翻重来了好几次。但现在回头看，每一步踩的坑都是值得的。RK3588这颗芯片的潜力很大，NPU的算力对于边缘端的AI应用来说绰绰有余。多模态融合的思路也不局限于婴儿监测，任何需要综合判断的场景都可以借鉴。如果你也在做类似的项目，希望这些经验能帮你少走点弯路。