现代网页渲染引擎一直被视为基础软件工程的珠峰。数以百计的高级工程师、长达数年的高强度演进，加上数千万行庞杂的 C++ 代码，让浏览器内核的定义权牢牢锁在极少数科技巨头手中。近期亮相的开源实验项目 Bez 试图改写这个规则：它不再靠纯人力逐行手写，而是让 AI 模型阅读 W3C 规范文本，以 Chromium、Firefox 和 WebKit 三大现役浏览器作为交叉比对的裁判，自动生成零运行时依赖的纯 Rust 渲染引擎。
但这绝不是大模型一键生成完整浏览器的科幻故事。截至 2026 年 9 月 25 日的数据测算，Bez 在整体特性矩阵中的实际生成代码占比仅为 0.6%。它的本质是一套极其克制的差分测试与代码固化流水线。这项实验真正让人兴奋的地方，不在于短期内替代 Chromium，而在于它揭示了一种可能：当主流浏览器互为考官时，机器生成的无依赖静态代码能否撕开巨头垄断的一道缝隙。
戳破数字迷思：94.8%的裁决共识与0.6%的真实代码
社区初看 Bez 项目时最容易产生的误解，是把 94.8% 的裁决共识率当成了引擎的实现完成度。在测试套件中，2,162,676 个 Web 平台测试（WPT）键确实能在三大引擎中形成稳定的多数派判决，但这只代表测试预言机（Oracle）的判卷规则已经就绪，并不代表 Bez 自己能跑通这些特性。
依据项目基于 browser-compat-data 8.0.4（共 17,259 个叶子键）的测算，真实进度呈现出严苛的技术断层：
| 领域分类 | 已生成比例 | 手写比例 | 预言机就绪 | 未触达比例 | 当前工程判断 |
|---|---|---|---|---|---|
| 整体特性 | 0.6% | 0.3% | 5.7% | 93.0% | 框架刚起步，骨干依赖手写 |
| CSS 排版 | 2.5% | 1.1% | 0.0% | 94.4% | 已固化 8 条模型规则与 1 条手写规则 |
| HTML 树 | 0.0% | 0.0% | 0.0% | 100.0% | 尚未进入自动化生成流水线 |
| API 接口 | 0.0% | 0.0% | 9.9% | 90.1% | 仅有部分测试裁决环境 |
| JS / Wasm | 0.0% | 0.0% | 0.0% | 100.0% | 完全未触及运行时实现 |
在整个引擎的基础骨架中，DOM 树、样式级联、盒模型和片段树完全是由开发者在核心模块中手写实现的 Rust 代码。而在生成的排版规则中，目前仅落地了 9 条 CSS 2.1 规则：其中 8 条由模型生成并通过三大浏览器几何比对表决，而块级高度规则因为大模型写出的所有候选版本都未超过手写质量，最终依然保留了人工手写实现。这套组合目前通过了 227 个配方案例与 11 个可用 WPT 常规流页面。
不同子系统的预言机建设也极为不均。Khronos WebGL 借助既有套件达到了 99.7% 的裁判一致性，Canvas 为 82.6%（排除暂定测试后为 92.7%），Web Audio 为 74.4%，而前沿的 WebGPU CTS 规范在数值执行测试上的共识度仅有约 50%。换句话说，在半数以上的复杂计算场景下，连三大浏览器自己都无法充当稳定的真理裁判。
裁判机制的双刃剑：捕获了火狐旧账，也固化了共有缺陷
Bez 的生成回路设计相当严密：模型根据规范写出数十个候选算法，放进微型引擎跑排版，随后抓取三大浏览器渲染结果比对盒模型坐标与尺寸。这个过程甚至逆向挑出了真实世界里的跨浏览器兼容病灶。
在针对 235 份测试文档的 705 组两两比对中，有 699 组展现了完全一致的排版结果。剩下的 6 组分歧全部发生在 12 层百分比嵌套排版中，三大浏览器投票机制每一次都将 Firefox 判定为离群者。调查证实这是 Gecko 引擎长久以来的底层历史负担：Gecko 内部使用 1/60 像素作为基准取整单位，而 Blink 与 WebKit 均采用 1/64 像素。这 1 像素的舍入差异，直接导致弹性盒模型在特定比例下提早换行，正是 Slack 与 Google Store 曾经遭遇过的兼容性故障。
差分测试能量出分歧，却无法凭空创造正确性。
这套多数决机制暗藏着严峻的工程隐患。三大主流内核并不是相互独立的数学真理系统，它们共享了大量上世纪遗留下来的历史解析怪癖与事实标准。当三个引擎同时违反 W3C 原意、按照某种约定俗成的潜规则处理畸变代码时，多数票机制就会把这些共有缺陷直接固化成正式代码。自动化流水线能快速消除偏离，却难以阻断这种群体性妥协。
更底层的挑战在于状态交互的组合爆炸。自动生成一条无状态的单行文本折行规则很容易，但在真实的渲染引擎里，DOM 突变、微任务队列、事件循环、字体整形引擎与沙箱安全架构相互交织。一旦跨过基础排版进入高动态渲染，孤立切片测试就很难捕捉跨子系统的状态坍缩。
避开通用神话：按内容裁剪才是现实生路
在当前的独立引擎探索中，所有项目都在承受手工编码的沉重代价。独立项目 Ladybird 仍处于 Pre-alpha 阶段，缺少稳定嵌入接口，其在苹果 M3 芯片上的跑分显示，Speedometer 2 得分约 64，Speedometer 3 约 3.9，StyleBench 约 83，距离日常商用仍有显著距离。而唯一提供公开完整嵌入接口与原生 Rust WebView 的独立引擎 Servo，在 2024 年 10 月的基准测试中，虽然在 4 个测试页面里的 3 个在首次内容绘制（FCP）上超越了 Chromium，但在总渲染用时上依然有 3 个落后。
让 Bez 成为下一个 Chrome 或 Safari 既不现实，也没有找准落脚点。在整个架构构想中，最具实用价值的模块其实是按内容裁剪引擎（Content-scoped engine）。
在桌面客户端和内嵌应用开发中，团队为了显示几个简单的界面，往往不得不把数百兆大小的完整 Chromium 框架塞进安装包。Bez 的思路是反向静态分析：如果一个本地文档查看器、内嵌工具界面或者特定 AI Agent 环境只需要用到基础的盒模型和排版能力，流水线可以直接在编译期把所有从未调用的 Web 规范和接口剔除，最终输出一个几十兆、极低内存占用的定制 Rust 渲染库。
- 结论.对于饱受大型框架内存膨胀之苦的嵌入式应用与边缘容器开发者而言，生成式引擎的价值不是通用上网，而是在特定受限场景下充当低开销的静态渲染靶机。
- 风险.一旦目标页面引入未受控的外部动态 JavaScript 脚本或复杂的弹性网格布局，高度裁剪的定制引擎将瞬间面临由于能力缺失导致的渲染崩溃。
Bez 展现的不是 AI 颠覆一切的捷径，而是一场冷酷而务实的现代逆向工程实验。它用主流厂商沉淀了数十年的庞大测试套件，给模型的输出套上了严格的几何缰绳。摆在它面前的下一道关卡，是证明这套方法在遭遇复杂的 JavaScript 运行时与动态 DOM 树时，依然不会被状态的组合洪流冲垮。