ROSGPT实战：用大模型把自然语言指令变成ROS机器人动作

把一句大白话变成机器人真正能执行的动作，这事在ROS圈子里被念叨了很多年。早年我们用语音识别加规则模板，后来用意图分类加槽位填充，再往后是行为树编排，每一代都能跑，但每一代都脆——换个说法、多一个修饰词、少一个量词，整条链路就断了。ROSGPT这个概念冒出来的时候，我第一反应是"又一个把大模型硬塞进机器人里的玩具"，直到我自己把一条自然语言指令端到端跑通到轮子转起来，才意识到这次不太一样：GPT补的恰恰是ROS最薄的那一层，也就是从人的模糊表达到一个结构化、可校验、可执行的动作参数之间的翻译。ROSGPT要解决的核心问题很朴素——让不懂ROS话题、不懂Twist消息、不懂四元数的人，用说话的方式指挥一台ROS机器人，同时让懂ROS的人还能守住安全边界。这篇文章适合三类人看：刚学完ROS基础教程想找点真项目练手的在校同学，做机器人产品原型想快速验证交互方式的工程师，以及纯粹好奇大模型能怎么落到物理世界里的技术爱好者。我下面写的东西，都是能直接抄去改的，包括代码、参数、踩过的坑和那些文档里不会写的判断逻辑。

1. ROSGPT 到底在解决什么层面的问题

1.1 传统ROS控制链路的三个卡点

不先把旧链路讲透，就理解不了新方案为什么长这样。一条典型的自然语言控制链路，以前大致是这样：语音转文字，文本送进意图分类器，分类器输出预定义意图标签，再走槽位填充把"向前""三米"这类词抠出来，最后映射成geometry_msgs/Twist或者导航目标点。这条链路在实验室演示里成功率很高，一旦换真实用户，三个卡点立刻暴露。

第一个卡点是表达空间和规则空间的错配。规则是人穷举出来的，而人的说法是发散的。用户说"往前挪一点点"，"挪"不在词表里；说"别走那么快，慢慢来"，这是对速度的连续调节，规则模板很难优雅处理；说"先退半米再左转"，这是复合指令，槽位填充直接懵。第二个卡点是上下文缺失。传统意图分类是单轮无状态的，用户说完"向前走"再说"再远一点"，第二个指令没有前文就无从解析。第三个卡点是开发成本随指令数量线性增长，支持二十种说法要写二十套模板，支持二百种就得有专人维护词表和正则，这在原型阶段是灾难。

大模型进来之后，这三个卡点的性质变了。表达空间的问题交给模型的语义泛化能力，上下文交给对话历史，而模板维护成本从"每一种说法"降到"一套输出规范"。这里的关键认知是：大模型不是替代ROS，而是替代中间那层脆弱的规则翻译器。ROS负责确定性执行，模型负责模糊理解，两者职责必须切干净，这是整个方案能落地的前提。

1.2 大模型接入后的能力边界与预期管理

我见过太多项目在这一步翻车，原因都是期望值没校准。先把丑话说在前面：大模型在ROSGPT里不能做这几件事。它不能直接输出电机 PWM，因为它的输出是概率性的，同一句话两次调用可能给出不同参数，而电机控制要求确定性；它不能做实时闭环控制，因为一次云端调用动辄几百毫秒到两秒，控制器循环周期是十毫秒级，两者差了三个数量级；它不能替代感知，模型看不见激光雷达的点云，除非你把点云结构化之后再喂给它，那成本高得离谱。

它能做的其实也很明确：把非结构化的人类语言，转成结构化的、有取值范围约束的动作描述。这个描述通常是一段JSON，字段是你自己定义的，比如动作类型、线速度、持续时间、目标点名称。转完之后，校验、限幅、执行全部交回给传统的确定性代码。我在项目里给自己定的规矩是"模型只出建议，代码做决策"，模型输出永远要过一层白名单校验和数值钳位，任何越界输出直接拒绝并让模型重试，重试两次还不行就回一句"我没听懂，请换个说法"。这套约束看起来笨，但它把不确定性牢牢圈在了文本层，物理层始终是确定的。

注意：不要把大模型的输出直接eval或者直接塞进Twist。我见过一段演示代码直接把模型返回的JSON反序列化后赋给速度字段，结果模型某次输出了3.5的线速度，机器人当场窜出去撞了桌腿。这个教训值一次重构。

1.3 三条主流接入路线的取舍对比

实际动手前有个选型问题：大模型放在哪、怎么调。我把常见做法归成三条路线，各自的代价差别很大，选错了后面全是返工。

