企业官网建设流程全解析

1. 从“All in AI”到“把AI塞进板子”：一个嵌入式老兵的真实困惑

过去两年，我身边做嵌入式的朋友分成了两拨。一拨人天天在群里转大模型的新闻，聊参数、聊算力、聊谁家又融了多少钱，嘴上喊着“All in AI”，手里却连一块能跑推理的板子都没摸过；另一拨人闷头在RK3588、Jetson Orin Nano这些平台上折腾，把YOLO、Qwen这类模型往边缘设备上搬，踩了一堆坑，但确实把东西跑起来了。

我自己是后者。从最早的STM32裸机开发，到后来跑嵌入式Linux，再到这两年接触边缘AI部署，一路走过来最大的感受是：“All in AI”对绝大多数嵌入式工程师来说是个伪命题，真正的机会在“走向边缘”。原因很简单——大模型训练和云端推理是算法工程师和基础设施团队的战场，而把模型压缩、量化、裁剪之后塞进功耗几瓦、内存几个G的嵌入式设备里，让它稳定跑在产线、车载、安防、机器人这些真实场景中，这件事只有懂硬件、懂系统、懂实时性的嵌入式工程师能干。

这篇文章不打算给你画大饼，也不打算复述那些“AI赋能万物”的套话。我想做的是把“嵌入式工程师如何切入边缘AI”这件事拆开，从平台选型、系统构建、模型部署、性能调优到职业路径，把我在Jetson、Rockchip、Yocto这些关键词背后踩过的坑和总结的经验，尽可能完整地摊开来讲。如果你正在纠结要不要转、怎么转、转到什么程度，或者你已经在做边缘AI但总觉得哪里不对劲，那这篇内容应该能给你一些参考。

需要提前说明的是，边缘AI这个方向变化很快，具体的工具版本、模型格式、驱动兼容性可能每隔几个月就有调整。我下面讲到的操作步骤和参数配置，都是基于我实际用过的版本和环境，你在复现的时候一定要结合自己手头的硬件和软件版本做适配，不要照搬。

2. 边缘AI到底在“边缘”什么：先搞清楚这件事再谈转型

2.1 云端推理和边缘推理的本质差异

很多人对边缘AI的理解停留在“把模型放到本地跑”，这个理解不算错，但太浅了。云端推理和边缘推理的差异，远不止“位置不同”这么简单。

云端推理的假设是：网络带宽充足、算力可以弹性扩展、功耗和散热不是主要矛盾、设备可以随时在线。而边缘推理面对的是完全相反的约束——带宽可能只有几兆、算力固定且有限、功耗和散热是硬指标、设备可能长期离线。这些约束直接决定了你在边缘侧能做什么、不能做什么。

举个具体的例子。你在云端部署一个YOLOv8x做目标检测，输入分辨率1280×1280，FP16精度，一张T4卡能轻松跑到几十FPS。但如果你要把同样的任务放到一块Jetson Orin Nano 8GB上，对不起，你得先把模型换成YOLOv8n或者YOLOv8s，输入分辨率降到640×640，还得做INT8量化，才能勉强跑到20-30FPS。这中间的差距不是“优化一下”就能补上的，而是物理层面的算力和内存带宽限制。

所以边缘AI的核心工作，不是“把云端模型搬过来”，而是在给定硬件约束下，重新设计一套从模型选型、量化压缩、推理引擎适配到后处理优化的完整方案。这套方案里，嵌入式工程师的价值在于对硬件资源的精确把控和对系统实时性的深刻理解，而不是调参。

2.2 嵌入式工程师在边缘AI链条中的不可替代性

我见过不少算法工程师尝试自己把模型部署到边缘设备上，结果卡在驱动、交叉编译、内存对齐、DMA传输这些环节上动弹不得。也见过纯嵌入式背景的工程师面对ONNX、TensorRT、RKNN这些工具链时一头雾水。这两类人之间的 gap，恰恰就是嵌入式工程师切入边缘AI的最佳位置。

具体来说，嵌入式工程师在边缘AI链条中至少承担四个不可替代的角色：

• 系统集成者：负责把AI推理框架（TensorRT、RKNN、TFLite等）集成到嵌入式Linux或RTOS系统中，处理驱动、库依赖、内存管理、进程调度等问题。
• 性能调优者：通过CPU/GPU/NPU的任务划分、内存带宽优化、流水线设计等手段，把推理延迟和功耗压到场景可接受的范围内。
• 可靠性保障者：设计看门狗、温度监控、降频策略、异常恢复机制，确保设备在7×24小时运行中不会因为AI推理而崩溃。
• 场景落地者：理解具体应用场景（如工业质检、车载感知、安防监控）对精度、延迟、功耗的真实需求，在算法指标和工程约束之间做权衡。

