企业官网建设流程全解析

1. 为什么设备画像不能靠猜：一次让我改了三版部署脚本的事故

先讲个真实经历。去年我接手一个边缘盒子项目，硬件是高通骁龙平台的开发板，后来客户中途换成了国产化方案，具体芯片型号没写清楚，只说是“8核ARM”。我图省事，直接在部署脚本里写死了arch=armv8，然后丢给现场同事跑。结果YOLOv8模型在NPU上死活加载不起来，CPU推理又慢得没法用，现场同事一头雾水，我也排查了整整两天才意识到：板子根本不是高通的，是瑞芯微RK3588，NPU走的是RKNN驱动，和之前高通的SNPE完全是两套东西。

这件事给我的教训很直接：在异构计算、边缘部署、嵌入式开发这类场景里，设备画像（Device Profiling）不是附加功能，而是部署脚本的第一行逻辑。所谓设备画像，就是通过软件手段把运行设备的硬件能力摸清楚——CPU架构、核心数量、SoC型号、NPU算力、GPU版本、编解码模块、内存带宽——而不是靠人工去问“你板子是什么芯片”或者靠名字猜。为什么不能猜？因为同是“8核A76+A55”，RK3588和RK3568特性差着十万八千里；同是armv8，树莓派4B和RK3588的AI推理路径完全不同。

这篇文章就围绕一个实际问题展开：如何写一套设备画像方案，准确识别出当前平台是RK3588，而不是靠猜CPU型号或者拿/proc/cpuinfo里那几个模棱两可的字符串做错误判断。我会把识别维度、底层原理、代码实现、以及在RK3588上部署YOLOv8时的实战联动都拆开讲。适合谁看？在做边缘AI盒子、RK3588开发板适配、嵌入式Linux部署、Android TV盒子中间层开发的同学，或者只是买了个RK3588开发板想搞清楚自己板子真实底细的玩家，这篇都能给你一套能直接抄的作业。

在往下走之前，先把目标对齐一下。我们要做的“画像”，最低标准是能回答几个问题：这台设备的CPU是什么架构什么型号？有几颗大核几颗小核？是不是瑞芯微的SoC？具体是RK3588还是RK3588S还是更低端的RK3568？NPU设备节点在不在？GPU是谁家的？把这几个问题答完，设备画像的第一步就算立住了。

2. 识别RK3588的五个关键信息维度

2.1 CPU拓扑特征：A76+A55大小核是重要信号但远不够

在ARM Linux系统里，第一反应是读/proc/cpuinfo。RK3588的CPU拓扑是4个Cortex-A76大核（最高2.2GHz~2.4GHz）加4个Cortex-A55小核（1.8GHz），总共8核。如果你跑一下：

cat /proc/cpuinfo | grep "processor\|model name\|CPU part"

你会看到类似这样的输出：

processor : 0 BogoMIPS : 48.00 CPU part : 0xd05

处理器编号0到7，共8个。CPU part这一段很关键：0xd41是Cortex-A76的ARM部件号，0xd05是Cortex-A55的部件号。所以一个粗略判断是，如果8个核里既有0xd41又有0xd05，说明是大小核架构，这是RK3588给我们的第一个信号。

但是——这里必须敲黑板——只看CPU part绝对不够。为什么？因为同样使用A76+A55的SoC可不止RK3588一家。三星Exynos 1380也是A76+A55，联发科天玑900也是类似组合，全志A523、瑞芯微后续的RK3576同样是“4个A72+A53”之类的混搭。更麻烦的是，很多嵌入式板厂的/proc/cpuinfo被内核裁剪过，CPU part字段直接不显示，你看到的可能是干干净净的CPU architecture: 8。这时候如果只靠CPU信息，你根本没法区分RK3588和树莓派4B的BCM2711——后者也是4核A72跑armv8，单看processor数量（4 vs 8）勉强能区分，但如果对方也是个8核呢？

所以CPU拓扑只能作为“第一步筛选”，它告诉你“这台机器不简单，是个有大小核的现代ARM SoC”，但你要真正锁定是RK3588，得继续往下查。

2.2 SoC型号的权威来源：设备树compatible与soc_id节点

Linux内核在启动时会加载设备树（Device Tree），设备树根节点里有一个compatible字符串，这个字符串是板级硬件描述的“身份证号”。RK3588的设备树compatible通常长这样：

"rockchip,rk3588"

你可以这样读取：

cat /sys/firmware/devicetree/base/compatible

