企业官网建设流程全解析

先说一个观点：具身导航大模型并没有白训，但这并不意味着“通用 coding-agent 裸接机器人”这件事不值得重视。正好相反，当一类没有经过任何机器人数据训练的通用智能体，在某个导航评测任务中打出比专用模型更高的成功率时，它正好逼着我们重新思考一个问题——大模型在机器人身上到底解决的是什么问题。

这篇文章我会先梳理具身导航大模型和 coding-agent 各自的能力边界，再分析通用模型为什么能在部分场景中“反超”专用模型，之后给出一套“大模型 + 传统导航栈”的最小可运行框架，最后聊一聊落地时容易踩的坑。全文偏工程视角，代码和配置会尽量完整，方便你直接照着搭一个原型。

1. 为什么会出现“白训了”的讨论

1.1 具身导航大模型的训练成本有多高

先看“具身导航大模型”这个方向在做什么。它的目标很明确：让机器人接收自然语言指令，比如“去客厅茶几上把那杯水拿过来”“去走廊尽头的房间看看门有没有关”，然后自己完成感知、规划、运动控制这一整条链路。

为了训练这类模型，团队需要准备多模态数据：

• 第一类是仿真数据，在 Matterport3D、Habitat、Gibson 这类 3D 场景里架设虚拟机器人，采集 RGB-D 图像、深度图、机器人位姿、动作序列；
• 第二类是真实世界数据，让机器人在办公室、家庭、仓库里长时间自主移动，记录传感器输入和对应的最优动作；
• 第三类是专家示范数据，人工遥控机器人完成任务，把人的操作录成轨迹。

这些数据的采集成本非常高。真实场景数据不仅要消耗大量硬件时间，还要人工清洗，仿真数据虽然便宜，但和真机之间存在很大的 sim-to-real gap。训练阶段还要做视觉语言模型预训练、动作分支微调、强化学习对齐，每一步都需要大量 GPU 资源。所以不少团队跑了几个月后发现效果还是不稳定，本来就容易焦虑。

1.2 coding-agent 的出场方式很“反常”

再看 coding-agent 这类产品。它最初是给程序员用的，核心能力是理解需求、生成代码、重构工程、写测试、修 bug。一些知名模型在 HumanEval、SWE-bench 这类编程基准上表现很好，但没人指望它直接控制一台机器人。

所以当出现“把 coding-agent 模型直接接到机器人上，不做具身微调，导航成功率却有 78%，超过专门为导航任务训练的工业级模型”这样的结果时，行业第一反应是怀疑，第二反应是好奇。怀疑是因为这个结论太反直觉——一个没有见过激光雷达数据、没有训练过策略网络的模型，凭什么能控制物理世界里的机器人？好奇是因为如果这是真的，那么过去几年投入巨大资源的具身导航专项训练，价值到底在哪里？

这里需要澄清一点：大多数“coding-agent 裸接机器人”的实验，并不是让模型直接输出电机电流、轮速或者关节力矩，而是让模型充当“任务规划大脑”，把自然语言任务转换成机器人的目标点、路径点或者可执行代码片段，底层仍然由运动控制模块去执行。换句话说，模型负责的是“做什么、先去哪、再做什么”的决策问题，而不是“怎么跟踪这条轨迹”的底层控制问题。这个边界很重要，后面还会反复提到。

1.3 与其说“白训了”，不如说“分工变了”

我个人更倾向于把这类现象解读为一个信号：具身智能任务正在被拆分成“任务规划”和“运动执行”两层，而大模型擅长的刚好是前者。

传统导航系统里，工程师把任务规划写死为状态机、行为树或者规则脚本。比如“听到指令 A 就去目标点 B，检测到障碍物 C 就绕行”。这种方案稳定，但是扩展性差，换一个场景、换一种说法，就要重新改规则。

具身导航大模型的做法是用神经网络替代掉部分规则：视觉语言导航模型直接把“语言指令 + 当前观测”映射成动作分布。它的上限取决于训练数据的覆盖范围，训练数据里没见过“桌子底下有一双拖鞋，请绕过去”这种组合，模型就容易懵。

