“把物料送到装配区”是一句自然语言，落实到机器人却需要确认物料、站点、路线、设备状态和权限。大模型可以帮助理解这句话，但理解后的结果还要经过可检查的执行流程。
本文讨论一种面向室内搬运机器人的设计思路：让模型提出受约束的任务，由明确的程序检查条件，再交给既有导航和控制系统执行。 以下流程是工程建议，尚未在具体机器人上实现或验证。
从有限的任务词表开始
不要一开始就让模型生成任意控制命令。可以先允许“查询状态”“请求前往已登记站点”“取消指定任务”这类有限操作，每个操作都有固定字段。
例如，将“送到装配区”解析成目标站点编号和任务类型。如果地图里存在两个装配区，系统应请求澄清；如果目标不存在，应返回明确错误。模型给出一个格式正确的编号，只说明格式符合约定，不说明编号真实有效。
NIST 的生成式 AI 风险资料将自信地生成错误内容列为需要管理的问题，也讨论了人对自动系统的过度依赖。将输出写得有条理，不能代替核查。NIST AI 600-1
把检查放在模型之外
建议先把边界写成一张表：
| 层次 | 可以承担的工作 | 必须具备的约束 |
|---|---|---|
| 大模型 | 理解表达、提出候选任务、解释状态 | 只输出约定操作与参数，允许表示不确定 |
| 任务程序 | 核对站点、权限、设备状态，接受或拒绝任务 | 明确规则、任务编号、有效期、重复请求处理 |
| 导航与控制 | 路径规划、运动执行与反馈 | 使用已配置和验证的接口及运行范围 |
| 安全相关系统 | 根据整机设计执行保护动作 | 不把模型回复当作保护动作成立的条件 |
Nav2 已区分路径规划和路径跟随的职责。接入大模型时，可以沿用这一分层，再在上面增加任务理解层；不必把每一层都改成模型决策。Nav2 官方模块说明
“已接受”与“已完成”分别处理
一个任务至少需要区分待检查、已接受、执行中和终态。终态又可能是成功、失败或取消。只有收到执行系统的结果，界面才能显示任务完成；模型说“已送达”不应成为完成依据。
ROS 2 的 Action 为长任务提供目标、反馈、结果和取消机制，可以作为这种交互的参考。具体动作服务器仍要正确实现取消与结果处理，使用 Action 本身不保证机器人能安全停止。ROS 2 接口指南
还要提前规定网络中断、模型超时和状态过期时怎么办。请求超时后，应先查询原任务是否已被接受，再决定是否重发，避免一次口令产生两次执行。
验证时刻意加入“不该执行”的输入
除了正常指令，还应覆盖未知站点、含糊目标、重复请求、过期状态和取消失败。外部文档或识别出的文字应按输入数据处理，不能因为其中写着指令，就获得修改系统规则的权限。
先在只读查询和任务模拟中记录解析、拒绝与状态一致性，再考虑受控环境中的实机验证。评价指标应同时包括错误执行、合理拒绝、失败恢复和可追溯性，不能只统计回答看起来是否合理。
资料与个人经验边界
本文依据公开资料提出系统设计建议，不是已部署方案，也没有真实机器人测试数据。个人经验部分待作者提供并确认可公开记录后补充。资料访问日期：2026-11-03。