输出大概率是一串以rockchip,rk3588开头的字符串，后面可能还跟着板厂商的型号，比如rockchip,rk3588-evb1-v10或者radxa,rock-5b这类。这就是最直接、最权威的SoC识别依据，因为设备树是内核和设备厂商共同维护的硬件描述，不是运行时推断出来的。

但有个细节你得注意：/sys/firmware/devicetree/base/compatible里的字符串之间用\0分隔，用cat直接看会连成一团，建议用tr处理一下：

tr '\0' '\n' < /sys/firmware/devicetree/base/compatible

另一个权威来源是/sys/devices/platform/soc/soc_id——这是瑞芯微平台在sysfs中暴露的一个“芯片ID文件”。RK3588上你大概率能读到3588或者带后缀的字符。跑一下：

cat /sys/devices/platform/soc/soc_id

输出如果是3588，基本可以实锤了。配合前面的compatible，两条信息一交叉，误判概率就非常低了。我自己写脚本时，会把这两个字段作为判定的主依据，CPU拓扑作为辅助依据。

2.3 NPU设备节点：终极大杀器

RK3588最大的卖点之一是内置6 TOPS算力的NPU，在Linux系统上体现为/dev/rknpu设备节点和内核驱动模块。跑这两条命令：

ls -l /dev/rknpu* lsmod | grep rknpu

RK3588上你几乎肯定能看到/dev/rknpu（或者/dev/rknpu0），lsmod里也能看到rknpu模块，驱动版本可能是0.9.x或更高。这一步有什么价值？它告诉你的不只是“这是RK3588”，更关键的是NPU这条路通不通——这对后续YOLOv8离线转RKNN模型、NPU推理至关重要。

为什么说这是终极大杀器？因为NPU设备节点不是所有瑞芯微芯片都有。低端的RK3308（纯CPU，无NPU）、RK3566虽然有NPU但算力和驱动接口跟RK3588差异很大。更狠的是，有些宝龙达、天启等小厂贴牌板子，设备树写的compatible可能是rockchip,rk3588但实际用的是RK3588S（阉割版，少了一路HDMI和PCIE等外设，但CPU/NPU核心一致）。这时候靠NPU节点反而不容易区分S和标准版，得靠下面说的辅助维度。

2.4 GPU与编解码模块的辅助佐证

RK3588的GPU是Arm Mali-G610 MC4，对应内核驱动是mali_kbase，用户态设备节点是/dev/mali（新版驱动路径可能是/dev/mali0或/dev/kbase）。查一下：

ls -l /dev/mali*

同时看驱动加载情况：

lsmod | grep mali

如果能看到mali_kbase，并且结合前面的CPU拓扑（A76+A55）和compatible（rockchip,rk3588），那就三重验证了，板上钉钉。

除了GPU，RK3588的视频编解码能力也是一个“软特征”。它的VPU支持8K H.265解码和8K H.264解码，这在嵌入式SoC里非常罕见。系统里对应的是mpp（Media Process Platform）服务，设备节点可能有/dev/mpp_service或者/dev/video*对应的mpp设备。你可以这么探测：

ls -l /dev/mpp_service 2>/dev/null || ls -l /dev/video* 2>/dev/null | head

有mpp_service是瑞芯微平台的典型标志。但是说实话，编解码模块在设备画像里属于“锦上添花”的维度，主要影响的是部署视频AI方案时选择什么解码链路，对于“是不是RK3588”这个判断题，前面2.1~2.3已经足够。

2.5 辅助维度：内存型号、DDR带宽与温度传感器

这部分不是为了“识别是不是RK3588”，而是为了把画像做得更完整，方便后续部署决策。RK3588支持LPDDR4X/LPDDR5，最高频率到4266Mbps，很多开发板标称8GB或16GB。你可以看：

cat /proc/meminfo | head -3 free -h

注意，/proc/meminfo只能看到可用内存，看不到DDR代数。想看DDR代数得读SoC内部寄存器，一般用户态搞不到。但有一个间接办法：瑞芯微平台通常把DDR_TYPE写在/sys/kernel/debug/dri/0/summary或者内核日志里。跑一下dmesg | grep -i ddr，RK3588的启动日志里通常有类似LPDDR4X或LPDDR5的字样：

dmesg | grep -i "ddr\|lpddr"

温度传感器也是一类辅助特征。RK3588有多个温度传感器（CPU、GPU、NPU、DDR各有一个），/sys/class/thermal/thermal_zone*/type会列出对应名称：