而通用 coding-agent 走的是另一条路：它不直接学习导航策略，而是把“解决这个任务需要调哪些 API、写几步判断、生成什么坐标”变成代码生成问题。在这个范式里，模型的能力来自互联网级别的代码与通用知识，而不是某一条机器人数据。它自然会写“走到门口要检测门的状态”“先导航到餐桌，再原地旋转 90 度找杯子”这类逻辑——因为它们大量出现在人类编写的代码、文档和教程里。

所以准确地说，具身导航大模型在“感知-决策-控制一体化的紧凑模型”路线上仍然有价值，而 coding-agent 展现出的是另一种能力，强大的开放世界常识推理和工具调用能力。二者不是取代关系，而是分工关系。后面我会给出一个可以落地的混合架构。

2. 核心概念拆解：具身导航大模型与 coding-agent

2.1 具身导航到底是什么任务

在机器人学里，导航（Navigation）不是一个单一问题，而是一组任务的集合：

传统工业导航机器人主要靠前四行。用户通过平板或者按钮选一个点位，系统负责把机器人安全送过去。“具身导航大模型”想解决的是最后一行，甚至想部分替代第二行和第三行，让机器人像人一样看懂没有预先定义的目标点。

2.2 具身导航大模型的常见技术路线

目前做具身导航大模型，主流技术路线可以归成三类：

第一类是端到端策略，输入当前视觉图像、机器人位姿和自然语言指令，输出动作概率分布，训练方式通常是模仿学习和强化学习的结合。这种方法看起来最“智能”，但数据需求量极大，而且对动作空间的炸裂维度很敏感。

第二类是模块化大模型，保留传统的 SLAM 与路径规划模块，大模型只负责把语言指令转换成结构化目标，比如输出房间类别、物体名称或者语义地图中的目标点，然后交给下游模块执行。这类方案最稳定，落地最快。

第三类是“语言-视觉”对齐导航，代表思路是把导航任务建模成“根据语言指令在拓扑地图上选点”的问题，模型不输出连续速度，而是输出下一时刻应该前往的拓扑节点。它比端到端好训练，但也依赖地图的质量。

2.3 coding-agent 的本质能力

coding-agent 本质上是一个“能使用工具的推理智能体”。它不止会对话，还能执行搜索、读取文件、调用命令行、生成代码，并基于外部反馈修正自己的输出。

这种能力映射到机器人任务上，会产生几个意想不到的优势：

• 它天然支持“多步拆分”：把复杂任务拆成“去厨房→找到咖啡机→按开关→等待出水→返回”，每一步的产物都可以是代码或参数；
• 它天然理解“坐标变换”：因为代码库里大量存在坐标、矩阵、物理量转换的写法；
• 它天然知道“先检查再执行”：因为工程代码里充满了条件判断、异常处理和资源释放，这些模式会被模型吸收成“先感知，再决策，再执行”的思维链。

2.4 从“生成代码”到“生成行动”的映射关系

要理解 coding-agent 为什么能控制机器人，需要建立三层映射：

第一层是“语言→程序”，这是 coding-agent 最原始的能力。用户说“从 A 点走到 B 点，中途如果遇到障碍物就绕行”，模型生成一段伪代码或者 Python 脚本。

第二层是“程序→机器人指令”。这一段模型并不关心机器人的具体型号，它只需要把动作分解成“设置导航目标点”“查询当前位置”“检查传感器状态”等抽象 API 调用，具体的 SDK 由执行层替换。

第三层是“机器人指令→物理运动”。这一段由底层导航栈完成，比如 RoboCup Rescue 常用的 move_base、ROS2 的 Nav2。

也就是说，coding-agent 被接上机器人的本质，是它多了一个会执行代码的工具环境。模型的强项是前两层，而传统的导航框架补上了第三层。所以 78% 的成功率不是“大模型直接变成了一个物理控制高手”，而是“大模型+导航工具链”组合后的系统成功率。

