从听懂指令到理解意图： Sensaro OS 的 48 小时黑客松实践

小米技术 2026-09-23 16:04 四川

今年的小米黑客马拉松，48 小时极限开发中，来自不同方向的团队带着各自的想法进入赛场，在有限时间里完成一次次快速验证。

获得小米赛区三等奖的 Sensaro OS 团队，选择了 Xiaomi MiMo 赛道。他们想做的事情很简单：让智能家居不再只是等待指令，而是能够结合人物、环境和上下文，理解人真正想做什么。围绕这个想法，五位队员在 48 小时里搭建了一套从意图理解到环境状态，再到数字孪生与真实设备协同的系统原型。

本文记录的，正是这个想法如何一步步成形的过程。

01

为什么要让环境开始“理解人”

让环境理解人，首先需要回答一个问题：系统理解的“意图”，究竟是什么？

当用户说“我想专注 90 分钟，除了家人不要打扰”，对于语音助手来说，这句话可能最终被拆成几个设备动作。但对于 Sensaro OS，它需要理解的是一个完整的状态：

• Goal：进入专注状态

• Scope：学习环境、手机及相关设备

• Actions：调整灯光、空调、通知

• Boundaries：家人来电、安全提醒不能被屏蔽

• Lifecycle：持续 90 分钟，或者用户主动退出

意图不是一句话对应一个动作，而是用户希望环境最终变成什么样。所以，系统需要理解的不只是“说了什么”，还包括：谁在说、在哪里、正在做什么、当前是什么场景，以及这句话究竟是讨论、尝试，还是已经做出了决定。这也是为什么整个系统需要多模态能力参与。

在系统中，Xiaomi MiMo 承担了从多模态感知、意图理解到方案编排的核心工作。不同的 Xiaomi MiMo 模型承担着不同的角色：

• Xiaomi MiMo-v2.5-asr：识别语音、区分说话人

• Xiaomi MiMo-v2.5：理解视觉、姿态、场景和情绪

• Xiaomi MiMo-v2.5-pro：理解意图、维护候选状态、生成 Sensaro State，并在执行出现问题时重新规划

• Xiaomi MiMo-v2.5-tts：完成提醒、确认和动作解释的语音输出

回到刚才一家人讨论周末出行的场景，它不会简单地把“颐和园”“欢乐谷”“上海迪士尼”当成三个命令，而是持续维护当前的候选意图，并根据后续对话不断调整判断。讨论还没有结束，就先获取天气、路线、车辆电量这些低风险信息。直到意图明确，才生成完整的 Sensaro State，再经过安全检查，把可以执行的动作交给真实设备。最终，设备执行后的状态，以及用户后续的反馈，还会重新回到系统里，继续修正环境状态。

从感知，到世界模型，再到意图判断和规划，系统首先需要完成对场景的理解。而当理解真正进入执行阶段，又会遇到另一个问题：模型理解正确，就意味着它可以直接控制现实设备吗？

03

Xiaomi MiMo 听懂之后，为什么不能马上动手

▍商量不打扰，拍板才动手

家庭对话中经常包含试探、反悔、玩笑和多个候选方案。如果系统听到“欢乐谷”就立刻订票、设置导航或者控制车辆，所谓的主动智能反而会成为新的打扰。

因此，团队提出了一个简单但重要的设计原则：商量不打扰，拍板才动手。

在讨论阶段，系统只更新候选意图和置信度，并预先查询天气、路线和电量等低成本信息。只有识别到明确决定，且行动时间、参与人员和授权关系足够清晰后，才会生成可执行的环境状态。

为了让这一原则真正落到系统里，从“听懂”到“动手”之间，还需要经过四层判断：

• 决定是否明确：判断候选意图是否稳定，行动时间和参与范围是否清楚；如果仍有分歧，系统会继续等待或主动询问。

• 操作风险多高：综合判断动作能否撤销，是否涉及资金、隐私和外部影响，以及设备状态能否回读。

