一个被"感觉"支配的领域
Nolan Lawson 十月二十八日发了一篇基准测试，开头先讲了他的不满：前端社区的技术决策大量建立在感觉上——框架 "极快"、工具 "超级充电"、抽象层 "同时改善开发体验和用户体验"，这些话通常没有任何证据支撑。
到了 AI 写代码的时代，他以为这种情况会变，结果没有。前端被重写的理由变成了 "某个框架对 AI 更友好"，"生成的代码更快"，"AI 出错更少"——依然没有数据。于是他决定自己造一把尺子。
实验怎么做的
他设计了一个用 PokéAPI 的小型应用：宝可梦列表、属性、招式，可搜索可筛选。然后让 AI 用十二种框架或元框架各实现一遍，每次都跑同一套依从性测试（防止 AI 投机取巧），再从开发花费、耗时、token 消耗、代码行数，以及 Lighthouse 的性能与无障碍得分几个维度评分。
为了公平，他给每个框架都配上官方提供的 MCP 或技能文件，不限定服务端渲染还是客户端渲染，也不要求性能优先，只交代 "用这个框架的最新版本"。每种框架跑五次取中位数；Angular 有两次生成的站点直接拒绝了非 localhost 访问，只取三次。
数字本身
按 API 报价计，最便宜的是 Hono 配 htmx，2.67 美元；Astro 2.76、Nuxt 2.82、原生加 Vite 2.98、Next.js 3.14；最贵的是 Angular，4.97 美元，SvelteKit 4.28、Gracile 配 Lit 4.65 也在高位。耗时从 Astro 的 8.2 分钟到 Angular 的 17.2 分钟，token 从 3.85M 到 9.76M。
但真正有信息量的是质量那一栏。Lighthouse 的性能分几乎全部落在 97 到 100 之间，无障碍分全是 100，布局偏移基本为 0——也就是说，光看总分，这些框架打成平手。差异藏在细分指标里：传输的 JS 体积从 Astro 的 0 KiB、原生加 Vite 的 7 KiB，一路涨到 Next.js 的 142 KiB；总阻塞时间从 0 毫秒到 Angular 的 103 毫秒；最大内容绘制从 Astro 的 810 毫秒到 Next.js 的 2,090 毫秒。
代码行数更能说明问题：同样的功能，Hono 配 htmx 用了 1,370 行，Angular 用了 2,009 行——前者只用七成代码做到同一件事，还更快。在 AI 时代这不只是整洁问题，代码越多，后续每次修改要读的上下文越多，维护成本直接折算成 token 和钱。
两个容易忽略的发现
第一，原生方案并不占优。被要求 "用原生 JavaScript 或 TypeScript 加 Vite、不用 UI 框架" 时，AI 五次全都自建了单页应用，体积小但性能反而输给几个成熟框架。有一点抽象比完全没有抽象更好用，这个结论和 "框架都是负担" 的直觉相反。
第二，官方给 AI 准备的 MCP 和技能文件，实际被用上的比例很低。Nuxt 的 MCP 五次一次没被调用，Next.js 的技能文件五次只读了一次。作者说得很直白：他怀疑现在这批 MCP 和技能可能弊大于利。基础设施做出来了，模型并不一定会去用。
对做企业站的小团队
如果你的项目是内容型站点——企业官网、活动页、产品目录——这份数据指向很明确：Astro 或 Hono 配 htmx 这类偏服务端渲染的组合，成本低、JS 体积接近零、首屏快，而且 AI 生成时不容易跑偏。如果项目是重交互的后台系统，Lighthouse 的评分本身就不适合当标准，该换成交互延迟这类自己的指标。
更该带走的是方法：把 "我们换框架是因为对 AI 友好" 这句话，改成一次能跑出来的对比。同一个需求，让两个方案各生成一遍，量体积、量首屏、量代码行数。这件事今天只需要一个下午，比一次架构会便宜得多。
评论交流
欢迎留下你的想法