这个结论并不削弱结果的价值，因为系统落地时本来就不是只靠模型一个人干活。能把这个组合高效装配起来，本身就是工程能力。

3. 通用模型凭什么在部分导航任务中反超专用模型

3.1 开放词汇理解：专用模型最吃力的地方

工业级专用导航模型通常在限定场景里表现很好。比如在固定产线上的 AGV，点位数不多、走廊宽度固定、地面标志清晰，专用模型可以把任务完成率做到 99% 以上。但它有个致命弱点：它对“新词”“新说法”“新常识组合”几乎没有泛化能力。

你让专用模型处理“在第二个岔路口左转，然后在看到蓝色货架后靠右走”，如果它没在训练数据里见过这种描述方式，大概率会执行失败。

通用大模型不同。它读过海量文本，知道“第二个岔路口”意味着途经一个路口、忽略掉第一个、在第二个转弯，也知道“蓝色货架”是一个视觉特征，可以先靠视觉检测模块找到目标，再靠近。

这种能力不是靠机器人数据学来的，而是靠互联网文本数据积累的常识。在开放场景的导航任务中，常识往往比精细的速度控制更重要。

3.2 任务拆解能力：导航不仅是移动问题

一个完整的“把杯子从客厅拿到厨房”任务，包含以下步骤：

1. 识别客厅茶几上的杯子；
2. 规划从机器人当前位置到茶几的路径；
3. 运动到茶几前；
4. 调整姿态，伸出机械臂抓取；
5. 识别厨房台面上的放置区；
6. 规划从茶几到厨房的路径；
7. 运动到厨房台面前；
8. 放置杯子。

这其实是“移动操作”任务。专用导航模型只负责 2、3、6、7 四步，而对 1、4、5、8 需要依赖其他模块。问题在于，每个模块之间的衔接逻辑需要预定义好，而且必须遵循固定流程。

coding-agent 的优势在于，它可以用代码把上述流程组织成一个动态分支逻辑：

• 如果没看到杯子，就调用视觉重识别；
• 如果机械臂抓取失败，就先重试一次，再决定要不要回退到导航原点；
• 如果厨房台面被遮挡，就切换视角再识别。

这些都是程序员的日常逻辑，模型生成的代码天然具备这种处理能力。于是“一个导航任务”就变成“一段可以自适应执行的程序”。专用模型可以做到单步导航很强，但在“面对意外情况时如何调整策略”这件事上，coding-agent 显然更接近通用智能。

3.3 规模效应与长尾知识

大语言模型的性能与参数规模、数据规模有明确的正相关关系。它在 Code、Math、Tool Use 等多个通用能力基准上表现出色，这不是靠“刷题”，而是靠对大量人类知识的内在统计建模。

而具身导航大模型的训练数据规模，相比互联网文本，少了几个数量级。一个专用模型可能只有几十万条机器人轨迹数据，而一个商用大模型可能见过几十万亿 token 的人类文本。当任务需要判断“哪种冰箱是双开门”“沙发和茶几的大致距离有多远”这类常识时，数据规模带来的差距会直接体现成任务成功率的差距。

3.4 不一定会被反超的部分：安全、时延与稳定性

既然 coding-agent 这么强，为什么工业现场没有立刻全面换成大模型导航方案？因为还有一些指标，通用模型暂时拿不到高分：

• 安全认证：工业机器人需要经过功能安全认证，认证的前提是决策逻辑可解释、可验证。大模型生成的代码天然带随机性，很难通过安全评估；
• 时延：大模型推理通常要几百毫秒到几秒，而底层路径规划需要在几十毫秒内响应；
• 确定性：同一个指令，模型不同次可能生成不同的动作序列。工业场景要求“同一输入、同一输出”；
• 算力成本：一张大模型的推理卡功耗很高，放在机器人机载端不现实，远程调用又有网络波动风险。

所以更理性的一句话总结是：通用模型强在“认知”，专用模型强在“控制”。在开放任务理解、复杂指令拆解这些认知密集环节，通用模型确实可能反超；在高速控制、安全保证这些物理执行环节，专用模型的地位暂时无法被替代。