我自己的做法是双通道：默认走本地部署的中等规模模型，保证断网也能演示；遇到本地模型解析失败的复杂句式，再降级到云端接口做一次兜底，同时把这条失败样本记下来，攒够一批就拿去做少样本示例，反哺本地模型的提示词。这套组合在实际测试里把端到端成功率从单通道的八成出头拉到了九成五以上，而成本几乎没增加，因为真正需要兜底的请求不到百分之五。

选型时容易被忽略的一点是输出格式的可靠程度。不同模型对"必须输出合法JSON"这条约束的遵守程度差别很大，有些模型会热心地加一句"好的，这是您要的JSON："然后才给内容，解析器直接崩。所以选模型时我建议先做一个小测试：给它二十条带歧义的中文指令，看它输出合法JSON的比例、字段名写错的比例、数值越界的比例。这三项比跑分榜有意义得多。

2. 系统架构拆解与关键设计取舍

2.1 分层架构：从自然语言到话题指令的四层切分

架构上我坚持四层切分，每一层的输入输出都是明确的、可单测的。第一层是输入层，负责把语音或文本收进来，做基本的清洗，比如去掉语气词、统一数字写法（"三米"转成"3米"），这一层不涉及任何智能。第二层是理解层，也就是大模型所在的位置，输入是清洗后的文本加对话历史，输出是严格符合Schema的JSON。第三层是校验层，这是纯代码，做三件事：JSON语法校验、字段完整性校验、数值范围钳位，任何一步失败就打回理解层重试。第四层是执行层，把校验通过的结构化指令翻译成具体的ROS调用，可能是发布Twist，可能是调用导航动作接口，可能是触发一个预设的行为树。

这么切的理由很实在：每一层都能独立替换和独立测试。想换模型？只动第二层。想加新动作？主要动Schema和执行层。想让机器人支持语音？只动第一层。我见过把模型调用、解析、发布揉在一个两百行的节点里的写法，改一个字段要通读全文，调试时根本分不清是模型理解错了还是执行写错了。分层之后，我可以拿一批固定的文本直接灌进第二层看JSON输出，完全不需要启动机器人，调试效率差好几倍。

层与层之间的通信我用两个话题：/nl_command传原始文本，/action_cmd传结构化指令。中间用自定义消息或者干脆传JSON字符串。用字符串的好处是调试时ros2 topic echo一眼能看清内容，坏处是丢类型安全，所以我在校验层做了严格的Schema检查来补这个缺口。这个取舍在小团队里我认为是划算的。

2.2 指令Schema设计：字段越少，模型越不容易出错

Schema是整个方案的地基，设计得好坏直接决定成功率。我的原则是字段数量控制在六个以内，能用枚举就不用自由文本，能给默认值就不要求模型填。字段一多，模型漏填、填错、自作主张加字段的概率就上去了。

我用的最小Schema长这样：

几个设计细节值得说。action设计成枚举而不是自由文本，是因为自由文本会让执行层写无穷多的分支；加一个unknown兜底项，让模型在没把握时有地方可去，比逼它硬猜要好。reply字段看起来多余，但它在实际产品里非常关键——机器人得有一句人话回应，用户才知道指令被接收了，而不是对着沉默的机器反复喊。target用预设地点列表而不是坐标，是因为模型对坐标的生成能力极差，让它输出"厨房"比输出"(2.3, -1.1)"可靠得多，坐标映射交给执行层查表。

提示：把Schema的说明直接写进系统提示词里，并且给两到三个完整的输入输出示例。只描述字段不举例，模型填错字段名的概率会明显上升。

2.3 安全护栏：三道闸门必须写死在代码里

这部分是我最想强调的。任何让语言模型碰物理执行器的项目，安全护栏不能靠提示词，必须靠代码。提示词里的"请不要输出超过0.3的速度"只是建议，模型可能无视，代码里的min(max(v, 0.0), 0.3)是硬约束。

我的三道闸门是这样布置的。第一道是数值钳位，所有速度、角度、时长字段在校验层做区间夹取，超出上限直接截断到上限，同时记一条警告日志，方便回头统计模型越界的频率。第二道是动作白名单，执行层只认Schema里定义的几个枚举值，任何其他字符串直接丢弃，这挡住了模型偶尔生成的"dance"、"jump"这类不存在的动作。第三道是看门狗超时，每条运动指令下发时启动一个定时器，时长是duration加一秒的余量，超时未收到停止指令就强制发布零速度。这道闸门防的是消息丢失或者执行层卡死导致的机器人狂奔。

