企业官网建设流程全解析

最近圈子里有个现象很有意思：一批专门为具身导航训练的“大模型”刚发布没多久，另一拨人却直接把代码生成智能体（coding-agent）接到机器人上，跑了一圈导航任务，成功率报到了78%，把不少“工业级专用模型”都比下去了。于是有人开始嘀咕：花大力气训练导航大模型，是不是白训了？

我的判断比较折中，但方向很明确：纯通用 coding-agent 裸接机器人，能在部分评测集上跑出高成功率，这背后有真实的技术逻辑，但它不是“专用模型白训了”，而是“专用模型的训练方式可能该换思路了”。本文不打算站队，而是把这个现象拆开看：coding-agent 为什么能接导航任务？它的 78% 到底意味着什么？它在什么条件下会翻车？以及最重要的——做具身导航的团队，能从中学到什么，不用推倒重来，但可能需要调整架构。

文章会从概念对比、原理解析、一个混合架构的代码示例、评测指标设计到排错清单逐步展开，尽量让对这个话题感兴趣但还没动手的读者，读完能形成一条自己的判断线。

1. 具身导航大模型与 coding-agent 的路线之争

先把名词对齐。具身导航大模型，通常指那些输入“视觉观测 + 语言指令”，输出机器人动作序列或导航目标点的模型。它们往往在仿真环境里预训练，再迁移到真机上，训练目标非常明确：让机器人从 A 点走到 B 点，途中避开障碍，完成语义任务比如“去厨房拿杯子”。

coding-agent 则是另一类东西。它本身不是为机器人设计的，它的核心能力是理解自然语言描述的需求，生成或调用代码完成任务。典型场景是：你告诉它“写一个 Python 脚本处理这批 CSV 文件”，它给你返回可运行的代码，或者直接调用某个接口执行。

路线之争的起点是：既然 coding-agent 已经能“理解复杂指令 + 调用工具 + 执行结果”，那为什么不把它直接接到机器人的传感器和执行器上？让机器人把“导航到茶几旁边”当成一个 API 调用，让 coding-agent 来调度和决策，这比专门训练一个导航模型成本低得多。

从表面看，这确实有吸引力。专用导航大模型的训练数据要采集、要标注、要仿真对齐，周期以月计。而 coding-agent 是现成的，接上 ROS 或机器人 SDK，再写几个工具函数，看起来一两天就能跑通。成功率数字又那么漂亮，自然会冲击“专用模型才可靠”的传统判断。

但这个路线之争的实质，并不只是“通用对专用”的胜负。它真正挑战的是：机器人导航这类任务，到底需要多少“具身经验”，又有多少可以靠“常识推理 + 工具调用”解决？如果后者占比很高，那通用模型经过轻量适配就能替代专用模型的大部分功能；如果占比不高，那 78% 就只是一个评测集上的偶然。

后面几节我会用更具体的技术机制来解释这个判断。先说明一点：这不是一个“谁替代谁”的问题，而是一个“任务复杂度分层”的问题。

2. 为什么 coding-agent 能接到机器人导航上

很多做机器人的同学第一反应是：“coding-agent 又没学过机器人控制，它怎么知道怎么走？” 这个疑问来自一个隐含假设：导航必须由“熟悉机器人运动学”的模型来完成。但 coding-agent 的性能来源，其实不在运动控制，而在下面三层：

2.1 对自然语言指令的语义理解

导航任务的第一步是“理解要去哪”。这看起来简单，实际很复杂。指令“把客厅桌子上的纸巾拿过来”，机器人需要解析出目标物体是纸巾、目标位置是客厅桌子、任务边界是“拿过来”。传统专用模型通常用固定模板解析意图，遇到长尾表达就会退化。coding-agent 在大量代码和文档语料上预训练过，语义理解覆盖面广，对这种复杂指令的解析能力往往更强。

这在“具身导航大模型”里其实是个常被忽略的短板：很多导航模型在训练时把指令编码成固定长度的向量，长指令、多子句指令、指代消解都会丢信息。而 coding-agent 擅长把指令先转成结构化的中间表示，再映射为工具调用，这本质上是一种更稳健的“意图理解”。

2.2 用“代码即策略”的方式连接感知与执行

coding-agent 不直接输出“左转 30 度，前进 2 米”这样的底层控制量，而是生成代码来调用现成的导航模块。比如它可能会生成下面这段逻辑：

