1. 边缘AI为什么绕不开SoC组合这道题去年帮朋友调试一台视觉分拣设备主控用的是RK3588相机采集端通了YOLO模型也跑起来了偏偏电机控制一塌糊涂Linux下的线程调度延迟动不动就几十毫秒伺服一抖就是一整排废品。后来实在没辙在控制板上加了一颗GD32F303把PWM输出、编码器回读和急停逻辑全部挪到这颗小MCU上问题当场消失。这个经历让我意识到边缘AI项目的真正难点往往不在选一颗多强的芯片而在怎么让不同芯片各干各擅长的事。单颗SoC的算力做得再高也没办法同时讨好实时控制、低功耗待机、丰富接口这三类诉求。所以主控SoC 协处理芯片的组合方案在边缘AI里不是炫技而是被功耗墙、接口墙和实时性逼出来的务实选择。这篇文章就围绕我手头做过的和深度评估过的12种SoC组合方案展开把每一种的适用场景、分工逻辑、通信方式和踩过的坑一次讲清楚。无论你是做产品选型、自研硬件还是学生项目想快速搭一套边缘智能原型都能在这里找到适合自己的组合思路。1.1 单芯片方案绕不开的三堵墙很多人选型时习惯先看算力TOPS高不高、能不能跑Transformer、视频编解码支不支持4K。看完算力再看接口发现引脚不够就开始硬挤。挤到最后三个问题迟早会暴露。第一堵墙是功耗。高性能SoC的动态功耗高得吓人RK3588标称适合做边缘盒子但整板跑起多路模型后5W到15W很常见Jetson Orin Nano甚至能冲到25W。这些芯片放在插电场景没问题一旦变成电池供电的巡检机器人或无线传感器就没法开机了。要让设备在无人关注的时段保持待机和监听必须另外挂一颗低功耗MCU负责唤醒。第二堵墙是接口。边缘AI产品往往要同时接多路摄像头、屏幕、网口、串口传感器、电机驱动和调试口。一颗SoC的外设资源再丰富也有引脚上限。把大量低速控制引脚压到一颗MCU上让SoC专心做PCIe、MIPI-CSI、USB3.0这些高速通道是更合理的外设分配方式。第三堵墙是实时性。Linux不是实时操作系统哪怕给CPU绑核、用PREEMPT_RT补丁中断响应和任务切换的抖动依然存在。伺服电流环需要微秒级确定性运动插补需要毫秒级周期这些活让通用SoC干结果就是电机发烫、轨迹偏移、保护误触发。把实时控制从Linux里剥出去交给专用MCU是最省力的解法。1.2 主从式与对等式的两种分工模型双芯片组合不是简单地把两颗芯片焊在一块板子上而是先想清楚两者是什么关系。我见过的方案基本能归成两类。主从式模型最常见一颗SoC当大脑负责AI推理、业务逻辑和网络通信一颗MCU当小脑负责电机、采集、IO扩展和电源管理。两者之间用UART、SPI或CAN连接命令从上往下发状态从下往上回。优点是责任清晰、调试方便、灵活度高缺点是通信链路上有延迟不适合需要两台设备高频交换大数据的场景。对等式模型则更极端两颗芯片各自独立运行完整任务中间通过PCIe、千兆网或CAN-FD做高速数据交换。比如RK3588做视频分析另外一颗K210专门跑低延迟唤醒模型两者都能独立工作只是通过消息总线协同。这种组合适合需要双保险或者算力水平拆分很极端的产品。用生活里的话说主从式像一个指挥中心配前线小队命令层层下达对等式更像两个平级部门各自处理后通过会议同步谁也不是谁的附庸。理解这两类关系后面看12种组合会清楚很多。2. 选型之前先把自己的权衡坐标画出来每次有人问我这个组合好不好我第一反应都是反问你的产品到底要解决什么问题组合方案看着很多但真正适合自己的往往只有一两个。在动手搭电路之前建议你先用四个问题给自己画一张权衡坐标。2.1 四个问题决定你要不要上组合方案问题一有没有硬实时需求如果系统里有电机、舵机、电源环路或者任何需要对时间严格把控的环节那就必须在主控之外加一颗MCU或者选自带独立MCU核的SoC。反过来如果只是做图像识别、数据转发这类任务单SoC就够没必要为了组合而组合。问题二有没有长时间待机场景比如网关设备、门锁、监测站大部分时间在等待事件发生。这类产品的功耗预算往往很低一颗高性能SoC光是启动就要几秒、待机也要两三瓦不合算。正确做法是让低功耗MCU常开用事件唤醒高算力SoC。问题三外设数量是不是爆炸了屏幕、摄像头、多路串口、多路GPIO、电机驱动、传感器接口如果全部压在SoC上引脚排不开PCB布局也糟心。让MCU承担低速外设SoC只接高速外设是一劳永逸的办法。问题四你有多少人力维护软件每增加一颗芯片意味着多一套SDK、编译器、烧录流程和协议代码。如果是小团队或学生项目这个隐性成本有时比硬件贵得多。所以我的建议是只有当上面三个问题里至少有一个是必须才值得上组合方案。2.2 画出分工地图再动手决定要组合之后别急着买开发板。先画一张分工地图把产品的所有功能列出来标注每项功能的响应时间、数据量和可靠性要求。然后把需要毫秒级确定性“需要微安级待机”需要大算力的功能分别划给对应芯片最后剩下的事情交给主SoC。这张图不需要很复杂一支笔一张纸就够。关键是有个明确结论哪种芯片负责哪几件事两者之间要跑什么协议、数据量多大、频率多高。我见过不少项目芯片选型和通信方案都定了结果做到一半发现SoC和MCU之间数据量远超预期原来是分工地图少了视频帧传输这一项。提前画图能避免这种返工。3. 12种SoC组合逐个拆解下面这12种组合是我在视觉分拣、机器人、工业网关、车载边缘计算、低功耗传感等场景里实际评估或使用过的方案。成本区间以裸板方案估算会随采购渠道和市场行情浮动看思路比看数字更重要。3.1 组合一RK3588 GD32F303——视频计算盒加实时执行机构RK3588是边缘AI里的明星SoC8核CPU加上6TOPS NPU视频编解码、PCIe、USB3.0、双千兆网口都给得很足跑YOLO系列、姿态估计、多路视频分析都很从容。GD32F303是Cortex-M4内核的国产MCU120MHz主频多路高级定时器引脚和STM32F103接近采购方便且供货稳定。这对组合的典型应用是视觉分拣设备、巡逻机器人、云台摄像机和多点位视频分析盒子。RK3588的Linux端负责取流、AI推理、结果上报GD32F303负责伺服电机PWM、编码器回读、急停信号、蜂鸣器和状态灯。两者之间用UART做命令通道另外用一根独立GPIO专门走急停信号——急停不能等串口解析必须是一根线直接拉断。选择GD32而不是STM32原因很现实价格更低供货更稳开发环境和标准外设库与STM32几乎同源。如果团队以前写过STM32代码迁移成本几乎为零。踩坑方面要特别注意上电时序RK3588有多路电源轨如果MCU先上电GPIO可能提前把SoC未初始化的引脚拉高产生灌电流甚至导致启动异常。3.2 组合二Jetson Orin Nano STM32G431——移动机器人的算力与手感Orin Nano是Jetson家族里的入门款却提供惊人的CUDA算力PyTorch、TensorRT、ROS生态相当完整适合做需要复杂视觉和深度学习的移动机器人。STM32G431则是一颗被低估的控制芯片Cortex-M4F内核内置运放、比较器和HRTIM高分辨率定时器是FOC电机控制的利器。这对组合最适合AGV、双轮平衡车、服务机器人这类既要算得懂又要控得稳的产品。Orin Nano负责视觉SLAM、目标检测、路径规划STM32G431负责电机电流环和速度环控制频率能做到20kHz以上。两者之间用CAN-FD通信带宽高、抗干扰强还能在机器人上多挂几个节点。这里有个关键逻辑AI推理路径相机采集→GPU→推理→输出的延迟是毫秒级且抖动的而伺服电流环需要微秒级刷新两者在同一个系统里相互拖累。拆开后哪怕Orin Nano跑满负载电机控制依然稳稳的。坑在于Orin Nano功耗很高电池容量、散热和供电拓扑都要提前算别等机器人都跑起来了才发现电池十几分钟就没电。3.3 组合三RK3308 RV1126——语音加视觉双前端RK3308是瑞芯微针对语音产品推出的SoC内置多路I2S/TDM接口可以直接接8路数字麦克风阵列配套的降噪和回声消除算法也比较成熟。RV1126则是一颗带ISP和2TOPS NPU的视觉芯片跑轻量目标检测和分类很顺手还支持H.264编码输出。这对组合在智能门禁、猫眼、老人看护、会议摄像头这类既听又看的设备里非常好用。RK3308常驻麦克风阵列做唤醒词识别和声源定位一旦唤醒通过UART通知RV1126启动摄像头画面分析把人脸识别和跌倒检测的结果返回给上层。两颗芯片各管一个感知模态互相不抢资源。为什么不直接选一颗带NPU又能接麦克风阵列的大SoC因为多路数字麦克风阵列的时钟和DMA中断非常消耗CPU如果同时还要跑ISP和视频编码单芯片负载很容易冲高功耗和发热跟着上来。拆开后每颗芯片的负载都很低整体反而更稳。缺点是两套SDK要分别维护发布固件时得同时烧两块芯片版本管理要做好。3.4 组合四STM32MP157 STM32G474——工业HMI与伺服驱动STM32MP157是ST官方出的MPU双核Cortex-A7加上一颗Cortex-M4既能跑Linux做图形界面又能用内部M4核做实时任务。那为什么还要再配一颗STM32G474因为MP157的M4核与A7共享DDR内存一旦Linux端发生大量内存分配或中断风暴M4的实时性会被拖累。对工业伺服控制来说这种不确定性不可接受。STM32G474自带HRTIM、多路高精度ADC和比较器专门为数字电源和伺服驱动设计。它彻底隔离了实时控制与Linux应用让伺服环路跑在微秒级周期内不受A7负载影响。两者之间用FDCAN连接在工业现场比UART抗干扰能力强很多。这对组合在工业控制面板、伺服驱动器、中小型PLC里很有代表性。代价是开发工具链多了一套A7端用Linux交叉编译M4端用STM32CubeIDEG474又一套而且三份代码要同步版本。建议提前设计好统一的固件版本号和升级流程否则工厂维护时会很痛苦。3.5 组合五i.MX8M Plus S32K144——汽车边缘计算的算安分离i.MX8M Plus是NXP推出的边缘计算SoC四核Cortex-A53集成了2.3TOPS NPU、双ISP、双CAN-FD和TSN以太网算力在汽车和工业场景里相当均衡。S32K144则是NXP的车规MCU通过ASIL-B功能安全认证运行独立的监控软件。这类组合的核心理念是算安分离i.MX8M Plus负责摄像头识别、驾驶员监控、雷达数据处理等AI推理但AI推理结果绝不能直接驱动执行器。结果要通过CAN-FD或SPI发给S32K144由这颗带功能安全认证的MCU经过校验、阈值判断再决定是否执行刹车、报警等动作。S32K144还独立监控主SoC的供电、温度和看门狗发现异常直接进入安全状态。这种架构在商用车辅助驾驶、车载边缘计算单元里很常见。它的工程量比前几个组合高一个量级因为涉及功能安全设计和认证流程。如果只是做消费级产品完全用不上这么重的方案但如果是车载或高危工业项目算安分离不是选择题而是必答题。3.6 组合六RK3568 ESP32-S3——边缘网关的常开与唤醒RK3568是瑞芯微的中端SoC四核A55搭配0.8到1TOPS NPU双千兆网口、PCIe、USB3.0一应俱全做边缘网关的算力刚好。ESP32-S3则是乐鑫的WiFi加BLE双模芯片自带低功耗处理器常开时功耗远低于完整Linux系统。这对组合最有意思的地方是把常开待机和按需唤醒做成了两个层级。ESP32-S3作为网关的值守哨兵平时只开着射频接收和简单的传感器轮询电流控制在毫安级一旦检测到环境数据越界、收到远程唤醒指令或收到本地按键中断就通过GPIO和UART把RK3568从休眠或深度待机状态拉起来由Linux系统完成视频推流、AI识别和复杂协议处理。这样安排之后整个网关在无事件时段的平均功耗从一颗RK3568常开的3到5W降到了几百毫瓦以下。在智能楼宇、环境监测和传感器汇聚这类大部分时间没事件来了事件要处理的场景里省电效果非常明显。需要特别注意事件唤醒的去抖ESP32-S3检测到信号后要连续确认几次再拉高唤醒引脚防止传感器毛刺导致网关反复开关机。3.7 组合七ESP32-S3 STM32L431——电池供电传感节点的低功耗双保险如果产品用电池供电还要连续工作几个月甚至一年那就进入低功耗设计的主场了。STM32L431是ST的超低功耗MCUstop模式下的静态电流能到微安级配合RTC可以定时醒来采集数据。ESP32-S3虽然也有低功耗模式但保持WiFi连接时功耗依然明显不适合深度睡眠场景下继续作为唯一主控。这对组合的分工很清晰STM32L431负责采集温度、湿度、振动、气压等传感器数据做简单的阈值判断和滤波把有效结果放入缓冲区ESP32-S3平时深度睡眠定时醒来通过SPI把缓冲区的数据取走然后启动WiFi上传传完继续睡。在冷链运输、环境监测和户外资产追踪这类产品里这对组合能把整机平均功耗压到很低的水平一颗2000mAh电池撑几个月是实际能实现的结果。关键坑在于两颗芯片的RTC唤醒时钟要对齐否则ESP32-S3醒来时STM32L431的数据还没准备好就得空等一个周期白白耗电。我自己的习惯是让STM32L431作为时间主节点通过GPIO通知ESP32-S3数据已就绪再让ESP32-S3从睡眠中醒来。3.8 组合八K210 ESP32-C3——极致成本AI视觉门禁K210是嘉楠科技推出的RISC-V AI芯片内置KPU加速器算力在0.8TOPS左右专攻目标检测、分类和人脸识别。ESP32-C3则是乐鑫的低成本WiFi/BLE芯片同样是RISC-V内核价格非常亲民。这两颗芯片凑在一起能做一个具备WiFi通信能力的人脸识别门禁或闸机方案裸板成本可以控制在二三十元级别。K210跑人脸检测和比对ESP32-C3负责与云端或手机App通信升级模型库、上报开门记录。对于学生竞赛、低成本考勤机、简易闸机这些场景性价比极高。但K210的坑也必须说清楚KPU支持的算子有限很多现代YOLO版本没法直接量化进去需要专门适配开发工具链比较老旧调试体验远不如STM32和RK平台。如果你打算跑复杂的Transformer类模型K210就力不从心了。它适合固定场景、固定模型、模型不频繁迭代的产品。3.9 组合九树莓派CM4 RP2040——原型的快速路量产的试错场树莓派CM4和RP2040的组合在商业产品里不算主流但在原型验证阶段非常好用。CM4提供完整的Linux生态各种AI框架几乎开箱即用RP2040有丰富的GPIO和PIO状态机适合做精细的IO时序和低速协议解析。做机器人和视觉类项目时我经常先用CM4跑Python或C版本的AI模型用RP2040驱动舵机、读取编码器几天就能跑通一套完整Demo。这个阶段的核心目标是验证算法和交互逻辑不追求极致功耗和成本。等原型验证完再把RP2040侧代码替换成STM32或GD32CM4替换成RK3588等量产芯片整体架构不用大改。需要提醒的是CM4的价格和供货一直不太稳定SD卡又是IO瓶颈长时间跑AI任务建议直接用eMMC版本或外接USB SSD。对应地RP2040没有ADC和DAC如果需要模拟量采集得在外面挂一颗ADC芯片或者直接用带ADC的MCU替代。3.10 组合十全志V3s ESP8266——百元级Linux小屏设备全志V3s是一颗很有意思的芯片片上集成了64MB DDR2内存、MIPI DSI显示接口、以太网控制器和音频编解码单颗芯片就能跑Linux系统做小屏设备非常省事。ESP8266则是老牌低成本WiFi芯片模块价格低到可以忽略。这对组合适合小批量HMI人机界面、桌面信息屏、电子价签、温湿度面板这类产品。V3s跑Linux驱动LCD屏幕和触摸ESP8266负责WiFi上报和远程配置。整体材料成本可以压到几十元在很多商业场景里有明显优势。不过要认清V3s的定位64MB内存去掉Linux内核占用后只剩三十多MB可用不适合跑Python或大模型。老老实实用C或C写界面逻辑配合轻量UI库才顺畅。ESP8266还有瞬间电流冲击的问题如果和V3s共用一颗LDOWiFi发射瞬间可能把电压拉低导致系统重启。电源设计时要单独给WiFi模块留电流余量或者用独立DC-DC供电。3.11 组合十一GD32F427 ESP8266——存量工业仪表的无线化改造很多工业现场还有大量只带RS-485接口的旧仪表、PLC和传感器本身没有联网能力更换成本又高得吓人。GD32F427作为Cortex-M4内核、主频200MHz的国产MCU外设丰富、价格便宜很适合做这种改造方案的翻译官。GD32F427通过UART或RS-485与老旧仪表通信解析Modbus等常见协议同时做数据滤波、故障特征提取这类轻量边缘处理再把结果压缩成小数据包交给ESP8266上传到云平台。这样旧设备不需要任何改动就能联网上报运行状态。这对组合解决的其实是算力有富余的问题原仪表端MCU算力早就跑满协议栈了没余力做WiFi和业务逻辑。外挂一颗MCU分担计算和无线传输比把整个设备换掉经济太多。工业现场的坑在于WiFi可靠性一定要加看门狗、本地缓存和数据重传机制保证断网时不丢数据。3.12 组合十二RK3588 K210——两级AI流水线把唤醒做成AI最后这个组合和我开头提到的加一颗MCU解决实时性思路不同它的目的是解决高算力SoC不该一直满负荷运行的问题。RK3588跑重模型没问题问题是一旦持续运行功耗和发热都压不住。K210在这里的角色更像AI门卫。具体架构是K210以低功耗状态连续运行一个轻量模型专门做人形检测、手势唤醒、快速分类这些简单判断一旦K210认为有值得处理的事件就通过GPIO唤醒RK3588让RK3588启动大模型做精细识别、视频推流和联动控制。反过来没有事件的时间里RK3588保持休眠或降频功耗大大降低。这个方案在智能家居中控、安防摄像头、会议系统这些平时待机、有事件才全力处理的场景里非常实用。最大的坑是两级AI的时间戳对齐K210发现事件到RK3588出结果两个时刻之间隔了几百毫秒甚至几秒必须记录好事件发生时间否则联动逻辑会误判。另外唤醒阈值要留抖动窗口不然误报一多高算力SoC被反复唤醒功耗反而更高。4. 十二种组合的横向对比和决策建议方案看多了容易眼花这一节把所有组合放一起做个横向对比。成本区间以裸板方案估算、仅供参考关键是理解每种组合适合什么场景。编号组合典型成本区间最适合的场景实时确定性开发难度一RK3588 GD32F303500–800元视觉分拣、机器人、视频分析盒MCU侧高中二Jetson Orin Nano STM32G4311500–2500元移动机器人、AGV、服务机器人高CAN-FD高三RK3308 RV1126200–350元智能门禁、猫眼、音视频一体设备中高四STM32MP157 STM32G474150–300元工业HMI、伺服驱动、PLC高高五i.MX8M Plus S32K144500–1500元车载边缘计算、功能安全场景高非常高六RK3568 ESP32-S3200–400元边缘网关、环境监测、智慧楼宇中中七ESP32-S3 STM32L43130–80元电池供电传感节点、冷链追踪MCU侧高低八K210 ESP32-C320–40元低成本门禁、闸机、视觉计数中中高九树莓派CM4 RP2040300–700元原型验证、竞赛、教学中低十全志V3s ESP826630–60元小屏HMI、信息屏、简单Linux设备中中十一GD32F427 ESP826620–50元工业仪表改造、数据采集高低十二RK3588 K210500–800元待机唤醒、安防、智能中控中高高怎么选我的经验是按预算和痛点来对号入座。预算极低又想玩AI视觉直接看第八种电池供电长周期监控第七种是标准答案要控制电机又需要高算力视觉第一、第二、第四种按预算挑做工业或车载这类可靠性要求极高的第五种最稳如果只是想快速验证想法第九种能帮你一晚上跑通Demo。如果目标场景是平时要省电、有事要全力处理那第六种和第十二种值得认真研究。它们的思路一致都是用一颗低功耗芯片常开值守用事件唤醒高算力芯片区别只是值守芯片是普通MCU还是带AI能力的K210。5. 双芯片方案里的坑都是拿工时换来的组合方案能带来灵活性和性能优势但也引入了一堆单芯片方案不需要面对的问题。下面这几类坑我基本都踩过一遍写出来给大家避雷。5.1 电源设计谁先上电谁后上电不是随便定的双芯片系统最隐蔽的问题就是上电时序。高性能SoC内部往往有多个电源域上电顺序有严格要求。比如RK3588这类SoC如果GPIO在核心电源还没稳定时就被外部MCU拉高轻则启动异常重则造成IO损伤。解决方法是仔细查阅两颗芯片的数据手册画清上电时序图必要时用PMIC的电源序列控制或电源监控芯片来保证先后顺序。PCB设计时把数字电源和模拟电源分开走线电机驱动的功率地不要和逻辑地混在一起否则PWM切换的尖峰干扰会通过地平面串进SoC的模拟电路导致ADC采样跳变。我习惯在每颗芯片的复位引脚和关键电源轨上预留RC延迟改件位置方便调试时调整时序。宁可前期在电源设计上多花一天也不要后期拿着示波器满板子找复位失败的原因。5.2 片间通信UART、SPI、CAN-FD怎么选两颗芯片之间的通信方案要看数据量、距离和环境干扰来定。简单状态同步和命令下发UART最省事高速数据块传输SPI配合DMA效率最高长距离、多点连接、工业现场CAN-FD是首选。我的原则是控制类数据用带CRC的帧协议媒体流或大批量数据走SPI或DMA通道不要让CPU在中断里反复拷贝数据。UART通信常见的坑是波特率误差。两颗芯片使用的晶振精度不同如果误差超过2%长时间传输就会概率性丢字节。解决方法是选带自动波特率检测的芯片或者统一使用精度更高的晶振。还要给通信协议设计握手和重传机制。很多双芯片系统跑着跑着出现偶发失灵复位一下又好了根因就是通信帧丢失后没有重传逻辑两端状态机处于不一致状态。帧头、长度、CRC、ACK、超时重传这五样东西缺一不可。5.3 双芯片调试日志、时间戳和观察点单芯片调试只需要一套串口日志双芯片出问题时最痛苦的是不知道问题出在哪一端。电机不转可能是SoC没发命令也可能是MCU收到了命令但没执行还可能是执行了但硬件没响应。三选一每次都要靠经验猜。吃了几次亏之后我养成了三个习惯。第一每颗芯片都预留独立调试串口日志分级可开关生产固件里也要保留错误日志导出功能。第二日志里打统一时间戳两颗芯片通过同一个RTC基准或网络时间源对齐时钟。排查问题时对比两边的日志时间线很快就能定位到掉链子的一方。第三在关键信号上留GPIO测试点。比如SoC发送命令时翻转一个GPIOMCU收到命令时也翻转一个GPIO用示波器双通道抓这两根线。逻辑是通的还是硬件断的一眼就能看出来。这个小技巧帮我省过无数个小时。5.4 工具链和版本管理两套SDK加一份升级流程双芯片方案意味着两套交叉编译链、两套烧录工具、两套固件版本号。很多团队把精力花在硬件联调上忽视了软件层面的版本同步等到量产后才发现主SoC的固件升级了MCU的协议没跟着升新老版本混在一起现场设备出现一堆莫名问题。我的做法是把两颗芯片的固件版本捆绑成整机固件包统一升级入口升级时先校验版本匹配关系不匹配就拒绝升级。同时把SDK版本、内核版本、关键库版本写进一份changelog随代码仓库一起管理。只要有人升级任一芯片的SDK就必须同步更新这份文件和另一颗芯片的适配代码。6. 先审题再组合回到开头那句话边缘AI做得好不好很多时候不是算力不够而是没搞清楚系统各处对时间、功耗和接口的不同要求。12种组合方案看似很多但我实际的经验是大多数产品用一颗好SoC就够了。真正需要组合的跑不掉三种情况有硬实时控制需求、有长期待机监听功耗要求、外设多到单芯片引脚排不开。如果都不沾那就别为组合而组合省下的物料成本、开发工时和现场故障率都是纯赚的。如果确实需要组合画一张分工地图想清楚每颗芯片干什么、两者之间怎么通信、升级流程怎么同步再动手做硬件。我自己每次开始一个新项目都会先花半天做这一件事把哪颗芯片负责做什么、另一个系统不响应时我该怎么办写清楚。这份文档不一定要很正式但一定要有。它不仅是设计参考更是未来排查问题的地图。