白泽上手：给小鸿 SE 写一个温控风扇工程

温度超过 30℃，风扇打开；降到 28℃，风扇关闭。屏幕上能看温湿度，也能手动开关风扇。

这次用来介绍白泽的，就是这样一个小需求。逻辑几句话就能说完，落到小鸿 SE 上却要照顾好几个地方：温湿度模块负责采集，风扇模块接收控制指令，主板 WS63 处理星闪通信，P4 负责屏幕和触摸。任何一边的接口没对上，页面画得再好看，风扇也不会转。

白泽（Bayes，原名 XM Studio）把这些工作放进了一个桌面应用。可以在对话里提出需求，让模型生成和修改工程，再由应用处理编译、烧录和串口调试。它的桌面框架是 Tauri 2，前端用 Vue 3，后端用 Rust。下面从源码启动写起，先做一个简单页面，再把温湿度和风扇加进去。

项目放在 AtomGit：https://atomgit.com/xiaomeng-ai/openbayes。

先看工程长什么样

温湿度与风扇项目的工作台，右侧是 P4 屏幕的本地预览。

左边是项目和会话，中间记录这轮任务改了哪些文件，右边可以看设备状态、预览屏幕。点开文件后，还能在窗口里直接看源码。

这张截图有个细节：右上角已经检测到 USB 串口，但下面的主板通信还在等数据，温湿度也显示为 --。这几个状态各有含义。电脑发现串口之后，还得确认连接的目标、运行的固件和模块通信，才能读到传感器数据。后面上板时会用到这个判断。

如果手头暂时没有开发板，可以先做工程生成和代码检查。屏幕预览还需要准备对应的构建资源，烧录和实物联动则留到接好设备之后。

把白泽跑起来

安装和启动

下面以 macOS 源码启动为例。需要 Git、Node.js、Rust stable，以及 Tauri 的系统依赖。Node.js 建议直接装 24 LTS：项目现在使用 Vite 8，依赖要求已经超过 Node.js 18，沿用旧环境容易在安装阶段卡住。

还没装环境的话，可以分别参考 Node.js 官网、Rust 安装说明。macOS 的编译工具用下面的命令安装；已经装过可以跳过：

bash 复制代码

xcode-select --install

Windows 需要 C++ Build Tools 和 WebView2，Linux 需要 WebKitGTK 等依赖，按 Tauri 的环境准备文档选择对应系统即可。

打开终端，先确认这些命令能输出版本号：

bash 复制代码

git --version
node --version
npm --version
rustc --version
cargo --version

获取源码后，进入项目根目录。这里的本地目录叫 xm-rust，请把路径换成自己的：

bash 复制代码

cd /你的源码路径/xm-rust
npm install
npm run dev

第一次启动要编译 Rust 依赖，耗时通常比后续启动长。等终端编译完成，就会出现"Bayes(白泽)"窗口。开发期间留着这个终端，结束时按 Ctrl+C。

如果报错说找不到 ws63flash，先看 vendor/ws63flash 是否完整。后端的 Cargo.toml 引用了这个仓库内的目录，单独复制 src 和 src-tauri 是不够的。

项目另有一个 npm run dev:web，会在 http://127.0.0.1:5183 启动网页预览。它适合调前端样式，文件和硬件操作要回到桌面窗口里做。执行 npm run dev 时会自动启动前端，不必再单独开一次 dev:web。

配好一个模型服务

点左下角"设置"，进入"模型服务"。云端 API、本地服务、本地 CLI 都有入口，先选自己已经有账号和凭据的服务即可。截图里用的是 DeepSeek。

填好 API Key 和模型后，可以在这里检测服务是否可达。

具体操作是：

打开"云端 API"，选择 DeepSeek。
填入自己的 API Key，再选择或填写账号可用的模型。
如果使用自定义地址，展开"连接设置"核对地址。
点服务区域右上角的检测按钮，查看返回结果。

图里的 HTTP 200 是一次成功的连通性探测。模型名用服务商当前提供的就行，截图中那串带日期的名称不用照抄。若返回 401，先检查密钥与账号权限；模型不存在的报错则要回头核对模型名。

白泽会通过系统凭据桥保存 API Key，不需要把它写进工程文件。设置完成后，关掉设置窗口，接下来用一个小任务确认实际调用。

建工程，先显示一句 Hello Bayes

在左侧"项目"旁边点 "+" → "新建小鸿 SE 工程" ，选择保存位置，命名为 se-climate-fan-demo。建好后，左侧会出现项目，当前模式应显示"小鸿 SE"。已有工程可以从"使用现有文件夹"打开。

