通用 AI 真的懂 ROS 吗？我把联调经验做成了一个开源 Skill

这不是一个泛泛的提示词包，而是一套面向 ROS 1 / ROS 2 机器人开发、迁移与联调 的工程化工作流。我想做的，不是让 AI 看起来更聪明，而是让它在真实机器人项目里，少走弯路、少制造误判、真正帮到开发者。

这段时间，我把自己在 ROS 开发、导航联调、控制链路排查、TF 调试、多机器人协同以及嵌入式协同里的经验，整理成了一个开源项目：

ros-robotics-skill

项目地址：

https://github.com/wzyn20051216/ros-robotics-skill

很多朋友第一次看到这个项目时，会下意识把它理解成一个“提示词仓库”。

但实际上，我做它的出发点，并不是为了堆提示词，而是想解决一个更具体、也更现实的问题：

通用 AI 很会写代码，但不一定真的懂 ROS 联调

做过 ROS 项目的人大多都知道，机器人开发里最麻烦的问题，往往不是“代码写错了”这么简单。

很多时候，问题真正出在这些地方：

• 一开始就没分清 catkin、ament 和 colcon，工作区判断从源头就偏了；
• 一看到报错就急着改业务代码，却没有先排查 TF、frame、时间戳、单位和资源安装；
• Nav2 明明已经激活，但底盘就是不动，不知道该先查控制链路、反馈链路还是 /cmd_vel；
• topic 丢帧看起来像节点异常，根因却可能只是 QoS 不兼容；
• 一提到 MCU 就默认建议上 micro-ROS，但很多时候 Linux 侧桥接反而更简单、更稳。

这些问题的共同点在于：

它们不是单点代码问题，而是工程上下文问题。

如果 AI 没有这些上下文，就很容易给出一种“看起来像正确建议”的动作：

直接改代码。

但做过真实联调的人都知道，这恰恰是最危险的起点。

我想做的，不是更多提示词，而是更接近现场的工作流

ros-robotics-skill 的目标，从来不是把项目包装成“万能 AI 提示合集”。

我更在意的是：当 AI 处理 ROS 问题时，能不能像一个真正理解现场的人一样，先按工程逻辑做判断。

比如：

• 先识别工作区类型，再决定构建与排查路径；
• 先查依赖、安装规则和 launch 资源，再判断是不是代码问题；
• 先排 TF、时间戳、frame、QoS、控制链路，再决定是否动业务逻辑；
• 先判断 Linux 侧桥接是否更合适，再讨论要不要引入 micro-ROS。

这类顺序听起来并不“炫技”，但恰恰最有工程价值。

因为真正决定联调效率的，往往不是你会不会写更多代码，而是你有没有从一开始就沿着正确路径收敛问题。

这个 Skill 到底沉淀了什么？

目前这个仓库已经不只是“一个 SKILL.md 文件”，而是逐渐整理出一套更完整的工程内容。

1. 专题参考文档

仓库目前已经覆盖多个 ROS 高频主题，包括：

• ROS 1 / ROS 2 / mixed workspace
• URDF / Xacro / TF / RViz
• Navigation2
• ros2_control
• DDS / QoS / 多机网络
• 多机器人命名空间隔离
• SLAM / Docker / Gazebo / MoveIt 2
• micro-ROS 与嵌入式协同
• Foxglove 可视化与离线分析

这部分内容的意义，并不是“把知识点堆得更全”，而是尽量让 AI 在不同场景里，有更准确的参考上下文。

2. 检查脚本与辅助工具

除了参考文档，仓库里还提供了几类实用脚本，比如：

• 工作区识别脚本
• 依赖与安装规则一致性检查脚本
• TF 树完整性离线检查脚本

这些脚本的价值，在于它们不是只给出“猜测”，而是尽量帮你把问题缩小到更真实的范围。

3. 真实案例与最小工作区

仓库里目前已经整理了 8 个真实案例，包括：

