AIWatch.

保留 Web 那套声明式 UI 的作者体验，却把浏览器/WebView 这层重运行时换成自研引擎直接绘制到操作系统窗口。没有浏览器，没有 WebView，二进制里也没有解释器。

桌面应用的经典两难： · 原生方案（Cocoa/Win32/GTK/Qt）：性能与系统集成好，但作者体验笨重、跨平台割裂。 · Web 方案（Electron/Tauri/WebView）：声明式 UI 范式成熟、迭代快、生态大，但代价是一个数十到上百 MB 的浏览器运行时。

Native SDK 做的：表达力不该和性能对立。把 Web 那套"声明式 markup + 数据绑定"的作者模型留下，把底下的运行时换成原生绘制引擎，于是同时拿到"写得像写网页"和"跑得像原生 app"。

技术架构：四件套 + 一个闭环 一个 app 就是一个 loop，由四部分组成（典型的 Elm/The Architecture 架构，但用 Zig 实现）： · Model — 一个普通 Zig struct，承载全部状态。 · Msg — 一个 tagged union，枚举所有可能发生的事件。 · update(model, msg) — 唯一可以修改状态的地方。 · View — .native 声明式 markup 文件（或 Zig view 函数），从 model 派生 UI。

渲染：自研引擎，编译期 markup · dev 模式：.native 文件运行时解析，文件改动约 2 秒热重载，保留 model 状态与 widget identity。 · release 模式：markup 在 comptime 编译进二进制，发布包里没有 parser/解释器。脚手架 counter app 编出来只有几 MB。

两种引擎产出完全相同的 widget tree（结构性 id、类型化 handler 表一致），所以测试、自动化、golden 在 dev/release 两端都成立。

原生绘制管 OS 真窗口；同时 OS 自己管：滚动物理、菜单、对话框、托盘、文本输入、IME、HiDPI。

Widget identity 与 rebuild 安全性 每次 update 后运行时都会从 model 重建整棵 view，重建被设计成廉价且安全： · 结构性 identity：widget 跨重建/重排/热重载保留 id，所以滚动位置、文本光标、焦点这类引擎拥有的状态不会丢。 · keyed 列表：list item 用 key（跨容器迁移用 global-key）保持 identity；无 key 的同类兄弟按位置取 id，前面插入/删除会让后续兄弟重新消歧——引擎状态可能"跳"，keyed 项和 keyed 祖先则稳。 · 源头优先：引擎保留态会持续到 model 显式给新值；这也是 controlled pattern 要把运行时值回写 model 的原因。 · 错误降级不崩溃：update 抛错被捕获并记录在 bounded error ring（自动化快照里能看到 dispatch_errors=），app 继续跑。

最值得注意的：AI in the workflow · 每个 app 内嵌 automation server：任何 agent 可读 accessibility 快照、驱动 widget、断言实时状态、对运行中窗口拍确定性截图。 · accessibility 检查在 native check 里被机器校验。 · CLI 自带 agent skills（native skills list），教 agent 怎么用整套工具。