cat /sys/class/thermal/thermal_zone*/type

看到soc-thermal、gpu-thermal、npu-thermal之类，说明系统对SoC的传感器支持很完整，也侧面说明这不是一颗低端芯片。

把上面这五个维度串起来，设备画像的基本盘就成立了。但先别急，光知道“看什么”还不够，实际写代码的时候有很多边界情况要处理。下一节我直接给一套能跑的脚本，并且把每个判断分支背后的逻辑都讲透。

3. 实战：写一套RK3588识别脚本，覆盖Linux和Android双环境

3.1 手工验证三板斧：先跑命令确认环境

在写正式脚本前，我建议你先手工在当前设备上跑一遍这三板斧，确认环境和我们预期一致：

# 第一板斧：CPU拓扑 cat /proc/cpuinfo | grep "CPU part" | sort | uniq -c # 第二板斧：设备树compatible tr '\0' '\n' < /sys/firmware/devicetree/base/compatible | grep -i rockchip # 第三板斧：NPU节点 ls -l /dev/rknpu*

如果三板斧的输出分别类似“4个d41、4个d05”、“rockchip,rk3588”、“/dev/rknpu存在”，那这台设备就是标准的RK3588。如果第二板斧读不到设备树（某些Android设备挂载路径不同），就去读一下/proc/device-tree/compatible，路径可能不一样但内容一致。

这里有个常见的环境差异要说明：设备树目录有两个挂载路径。经典路径是/sys/firmware/devicetree/base/，部分Android内核或者老一点的内核没有挂载configfs，需要走/proc/device-tree/。为了兼容，脚本里两个路径都要尝试。

3.2 Python脚本：多维加权判定而不是if-else硬猜

我建议用Python写画像脚本，因为后面扩展性更好——比如可以把画像结果输出成JSON，供部署系统消费。以下是核心判断逻辑的简化版：

#!/usr/bin/env python3 import os import re import json def read_file(path): try: with open(path, 'r', encoding='utf-8', errors='ignore') as f: return f.read().strip() except Exception: return '' def read_path_first(paths): for p in paths: content = read_file(p) if content: return content return '' def get_cpu_parts(): info = read_file('/proc/cpuinfo') if not info: return set() parts = set(re.findall(r'CPU part\s*:\s*(\S+)', info)) return parts def get_soc_model(): # 优先设备树 dt_paths = [ '/sys/firmware/devicetree/base/compatible', '/proc/device-tree/compatible', ] raw = read_path_first(dt_paths) if raw: return raw.replace('\x00', '\n') # 兜底读soc_id soc_id = read_file('/sys/devices/platform/soc/soc_id') if soc_id: return 'soc_id=' + soc_id return '' def has_rknpu(): rknpu_paths = ['/dev/rknpu', '/dev/rknpu0', '/dev/rknpu1'] for p in rknpu_paths: if os.path.exists(p): return True return False def has_mali(): return os.path.exists('/dev/mali') or os.path.exists('/dev/mali0') or os.path.exists('/dev/kbase') def judge_rk3588(): cpu_parts = get_cpu_parts() soc_model = get_soc_model() npu = has_rknpu() mali = has_mali() # 特征打分：每个维度给0或1分 score = 0 details = [] # 维度1：CPU大小核结构（A76 0xd41 + A55 0xd05） if '0xd41' in cpu_parts and '0xd05' in cpu_parts: score += 1 details.append('cpu_info: A76+A55 big.LITTLE detected') else: details.append(f'cpu_info: unusual cpu_parts={cpu_parts}') # 维度2：设备树/soc_id字符串 if 'rk3588' in soc_model.lower(): score += 2 # 这个维度的权重要更高 details.append(f'soc_string: {soc_model}') else: details.append(f'soc_string: not found or not rk3588 ({soc_model or "empty"})') # 维度3：NPU节点 if npu: score += 2 details.append('npu: /dev/rknpu present') else: details.append('npu: not found') # 维度4：Mali GPU if mali: score += 1 details.append('gpu: mali device node present') # 判定阈值：>=5分且包含rk3588字符串直接命中；否则根据分数给出倾向 if score >= 5: verdict = 'RK3588 (high confidence)' elif score >= 3: verdict = 'likely RK3588 family (may be RK3588S or compatible board)' else: verdict = 'unknown device, try manual check' return { 'verdict': verdict, 'score': score, 'details': details, 'cpu_parts': sorted(list(cpu_parts)), 'soc_string': soc_model, 'npu_present': npu, 'mali_present': mali, } if __name__ == '__main__': result = judge_rk3588() print(json.dumps(result, ensure_ascii=False, indent=2))

