企业官网建设流程全解析

端侧 AI 算力避坑指南：具身智能车载/机载算力芯片与硬件选型实测

老读者应该记得，我这两年一直在折腾具身智能方向的项目，从最早的机械臂抓取，到后来的室外无人车巡检，再到最近上车的机载视觉导航，一路走来踩得最多的坑，不是算法不收敛，也不是传感器标定不过关，而是看似最不起眼的——算力硬件选型。

说句实在话，算法模型写得再漂亮，放到端侧跑不动，或者跑起来发热降频、续航崩盘，项目照样黄。尤其是车载和机载这两种场景，和桌面端、云端完全不是一个逻辑。你得同时伺候功耗、散热、体积、实时性、环境适应性，还得考虑供应链能不能稳定供货，这里面的门道远比想象中复杂。所以今天这篇，我就把这两年做端侧 AI 和具身智能项目时，在算力芯片与硬件选型上踩过的坑、总结出的方法、实测过的数据，一次性整理出来。内容会比较长，但每一段都是拿真金白银换来的经验，适合正在做机器人、无人车、无人机或者任何移动端 AI 项目的朋友参考。

1. 内容整体设计与思路拆解

1.1 车载/机载场景下，算力选型为什么这么难

先说一个很多人容易忽略的事实：具身智能项目里的“脑子”，和普通安防摄像头里的“脑子”，根本是两个物种。摄像头端侧 AI 跑个目标检测，模型可能就几 MB，算力需求 1TOPS 以内就能搞定；但到了具身智能领域，你得同时处理多模态感知、实时建图、路径规划、运动控制，甚至在未来还得跑 VLA（Vision-Language-Action）这类大模型，算力需求量级直接跳到几十甚至上百 TOPS。

车载和机载场景比普通端侧更苛刻。车规和航规对芯片的工作温度、振动、寿命都有硬性要求，消费级芯片在车里晒一个夏天可能就频繁重启，在无人机上飞高一点可能直接过热保护。更麻烦的是功耗预算，车载还能稍微宽裕点，机载基本都是电池供电，功率器件、传感器、飞控、数传都在抢同一块电池，你给算力板分到的功耗往往只有 10W 到 30W。在这么紧的功耗墙里塞进足够的算力，本身就是一道非常考验功力的选择题。

我在早期做项目时犯过一个典型错误：只盯着芯片的“峰值算力”看，觉得 TOPS 越大越好。结果买回来一块标称 32TOPS 的开发板，实际跑起来发现内存带宽跟不上，NPU（神经网络处理单元）利用率连一半都到不了，而且整板功耗轻松突破 60W，在户外无人车上根本没法定容量的电池去带。后来我学乖了，做选型时先列约束条件，再谈算力指标：工作环境（温度、振动、防护等级）、供电方式（电压、电流上限）、整机功耗预算、接口需求（传感器、执行器）、软件生态成熟度，最后才是算力规格。

1.2 具身智能项目的算力需求分层和典型任务拆解

如果只看算力数字选芯片，十有八九会翻车。我做项目时的习惯是先把整套系统的任务拆开，算清每一路需要的算力，再汇总去匹配硬件。具身智能项目里典型的任务层大致可以分成四层：

感知层：包括摄像头图像的目标检测、语义分割、深度估计，激光雷达的点云处理，麦克风阵列的语音识别与声源定位。这一层是端侧 AI 消耗算力的大头，尤其是多路摄像头同时跑 YOLO 或者 Transformer 类模型时，算力需求会指数级增长。

建图定位层：VSLAM、激光 SLAM、语义地图构建，这层任务对 CPU 和 DSP 的消耗也很大，很多 NPU 用不上的几何计算会堆到 CPU 上。我实测过一些只有 NPU 强悍但 CPU 孱弱的芯片，跑 VSLAM 时表现非常拉胯。

规划决策层：包括全局路径规划、局部避障、行为决策。传统方法吃 CPU 还算温和，一旦引入基于强化学习或端到端模型的决策，算力需求又会上升一个台阶。

控制执行层：运动学解算、力控、滤波、状态估计。这层虽然单次计算量不大，但控制频率高（通常 500Hz 到 1kHz），对实时性和稳定性的要求极高，任何抖动都可能导致机械臂或车辆失控。

