随着技术的发展RM已经逐渐地变得和我曾经的印象产生了非常巨大的断层，有技术方面的，也有认知方面的，AI的兴起非常明显地加快了大家的学习和开发进程（同时也为各位的屎山制造速度添砖加瓦），同时组委会也可以基于现有的技术发展速度提出一些更加（）的技术要求。

在这一过程中我开始注意到，不管是我自己，我们队内的成员，还是其他队的成员，对AI的依赖程度明显升高，写代码的时候问 AI，编译报错问 AI，导航漂了问 AI，强化学习不收敛也问 AI。以前一个晚上可能只能查完几个 issue，现在十分钟能把 ROS、控制、视觉、规划几个方向都扫一遍。

这当然提高了效率。

但是也会引来真正的麻烦：

AI 一直在给你答案，项目也一直在往前走，但你慢慢不知道自己到底在干什么了，也不知道自己这个项目最终会走到哪里。最终你不是在真正地饲养AI，而是逐渐地被AI饲养。

我自己现在越来越倾向于一种用法：

不要把 AI 当成一个替你完成项目的人。把它当成一个能力很强、知识面很广、干活极快，但对你的机器人一无所知，也不会为最终结果负责的研发助手。

切记，不要真的变成Agent物理接口

1. 不要赛博算命

很多低效的 AI 使用，往往从第一句话就已经跑偏了。像“帮我写一个 RM 自瞄”、“帮我做一个轮腿强化学习”或者“帮我解决导航漂移”这类问题，表面看似明确，实则几乎没有提供任何有效信息。

以机器人的运动控制仿真为例，遇到异常时，不要直接把一句“机器人为什么一直在抖动？”扔给 AI。相反，先自行梳理好上下文：当前的目标与具体现象是什么？已知信息和已经尝试过的方案有哪些？数据包的形态是怎样的？个人的预判以及背后的依据又是什么？在铺垫好这些背景后，再给 AI 下达指令：“根据以上现象，先不要急着改代码。请帮我把可能的原因按概率排序，并提供每个原因最省事的验证方法。”

这种做法看似比直接提问麻烦得多，但实际效率却有质的飞跃。因为前者是在引导 AI 分析问题，而后者往往是在让AI进行一个赛博算命。

这在机器人项目中尤为致命。如果你不主动提供电机方向、坐标系、控制周期、传感器型号、软件版本、机械结构以及系统当前状态，AI 是不会停下来提醒你“信息不足”的。它只会擅自脑补一套看似合理的设定，然后一本正经地给你一个只是在 Cosplay 正确答案的无效建议。

2. 不要赛博叠甲

这是我认为现在用 AI 最容易踩的坑。很多人的常态是：一出现问题，就把日志直接扔给 AI。AI 建议修改 A，你改了但问题依旧；AI 接着说可能是 B，你继续改，结果又引发了新问题；AI 接着提议加个滤波器来解决 C……这样折腾一晚上，代码改了六七十处，参数调了三十几轮，系统比一开始复杂了十倍。结果呢？问题没解决，你连最开始报错的真正原因都找不到了。这种调试方式看起来效率很高，因为你一直在敲键盘，但实际画风往往是：你像个榜一大哥一样疯狂给 AI 刷着 Token，像老父亲一样守在屏幕前苦等‘神谕’，等到黄花菜都冻成冰雕了，最后 AI 双手一摊，绝望地吐出一句：“臣妾做不到啊”。

我们必须学会刻意克制这种行为。以“机器人站立后向后倒”为例，绝对不要直接让 AI 给你生成一个“完整修复方案”。相反，先列出几个最可能的假设：初始关节角有没有错？重心是不是在支撑区域之外？PID 参数是否合理？力矩方向有没有反？控制器启动前是否存在无输出的空窗期？然后，严格要求自己一次只验证一个变量。

这个时候，你可以换一种思路让 AI 协助你：“我现在有这五个假设，请根据现象帮我按发生概率排序。如果下一次实验只能测试一个点，验证哪一个能带来最大的信息量？”