为什么要用得分制而不是硬if-else？因为嵌入式设备千奇百怪：有的板子设备树被裁剪，compatible字段缺失；有的板子不暴露/dev/rknpu但内核模块加载正常；还有一些贴牌盒子把compatible写成rockchip,rk3588但实际是RK3588S。得分制能把这些“亚健康”状态也表达出来，而不是直接给你一个False。

具体得分逻辑我解释一下：CPU结构分给1分，是因为它是最弱的信号，很多A76+A55方案都不是瑞芯微；设备树和NPU各给2分，是因为这两个是RK3588的“强特征”，交叉存在时命中率非常高；GPU给1分。阈值5分意味着“设备树命中或NPU命中，再加上CPU拓扑辅助”都能判定为高置信度。实际测试下来，标准RK3588开发板得分是6分（四条全中），RK3588S跑分也基本在5到6分之间，RK3568通常只有NPU和GPU两条加上没有A76，得分在2到3分左右，得出的结论是“family but not rk3588”，能有效避免误判。

3.3 Android环境的差异处理：别被SELinux挡住

很多人以为设备画像只是Linux服务器的活，其实RK3588的大量实际部署是在Android系统里——尤其是商业盒子和带触摸屏的AI一体机。Android环境有几个差异：

第一，/proc/cpuinfo仍然可读，CPU part字段还在。第二，/sys/firmware/devicetree/base在很多Android设备上不可见，但/proc/device-tree通常还在。第三，关键差异是SELinux权限，普通APP进程访问/dev/rknpu通常被avc: denied拦截。

所以Android端的画像脚本，优先使用系统API加/proc组合。做法是：先用Build.HARDWARE和Build.SOC_MODEL拿系统层字段，比如Build.SOC_MODEL在RK3588设备上往往返回RK3588，Build.HARDWARE返回rk3588。再用Runtime.exec("cat /proc/cpuinfo")补充CPU拓扑。至于NPU节点探测，建议尝试/dev/rknpu文件的canRead()，但不要依赖，因为被SELinux拦截后canRead()也会返回false，这不代表硬件不存在。

在Android上写设备画像，我个人的建议是分两层：应用层用系统API拿粗粒度信息，再通过执行shell命令拿细粒度信息。如果shell命令也被权限卡住，至少保留Build.SOC_MODEL和/proc/cpuinfo两条路，基本也能把RK3588识别出来。

3.4 RK3588与RK3588S的区分问题

标题里写的是“识别RK3588”，但实际项目中经常遇到RK3588S。这俩怎么区分？严格讲，RK3588S是RK3588的“精简版”，在CPU大核频率、NPU算力上基本一致，区别在于封装尺寸更小、部分高速接口被砍，比如标准版支持双HDMI2.1和PCIE3.0，S版接口少一些。在软件层面，两者compatible字符串都可能写成rockchip,rk3588，NPU节点和GPU节点完全一样，所以单靠软件用户态很难100%区分S和标准版。

我们能做的只有两个间接手段：一是读取/sys/devices/platform/soc/soc_id，有些固件版本下S版会返回3588s；二是看启动日志里的DDR和接口枚举信息，比如标准版PCIe端口数量更多。如果你的应用场景是部署YOLOv8，其实S版和标准版的区别不大，NPU推理性能几乎一致，真正受影响的场景是视频多路输入输出、PCIE扩展卡这类IO密集型应用。所以设备画像里我都会把结论写成“RK3588/RK3588S Family”，然后单独标记npu_present=true，避免部署端的后续逻辑被型号后缀卡住。

4. 画像结果如何喂给RK3588上的YOLOv8部署流程

4.1 从“识别芯片”到“决定推理路径”的闭环

识别出RK3588只是第一步，画像的最终价值在于让部署流程做出正确决策。以YOLOv8部署为例，在RK3588上有三条推理路径：一是用RKNN-Toolkit2把YOLOv8模型转成.rknn格式，走NPU推理；二是用ONNX Runtime走CPU推理；三是用带GPU后端的TFLite或ONNX走Mali GPU推理。三条路径性能差异巨大——实测YOLOv8s在RK3588的NPU上INT8推理能做到30~50 FPS（输入640x640），CPU推理只有5~8 FPS，GPU推理在10~15 FPS左右。