这里新建的是硬件工程，和白泽自身的 xm-rust 源码分开放就好。

第一次先别急着加入传感器，在输入框里发一个简单需求：

text 复制代码

给当前小鸿 SE 工程做一个 P4 页面，显示"Hello Bayes"，
下面放一行"我的第一个小鸿 SE 工程"。
按当前硬件规范设置屏幕尺寸，并把页面接入实际工程入口。
先只生成文件，不编译、不烧录。完成后告诉我页面入口在哪。

等任务结束，点开生成的文件，看看两行文字和入口函数是否在里面。这样就完成了第一次模型调用和工程生成。如果界面提示工程模式不匹配，先确认打开的是小鸿 SE 工程，再重新发送需求。

有了这一小步，后面即使复杂任务出了问题，也比较容易分辨是模型配置、工程结构，还是硬件环境的问题。

把温湿度和风扇加进来

接下来继续使用刚才的工程。需求可以直接这样写：

text 复制代码

把当前工程改成温湿度监测和风扇联动页面。
使用温湿度模块、智能风扇模块，通过星闪与主板通信。
屏幕显示温度、湿度、模块在线状态和风扇状态。

温度高于 30℃时自动开风扇，降到 28℃及以下时关闭。
再加"自动""强制开""强制关"三个按钮。
没收到有效数据时显示"--"或"未观测"；
控制指令没收到回执时，不要显示为执行成功。

生成相关目标的源码、工程清单、引脚表和接线图，准备屏幕预览。
这次先不烧录。

开启和关闭用了两个温度值，中间留出 2℃ 回差。否则温度在 30℃ 附近来回波动，风扇就可能频繁启停。这种小规则最好在提需求时说清楚，后面检查代码也有依据。

任务生成的内容可以从文件树里查看：

打开的是 se_protocol_encode.c，右侧能看到主板和两个模块各自的目录。

这个案例涉及四个固件目标，目录分工很直观：

text 复制代码

se-climate-fan-demo/
├── bayes.project.json       # 工程与目标声明
├── bayes.scenes.json        # 场景规则
├── targets/
│   ├── main-p4/             # 屏幕和触摸
│   ├── main-ws63/           # 主板星闪通信
│   ├── module-climate/      # 温湿度采集
│   └── module-fan/          # 风扇控制
├── specs/                  # 引脚等规格
├── wiring/                 # 接线关系
└── firmware/

看生成结果时，我会优先找页面入口、两个温度阈值，以及数据失效后的处理。协议实现可以再往下读，但这几处已经能帮助判断生成的工程有没有偏离需求。比如页面文件写出来了，还要确认它参加构建并能从实际入口调用，否则预览和上板可能出现两种结果。

右侧"SE 屏幕模拟器"用于检查布局。等预览资源准备好后，点播放按钮启动，页面有修改时再刷新。这里的 SE 页面使用 480×800 尺寸，由后端通过 LVGL 渲染，可以查看温湿度卡片、按钮位置并尝试触摸交互。

没有设备数据时，页面上的 -- 可以保留。先把未知状态显示清楚，比摆一组看起来正常的假读数更有用。

准备上板时，再处理编译和烧录

到这里，应用源码环境已经够用了。要继续编译固件，还需要对应的硬件构建资源：WS63 和 P4 各有自己的工具链，macOS 这边使用白泽管理的 Lima 构建环境，Windows 使用受管 WSL2。USB 烧录在宿主系统侧进行，P4 还需要匹配的离线构建资产和烧录器。

所以，npm install 完成后如果还提示缺少 builder 或镜像，先按错误信息补资源。P4 的准备说明在项目的 docs/xiaohong-se-p4-builder-assets.md，这部分不能靠重新安装前端依赖解决。

环境齐全后，在当前会话里发：

text 复制代码

编译这个温湿度与风扇工程涉及的目标，分别列出编译结果和固件产物。
这次只编译，先不烧录。

看每个目标的结果，失败的先根据日志修复。全部需要的固件编译成功后，按接线图和板卡说明连接设备，再发：

text 复制代码

使用本次编译成功的固件，按目标引导我烧录并核验固件身份。
需要换模块或切换主板下载路由时，告诉我当前要操作哪块设备。

这一步要留意确认卡片里的目标和端口。小鸿 SE 主板的 P4、WS63 下载路由可能需要物理切换，外接模块也可能要逐块连接。串口名字相同，不代表前后两次连接的目标相同。

