把三维软件 Blender 打磨了三十多年的界面单独扒出来，变成一个谁都能调的跨平台 GUI 库，还能把明星框架 GPUI 按在地上摩擦，这听起来像桌面开发者的美梦成真。开源项目 BUI（仓库 ppmpreetham/BUI，包名 blenderui 与 @blender-ui/react）刚把这件事摆上了台面，宣称比 GPUI 好两倍。翻开底牌却会发现，它默认跑的根本不是 Blender 原生代码，而是完全用大语言模型生成的 C 语言重写版。
先用最快的速度把这张项目卡片过一遍：
- 核心能力.跨 Windows、Linux、macOS 三端，支持脏区渲染（Damage rendering）与 CPU/GPU 双模式加速，无需挂浏览器或 WebView。
- 多语言与语法兼容.底层是 C，往上直接喂给 Python、Rust、JavaScript/React、C++ 和 Dear ImGui；老 tkinter 程序一行不改直接换皮（完整覆盖 7846 个公开接口），还能写 Qt 语法、45 个原生 Blender 组件、113 个 HTML 标签、Tailwind CSS v4 以及 GPUI 风格代码。
- 最扎眼的争议.PyPI 官方页面直接坦白整个代码库完全由大语言模型（LLMs）构建；同时带着 GPL 开源协议的强传染性，商业闭源项目沾上就得脱层皮。
59.9 帧对 19.9 帧：核显笔记本上的跑分水分
桌面 GUI 赛道向来是跑分修罗场。Zed 编辑器团队开源的 GPUI 一直是 Rust 圈的性能标杆，但社区怨气也不小。早在 2025 年 10 月 27 日的 Hacker News 讨论里，开发者就吐槽过 GPUI 高达约 900 个依赖项和缓慢的编译速度；到了 Canora 项目的 Reddit 讨论中，它约 700 MB 的综合内存占用和合成测试代表性又被拿出来拷问。
BUI 精准踩中了这个痛点，直接甩出一份在 1000×800 窗口里渲染 3000 个动画圆角单元格（anim 模式）的基准测试。测试跑在一台满电插电的 Windows 11 笔记本上，搭载 Ryzen 7 5800U（8 核 16 线程）、AMD Radeon 核显与 60 Hz 屏幕，基于 Direct3D 11 的 Release 构建：
| 框架与配置 | 平均帧率 | 每帧 CPU 耗时 | 内存工作集 | 独立 GPU 内存 | 首帧耗时 |
|---|---|---|---|---|---|
| BUI GPU | 59.9 FPS | 11.6 ms | 约 40 MB | 19–22 MB | 约 5 ms |
| BUI CPU | 57.6 FPS | 22.0 ms | 约 30 MB | - | 约 5 ms |
| gpui-fast (0.1.13) | 31.5 FPS | 31.9 ms | 约 65 MB | 19–24 MB | 约 200 ms |
| GPUI (0.2.2) | 19.9 FPS | 50.5 ms | 约 77 MB | 16–21 MB | 约 220 ms |
光看账面数字，BUI 不仅把帧率拉满到 59.9 FPS，首帧响应更是快出 40 多倍。但扒开测试代码和文档，里面的方法论漏洞根本藏不住。
BUI 的基准文档前面刚写着结果取自 3 次运行的平均值（默认 3 次重复、3 秒预热、10 秒测量），但展示核心数据的四配置表格底下，却赫然标着运行参数是 --reps 1 --warmup 2 --seconds 6。只跑 单次 6 秒 就拿出来当铁证，文档自己都承认 gpui-fast 在不同测试会话之间波动极大。
更经不起推敲的是那个 5 ms 对 220 ms 的首帧差距。翻看它的测量源码 measure.rs 就会发现，这个指标根本不是物理屏幕点亮的时间，也不是输入到光子的真实延迟，仅仅是一个内部测量线程轮询到应用内部帧计数器加一的时间。拿内部计数器跳动去论证界面秒开，多少有点自欺欺人。
借壳 Blender：大模型是怎么偷梁换柱的
比跑分水分更有意思的，是 BUI 到底怎么把 Blender 的界面拆出来的。
Blender 的自定义 UI 始于 1990 年代初，输入框里直接敲 2*pi 就能算数学题，按住数值左右滑鼠标指针会自动隐身，菜单里敲 ad cu 就能模糊搜出 Add Cube。早在 2013 年 12 月 3 日，Blender Artists 论坛就有人提议把这套手感极佳的界面抽出来并取名 BUI，但一直没人干成。原因很简单，Blender 官方开发文档早就泼过冷水，这套 UI 跟 Blender 内部状态、C++ 和 Python 架构咬死在一起，剥离它等于脱一层皮。
BUI 仓库的 CHANGELOG 里，0.2.0 和 0.3.0 版本分别记录在 2026 年 11 月 5 日和 11 月 6 日，这个连时间戳都带着生成式幻觉痕迹的项目，用了一招谁都没想到的解法。
移花接木的最高境界，是不搬那棵老树，直接让大模型照着画一棵。
它根本没有去硬啃那块难拆的骨头。仓库里虽然保留了从 Blender 提取的原始 ui/ 源码目录，但那只是放着当可选参考的摆设。BUI 默认跑起来的运行时，是对选定 Blender UI 机制的 C 语言移植版（C port）。
整个架构被切成了清爽的三层：底层的 gpu/ 负责软件光栅化、Direct3D 11 和 OpenGL 3.3 渲染，中间的 kit/ 与 core/ 用纯 C 语言管理整个控件树、布局和鼠标键盘交互，最上面再用薄薄的一层绑定（比如用 napi-rs 桥接 Node.js 或 Bun）把各种语言接进来。
我更在意的是它在 PyPI（blenderui）主页上那句毫不避讳的声明：整个代码库完全使用大语言模型构建。
《考工记》有言：“审曲面势，以饬五材，以辨民器。”意思是高明的工匠会顺应材料的天然形态来打造器物。以前我们觉得工业软件的底层模块是一块铁板，拆不动；现在大模型直接把 Blender 的 interface_widgets.cc 当成设计图纸，用 C 语言重新默写了一遍，顺手还把 tkinter 的 7846 个接口、React 的信号钩子和 GPUI 的链式语法全给缝了进去。
为什么它替不了 Electron 和 GPUI
既然能零成本让老掉牙的 tkinter 瞬间换上现代暗黑风皮肤，还能用 React 写不带 Chromium 累赘的原生桌面应用，开发者是不是马上就能把它搬进公司项目里？
我不太买账的是它埋在工程落地面前的两颗雷。
第一颗雷是 GPL 开源协议。主流的 GUI 库，不管是 Dear ImGui 还是 GPUI，基本都走 MIT 或 Apache 这类宽松路线，商业公司闭源分发毫无心理负担。而 BUI 因为搬了 Blender 的代码与设计，逃不开强传染性的 GPL 协议。更荒唐的是，大模型在生成仓库时连许可证都没对齐：README 里信誓旦旦写着继承自 Blender 的 GPL-2.0-or-later，但 GitHub 仓库标签和顶层 LICENSE 文件里塞的却是 GPL-3.0。不管按哪一个算，只要你的商业闭源软件静态或动态链接了 BUI，分发时就面临强制开源的法律死局。
- 风险.GPLv2 与 GPLv3 协议在仓库内混杂且具强传染性，加上全量 AI 生成的 C 语言指针与内存管理代码未经独立安全审计，直接用于商业闭源产品或高可靠性生产环境会引发合规与崩溃双重事故。
第二颗雷正是全大模型生成的 C 语言底座。UI 框架是最容易在极端边界条件下出洋相的软件类型——超高分屏缩放、多国语言字体回退、复杂嵌套布局下的内存泄漏，全靠人类工程师日积月累地修补。一个在几天内由大模型批量吐出来、横跨六七种语言绑定的庞大 C 代码库，哪怕跑分再漂亮，在没有经过独立开发者大规模复现审计之前，充其量只能算个惊艳的玩具或内部小工具。
BUI 像一面照妖镜。它既照出了 GPUI 等现代框架在核显设备和高密度节点下略显臃肿的真实窘境，也照出了大模型时代软件工程的新玩法。当三十年的工业级老代码可以被 AI 一夜之间解剖、重写并套上全套现代语法糖，护城河就已经不再是代码量本身，而是谁敢为那几万行无人亲手写下的 C 语言指针签字担责。