这个用法非常核心。因为调试的本质从来不是“我还能再改点什么”，而是“我的下一次实验能排除什么因素”。如果在一次实验中你同时改了五个参数，哪怕最后机器人奇迹般地站稳了，严格来说你也没有获得任何真实的知识。下次它换一种姿势摔倒，你依然无从下手。

3. 不要赛博求雨

现在很多人一跑代码，看到终端满屏飘红，第一反应早就不是去读报错信息了，而是反手一套丝滑的 Ctrl+C 加上 Ctrl+V 喂给 AI。

有一说一，短期看这波操作没毛病。像那些阴间版本的 CMake 报错、玄学环境依赖，把 AI 当成“赛博帕鲁”去翻垃圾堆，确实能保住咱们本就不富裕的头发。但如果什么 Bug 都这么搞，时间一长，你就会患上严重的“赛博依赖症”：你越来越擅长当一个“AI 哄睡师”，却越来越丧失“老中医把脉”找 Bug 的能力。

要知道，在RM队里里，搞机器人真正值钱的硬核手艺，恰恰是后者。

现在去看看那些刚进战队的学弟学妹在怎么 Debug？问进度就是“马上就好”，一下地测试就是“不知道为啥崩了”，真坐下来盘逻辑，唯一的底气就是“AI 大哥跟我说这样改能行”。

真正的老手是怎么干活的？肌肉记忆必须刻进 DNA 里。

比如你辛辛苦苦搞出来的四足或者步兵，一上电直接给你表演一个后空翻。老控制看到这画面，脑子里应该瞬间“弹幕护体”：初始姿态给对了吗？重心是不是飘出外太空了？关节零点对齐没？力矩方向是不是接反了？

如果你的导航一开，车子就开始在场上“凌波微步”满地乱漂。你的第一反应必须是：时间同步炸了？外参飞了？IMU 在发癫？还是 TF 树拧成麻花了？

万一底盘或者云台电机开始疯狂鬼畜、原地打碟。你得本能地警觉：PID 增益给太大了吧？达妙电机延迟了？饱和了？控制频率没跟上，还是机械结构搁这儿产生共振了？

这些排查清单，AI 当然可以帮你补全，但千万别指望它从零给你无中生有。

正确的食用姿势是：你自己先当好主治医师，开出三个最可能的诊断证明，然后再把 AI 当成你的实习生去碰撞灵魂：“我盘出的这三个方向有没有逻辑硬伤？还有什么高概率的死角被我漏掉了？”

在这个过程中，AI 的作用是给你开全图视野，而不是替你清空大脑。

如果本末倒置，这事儿极易演变成一场悲惨的赛博求雨：Token 烧得跟纸钱一样快，你望眼欲穿地守在屏幕前，等到黄花菜不仅凉了甚至都长毛了，最后 AI 成功向你证明了——它不仅修不好你的 UoN-IM 战车，还顺手给你造了 10 万个不知所云的测试脚本。

这点思维方式的区别，一两次调车可能看不出来。但在 RM 这种高压环境里熬上几个赛季，最后有人成了指点江山的系统架构师，而有人，只练成了手速极快的复制粘贴大牛。

4.不要赛博炼丹

不懂的东西就别乱用。

有一说一，现在的机器人系统简直就是个极度复杂的“缝合怪”。ROS 节点满天飞，底层挂着 Eigen 矩阵算子，时不时还要跑个 CUDA 加速，外加一堆叫不出名字的第三方库和电机驱动。指望把每一行源码都盘明白确实不现实，但这绝不意味着你可以把系统当成黑盒，舒舒服服地当一个“赛博炼丹师”。关键的控制链路，必须死死捏在手里。

比如搞底盘控制，哪怕代码全是从 AI 那儿“薅”来的，你也得对整个数据流的来龙去脉门儿清。从速度指令最初被哪个节点塞进来，到中间途经的各路 TF 坐标系变换，再到控制器最终输出量的具体含义及其向四个驱动轮的解算映射，必须是一笔明白账。这其中包含了对单位基准、正方向朝向、死区与限幅卡位等细节的掌控，更决定了那个最要命的安全底线——当 CAN 线上通信猝然断开时，你的车究竟是会优雅急刹，还是直接化身失控的疯狗冲向人群。