# 伪代码：coding-agent 可能生成的导航调度逻辑 from robot_api import Robot robot = Robot() target = robot.semantic_search("客厅茶几") # 语义搜索目标点 if not target: robot.ask_user("我没有找到客厅茶几，请确认附近是否有遮挡") else: plan = robot.plan_path(target) # 调用全局路径规划 while not plan.completed: robot.follow_path(plan) if robot.detected_obstacle(): plan.reroute() # 动态避障

这段代码本身没有任何“智能”，但它展示了 coding-agent 的真实价值：把不熟悉的机器人硬件能力，封装成可组合的软件逻辑。机器人的底层导航栈可能已经提供了路径规划、动态避障、里程计定位等功能，coding-agent 要做的不是重新发明这些能力，而是像写业务代码一样把流程编排起来。

这解释了为什么它能“裸接”机器人：只要你给它提供清晰的工具 API 文档，它就能像使用代码库一样使用机器人能力。传统专用导航模型是把“感知到控制”的映射放进神经网络权重里，而 coding-agent 是把“感知到决策”的逻辑写成了显式代码。

2.3 任务失败时的自我修正能力

专用导航模型遇到规划失败，往往直接返回“无法到达目标”。coding-agent 则有一个专用模型通常不具备的机制：它能看到错误信息，修改代码，重新执行。这种“看错误信息 → 改策略 → 重试”的循环，让它在真实环境中更有韧性。

比如第一次调用路径规划接口时，因为起点和目标点距离太近，规划器报错。coding-agent 可能会改成先让机器人小幅后退，再重新规划。这种问题在仿真评测里很少出现，但在真实机器人上非常常见。

2.4 这套路线对传统技术栈的依赖仍然很深

但注意，上面所有机制都建立在一个前提上：机器人底层已经具备可调用的导航能力。如果没有成熟的 SLAM、路径规划、避障模块，coding-agent 就算写出花来，也只是在空壳上做决策。这也正是“裸接”两个字最容易误导人的地方——它不是不需要导航技术栈，而是把导航技术栈从“模型参数”搬到了“系统组件”。

这个区别非常重要，后面会说清楚为什么它既给了 coding-agent 机会，也限制了它的天花板。

3. 成功率 78% 是怎么来的，又意味着什么

先声明一下，这个 78% 的数据来自行业讨论和评测场景，不同评测集、不同机器人平台、不同指令复杂度下，数字会明显波动。我不打算把它当成一个严格复现的实验结论，而是当作一个“方向性信号”来看。

3.1 成功率指标的常见陷阱

评测“成功率”有一个经典问题：任务成功的定义边界在哪里。对导航任务来说，至少有三个口径：

很多“高成功率”只统计了第一项。如果机器人绕远路、贴墙蹭过去、甚至多次倒退，只要最终到达就算成功，那这个数字会虚高。

所以 78% 这个数字本身不能直接说明“超越了专用模型”，必须看评测口径是否一致。如果专用模型用无碰撞到达率，而 coding-agent 用端到端到达率，那两者根本不具备可比性。

3.2 coding-agent 在什么场景下容易刷出高分

结合编码智能体的能力特点，它在下面几类场景中表现较好：

• 指令类型丰富但语义清晰。比如“去卧室窗户附近看一下”，目标位置可以通过语义搜索得到，不依赖精确坐标记忆。
• 环境结构化程度较高。比如室内走廊、房间布局规整，底层路径规划器本身就能处理大部分情况。
• 允许重试和交互。如果机器人错过了目标点，可以“掉头再找”，这种容错空间对 coding-agent 的自我修正能力非常有利。

反过来说，如果评测集中在“只给一次规划机会，不允许失败重试”，或者目标点在没有任何语义标签的开放环境中，coding-agent 的优势就会被大幅削弱。

3.3 为什么专用模型反而可能吃亏

专用导航大模型的训练范式，往往是“端到端学习”：输入图像和指令，直接输出动作分布。这个范式的优势是反应快、不依赖外部模块，但劣势也很明显：

• 对不在训练分布中的场景，泛化能力不足。换一个光照条件、换一类地砖纹理，模型可能就“不认识路”了。
• 端到端模型更像一个黑盒，错误一旦发生，很难定位是感知错了、决策错了还是控制错了。
• 训练数据通常来自固定环境的仿真采集，评测环境如果和训练环境差异大，性能会快速下滑。