另外我单独做了一个/emergency_stop话题，任何节点都能发，一旦收到立刻清零速度并锁定三秒。物理上还留了一个硬件急停按钮串联在电机使能线上——软件护栏再厚，也得有一层不依赖软件的兜底。这套东西在演示时看起来小题大做，真出过一次模型把"快速冲过去"解析成满速前进之后，我庆幸自己写了钳位。

3. 动手实现：最小可用原型从零到跑通

3.1 环境准备与依赖清单

我用的环境是较新版本的长期支持发行版加Python 3，ROS侧使用新版客户端库。这里不写具体版本号，因为不同发行版之间的API差异主要在启动方式上，核心的发布订阅和定时器写法是通用的，你按自己装的版本调整即可。

依赖分三块。ROS侧需要rclpy、geometry_msgs、std_msgs，如果要跑导航还得加导航相关的动作接口包。Python侧需要requests用来调模型接口，jsonschema用来做结构化校验，pyyaml读配置文件。模型侧如果走本地部署，需要一套推理服务，能提供HTTP接口就行，不限定具体框架。

# 创建工作空间 mkdir -p ~/rosgpt_ws/src && cd ~/rosgpt_ws/src ros2 pkg create --build-type ament_python rosgpt_bridge \ --dependencies rclpy std_msgs geometry_msgs # Python 侧依赖 pip install requests jsonschema pyyaml

工作空间建好之后，我先不急着写节点，而是拿一个独立的Python脚本把"文本进、JSON出"这一段单独跑通。这个习惯救过我很多次——模型调不通的时候，你至少能确定问题不在ROS的构建系统上。脚本里直接硬编码一条指令，打印模型返回的原始字符串和解析后的字典，看字段对不对、数值合不合理。

3.2 提示词工程：把Schema讲清楚比什么都重要

系统提示词我改过十几版，最后收敛下来的结构是四段式：角色设定、任务说明、输出规范、示例。角色设定一句话就够，"你是一个机器人指令解析器"，多了没用。任务说明讲清楚输入是什么、要做什么判断。真正起作用的是输出规范那一段，必须把每个字段的类型、单位、取值范围、缺省值列清楚，并且明确要求"只输出JSON，不要输出任何解释文字、不要使用Markdown代码块包裹"。

示例部分我放了两正一负。正例一是一条简单的单动作指令，正例二是一条带复合语义的指令，负例是一条有歧义的指令，示范模型该怎么输出unknown。这个负例很重要，没有它，模型遇到听不懂的话会硬编一个动作出来，而不是老老实实承认失败。

模型参数方面，温度必须设成0或者接近0，这是硬要求。温度一高，同样的输入两次调用可能给出不同的速度和时长，调试时你会怀疑人生。max_tokens限制在两百以内，因为输出就是一小段JSON，给多了纯属浪费并且增加跑偏空间。如果接口支持强制JSON输出模式，一定打开，这一项能把解析失败率压下去一大截。

SYSTEM_PROMPT = """你是一个机器人指令解析器。用户会用自然语言下达移动指令， 你需要把它转成 JSON 动作描述。 输出规范： - 只输出 JSON 对象，不要输出解释、不要用代码块包裹。 - action 只能是以下之一：move, turn, stop, goto, unknown - linear_x：线速度，单位 m/s，范围 0.0-0.30，前进为正，缺省 0.15 - duration：持续时间，单位 s，范围 0.0-5.0，缺省 2.0 - angle_deg：转向角度，单位度，左转为正，范围 -180 到 180 - target：仅 goto 时填写，取值必须是 客厅/厨房/门口/充电桩 之一 - reply：一句不超过 30 字的中文口语回应，语气自然。 - 如果指令无法理解或超出能力范围，action 填 unknown，并在 reply 中说明。 示例1： 输入：往前走一点 输出：{"action":"move","linear_x":0.15,"duration":2.0,"reply":"好的，我往前挪一小段。"} 示例2： 输入：先退后一点再左转九十度 输出：{"action":"turn","linear_x":-0.1,"duration":1.5,"angle_deg":90,"reply":"我先退一点，然后左转。"} 示例3： 输入：帮我泡杯咖啡 输出：{"action":"unknown","reply":"抱歉，我没有这个能力。"} """