4. 78% 成功率背后：评估方法比数字更有说服力

4.1 导航任务的常见评估指标

“导航成功率 78%”这个数字本身没有意义，除非定义清楚“什么算一次成功”。业界常见的评估指标有：

4.2 成功率的构成拆解

一个端到端系统最终成功率是多个阶段成功率的乘积。比如我们把任务拆成四步：

• 语言指令理解成功率：90%
• 目标点定位成功率：95%
• 路径规划与避开成功率：95%
• 最终靠近并停止成功率：95%

总成功率 = 90% × 95% × 95% × 95% ≈ 77.2%

如果报告里写的是 78%，很可能原因是：单个模块各有失败，系统最终以不低的概率成功。但这也意味着如果某一环节从 95% 降到 85%，总成功率会掉到约 61%，说明逐级相乘后错误会被放大。这提醒我们，不能因为一个综合成功率数字高，就觉得每个模块都很强。

4.3 为什么专用模型可能在特定评测中表现不如通用模型

很多评测集包含复杂自然语言指令、开放词汇物体、家居场景变化等因素。专用模型在训练时没有覆盖到这些组合，遇到新任务很容易失败；而 coding-agent 用常识推理“猜”出了大致正确的执行方式，即便没有精确的语义地图，也能靠目标检测模块完成大部分工作。

不过反过来，如果把评测换成狭窄产线上的固定点位导航，专用模型可以把成功率做到 99% 以上，而 coding-agent 反而会因为大模型推理的不确定性频繁出错。

所以“反超”是有前置条件的：任务越开放、指令越多样、场景越动态，通用模型的相对优势越明显；任务越固定、环境越可控、位姿越精确，传统专用模型越难被撼动。

5. 实战：搭建一个“大模型 + 导航栈”的最小系统

如果你想复现或验证“coding-agent 裸接机器人”的思想，不一定要先砸钱买真机。用仿真环境 + 一个开源大模型 API 就可以搭一个最小原型。下面给出一套可运行的工程框架，代码逻辑清晰，你可以把底层换成自己的机器人平台。

5.1 系统整体架构

用户自然语言指令 ↓ [大模型智能体（任务规划层）] ↓ 输出结构化目标点 / 代码片段 ↓ [导航执行层（ROS2 Nav2 / move_base）] ↓ [底层机器人 / 仿真器]

整个系统中，大模型不直接下发速度指令，而是生成“目标点”或“任务脚本”，这种做法既保留了大模型的推理能力，又避免了大模型在毫秒级控制上的缺陷，也更容易通过安全审查。

5.2 环境准备

我用 ROS 2 + Python 作为示例。你不需要真机，用 Gazebo 或 TurtleSim 都可以。

建议环境：

• Ubuntu 22.04
• ROS 2 Humble
• Python 3.10+
• 一个可以调用的大模型 API（本文以兼容 OpenAI 接口的服务为例）

启动一个最基础的 ROS 2 节点：

# 安装 ROS 2 基础组件（以 Humble 为例） sudo apt install ros-humble-desktop source /opt/ros/humble/setup.bash # 创建功能包 ros2 pkg create --build-type ament_python nav_llm_demo --dependencies rclpy geometry_msgs action_msgs

注意：如果你用的是 ROS 1，后续代码需要做小部分调整，比如 move_base 的 action 接口和 ROS 2 Nav2 的接口参数不同。示例思路是一致的。

5.3 核心代码：自然语言指令 → 导航目标点

先写一个“大模型任务规划节点”。它的职责是接收用户自然语言指令，让大模型返回一个 JSON，其中包含目标点坐标、目标名称和可选的判断条件。

