给现有中控屏加上语音入口，用户说“准备睡觉”，屏幕显示一句“好的”，并不意味着升级成功。灯可能没关，目标房间可能选错，夜灯亮度也可能被保存成以后每晚的规则。原来能通过触控立即完成的任务，反而多了一层看不见的模型判断。
先决定屏幕要替用户确认什么，再决定模型放在哪里。 对大多数存量产品，第一步不是让屏端跑大模型，而是把目标、参数、执行状态和异常放到屏上。已有 MCU 屏若能稳定显示这些信息、连接受控的本地服务，就有机会继续使用；只有显示、音频、内存、接口或维护要求确实超出它的能力时，才进入换板或 Linux 屏评估。
以下用一个明确的假设家庭推演：客厅和卧室各有灯，客厅有一块中控屏，用户说“准备睡觉”。这是产品设计讨论，不是真实客户项目，也没有目标板卡的延迟、成本、功耗或识别率测试。文中的升级路线须回到具体 BOM、固件和控制接口验证，不能当作已经联调通过的方案。
先看任务：一句话之后，屏幕该给出什么
传统控制屏通常按房间列设备，点击按钮后改变图标状态。这种界面对“我知道要控制哪盏灯”很有效，却不擅长回答自然语言带来的歧义：“准备睡觉”是关客厅主灯、调暗卧室夜灯，还是保存一条每天自动执行的规则？AI 带来的价值不是多一个聊天页，而是把原本隐含的选择显露出来。
在这个假设场景里，较稳妥的流程可以分为四个可见时刻：
- 理解后预览：显示“将关闭客厅主灯、把卧室夜灯设为 20%”，并标注这是本次动作，不是永久规则。若系统只知道“主灯”而无法确定房间，先让用户选目标。
- 明确确认：普通低风险灯光可按产品设定直接执行或轻确认；涉及门锁、电热等动作时，不应沿用同一个宽泛的“好的”。是否需要独立可信身份确认，取决于动作风险和实际授权设计。
- 执行中反馈：分别显示两个设备的请求已发送、设备状态已确认或结果未知。按钮变色和模型说“完成了”，都不能代替设备侧确认。
- 部分失败处理：若客厅灯已关而卧室灯离线，屏幕应告诉用户哪一步成功、哪一步未确认，并提供对失败项的明确重试入口；不盲目重放整个场景。
这四步不要求每次都出现四个弹窗。低风险、确定性的开灯命令可以维持快速触控；复合、含糊或持久化的请求才需要更多预览和确认。过度确认会使屏幕比普通开关还难用，完全不确认又把模型的猜测变成了设备动作。设计重点是按歧义、影响范围和可撤销性分级，而不是按“是否由 AI 发起”一刀切。
示意图由 AI 生成，不是目标产品界面或现场测试；图标颜色不能代替设备回执。
一次动作与“以后都这样”是不同产品功能
“今晚把夜灯调到 20%”是一项当前动作。“以后准备睡觉都调到 20%”会改变未来行为，不能因为两句话很相近就走同一条提交路径。后者至少要展示旧规则、新规则、涉及设备、生效时间和恢复入口。保存规则前可以让用户在虚拟预览中查看结果；保存成功也不代表已经发生的物理动作能撤销。
屏幕很适合承载这段差异确认：用户能看见改的是哪个场景，而不是只听一句“我记住了”。但屏幕上的确认按钮不是权限系统。公共区域的屏幕、访客和儿童都可能触碰它；真正的写入权和敏感动作范围仍应由控制服务验证，不能由模型话术或界面可见性决定。
保留 MCU 屏，还是换一块更强的板
先盘点现有产品，而不是先选新 SoC。至少拿到屏幕分辨率和刷新要求、触控与音频硬件、RAM/PSRAM、网络方式、现有设备控制 API、OTA 路径、可访问的状态回执，以及产品的离线要求。缺了这些，无法回答“靠 OTA 就能升级”或“必须换 Linux 屏”。
三条路线的性能、成本与失败风险
路线评估不能只比较芯片单价。保留旧屏可能省掉结构和认证改动，却增加中枢部署、双端升级及售后排障；换 MCU 可换取显示与音频余量，却要重新验证电源和无线；Linux 屏能承载更复杂的软件，也带来启动、补丁和现场恢复成本。把这些项目与首屏响应、复合动作反馈、断网可用性一起列进样机验收表，才能比较同一个产品目标，而不是比较三个不同演示。
| 路线 | 适合的前提 | 屏端主要职责 | 容易被忽略的代价 |
|---|---|---|---|
| 保留现有 MCU 屏，连接本地 AI 中枢 | 现有界面能增加预览与状态页，控制协议可扩展，音频硬件满足目标任务或允许不做语音 | 触控、可见确认、设备状态和基础控制；模型服务在中枢 | 中枢发现、会话恢复、断网退化、接口版本和双端 OTA |
| 更换 MCU 屏或模组，仍连接中枢 | 旧屏显示/音频/内存不足，但不需要在屏上运行开放式模型 | 更复杂的 HMI、音频前端和本地状态缓存 | 硬件、结构件、电源、散热、认证和固件迁移 |
| Linux 屏集成部分 AI 服务 | 确有多任务、复杂媒体或本机推理需求，且维护团队能承担 OS 生命周期 | HMI 与部分推理；控制服务仍独立 | 启动时间、资源竞争、系统更新、安全维护和故障隔离 |
这不是一张按“高级程度”排序的推荐表。若产品需求只是让用户能看见复合动作并处理失败，保留 MCU 屏加中枢通常值得先做验证；若目标是离线开放式对话和多模态界面，就必须重新评估音频、内存和系统维护。若现有屏没有麦克风、播放参考或音频接口，软件升级无法凭空补上声学链路；也可以先交付触控上的预览与配置，不强迫第一版同时支持语音。
以 ESP32-S3 RGB 屏为例，官方 LCD 驱动文档明确讨论将帧缓冲放在 PSRAM、显示 DMA 与 CPU 争用带宽，以及某些配置下的画面撕裂或漂移风险。由此能推断：加入实时波形、复杂动画和音频处理时，必须在目标分辨率与实际负载下测内存和帧稳定性；不能从开发板演示流畅推导存量整机也能流畅。ESP32-S3 RGB LCD 驱动
ESP32-P4 适合被列为更复杂屏端的候选，但官方入门文档明确说明它不内建 Wi-Fi 或 Bluetooth，需要外接无线 SoC。若旧产品依赖单芯片无线和既有认证路径，换 P4 不是直接换一颗更快的 MCU；无线组合、板级接口和维护链都会改变。ESP32-P4 入门与无线边界
ESP-Brookesia 提供面向 AIoT 的 HMI 开发框架，这能帮助团队评估界面组件和 Agent 接入方式，却不能证明目标屏、现有驱动、音频链或产品 OTA 已适配。选用它之前，应冻结分支/版本，做一页最小原型：房间视图、复合动作预览、部分失败反馈，测实际内存、响应与异常恢复。框架存在不等于产品已经完成升级。ESP-Brookesia 官方仓库
AI 服务与设备控制之间要留一道确定性边界
模型可以把“准备睡觉”解释为候选动作，也可以解释这些动作的后果；设备控制系统应决定哪些对象可用、参数是否越界、当前状态是否允许执行。不要给模型一个接受任意设备 ID、任意服务名的万能工具，否则屏上预览再漂亮，也可能只是对已扩大权限的操作做事后展示。
Home Assistant 的脚本工具机制说明：被暴露给 LLM 的脚本会变为可调用工具，脚本描述和参数会影响模型是否正确使用。Ollama 集成同时把设备控制标为实验性，并说明它不直接集成 sentence triggers。这些资料支持“用受限脚本承接动作、在实际会话里验证工具调用”的设计方向，但不证明一个现成配置就能实现“固定命令优先、失败再转模型”的自动分流；若产品需要这种路由，必须另外设计并测试。脚本工具说明 · Ollama 集成边界
对于存量屏，最小可行的接入合同比“接上模型 API”更具体。屏端发出会话 ID、当前房间、用户选中的目标和取消事件；中枢返回候选动作、所需确认级别与可解释的拒绝原因；控制服务返回每个设备的受理、确认、超时或未知状态。取消请求不等于已经执行的动作被回滚，也须查询最终状态。断线重连后，屏幕不能仅凭本地动画猜测动作是否完成，应按请求 ID 查询。若 API 只有“发送成功”而没有设备回执，界面就只能如实写“请求已发送”，不能写“灯已关闭”。
“主动建议”也应晚于可靠的当前动作。屏幕若建议“今晚更早关灯”，需显示依据是什么、影响哪条规则、允许忽略或关闭建议；不能根据几次对话静默扩大控制范围。初版更有价值的改进，往往是少报一次假成功、少选错一个房间，而不是多生成十条自动化建议。
按三轮验收决定是否继续投资
第一轮只做触控与状态：不接模型，选一个复合场景，验证两个设备分别成功、一个离线、状态延迟和用户取消。若现有平台连目标与回执都显示不清，先修控制接口或 HMI；换模型不会补齐状态事实。
第二轮接“理解但不直接执行”：由模型给出候选目标和参数，屏幕可修改或取消；执行仍走固定动作集合。测试同名设备、错房间、含否定词以及“本次”与“以后”的差别。验收记录应包括模型建议、用户最终确认、控制服务裁决和设备回执，不能只存对话截图。若选择错误率高，先限制表达范围或退回确定性入口，不把确认弹窗当作无限兜底。
第三轮才讨论更自由的场景配置和主动建议。此时需要规则版本、写入授权、审计与恢复；同时故障注入 AI 服务停止、外网断开、中枢离线和设备离线。物理开关、基础触控和已有定时控制是否继续可用，要分别验证依赖链。外网断开不等于本地模型和本地中枢不会故障。
路线决策可据此落地：第一轮在原屏上完成，可暂缓换板，但不代表第二轮的语音、内存和音频负载已通过；第二轮若暴露出内存、音频或显示瓶颈，再用目标板卡的同负载数据决定 MCU 换板；只有第三轮确实需要屏端承载复杂媒体或推理、且团队有 OS 维护能力，才把 Linux 屏放进正式方案。不同产品可以停在不同轮次。好的升级不是所有设备都“AI 化”，而是让用户始终看得见系统准备做什么、实际做成了什么、没做成时还能怎样控制。