把这四层列出来后，你就会发现：选芯片看的不是单个指标，而是 CPU、NPU、GPU、DSP、内存带宽、外设接口的综合平衡。比如我做的室外无人车项目，最终需求大约是：双路 1080P 摄像头做目标检测（感知层），单线激光雷达跑 SLAM（建图层），路径规划跑在 CPU 上（规划层），底层控制走 MCU。综合测算后，理想配置是 NPU 算力 8TOPS 以上，CPU 至少 4 核高性能核心，内存带宽不低于 25GB/s，而整板功耗不能超过 25W。

有趣的是，这种按任务分层去测算的方法，和最近行业内推出的《人形机器人与具身智能标准体系》里的思路异曲同工——先标准化任务，再标准化算力接口。虽然那份标准目前还不是强制性的，但提前按这个思路做设计，后面做产品化升级会省很多事。

1.3 芯片选型方案的对比框架与产品化视角

大部分开发者在选型时只在“性能”这一个维度里纠结，但真正做过产品的人会告诉你，选型本质上就是一个多目标优化问题。我强烈建议你在选型初期就建立一个评分表，把以下维度全部拉进去打分：

• 算力密度（TOPS/W）：单位功耗能换来多少算力，机载场景尤其要重点看这项。
• 软件生态成熟度：有没有完善的 SDK、模型转换工具、算子库，社区活跃度如何。
• 内存带宽与容量：NPU 再强，内存带宽不够也会成为瓶颈；模型越大越吃内存容量。
• 接口丰富度：CSI/MIPI 摄像头接口、PCIe、CAN、串口、以太网这些对你的传感器和执行器是否友好。
• 环境适应性：工作温度范围、是否通过车规/航规认证、抗振能力。
• 供应链稳定性：交期、涨价风险、是否有第二供应商方案。
• 开发门槛与学习成本：你是不是愿意花两个月去啃一份糟糕的文档。

这里我想多说一句供应链的问题，它可能是普通开发者最容易忽略但在产业里最致命的一环。我身边就有团队用到一半，主控芯片突然进入“产能分配期”，交期从 8 周拉到 26 周，整个项目停摆了三个多月。所以如果你做的是偏产品的项目，尽量在立项时就确认好芯片的长期供货策略，甚至同步备选第二方案。

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

2.1 算力芯片领域的主流方案与各自“性格”

市场上能做端侧 AI 算力的芯片不少，但不同方案的性格差异巨大。我按自己的使用经验把它们大致分成了几个流派：

第一派是英伟达 Jetson 系列。它的最大优势是软件生态无敌，CUDA 生态让开发者几乎可以无缝从服务器搬到端侧，跑 PyTorch 模型简直不要太舒服。缺点是功耗偏高、价格不便宜，而且有些型号也面临供货波动。Jetson Orin Nano 我实测过，在 7W 到 15W 功耗档位跑目标检测和分割模型完全没问题，但跑视觉-语言模型时内存就成了瓶颈。

第二派是地平线系列，比如 Journey 系列和旭日系列。地平线最吸引人的是它的 BPU 架构对 Transformer 类模型做了很强的优化，比如在一些自动驾驶场景里跑 BEV 模型的效率很高。国内技术支持响应快，中文文档相对友好，这对国内团队是福星。不过它的生态主要还是围绕智能驾驶场景，如果你想把它用于通用机器人的复杂控制任务，部分算子支持度会有点局限。

第三派是瑞芯微 RK3588这类通用 SoC。它的优势是价格亲民、接口丰富、6 TOPS NPU 在中等负载下够用，而且 RKNN 工具链在持续迭代，社区资料越积越多，很多做机械臂和室内机器人的团队都喜欢用它。缺点是 NPU 的峰值算力在重型模型面前有些吃力，跑大模型时内存带宽也吃紧。

第四派是全志、安凯这类更轻量级方案，以及华为昇腾、寒武纪等偏国产信创方向的方案。华为昇腾在端侧的 Atlas 系列算力密度不错，但开发工具链上手曲线陡峭，适合有大厂支持的团队。

2.2 端侧模型的算力估算方法，别再拍脑袋了

到底怎么算一个模型在端侧需要多少算力？如果你去问芯片厂商，他们一般会给你一个乐观的 TOPS 建议，但那个数字往往是拿最优化模型跑出来的，真实场景基本到不了。我这里给出一套自己反复验证过的粗估方法，不敢说精确，但比拍脑袋靠谱一个量级。