• ROS 1 catkin_ws 构建失败
• 模型能加载但 TF / RViz 异常
• Nav2 已激活但底盘不动
• QoS 不兼容导致 topic 丢帧
• Docker 中 ROS 2 无法发现节点
• SLAM 建图漂移严重
• Lifecycle 节点状态转换失败
• 多机器人命名空间冲突

同时，还提供了一个可以直接 colcon build 的最小 ROS 2 示例工作区，方便快速理解整个 skill 的使用方式。

为什么我觉得“工作流”比“答案”更重要？

因为在机器人系统里，真正困难的从来都不是“写一段代码”，而是：

• 判断问题到底落在哪一层；
• 按顺序排查，而不是同时怀疑一切；
• 小步修改，小范围验证；
• 最后把修复动作沉淀成以后还可以重复使用的方法。

我更希望 ros-robotics-skill 做成这样一种工具：

它不只是帮你回答，而是帮你判断、帮你收敛、帮你验证。

下面这张图，就是我想让这个项目持续沉淀的核心思路：

一个更贴近真实工程的问题例子

如果你做过 Nav2 联调，应该很熟悉一种特别“折磨人”的情况：

路径已经出来了，机器人却完全不走。

这类问题最容易把人带偏。

因为表面上看，它像是导航没生效；但真正的根因，可能在控制器参数、底盘接口、控制链路、反馈频率、话题桥接甚至 TF 连续性上。

如果这时候 AI 没有场景意识，很容易建议你“重写节点”“修改业务逻辑”甚至“换一套导航配置”。

但实际上，很多时候真正需要的，是先把链路拆开，一段段验证：

• Nav2 是否真的处于 active 状态；
• 控制器输出是否已发到正确话题；
• 底盘是否真的订阅到了控制命令；
• 反馈链路是否完整；
• TF 与时间同步是否稳定；
• QoS 是否存在隐藏的不兼容。

这也是为什么我想把真实案例写进 skill：

因为机器人问题，很多时候不是“会不会写”，而是“会不会查”。

它支持哪些工具？怎么接入？

目前这个项目已经适配：

• Codex
• Claude Code
• Gemini CLI

如果你已经在使用 Skills CLI，可以直接通过下面的命令安装：

npx skills add https://github.com/wzyn20051216/ros-robotics-skill -g -y

如果你更习惯一键安装，仓库里也提供了对应脚本。

从我自己的目标来看，我很希望它做到两件事：

1. 让已经在做 ROS 项目的人更快进入正确排障顺序；
2. 让刚接触 ROS 的人少踩一些本可以避免的坑。

这个项目适合谁？

如果你符合下面任意一种情况，我觉得这个项目都值得你看看：

• 正在学习 ROS / ROS 2 的学生；
• 机器人实验室或项目组成员；
• 做导航、控制、仿真、联调的工程师；
• 想把 AI 真正用进机器人研发流程的人；
• 正在做 MCU、RTOS、串口、CAN 与 ROS 协同开发的人。

最后

我越来越觉得，未来真正有价值的 AI 工程方式，不是让模型“看起来无所不知”，而是让它在垂直领域里，拥有更可靠的判断顺序、更贴近现场的上下文，以及更能落地的验证闭环。

ros-robotics-skill 对我来说，就是这样一次尝试。

它不是为了取代工程师，也不是为了制造“更会说”的 AI，而是希望把那些原本只存在于个人经验、排障直觉和项目复盘里的东西，慢慢沉淀为一套可以复用、可以传递、也可以被 AI 正确调用的工作流。

如果你也在做 ROS、机器人、导航、控制、仿真、多机器人或者嵌入式协同开发，欢迎来看看这个项目，也欢迎一起交流。

项目地址：

https://github.com/wzyn20051216/ros-robotics-skill

如果你觉得这个方向值得继续做下去，也欢迎点一个 Star 支持一下。

---

文末互动引导

你在 ROS 开发里最常踩的坑是什么？

如果下一篇继续写，你更想看：

• TF / Nav2 / QoS 典型问题拆解
• ros2_control 联调思路
• 多机器人命名空间设计
• micro-ROS 与 Linux 侧桥接取舍
• 这个 skill 的目录结构与工作流设计

欢迎留言交流。