该代码仓库 burrito.space/bez 的语言构成以 Rust（75.5%）为主，辅以 Shell（12.9%）、JavaScript（7.6%）与 Python（2.6%）等，含有 1.3k 次提交、21 个分支及 50 个标签。其 README 介绍，贝兹（Bez）是一个从规范与测试生成 Web 渲染引擎的项目。手工构建引擎需数百工程师和多年时间，贝兹改为从规范生成，以三大浏览器互校和 WPT 作为测试，管线建成后每个额外引擎成本极低。

Bez —— 一个生成式网页引擎

从规范和测试生成网页渲染引擎。

为什么

手工造一个网页引擎要花数百名工程师和多年时间，所以只有少数公司能有自己的引擎，也只有它们决定网页如何运作。Bez 改为生成引擎：依据规范，用三款已发布浏览器互相校验，以 WPT 作为测试。流水线一旦建成，再多一个引擎的成本就很低。

目标

• 完整，或者被摇树裁剪。 默认构建是完整引擎。用于浏览器之外的场景时，构建可以只包含其内容用得到的特性：分析一个网站或应用，它从未触及的特性就不进二进制，而不只是被关掉（docs/content-scoped-engine.md）。
• 在任何设备上都快。 引擎更小，做的事情更少，需要的内存也更少。
• 易于嵌入。 引擎小、API 清晰，适合如今要么打包整个 Chromium、要么干脆没有浏览器的应用和设备。
• 更新最快。 规范或测试一变，受影响的代码就被重新生成、重新验证，而不是手工重写。

工作原理

流程是：从规范文本出发，模型写出大量候选实现；候选在引擎内部运行；再与缓存的 Chromium、Firefox、WebKit 结果对照，检查「框是否相同、位置是否相同」。不一致就退回模型重写，一致就作为普通 Rust 代码提交。

• docs/generation-loop.md —— 一条规则如何从规范文本变成提交的代码。
• docs/geometry-verification.md —— 引擎布局如何与三款浏览器核对。
• docs/generated-functions.md —— 目前生成了哪些布局规则，每一批说明了什么。
• roadmap.md —— 计划、决策和未决问题。

现状

基于 2026-09-25 的 browser-compat-data 8.0.4 计算（17259 个叶子键，docs/feature-map.json 中 74 条规则）。

| 领域 | 已生成 | 手写 | 已链接 | 仅 oracle | 未触及 | | --- | --- | --- | --- | --- | --- | | 总体 | 0.6% | 0.3% | 0.5% | 5.7% | 93.0% | | css | 2.5% | 1.1% | 2.0% | 0.0% | 94.4% | | html | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% | | api | 0.0% | 0.0% | 0.0% | 9.9% | 90.1% | | javascript | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% | | svg | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% | | webassembly | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% | | http | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% | | mathml | 0.0% | 0.0% | 0.0% | 0.0% | 100.0% |

这些状态的含义以及这张表如何保持同步，见 docs/dashboard.md。

DOM、样式、盒树和片段树是在 crates/dom 和 crates/layout 中手写的，已通过浏览器校验（roadmap.md → "Phase 1 — Engine bootstrap"）。九条 CSS 2.1 布局规则位于 crates/layout/src/generated；其中八条由模型写出，并在三浏览器投票下被接纳，块高度保留手写规则，因为没有模型候选胜过它。它们合起来通过全部 227 个 recipe 用例和全部 11 个可用的 WPT 常规流页面。引擎实际调用哪些规则见 roadmap.md → "Which resolver each generated function runs"；什么能证明这个论题见 roadmap.md → "Proof of concept"。

目前的发现