假设你要在端侧跑一个 YOLOv8s 目标检测模型，输入分辨率 640×640，在 Jetson Orin Nano 上实测的 NPU 算力占用大约是 4TOPS 到 6TOPS（依框架和量化程度而定）。如果用更重的 YOLOv8m，算力需求大概要翻倍到 8TOPS 到 10TOPS。如果跑的是视觉 Transformer 类模型如 DETR，由于 Attention 机制的计算模式不同，相同参数量的模型对 NPU 的要求往往比 CNN 高 2 到 3 倍。

更准确的方法是先跑一遍模型 FLOPs（浮点运算次数），然后按公式估算：所需算力 = 模型FLOPs × 帧率 ÷ 芯片利用率。我举个例子，YOLOv8s 的 FLOPs 大约是 28.7G（即 287 亿次浮点运算）。如果目标帧率是 30FPS，理论算力需求就是 28.7G × 30 = 861GFLOPs，约等于 0.86TOPS@FP32。但如果芯片跑的是 INT8 量化，NPU 的标称 TOPS 通常按 INT8 算，且考虑实际利用率通常在 30% 到 60%，那你就需要预留 2 到 3 倍的余量。按这个逻辑，0.86TOPS 的理论值乘上 3 倍余量，大约需要 2.6TOPS 以上才跑得流畅。

这个估算把账算明白之后，你就知道为什么“标称 6TOPS”的 RK3588 跑 YOLOv8s 时已经有点紧张，因为还得把 CPU 资源留给 SLAM 和其他任务。所以我做项目时习惯把每个模型都按这个方式列成一张表，逐项加总算力，最后得出需要采购的硬件阈值。这样选出来的芯片至少不会出现“跑一个模型就吃满所有资源”的尴尬。

2.3 车规与机载场景下硬件选型的“硬指标”

环境适应性这块，我吃过不少亏。第一次做户外无人车时图便宜买了工业级开发板（标注 0℃ 到 60℃），夏天在柏油路面晒半小时，机箱内温度直接干到 70℃，系统就开始频繁降频，图像处理帧率从 30 掉到 10，整个车辆的避障反应肉眼可见地变迟钝。后来换用宽温版本（-40℃ 到 85℃），配合主动散热才彻底解决问题。

车载和机载场景对于硬件的要求是有明显区别的，我帮你梳理几个关键差异：

• 工作温度：车规级一般要求 -40℃ 到 85℃（部分位置 105℃），机载环境因为空中温度低，反而更怕的是地面暴晒和电子设备自热，一般 -40℃ 到 70℃ 够用。
• 振动冲击：车载要过 ISO 16750 等标准，机载则要看无人机本身的振动谱，多旋翼的高频振动对焊接点和连接器是巨大考验，必须用带锁扣的连接器并点胶固定。
• 供电波动：车载 12V/24V 系统在启动瞬间电压跌落很严重，需要宽压输入（9V 到 36V）的电源模块；机载电池放电平台变化大，3S 锂电池从满电 12.6V 到低压 9V，如果板卡只支持 12V 窄压输入，会在飞行中途突然关机。
• EMI/EMC：车载对电磁兼容有明确要求，尤其是和电机驱动器、无线模块共存时，屏蔽和滤波设计必须到位。

这些硬指标不像 TOPS 那样写在宣传页最显眼的位置，但恰恰是它们决定了你的设备在现场会不会“撂挑子”。

2.4 散热设计、功耗墙和降频保护

算力芯片发热是绕不过去的坎。我打个比方，NPU 工作时就像一个小火炉，算得越快，火炉烧得越旺。如果热量散不出去，芯片内部的温度传感器就会触发降频保护，本来能跑 30TOPS 的性能，瞬间掉到不到 10TOPS。

在车载场景，由于空间相对宽裕，可以用主动风冷或水冷，但我实测下来风冷在户外沙尘环境下问题很多，散热鳍片会被灰尘糊住，效率直线下降。后来我转向了铝制外壳被动散热加导热垫的方案，虽然重量增加了，但可靠性提升非常显著。机载场景则麻烦得多，无人机对重量极度敏感，加一个几十克的散热片都可能影响续航和飞行性能，所以更推荐选用本身功耗低的芯片，并把算力运行点控制在峰值功耗的 70% 到 80%，给热设计留余量。