所以“coding-agent 反超专用模型”这个现象，更准确的解释是：在不少“语义导航 + 结构化环境”任务上，用现成工具组件 + 大模型调度，比在有限训练数据上硬学端到端策略更稳。

4. 具身导航真正需要的，是多层架构而非单一模型

写到这里，可以给出本文的核心判断了：具身导航大模型“白训了”是一个过于绝对的结论，但“单一端到端大模型包打天下”的思路，确实在面对真实环境时显得吃力。从工程角度看，更值得采用的是分层架构：通用模型负责高层语义决策，传统算法模块负责底层运动执行，中间用工具接口衔接。

这种架构并不新鲜，在自动驾驶和工业机器人领域早有类似做法。但 coding-agent 的介入，让“高层语义决策”这一层的实现成本大幅降低。

4.1 分层架构里的职责划分

关键点在第二层和第五层，这两层正好是专用导航模型主攻的方向，也是 coding-agent 相对容易切入的地方。专用导航模型通常想把第一层到第四层全部压缩进一个网络里，而分层架构允许每一层使用最适合的工具。

4.2 代码示例：一个最小混合架构

下面给一个最小示例，展示如何用 Python 把“语言模型调度 + 底层规划”组合起来。这个示例不依赖具体机器人厂商，用接口占位的方式演示逻辑。

# 文件路径：mixed_navigation_demo.py # 功能：演示大模型高层调度 + 传统路径规划的分层导航架构 # 注意：这是一个架构演示，RobotAPI 需要根据实际机器人 SDK 实现 import json from robot_api import RobotAPI # 假设已有机器人接口封装 class LayeredNavigationSystem: def __init__(self, llm_client): self.robot = RobotAPI() self.llm = llm_client # 任意大模型 API 客户端 self.known_locations = { "客厅茶几": [1.2, 3.4], "卧室书桌": [2.5, 1.8], "厨房冰箱": [4.0, 2.2], } def parse_instruction(self, instruction: str) -> dict: prompt = f""" 请从机器人导航指令中提取目标位置和约束条件。 指令：{instruction} 只输出 JSON，包含 target 和 constraint 两个字段。 """ response = self.llm.chat(prompt) return json.loads(response) def locate_target(self, parsed: dict): target = parsed.get("target") if target in self.known_locations: return self.known_locations[target] # 如果目标不在已知位置，调用语义搜索接口 return self.robot.semantic_search(target) def execute_navigation(self, instruction: str): parsed = self.parse_instruction(instruction) target_pos = self.locate_target(parsed) if target_pos is None: return {"status": "target_not_found", "message": "无法定位目标"} plan = self.robot.plan_path(target_pos) if not plan: return {"status": "plan_failed", "message": "路径规划失败"} max_retry = 3 for attempt in range(max_retry): result = self.robot.follow_path(plan) if result.get("collision"): # 碰撞后让 LLM 决策下一步 recovery = self.llm.chat( f"机器人执行路径时发生碰撞，错误信息：{result}，请给出恢复策略" ) plan = self.robot.plan_path(target_pos, avoid=result.get("obstacle_pos")) continue return {"status": "success", "attempts": attempt + 1} return {"status": "failed", "message": "多次重试仍失败"} # 运行示例 if __name__ == "__main__": llm_client = lambda prompt: '{"target": "客厅茶几", "constraint": "无"}' # 简化示例 system = LayeredNavigationSystem(llm_client) result = system.execute_navigation("去客厅茶几旁边等我") print(result)

这个示例的核心逻辑很简单：大模型负责把指令解析成结构化信息，传统的plan_path和follow_path负责实际导航，碰撞后由大模型给出恢复建议。它没有让模型直接控制电机，而是把模型放在“决策链”的高层。

4.3 更工程化的调度配置

在实际项目中，大模型调度往往不是硬编码在 Python 里的，而是通过配置中心管理。下面是一个 yaml 风格的配置示例，表示不同任务类型使用的导航策略：

# 文件路径：config/navigation_strategy.yaml navigation: default: planner: AStarPlanner obstacle_check: true max_retry: 3 semantic_task: planner: HybridAStarPlanner semantic_search: enabled target_timeout_sec: 30 emergency_recovery: planner: RRTPlanner allow_backward: true fallback_strategy: ask_user

