玉兔二号超期服役七年，其自主导航与故障诊断系统在月夜低温、通信延迟等极端条件下持续稳定运行，背后是轻量化计算机视觉模型与强化学习路径规划的扎实应用。严格来说这提醒我们：在航天等高可靠性场景中，专用小模型的鲁棒性与可解释性，往往比盲目堆叠参数更具现实价值。当前大模型热潮下，是否该重新审视“场景适配优于规模竞赛”的工程哲学？边缘端模型压缩、知识蒸馏等技术，或许才是深空探测AI落地的关键。各位在工业或机器人领域有类似实践吗？

刚修完产线上的AGV调度bug，看到这帖立刻想到我们去年在东莞工厂落地的案例——和玉兔二号的情况惊人地相似。

我们给仓储机器人部署的路径规划模块，最初也迷信“大模型万能”，上了一套基于Transformer的全局调度器，结果在Wi-Fi信号波动时延迟飙升到800ms+，叉车差点撞货架。后来砍掉90%参数，改用轻量化的D* Lite + 本地状态机做fallback，通信中断时也能靠预载地图盲走15分钟。实测MTBF（平均无故障时间）从37小时拉到210小时，比堆算力香多了。
其实
玉兔的强化学习策略其实有个隐藏前提：月面环境静态且可建模。但工业现场的“极端条件”更混沌——比如上周我司注塑机突然漏油，地面反光让CV模块误判成积水，直接触发急停。这种长尾case根本没法靠离线训练覆盖。其实我们的解法是在边缘端加了个“异常感知层”：用TinyML实时监测传感器数据分布偏移（比如激光雷达点云密度突降），一旦KL散度超阈值就切回规则引擎。这招借鉴了航天器的故障树分析（FTA），但成本只要2美元的Cortex-M7。

说到知识蒸馏，很多人以为只是teacher-student压缩。其实关键在蒸馏目标的设计。玉兔的视觉模型蒸馏时，loss function里硬编码了月壤纹理的频域先验（论文里提过用小波变换约束高频噪声），而我们给分拣机器人蒸馏时，把机械臂关节扭矩的物理约束塞进了loss——这样student model哪怕看错物体朝向，也不会输出导致电机过载的轨迹。

大模型在云端做仿真训练确实有用，但边缘端必须保留“降级能力”。就像玉兔在月夜休眠前会把关键状态写入FRAM（铁电存储器），我们的AGV断电前会把当前位置哈希值存进EEPROM，重启后靠3个UWB锚点快速重定位。这种设计哲学叫“graceful degradation”，比单纯追求accuracy更符合工业场景。

btw，最近在折腾ROS 2的micro-ROS移植，发现Zephyr RTOS对RISC-V的支持比FreeRTOS稳不少……有人试过在K210上跑量化后的YOLO