还有一个很隐蔽的功耗坑：开发板的标准功耗和满负载实际功耗往往差很多。我实测过某款标称 15W 的开发板，在 CPU 和 NPU 同时满载时整板功耗能到 28W。如果你按照 15W 去做电源设计，系统很可能在满负载工作时供电不足，导致莫名其妙的重启。我的做法是，选型后立刻做一次持续 30 分钟以上的满负载压力测试，记录实际功耗峰值和稳态温度，用这个数据去设计电源和散热，而不是轻信规格书。

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

3.1 端侧 AI 硬件选型需求拆解：从零开始的实操清单

这里我直接把一套可复用的需求拆解方法写出来。我每次接新项目，都会先按照下面这个顺序做一轮信息收集和计算，再进入选型阶段：

1. 搞清楚传感器配置：几个摄像头（分辨率、帧率、接口类型）、几路激光雷达、有没有麦克风阵列、有没有 IMU。每一种传感器都会占 CPU 或专门接口的资源。
2. 列出要跑的算法模型清单：检测模型、分割模型、姿态估计、语音模型、SLAM 等。如果项目还没定算法，就按照行业典型配置先估算。
3. 测算每种模型的计算需求：用 2.2 节的方法，按目标分辨率、帧率、量化方式（FP16/INT8）分别计算所需的 TOPS，汇总出一个目标算力区间。
4. 评估内存需求：以最大的那个模型为准，模型权重加激活值一般需要 2 到 4 倍的内存余量，再叠加多路传感器的帧缓冲，给出内存容量和带宽的要求。
5. 梳理接口需求：摄像头走 MIPI-CSI 还是 USB？激光雷达走 Ethernet 还是串口？电机驱动器走 CAN 还是 PWM？执行器是否要 EtherCAT？
6. 明确功耗和热边界：整机供电容量、允许的最大热耗散、机箱尺寸和散热方式。
7. 考虑部署环境：车内温度范围、户外暴晒强度、是否有沙尘、是否震动剧烈。
8. 确定生命周期与供应链约束：预计出货量、项目周期、可接受的芯片交期和替代方案。

这套需求清单完成后，你手里就有了一张“需求卡片”，拿着它去对比不同芯片方案，效率会高非常多。如果你还想更系统化一点，可以去下载《人形机器人与具身智能标准体系》的 PDF 看看，里面对于机器人整机、模块、接口的标准划分思路还挺有参考价值的。

3.2 主流端侧 AI 开发板/模块实测横评

接下来把重点落在实测数据上。我从手头用过的板卡里挑几款有代表性的，列一个横评表格，数据均来自我自己的实际测试环境（同一散热条件下跑同一套模型负载，环境温度 25℃，结果仅供参考）：

注意看这个表格里的“实测可用算力”和“标称算力”差距，这就是我一直强调的：芯片厂商给的标称值通常是理论峰值，真实跑模型时，算子调度、内存访问、散热降频等因素都会打折扣。所以我做方案设计时，通常会按标称值的 50% 到 70% 去估算可用算力，宁可多留余量，也不要让系统在关键时刻喘不过气。

3.3 端侧 AI 部署时的模型转换与量化避坑

算力芯片选完只是第一步，把模型跑起来才是真正考验功力的地方。我遇到过太多人在模型转换和量化阶段反复折腾，本来在 GPU 上跑得好好的 PyTorch 模型，转成端侧格式后精度掉得惨不忍睹，或者干脆编译失败。

模型转换的第一步是确认算子支持情况。每个芯片平台的工具链都有自己的算子库，比如英伟达 TensorRT、地平线 OpenExplorer、瑞芯微 RKNN-Toolkit2。如果你的模型里有工具链不支持的算子，最常见的处理方式有两种：一是改用等价算子组合替代，这需要你对网络结构有比较深的理解；二是把不支持的算子放回 CPU 执行，但会带来额外的数据传输开销，拉低整体性能。我建议你在设计模型结构阶段，就先查好目标工具链支持哪些算子，能避免的算子（比如某些冷门激活函数、自定义层）提前换掉，能省非常多事。

量化是另一个大坑。INT8 量化后模型体积缩小到原来的四分之一，推理速度也快很多，但精度损失是必须面对的。我常用的一个流程是：先做校准数据集采样（通常几百张到上千张有代表性的图），然后做量化感知训练或后训练量化，接着在端侧跑一轮完整测试集，对比精度。如果精度下降超过可接受范围，就改用混合精度量化或只量化部分层。还有一个很容易被忽略的点：量化对输入数据的分布非常敏感，你训练的图片和部署现场的光照分布差异大，量化后精度劣化会更明显。