把策略配置从代码中解耦出来的好处是：评估时可以快速切换不同规划器组合，找出哪个配置在目标场景下最稳。这也是“调试大模型机器人”最重要的工程手段之一——不是你换一个大模型就行，而是系统里每一层都可能成为瓶颈，需要单独验证。

5. 评估具身导航模型，不能只看成功率

既然标题里的 78% 声称“反超专用模型”，那我们必须认真讨论评估标准。如果评估指标本身偏了，任何“反超”都只是数字游戏。

5.1 成功率之外，至少要看 5 个维度

• 碰撞率：到达目标的过程中，机器人是否与障碍物发生过接触。真实环境中碰撞会导致设备损坏，是比失败更严重的问题。
• 路径效率：实际行驶路径与理论最短路径的比值。绕远路到达，任务完成了但用户体验很差。
• 任务耗时：包含思考时间、规划时间、执行时间。大模型调度如果每一步都思考 5 秒，真实场景根本不可用。
• 指令泛化性：训练集之外的指令，模型还能不能理解。这是专用模型最容易翻车的地方。
• 故障恢复成功率：首次失败后，系统能否通过重试或调整策略完成任务。coding-agent 的价值主要体现这里。

5.2 一个可落地的评测脚本框架

下面给一个评测脚本的骨架，便于把“成功率”扩展成多维指标：

# 文件路径：eval_navigation.py # 功能：统计多维度导航指标 import time import statistics def evaluate(task_list, robot_runner, max_steps=10): metrics = { "success_rate": [], "collision_rate": [], "path_efficiency": [], "task_time": [], "recovery_success": [], } for task in task_list: start = time.time() result = robot_runner.run(task, max_steps=max_steps) metrics["success_rate"].append(result.get("success", 0)) metrics["collision_rate"].append(result.get("has_collision", 0)) metrics["task_time"].append(time.time() - start) actual_path = result.get("path_length", 0) shortest = result.get("shortest_path", 0) efficiency = actual_path / shortest if shortest else 0 metrics["path_efficiency"].append(efficiency) metrics["recovery_success"].append(result.get("recovery_success", 0)) summary = { "success_rate": statistics.mean(metrics["success_rate"]), "collision_rate": statistics.mean(metrics["collision_rate"]), "avg_path_efficiency": statistics.mean(metrics["path_efficiency"]), "avg_task_time": statistics.mean(metrics["task_time"]), "recovery_success_rate": statistics.mean(metrics["recovery_success"]), } return summary

在真实项目中，建议把每个任务的具体指令、地图 ID、传感器配置、失败原因都记录下来，方便后续定位是哪一层出了问题。这个脚本骨架还可以扩展成把结果写回数据库或对象存储，形成长周期回归数据。

5.3 评测集设计的两个原则

第一，训练集和评测集不能“同分布”。如果评测场景都是训练数据的轻微扰动，那测出来的数字没有迁移意义。第二，必须包含失败场景。比如目标物体被遮挡、地图未更新、传感器噪声异常等，这些才是真实使用中决定系统可用性的场景。

很多团队的评测报告看起来很漂亮，因为选的任务都是模型擅长处理的任务。真正有价值的评测，是让模型在“它不擅长”的任务上也跑一遍，看它怎么失败、失败后能不能恢复。

6. 当前 coding-agent 裸接机器人有哪些硬伤

前面说了不少 coding-agent 路线的好处，但工程上必须把风险说透，否则读者照着做会踩大坑。

6.1 延迟和成本问题

一次导航决策如果是“大模型 API 调用”，网络往返加解码时间通常需要几秒。这在“机器人停下来思考”的任务里可以接受，但在人流密集环境中，机器人每走几步就要停下来思考几秒，体验和安全性都堪忧。

具体数据因模型和网络环境而异，但从架构判断，任何把大模型放进“高频控制环路”的设计都不合适。高频控制应该保持在 10Hz 以上，交给局部避障和底盘控制器；大模型最多只能出现在 0.1Hz 到 1Hz 的低频决策层。

6.2 安全与可解释性风险

大模型生成的恢复策略，从语义上看起来合理，但可能在真实环境中产生意外后果。比如模型建议“尝试穿过门缝”，如果门缝宽度小于机器人本体，就会导致卡住甚至损坏设备。

工程上必须有“安全卫士”机制：大模型的建议只能作为候选指令，必须经过合法性校验，比如检查目标点是否在可通行区域、路径长度是否在合理范围、速度指令是否超过阈值。校验不过则丢弃并回到默认策略。