这四件事，算法工程师做不了全部，纯软件工程师也做不了全部。只有既懂底层硬件又懂上层系统的嵌入式工程师，才能把整条链路打通。

2.3 一个真实的场景：从“跑通Demo”到“产线可用”有多远

我拿自己做过的一个工业质检项目举例。需求是在产线传送带上检测零件表面缺陷，要求延迟低于100ms，准确率高于95%，设备功耗低于15W，成本控制在千元以内。

最开始我们用Jetson Nano跑了一个YOLOv5s的Demo，在实验室环境下效果很好，检测一张图大概80ms。但到了产线上，问题全来了：传送带速度一快，摄像头采集的帧率跟不上；车间温度到40度以上，Jetson Nano开始降频，延迟直接飙到200ms以上；光照变化导致误检率上升；连续运行8小时后系统内存泄漏，推理进程被OOM Killer干掉。

从“跑通Demo”到“产线可用”，我们花了将近三个月时间，做了这些事情：换用Rockchip RK3588平台（NPU算力更强、功耗更低）、重新训练模型并做INT8量化、设计主动散热方案、增加温度监控和动态降频策略、优化摄像头采集和推理的流水线、加入内存监控和自动重启机制。最终延迟稳定在60-80ms，准确率97%，功耗12W左右，成本控制在800元以内。

这个经历让我深刻认识到：边缘AI的难点从来不在模型本身，而在模型之外的系统工程。而这恰恰是嵌入式工程师的主场。

3. 平台选型：Jetson、Rockchip还是别的什么

3.1 Jetson系列：生态最成熟，但别盲目追新

Jetson系列是NVIDIA在边缘AI领域的拳头产品，从最早的Jetson Nano到现在的Jetson Orin系列，覆盖了从入门到高端的完整产品线。我实际用过的有Jetson Nano、Jetson Xavier NX、Jetson Orin Nano和Jetson AGX Orin。

Jetson最大的优势是软件生态。CUDA、cuDNN、TensorRT这套工具链在边缘设备上几乎是无缝迁移的，你在服务器上训练的模型，导出ONNX后可以直接用TensorRT优化和推理。JetPack SDK把驱动、CUDA、TensorRT、OpenCV、DeepStream都打包好了，刷机之后基本开箱即用。对于需要快速验证方案的团队来说，Jetson的启动成本是最低的。

但Jetson的问题也很明显。首先是价格，Jetson Orin Nano 8GB的模组价格在千元以上，加上载板、散热、存储，整套下来成本不低。其次是功耗和散热，Orin Nano的TDP在7-15W之间，实际跑满的时候发热量不小，在密闭环境下必须加主动散热。最后是供货，NVIDIA的模组供货周期一直不太稳定，小批量采购经常要等。

我的建议是：如果你做的是原型验证、科研项目或者对成本不敏感的高端应用，Jetson是首选。但如果你要做量产产品，尤其是成本敏感的消费级或工业级产品，Jetson的性价比需要仔细算账。

3.2 Rockchip RK3588：国产替代里的“真香”选择

Rockchip RK3588是我这两年用得最多的边缘AI平台。8核CPU（4×A76 + 4×A55）、Mali-G610 GPU、6TOPS NPU、支持8K视频编解码，这个配置放在千元以内的价格区间里，性价比非常突出。

RK3588的NPU通过RKNN工具链使用。RKNN-Toolkit2支持将ONNX、TensorFlow、PyTorch等格式的模型转换为RKNN格式，然后在板子上通过RKNN Runtime推理。我实测下来，YOLOv5s在RK3588 NPU上跑640×640输入，INT8量化后单帧推理时间在25-35ms左右，比Jetson Orin Nano的TensorRT略慢，但功耗只有Orin Nano的一半左右。

RK3588的坑主要集中在工具链成熟度上。RKNN-Toolkit2的版本迭代很快，不同版本之间的API和算子支持差异较大，有时候你按照官方文档转换模型会失败，需要去社区找patch或者自己改算子。另外，RK3588的Linux SDK（基于Yocto构建）文档比较零散，很多配置需要看源码或者问FAE才能搞清楚。