实操层面，我整理了几条部署时的核心建议：

• 先在 PC 端模拟环境里把模型完整跑通，再上板调试，不要一上来就在开发板上折腾。
• 每转一次格式就做一次输出比对，用同一张输入图分别跑原始模型和转换后模型，检查关键层输出误差。
• 注意输入输出的数据格式和归一化方式，端侧工具链对通道顺序（RGB/BGR）、数据排布（NCHW/NHWC）的要求各不相同，任何一处不匹配都会导致结果离谱。
• 性能测试要使用至少 1000 次推理取平均值，单次推理时间受缓存影响太大，不能代表真实水平。

3.4 完整项目实操：室外巡检无人车算力平台搭建实录

拿我去年的一个室外巡检无人车项目做完整演示。需求是：在园区道路上自动巡逻，识别车辆、行人和异常物体，并把结果回传后台，同时做简单的避障偏移。

硬件方案最终定为：Jetson Orin Nano 8GB作为主算力板，配合一个 STM32 作为底层运动控制 MCU，传感器用了两个 1080P USB 摄像头和一个单线激光雷达。选 Jetson Orin Nano 的原因是它的软件生态成熟，CUDA 加持下部署目标检测模型非常顺滑，而且 8GB 内存能够容纳我要跑的 YOLOv8s 模型加 SLAM 节点。

软件框架我采用 ROS 2（Humble 版本），感知模块用 TensorRT 加速的 YOLOv8s，建图定位用 Google Cartographer 的单线激光雷达模式。整个系统的节点拓扑大致是：摄像头节点采集图像发布到话题，感知节点订阅图像后做检测并发布检测结果，SLAM 节点通过激光雷达数据发布位姿，规划节点订阅检测结果和位姿后输出速度指令，最后由底层 MCU 通过串口接收指令控制电机。

实际跑起来后的效果：在 15W 功耗模式下，检测帧率稳定在 28 到 30FPS，CPU 占用率约 55% 到 70%，NPU 占用率约 60% 到 80%，内存占用 3.5GB 左右。这个负载已经比较接近性能上限了，所以在后续迭代中我会考虑裁剪模型结构、减少不必要的后处理计算，来给未来加入的新功能腾出余量。

这里有一个我在实操中总结的重要经验：端侧系统一定要预留至少 30% 的算力和内存余量。因为现场的算法迭代是必然的，模型每次升级都可能更重，如果一开始就把硬件跑满，后面每次迭代都等于在刀尖上跳舞，体验非常痛苦。

3.5 机载场景的特殊处理：重量、功耗和散热的三重博弈

机载平台和车载相比有一个额外的约束维度：重量。车载多 100 克重量根本无所谓，但无人机每多 1 克都在和续航过不去。我做过一个四旋翼视觉巡检项目，整机起飞重量限制在 2500 克，留给算力平台的重量预算只有 150 克。在这个重量下，Jetson Orin Nano 加散热底座就已经接近 100 克，再配合稳压模块、线缆和固定结构，150 克几乎用完，完全没有加主动风扇的余地。

这种情况下只能走“低功耗+被动散热”的路线。我把 Orin Nano 设置在 7W 功耗模式，用一块定制铝板作为被动散热片，同时将算力板放置在机架中间位置，利用旋翼下洗气流辅助散热。实测下来，在 25℃ 环境温度、持续满载跑 20 分钟的工况下，核心温度稳定在 78℃ 左右，虽然偏高但尚在安全范围。如果环境温度升高到 35℃，就需要限制任务负载或降低功耗模式，否则会触发降频。

机载场景的电源设计也要特别注意。很多飞控和动力系统对电压纹波敏感，如果算力板突然拉高电流导致电压波动，有可能干扰飞控的传感器读数，严重的甚至会影响到飞行稳定性。我的做法是：算力板使用独立的 DC-DC 稳压模块供电，并在输入端加足够容量的钽电容和LC滤波，让算力板的供电和飞控系统在电气上尽量隔离，实测下来干扰问题大幅缓解。

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

4.1 实测中遇到的高频故障和排查思路

做端侧 AI 项目这么久，收集了一堆真实故障案例。每个故障背后都是一个选型或部署的教训，我把它们整理成速查表，方便你以后参考：