烧录结束后，再看真实数据：温湿度是否持续更新，超过上限时风扇有没有转，降到下限后会不会停，手动开关和恢复自动是否正常。还可以断开模块、重启设备，看看页面能不能正确反映离线和重连。

文中的截图记录了工程生成和页面预览，实物联动要按上面这些现象单独验证。尤其是开头那张图，即使串口已发现、固件核验有进度，也还需要继续等主板和模块的运行数据。

源码里更值得看的，是文件怎么改、工具怎么执行

多目标工程有个麻烦：一个请求可能同时修改主板协议、模块驱动和屏幕。如果任务中途失败，只改完其中一部分，留下的工程就很难继续用。看白泽的源码时，我更关心这些修改怎样提交，以及编译结果能否对应到这一轮的新代码。

前端入口可以从 src/features/chat/ChatShell.vue 看起，交互通过 src/tauriBridge.ts 的 window.xmStudioDesktop 进入 Rust，命令注册在 src-tauri/src/lib.rs。编辑器用 CodeMirror 6，文件变化和运行日志由后端事件送回界面。

再往里看，截图底部的"Pi Core"对应项目的 Agent 运行时。agent-runtime/pi-sidecar.mjs 接入 @earendil-works/pi-agent-core，通过 JSONL 消息与 Rust Host 通信。模型请求由白泽已有的服务适配层发出，工具请求也交给白泽执行；sidecar 本身不直接持有真实工程路径和串口句柄。

这样换一个模型服务时，工程文件和硬件操作仍能沿用同一套执行逻辑。排查问题也有落点：服务没返回，去看模型适配；文件修改失败，去看候选改动；固件编译失败，去看构建日志。

一轮改动先放进候选区

小鸿产品模式下的请求使用 PreviewPatch。模型创建、修改、删除文件时，变化先进入候选 ChangeSet。准备提交时，后端检查路径、文件基线、冲突和相关硬件产物，通过后再整轮写回真实工程，建立检查点。

假设这次调整协议，同时改了一个头文件和三个 C 文件。把这些变化放在同一轮里处理，比留下"头文件更新了，实现文件还没改完"的工程状态更容易检查，也方便回滚。

候选文件还没写回磁盘时，编译器直接读工程目录，读到的会是旧代码。实现里因此提供了隔离构建快照，把候选补丁应用到快照后再验证。否则一条"编译通过"的日志，也解释不了这轮修改有没有问题。

想继续读这部分，可以从 src-tauri/src/commands/agent_loop.rs 的 PreviewPatch 和编译处理往下找。

板卡知识放在哪

设置里的技能市场可以查看具体规则，增强技能支持自动使用。

比如 LVGL 对象怎么创建、模块协议怎么对齐、哪些文件应该进入哪个目标，这些信息需要随着任务一起交给模型。白泽把板卡规范、模板和参考资料整理进技能。

图中的"SE 多目标协作"就和这个风扇例子有关：它要求按清单协调 P4、WS63 和外接模块，分别核对协议与验证范围。"AI 屏幕代码检查"则关注 LVGL 参数、回调和对象生命周期。

看技能内容时，也能顺着理解这个项目对硬件工程的要求。当然，规则写进上下文只是开始，接下来还得靠后端校验、编译和设备反馈检查生成结果。

用得久了，还会碰到这两项设置

项目迭代几轮之后，有些话会反复出现：界面统一中文，变量怎么命名，没读到传感器时该显示什么。这类已经确认的约定，可以通过"项目记忆"跨会话保留，并在设置里查看、修改或关闭。

这张截图中记忆已开启，记录还是空的。

它和当前会话的历史不是一回事。当前会话会恢复已有上下文；另起一个会话时，不会把前一个会话的全部内容都搬过来。新任务的具体目标还是要说，长期约定则交给项目记忆保存。

外观设置相对简单，支持简体中文、English、繁体中文，也有多种深浅主题。

语言和主题在同一页切换，截图使用的是"石墨"。

如果只是想快速试一试，做到前面的 Hello Bayes 页面就可以开始熟悉白泽了。接上硬件之后，再逐步加通信和控制逻辑，每次改动小一些，出了问题也好定位。

源码和问题反馈都在这个仓库：https://atomgit.com/xiaomeng-ai/openbayes。提 Issue 时带上系统、板卡型号、操作步骤和去掉密钥的日志，比只贴一句"跑不起来"更方便复现。

更多开源项目和技术交流，可以到玄武社区看看：https://xuanwu.openatom.org。