但总体来说，如果你要做量产产品，尤其是对成本和功耗有要求的场景，RK3588是目前国产平台里最均衡的选择。Ubuntu Rockchip社区项目（如rk3588的Ubuntu镜像）也在逐步完善，开发体验比前两年好了很多。

3.3 平台选型的决策框架

我把平台选型的关键维度整理成了一张表，你可以根据自己的项目需求来打分：

选型的核心逻辑是：先明确你的场景对算力、功耗、成本、供货的硬约束，再在满足约束的平台里选生态最好的那个。不要因为Jetson名气大就无脑选Jetson，也不要因为RK3588便宜就硬上，算力不够的时候再便宜也没用。

4. 系统构建：Yocto、Ubuntu还是厂商SDK

4.1 Yocto的“劝退”与“真香”

Yocto是嵌入式Linux领域最主流的构建系统之一，Rockchip、NXP、TI等厂商的官方SDK大多基于Yocto。但Yocto的学习曲线非常陡峭，很多人第一次接触Yocto的时候会被那一堆layer、recipe、bbappend文件搞晕。

我刚开始用Yocto的时候也踩了不少坑。最典型的问题是：不知道改哪里。比如我想在镜像里加一个自己的应用程序，需要写一个recipe；想修改内核配置，需要写一个bbappend；想调整根文件系统的内容，需要改image recipe。这些操作在Buildroot里可能只需要改几个配置文件，但在Yocto里需要理解整个layer架构。

但Yocto的“真香”之处在于可复现性和可定制性。一旦你把layer和recipe写好了，整个系统的构建就是完全可复现的，换一台机器、换一个版本，只要layer不变，构建出来的镜像就是一致的。这对于量产产品来说非常重要。另外，Yocto的包管理机制让你可以精确控制镜像里包含哪些包、哪些库、哪些驱动，不会像Ubuntu那样带一堆用不到的东西。

我的建议是：如果你做的是量产产品，花时间学Yocto是值得的。如果你只是做原型验证，用厂商提供的Ubuntu镜像或者预编译的SDK就够了，没必要在Yocto上耗时间。

4.2 Ubuntu Rockchip社区项目的实际体验

Rockchip官方提供的Linux SDK是基于Yocto的，但社区里有一些基于Ubuntu的项目（比如rk3588的Ubuntu 22.04镜像），用起来更接近桌面Linux的体验。我实测过几个版本，优缺点都很明显。

优点是上手快。刷好镜像之后，apt、pip、docker这些工具都能直接用，装个Python环境、跑个ONNX Runtime推理，几分钟就能搞定。对于不熟悉Yocto的开发者来说，Ubuntu镜像大大降低了入门门槛。

缺点是定制性差。Ubuntu镜像里包含了很多用不到的服务和包，启动时间比Yocto构建的镜像长不少。另外，Ubuntu的内核版本和驱动版本可能和Rockchip官方的BSP有差异，某些硬件功能（比如NPU、VPU）的驱动可能不是最新的。如果你要做深度定制或者对启动时间有要求，最终还是得回到Yocto。

4.3 交叉编译环境的搭建要点

不管用Yocto还是Ubuntu，交叉编译环境都是绕不开的。我总结几个关键点：

• 工具链选择：Rockchip RK3588是aarch64架构，需要用aarch64-linux-gnu工具链。厂商SDK里通常会自带工具链，建议优先使用厂商提供的版本，避免glibc版本不匹配的问题。
• sysroot配置：交叉编译时，头文件和库的路径要指向目标系统的sysroot，而不是宿主机的。CMake里通过CMAKE_SYSROOT指定，Makefile里通过--sysroot指定。
• 依赖库处理：如果你的程序依赖OpenCV、FFmpeg等库，需要先在目标系统上安装对应的开发包，或者从SDK里提取对应的头文件和库文件放到sysroot里。
• 动态库路径：交叉编译出来的可执行文件在目标系统上运行时，要确保动态库路径正确。可以通过LD_LIBRARY_PATH或者rpath来指定。

提示：交叉编译环境搭建好之后，建议先用一个最简单的hello world程序验证工具链是否正常工作，再逐步加入依赖库。不要一上来就编译整个项目，出了问题很难定位。

5. 模型部署：从ONNX到NPU的完整链路

5.1 模型转换：ONNX是中间格式的首选

不管你是用PyTorch还是TensorFlow训练的模型，部署到边缘设备的第一步通常是导出为ONNX格式。ONNX的好处是格式统一、工具链支持广泛，TensorRT、RKNN、OpenVINO等推理框架都支持ONNX作为输入。