下面是一个最小安全校验逻辑：

# 文件路径：safety_check.py # 功能：对大模型建议做基础安全校验 class SafetyGuardian: def __init__(self, max_speed=0.5, max_path_length=50.0): self.max_speed = max_speed self.max_path_length = max_path_length def check_command(self, command: dict) -> bool: # 检查速度限制 if command.get("type") == "move": speed = command.get("speed", 0) if speed > self.max_speed: return False # 检查目标点距离 if command.get("type") == "goto": distance = command.get("distance", 0) if distance > self.max_path_length: return False return True

这种校验不是限制大模型的能力，而是把安全责任重新交还给可验证的代码逻辑。当前大模型的输出本质上是一种概率采样，概率再高也不等于真实环境中的安全。

6.3 环境动态变化的感知盲区

coding-agent 的“世界模型”来自训练语料，而不是当前环境的实时状态。如果机器人所在环境发生了结构变化，比如施工导致走廊临时封闭，大模型并不知道。它可能会执着地建议走那条“最短路径”，反而比传统规划器更容易犯错。

所以编码智能体不能是唯一决策者。它需要和实时地图、传感器融合模块组成一套系统，动态地图信息必须优先于模型先验知识。

6.4 机器人厂商 SDK 的接口文档质量决定上限

coding-agent 要“会调用”机器人接口，就得“看懂”SDK 文档。如果文档质量差、接口命名混乱、缺少示例代码，coding-agent 的调度能力会急剧下降。这也是“裸接”很容易翻车的工程原因——不是模型能力不够，而是接口本身没有为模型调用优化。

做法是专门为模型维护一份“机器人能力图谱”，用统一格式描述每个接口的用途、参数、返回值和失败模式。模型调用前先读这份图谱，比直接让它读原始 SDK 文档可靠得多。

7. 专用导航大模型还有没有必要继续训

这个问题是标题留给读者的核心疑问。我的观点是：专用模型没有“白训”，但其训练目标和架构需要调整。

7.1 专用模型仍然有不可替代的场景

在算力受限的边缘设备上，一个几亿参数的专用导航模型，可以做到低延迟、离线运行、输入输出固定，不需要依赖云端 API。这在工业现场、医疗物流、偏远地区等场景里是刚需。coding-agent 路线依赖大模型推理，要么本地跑大模型（对硬件要求高），要么连云端（对网络要求高），这些约束在不少真实场景里根本满足不了。

另外，当任务对实时性要求极高时，比如动态避障、人机协作，端到端专用模型的一步推理延迟通常远低于“调用大模型 API”。这个优势在物理世界里是决定性的。

所以更准确的说法是：专用模型在某些维度上仍然更强，但它在“语义理解”和“长尾泛化”这两个维度上确实不如通用大模型。

7.2 专用模型的训练范式需要进化

从 coding-agent 的表现里，可以提炼出三个对专用模型训练有启发的方向：

• 训练数据中增加“工具调用”样本。让模型学会调用语义地图、路径规划器等外部模块，而不是把所有能力塞进神经网络权值里。
• 增加“恢复策略”训练。当前大多数导航模型只训练“怎么走”，不训练“走错了怎么办”。在评测中加入失败恢复科目，模型实用性能大幅提升。
• 用大模型生成仿真训练数据。利用 LLM/VLM 设计更多样化的指令和场景，缓解专用模型在长尾指令上的数据不足问题。

7.3 混合路线可能是最终形态

未来更可能的业界形态是：一个中等规模的专用导航模型负责底层感知与运动控制，一个通用大模型（比如 coding-agent 类模型）负责高层语义决策与异常恢复，两者通过标准接口协作。这不是“谁替代谁”，而是各司其职。

对团队来说，这意味着大模型技术栈和传统机器人技术栈不是二选一，而是要同时建设。机器人团队需要有人懂大模型 API 接入和 prompt 设计，大模型团队需要有人懂机器人 SDK 和实时约束。这个交叉能力，可能比“训练一个更强的专用模型”更稀缺。

8. 实际落地建议与避坑指南

如果你正在评估“要不要用 coding-agent 做具身导航”，下面几条建议可以根据自己的项目情况参考。

8.1 先判断任务层级，再决定模型路线

8.2 先做仿真回归，再上真机

