一句话看懂：开发者 Nolan Lawson 用 AI 代理分别以多个主流 JavaScript 框架构建同一个宝可梦应用，比较开发耗时、token 消耗、代码量及 Lighthouse 性能与无障碍得分，试图给“哪个框架更适合 AI 写前端”这类流行说法补上可核验数据。
事件核心：发生了什么
Lawson 在 2026 年 10 月底发布的实验中，让 Opus 5.5 以高推理力度分别在 Next.js、Nuxt、SvelteKit、Angular 等框架下构建同一个基于 PokéAPI 的宝可梦查询应用，支持搜索、筛选等基本功能。每个框架使用官方 MCP 或 skills，运行在沙箱中，代理事先不知道会接受 Lighthouse 性能与无障碍测试，但需通过基于无障碍树的一致性测试，以防“作弊”。每个框架取 5 次运行的中位数，Angular 因两次未能产出可用应用只跑了 3 次。作者坦言结果具有随机性，LLM 输出和 Lighthouse 的 LCP 判定都可能波动，因此这不是绝对排名。
为什么重要
前端社区长期以“更快”“对 AI 更友好”等模糊说法推动技术选型，Lawson 引用 Alex Russell 的“前端失去的十年”和 Baldur Bjarnason 的“编程流行文化”批评，指向的正是这种缺乏证据的决策习惯。进入 AI 编码时代，开发者不再手写代码，按说应更少受开发体验偏见影响，但“某框架更适合代理”“生成代码更快、错误更少”的说法仍常无基准支撑。这项实验的价值不在于定论，而在于把开发成本、token 消耗和实际页面表现放到同一张表里比较，让框架讨论从感觉转向数据。
对用户/开发者/创作者的影响
对开发者而言，选择框架时可以开始关注“代理生成质量”这一维度，但需注意实验只覆盖一个内容型站点，交互复杂度接近维基百科而非 Gmail 或 Figma，结论不宜外推到强交互应用。对企业技术选型者，构建成本与 token 消耗可能逐渐成为和性能同等重要的评估项。对普通用户，框架之争最终会体现在页面加载速度和无障碍体验上，不过单次基准无法代表长期维护成本。目前公开信息显示，作者未指定 SSR/CSR 等具体架构，也未要求代理追求极致性能，这会影响结果解释。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是是否有人用更交互密集的应用或更多模型复现类似对比；二是各框架官方 MCP 与 skills 迭代后，代理生成质量是否出现明显变化；三是社区能否形成更统一的 AI 编码基准，而非停留在单次博客实验。