复合指令那条其实我处理得不够优雅——示例二里我把"后退"和"左转"塞进了同一个动作，实际执行时是串行两段。更规范的做法是让Schema支持动作数组，但数组会让模型的输出稳定性下降，我在原型阶段选择了牺牲一点表达力换取解析成功率。这个取舍你要根据场景自己判断，如果复合指令占比很高，还是老老实实做数组加逐项校验。

3.3 核心节点实现：订阅、解析、校验、发布

节点的主体就是一个订阅者加一个发布者，中间夹着模型调用和校验。我把校验单独抽成函数，方便写单元测试。

import json import time import requests import rclpy from rclpy.node import Node from std_msgs.msg import String from geometry_msgs.msg import Twist ALLOWED_ACTIONS = {"move", "turn", "stop", "goto", "unknown"} MAX_LINEAR = 0.30 MAX_DURATION = 5.0 MAX_ANGLE = 180.0 class RosGptBridge(Node): def __init__(self): super().__init__("rosgpt_bridge") self.sub = self.create_subscription( String, "/nl_command", self.on_command, 10) self.pub = self.create_publisher(Twist, "/cmd_vel", 10) self.say = self.create_publisher(String, "/robot_say", 10) self.busy_until = 0.0 self.timer = self.create_timer(0.05, self.watchdog) self.get_logger().info("rosgpt_bridge 已启动，等待自然语言指令") def on_command(self, msg): text = msg.data.strip() if not text: return if time.time() < self.busy_until: self.reply("我还在执行上一条指令") return raw = self.call_llm(text) cmd = self.validate(raw) if cmd is None: self.reply("抱歉，我没能理解这条指令") return self.reply(cmd.get("reply", "收到")) self.execute(cmd) def call_llm(self, text): """调用模型接口，带一次重试。实际部署时把地址换成你自己的服务。""" payload = { "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": text}, ], "temperature": 0.0, "max_tokens": 200, } for _ in range(2): try: resp = requests.post( "http://127.0.0.1:8000/v1/chat", json=payload, timeout=8) return resp.json()["choices"][0]["message"]["content"] except Exception as e: self.get_logger().warn(f"模型调用失败: {e}") return "" def validate(self, raw): """语法校验 + 字段校验 + 数值钳位，任何一步失败返回 None。""" if not raw: return None raw = raw.strip() # 容错：剥掉模型偶尔加的代码块包裹 if raw.startswith("```"): raw = raw.strip("`") raw = raw[raw.find("{"):] try: obj = json.loads(raw[raw.find("{"): raw.rfind("}") + 1]) except Exception: return None action = str(obj.get("action", "")).lower() if action not in ALLOWED_ACTIONS: return None # 数值钳位，越界截断而不是直接拒绝，避免频繁失败 try: linear = float(obj.get("linear_x", 0.15)) duration = float(obj.get("duration", 2.0)) angle = float(obj.get("angle_deg", 0.0)) except (TypeError, ValueError): return None linear = max(-MAX_LINEAR, min(MAX_LINEAR, linear)) duration = max(0.0, min(MAX_DURATION, duration)) angle = max(-MAX_ANGLE, min(MAX_ANGLE, angle)) return { "action": action, "linear_x": linear, "duration": duration, "angle_deg": angle, "target": obj.get("target"), "reply": str(obj.get("reply", ""))[:60], } def execute(self, cmd): if cmd["action"] == "stop" or cmd["action"] == "unknown": self.publish_twist(0.0, 0.0) return if cmd["action"] == "move": self.publish_twist(cmd["linear_x"], 0.0) self.busy_until = time.time() + cmd["duration"] elif cmd["action"] == "turn": # 角速度换算见 3.4 节参数计算 self.publish_twist(0.0, self.angle_to_omega(cmd["angle_deg"])) self.busy_until = time.time() + cmd["duration"] / 2.0 @staticmethod def angle_to_omega(angle_deg, ref_duration=2.0): import math return (math.radians(angle_deg) / ref_duration) def publish_twist(self, vx, wz): t = Twist() t.linear.x = float(vx) t.angular.z = float(wz) self.pub.publish(t) def watchdog(self): if time.time() >= self.busy_until and self.busy_until > 0: self.publish_twist(0.0, 0.0) self.busy_until = 0.0 def reply(self, text): self.say.publish(String(data=text)) def main(): rclpy.init() node = RosGptBridge() try: rclpy.spin(node) except KeyboardInterrupt: node.publish_twist(0.0, 0.0) finally: node.destroy_node() rclpy.shutdown()

