把一个原本依赖 Three.js 的 3D 网页直接扒掉框架，换成纯原生 JavaScript 加 WebGL 重写，大模型在同一个对话窗口里就能一步到位。2026 年 11 月 9 日，知名开发者 Simon Willison 拿 Claude Chat 里的 Claude Opus 5.5 Medium 模型做了一次去框架实验，把一个 77KB 的裸鳃类主题法贝热彩蛋页面，转手变成了 98KB 的零依赖原生单文件。实验证明 AI 确实能徒手啃下最繁琐的底层图形代码，但把这当成前端框架的丧钟就想简单了——连实验者自己都搞不清两个版本的画面为什么不一样，这种省掉依赖却丢掉控制权的买卖，账还没算完。
一颗 98KB 彩蛋引出的去框架冲动
这场实验的引子在半个月前就埋下了。2026 年 10 月 21 日，Paul Ford 在个人网站 Ftrain 的《The Aboard Newsletter》专栏发了一篇《The Web Is More Than Enough》，重申原生 Web 平台本身的能力已经绰绰有余。紧接着在 10 月 28 日，Willison 自己也写了一篇《The October inflection point for vibe game development》，复盘 Claude Opus 5.5 结合 Three.js 与 WebGL 如何在一次对话里直接生成 Tree Appreciator 这类 3D 小游戏。
当这两股讨论在 Hacker News 撞上时，评论区冒出了一个很大胆的提议。有开发者认为既然大模型已经这么能写，干脆把 Three.js 这层拐杖踢掉，让 AI 针对具体应用直接去优化底层图形代码。
Willison 被说动了，当场拿早上刚用 Three.js 捏出来的彩蛋页面做起了小白鼠。实际交付的结果可以压成三点：
- 体积变化上，原版 Three.js 的 HTML 文件是 77KB，重写后的原生 JS + WebGL 单文件涨到了 98KB。
- 呈现效果上，两个页面跑出来的视觉画面并不一致，Willison 坦言自己也没完全搞懂差异出在哪。
- 维护体感上，他扫了一眼源码，承认 Three.js 版本稍微好懂一点，但补了一句狠话，说自己反正很少看这类 3D 项目的代码，好不好懂无所谓。
就是最后这句无所谓，戳中了当下凭感觉编程最真实的心理状态。过去人类死磕 Three.js，是因为原生 WebGL 本质上是个极其啰嗦的底层状态机，写个旋转立方体都得手动伺候着色器、矩阵数学和缓冲区绑定。现在 AI 一秒钟就能把几百行样板代码吐出来，那套为了照顾人类脑容量而建起来的第三方库，看着确实有点多余了。
剥掉框架外壳换不来免费的性能红利
但我不太买账的是，社区里不少人顺着这个实验就开始欢呼原生无敌、框架已死。把跑通一个玩具当成工程路线的胜利，中间至少漏算了两笔硬账。
第一笔糊涂账在 77KB 对 98KB 这组数字上。单看文件体积，原生版好像还变胖了，但这其实是个统计错觉，因为 77KB 只算了 HTML 本身的业务代码，没把浏览器额外下载的 Three.js 核心库算进去。如果比拼单文件离线分发，98KB 的零依赖页面确实干净利落。
可反过来看，当初 Hacker News 评论者撺掇去框架的核心理由，是指望大模型能绕过中间商，针对具体画面做底层定制优化。整场讨论下来，没有任何人拿出帧率、内存占用或压缩后传输体积的跑分对比。更尴尬的是，连软件移植最起码的视觉等价性都没保住——画面都走样了，谈何精准优化。
零外部依赖绝不等于零系统复杂度，代码只是换了地方藏身。
第二笔账在图形学的底层物理规律里。很多人误以为剥掉一层高层 API 封装，GPU 就能跑得更快。去翻翻 WebGL 的工程实践就知道，真正决定渲染性能生死的，是批次合并、规避主线程阻塞调用，以及严格的 GPU 资源管理。
Three.js 平时干的脏活，是把场景图、光照、材质、纹理和三维数学打包成经过千万人踩坑验证的标准件；哪怕有它兜底，官方文档依然明确要求开发者自己在应用层手动销毁释放几何体、材质和纹理，以防显存泄漏。现在把 Three.js 一脚踢开，相当于让大模型临时手搓一套未经检验的私人迷你引擎。做一颗静态展示的彩蛋当然能混过去，一旦需求加上动态阴影、多光源切换或者频繁的页面销毁重建，这些被塞进单文件里的底层样板代码，分分钟就会变成显存泄漏和状态错乱的重灾区。
当人类不看代码时抽象层还在保护谁
真正让我后背发凉的，其实是把不看代码和抛弃框架这两件事叠在一起看。
计算机软件史走过这么多年，从汇编到 C 语言，从早期浏览器里满天飞的原生 DOM 操作到后来的前端框架，每一次抽象层上移，表面看是在帮程序员省键盘，骨子里是在建立一套可对齐的契约。古人讲工欲善其事，必先利其器，这个器到了大模型时代，功能已经变了。它不再是为了让人类少敲几行字，而是为了限制代码的发散空间，给人机协作留一个双方都能听懂的中间语言。
拿这次的彩蛋实验对照一下就很清楚。虽然早期 C 编译器刚普及那会儿，也有老派程序员嫌编译器生成的机器码不够精简，但今天的情况和当年不完全一样。编译器是严格确定性的，输入同一份源码永远跑出同一套逻辑；而 Claude Opus 5.5 是一套概率生成系统，它把 Three.js 翻译成原生 WebGL 时，顺手就把高光、材质或者法线计算的细节给改歪了。
当它基于 Three.js 写代码时，哪怕你不常看源码，一旦画面颜色不对，你扫一眼材质参数和光源配置就能抓到病根。可一旦跨过这层人类共享的语义抽象，直接让模型输出上千行原生缓冲区绑定和着色器矩阵，遇到两版画面不一致时，强如 Simon Willison 也只能摊手说不完全理解。人类省掉了引入外部库的麻烦，代价是直接交出了对软件行为的确定性控制。
- 风险.在需要长期迭代的生产项目中盲目跟风去框架化，一旦出现跨设备渲染色差、状态机错乱或 GPU 内存泄漏，团队将面临既无社区文档可查、又无法靠人工排查底层矩阵代码的死局。
这事落到具体人身上，分水岭已经很清晰了。对 Three.js 这类开源中间件来说，在一次性营销贺卡、个人创意玩具和单文件演示场景里，它们作为防繁琐脚手架的垄断地位确实正在被大模型啃食；但在任何需要多人接手、持续改需求的正经工程里，成熟框架反倒成了镇住 AI 幻觉的压舱石。至于 Anthropic 这些大模型厂商，能把代码跑通只是上半场，什么时候能让模型在保持像素级视觉等价的前提下，真刀真枪把批次合并和显存销毁做漂亮，才算真正接管了底层图形栈。
回看那颗 98KB 的裸鳃类彩蛋，它确实漂亮地证明了原生 Web 加上顶级大模型能单兵作战到什么地步。只是在动手删掉项目里的依赖库之前，最好先问自己一句，如果明天老板要求把彩蛋上的某道反光调暗两成，你是打算去改一行材质属性，还是准备跟几百行自己根本不看的着色器矩阵赌运气。