当前小鸿界面要同时容纳状态栏、语音焦点、状态提示、对话文本、音量反馈和配网/升级页面，还要在 WS63 的 SRAM 与 LiteOS-M 任务模型下稳定刷新。源码层已经确认 240×240 尺寸、对象层次、五种视觉模式、16 行局部缓冲、单任务 tick、1～20 ms 等待、512 字节 pending buffer、144/108 字节分页和 3.2 秒停留。在 LVGL 任务初始化时创建状

三个实体按键看起来只是 GPIO 输入，但在当前小鸿 WS63 OpenHarmony 固件中，一次短按要经过电平采样、稳定去抖、时长分类、事件回调、主消息队列，再分发到音频、显示或 Agent 任务。本文已经从当前源码确认三键映射、30/60/80/400 ms 时序阈值、500/5000 ms 长按边界、事件数据表、四个消息队列的容量，以及音量、亮度和中键的实际分支。这里有一个容易忽略的设计：

本轮没有重新烧入黑屏包，也没有再次用当前源码构建后完成三键、显示、Wi-Fi 与 Agent 的整机回归。这次故障最容易误判的地方，是 BurnTool 已经完成写入，设备却黑屏。要确认修复进入新包，还应重新构建并保存产物哈希，烧入后读取启动串口，观察早期显示日志，再检查三键。对于 PWR_ON、复位、Flash 片选、LCD 片选和背光等关键脚，应建立保留表，并让编译期或静态脚本拒绝通用扫描覆盖

的过程拆开，这一篇继续处理构建之后最容易混淆的部分：BurnTool 到底证明了什么、Loader 在什么时候参与、怎样做完整内部 Flash 导出，以及出问题后如何回到已知可工作的固件。本文依据小鸿项目自带的 Windows 烧录指南、本地真实固件包和一份已经完成长度、内容分布与 SHA-256 核对的 4 MiB 原始备份整理，不把官方操作说明、历史烧录结果和本轮文件核验混成同一条证据。如果只

遇到失败时按“目标图、产品依赖、工具链 PATH、写权限、业务源码”的顺序定位，通常比从最后一条编译器输出倒猜更稳定。这一步的正确结论是“本机经过兼容适配后构建成功”，不是“仓库原始检出开箱即构建成功”。这个边界看起来严格，却能避免最常见的固件混淆：源码改的是一份、打包来自另一份、烧录选中第三份，最终又拿旧串口日志证明全部通过。这不是把 README 命令再抄一遍，而是记录 2026 年 7 月

本文依据 OpenHarmony WS63 当前板级源码，核对 P13/P12/P11 按键、P14 PWR_ON、ST7789 与 W25Q128 共享 SPI1、CI1302 UART2 921600 8N1、16 MiB 外部 Flash 与 4 MiB 固件备份边界，并明确尚未完成的实机验证。

本文依据 OpenHarmony-6.1.0.31-Release 分支及源码快照，梳理小鸿本体 WS63、xiaohong-se 与 ESP32-P4 工程边界，说明 config.json、BUILD.gn、LiteOS-M 消息队列、固件产物和 BurnTool 的验证边界。

键盘和鼠标应增强现有像素编辑流程，而不是制造第二套状态。本文结合 bitArt，说明快捷键映射、焦点保护、撤销重做、滚轮缩放及桌面与移动布局的输入边界。

键盘和鼠标应增强现有像素编辑流程，而不是制造第二套状态。本文结合 bitArt，说明快捷键映射、焦点保护、撤销重做、滚轮缩放及桌面与移动布局的输入边界。

编辑器设置的难点不在控件数量，而在输入边界和副作用。本文结合 bitArt，说明自动保存、导出倍率、历史上限、背景与洋葱皮等设置如何规范化、刷新并持久化。