这段代码里有个容易忽略的细节：busy_until机制。如果用户连着发三条指令，不加这个判断的话三条会依次下发，速度叠加，行为不可预测。加了这个"忙则拒绝"的逻辑，机器人一次只执行一条，语义清晰，安全得多。代价是用户会收到"我还在执行"的回复，体验上有一点点阻塞感，但相比行为混乱，这点代价值得付。

3.4 参数换算：从角度到角速度的实际计算

模型输出的angle_deg是人能理解的度，但Twist要的是弧度每秒的角速度，中间必须换算。这个计算我在实际调试里反复调过，说一下过程。

假设要求机器人左转90度，我选定段时长为2秒，那么角速度ω = θ / t = (90 × π / 180) / 2 = 1.571 / 2 ≈ 0.785 rad/s。这个值没有超过我设的1.0 rad/s上限，可以直接用。如果要求转180度、时长还是2秒，ω就是1.571，超限了，这时候有两个选择：要么把时长拉长到2 × 1.571/1.0 ≈ 3.14秒，要么让模型重新给一个更合理的时长。我选择前者，在校验层自动延长时长，日志里记一笔。

进一步，如果你用的是差速轮底盘，还需要校验角速度对应的轮速是否在电机能力范围内。轮子速度v_wheel = ω × (轮距 / 2)，假设轮距是0.3米，那么v_wheel = 0.785 × 0.15 ≈ 0.118 m/s，远低于一般小车的限速，没问题。但如果你的底盘轮距只有0.15米，同时要求高速旋转，轮速可能接近甚至超过电机额定值，这时候就得限幅或者延长时长。

我觉得这一段计算是很多ROSGPT教程跳过的部分，大家都停在"输出Twist就完事了"，但真实机器人转不准的原因往往就在这里：角速度给得对，时长给得不准。一段2秒的旋转，因为通信延迟和减速时间，实际转角可能只有85度。我的做法是把旋转指令拆成三段：加速0.2秒、匀速、减速0.2秒，时长上给匀速段预留余量，实测下来转角误差能压到正负3度以内。这个细节在演示里有没有人注意不重要，在你真正要用机器人干活的时候，它决定了这套东西是可用的还是只能拍视频。

4. 常见问题与排查技巧实录

4.1 典型故障速查表

我把调试期间遇到过的、以及帮别人看代码时见过的坑整理成一张表，按症状倒查原因，能省不少时间。

4.2 模型幻觉的治理：让"听不懂"成为一种合法输出

幻觉在文本场景里是编事实，在ROSGPT里是编动作。用户说"把那个东西拿过来"，模型如果硬要输出一个move，机器人就会莫名其妙地往前走。治理办法不是让模型更聪明，而是给它一条体面的退路。

我在提示词里把unknown这个选项反复强调，并且配了负例，效果立竿见影。另外做了一个小机制：当模型输出unknown时，节点不光是回一句"抱歉"，还会把这条原始指令和模型返回一起写进日志文件。攒够几十条之后，我会把这些真实失败样本挑几条改成正例补进提示词，或者干脆新增一个动作类型。这个循环跑了三四轮之后，unknown的比例从最初的两成多降到了不足一成，而且降下来的部分都是真实可执行的，不是模型硬猜出来的。

还有一个经验：不要在提示词里写"尽量理解用户的意图"这种话。这句话会诱导模型去勉强解释它不理解的东西。要写就写"如果指令包含你无法映射到上述动作类型的内容，必须输出unknown"，把边界划死。

4.3 延迟与实时性的现实取舍

端到端延迟是这类方案绕不开的痛。我实测过的数据是：本地中等规模模型从请求发出到收到完整JSON，平均七百毫秒；云端接口平均一点四秒，网络差的时候到三秒以上。加上解析、校验、ROS通信，端到端的用户感知延迟在一秒到三秒之间。这个延迟对人说话下指令的节奏来说勉强能接受，但绝不适合做任何闭环控制。

所以设计上必须把开环指令和闭环控制彻底分开。用户说"向前走两米"，这是开环指令，走两秒延迟启动无所谓；用户需要机器人实时避障，这是闭环，必须由本地的控制器以几十赫兹的频率跑，模型绝对不能插在这条环里。我在节点里设置了忙锁，本质上也是在承认"我不追求低延迟，我追求指令清晰"。

想压延迟的话有几招。一是让模型输出尽可能短，max_tokens给到两百而不是两千；二是本地部署，把网络往返砍掉；三是做指令预取，用户开口的瞬间先发起一次请求，用语音端点检测触发，抢出几百毫秒；四是维护一个高频指令缓存，像"停"、"过来"这种常用短指令直接查缓存不走模型。第四招最简单也最有效，我做了十几个常用指令的本地映射，命中率大概三成，相当于这三成的请求延迟直接降到几十毫秒。

