2026 具身智能实战：把感知行动契约写进SPEC，MonkeyCode 云端跑通
老刘带 6 人小队给省级农业农村厅做温室巡检调度助手。客户口头说：摄像头看到叶片黄了就派小车去、湿度超了就开窗、人在过道里绝对不能撞，高峰响应压到两秒。
上线第一周就炸了。Qwen 把演示视频当实时画面乱派车，DeepSeek 看见黄叶就编虫害等级，Kimi 窗口一短把上一栋大棚的喷灌指令交差。群里改三天提示词，线上又漂回去。隔壁老同事路过说了一句：别再拿聊天记录当感知行动手册，把感知契约、动作预算、安全红线和失败回退写进 SPEC。
具身智能到底在管什么
具身智能不是“会看图的聊天机器人”，也不是单纯的 Computer Use。它管的是：感知输入能不能对齐现场、动作输出能不能进执行器、安全红线能不能压住物理后果。
可以把它拆成四件套：
- 感知契约：允许哪些传感器、分辨率、时延；图像/点云/温湿度必须带时间戳和棚号，过期帧一律丢弃。
- 动作预算：一次调度最多派几台车、开几扇窗、喷灌持续多久；超时必须降级，不允许无限重试。
- 安全红线：过道有人禁止移动底盘、农药泵未确认禁止开启、跨棚指令必须二次对齐。
- 失败回退：感知对不齐、动作校验失败、模型编造现场，一律停机升级人工，禁止“猜着开”。
值班室比喻很直白：摄像头是眼睛，小车是手脚，SPEC 是值班条例。眼睛花了不能让手脚自己编，条例不写进系统就等于写在群公告里。
为什么 2026 必须认真对待
交付已经从“能聊”变成“能进执行器”。温室、仓储、巡检这类场景，错一次不是错一个字，是撞一次人或喷一次药。
同一套口头规则，在不同基座上服从度差一个数量级。Qwen 爱把演示数据当真，DeepSeek 爱补全看不见的虫害，Kimi 短窗口会丢掉棚号。规则写在群里最容易漂，私有化现场最吃这一套——网闸后面没有“再问一句用户”。
三大落地门槛也一模一样：
- 环境不稳：本地笔记本 Mock 摄像头，一换工控机时间戳就乱。
- 模型不灵：一套提示词只在某一个基座上会看棚号。
- 规则易飘：安全距离从 1.5 米改成 2 米，改在群里，线上还是旧的。
为什么放到 MonkeyCode 上跑
MonkeyCode 是免费、免安装的在线 AI 开发平台，浏览器打开就能用云端真实环境，编译、联调、回放都在云端，不用把工控机搬进会议室。
它内置 GLM、Kimi、MiniMax、Qwen、DeepSeek，同一条巡检工单可以一键切换交叉验证：谁在编造现场、谁把上一棚指令带过来，对完再固化。
需求和 SPEC 管理可以把角色、感知字段、动作枚举、超时、升级条件写成可版本化的契约，而不是聊天记录。完全开源，支持私有化离线部署，适合有网络隔离的农业厅、园区和产线。
基础版免费（1 并发 / 1C4G / 每日 30M Token）；专业会员 99 元/月，旗舰会员 499 元/月。小团队先拿一条巡检链路试点就够。
三步把契约跑通
第一步：新建任务。Qwen 做主实验，DeepSeek 做对照，Kimi 做短窗口基线，专门抓“丢掉棚号还敢喷灌”的样本。
第二步：把规则写进 SPEC。
- 角色：省级农业农村厅温室巡检调度助手
- 红线：不编造虫害与浓度、过道有人禁止移动、跨棚必须二次对齐、不确定就升级人工
- 感知：image 必填且不超过 3 秒、humidity/temperature 带棚号、不允许额外传感器通道
- 动作：dispatch_cart / open_window / start_irrigation 三选一，单次超时 8 秒降级
- 校验：缺图、棚号对不齐、解析失败，重试一次仍失败则升级；禁止在感知未对齐前输出动作
第三步：同批 20 条现场工单对比。编造画面中不存在的虫害 7 降到 0，跨棚喷灌 5 降到 0，过道有人仍派车 4 降到 0。Kimi 短窗口截断棚号，被回退拦住，没有把上一棚指令打出去。
四点建议
- 小任务试点：先做“黄叶派车 + 湿度开窗”，不要一上来全场机器人编排。
- 规则写进 SPEC：感知字段、动作枚举、超时和升级条件都版本化。
- 多模型交叉验证：至少两个基座对同一条工单，专门抓编造和串棚。
- 敏感现场私有化：棚内画面和人员轨迹不出域，用开源版本离线部署。
具身智能的难点不在多买几台小车，而在把“看见什么才能动、动错了谁负责”写成系统能执行的契约。老刘他们把聊天记录换成 SPEC 之后，值班大屏终于不再半夜自己开泵。
MonkeyCode 把这件事从群公告里搬进可跑的云端环境。想试的话，打开浏览器就能开干。
