第四章 硬件产品系统架构设计
好，咱们今天聊聊硬件系统架构。说实话，很多AI产品经理一听到「架构」两个字就头大。我刚开始做智能硬件那会儿也一样，总觉得这是硬件工程师的事。但后来踩过几次坑才发现——不懂架构，你连需求都提不明白。
硬件系统架构，说白了就是三件事：感知、传输、处理。对应到技术层面，就是感知层、网络层、应用层。咱们一层一层拆开看。
4.1 硬件系统架构：三层模型
先画个框架。任何智能硬件产品，都逃不开这三层：
- 感知层：传感器、执行器、MCU等底层硬件
- 网络层：通信协议、网关、云连接
- 应用层：APP、云端服务、AI算法
我习惯把这三层比作「人的身体、神经、大脑」。感知层是手和脚，网络层是神经系统，应用层是大脑。缺一个，产品就「残」了。
4.1.1 感知层设计要点
感知层是离用户最近的一层。你想想看，用户摸到的、看到的、听到的，都是感知层的东西。
这里有几个关键点：
- 传感器选型：精度、功耗、成本三者要平衡。我在项目中遇到过，为了省5毛钱选了低精度温湿度传感器，结果数据漂移严重，AI模型直接废了。
- MCU主控：处理能力够用就行，别盲目追求高性能。ESP32、STM32是主流选择。
- 电源管理：电池供电的产品，待机功耗必须控制在μA级别。嗯，这里要注意——很多产品死就死在「待机功耗过高」上。
4.1.2 网络层设计要点
网络层是「神经」，负责把感知层的数据传上去，把应用层的指令传下来。这里最容易出问题的是「通信距离」和「数据丢包」。
我个人习惯在设计网络层时，先问三个问题：
- 数据量多大？——决定了用Wi-Fi还是BLE
- 传输距离多远？——决定了要不要加网关
- 实时性要求多高？——决定了协议栈选型
举个例子，智能音箱的数据量很大（音频流），距离近（10米内），实时性要求高。所以Wi-Fi是首选。而智能门锁，数据量极小（开锁指令），距离无所谓（有手机就行），实时性要求中等。BLE就够用了。
4.1.3 应用层设计要点
应用层是「大脑」。这里AI产品经理要重点关注两件事：
- 云端架构：数据存储、模型推理、OTA升级
- 边缘计算：哪些逻辑在设备端跑，哪些上云
我建议的原则是：能边缘计算的，就别上云。为什么？延迟低、隐私好、成本省。比如人脸识别门锁，本地跑模型比上传云端快得多，用户开门体验完全不一样。
4.2 软件与固件架构设计
硬件产品里，软件和固件是「灵魂」。很多AI产品经理只关注APP和云端，忽略了固件。但说实话，固件才是硬件的「操作系统」。
4.2.1 固件架构
固件跑在MCU上，资源极其有限。我见过最夸张的项目，一个固件代码写了10万行，结果MCU Flash只有512KB，编译都过不去。
固件架构通常分三层：
- 硬件抽象层（HAL）：封装传感器、外设驱动
- 中间件层：协议栈、任务调度、OTA模块
- 应用层：业务逻辑、AI推理
举个例子，一个智能灯控的固件架构：
// 伪代码示例：固件任务调度
void setup() {
hal_init(); // 初始化硬件
wifi_connect(); // 连接网络
mqtt_init(); // 初始化MQTT
ota_check(); // 检查OTA更新
}
void loop() {
handle_light(); // 灯光控制逻辑
report_status(); // 上报设备状态
check_ota(); // 检查OTA
sleep(10); // 低功耗休眠
}
你看，固件代码其实很「朴素」。没有复杂的框架，就是循环+中断。但越简单的东西，越容易出问题。我曾经在一个项目里，因为中断优先级没配好，导致Wi-Fi断连后无法重连。排查了三天才找到原因。
4.2.2 软件架构
软件主要指APP和云端服务。这里AI产品经理要关注的是「数据流」和「状态同步」。
我习惯用「状态机」来设计软件架构。比如智能门锁的状态：
- 待机状态 → 用户靠近 → 唤醒状态
- 唤醒状态 → 指纹识别 → 开锁状态
- 开锁状态 → 门关闭 → 待机状态
每个状态对应一组UI和逻辑。这样设计的好处是——状态清晰，bug好找。
4.3 通信协议选型
通信协议选型，是AI产品经理最头疼的事。Wi-Fi、BLE、Zigbee、Matter……到底选哪个？
别急，咱们一个一个看。
4.3.1 Wi-Fi
优点：带宽大、直连路由器、无需网关
缺点：功耗高、配网复杂、成本较高
适合场景：智能音箱、摄像头、家电等需要持续联网、数据量大的产品。
我个人建议：如果产品需要「持续在线」，Wi-Fi是首选。但要注意配网体验——很多用户被「长按3秒进入配网模式」搞崩溃了。现在主流方案是「蓝牙辅助配网」，先用BLE把Wi-Fi信息传给设备，再自动连接。
4.3.2 BLE（蓝牙低功耗）
优点：功耗极低、手机直连、成本低
缺点：带宽小、距离短（10米内）、不能直连互联网
适合场景：手环、门锁、传感器、遥控器等电池供电、数据量小的产品。
你想想看，为什么智能手环都用BLE？因为一块电池能用半年。如果用Wi-Fi，两天就得充一次电。
4.3.3 Zigbee
优点：自组网、低功耗、支持大量节点（理论65000个）
缺点：需要网关、手机不能直连、生态封闭
适合场景：智能家居全屋方案、楼宇自动化、工业传感器网络。
Zigbee有个特点——网状网络。每个设备都可以当「中继」，信号可以一跳一跳传很远。我在一个智能照明项目里，用Zigbee组了200个灯，覆盖整栋办公楼，一个网关就够了。
但Zigbee的坑也不少。比如不同品牌的Zigbee设备可能不兼容，因为协议栈版本不同。嗯，这里要注意——选Zigbee方案，一定要确认协议栈版本和认证。
4.3.4 Matter
优点：跨平台、统一标准、未来趋势
缺点：生态不成熟、开发成本高、认证周期长
Matter是2022年推出的新协议，目标是统一智能家居标准。说白了，就是让Apple HomeKit、Google Home、Amazon Alexa的设备能互相通信。
我个人对Matter的看法是：长期看好，短期谨慎。如果你做的是面向未来的产品，可以提前布局Matter。但如果产品今年就要上市，建议先用成熟的Wi-Fi或BLE方案。
4.3.5 协议选型对比表
| 协议 | 功耗 | 带宽 | 距离 | 网关 | 成本 | 适合场景 |
|---|---|---|---|---|---|---|
| Wi-Fi | 高 | 高 | 50米+ | 不需要 | 中 | 持续在线、大数据量 |
| BLE | 极低 | 低 | 10米 | 不需要 | 低 | 电池供电、小数据量 |
| Zigbee | 低 | 低 | 100米+（网状） | 需要 | 中 | 全屋智能、多节点 |
| Matter | 中 | 中 | 取决于底层协议 | 需要 | 高 | 跨平台、未来产品 |
4.4 实战建议：如何做架构选型
说了这么多，到底怎么选？我总结了一个「三步法」：
- 先定产品形态：电池供电还是插电？室内还是室外？数据量大还是小？
- 再定通信协议：根据功耗、距离、带宽需求，从Wi-Fi/BLE/Zigbee/Matter里选
- 最后定架构：感知层用什么传感器？网络层要不要网关？应用层本地还是云端？
举个例子，一个智能门锁的架构选型：
- 产品形态：电池供电、室内、数据量小
- 通信协议：BLE（低功耗、手机直连）
- 架构：感知层（指纹传感器+MCU）→ 网络层（BLE）→ 应用层（手机APP+云端管理）
你看，逻辑很清晰。AI产品经理不需要懂每个技术细节，但一定要会「做选择题」。
好，这一章就到这里。下一章咱们聊聊「硬件产品开发流程」，从立项到量产，每一步怎么走。到时候我会分享一些「血泪史」，保证让你少走弯路。