导出ONNX的时候有几个坑要注意：

• 算子版本：PyTorch导出ONNX时，opset_version的选择很重要。版本太低可能不支持某些算子，版本太高可能推理框架不支持。我一般用opset 11或12，兼容性比较好。
• 动态维度：如果模型输入是动态尺寸的，导出时要指定dynamic_axes。但很多边缘推理框架对动态维度的支持不好，建议尽量固定输入尺寸。
• 后处理：YOLO系列模型的后处理（NMS、解码）通常不建议导出到ONNX里，因为不同推理框架对后处理算子的支持差异很大。更好的做法是把后处理用C++或Python单独实现，在推理输出之后处理。

5.2 RKNN模型转换的实操细节

RKNN-Toolkit2的模型转换流程大致是：加载ONNX模型 → 配置量化参数 → 构建RKNN模型 → 导出RKNN文件。我拿YOLOv5s举例，讲几个关键步骤。

首先是环境准备。RKNN-Toolkit2需要在x86主机上运行，Python版本建议3.8或3.10。安装的时候要注意版本匹配，不同版本的RKNN-Toolkit2对应的RKNN Runtime版本不同，板子上的Runtime版本要和Toolkit版本对应。

# 创建虚拟环境 python3 -m venv rknn_env source rknn_env/bin/activate # 安装RKNN-Toolkit2 pip install rknn-toolkit2 -i https://mirrors.aliyun.com/pypi/simple/

然后是模型转换脚本。核心是config里的量化配置：

from rknn.api import RKNN rknn = RKNN(verbose=True) # 配置模型输入 rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588', quantized_dtype='asymmetric_quantized-8', optimization_level=3 ) # 加载ONNX模型 ret = rknn.load_onnx(model='yolov5s.onnx') if ret != 0: print('Load ONNX failed') exit(ret) # 构建RKNN模型，需要提供量化校准数据集 ret = rknn.build(do_quantization=True, dataset='./calibration.txt') if ret != 0: print('Build RKNN failed') exit(ret) # 导出RKNN模型 ret = rknn.export_rknn('yolov5s.rknn') if ret != 0: print('Export RKNN failed') exit(ret)

这里有几个关键点：

• 量化校准数据集：calibration.txt里列出的是校准图片的路径，一般准备100-200张有代表性的图片就够了。校准集的质量直接影响量化后的精度，建议用实际场景的图片，不要用无关的公开数据集。
• 量化类型：asymmetric_quantized-8是RKNN常用的INT8量化方式，精度和速度比较均衡。如果精度损失太大，可以尝试dynamic_fixed_point-8或者混合量化。
• 优化级别：optimization_level=3会启用所有优化，包括算子融合、内存复用等。如果遇到转换失败，可以降到2或1试试。

5.3 TensorRT部署Jetson的注意事项

Jetson平台上用TensorRT部署模型，流程和RKNN类似，但细节不同。TensorRT的核心是构建Engine，这个过程比较耗时，建议在PC上构建好Engine再部署到Jetson上。

TensorRT部署的几个关键点：

• 精度模式：FP32、FP16、INT8三种模式。FP16在Jetson上通常能带来1.5-2倍的速度提升，精度损失很小。INT8需要校准，精度损失取决于模型和校准集。
• 动态Shape：TensorRT支持动态Shape，但需要设置Optimization Profile。如果输入尺寸固定，建议直接用固定Shape，性能更好。
• 插件：某些算子（如YOLO的NMS）TensorRT原生不支持，需要写Plugin。NVIDIA提供了开源的TensorRT OSS插件库，可以直接用。

5.4 推理结果的后处理优化

模型推理只是整个链路的一部分，后处理（解码、NMS、坐标映射）往往也占不少时间。我实测过，YOLOv5s在RK3588上推理25ms，后处理如果写得不好，可能也要10-15ms。

后处理优化的几个方向：

• 用C++重写：Python后处理虽然写起来快，但性能差很多。生产环境建议用C++实现后处理，通过pybind11或者直接集成到推理程序里。
• SIMD加速：NMS里的排序和IoU计算可以用NEON指令加速，RK3588的A76核心支持NEON，优化后能快不少。
• 并行化：如果有多路视频流，可以把推理和后处理放在不同线程里，用流水线的方式并行处理。

6. 性能调优：延迟、功耗、精度的三角平衡

6.1 延迟优化的几个抓手

