JavaScript框架的AI开发成本：一项基准测试的发现与启示

近日，开发者 Nolan Lawson 发布了一项有趣的基准测试，试图回答一个在 AI 辅助编程时代愈发重要的问题：不同 JavaScript 框架或元框架，在让 AI 代理构建应用时，成本与产出质量究竟有何差异。这项测试并非官方标准，而是一次带有探索性质的实验，但其方法与结果仍值得开发者与运维人员关注。

背景：从“感觉”到“证据”

Lawson 在文章开篇指出，Web 开发社区长期存在一种“基于感觉”的决策文化：框架被形容为“极快”，工具被说成能“超级加速”开发，抽象层被宣称同时利好开发者体验与用户体验，但这些说法往往缺乏证据。他认为，进入代理式开发时代后，开发者不再逐行手写代码，对开发者体验的约束减弱，可“感觉驱动”的现象依然存在——例如前端因为某框架“对代理更友好”而被重写，却很少有人追问基准数据在哪里。

正是这种疑问促使他设计了这项基准测试。测试的核心结构是：用 PokéAPI 设计一个规模不大但非平凡的应用，指示 AI 代理使用特定框架构建，然后通过一致性测试套件验证功能，并统计开发时间、令牌消耗、代码行数以及灯塔性能与可访问性得分。

需要明确的是，来源将这项实验定位为“不完美的实验”。它只覆盖一种应用类型——内容为主、交互较少，更接近维基百科而非复杂交互应用。代理使用各框架官方的 MCP 或技能文件，但并未被过度指定架构（如 SSR 与 CSR 的选择），也未被告知会在灯塔上测试性能与可访问性。每个代理在沙箱中运行，且被给予一致性测试套件以防止“作弊”。

核心变化：AI 代理时代的框架成本可被测量

这项测试最直接的贡献，是把“框架对 AI 开发成本的影响”从模糊讨论变成了可观察的数据。来源报告了多个维度的结果，以下为其中关键事实。

成本与时间

按每次运行的中位数成本（美元）排序，来源给出的结果大致为：Hono+htmx 约 2.67 美元、Astro 约 2.76 美元、Nuxt 约 2.82 美元、Vanilla 约 2.98 美元、Next.js 约 3.14 美元、Qwik 约 3.27 美元、TanStack Start 约 3.54 美元、SolidStart 约 3.79 美元、React Router 约 3.81 美元、SvelteKit 约 4.28 美元、Gracile+Lit 约 4.65 美元、Angular 约 4.97 美元。来源同时提醒，这些价格直接引自 Claude Code 的 API 报价，并不代表作者实际支出；作者使用的是 Max 套餐。

时间方面，Astro 与 Hono+htmx 的中位耗时最短，分别约 8.2 分钟和 8.6 分钟；Angular 最长，约 17.2 分钟。令牌消耗与成本趋势大体一致，Nuxt、Astro、Hono+htmx 较低，SvelteKit、Gracile+Lit、Angular 较高。

来源对部分高成本现象给出解释：SvelteKit 的代理每次运行都阅读 v3 迁移指南，可能因为版本太新未进入模型训练数据；Gracile 的代理不熟悉该框架，会克隆仓库或阅读编译后源码；Angular 的高成本与总代码量较大有关。

质量：灯塔分数接近饱和，但 JavaScript 字节差异明显

在性能、可访问性与累积布局偏移方面，各框架的灯塔分数几乎饱和，差异很小。来源报告大多数框架的性能得分为 99 至 100，可访问性为 100，累积布局偏移为 0；Vanilla 的累积布局偏移为 0.111，性能为 97。

更有区分度的是传输的 JavaScript 字节数：Astro 为 0 KiB，Vanilla 约 7 KiB，Gracile+Lit 约 8 KiB，Hono+htmx 约 18 KiB，SvelteKit 约 36 KiB，SolidStart 约 40 KiB，Qwik 约 40 KiB，Nuxt 约 84 KiB，Angular 约 93 KiB，React Router 约 115 KiB，TanStack Start 约 118 KiB，Next.js 约 142 KiB。

总阻塞时间方面，Astro、Gracile+Lit、Hono+htmx、SvelteKit、Vanilla 的中位数接近 0 毫秒；Angular 最高，约 103 毫秒；Next.js 约 71 毫秒；Nuxt 约 40 毫秒。最大内容绘制则普遍对单页应用不利，Astro 约 810 毫秒，Gracile+Lit 约 956 毫秒，Hono+htmx 约 978 毫秒，而 Next.js 约 2090 毫秒，TanStack Start 约 2028 毫秒。来源也指出该指标本身波动较大。

可维护性：代码行数差异显著