• 是否需要确认：灯光、空调等低风险、可撤销的动作可以自动执行；门锁、支付、燃气等高风险操作必须经过确定性规则和单独确认，模型只能提出建议。

• 当前信息是否充分：如果身份、意图或环境信息不够明确，系统会继续观察、主动追问，或进入风险更低的保守状态。

对于家庭环境中的敏感数据，同样需要设置明确边界。主动理解不意味着无边界地获取信息，这类数据应尽可能在本地处理；系统越接近真实生活，越需要明确能力边界，并将最终控制权交还给用户。

部分安全方向明确、且已经获得用户授权的保护动作，可以由确定性策略特殊处理。例如，检测到燃气异常后自动关闭阀门。但这类动作不能由大模型现场临时决定，而要提前写入明确的安全规则。

进一步接入真实设备后，团队发现，大模型擅长开放式理解和推理，但真实设备系统仍然需要结构化约束、状态机、容错机制和确定性规则。

例如，针对模型 JSON 输出不稳定的问题，团队设计了多层解析机制：优先解析标准 JSON；无法直接解析时，再从代码块或文本中提取结构化内容；如果仍然失败，系统便切换至预设方案。同时，XiaomiMiMo API 也设置了超时和降级机制，避免单个环节异常影响整体运行。

最终，团队形成了一套更清晰的分工机制：模型负责理解和提出方案，系统负责判断是否执行、如何执行，以及执行边界。

模型负责理解开放世界，系统负责约束现实执行。两者之间，需要一层清晰、稳定、可以被校验的工程边界。

04

48小时，如何让 Demo 真正跑起来

▍困难二：真机接入波折

与数字孪生同步推进的，还有真实硬件接入。团队原计划使用的一块蓝牙模组临时找不到，新购买的同型号模组又未能按时送达。继续等待，意味着硬件相关的开发都可能被拖慢。

于是，团队决定：把硬件能力和上层系统解耦。整个系统被拆分为不同模块，并按照高内聚、低耦合的方式分别推进。暂时无法接入真实硬件的部分，通过 API Mock 模拟。

第二天上午，团队终于从周边有硬件经验的同事那里找到一块可用模组。拿到模组后，负责硬件的成员立即开始组装和调试，其中还涉及片上系统固件的重新烧写。由于前一天已经提前准备好了软硬件环境，整个过程得以继续推进。

中午过一点，蓝牙模组终于与整个系统打通，基本功能符合预期。

团队开始着手进行整体联调，各个系统模块终于开始真正对接。但在第一次发出自动控制命令时，由于联调参数设置不当，加上队员没有注意到本次命令会发送成功、小车放置的位置又靠近工作台边缘。小车突然冲出工作台，砸向地面。原型车瞬间损坏，蓝牙模组被甩出，连接引脚及附近 PCB 线路也受到破坏。

但为了让系统决策真正落到物理设备，联动更加直观，团队决定尽可能保住真机演示，冒着大雨前往了中关村，寻找替代模组。

周末的电子城异常冷清，很多店铺已经关门，在连续跑了多个楼层和商场后，他们终于在一家即将结束营业的店铺中找到所需型号并买下两块。回公司路上，雨越来越大，队员们却开始说笑：“本来不太抱希望，踩点都能买到，看来这次要成。”

回到公司后，团队立即投入新的系统联调，更换模组、重新调整参数、再次测试，经过多次微调，大模型生成的控制命令终于能够稳定地驱动原型小车。

成功的那一刻，大家不由得松了口气，五人互相击掌庆祝了起来。

正在进行“重组”的澎程车模

装车完毕，待进一步调优

▍困难三：通信协议限制

硬件问题解决后，新的问题又出现在部署阶段。由于系统横跨前端、后端、手机 App 和硬件设备，为了降低多端延迟，团队最初采用 WebSocket 作为通信协议，前期的 API 定义、开发和 Mock 联调也都围绕这一方案进行。