再比如 AI 顺手帮你搓的 PID 控制器，虽然不用去死记硬背底层 C++ 类的声明，但你起码要懂 Kp、Ki、Kd 各自的物理发力逻辑。你得心里有数输出是否早就被死死卡在了饱和区、系统的采样和控制周期究竟多长，更要明白为什么稍微拉高一点增益，云台或关节就会立刻开始原地“帕金森”狂抖。

搞强化学习（RL）更是这种盲目炼丹的重灾区。现在让 AI 帮忙搭个 MuJoCo 或 Isaac 环境、写写 Reward 甚至调一调 PPO 参数简直不要太轻松，可一旦没人给背后的物理逻辑兜底，整个项目就彻底抓瞎了。你必须理顺系统观测到的状态空间与策略网络吐出的 Action 含义，弄清楚 Reward 函数到底是在鼓励正常行走还是在地上蠕动，最终还得明白仿真里跑出来的神仙步态切到真机时，具体是怎么落地成那一串实打实的电机指令的。

你要知道，对于“赛博炼丹师”来说，最毛骨悚然的根本不是训练失败或者模型炸了。而是：我虽然不知道为什么，但是卧槽它居然动了！

遇到这种状况，你除了在心里默默赞美一句“欧姆弥赛亚保佑”，什么也做不了。这种全靠玄学和代码盲目拼凑出来的系统跟纸糊的真没什么区别，只要稍微换个场地地形、动一动机械结构参数，或者换个重量级的传感器，整个架构分分钟全盘崩溃。到那时你再想去修，连去哪烧香都找不到庙门。

5.不要赛博开盲盒

AI 平时说话再怎么像个全知全能的架构师，很多时候只要一戳到底层，你会发现它本质上还是个“赛博大聪明”。

比如 RM 赛季的规则和限制，它信誓旦旦背给你的可能是对的，但你绝对猜不到它背的是哪朝哪代的“上古圣经”。要是你真信了它的邪，在 2026 赛季头铁地造出一台强力的“没头脑+不高兴”双云台哨兵，等上了赛场，那全队人确实是再也高兴不起来了。

所以，能一步验证的硬通货，千万别偷懒指望 AI 喂到嘴里。接口到底存不存在，老老实实去翻源码；电机参数是不是这个鬼名字，自己去扒大疆或者达妙的官方手册；论文是不是真敢这么吹，自己去啃原版 PDF。至于 AI 提议的玄学算法到底行不行，也别在聊天框里跟它“坐而论道”了，真理永远在测试场上，直接下地跑跑看才是硬道理。

特别是涉及到机器人本体的控制代码，你必须强制自己养成晚期“被害妄想症”。AI 吐出一堆看着很优雅的代码后，你的第一反应绝对不能是兴冲冲地“编译，烧录，下地跑一下试试”，这不叫测试，这叫拿命调车。

在你敲下回车之前，得先拿着八倍镜去排雷：输出做没做死区和限幅？量纲单位对不对得上？正负方向有没有写反？飞掉的异常数据怎么过滤？CAN 线要是突然被击断了系统怎么自救？控制器进程一旦挂了，底层的执行器是傻乎乎地锁死最后一个指令满功率原地狂飙，还是能切到安全模式归零？还有最后一道防线——当你一巴掌把物理急停拍下去的时候，这台失控的钢铁猛兽到底还能不能刹得住？

你得时刻把这句话刻在脑门上：这些逻辑在 IDE 里只是一堆人畜无害的浮点数，但一旦通过串口下发到机器人身上，瞬间就会化作实打实的狂暴电流、极限转速和能把人骨头撅折的撕裂力矩。