这不是套话。具身导航模型改动的回归风险很高，因为真机测试成本大、周期长。建议先在仿真环境里跑一个固定任务集，记录成功率、碰撞率、路径效率等指标。每次修改模型、prompt 或工具调用逻辑后，先跑回归，指标不下降再上真机。

仿真环境的选择可以参考机器人仿真平台对比，目前主流有 Gazebo、Isaac Sim、MuJoCo 等，具体选型取决于是否有现成机器人模型、是否需要物理精度、团队熟悉度等。没有“最好”的平台，只有“匹配”的平台。

8.3 prompt 设计要包含“失败处理”

做 coding-agent 导航时，很多人只写任务指令和工具说明，忽略了“失败后怎么办”这一关键部分。建议在系统提示词中明确写入：

• 第一次规划失败时，可以尝试哪些替代策略。
• 哪些操作是禁止的，比如强行穿越窄缝、超速移动。
• 当多次尝试失败时，必须向用户求助，而不是无限重试。

# 系统提示词片段，可放入大模型 API 的 system message 你是机器人导航调度助手。你可以调用以下工具完成导航任务： - semantic_search(target): 通过语义检索定位目标位置 - plan_path(target_pos): 计算全局路径 - follow_path(plan): 沿路径执行 - ask_user(question): 向用户提问 约束： 1. 如果 plan_path 失败，最多重试 2 次，并尝试调整目标点附近的可通行区域。 2. 禁止在未确认安全宽度的情况下穿过狭窄空间。 3. 如果 3 次尝试后仍无法完成，调用 ask_user 请求协助，不得自行尝试未经验证的策略。

这段提示词能显著减少 coding-agent 在真实环境中的“天马行空”行为。不要指望模型自动遵守安全规则，必须写进提示词里，并在安全校验层再做一次硬拦截。

8.4 建立失败日志与回放系统

每次真机运行，都应该记录传感器数据、模型输入输出、规划路径、执行结果。一旦出现问题，可以像回放视频一样分析失败因果。很多具身导航团队在模型训练上投入大量资源，却忽略了工程化的问题追踪体系，导致同样的错误反复出现。

实践中可以把运行数据保存为 bag 文件（ROS 场景）或一份带时间戳的 JSON 日志，配合对应的地图和任务描述。排错时先找“是哪一层出问题”，再决定是否需要换模型、改提示词还是修底层模块。

8.5 团队配置建议

如果团队要同时走“大模型 + 机器人”路线，建议至少有三类角色：

• 机器人工程师：负责底层导航栈、传感器集成、安全校验。
• 大模型应用工程师：负责 prompt 设计、API 接入、工具调用编排。
• 评测工程师：负责设计评测集、构建仿真回归环境、维护失败日志库。

三个角色可以重叠，但不能缺失。很多项目失败不是因为模型不够强，而是没人从全局视角去设计“模型和机器人之间的接口”。

9. 常见问题与排查方法

这些问题没有一个是靠“换更强模型”解决的，大多数要靠工程体系弥补。这是具身导航和纯软件任务最大的不同：模型不是跑在服务器上，而是跑在真实物理环境里，所以“可靠性”和“可诊断性”比“单次性能”更重要。

10. 总结与下一步

回到标题的问题：具身导航大模型白训了吗？我的结论是，没有白训，但“只用大模型包办一切”的训练理念确实需要调整。coding-agent 裸接机器人能够取得 78% 这类结果，真正说明的是：语义理解、工具调用、失败恢复这些能力，在导航任务中的价值被此前低估了；而那些传统导航算法已经解决得很好的底层问题，端到端模型未必能做得更好。

对读者来说，下一步可以按这样的路径实践：

1. 先搞清你的导航任务里，瓶颈在语义层、感知层还是控制层。最简单的做法是拿现有传统规划器跑一遍，如果表现很好，那瓶颈就不在控制层。
2. 如果瓶颈在语义层，接一个标准大模型 API，写一个工具调用层，先跑仿真回归。
3. 如果瓶颈在感知层，比如目标检测、语义分割不稳定，那应该优化检测模型，而不是指望大模型“看图”解决问题。
4. 构建多维评测体系，把成功率、碰撞率、路径效率、恢复成功率都记录下来，建立回归基线。

这个领域的变化速度很快，但工程判断力不会过时：用什么模型，取决于你的任务在哪一层有瓶颈。大模型擅长把复杂语义转化为行动，传统算法擅长在真实物理约束下稳定执行，把它们组合起来，才是当下具身导航最务实的路线。