# 文件路径：nav_llm_demo/nav_llm_demo/planner.py import json import rclpy from rclpy.node import Node from geometry_msgs.msg import PoseStamped from nav2_msgs.action import NavigateToPose from rclpy.action import ActionClient class LLMPlanner(Node): def __init__(self): super().__init__('llm_planner') self.nav_client = ActionClient(self, NavigateToPose, 'navigate_to_pose') def call_llm(self, instruction: str): """调用大模型，将自然语言转换为结构化目标点。 这里使用兼容 OpenAI 接口的服务。 """ messages = [ { "role": "system", "content": ( "你是一个机器人导航规划器。" "请把用户指令转换为 JSON 输出，格式如下：\n" "{\"target_name\": \"餐桌\", \"x\": 3.20, \"y\": -1.50, \"yaw\": 1.57}\n" "如果指令中没有坐标，你可以根据常识合理选择，" "但必须输出合法 JSON，不要输出其他解释。" ), }, {"role": "user", "content": instruction}, ] # 以 OpenAI SDK 风格调用为例 try: from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", base_url="YOUR_LLM_SERVICE_ENDPOINT", ) resp = client.chat.completions.create( model="your-llm-model", messages=messages, temperature=0.0, ) content = resp.choices[0].message.content.strip() # 防止模型输出包含 ```json 代码块 if content.startswith("```"): content = content.strip("`") if content.startswith("json"): content = content[4:] return json.loads(content) except Exception as e: self.get_logger().error(f"调用大模型失败: {e}") return None def send_nav_goal(self, x: float, y: float, yaw: float): """将目标点发送给 Nav2。""" goal_msg = NavigateToPose.Goal() goal_msg.pose.header.frame_id = "map" goal_msg.pose.header.stamp = self.get_clock().now().to_msg() goal_msg.pose.pose.position.x = x goal_msg.pose.pose.position.y = y goal_msg.pose.pose.position.z = 0.0 # 将 yaw 角转为四元数 from tf_transformations import quaternion_from_euler q = quaternion_from_euler(0.0, 0.0, yaw) goal_msg.pose.pose.orientation.x = q[0] goal_msg.pose.pose.orientation.y = q[1] goal_msg.pose.pose.orientation.z = q[2] goal_msg.pose.pose.orientation.w = q[3] self.get_logger().info( f"发送导航目标: ({x}, {y}), yaw={yaw}" ) self.nav_client.wait_for_server() future = self.nav_client.send_goal_async(goal_msg) future.add_done_callback(self.goal_response_callback) def goal_response_callback(self, future): goal_handle = future.result() if not goal_handle.accepted: self.get_logger().info("导航目标被拒绝") return self.get_logger().info("导航目标已接受") result_future = goal_handle.get_result_async() result_future.add_done_callback(self.result_callback) def result_callback(self, future): state = future.result().status if state == 4: self.get_logger().info("导航成功") else: self.get_logger().info(f"导航失败，状态码: {state}") def run(self, instruction: str): plan = self.call_llm(instruction) if plan: self.send_nav_goal( x=float(plan["x"]), y=float(plan["y"]), yaw=float(plan["yaw"]), ) def main(args=None): rclpy.init(args=args) node = LLMPlanner() # 示例指令，实际使用可以做成 topic 订阅或者命令行输入 node.run("去客厅茶几旁边的位置") rclpy.spin(node) rclpy.shutdown() if __name__ == "__main__": main()

这段代码里有两个关键设计：