注意：缓存匹配要做归一化，去掉标点和语气词再比。我一开始用精确匹配，用户说"停！"带了感叹号就命不中，白白走了一次模型。

5. 进阶玩法与我这段时间的真实体会

5.1 从单步指令走向任务分解

单条指令跑通之后，自然想让它做多步任务。"去厨房看看有没有人"这种指令，单靠一次JSON输出搞不定，需要拆成导航到厨房、调用视觉检测、根据结果决定下一步三个环节。我的做法是在理解层和执行层之间加一个轻量的任务规划层，用多轮对话的方式让模型逐步产出子任务，每产出一个就执行一个，执行结果再作为下一轮的上下文喂回去。

这么做的代价是延迟叠加，三步任务可能耗时五六秒，用户会觉得机器人"反应慢"。缓解办法是让模型一次性输出一个任务列表，而不是一步步挤牙膏，然后由本地规划器按序执行。列表形式的输出对模型来说难度更高，需要更详细的示例，但换来的是整体响应更连贯，我觉得值得。这里有个坑：任务列表里任何一步失败，后续步骤都要能优雅中止，不能傻乎乎地往下走。我在每个子任务之间加了前置检查，检查不过就整个任务中止并汇报，而不是硬着头皮执行剩下的。

5.2 视觉信息怎么接进来

纯文本的ROSGPT能力天花板很明显，因为它看不见。想让"把红色的杯子拿过来"这种指令成立，必须把视觉结果结构化之后喂给模型。我的做法是先用本地检测模型把画面转成一段文字描述，比如"画面中有三个物体：左侧红色杯子，中间蓝色盒子，右侧白色瓶子"，然后把这段描述和用户指令一起送进模型。模型要做的事情就变成了"从给定的候选列表里选一个"，这比让它从像素里找东西简单几个数量级，准确率也高得多。

这个思路的核心是永远不要让语言模型处理原始感知数据，它擅长的是在结构化选项之间做语义匹配和常识推理。你把候选列表给它，它选得又快又准；你把点云给它，它除了浪费token什么也做不了。这也是我认为ROSGPT这条路能走多远的关键——它的上限不取决于模型多强，而取决于你能把物理世界结构化到什么程度。

5.3 一些踩坑之后的个人判断

写到这里，说几个不成体系但我觉得有用的判断。第一个判断是关于"要不要用"。如果你的项目只需要支持五六种固定指令，用传统意图识别就够了，上大模型纯属杀鸡用牛刀，还引入了一堆不确定性。ROSGPT真正的价值区间是指令表达高度发散、用户不愿学习固定说法的场景，比如服务机器人面对普通访客，或者科研场景里需要快速验证各种交互假设。

第二个判断是关于"什么时候该放弃模型"。我在调试期定了一条规矩：任何一条指令，如果模型连续三次理解错误，就不再去调提示词，而是把它做成硬编码的本地映射。有些指令就是不该交给概率模型，比如"急停"、"回充电桩"这种容错为零的操作，直接写死更省心。模型负责长尾，代码负责关键路径，这个分工我觉得是舒服的。

第三个判断是关于评估方式。别只看演示视频里那几条成功的指令，要建一个小测试集，至少五十条，覆盖简单指令、复合指令、歧义指令、超范围指令四类，每次改提示词或换模型都跑一遍，记录成功率、解析失败率、越界率三个指标。我一开始嫌麻烦不建，结果改了一版提示词，演示时当场翻车——原本能听懂的说法听不懂了，因为新提示词里示例的表述方式偏了。有了测试集之后，这种回归问题几分钟就能发现。

最后一个体会是关于心态。这类项目最容易陷入的陷阱是把九成的精力花在让模型更聪明上，而只花一成在让系统更可靠上。但实际用起来，用户抱怨最多的往往不是"它听不懂复杂的话"，而是"它偶尔会莫名其妙动一下"、"它转的角度老是差一点"、"我说停它要愣一秒才停"。这些问题全部出在工程细节上，跟模型能力关系不大。所以我的建议是，把提示词调到八成正确率就先去打磨校验层、看门狗、参数换算这些枯燥但决定体验的部分，等系统整体稳了，再回头用测试集慢慢磨那剩下的两成。这个顺序反了的话，你会得到一个演示很惊艳但没人敢真用的东西。