来源用非空源代码行数作为可维护性的简单代理指标。Hono+htmx 约 1370 行，Nuxt 约 1415 行，Astro 约 1461 行，Vanilla 约 1492 行，Next.js 约 1539 行，React Router 约 1564 行，SvelteKit 约 1611 行，SolidStart 约 1630 行，TanStack Start 约 1697 行，Gracile+Lit 约 1717 行，Qwik 约 1744 行，Angular 约 2009 行。来源特别提到，Hono+htmx 用约 70% 的代码完成了与 Angular 大致相同的功能，且速度更快。

实验的随机性与局限

来源反复强调结果的随机性：大语言模型是随机词生成器，有时会因低概率“掷骰子”而跑偏、浪费令牌；灯塔本身也可能给出不一致的结果，例如最大内容绘制元素在不同运行间变化。代理是否使用 MCP 或技能文件也不稳定，例如 TanStack Start 的代理仅在 2/5 次运行中发现技能文件，Nuxt 的 MCP 从未被使用，Next.js 的代理仅在 1/5 次运行中读取技能文件。Angular 有两次运行未能构建出可测量应用，因此部分指标取 3 次迭代。

此外，测试环境为特定笔记本、4 倍 CPU 节流和“慢速 4G”网络节流，仅运行移动端灯塔测试。这些条件意味着结果不宜直接外推到生产环境或大型复杂应用。

影响分析：框架选择在 AI 时代仍是经济决策

从编辑视角看，这项测试的价值不在于给出“哪个框架最好”的结论，而在于揭示一个容易被忽视的事实：当代码由 AI 代理生成时，框架选择会转化为可计量的经济成本与维护成本。

首先，开发成本与框架的“代理友好度”相关。来源数据显示，代理对框架的熟悉程度、官方工具的使用情况、迁移指南的可获取性，都会影响令牌消耗与运行时间。这意味着，若团队计划在 AI 辅助下重写或新建项目，应把“代理能否高效使用该框架”纳入评估，而不仅是开发者偏好。

其次，代码行数会反向影响长期 AI 成本。来源指出，代码规模最终影响令牌数量，包括未来的编辑操作，因此也影响代码库随时间的实际维护成本。这一观点对运维与平台团队有直接参考意义：在代理式开发中，简洁的代码库不仅关乎可读性，也关乎持续的经济投入。

第三，性能差异仍然存在，但需结合场景解读。单页应用在最大内容绘制等指标上处于劣势，内容型站点使用多页应用或静态框架可能获得更好的初始加载表现；但灯塔分数整体接近饱和，说明在小型应用中，框架间的性能差距可能被其他因素掩盖。

第四，实验的随机性提醒我们，不应把单次 AI 生成结果当作框架能力的定论。代理可能不使用官方工具，可能选择非预期架构，甚至可能构建出不符合部署要求的产物。这些不确定性需要通过工程流程来管理，而非归咎于框架本身。

行动建议：面向开发者与运维人员

基于来源事实与上述分析，提出以下建议，供团队参考。

1. 建立自己的小型基准。不要直接套用他人结果。选择与自身业务相近的应用类型，固定模型与工具版本，多次运行并取中位数，记录成本、时间、代码行数与关键性能指标。来源的实验本身也说明，单一场景的结果不足以代表所有应用。

2. 把“代理工具使用率”纳入评估。来源显示代理并不总是使用官方 MCP 或技能文件。团队可以在提示词或项目配置中明确要求使用官方工具，并检查代理是否实际采用，以减少因工具未用导致的额外令牌消耗。

3. 关注代码规模与长期维护成本。在 AI 辅助开发中，代码行数会转化为未来的令牌成本。建议在代码评审中关注生成代码的简洁性，避免不必要的抽象与重复，并定期评估框架是否仍与团队维护能力匹配。

4. 对性能保持场景化判断。小型内容型应用可优先考虑多页应用或静态生成方案，以降低 JavaScript 传输量与最大内容绘制时间；交互密集型应用则需综合评估框架的客户端运行时成本。不要仅凭灯塔总分做决策。

5. 为随机性设计流程。代理运行结果存在波动，建议对关键生成任务进行多次运行与一致性测试，并在部署前验证架构是否符合反向代理、非本地主机访问等实际环境要求。来源中 Angular 的失败案例说明，规格遵循问题可能被随机性放大。

6. 不要将本实验视为安全或攻击指导。本文仅讨论开发成本与性能，不涉及任何可操作攻击步骤；相关安全实践应参考专门的安全指南。

资料来源

• The AI cost of JavaScript frameworks | Read the Tea Leaves

本文由自动化系统筛选公开技术信息，并经 AI 辅助整理。