这两年“端侧AI”四个字被翻来覆去地讲但我更在意的其实是后半截——“终端”。这个词在圈子里有两层含义一层是嵌入式设备、工控机、智能融合终端这类真正跑业务的硬件另一层是开发者的命令行工具、终端模拟器、远程SSH会话。我做过嵌入式也折腾过各种终端软件给政企环境配过终端安全管理系统越来越发现端侧AI终端真正在填的是“算力必须在现场、数据不能出本地、结果还得实时给出来”这个产品裂缝。拿我去年做的一个设备预测维护项目来说。产线上的振动传感器、温度传感器全天候采集数据PLC和工控机在本地跑异常检测模型预测轴承故障。起初甲方也提过数据上云分析后来发现现场网络时好时坏几条数据回传延迟都在200毫秒以上生产安全根本赌不起。最后还是把模型量化压缩后塞进了终端设备。这个案例基本就是把“端侧AI终端填裂缝”的过程完整演示了一遍。这篇文章不打算聊太多空泛的趋势我想把终端设备跑AI、终端工具链、以及企业终端管理这几条线上我自己实操过的内容整理出来。适合正在做边缘或嵌入式AI的开发者、需要给终端设备配AI能力的产品经理以及每天被各种终端工具折磨的运维同学。1. 端侧AI终端到底填的是什么裂缝1.1 先分清两种“终端”再谈裂缝“终端”这个词的歧义本身就是产品裂缝的一部分。我做嵌入式时终端是设备本身——一块ESP32开发板、一台RK3588工控机、一个带屏幕的智能融合终端它们要完成数据采集、AI推理、结果输出。我做软件开发时终端又变成命令行工具——Tabby、Windows Terminal、VS Code里的内置终端、WSL里的Ubuntu shell它们是我的操作入口。这两种终端之间的断层非常现实。模型在PC上跑得风生水起模型文件烧进ESP32直接内存爆掉模型在服务器上验证完毕要适配到国产化终端时发现推理引擎根本不支持AI应用在开发终端里调试正常部署到生产终端后却被安全管控软件当成未知程序拦截。这些我都踩过而且每一个都能单独写一篇避坑文。所以“端侧AI终端”不是单指硬件也不是单指工具它是从模型训练到端侧部署的整个链路。这个链路里最大的裂缝就是“模型能跑”和“产品能用”之间的距离。本篇文章讨论的核心就是怎么缩短这段距离。1.2 时延、成本与隐私三拳打在云端AI的软肋上云端AI很强但它有三个绕不开的弱点恰好就是端侧AI终端的价值空间。第一个是时延。工业质检、自动驾驶、手势控制这类场景要求毫秒级响应。云端推理哪怕再快也要经受网络传输的物理限制从设备到机房一个往返几十毫秒已经算优秀了但在高速流水线上几十毫秒足以让一个缺陷工件滑过去。更别说网络抖动、基站切换、公网丢包这些不可控因素。第二个是成本。7×24小时运行的产线设备如果每一路视频、每一条传感器数据都送云端算一次流量费和推理费用是持续流血的。我算过一笔账一条摄像头24小时连续上传一个月光流量就是大几百GB按商业云的价格一年下来够买好几块高性能终端主板。端侧AI把推理挪到本地这些成本直接归零。第三个是隐私。人脸、语音、医疗影像、企业经营数据这些数据一旦离开设备就要面对数据合规问题。很多行业的红线是“数据不出域”。端侧AI终端把推理放在本地从物理上规避了数据外泄的可能。对比下来很简单云端AI负责重计算、大数据量的复杂任务端侧AI终端负责低时延、高敏感、断网可用的现场任务。裂缝不是替代关系而是互补关系里的那个空档。对比维度云端AI端侧AI终端典型时延几十毫秒到几百毫秒毫秒级甚至更低网络依赖强依赖断网即失效断网可用单路成本流量推理费用持续叠加一次性硬件成本数据隐私数据需传输到服务端数据留本地模型能力可跑大模型、高精度模型需压缩量化精度受限更新维护服务端统一更新需逐台设备OTA或手动升级1.3 谁在填这条裂缝硬件、模型、工具链三伙人我观察下来真正在填这条裂缝的人分成三波。第一波是硬件厂商他们把NPU、AI加速器、低功耗算力模块塞进终端设备典型就是带ESP32-S3的MCU板子或者带6TOPS算力的RK3588工控板。第二波是模型团队他们做量化、剪枝、蒸馏把动辄几百MB的模型压到几十MB甚至几MB让终端跑得动。第三波是工具链团队他们做Tabby这样的终端工具、做端侧AI硬件部署框架、做AI终端接入工具解决开发者和运维者的操作效率问题。这三波人到目前为止还没有完全打通。硬件厂商只管把算力做出来模型团队只管把模型压小工具链团队只管把终端体验做好。结果就是分配一个端侧AI项目时硬件选型、模型裁剪、部署工具往往是三批人干三批活中间断层严重。这篇文章后面的内容就是围绕这三条线来展开实操记录的。2. 硬件端实操终端设备里塞AI要先过算力、内存、功耗三道关2.1 怎么评估终端设备跑不跑得动AI很多人挑开发板时只看TOPS觉得算力越高越好。实际做下来这个指标最骗人。TOPS只是理论峰值要看配套的还有什么——内存带宽够不够、算子是否支持、量化精度如何、工具链是否成熟。我拿一次现实选型举例。我当时的项目要在现场设备上做异常声音检测候选设备有ESP32-S3、树莓派5、RK3588还有一块带NPU的边缘盒子。ESP32-S3算力只有几百GOPS级别但做一个关键词识别或简单分类模型绰绰有余树莓派5有CPU无NPU跑轻量CNN靠的是ARM NEON加速适合做原型验证RK3588嵌入6TOPS NPU能跑目标检测和分割模型更高一档的Jetson Orin Nano能跑端侧大一点的检测模型但功耗和价格都上去一个量级。选型就一句话先定场景和模型体量再定硬件不要反过来。关键词唤醒、振动异常分类、手势识别ESP32-S3这种MCU级就够了目标检测、语义分割需要带NPU的Linux SoC如果要跑重一点的多模态模型就得考虑大算力边缘盒子甚至带GPU的工控机。设备类型算力/加速内存典型功耗适合任务参考价格区间ESP32-S3MCU向量指令可选AI加速512KB SRAM几百毫瓦唤醒词、简单分类几十元树莓派5SBCCPU NEON8GB5-10W原型验证、中等模型几百元RK3588SoC板6TOPS NPU8/16GB5-15W目标检测、分割千元级Jetson Orin Nano边缘AI模组20-40 TOPS4/8GB5-25W多路视觉AI、轻量大模型2000元选型还有一个容易忽略的地方内存带宽。算力好比发动机马力内存带宽是能同时过多少辆车内存容量是停车场能停多少车。很多终端设备算力纸面很强但内存带宽不够模型推理时数据搬运跟不上实际帧率惨不忍睹。买板子之前最好先拿目标模型跑一次benchmark别只看参数表。2.2 模型压缩是端侧部署的主战场模型压不到终端能跑的大小前面选型全白搭。我见过太多项目死在“模型太大”上。压缩手段无非三件套量化、剪枝、蒸馏。量化是把模型权重从FP32精度压到INT8甚至INT4。FP32一个权重占4字节INT8只占1字节体积直接变四分之一推理速度和功耗也有明显改善。但量化是有代价的。我做YOLOv5s转INT8时mAP平均掉了2到3个点这个损失通常可以接受但某一层出现严重掉点时可能是激活值分布太宽量化参数算得不准。这时要先转ONNX用校准集统计激活分布再逐层排查哪一层掉点最多把那几层保留FP16混合精度。剪枝是去掉不那么重要的权重通道或卷积核让模型结构本身变小。蒸馏是用一个大模型当师傅教一个小模型学生。三件套组合下来一个几十MB的模型压到几MB在ESP32这类MCU上也勉强能跑。注意模型压缩不能只看文件大小还要看内存峰值占用因为MCU的SRAM往往只有几百KB模型参数稍微大一点就直接放不进内存。实操工具方面MCU级常用TFLite MicroLinux SoC上常用ONNX Runtime、OpenVINO、RKNN、TensorRT。每个平台都有自己的格式和算子限制跨平台转换时要特别小心一些变形算子、动态形状和自定义算子这些往往是转换报错的高发区。我已经养成习惯模型转换后先在小数据集上验证输出一致性再上机跑不然部署半天发现结果全是错的浪费时间。2.3 一次ESP32关键词唤醒的完整实操记录这部分我拿近期一个关键词唤醒项目详细说说。需求简单在ESP32-S3上做一个“小度小度”唤醒词检测检测到之后点亮LED并把唤醒结果通过串口发出来。整个链路是采集音频数据、训练一个CNN分类模型、量化转换、写C代码烧录。数据采集用的是麦克风阵列板加PC录音脚本采集了3个人的正常语音和对应的负样本正样本是几百条“小度小度”负样本是日常对话和噪声。训练模型时用的是PyTorch模型结构很简单几层一维卷积加全连接输入是40维梅尔频谱特征。模型训练完大约2MB直接烧录肯定放不下先转ONNX再转TFLite同时做INT8量化最终模型700KB左右。但烧录后第一个问题就来了ESP32-S3只有512KB左右的SRAM可用模型虽然700KB但推理时中间张量还要占一大块内存直接堆栈溢出、系统反复重启。解决思路有两个一是把模型权重放到PSRAM外置伪静态随机存储器里用ESP-IDF提供的配置把TFLite模型分配到大内存区二是把输入特征窗口从40维压缩到更小减少中间张量。最终我把特征维度降到25配合模型分块加载总算稳定跑起来。第二个问题是误唤醒。板子放在客厅电视声、空调声、键盘声都能触发模型。排查下来罪魁祸首是训练数据里噪声不足、泛化太差。后面我加了数据增强随机加噪声、随机音量、时间偏移重新训练后误唤醒明显下降。同时在实际产品中还要做双阈值检测概率超过高阈值立刻响应介于高低阈值之间则继续检测几帧做二次确认。这些都是产品级细节单纯跑demo时根本不会意识到。2.4 CAN通信物理层容错与终端电阻别让AI终端在总线上掉线端侧AI终端在工业场景里经常要挂CAN总线。很多人以为跑AI的设备出问题一定是算法问题实际上我在现场排查过好几次最终都是CAN物理层在作祟。CAN总线是差分信号CAN_H和CAN_L互为镜像靠显性电平逻辑0和隐性电平逻辑1传输数据。总线两端必须各接一个120欧姆终端电阻作用是匹配线缆特性阻抗消除信号反射。为什么是120欧姆因为CAN总线线缆的特征阻抗典型值就是120欧姆左右。高速CAN要求总线两端总等效电阻约60欧姆也就是两个120欧姆并联。如果终端电阻缺失、阻值漂移或位置错误信号反射会直接导致数据帧CRC错误、总线错误率升高严重的甚至整个网络瘫痪。现场排查时我会用示波器测CAN_H和CAN_L之间的差分电压。正常隐性电平约2.5V显性电平约3.5V。如果波形过冲、振铃或者边沿不陡大概率是终端电阻问题。再配合查看总线长度和节点数CAN总线的传输速率和线缆长度成反比125kbps时理论上限是500米左右1Mbps就只有40米左右。除此之外共模电压异常、总线供电不足、接地不良也会造成通信故障。我之前整理过一张简易排查表直接贴在工位上了。故障现象可能原因排查动作总线错误率持续升高终端电阻缺失或不匹配示波器测差分电平检查两端120欧姆节点偶发掉线总线长度超过该波特率限制降低波特率优化拓扑波形振铃严重终端电阻位置不在物理末端把终端电阻调整到总线物理末端共模电压异常节点供电隔离没做好检查各节点地电位考虑加隔离收发器网段内一个节点拉垮全总线该节点收发器损坏逐节点脱离总线排查更换收发器这段经验跟AI模型本身没有任何关系但端侧AI终端作为总线上的一个智能节点如果物理层不稳定再强的推理能力也白搭。嵌入式开发有个很朴素的道理先把设备当普通控制节点跑通再往上叠AI能力。3. 终端工具链开发端侧AI时的“人居环境”革命3.1 为什么要从系统自带终端换成Tabby这类工具端侧AI开发绕不开远程连接设备SSH到工控机、刷写ESP32、查看日志、拉取数据。系统自带的终端基础功能够用但一旦同时管理好几台设备效率立刻下来。我现在的主力终端工具是Tabby跨平台、免费开源支持SSH、SFTP、串口还能管理分组、保存密钥。最实用的是左侧机器列表我按项目分组双击就连不需要每次敲一长串SSH命令。有人会问为什么不用Windows Terminal用Tabby因为Windows Terminal是终端模拟器本身不提供SSH会话管理Tabby这类工具更像是“终端会话管理器终端模拟器”的结合体。我最喜欢的功能是内置SFTP面板传输刷机固件、拉取日志文件非常直观不用额外开一个FTP客户端。脚本也支持可以在建立会话后自动执行初始化命令。配置迁移也方便导出配置文件换机器直接导入项目交接很省事。踩过的坑也得说Tabby默认配置下某些字体对中文显示不友好会出现字形古怪、对齐错乱。解决办法是在设置里把字体改成Sarasa Mono SC、Noto Sans Mono CJK之类的中文等宽字体。另外连上设备后颜色主题偏暗的话日志里很多信息看不清我会把主题调成浅色或者自定义配色。总之工具要先伺候好自己否则远程调试能把自己调崩溃。3.2 WSL、Linux、macOS终端日常问题实录端侧AI开发往往要在多个操作系统之间横跳终端相关的小问题特别多整理几个高频的。WSL2里进入Ubuntu终端最直接的方式是安装Windows Terminal然后用下拉菜单进入WSL发行版。如果发现WSL里的终端没法访问Windows文件检查是否在/etc/wsl.conf中配置了automount如果改完配置不生效记得在PowerShell里执行wsl --shutdown重启WSL。Ubuntu下打开终端是CtrlAltT这个快捷键我做演示时经常用很多新手不知道。Linux命令行里“换到上一行”这个需求也很常见。终端不是文本编辑器但Readline快捷键支持行内编辑CtrlA跳到行首CtrlE跳到行尾CtrlU删除光标到行首CtrlK删除光标到行尾。执行过的历史命令用CtrlR搜索不用一直按方向键找。查看远程服务器资源时xterm或任何SSH终端里通用的命令是df -h看磁盘、free -h看内存、htop看整体负载配合uname -a看内核版本。这些命令我每次排查问题都要用闭着眼都能敲出来。macOS上我遇到过“终端完全没权限了”的情况。装了某个软件后终端访问“桌面”“文稿”都被拒绝报错没有权限。这在macOS 10.15及以后特别常见原因是隐私保护机制终端App需要授予完全磁盘访问权限。去系统设置-隐私与安全性-完全磁盘访问权限把终端App加进去并勾选重启终端就好。如果还不行再看SIP系统完整性保护是否误关了恢复模式下执行csrutil enable。另外macOS想在当前目录打开终端可以装一个“Open in Terminal”服务或者直接在访达里右键文件夹选择“新建位于文件夹位置的终端窗口”。Windows相关的小问题也有。比如在cmd里从C盘切到D盘直接输“cd /d D:\路径”少了个/d参数就不会切盘。删除文件夹用rmdir /s /q 文件夹名别用deldel删文件不删目录。vscode里cmd终端中文乱码十有八九是代码页问题终端里执行chcp 65001切UTF-8或者直接在PowerShell里设置$OutputEncoding。如果跑conda环境vscode终端里切换环境用conda activate env名切回base用conda deactivate。这些命令都不难但堆在一起就是体力活。3.3 终端复用与AI终端集成的“新一代裂缝”做端侧AI开发最怕的就是远程SSH会话意外断开。烧录固件烧到一半、模型训练到第30个epoch、日志正在滚动输出网络一抖全没了。终端复用工具就是为了解决这类问题。我常用tmux它能在服务器上保活会话SSH断了回连后tmux attach还回到原地任务继续跑。tmux的基本用法不复杂tmux new -s work新建会话CtrlB然后C新建窗口CtrlB然后W切窗口CtrlB然后D脱离会话。第一次用的人容易困惑的是“脱离会话之后任务还在跑吗”答案是还在跑这正是我们要的。把长时间编译、模型转换、批量刷机任务丢进tmux然后放心关电脑。第二天打开终端tmux attach -t work一切照旧。真正的新裂缝出在AI编程工具和终端工具的集成上。我最近把AI助手接入终端日常让它在终端里帮我写脚本、解析日志、生成烧录命令。方向是对的但体验还很“毛坯”Codex这类AI编程工具经常提示当前回合没有可用的终端和文件编辑工具IDEA内置的AI终端流式输出日志时打印显示不全需要手动滚动才刷新。终端接入Claude、DeepSeek这类大模型时上下文窗口对终端命令回显的理解能力也还不够成熟。说到底终端这个老物件正在被AI工具重新塑造但现在的状态是“能跑不顺手”。我的建议是在正式项目里不要过度依赖AI终端做关键操作可以把它当辅助问答工具用真正的刷机、部署还是要自己把控。未来等终端工具提供更标准的工具调用接口这条裂缝才会慢慢收拢。3.4 终端文件管理器yazi让终端里看文件不再痛苦终端里看目录结构传统做法是ls、tree加cd一层一层翻。文件多了就很痛苦尤其在调试嵌入式工程时目录嵌套深还要在build、src、include之间来回跳。我最近试用了一个终端文件管理器yazi体验大幅提升。它在终端里提供类似侧边树形目录的界面支持文件预览、图片预览、文件夹展开折叠快捷键和vim类似h/j/k/l移动回车进入空格预览。yazi在Windows上也能跑需要配合WSL或者原生Windows终端使用。它还可以通过插件集成到系统终端中比如在Shell里按一个快捷键直接呼出yazi选完路径退出后直接cd到那个目录。这个体验非常顺手。我现在的习惯是在一个终端里开tmux再在tmux里跑yazi浏览代码和日志文件效率比单纯ls高很多。对于做端侧AI这种天天翻模型文件、日志目录、固件包的人来说值得一试。4. 企业终端管理与合规端侧AI落地的“隐形前提”4.1 终端防护管理系统的实际体验端侧AI终端一旦进入政企环境第一道坎往往不是技术而是终端安全管控。很多单位要求每台设备必须安装终端防护中心或终端安全管理系统统一登记、统一策略、定期检查。这些系统的初衷是好的但实际使用中问题不少。应用安装包会被拦截AI推理进程会被当成可疑进程隔离模型文件目录被定期扫描后误报为风险文件。我做的一个项目就遇到过在国产化终端上部署了端到端的AI检测服务第二天发现批量终端全部离线原因就是终端防护中心把AI推理服务判定为未知服务并禁用。排查时又发现卸载需要密码密码遗忘了进退两难。这种场景很典型。正确的做法不是在用户机上斗智斗勇而是走正规流程在测试环境申请白名单把AI应用的进程名、签名、安装路径加入可信列表再通过管理端统一下发策略。另外很多终端管理客户端还有“更换硬盘后需要重新授权”的机制。我踩过坑一台工控机硬盘坏了换上新硬盘后终端防护中心要求重新输入授权密码而密码是甲方原来的同事设置的人已经离职。最后只能走重置流程折腾了大半天。所以项目交付时一定要把终端管理软件的授权密码、离线安装包、卸载流程一并写进文档不然将来运维就是灾难。离线安装也是常见痛点。很多现场不允许连接外网Windows Server的终端服务、各终端管理系统的离线安装包必须提前准备好依赖组件一个都不能少。我之前整理过一份“现场终端离线安装清单”包含安装包、依赖、授权文件、离线病毒库每次现场交付之前先按清单检查一遍能少很多麻烦。4.2 国产OS、虚拟化与端侧AI的兼容性国产化环境下做端侧AI兼容性问题比想象中多。麒麟系统上的终端虚拟化平台、天逸终端虚拟化软件还有各种保密检查系统组成了一个独特的软件生态。这些软件本身运行稳定但它们和AI推理框架的配合还不够成熟。比如在麒麟上用TFLite或者ONNX Runtime需要提前确认推理引擎的Linux版本是否支持对应CPU架构和GLIBC版本不然装上了也跑不起来。我遇到过最典型的问题是NPU工具链缺失。国产化终端部分使用国产NPU芯片但配套SDK往往只提供自家的模型转换工具支持的算子有限模型从标准框架转换过去经常报不支持算子。这种情况没有捷径只能在模型侧做适配替换不支持的算子、拆分复杂结构、手工实现底层算子。项目排期时必须预留这部分工作量否则项目经理会以为换个格式一小时就能搞定。智能融合终端是这两年很有代表性的产品方向把数据采集、AI计算、控制输出、网络通信集成到一个终端里。给这类终端选型时我建议先看技术规范说明书确认接口协议、扩展槽位、AI算力、操作系统兼容范围不要被“智能”两个字忽悠。下载说明书后重点翻“硬件规格”和“二次开发支持”两章没有开放SDK或示例代码的所谓智能终端后续根本没法落地AI应用。此外端侧AI终端也有连接5G网络的形态比如一些巡检机器人和移动布控终端通过5G模块和商用终端通信。这类设备调试时重点确认信道配置、SIM卡APN、数据上下行限速策略。AI推理在本地完成5G主要用于上报结果和接收指令对网络实时性压力相对小这也是端侧AI与5G结合最务实的路径。4.3 软考“云端—终端混合餐饮服务系统”案例带来的思考软考的“云端—终端混合餐饮服务系统”考题表面上是个软件架构设计题本质上是教你怎么做分布式系统的算力划分。这个问题跟端侧AI的架构决策一模一样哪些功能必须在终端本地做哪些可以上云。以餐饮系统为例点餐终端要实时响应下单动作如果依赖云端网络一卡点餐体验就崩所以终端本地做菜单展示、输入校验、部分缓存而菜品推荐、销售统计这类重计算则放到云端做。我把它翻译成AI架构原则凡是涉及用户实时操作的、数据敏感的、离线要用的功能留在终端凡是需要大模型、大数据训练的放云端。按数据敏感度、按时延要求、按模型体积三个维度来划分基本不会跑偏。这比架构师拍脑袋定方案要靠谱得多。5. 端侧终端高频问题速查表与排查清单5.1 高频问题速查表实际项目中遇到的各种终端问题我汇总成了一张速查表可以直接抄作业。现象可能原因解决动作终端中文乱码代码页或编码不匹配执行chcp 65001或设置终端字体与编码UTF-8磁盘满但df显示还有空间被删除文件依然被进程占用lsof | grep deleted 定位进程重启该服务释放内存看起来不够用有僵尸进程或缓存占用先看free -h的available列别只看used用htop排查WSL启动后进不了Ubuntu终端WSL服务卡死或配置失效在PowerShell执行wsl --shutdown后重开麒麟系统关机时终端响铃内核蜂鸣器未禁用执行modprobe -r pcspkr或系统设置中关闭蜂鸣macOS终端无权限访问文件缺完全磁盘访问权限系统设置-隐私与安全性中为终端App授权conda环境切换无效shell未初始化先执行conda init bash重开终端再activateAI终端工具提示没有终端接口工具权限或会话配置问题检查是否授权文件编辑与终端执行权限重新发起会话设备烧录时串口被占用串口被其他程序占用关闭占用端口的工具或重新插拔设备后看设备映射CAN总线上AI终端偶发失联终端电阻或物理层问题按2.4小节表格逐项排查先测差分波形5.2 端侧AI终端落地的完整检查清单分享一份我每次做端侧AI项目都要过一遍的检查清单按阶段来需求确认阶段厘清时延、隐私、断网可用性三项硬指标写进需求文档确认数据能否出本地这决定云端还是端侧。硬件选型阶段按模型体量和场景选型先跑模型benchmark再定板子确认内存峰值能否放下模型权重和中间张量确认终端是否支持目标推理引擎。模型适配阶段先做模型转换和量化验证输出一致性对掉点严重的层做混合精度或算子替换记录压缩前后模型体积、推理耗时、精度对比。部署测试阶段先把硬件当普通节点跑通串口、CAN、网络通道再部署AI应用检查终端安全管控软件是否拦截进程提前申请白名单长时间稳定性运行至少48小时观察内存泄漏和发热。运维交付阶段整理终端管理客户端密码、离线安装包、授权信息准备OTA升级方案不能在部署后“裸奔”写清更换硬盘、重装系统后的恢复流程。这份清单看着基础但每一条背后都有翻车教训。现在只要现场出问题我第一反应就是对照清单逐项排查而不是从AI算法本身找原因。说实话做了这么久我觉得端侧AI终端不是在抢云端AI的工作它填的是云根本够不着的场景几百毫秒都等不起的产线、一丝数据都不能出去的机房、断了网还得正常工作的设备。端侧AI和云端AI未来会是并存的各管一段。最后分享一个我自己的习惯。拿到一块新的终端硬件第一件事不是急着跑模型而是先把它当普通工具连上终端、看资源、跑一个小程序把设备本身的脾气摸透。这个习惯帮我挡掉过不少莫名其妙的部署翻车。端侧AI的关键不在“AI”多炫而在“端”稳不稳设备都不稳模型再厉害也是空中楼阁。