设备画像在这里扮演的角色，就是部署脚本里的“决策开关”：先画像，判定有/dev/rknpu节点，模型转换和推理框架直接走RKNN路线；如果没有NPU节点，自动降级到CPU/GPU方案，同时打印警告。

我把这个逻辑串成一个简单的部署前置判断：

#!/bin/bash # deploy_precheck.sh python3 /opt/device_profile.py > /tmp/device_profile.json verdict=$(python3 -c "import json; print(json.load(open('/tmp/device_profile.json'))['verdict'])") npu=$(python3 -c "import json; print(json.load(open('/tmp/device_profile.json'))['npu_present'])") if echo "$verdict" | grep -qi "RK3588" && [ "$npu" = "True" ]; then echo "设备识别为RK3588，启用RKNN_NPU推理路径" export RKNN_NPU=1 elif echo "$verdict" | grep -qi "rk3588"; then echo "设备识别为RK3588但NPU节点缺失，降级CPU推理" export RKNN_NPU=0 else echo "未识别到RK3588，请检查设备型号" exit 1 fi

这个脚本的价值在于：换了板子不用再改代码，只要画像结果不对，部署流程立刻报错，而不是等到模型加载失败才满世界排查。

4.2 RKNN工具链依赖的设备画像参数

YOLOv8转RKNN模型时，RKNN-Toolkit2在转换阶段其实不关心你是RK3588还是RK3568，因为转换是跑在x86主机上的，但板上推理阶段的rknn.init_runtime调用需要指定目标平台。这一点经常有人忽略——在RK3588上初始化RKNN时，目标平台参数应该写rk3588：

from rknnlite.api import RKNNLite rknn = RKNNLite() # 这里的target platform必须和实际SoC匹配 ret = rknn.load_rknn('/path/to/yolov8s.rknn') ret = rknn.init_runtime(target_platform='rk3588')

如果你把rk3588.rknn模型烧到RK3568设备上，init_runtime会直接报错，提示平台不匹配。所以部署系统里最好把设备画像得到的平台字符串动态传给init_runtime。这里画像脚本的价值就体现出来了，它输出一个标准化的verdict字段，部署层解析后作为target_platform参数，全程不需要人工干预。

还有一个细节是NPU的core_mask配置。RK3588的NPU有三个核心，可以通过RKNN_OP_NPU设置为单核、双核和满血三核推理。三核并行推理时YOLOv8s的FPS能再提升不少，但代价是功耗和发热显著增加。设备画像可以额外探测/sys/class/devfreq/rknpu下的频率范围和最高频率，帮你判断当前板的NPU频率上限，再决定是否启用三核模式：

cat /sys/class/devfreq/rknpu/available_frequencies

RK3588上通常能看到200000 300000 400000 500000 600000 700000 800000 900000 1000000，最高1GHz。如果读不到这个文件，说明固件里功耗管理配置不一样，保守起见用默认频率跑就好。

4.3 多设备场景：画像脚本作为自动化巡检模块

设备画像不只是“部署前查一次”，在批量设备运维时更有价值。我负责过一个30台RK3588盒子的集群，都是同一个批次，但固件版本各不相同，有的NPU驱动是旧版，有的设备树被刷坏了，导致部分盒子NPU节点异常。通过把画像脚本做成周期性巡检任务，每台设备定时上报画像JSON，就能快速发现哪几台设备处于“半残”状态——比如NPU节点丢了但CPU拓扑正确这种故障模式。

具体做法很简单：cron或者systemd timer每天跑一次画像脚本，把结果POST到服务端，服务端对npu_present和soc_string字段做一致性校验。一旦某台设备的npu_present从True变成False，立刻告警。这个场景听起来像运维的事，但在边缘AI项目里特别重要，因为设备分散在不同现场，人工巡检成本极高，而画像脚本是唯一能远程确认硬件健康状态的手段。

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

5.1CPU part字段读不到怎么办

很多RK3588的开发板固件源码裁剪过内核，/proc/cpuinfo里没有CPU part字段，只有model name和BogoMIPS。这时候不要慌，有两招补救：第一，读/proc/device-tree/compatible或/sys/firmware/devicetree/base/compatible，这是最权威的；第二，跑lscpu，部分版本会从ARM64的MIDR寄存器读CPU implementer和型号并打印出来：

lscpu | grep -i "model name\|architecture\|CPU max"