以上每一个问题我都在真实项目中遇到过，而且往往不是单一原因，需要结合 PCB 布局、软件配置、机械设计几方面联动排查。一旦遇到别着急，先按优先级查温度、电压、日志、频率四件事，大多数问题能解掉 80%。

4.2 工具链对比与逃不掉的“生态税”

端侧 AI 部署最耗时间的部分往往不是模型训练，而是“生态适配”。业界把它形容为生态税——你选择了一个硬件平台，就得接受它的工具链、文档、示例代码和社区成熟度带来的隐性成本。

英伟达的生态税最低，因为大部分开发者从 PyTorch/TensorFlow 起步，转到 TensorRT 的路径最短，踩坑的人多，网上资料也多，遇到问题随便搜一下就有答案。地平线面向国内车厂做了很多定制，如果你的项目落在智能驾驶领域，它的 BEV 感知套件和算子优化相当省事，但做通用机器人时经常会遇到“这个算子为什么还不支持”的困惑。瑞芯微的 RKNN 工具链这两年进步很大，对 PyTorch 模型的支持越来越完善，开源社区的案例也越来越多，而且毕竟价格摆在那里，很适合起步阶段的项目。

我个人的通用建议是：在项目早期花 3 到 5 天时间，把目标平台上最常用的 3 个模型（比如目标检测、关键点检测、语义分割）完整部署一遍。如果这 3 个模型能在 5 天内跑通且精度满足要求，就选它；如果连示例模型都跑得艰难，后面正式开发一定会被拖垮。这个“5 天验证法”帮我筛掉了好几个看似参数强悍但工具链稀烂的方案。

4.3 供电与接口的细节避坑

车载和机载项目里，供电和接口的坑最隐蔽，但一旦踩中往往是灾难性的。供电方面，有一类典型问题：算力板启动瞬间电流非常大，经常能达到稳态电流的 2 到 3 倍。如果你选用的电源模块不支持这么大的峰值电流，板子就会在启动瞬间电压跌落，导致反复重启。我遇到过一块板子冷启动时电流达到 6A，但稳态只有 2A，最初用的 3A 电源模块怎么都起不来，换成 8A 模块后一次点亮。

接口方面的坑主要体现在引脚复用和信号电平上。很多 SoC 的引脚是复用的，比如某个引脚既可以做 UART 又可以做 PWM，如果你在设备树里配置错，轻则外设不工作，重则整个系统起不来。信号电平问题在连接舵机、电机驱动时特别常见，3.3V 的逻辑电平连 5V 的舵机控制线，虽然大多数情况下能工作，但在干扰大的环境里就可能出现误触发。我在项目中会统一处理电平转换，所有跨电平的信号都加电平转换芯片，从源头上杜绝这类不稳定因素。

雷达和摄像头这类高速传感器的接口也值得提防。USB3.0 接口对线缆质量非常敏感，劣质线缆会导致传输错误，表现就是图像偶尔花屏或者设备掉线。我后来全部改用带屏蔽的工业级线缆，并且尽量缩短线缆长度，问题率大幅下降。

5. 写在最后：我的选型心法和建议

端侧 AI 算力选型这件事，本质上是平衡的艺术。你必须把功耗、性能、生态、成本、供应链放在同一个天平上称量，任何单一维度的惊艳都无法弥补其他维度的短板。经历过这么多项目之后，我的核心心法可以浓缩成一句话：先算清楚需求，再去看参数；先跑通模型，再谈优化；先理解场景约束，再做最终决策。如果你能牢牢记住这条主线，在车载和机载场景下做具身智能项目时，大概率能绕开我曾经踩过的大部分坑。

第二点建议是，选型文档一定要沉淀。我每做一个项目都会把需求拆解表、芯片对比评分表、实测数据、故障记录整理成一个标准模板，方便下一个项目直接复用。很多人觉得这是浪费时间，但当你第三次面对“芯片选型该看什么”这个问题时，会发现这套模板帮你节省的时间远远超过当初整理它花费的时间。

最后一点，别忽视社区和交流。芯片选型这种事，厂商的规格书永远是“报喜不报忧”，但社区里的真实用户从不掩饰痛点。多去翻翻中文社区、开发者论坛和开源项目里的问题区，那些“为什么我的 Orin Nano 跑不到标称算力”之类的帖子，往往是比规格书珍贵得多的情报。工具是死的，经验是活的，愿这篇避坑指南能帮你少走我走过的弯路，把精力真正花在具身智能的算法和产品创新上。