边缘AI场景对延迟的要求通常很严格，工业质检可能要求50ms以内，自动驾驶要求更低。延迟优化可以从几个层面入手：

模型层面：换更小的模型（YOLOv5n vs YOLOv5s）、降低输入分辨率、减少类别数、裁剪冗余层。这些操作会直接影响精度，需要根据场景做权衡。

推理层面：启用INT8量化、使用NPU而不是CPU推理、开启算子融合、减少内存拷贝。RK3588的NPU推理比CPU推理快5-10倍，能用NPU就一定要用。

系统层面：提高推理进程的优先级、绑定CPU核心、使用DMA减少数据拷贝、优化摄像头采集和推理的流水线。这些操作不改变模型，但能显著降低端到端延迟。

我做过一个测试，同样的YOLOv5s模型在RK3588上，不做任何系统优化的情况下端到端延迟是80ms，做了CPU绑核、进程优先级调整、DMA优化之后降到了55ms。系统层面的优化空间往往比模型层面更大。

6.2 功耗控制与散热设计

边缘设备的功耗和散热是硬约束。RK3588在满载跑NPU推理的时候，功耗大概在5-8W，Jetson Orin Nano在10-15W。如果设备是密闭无风扇设计，散热问题会很突出。

功耗控制的几个手段：

• 动态调频：根据负载动态调整CPU/GPU/NPU的频率。Linux的cpufreq子系统可以配置，但NPU的频率调整需要厂商驱动支持。
• 任务调度：把推理任务分散到多个时间段，避免长时间满载。比如视频流场景可以隔帧推理，或者用低分辨率做粗筛、高分辨率做精检。
• 散热设计：如果功耗降不下来，就得在散热上下功夫。导热硅脂、石墨烯散热片、均热板、微型风扇，根据设备形态选择。

注意：温度监控是必须的。我在项目里遇到过RK3588在高温下降频导致推理延迟翻倍的情况，后来加了温度监控和动态降频策略，温度超过阈值就主动降低推理频率，保证系统稳定。

6.3 精度损失的评估与补偿

INT8量化通常会带来1-3%的精度损失，具体取决于模型和校准集。评估精度损失的方法是在验证集上对比量化前后的mAP或者准确率。

如果精度损失太大，可以尝试这些补偿手段：

• 混合量化：对精度敏感的层用FP16，其他层用INT8。RKNN和TensorRT都支持混合量化。
• 量化感知训练：在训练阶段就模拟量化误差，让模型适应量化。这种方法效果最好，但需要重新训练。
• 校准集优化：用更多、更有代表性的校准图片，覆盖各种光照、角度、场景。
• 后处理补偿：调整置信度阈值、NMS阈值，在一定程度上弥补量化带来的精度损失。

7. 职业路径：嵌入式工程师切入边缘AI的几种姿势

7.1 从驱动/系统工程师转型

如果你现在是驱动工程师或者系统工程师，切入边缘AI最自然的路径是做AI推理框架的系统集成和优化。你对Linux内核、驱动、内存管理、进程调度的理解，在边缘AI部署中非常值钱。

具体来说，你可以从这些方向入手：学习TensorRT或RKNN的推理流程，理解模型加载、内存分配、任务调度的机制；研究如何把推理框架集成到现有的嵌入式系统中；优化推理过程中的内存拷贝和DMA传输。这些工作不需要你懂模型训练，但需要你对系统有深入理解。

7.2 从应用工程师转型

如果你现在是嵌入式Linux应用工程师，切入边缘AI的路径是做AI应用的全链路开发。你需要理解模型输入输出的格式、后处理的逻辑、多路视频流的管理、推理结果的业务处理。

具体来说，你可以从这些方向入手：学习Python和C++的推理接口，掌握ONNX Runtime、RKNN Runtime、TensorRT的API；实现YOLO、ResNet等常见模型的后处理；设计多线程/多进程的推理流水线。这些工作不需要你改模型结构，但需要你懂工程实现。

7.3 从算法工程师转型

如果你现在是算法工程师，想往边缘方向走，你需要补的是嵌入式系统的基础知识。交叉编译、驱动、内存对齐、实时性、功耗管理，这些是算法工程师在边缘场景下最容易踩坑的地方。

具体来说，你可以从这些方向入手：学习Linux系统编程，理解进程、线程、内存映射、设备文件；学习交叉编译工具链的使用；了解常见嵌入式平台的硬件架构和资源约束。这些知识不需要你成为专家，但需要你能和嵌入式工程师顺畅沟通。

7.4 边缘AI岗位的真实需求画像