• temperature=0.0，让大模型尽量稳定输出，降低随机性；
• 增加了 JSON 代码块清理逻辑，避免模型返回```json标记导致解析失败。

如果你不想引入 OpenAI SDK，直接用requests调用 HTTP 接口也可以，核心是拿到 JSON。

5.4 用“coding-agent”方式生成导航脚本

上面的例子还是“大模型输出数据”，更贴近 coding-agent 的玩法是让大模型直接生成一段可执行的导航代码，再放进沙箱执行。这样做的好处是灵活性更高，坏处是安全性更难保证。

下面给一个最小示例：

# 文件路径：nav_llm_demo/nav_llm_demo/coding_agent_nav.py import textwrap class CodingAgent: def __init__(self, llm_client): self.llm_client = llm_client def generate_script(self, instruction: str) -> str: system_prompt = ( "你是一个移动机器人控制助手。" "请根据用户指令，生成一段 Python 代码。" "代码中只能调用以下接口：\n" " robot_nav.go_to(x, y, yaw)\n" " robot_vision.detect_object(object_name)\n" " robot_io.read_sensor(sensor_name)\n" " robot_io.wait(seconds)\n" "不要写任何 import 语句，不要写 main 函数，" "直接输出可执行的代码块。" ) # 省略实际的 API 请求过程，思路与 5.3 类似 # 假设返回结果如下： code = textwrap.dedent( """ target = robot_vision.detect_object("水杯") if target is not None: robot_nav.go_to(target.x, target.y, 0.0) robot_io.wait(2.0) else: robot_nav.go_to(1.0, 1.0, 0.0) """ ) return code def execute_script(self, code: str): """在受限的机器人控制环境中执行代码。 生产环境下不要直接调用 exec，建议使用 subprocess 或沙箱。 """ try: exec(code) except Exception as e: print(f"执行失败: {e}") if __name__ == "__main__": # 用真实大模型替换下面的 agent coding_agent = CodingAgent(llm_client=None) script = coding_agent.generate_script("去桌上找一下水杯") print("生成的脚本：") print(script) # 生产环境中建议放到沙箱执行 # coding_agent.execute_script(script)

需要特别提醒：直接exec大模型生成的代码是非常危险的做法。如果模型被恶意诱导，可能会生成访问文件系统、执行 shell 命令的代码。正式环境必须做三层防护：

1. AST 静态扫描，只允许白名单函数和关键字；
2. 在独立子进程或容器中执行，设置 CPU、内存、时间上限；
3. 执行前先打印代码，由人工确认后再下发到机器人。

5.5 运行与验证

启动整个流程时，确保先启动仿真器和 Nav2：

# 启动仿真器（以 Gazebo + TurtleBot3 为例） export TURTLEBOT3_MODEL=burger ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py # 启动 Nav2 导航栈 ros2 launch turtlebot3_navigation2 navigation2.launch.py use_sim_time:=true # 启动大模型规划节点 ros2 run nav_llm_demo planner

预期行为是：

• 输入自然语言指令"去客厅茶几旁边的位置"；
• 大模型返回一个 JSON，包含目标点坐标；
• Nav2 开始规划路径并控制机器人移动；
• 到达目标点后，终端输出“导航成功”。

如果最终没有达到预期，大概率问题出在坐标系、占位或模型输出格式上。排查思路参考下一节。

6. 常见问题与排查思路

6.1 一个额外的隐藏坑：大模型不会自己知道“当前在哪”

很多第一次做“大模型+机器人”的人会犯一个直觉错误，以为大模型真的“看见”了机器人所在环境。实际上，在这个架构里，大模型只能看到你喂给它的文字，它不知道机器人当前坐标、地图边界、障碍物分布、传感器读数。

所以你必须主动把这些信息拼接成提示词。比如：

当前机器人坐标：x=0.2，y=0.8，yaw=0.0 当前场景地图范围：x∈[-5.0, 5.0]，y∈[-5.0, 5.0] 已知可通行区域：客厅、走廊、厨房、卧室 导航目标点候选： - 客厅茶几：x=3.2, y=-1.5 - 厨房台面：x=-2.1, y=2.8 - 卧室门口：x=-0.5, y=4.0 用户指令：去茶几右侧 请输出目标点。

这样大模型的“幻觉”概率会大幅下降。信息越完整，成功率越高。

6.2 排查顺序建议

遇到导航失败，推荐先按下面的顺序排查：

1. 确认目标点是否合法：把大模型输出的坐标手动放到 RViz 里看位置。
2. 确认导航栈是否能独立完成点到点任务：绕过大模型，直接发送一个固定目标点，看 Nav2 是否正常工作。
3. 确认坐标系是否正确：比如地图坐标系 map 与机器人坐标系 base_link 是否对齐。
4. 确认大模型输出是否稳定：连续调用 10 次，看 JSON 格式、坐标是否一致。
5. 确认提示词是否包含足够信息：场景边界、可通行区域、候选点。

7. 最佳实践与工程建议

7.1 用“分层决策”而不是“全端到端”

从 78% 这个案例里，我们得到的真正经验不是“端到端模型没用”，而是“分层决策更容易在真实系统中取得稳定收益”。

推荐架构是三层：

• 认知层：大模型负责理解复杂指令、做任务规划、处理异常分支；
• 逻辑层：状态机或行为树负责管理任务流转，比如“导航到餐桌→检测目标→成功则继续→失败则重试”；
• 执行层：传统导航栈、运动控制库、机械臂 SDK 负责精确物理动作。

大模型只做“它擅长的事”，其余交给确定性的工程模块。这样既能利用通用模型的开放能力，又能保证系统的稳定性和安全性。

7.2 安全边界怎么划

机器人涉及物理运动，安全不能靠提示词约束。必须依赖工程机制：

• 速度上限：在底层控制器强制限速，无论上层输出什么指令，最大线速度不超过安全阈值；
• 急停开关：大模型没有“身体感知”，碰撞风险必须由急停按钮、碰撞传感器和激光雷达安全模块兜底；
• 动态目标过滤：大模型给出的目标点必须通过代价地图合法性检查；
• 代码沙箱：如果采用“coding-agent 生成代码”的模式，执行环境必须隔离，禁止访问文件系统、网络端口和 shell；
• 人工审批：前期落地时，机器人在执行大模型指令前，先把计划发送到远程监控页面，由人确认后执行。

7.3 提示词工程在机器人场景里的特殊之处

机器人任务里的提示词，更像一份“接口文档”，而不是平时聊天的指令。建议固定包含：

• 系统角色定义；
• 可用 API 列表及输入输出签名；
• 当前环境状态；
• 输出格式约束；
• 一个成功示例和一个失败示例；
• 安全提示，比如“遇到不明障碍物必须停止并报告”。

这些信息可以减少模型输出非法结构、编造 API、越权操作的情况。

7.4 数据闭环依然是护城河

通用大模型再强，它对某个具体场景的理解仍然是“猜”。真正能让系统持续变强的，是采集真实运行中的失败案例，整理成大模型微调数据。比如：

• 机器人为什么在某个位置反复失败？
• 用户指令中哪些说法容易让模型歧义？
• 哪些目标点经常被 Nav2 拒绝？

把这些数据沉淀下来，持续做模型微调或检索增强，系统的成功率才会从“通用水平”逐步走向“领域专家水平”。这也是“具身导航大模型”最值得投入的方向——不是靠通用性硬扛，而是用场景数据把通用能力打磨成可用能力。

7.5 模型选型建议

• 如果你只需要“自然语言→目标点”，选择一个支持结构化输出、时延较短的商用大模型或者中等规模开源模型即可；
• 如果你需要“自然语言→复杂多步任务代码”，最好选代码能力强的模型，并配合沙箱执行机制；
• 如果你需要在无网络条件下本地部署，可以选经过量化裁剪的开源模型，但要注意精度下降问题；
• 不管选哪种模型，都不要把“单次成功率”作为唯一指标，要关注失败时的行为是否可解释、可回滚。

8. 总结

回到开始的问题：具身导航大模型“白训”了吗？没有。

真正发生的是，通用 coding-agent 用海量互联网知识和强大代码生成能力，在“任务规划、常识推理、开放指令理解”这些认知密集环节展现了比专用导航模型更强的泛化能力，所以在开放场景评测中打出了更高的成功率。但它在底层安全、时延、确定性上仍然无法替代传统导航栈。

对做工程的人来说，最有价值的方向不是争论“谁取代谁”，而是把二者组合成一套分层系统：大模型做认知决策，传统导航栈做精确执行，中间用工程机制兜底。然后通过数据闭环把整套系统的成功率一步步推到可以商用的水平。

如果这篇文章对你有帮助，可以收藏备用。有疑问欢迎在评论区交流，尤其是你已经试着把大模型接到机器人上的那些坑，你的经验可能比任何论文里的结论都更值钱。