但部署到比赛专用环境后，团队发现，测试域名的 HTTP/HTTPS 环境并不支持 WebSocket。此时如果继续等待专门的运维支持，不仅时间成本难以承受，整个 Demo 的联调进度也会被拖慢。

团队因此做了一个判断：演示环境负载有限，对实时性的要求也在可接受范围内，当前更重要的是先保证整条链路能够稳定跑通。于是，团队决定将通信方案降级为 HTTP 轮询。

原本围绕 WebSocket 开发的服务端接口、数字孪生前端页面和手机蓝牙网关 App，都需要增加新的 HTTP 接口。但团队并没有直接放弃原有方案，而是进一步做了一层兼容设计：系统优先使用 WebSocket，如果检测到后端环境不支持，再自动切换到 HTTP。

这样既保留了 WebSocket 的实时通信能力，也避免让某一种协议成为 Demo 能否跑通的单点依赖。

改动涉及多个系统模块。在 AI Coding 的帮助下，编码工作得以快速推进，但团队更多的时间仍然花在方案确立、接口澄清和联调测试上。

对于 48 小时的黑客马拉松来说，方案发生变化并不罕见。比坚持最初的设计更重要的，是在限制出现后快速判断：哪些能力必须保留，哪些方案可以调整，再围绕核心目标重新选择实现路径。

05

48 小时之后，沉淀下来的技术思考

Demo 最终跑通后，团队验证的不只是一套系统，也对“大模型+智能家居”有了更清晰的认识。围绕认知闭环、执行边界和多模态信息，他们沉淀出几项关键的工程思考。

1. 建立完整闭环，比生成几条设备指令更重要

回看整个 Demo 从 0 到 1 的过程，团队发现，让 Xiaomi MiMo 生成几条合理的设备指令，只是其中一个环节。真正的难点，是把“感知 → 世界模型 → 意图判断 → 规划 → 安全检查 → 执行 → 状态回读 → 用户反馈”这条链路完整串起来。模型说得再对，如果环境状态回不来、用户反馈接不进去，整个系统就只是一次性展示，而不是一个能持续运行的环境。

2. 概率性认知与确定性执行必须分开

在让 Xiaomi MiMo 真正参与设备控制的过程中，团队发现，模型可以理解和推理，但现实设备的执行不能直接建立在概率性判断之上。因此，团队将 Xiaomi MiMo、Sensaro state 和策略内核分层处理：模型负责理解和生成候选方案，系统负责权限、风险和安全校验。实践下来，团队更加明确，模型与真实设备之间必须保留清晰的工程边界。

3. 多模态信息的关键不在于多，而在于相关

随着语音、画面、人物状态和设备信息不断加入，团队发现，把更多信息交给模型，并不一定能带来更准确的判断。实际开发中， Sensaro OS 会围绕当前意图筛选真正相关的信息，并结合置信度、时间、空间和风险等级进行判断。这也让团队进一步认识到，多模态能力的关键不是“信息更多”，而是“信息与当前任务足够相关”。

-

48 小时里，从蓝牙模组迟迟无法到位，到原型小车意外坠落，再到通信方案临时调整，团队一次次遇到计划之外的问题，也一次次重新拆解、调整方案。在有限时间里让一个最初的设想逐步变成可以运行、可以验证的 Demo。

这次实践也让团队对“大模型+智能家居”有了更具体的认识：真正困难的，不只是让模型理解用户意图，而是如何把感知、判断、规划、执行和反馈完整串起来，并在模型的能力与真实世界的确定性之间建立清晰的工程边界。

对于 Sensaro OS 而言，48 小时只是一次原型验证。如果继续推动完善，团队希望进一步提高设备接入和执行闭环的稳定性与通用性，包括接入更多真实设备、完善状态回读与回滚，以及提升多人、多意图场景下的判断能力。

跳转微信打开