ReactBench v1（14分钟阅读）

# ReactBench 介绍 · ReactBench 来源：https://www.reactbench.com/blog ReactBench 是一个针对现实 React 开发场景的编码智能体评估基准。如今的模型能通过基准测试，但写出的 React 代码在生产中依然会出问题。测试可以验证行为，却无法捕捉 React 的性能、可访问性和质量问题。 ReactBench 的不同之处如下： - **比“通过测试”更高的标准**：每个解决方案既要通过行为测试，也要通过 [React Doctor](https://react.doctor/)（我们开源的、确定性的 React 代码验证器）的检查。其 400+ 条规则会扫描智能体代码中的错误副作用、不必要的渲染、可访问性问题以及可维护性问题。 - **由 React 专家构建**：我们的团队构建了 [React Doctor](https://github.com/millionco/react-doctor)（★13.8k）、[React Scan](https://github.com/aidenybai/react-scan)（★21.6k）和 [Million.js](https://github.com/aidenybai/million)（★17.7k），被 GitHub、PayPal、Rippling 和 Airbnb 的工程师使用。我们花费数百小时精心挑选任务，以衡量模型能力上的真实差距。 - **真实代码库中的真实工作**：ReactBench 涵盖开源代码仓库以及基于现有项目（而非合成谜题）的真实改动。智能体必须实现功能、保持行为，并通过 React 特定的质量检查。 ## 结果 我们评估了两种互补的能力：实现新功能与改进现有代码。 - **编写 React**：实现一项真实功能或修复，通过隐藏的行为测试，并验证未引入新的 React Doctor 问题。[查看示例](https://www.reactbench.com/data/tasks/write-react-docusaurus-tabs-11733) - **修复 React**：重构现有代码中的 React 故障，同时保持原有行为且不引入新的 React Doctor 问题。[查看示例](https://www.reactbench.com/data/tasks/fix-react-rdh-embeddable-hq-remarkable-ui-multiselectfield) 我们报告的是 5 次试验中 pass@1 的平均值。 ### ReactBench 分数 vs. 成本 / 输出 token **图 2：ReactBench 分数（%）与平均部署成本或输出 token 的关系。** ReactBench 尚未饱和，即使对于领先模型也是如此。GPT-5.6 Sol at XHigh 的总体聚合得分最高，为 43.1%，而 Claude Fable 5 at XHigh 达到 41.2%。在评估的配置中，Fable 平均每次试验成本为 7.97 美元，Sol 为 1.37 美元，相差 5.8 倍。在 XHigh 下，Fable 的成本是 Sol 的 6.3 倍。即使是最好的配置，也只能解决不到一半的基准任务。 我们还评估了各模型配置间的任务区分度。在 51 个任务面板中，有 36 个任务（70.6%）的跨配置标准差高于 0.10。 在质量与成本的平衡方面，GPT-5.6 Terra at Medium 达到了 38.0%，仅比 GPT-5.6 Sol at XHigh 低 5.1 个百分点，而输出 token 减少了 10.8%，每次任务成本降低了 63.2%。它以大约三分之一的价格保留了大部分领先配置的性能，是高负载工作负载下最实用的权衡选择。 GPT-5.6 Sol at XHigh 获得了最高的总体通过率。然而，领先配置之间的差异太小，无法有信心地确定一个明确的赢家。 ### Bug 主导了新引入的 React 问题 | 模型 | Bug（每100次试验） | 性能（每100次试验） | 可访问性（每100次试验） | 可维护性（每100次试验） | 问题总数（每100次试验） | |----------------|-----------------|-----------------|-------------------|-------------------|-------------------| | GPT-5.6 Sol | 15.7 | 1.9 | 0.3 | 0.3 | 18.2 | | Fable 5 | 15 | 2.0 | 0.9 | 0.7 | 18.7 | | Opus 4.8 | 18.5 | 2.5 | 0.9 | 1.6 | 23.6 | | GPT-5.6 Terra | 21.5 | 4.1 | 0.7 | 0.3 | 26.7 | | Sonnet 5 | 18.2 | 2.8 | 3.0 | 3.0 | 27.0 | | GPT-5.6 Luna | 26.4 | 4.7 | 0.4 | 0 | 31.6 | | GLM 5.2 | 25.7 | 9.1 | 0.5 | 0.5 | 35.8 | | Kimi K2.7 Code | 46.7 | 8.9 | 5.2 | 6.7 | 67.4 | **图 3：跨 4,455 次 Write React 试验和 8 个模型系列，每 100 次试验中新引入的分级 React Doctor 问题。** 在 4,455 次 Write React 试验中，评估的模型引入了 1,194 个分级的 React Doctor 问题。Bug（包括安全发现）占 925 个，即 77.5%。最常见的问题涉及列表渲染和 Hook 正确性。 验证器输出分类显示，Write 和 Fix 任务的失败方式不同。在 2,486 次失败的 Write 试验中，有 1,623 次（65.3%）未通过行为测试但通过了 React Doctor。在 3,219 次失败的 Fix 试验中，有 1,956 次（60.8%）通过了行为测试但未通过 React Doctor。 Write 任务主要因要求的行为而失败，而 Fix 任务主要因未解决的 React 问题而失败。 [探索结果](https://www.reactbench.com/data) ## 我们为何构建 ReactBench React 是占主导地位的前端框架，也是编码智能体最流行的目标。大约 70% 基于 JavaScript 框架构建的网站选择 React。 我们亲眼目睹了其中的风险。[React Doctor](https://react.doctor/) 是我们开源的用于扫描 React 问题的工具，被 PayPal、Rippling、Polymarket 以及美国疾病控制与预防中心（CDC）的工程师使用。其采用主要由模型生成代码的增加所驱动，这些代码使细微缺陷更容易进入生产环境。随着模型编写越来越多的 React 代码，小错误可以以巨大的规模传播。在最坏的情况下，这些缺陷会导致生产故障： - **宕机**：错误的 `useEffect` 用法导致生产环境宕机。Cloudflare 将其 2025 年 9 月的仪表盘和 API 宕机归因于一个有错误依赖项的副作用。尽管经过了人工审查和测试，该 Bug 仍然进入了生产环境。 ## 构建 ReactBench 每种任务类型使用不同的构建和评估流程。 ### 编写 React Write React 衡量智能体能否在不引入 React 回归的情况下实现真实工作。每个任务从一个开源仓库中已合并的 Pull Request 开始。智能体会收到基础仓库和一个类似于 issue 的指令。参考补丁和验证器不提供。 - **行为**：验证器在智能体完成后注入隐藏的行为测试并在单独的容器中验证结果。 - **React 健康**：一个固定版本的 React Doctor 扫描将提交与基础提交进行比较。如果检测到新问题，则判定失败。 ### Write React 各模型得分 （此处应为图表/图形，原文未提供具体数值） ### 修复 React Fix React 衡量智能体能否仅从源代码中识别并重构 React 问题。我们选择一个存在已知 React 问题的组件，并指示智能体改进它，但不会指明具体发现。 - **React 健康**：智能体必须移除所有目标问题，同时不引入另一个分级的 React 问题。评分器忽略行偏移。 - **行为**：任务的测试套件必须仍然通过，以确保重构组件没有在功能上使其退化。 我们从智能体镜像中移除 React Doctor 和其他 React 感知的 linter。只有验证器包含固定的扫描器及其干净的基线。 ### Fix React 各模型得分 （此处应为图表/图形，原文未提供具体数值） ### React Doctor 作为验证器 我们构建了 [React Doctor](https://react.doctor/)，一个开源的、确定性的 React 验证器，拥有 400+ 条[规则](https://react.doctor/docs/rules)，以覆盖行为测试断言以外的问题： - **正确性**：捕获条件性 hooks、不稳定的列表键、水合不匹配以及已弃用的 React API。 - **状态与副作用**：标记派生的或重复的状态、useEffect 滥用以及无限重新渲染。 - **性能**：发现不必要的渲染、布局抖动、顺序异步工作以及 bundle 过重的导入。 - **可访问性与安全性**：检测未标记的控件、键盘无法访问的交互、不安全的 HTML 以及暴露给客户端 bundle 的密钥。 ### 示例 诊断信息附加到智能体引入的确切行。 行为测试通过 2 个新问题 **图 4：行为验证和 React Doctor 独立对同一补丁进行评分。** ReactBench 不使用时规则或 LLM-as-a-judge。我们精选用于评分的特定 React Doctor 规则，然后固定扫描器版本和干净的基线。 ### 从真实的 Pull Request 到验证过的任务 ReactBench 将公共仓库中已合并的更改转换为评估任务。 **ReactBench 任务挖掘漏斗** 23,087 个候选 Pull Request 经过四个阶段筛选。被拒绝的候选者在每个阶段分支出去，直到剩下 51 个任务。 - 19.2k 被拒绝：无 React 信号 - 1,680 被拒绝：未通过任务筛选 - 2,043 被拒绝：评审中被拒 - 78 被拒绝：验证失败 **图 5：发布版任务挖掘漏斗。中间计数来自挖掘导出；保留了 51 个任务。带粗细缩放至可读性。** - **挖掘候选者**：我们从开源 React 项目中收集已合并的 Pull Request。 - **筛选候选者**：我们构建了自动筛选器，检查是否对产品代码进行了有意义的更改。然后，评审者评估覆盖更广泛功能工作或重要项目的例外情况，并具有现实的行为测试。 - **编写任务**：每位评审者将已验证的 Pull Request 转换为类似 issue 的逼真指令。如果候选者的测试过于严格，评审者将重建一个自定义测试工具来验证行为。 - **验证行为**：测试必须对固定基础提交失败，并对参考解决方案通过。未更改的仓库必须得分为 0，而参考解决方案必须得分为 1。 - **测试验证器**：一个对抗性智能体试图在不实现要求行为的情况下获得满分。 - **固定版本**：对于每个任务，我们固定源提交、环境、测试套件、参考解决方案和验证器配置。我们还拥有一个版本化的清单，记录每个发布产物的哈希值。 ### 筛选标准 | 筛选条件 | 要求 | |---------|------| | 更改代码量 | 至少 50 行更改 | | 新增行数 | 至少 40 行新增 | | React 信号 | 更改 React 产品代码 | | 时效性 | 在 2026 年 2 月 1 日或之后合并 | | 仓库大小 | 审核时 GitHub 星数少于 20,000 | 92% 的 Write React 任务同时满足时效性和仓库大小标准。这些阈值是为了降低可能的训练数据暴露而实施的。 ### 行为覆盖 每个任务在发布前定义了确定性的行为检查。当仓库现有的 Vitest、Jest 或 Playwright 测试能够完全指定要求的行为时，我们使用它们。 当现有测试存在空白时，我们围绕可观察的行为构建一个独立的测试工具。评审者确认验证器接受超出参考解决方案的有效实现。 ### 隔离评分 智能体和验证器在独立的容器中运行。在评分之前，验证器恢复其自身的 Git 元数据、依赖项、受保护配置、隐藏测试和固定版本的 React Doctor 二进制文件。 持续集成（CI）确认两个容器使用相同的源提交。验证器离线运行，不发出外部网络请求。智能体在其运行期间无法访问隐藏测试或参考解决方案。 ### 区分模型失败与基准失败 零分可能代表模型失败、指令不明确、测试脆弱、验证器错误、基础设施失败或无效运行。 评审者在将结果纳入模型性能结论之前，会检查轨迹和最终补丁。他们将每个审查过的部署分类为：合法解决、真正的模型失败、验证器假阳性、验证器假阴性或无效运行。 ### 针对奖励黑客测试 ReactBench 对抗性智能体探测测试基础设施、奖励文件、Git 历史和 React Doctor 输入。其目标是获得满分而不实现要求的行为。 我们修复或移除任何暴露了作弊方法的任务，然后重新运行所有控制组。这一最终检查测试 ReactBench 是否衡量了要求的工作，而非智能体利用评分器的能力。 ## 局限性 ReactBench 评估的是智能体，而非孤立的模型。Codex CLI、Claude Code、Cursor、Gemini CLI 及其他工具链之间的差异可能影响结果。 每个任务都结合了行为测试与 React Doctor 作为验证器。这些检查能捕捉重要的 React 问题，但无法保证视觉正确性及其他重要属性。 此外，该基准主要涵盖开源 React 项目。结果可能无法推广到专有代码库、不同架构或其他前端框架或设置。 ReactBench 将发布版本化的任务、解决方案、清单和发布记录，以便他人可以检查并重现每个评估过的任务集。 ## 未来工作 我们计划在更多努力级别上比较更多模型。此外，我们不仅计划在商业工具链上运行，还计划在 mini-swe-agent 上运行，以获得更坚实的基线。 我们还计划扩展到视觉设计和其他前端框架，并丰富所代表的仓库和任务类型。 我们在不断改进 ReactBench。在 [GitHub](https://github.com/millionco/reactbench/issues) 上报告基准问题。模型实验室和编码智能体团队可以[联系我们](https://million.dev/)以在我们的保留任务集上评估模型、获取新基准的早期访问权限，或与我们合作。 ## 致谢 ReactBench 之所以存在，是因为工程师和开源维护者贡献了他们的时间和专业知识。我们感谢所有审阅其任务、草稿和评估基础设施的人。 - **外部贡献者**： - Michał Pierzchała (React Native 团队) - Jovi De Croock (Preact 核心团队) - Dev Agrawal (SolidJS 核心团队) - ryoppippi (ccusage 创建者) - Rahim Alwer (Vidstack 创建者，Video.js v10 团队) - Tiger Abrodi (早期 Lovable 团队) - Isabelle Reksopuro - **数据顾问**：Parth Patel (AfterQuery 创始工程师) 特别感谢构建、验证和审阅 ReactBench 任务及评估基础设施的工程师，以及当前任务集中所代表的开源仓库的维护者。