具身智能最近在圈内到底有多火我不用多说了。各大厂商、高校实验室、创投圈都在谈连做前端、做后端的朋友都开始问“大模型怎么跟机器人结合起来”。但说实话绝大多数人看到的都是“具身智能”这四个字的热度真要让一个普通开发者或者刚入门的小白把这个概念落到一个能跑的 Demo 上中间隔着的东西比想象中多得多。这篇内容就是冲着这件事来的。我把具身智能背后真正的大模型应用开发链路拆开讲清楚从技术栈选型、任务拆解、API 接入、函数调用、多模态处理到端侧部署的常见坑一条龙捋一遍。不管你以前是做 Web、做客户端、做算法还是完全零基础只要你会一点 Python 或者至少能看懂代码就能在这篇文章里找到一条从“知道具身智能”到“写出一个能聊、能看、能动的原型”的路径。适合谁看想转 AI 应用方向的程序员、正在做毕设或课题的学生、以及被老板临时拉去搞机器人大脑的倒霉蛋——都适用。1. 具身智能到底烧的是什么火从概念到技术栈拆解1.1 为什么具身智能绕不开大模型很多人以为具身智能就是把 ChatGPT 塞进机器人里让它能说话。这么理解没错但只是最表层的东西。真正的具身智能强调的是“身体”和“智能”的统一一个机器人不仅要听懂人类的指令还要能感知周围环境、规划动作序列、执行物理操作并且在执行出错后自己调整。这里面每一环传统机器人领域都有对应的技术。比如 SLAM 做定位建图、运动规划做路径生成、机械臂控制做抓取轨迹。但传统方案有个致命瓶颈所有能力都是预先编程的换个场景、换个物体、换种说法系统就废了。大模型的出现改变了这个局面它提供的是“常识理解”和“泛化推理”的能力。让机器人理解“帮我把桌上的红色杯子拿过来”这句话再结合视觉模型识别哪个是红色杯子最后用运动规划生成抓取路径——这三段能力拼起来就是一个典型的具身智能应用。大模型在这个链路里不只是“嘴”它更像是一个“大脑皮层”。它负责把自然语言转换成可执行的任务描述把视觉信息转换成语义标签甚至通过推理能力拆解一个复杂指令成多步操作。所以我说具身智能是绕不开大模型的因为它承担了“理解规划”这一层的核心职责。1.2 应用开发者的切入点在哪里搞具身智能听起来像机器人工程师的活要懂 ROS、懂运动学、懂嵌入式门槛确实高。但如果你把视角从“造机器人”切换到“给机器人造大脑”切入点就完全不一样了。现在的机器人本体不管你是用现成的四足机器人、机械臂开发套件还是那种带轮子的移动底盘底层控制基本已经模块化。厂商会提供运动控制 SDK你只要发一条“前进 50 厘米”“抓取前方物体”的指令机器人就能执行。真正需要开发者做的事情是搭建一个“大模型应用层”把用户说的话翻译成这些底层指令把摄像头看到的画面转换成模型能理解的上下文再把执行结果反馈给用户。这条链路其实跟你做一个 AI 客服、做一个智能知识库助手没有本质区别。核心都是大模型应用开发只是输入输出从“文本到文本”变成了“多模态输入到动作指令”。所以对程序员来说切入具身智能的最短路径不是先去啃机器人学而是先把大模型应用开发的基本功打扎实。会调 API、会写结构化输出解析、会设计 Function Calling 的调用逻辑你就已经站在门槛里了。2. 入门AI大模型应用开发前先理清这四件事2.1 先拆任务再选模型不要一上来就问“该用哪个大模型”新手最容易犯的错就是还没想清楚要做什么先到处问“现在哪个模型最强”“该用哪个 API”。但真到了应用层面模型选型取决于你的任务类型和部署约束没有万能的答案。拿具身智能的应用场景举例你需要拆一拆自己的需求你是只做“语音对话意图识别”还是做“视觉 语言 动作规划”的多模态推理你的延迟要求多高如果是实时的机械臂抓取几百毫秒的响应都不一定来得及可能需要局部小模型 云端大模型分层处理。你的数据能不能出本地有些实验室、工厂场景对数据隐私要求严格云端 API 就不一定走得通要考虑本地部署或者私有化方案。你的运行硬件是什么是只跑在服务器上还是要部署到机器人自带的 Jetson、树莓派之类的边缘设备上把这四个问题回答清楚选型自然就有方向了。纯云端、效果优先那就选当前综合能力靠前的大模型 API省心省力低延迟、离线优先那就要考虑 7B、13B 量级的开源模型量化后跑在本地方便如果既要实时又要效果就得做级联——比如本地小模型做关键词提取和粗过滤云端大模型做复杂推理和规划。我在一个校园机器人项目里做的就是第二种方案。机器人上的视觉组件用轻量模型跑识别任务规划统一走云端 API这样既保证了响应速度又能在复杂指令面前不露怯。这个“分级处理”的思路在任何 AI 应用里都值得先想清楚。2.2 理解一次完整的大模型调用到底发生了什么很多开发者的认知停留在“把 prompt 发过去拿到一段文字”。但做 AI 应用开发你必须理解一次调用背后的完整过程输入先被 token 化模型在注意力机制下逐字预测输出经过采样策略生成文本整个过程还有上下文窗口、系统提示词、结构化输出格式等变量在约束结果。你可以不用从头训练模型但至少要理解三个关键概念。第一个是上下文窗口Context Window。它决定了模型一次能“看到”多少信息。你的系统提示词、用户的输入、历史对话、工具返回的结果全部都要塞进这个窗口里。真做具身智能应用时上下文管理非常容易失控。你想想一个机器人执行任务整个过程的日志、视觉识别的中间结果、环境状态信息每轮都要拼进 prompt如果用 6 万 token 的长上下文模型看似很大但几轮之后照样塞满。所以你必须养成“该丢就丢”的习惯只保留对当前决策最有用的信息。第二个是结构化输出Structured Output / JSON Mode。具身智能应用不只是让模型“说话”更重要的是让它输出可以被程序解析的指令。比如让模型输出一个 JSON里面包含动作类型、目标物体、坐标、置信度等字段。如果不开启结构化输出模型大概率会给你一段夹杂着自然语言的文本解析起来让人头大。现在主流平台基本都支持 JSON 输出模式或者用 Function Calling 机制天然返回结构化调用参数这个必须学会。第三个是采样参数Temperature / Top-p。这个直接决定模型的随机性。感知理解类任务比如图像描述、物体识别应该把 temperature 调低比如 0.1保证结果稳定。而开放性的任务规划、对话生成可以适度调高到 0.7让回答更有灵活性。如果你发现机器人经常在同一个任务上做出不同的动作规划别急着骂模型先看看是不是 temperature 设太高了。2.3 把大模型当“实习生”而不是“百科全书”做应用开发有一句经验之谈不要指望大模型永远正确也不要让它承担超出能力范围的事。它更适合作为你整个系统里的“决策组件”而不是唯一的“知识源”和“逻辑裁判”。在具身智能场景里一个可靠的架构通常是这样的感知模块视觉、语音、传感器负责获取信息 → 大模型负责理解和规划 → 规则引擎和安全模块负责兜底 → 底层控制模块负责执行。大模型输出的动作指令必须经过一道合法性校验。比如模型说“执行向桌子方向移动 50 米”明显超出安全边界这时候规则引擎要拦截而不是盲目执行。我见过一个挺有意思的翻车事故。某开发者在调试机械臂时让大模型帮忙设计一个“把易碎物品轻轻放下”的动作序列模型规划得很好实际执行时机械臂却突然猛砸下去。问题出在哪模型本身没问题是开发者在调用时没有限定机械臂的力矩和速度参数导致执行层按默认参数暴力操作。这就是典型的“模型背锅工程买单”。记住大模型给出的更多是意图级别的规划物理世界的参数限制必须由工程层严格把关。2.4 数据、评估和回流AI 应用开发常被忽视的三角模型能跑通 Demo 和能稳定上线之间隔着一个巨大的“工程哈勃常数”——数据、评估、回流。数据在这里不是指训练数据而是“用户/场景数据”。你的机器人交互过程中会产生大量指令日志、执行结果、失败记录这些数据不能只躺在数据库里吃灰你要把它们变成评估集。每隔一段时间拿一批真实场景的 query 去测当前模型输出看看哪些任务稳定、哪些任务飘。评估这件事在具身智能里尤其难做因为动作执行结果很难靠自动评测打分。我的做法是分级评估第一级是结构评估检查模型输出的 JSON 是否合法、字段是否齐全第二级是语义评估看规划的动作序列是否符合常识第三级才是真机测试人工观察执行效果。三级评估跑下来系统稳定性才会真正有保障。回流更直白把执行失败的数据和人工修正的结果整理成 Few-shot 样本或指令微调数据逐步改进模型表现。小项目阶段做不了模型微调那就把这些样本作为参考示例拼到 prompt 里也能带来肉眼可见的提升。3. 手把手搭建第一个具身智能大模型交互 Demo3.1 设计一个足够简单但完整的交互流程如果这是你第一个具身智能 Demo我建议不要一上来就做真实机械臂抓取那个成本太高而且一旦动作出错很容易损坏设备和周围环境。先用一个模拟项目 X 来练习用摄像头获取桌面画面让大模型理解画面里的物体响应自然语言指令模拟输出动作规划序列。等这条链路完全跑通再把模拟的动作输出替换成真实设备的 SDK 调用即可。我的模拟项目 X 交互流程设计如下用户发送文本指令例如“帮我把桌上的蓝色水杯拿给我”。系统调用视觉模块对桌面图像进行目标检测把检测到的物体名称、位置坐标、颜色等信息整理成缩略描述。把用户指令、视觉描述、系统提示词拼装好调用大模型 API。大模型输出结构化 JSON包含动作序列和参数。程序解析 JSON经过合法性校验后模拟执行动作并打印日志。整个流程可能不到 100 行 Python 代码就能串起来但它覆盖了具身智能应用的核心感知、理解、规划、执行。3.2 环境准备与依赖清单开始之前你需要准备这么几样东西Python 3.10 以上环境基本的 requests 库或 openai 库一个可用的目标检测模型接口可以是本地的小模型也可以是云端视觉 API一个大模型 API 的访问凭证支持 JSON 输出或 Function Calling一张测试用的桌面图片或者一个 USB 摄像头用于实时画面采集依赖安装很简单建议用虚拟环境python -m venv embodied_env source embodied_env/bin/activate pip install requests openai pillow numpy这里有个小建议所有 API 的访问凭证和密钥不要硬编码在代码里放到环境变量或配置文件中避免以后项目和 Git 仓库一起泄露。我习惯在项目目录下建一个 .env 文件用 pydantic-settings 或者 python-dotenv 加载整洁又安全。3.3 核心代码实现与逐段讲解先看最简单的版本用视觉模块获取物体列表再让大模型规划动作。import json import os import requests # 模拟视觉检测结果: 实际项目中替换为目标检测模型的输出 def get_visual_perception(image_path): # 这里用硬编码模拟检测结果 return [ {label: blue cup, position: [124, 360], confidence: 0.92}, {label: red book, position: [518, 271], confidence: 0.88}, {label: keyboard, position: [320, 540], confidence: 0.95}, ] def build_messages(user_instruction, perception_data): perception_text json.dumps(perception_data, ensure_asciiFalse) system_prompt 你是一个具身智能机器人的任务规划器。 根据用户指令和视觉感知数据生成一个合理的动作序列。 必须输出 JSON格式如下: { actions: [ {action: move_to, target: blue cup, params: {x: 124, y: 360}}, {action: grasp, target: blue cup, params: {force: 0.4}} ], reasoning: 简要说明规划理由 } 注意: 动作必须来自视觉感知中存在的物体禁止产生幻觉。 return [ {role: system, content: system_prompt}, {role: user, content: f用户指令: {user_instruction}\\n视觉感知: {perception_text}}, ] def call_llm(messages): api_key os.environ[LLM_API_KEY] url os.environ.get(LLM_API_URL, https://api.example.com/v1/chat/completions) headers {Authorization: fBearer {api_key}, Content-Type: application/json} payload { model: os.environ.get(LLM_MODEL, current-default), messages: messages, temperature: 0.2, response_format: {type: json_object}, } resp requests.post(url, jsonpayload, headersheaders, timeout30) resp.raise_for_status() data resp.json() return json.loads(data[choices][0][message][content]) def validate_actions(actions, perception_data): valid_labels {obj[label] for obj in perception_data} for act in actions: if act.get(target) and act[target] not in valid_labels: raise ValueError(f目标物体 {act[target]} 不在视觉感知列表中) if act[action] not in {move_to, grasp, release, move_forward}: raise ValueError(f非法动作类型: {act[action]}) print(动作合法性校验通过) return actions def main(): user_instruction 帮我把桌上的蓝色水杯拿起来 perception get_visual_perception(desktop.jpg) messages build_messages(user_instruction, perception) plan call_llm(messages) validated validate_actions(plan[actions], perception) print(大模型的规划结果:) print(json.dumps(validated, ensure_asciiFalse, indent2)) # 实际项目中在这里把 validated 转换为机器人 SDK 指令执行 if __name__ __main__: main()这段代码里有几个细节值得展开讲。首先是系统提示词的设计。我特意强调了“动作必须来自视觉感知中存在的物体禁止产生幻觉”。原因很直接——如果画面中根本没有杯子模型却规划了抓取动作到了真实机器人场景就是一次空抓甚至碰撞。让模型严格基于感知数据做规划是具身智能应用安全性的第一道防线。其次是 temperature 的设置。我用 0.2 而不是默认的 1.0是为了让动作规划结果尽量稳定可复现。规划任务和闲聊不同它更像是要“输出有限范围内的最佳选择”随机性低一些更合适。如果你在做开放式的任务探索再考虑调高。再看 validate_actions 这个函数。这是我自己特别强调的“兜底层”。大模型输出再结构化也可能出现字段缺失、动作类型拼写错误、目标物体不在场景内等问题。健壮的应用开发一定不能跳过合法性校验。在真实项目中这里还会增加安全区间判定例如目标坐标是否超出机械臂可操作范围、动作执行顺序是否逻辑合理、是否存在自碰撞风险等。3.4 从模拟输出到真实机器人执行Demo 跑通之后最激动人心的就是把模拟动作换成真实设备调用。别急着直接替换我建议分三步走第一步把动作序列转成统一的中间指令格式例如RobotCommand列表。这一步的目的是让上层逻辑和底层设备完全解耦。第二步为你的真实机器人 SDK 写一个适配器Adapter负责把RobotCommand转换为 SDK 调用。第三步先用软硬件联动测试比如设置机械臂的虚拟边界和力限制将速度、力矩调到最小再跑一轮完整流程。这里特别提一个容易犯的错直接把大模型输出的坐标传给机械臂。因为视觉坐标通常是像素坐标或相机坐标系下的坐标而机械臂有自己的世界坐标系中间需要一个坐标变换。你有几种处理方案用标定好的单应性矩阵做像素到平面坐标的映射或者把感知模块的坐标已经输出成机械臂基座坐标系下的三维坐标或者只在抓取平面上工作简化问题。我在某个机器人项目里就吃过这个亏。视觉模型运行得很漂亮机械臂也调试得很顺但接在一起后机械臂的抓取点偏差达到十几厘米问题就出在坐标系上。后来我先用几个已知坐标点做标定再在代码里调用 OpenCV 的解算方法求变换矩阵问题才彻底解决。对新手来说最好在项目一开始就跟清楚每个数据的坐标系来源别等到真机测试才排查。3.5 让机器人具备“看”的能力多模态视觉输入的接入前面那个 Demo 用的视觉信息是预先模拟好的如果要做真正的具身智能视觉模块必须和模型链路打通。有三种接入方式第一种是“文本化感知”把目标检测模型的结果转成文字描述。上文 Demo 就是这种做法。这种方式的优点是省 token模型不需要看图片成本低。缺点是模型无法理解空间布局和细节对复杂场景的推理能力有限。第二种是“多模态模型直接看图”直接把摄像头画面或单帧图像传给支持视觉输入的大模型 API让它输出目标列表和动作规划。这种方式交互最自然模型能同时看图和读文字理解和推理效果好很多。但成本高每轮调用都要传图在边缘设备上带宽和延迟压力也比较大。第三种是“混合感知”感知层用一个轻量模型做对象检测和定位然后裁剪物体区域图片把关键图块和检测结果一起发给多模态模型。这样兼顾了成本、速度和准确性。如果条件允许我自己更推荐这种做法。无论用哪种方式有一个原则不变感知信息必须结构化、有依据地进入 prompt尽可能减少模型的猜测空间。比如给模型的信息应该写成“检测到蓝色水杯置信度 0.92位于画面中心”而不是“画面里好像有个杯子”。4. 实测踩坑记录从 API 接入到端侧部署的五个教训4.1 上下文塞太满效果反而变差我在模拟项目 X 里第一次做连续多轮交互时把机器人的全部执行记录和视觉历史一股脑丢给大模型想着让它“记住一切”结果输出质量直线下降。指令稍微复杂一点模型就开始重复之前的动作或者混淆目标物体。原因是上下文窗口里塞了大量低价值的历史信息比如重复的传感器日志、大量视觉检测的旧坐标、无关的执行噪声。这些信息既消耗 token又干扰模型的注意力。后来我的处理办法是只保留与当前任务相关的摘要信息。比如用一个小模型先对历史对话做总结生成简洁的“前序状态摘要”再配上最近两轮的完整信息送给大模型。效果立刻不一样出错率明显下降。经验就是长上下文不等于高智能。上下文窗口是给你的工具不是让你囤数据的仓库。信息要精简结构要清晰关键状态要显式标注。4.2 函数调用参数出错问题全在“没有锁定枚举值”用 Function Calling 让大模型执行具体动作时最常见的错误是传入非法参数。比如定义了grasp动作的力度字段期望值在 0 到 1 之间模型却经常给一个 0.7 之外的怪异数字甚至把 “force” 写错成 “force_level”。问题根源在于函数定义里的参数描述不够严格。你需要把每个参数的type、enum、minimum、maximum都定义清楚并且在系统提示词里加一句“所有参数必须从给定枚举值中选择不要发明新字段”。这不能 100% 保证模型不出错但能把出错概率大幅降低。另一个更重要的技巧永远让“程序去适配模型”而不是“模型去适配程序”。在解析函数结果时用宽松的解析逻辑比如忽略未知字段、大小写归一化、从枚举值中做模糊匹配。模型输出偶尔不规整但你的解析层足够包容系统就能稳得住。4.3 只测“成功路径”导致模型在边缘场景直接崩盘Demo 阶段大家都喜欢用一两个精心设计的指令测流程比如“把杯子拿过来”。但真实场景里用户的表达方式千奇百怪机器人的状态也五花八门。只测成功路径会让你产生系统已经可用的错觉。有一次我在测试另一组实验时让机器人处理一个超出视野的目标对象。用户问“我身后的书呢”画面里根本没有书。模型居然自信地输出了一套完整的抓取方案还编造了一个不存在的坐标。后来我在系统提示词里加了严格限定如果目标物体不在感知列表中必须输出error: object_not_found并停止规划动作序列。这才把问题堵住。所以做评估时一定要覆盖失败路径、冲突指令和模糊表达。你可以整理一个“对抗性测试集”专门用各种刁钻问题轰炸模型看它能不能体面地拒绝而不是硬编造。4.4 端侧部署不是“模型换小”这么简单说到机器人端侧的模型部署很多人以为把一个大模型换成 7B 或更小的模型就算部署完成。实际上端侧部署至少要面对三个问题第一是显存和算力。Jetson Orin 这类设备跑 7B 模型量化版本已经是极限帧率也要看量化精度和数据长度。第二是散热和功耗。机器人是移动设备长时间高负载跑模型温度一上来就降频推理速度断崖式下跌。我见过某开发者把模型放到机器人的主板上结果没过多久设备过热直接关机。第三是依赖环境。不同边缘设备的 CUDA 版本、Python 版本、PyTorch 版本很难完全一致一个不小心就在环境配置里消耗一整个星期。我的建议是端侧部署的项目一开始就建立一个“目标环境清单”把所有依赖版本锁死做成镜像或者安装脚本。具体到模型用 4bit 量化并充分测试精度损失如果发现不可接受宁可减少上下文长度也要保住关键任务的准确率。4.5 日志和可观测性机器人调试的唯一救星大模型应用尤其是涉及真实物理动作的具身智能应用是一个典型的“黑盒子环境”。你在电脑前调试时一切正常一放到真实环境中就各种诡异问题。没有足够的日志排查错误就像蒙眼开车。我从一开始就强制要求每个关键环节记录结构化日志收到什么用户输入视觉模型输出了什么拼装后的最终 prompt 是什么大模型原始输出是什么解析之后的动作序列是什么校验器是否放行底层设备实际执行结果是什么每一层的输入输出都记录下来发生问题时能快速定位到底是哪一层出了问题。尤其记得把“模型原始输出”原样存下来而不是只存解析后的结果。因为解析层可能丢信息也可能是解析代码的 bug 导致指令错误。只有原始数据在手你才能在事后复盘时看清真相。5. 从 Demo 到产品进一步提升的四个方向5.1 给模型装上“手和脚”动作原语与技能库当前 Demo 的粒度还停留在单动作级别比如move_to、grasp这在真实复杂任务中远远不够。真实场景里的指令往往是“帮我把书桌整理一下”这需要模型能把它拆解成一系列原子操作并调用已有的“技能原语”。我建议你在项目演进时把动作封装成一个“技能库”。你事先设计好一批精细化的技能函数例如pick_and_place(src, dst)、open_drawer(id)、align_to_edge(obj)。大模型不直接输出原始坐标而是输出相应技能的名称和参数。这样既降低了模型被坐标细节搞糊涂的概率又方便你做安全校验、复用和版本迭代。技能库的设计要注意“原子性”和“可组合性”。每个技能只完成一件事多个技能组合在一起完成复杂任务。例如把“整理桌面”拆成“识别乱序物体-分类-移动到目标区域-摆放整齐”每一步对应不同技能整体逻辑清晰又可控。5.2 让机器人学会“追进度”任务状态跟踪上一轮规划的动作执行完毕之后系统需要更新状态决定下一轮做什么。这就是任务状态跟踪Task State Tracking。一个更实用的设计是把“当前环境状态描述”显式保存在状态变量里每一轮执行完成后让视觉模块重新感知场景把新的物体分布、机器人位置、动作完成情况汇总成一个“状态摘要”喂给模型。这样模型才能知道“杯子已经抓到了”“下一步该放下来”。状态跟踪最大的坑是状态漂移。真实环境不是静止的光照变化、行人走过、物体被碰了一下都会让视觉结果变化。与其追求完美的状态一致性不如让感知模块每轮刷新用容错机制接受状态的一定程度出入。5.3 多机协同从单智能体到多智能体调度当你的机器人从一个变成两个、三个模型的应用就从“单脑单身”升级到“多脑多身”。多机协同的难点不在于每个机器人多聪明而在于任务分配和冲突避免。比如两个机器人同时要经过同一个门口这需要决策层有全局视角。实际做法里通常会有一个“中心调度模块”接收所有机器人的状态用大模型做任务分配和路径协调或者用更轻量的规则算法解决分配问题。现阶段我建议别急着让大模型直接做多机调度它太不稳定了。先用规则做兜底把调度问题限制在小范围大模型只在遇到规则覆盖不了的新情况时介入。这样系统既保证实时性又保留了智能扩展的可能。5.4 持续迭代的数据闭环你的护城河最后想多说一句具身智能项目能不能越做越好核心不在模型选择而在数据闭环。你的每次执行都在生成新数据。这些数据如果只是堆在硬盘里那只是废料如果被整理成高质量的训练/评估样本那就是资产。具体操作可以是这样每次执行完成后给动作序列和执行结果打标签分为“成功”“可接受”“失败”“危险”四类。每周抽取失败案例人工修正后入库。每月用入库数据评估模型效果挑出反复出错的场景针对性补充 prompt 示例或者微调数据集。坚持三个月你的系统在特定场景下的表现一定会远超裸调用大模型的效果。这就是工程经验带来的差异化也是别人不容易抄走的护城河。写在最后面的几点个人体会这几年来我一直在做 AI 应用方向的东西眼看着大模型从一个“聊天玩具”慢慢变成了机器人等物理世界系统的核心推理引擎。给我最大的体会是AI 应用开发的门槛确实在快速降低但门槛低不代表没有门道。工具越来越简单反而对开发者的工程判断力要求更高了。再分享一个小技巧在进行大模型调用时在 prompt 末尾显式加上“请严格检查你的答案是否符合上述字段要求缺失字段的输出会导致严重后果”。这种看似带威胁色彩的语句实测能明显提高模型输出格式的完整率。原因大概是它把模型的注意力重新拉到了约束条件上。上面那段代码里的 verify 函数是我专门写的但很多平台本身支持链式思考推理如果你用那些能力更强的底层接口也可以让模型在输出前自己验证一遍。哪怕是简单的一句话都比你默默祈祷它不要出错要强得多。具身智能这个方向现在看起来热得发烫大模型应用开发则是把热量变成动力的传动装置。从这一篇开始希望你不再只是个看热闹的人而是能亲手把一行行代码变成机器人的行动指令。跑起来你就赢了大多数人。