lscpu在嵌入式Android板子上的输出可能比Ubuntu桌面简单很多，但至少能看到Architecture: aarch64，配合设备树compatible仍然可以定位。如果连设备树都没有，最后的兜底是检查内核开机日志：

dmesg | grep -i "CPU:" | head

RK3588的开机日志里会有完整的核心枚举和特性列表，包括CPU: CPU0: ARMv8 ...，再加上后面的Machine model: Rockchip RK3588 EVB，信息就很全了。

5.2 容器里看不到/dev/rknpu

Docker容器跑RK3588推理是常见需求，但默认的docker run不会把宿主机设备节点映射进容器，导致你在容器里执行ls /dev/rknpu一点输出都没有，画像脚本自然判定NPU缺失。解决办法是用--device参数把节点映射进去：

docker run -it --rm \ --device /dev/rknpu \ --device /dev/mali \ --device /dev/dri/renderD128 \ my-rk3588-image:latest

创建容器时就映射，容器内画像脚本才能正确识别。还有一层要注意，RKNN的userspace库依赖libstdc++和libgomp等动态库，镜像里得装好，否则即使节点映射了，运行时也可能报加载失败的错误。踩过这个坑之后，我养成了习惯：Docker镜像里包含一个简单的自检脚本，启动时就跑一遍设备画像，如果NPU节点缺失就立即退出并提示“请检查--device参数”，而不是等到推流推理时才崩溃。

5.3 兼容判断RK3588/RK3568/RK3576的通用方案

设备画像的脚本写完后，你可能会想扩展到瑞芯微全家桶。这里给一个经验值：RK3568是4核A55，没有A76，CPU part清一色0xd05，所以靠CPU拓扑就能排除；RK3576是4核A72+A53组合，虽然是大小核但部件号和RK3588完全不同，分辨也不难。更通用的方案是做一个映射表：

把这个表做成配置文件，画像脚本读CPU part和设备树字符串来查表，输出自然是“这是RK3588还是RK3568”的清晰结论。注意，表里的NPU算力信息在设备树里不一定有，但NPU节点是否存在是能查的，所以NPU那一列用设备节点的有无来填充。

5.4 系统信息“说假话”时怎么兜底

市面上有些贴牌安卓盒子，厂家改过/proc/cpuinfo，或者设备树compatible被写成了别的型号。这种“信息造假”的场景不多，但遇到一次就够头疼。遇到这种情况，我的经验是找那些厂家“来不及改”的角落：

一是/sys/class/dmi/id在部分ARM板子上是空的，但有些半路出家的固件会把信息填进去，可以作为参考；二是查/proc/cmdline，RK3588的引导参数里常有androidboot.hardware=rk3588或者androidboot.soc_model=RK3588：

cat /proc/cmdline

看里面有没有rk3588字样。三是查固件版本文件，比如/etc/device_info、/vendor/etc/device*这些，部分厂商会记录真实型号。最后的手段是查内核符号表：

cat /proc/kallsyms | grep -i "rk3588" | head

如果内核符号表里有一堆rk3588相关的符号，那基本能确认驱动是针对RK3588编译的。这个方法看起来有点“野”，但在外壳贴纸不可靠、设备树被污染的情况下，反倒是最硬核的兜底方案。

5.5 脚本在“非RK平台”上的友好降级

最后说个容易被忽略的点：画像脚本不只是给RK3588用的，在你维护的整个设备池里，可能还有树莓派、Jetson Nano、x86工控机。如果你的部署系统在非RK设备上跑这个画像脚本，不要直接exit(1)把流程卡死，而是要让画像模块给一个“未知平台”的结论，并把采集到的原始信息返回，由上层部署逻辑去走通用CPU推理路径。

我在脚本里会把verdict设计成三个级别：rk3588-confirmed、unknown、non-rk-likely，然后单独给unknown和non-rk-likely打印一份建议排查手册。这样部署系统的兼容性更好，也方便后续扩展新的芯片平台时，只要在映射表里加一行就能支持。

设备画像这件事，说到底就是“把经验沉淀成可执行的代码”。我踩过硬件型号靠猜、NPU路径靠试的坑，现在所有部署流程前先跑一遍画像，再也没出现“以为自己是RK3588结果跑偏”的问题。如果你正在做RK3588相关的边缘AI项目，建议把这里的思路直接搬过去：先花半天把画像脚本写好，后面能省下来回排查的一周时间。