在仿真里写反一个正负号，大不了就是满屏爆红，机器人一个旱地拔葱飞出视口，大家权当看个免费的赛博烟花；但在真机上搞反一个符号，那代价可是带响的——轻则当场送走一块昂贵的驱动板，重则伴随着“咔哒”一声让人心碎的脆响，直接干碎你的宝贝英雄（哦没有英雄了，英雄死了（崩溃大哭））。

到那个时候，你看着满地残骸，再转头看到屏幕上 AI 吐出的那句温文尔雅的“希望这个方案能帮到您”，估计当场就能气出高血压，连把电脑顺着窗户扔出去的心都有了。

6. 不要赛博幻觉

这一点，在搞 RMUA、导航和强化学习的兄弟们身上简直是重灾区。很多算法在仿真里跑出来的效果风骚丝滑，简直能直接截个 GIF 去发顶会。结果满怀期待地一上真机，现实立马给你表演一套“物理学不存在了”。

仿真器无论吹得多牛逼，说到底也只是个加了美颜滤镜的“赛博乌托邦”。在屏幕里一切岁月静好，可一旦代码下地，现实的铁拳就会立刻教你做人。底盘飞个坡或者吃一发大弹丸，某根祖传的 Type-C 接口可能当场就被震得藕断丝连；要是赶上场馆闷热，PC过热降频，原本满帧的算法瞬间卡成PPT。更要命的是，赛场强光分分钟能让工业相机物理致盲，而你用 3D 打印件硬挂上去的雷达，也会被车体传来的高频共振抖出“脑震荡”。真实电机那长得离谱的响应延迟、地胶玄学的摩擦系数，还有几十支队伍同时疯狂发波带来的地狱级 Wi-Fi 干扰，在仿真软件的理想真空里压根无迹可寻。

不要一天天抱着仿真不松手，实机就在边上，调一下呢（当然不在手边上的话可以调一下机械，找找原因为什么不在手边上）

7. 不要赛博梦游

AI 有一个极具欺骗性的特质：它永远不知疲倦，且永远能满腔热血地给你指引“下一步”该干什么。

这在搞导航、强化学习，或者赛前最让人高血压的整车联调时尤为致命。如果你毫无防备地跟着 AI 的节奏连轴转上几天，极容易陷入一种离谱的“赛博梦游”状态。你感觉自己敲破了键盘，每天都在疯狂测试、疯狂重构模块，但在某个熬红了眼的凌晨，你恍惚间会突然发现：自己已经完全想不起来，最初到底是为了修哪个该死的 Bug 才一路走到这里的。

要学会接受适可而止，能用就行。

AI现在太强大了，前几天我开始试图用AI构建一个RL框架，在此之前我从来没接触过RL，我一直以来大部分工作都是机械和理论，会用到仿真和代码但都是服务于理论验证，然后我眼睁睁地看着AI用了一晚上时间干了我以前三个月的工作量。

我现在越来越觉得，AI 真正厉害的地方并不是“替你写代码”。而是它可以让一个人的能力边界扩展得非常夸张。以前做导航的人可能不懂控制，做控制的人不懂视觉，写上位机的人不熟悉嵌入式。但是现在你完全可以借助 AI 很快进入一个陌生领域。

但代价是，人必须比以前更清楚：

什么是事实，什么是推测；什么是已经验证的，什么只是看起来合理；现在为什么做这一步，以及做完以后要得到什么信息。

所以如果一定要总结我的 AI 使用习惯，其实就一条：

要时刻能看懂自己在干什么，AI在干什么，接下来要干什么。

AI 可以替你查文档、读代码、写脚本、分析日志、整理方案，甚至一天完成过去一周的工作量。

但最后真正决定机器人能不能上场的，还是那个很朴素的问题：

如果现在机器人出了问题，你知不知道自己第一步该查哪里？

如果知道，AI 是你的效率放大器。这篇帖子都是AI帮我花了十几分钟写的（虽然后期修改花了不少时间改一些非人语法习惯）

如果不知道，只是在不断把现象复制给 AI，那大概率不是你在调机器人。是机器人在调你

Agent物理接口其实不怎么好当，GPT的榜一大哥当不明白的话要花不少冤枉钱。