• 三款浏览器大体一致，第三款能指出哪一个是异类。 在 235 个文档、705 次浏览器两两比较中，699 次一致（commit 3ca7323）；全部六处分歧都出自十二层深的百分比嵌套，多数投票每一次都判定 Firefox 是异类。docs/firefox-app-units.md。
• Firefox 的这个差异是真实的网页兼容性 bug。 Gecko 把长度舍入到 1/60 px，而 Blink 和 WebKit 用 1/64 px，这会让某个 flex 项只在 Firefox 里换行，或者让 offsetWidth 差一个像素。复现结果与 Mozilla 诊断出的 Slack、Google Store 和三星上的故障，以及 Mozilla bug 1719314 吻合。experiments/firefox-compat/。
• WPT 投票表在测试套件的绝大部分上一致。 稳定的三引擎多数覆盖 2,282,301 个测试/子测试键中的 2,162,676 个（94.8%）。docs/wpt-votes.md。
• 脚本可观察的行为也一致。 在伪媒体配置下的 trace 探针，18 对引擎中有 15 对一致；三处分歧是真实的平台差异。docs/dump-format.md → "Trace protocol"。
• 一致性套件是可用的 oracle。 三个引擎中有两个一致时，就认为该测试可用：WPT canvas 82.6%（排除 tentative 为 92.7%），带 dEQP 的 Khronos WebGL 99.7%，WPT Web Audio 74.4%（排除 tentative 为 85.6%）；WebGPU CTS 在验证上约 85%，在数值执行上约 50%。docs/conformance-oracles.md、docs/webgpu-cts.md。
• 逻辑编程赢得了一席之地。 用 Datalog 写的 margin collapsing 在 1195 个偏移上与浏览器全部一致，并在全部 227 个用例中抓到了一个几何检查漏掉的注入 bug。docs/logic-layer.md。
• 这个经济学对平台的一个子集成立。 约 55–60% 与引擎相关的兼容条目有可用的自动化 oracle 和可生成的规范文本；大约 8–18% 两样都没有。docs/platform-economics.md、docs/oracle-coverage.md。
• 一个按单个网站内容裁剪的引擎已经设计完成，它的内容分析器也已落地。docs/content-scoped-engine.md。

未决问题

手工构建每条规则的成本是多少、一个特性的生成部分应该覆盖多宽、不依赖 JavaScript 能触达多少 WPT，以及 IDL 生成代码止于何处：roadmap.md → "Open questions"。按领域划分的状态：docs/platform-areas.md。

来源

• browser-specs，所有网页规范集中在一个仓库：https://github.com/w3c/browser-specs
• web-features，把网页平台按特性分组：https://github.com/web-platform-dx/web-features/
• browser-compat-data，网页表面的每一部分：https://github.com/mdn/browser-compat-data
• WPT，网页平台测试：https://web-platform-tests.org/
• wpt-gen，从规范生成的 WPT 测试：https://github.com/GoogleChromeLabs/wpt-gen
• webref，网页规范中的机器可读术语：https://github.com/w3c/webref

社区对利用 AI 从 Web 规范生成浏览器的想法普遍感到认可，但对其现实可行性与当前模型能力存有显著质疑。

认为从规范生成浏览器是值得探索的方向

• 部分人表示，面对庞大的 Web 标准，理论上自动生成浏览器能将人力从繁琐实现中解放出来以完善规范，还有人看好其让网页应用获得原生能力的潜力（较多人）。 > 理论上我们应该能从规范生成浏览器，只是以前太费人力（@Alacart）

质疑当前技术能力与生成代码的可维护性

• 不少人指出，真实 Web 兼容性往往取决于 Chrome 的事实行为而非纯规范，且现有 AI 处理复杂渲染器仍吃力，两年前类似尝试只能产出骨架，同时有人担心生成代码难以被理解（较多人）。 > 虽然想法酷，但真正实现还遥遥无期，而且兼容 Web 实际意味着得照着 Chrome 来做（@esprehn）

期望打破平台壁垒与获得完全控制

• 少数人希望此类技术能进一步实现跨平台运行，或诞生完全可编程、脱离主流引擎垄断的浏览器（少数人）。 > 期待能用上完全可编程控制的浏览器，希望基于 Chromium 的引擎消失（@fouc）

有价值的补充

• 规范中不少行为属于用户代理自定义范畴，但借助三大引擎与 Ladybird 的公开源码，AI 可通过比对不同实现来寻找优化并反馈规范歧义（@esprehn）。