JavaScript 框架的 AI 成本：一项数据驱动的分析

在智能体编程（agentic coding）时代，Web 开发社区依然倾向于基于“感觉”而非实证证据来做出技术选择。为了挑战这一现状，最近的一项基准测试实验评估了 12 个 JavaScript 框架，任务是让 AI 智能体（Claude 3.5 Opus）构建一个非简单的 Pokémon 应用程序。结果表明，即使开发者不再亲手编写代码，框架的选择也会显著影响开发成本、Token 消耗和最终性能。

基准测试方法

该实验专注于使用 PokéAPI 构建一个功能性的 Pokémon 应用，要求具备搜索和过滤功能。为了确保公平比较，研究测量了以下指标：

• 成本： 每次构建的总 API 支出。
• 效率： 所需时间和消耗的总 Token 数。
• 质量： Lighthouse 性能、可访问性和 JavaScript 包大小。
• 可维护性： 总代码行数 (LOC)。

智能体被要求使用各框架的最新版本，并在可用时提供对官方 MCP (Model Context Protocol) 服务器或智能体技能的访问权限。实验对每个框架进行了 3–5 次迭代，以考虑大语言模型 (LLM) 的随机性。

主要发现：成本与效率

倾向于服务端渲染或更简单抽象的框架对 AI 智能体而言效率更高。Hono+htmx 和 Astro 成为最具成本效益和速度最快的选择，而 Angular 和 SvelteKit 等较重的框架则产生了更高的成本和更长的构建时间。

框架	中位数成本 ($)	中位数时间 (min)	Token (M)
Hono+htmx	2.67	8.6	4.26
Astro	2.76	8.2	4.13
Next.js	3.14	10.9	4.99
SvelteKit	4.28	10.8	8.53
Angular	4.97	17.2	9.76

性能与可维护性

虽然所有框架在可访问性和性能的 Lighthouse 得分上基本都已饱和，但在 JavaScript 包大小和总阻塞时间 (TBT) 上表现出了明显的差异。与重度依赖 SPA 的框架相比，基于 MPA 的框架（如 Astro 和 Hono+htmx）始终能提供更小的包体积和更低的 TBT。

在可维护性方面（以非空代码行数衡量），Hono+htmx 大约需要 1,370 行代码，而 Angular 则需要超过 2,000 行。这表明在智能体工作流中，框架的冗长程度与未来维护和更新的 Token 成本直接相关。

社区见解与批评

围绕这些结果的讨论凸显了开发者如何看待“开发者体验”(DX) 与“智能体体验”(AX) 之间观念的转变。

• 追求简洁的理由： 许多评论者指出，像 Hono 和 HTMX 这样的框架天生就更容易让智能体驾驭，因为它们的抽象更接近标准的 Web 原语。
• 训练数据的作用： 一些观察者指出，较新的框架（如 SvelteKit 3）表现较差可能是因为缺乏训练数据，迫使智能体反复阅读迁移指南，从而增加了成本。
• 研究的局限性： 批评者认为，Pokémon 应用过于简单，无法代表复杂的企业级应用。正如一位评论者所言：“使用框架的意义在于以牺牲可定制性为代价来降低认知负荷……一旦你需要更改框架中的某些内容，这种心理模型就会崩溃。”

“在智能体时代，当开发者不再亲手敲代码，从而不再受限于 DX 时，我依然看到‘感觉’在主导一切……如果你已经基本实现了自动化，那么你对那些曾经像动物一样逐行敲代码时所做的选择，到底还有什么执念呢？” — @Nolan Lawson

最终，这项基准测试表明，AI 智能体对它们所使用工具的架构复杂性非常敏感。随着智能体开发成为标准，行业可能会转向那些优先考虑低 Token 开销和清晰、可预测模式的框架，而不是传统的以 DX 为中心的抽象。