我看了不少边缘AI相关的岗位JD，总结下来核心要求大概是这些：

• 熟悉至少一个边缘AI平台（Jetson、RK3588、Ascend等）的部署流程
• 掌握TensorRT、RKNN、TFLite等至少一种推理框架
• 熟悉C++和Python，能写高性能的推理程序
• 理解模型量化、剪枝、蒸馏等压缩技术
• 有嵌入式Linux开发经验，熟悉交叉编译、驱动、系统调优
• 有实际项目落地经验，能独立解决部署过程中的各种问题

这些要求里，实际项目落地经验是最值钱的。你跑通过一个完整的边缘AI项目，比看十本书都管用。

8. 几个我踩过的坑和对应的解法

8.1 RKNN模型转换失败：算子不支持怎么办

RKNN-Toolkit2对ONNX算子的支持不是100%的，遇到不支持的算子，转换会直接报错。我遇到过几次，解法大概有这几种：

• 查文档：RKNN-Toolkit2的文档里列出了支持的算子列表，先确认你的模型里有没有不支持的算子。
• 改模型：把不支持的算子替换成支持的等价算子。比如某些激活函数可以用支持的算子组合实现。
• 自定义算子：RKNN支持自定义算子，但需要写C++实现并编译到Runtime里，比较麻烦。
• 换框架：如果实在搞不定，可以考虑换用ONNX Runtime或者TFLite，虽然性能可能不如RKNN，但算子支持更全。

8.2 Jetson散热不足导致降频

Jetson Orin Nano在密闭环境下跑推理，温度很容易到80度以上，然后触发降频，推理延迟直接翻倍。我的解法是：

• 加装散热片和风扇，确保核心温度控制在70度以下
• 用tegrastats监控温度和频率，设置温度阈值告警
• 在软件层面做动态降频，温度过高时主动降低推理频率，避免系统崩溃

8.3 内存泄漏导致推理进程被杀

长时间运行的推理程序，如果内存管理没做好，很容易出现内存泄漏。我遇到过一次，程序跑了8小时之后被OOM Killer干掉。排查下来是每次推理都创建了新的Tensor，没有释放。

解法是：用内存池管理推理的输入输出Tensor，避免频繁分配释放；用valgrind或者heaptrack做内存分析；加内存监控，超过阈值就重启推理进程。

8.4 摄像头采集和推理的流水线设计

多路视频流场景下，摄像头采集和推理的流水线设计很关键。我一开始是采集一帧、推理一帧、输出一帧，串行执行，延迟很高。后来改成三线程流水线：采集线程负责从摄像头取帧放入队列，推理线程从队列取帧推理，输出线程负责后处理和显示。这样采集和推理可以并行，端到端延迟降低了30%以上。

9. 边缘AI学习路线上的一些个人建议

如果你刚开始接触边缘AI，我建议的学习顺序是这样的：

第一阶段：打基础。先把嵌入式Linux的基本功练扎实——交叉编译、系统编程、驱动基础、网络编程。这些是后面所有工作的基础，基础不牢后面会很痛苦。

第二阶段：跑通一个完整Demo。选一个平台（Jetson或者RK3588），从刷机开始，到跑通一个YOLO推理Demo，把整个流程走一遍。这个阶段不用追求性能，重点是理解整个链路。

第三阶段：深入推理框架。选一个推理框架（TensorRT或RKNN），深入学它的API、量化机制、优化选项。把这个框架的官方示例都跑一遍，理解每个参数的含义。

第四阶段：做性能优化。在你跑通的Demo基础上，做延迟、功耗、精度的优化。记录每次优化的效果，积累经验。

第五阶段：做完整项目。找一个真实场景，从需求分析到方案设计到落地部署，完整做一遍。这个阶段你会遇到各种意想不到的问题，解决这些问题的过程就是成长最快的时候。

关于学习资源，我推荐几个方向：厂商的官方文档和示例代码是最权威的，虽然有时候写得不够详细，但准确性最高；GitHub上的开源项目（比如RKNN Model Zoo、TensorRT OSS）有很多实战代码可以参考；技术社区里的部署笔记和踩坑记录也很有价值，但要注意版本差异。

最后说一点个人体会。边缘AI这个方向，技术更新很快，今天好用的工具明天可能就换了。但底层的东西——对硬件的理解、对系统的把控、对性能的敏感度——这些是不会过时的。与其追着新工具跑，不如把基本功练扎实，这样不管工具怎么变，你都能快速上手。