《几猫国产3A大作》：1.4MB的HTML如何跑起FPS游戏？
文：花椒军曹的杂货铺从绿泡泡狂转的《几猫国产3A大作》，讲讲一场AI游戏开发实验，以及程序化生成技术的前世今生。今日，一款名为《几猫国产3A大作》的游戏开始在中文社交媒体传播。它的形式有些出人意料：没有安装程序，不需要下载几十GB的资源包，整个游戏只有一个约1.4MB的HTML文件。双击打开，浏览器里就能运行一款第..
绿泡泡上被疯狂转发的《几猫国产3A大作》，背后是一场AI做游戏的实验，也牵着程序化生成技术的一段旧事。
今天，一款叫《几猫国产3A大作》的游戏在中文社交平台上流传开来。
它的形态挺特别：没有安装包，也不用下几十GB的资源，整个游戏就是一个约1.4MB的HTML文件。双击打开，浏览器里直接跑起一款第一人称射击游戏。
场景设在一座雨夜港口。集装箱、起重机、仓库、远处的船，加上端着枪的玩家，看上去颇有现代商业射击游戏的样子。武器射击、敌人、任务目标、弹药计数、导航界面这些基本功能，游戏里也都有。
问题也就来了：一款看着挺复杂的3D游戏，凭什么只要1.4MB？
更有意思的是，这个自称“国产3A大作”的东西，到底是从哪儿来的？
一、从“几猫”到 Saltline：源码里的一次溯源
先说清楚，这款游戏并非中文网络里凭空冒出来的原创项目。
把流传的HTML文件翻一遍，能找到不少明确的线索。
网页标题已经改成了“几猫3A大作”，游戏里也出现了“几猫兵工厂”“几猫远洋”“四号泊位”这些中文标识。
可JavaScript代码内部，下面这些名称还留着：
SALTLINE_SKYSALTLINE_SHADOWSALTLINE_POSTsaltline-sky
它们分别对应游戏里的天空、阴影、后期处理等渲染模块。
这些名字指向另一款游戏：《Saltline》。（点阅读原文可以直接跳转）
那款游戏同样发生在港口，同样有集装箱、机器人敌人、武器射击，任务流程也是切断三处通信中继、随后撤离。
不止如此，Saltline用的也是内嵌在网页里的Three.js渲染库，大量美术资产靠程序化方式生成。
源码里残留的名称、游戏场景、机制和技术结构放在一起看，有充分理由判断，中文网络传播的《几猫国产3A大作》与《Saltline》是直接的继承关系，应当属于改名或本地化版本。（AI说话真客气啊，希望我也能像它一样文明）
不过，这款游戏真正值得讲的故事，显然不在“几猫”，而在《Saltline》是怎么诞生的。
二、原作者是谁？一位Anthropic工程师的AI实验
按他的个人网站信息，Rieseberg目前任职于Anthropic，也就是开发Claude系列AI模型的那家公司。
在这之前，他在微软、Slack、Stripe和Notion工作过，还长期参与Electron开源项目的维护。
Electron是一套用网页技术做桌面软件的框架。不少桌面应用背后的技术底子，都和网页运行环境关系密切。
Rieseberg还做过一些挺好玩儿的个人项目，比如在现代桌面系统上运行经典Windows 95或Macintosh系统的软件。
这次《Saltline》的实验，就是把这些经验和新一代AI编程模型接到了一起。
按Rieseberg在11月10日的公开说明，他想测试的是：在缺少人工反馈的情况下，Claude Fable 5.2接到一条宽泛的任务指令，能完成多复杂的软件项目。
Rieseberg提出的任务大致是这样的：做一款第一人称射击游戏，视觉效果尽量向现代AAA作品看齐，但体量要压得很小，比如只做一个短关卡。
接到指令后，AI便着手规划和开发。
他给出的实验数据相当扎眼：开发耗时约8小时，输出约270万个Token，输入约4.45亿个Token，其中很大一部分走了缓存；按API价格折算，花费约550美元。
需要说明的是，这550美元既不是游戏卖多少钱，也不能直接当成实际付给某个平台的开发开销，它只是按模型API的计费方式算出来的估值。
另外，原作者放出的试玩版也不是未经任何改动的原始产物。游戏页面写明，他后来又花了约两小时调整武器模型、音效和部分玩法，最初版本则单独留了一个试玩入口。所以说，“AI用八小时生成了一款FPS原型”这话有出处、站得住；可要讲成“零人工参与就做完了一款商业3A游戏”，那显然不对。
三、1.4MB为什么足够装下一款三维游戏？
这大概是《Saltline》最容易被误读、也最需要讲清楚的一点。
现在的大型游戏动不动就要几十GB，一大原因在于里面塞满了美术资源。一把武器可能带着精细模型、高清贴图、材质数据、骨骼动画和音效；一个场景则可能堆着大量建筑、地形、植被、人物和其他装饰资产。
按常规做法，开发者会先把这些内容做好，再打包进游戏里。
而《Saltline》换了个路子：不去存已经做好的资产，转而存生成这些资产所需的规则。
举个例子，做一个集装箱，传统办法是先在Blender这类三维软件里把模型建好，再做表面材质和贴图。程序化生成则可以用代码来规定：建一个长方体，给它加上规律排列的波纹结构，用颜色和噪声模拟油漆剥落，再在表面加上锈蚀、污渍和编号。
等游戏跑起来，计算机再依照这些规则生成具体的几何形状和表面图像。同样的思路也能用在仓库、道路、机械设备，甚至某些角色部件上。
于是，一条只有几十或几百字节的规则，在运行时可能生成占用大量内存和显存的视觉资源。这正是《Saltline》能把文件体积压得极小的关键。
不过有一点得说清楚：文件小，不等于运行时它也只占1.4MB内存。
模型、纹理、渲染缓冲区，这些东西生成出来以后都要吃内存和显存。说白了，原本躺在硬盘上的大块内容，被搬到了运行时去计算、去构造。
四、Three.js和WebGL究竟是什么？
翻《几猫国产3A大作》的源码，有个细节挺有意思：这个不大的HTML文件里，其实塞进了Three.js的渲染库代码，标明的版本是r180。
那Three.js到底是个什么东西？它是给JavaScript用的一套三维图形库。开发者靠它建几何体、材质、灯光、摄像机、场景，再把这些对象组织到一块儿。
比如程序可以先造一个长方体，摆到场景的某个坐标上，然后把光照和摄像机设好。不过Three.js本身并不等于显卡，三维场景要显示到屏幕上，还得走更底层的图形接口。
在《Saltline》里，这一步主要交给WebGL。WebGL是能在网页环境里用的一套图形API，JavaScript通过浏览器调用GPU的图形处理能力，三维渲染就完成了。
三者的关系可以这么理解：JavaScript管游戏逻辑和数据生成，Three.js管三维场景的组织和管理，WebGL管把渲染任务提交给图形硬件。真实程序里的技术分工当然更复杂，但这已经是最容易看懂的基本结构。
还有个容易被忽略的事实：浏览器、JavaScript运行环境、WebGL实现还有显卡驱动，都不算在HTML文件的大小里。所以《Saltline》并没有把现代三维图形技术的整套基础设施塞进1.4MB。
它借的是玩家电脑本来就有的计算和渲染能力。这也解释了一件事：一个体积小得吓人的程序，照样可能对显卡和处理器提出不低的要求。
五、程序化生成并不是什么新发明
看到《Saltline》，有人也许会想，拿少量程序代码生成一个完整三维游戏，是AI时代才有的新技术。事实并非如此。
早在2004年，德国技术艺术团队.theprodukkt就做过一款第一人称射击游戏，名叫《.kkrieger》，大小只有约96KB。
它不光有三维场景和第一人称射击玩法，敌人、武器、纹理、音效也一应俱全。放在当年，这点体积比一些普通文档还小。
《.kkrieger》靠的同样是程序化生成。开发者借助专门的工具和算法，在游戏启动那一刻现场生成大量视觉内容，而不是事先把模型和贴图存好。
2005年，开发者 Fabian Giesen 接受 Game Developer 采访时专门讲过这套做法的代价：内容放到启动时生成，许多本可提前完成的优化就用不上了，画面质量或硬件性能要求因此受影响。说到底，这不是什么零成本的魔法。
又过了十几年，类似的尝试转到了浏览器上。2021年，程序员 Dominic Szablewski 做出一款叫《Q1K3》的游戏，向经典FPS《Quake》致敬。
体积只有约13KB，里面却装了两个关卡、三种武器、五类敌人，还有动态光照、音乐和多种纹理。
开发者还专门写过技术文章，讲怎么用程序化方式构造纹理，以及怎么把游戏代码压进极小的空间。
其实还有一个叫 js13kGames 的开发比赛，规则就是要求参赛者把网页游戏塞进13KB的压缩包里。所以，《Saltline》并没有发明某种此前不存在的游戏开发技术。
它用到的许多核心理念，二十多年前就已出现，并在极小游戏开发社区里被长期摸索。
六、既然如此，《Saltline》为什么仍然值得关注？
答案在于，这回变的不是程序化生成的基本原理，而是写那些复杂程序化生成规则的人。
过去，不管是《.kkrieger》还是《Q1K3》，靠的都是熟悉图形学、三维数学、代码优化和底层技术的程序员。这些人得亲自设计资产生成算法，安排场景、调试渲染结果，还得在极其严苛的体积限制下把代码一点点精简。
《Saltline》展示的是另一种流程：人类提出目标，AI模型来制定开发计划、编写游戏逻辑、构造三维场景、设计程序化材质与着色器，并对最终结果反复迭代。
Rieseberg随后公开的制作过程，还展示了纹理算法、机械敌人骨骼和运动计算等技术细节，以及用另一轮AI来评价画面结果的工作方式。
这意味着AI干的并不只是某些简单的重复劳动。它实际参与的是游戏开发中原本需要多种专业知识才能完成的工作。
当然，实验能成，也和任务怎么选有关。
《Saltline》把范围卡得很死，只做一个相对短小的射击关卡。数十小时的叙事内容？没有。庞大的开放世界？也没有。大型商业游戏那套联机、长期运营和海量内容制作，它同样不用碰。
再说，一段演示能跑起来，也证明不了商业产品要的代码可维护性、跨设备兼容性、完整测试和长期稳定性。
不过把这些限制都算上，它仍是一个值得留意的技术案例。
原因在于：AI已经能在相对有限的时间里，把多种成熟技术拼成一个有点复杂度的可玩三维游戏。
七、它会改变未来的游戏开发吗？
单看《Saltline》用到的技术，说它是革命性发明，站不住脚。
Three.js不新，WebGL不新，程序化生成更不新。极小体积游戏也存在二十多年了。
可一个复杂的软件项目能不能由AI在较少人工干预下做完，是另一回事。
落到游戏开发上，这种变化可能先出现在原型制作环节。
以前一位游戏策划要验证某个三维玩法，往往得拉上程序员、美术和技术美术一起干。
现在，越来越多原本只有专业开发人员才能完成的原型工作，可以试着交给AI去做。
这不等于游戏美术和程序开发不重要了。
恰恰相反，初步可玩的游戏做起来越容易，玩法设计、艺术判断、内容质量、技术维护和长期迭代的能力，越可能直接决定作品最终能走多远。
回头看中文社交媒体上流传的《几猫国产3A大作》，真正有意思的地方既不在那个带戏谑味儿的名字，也不在1.4MB这个数字。
它背后的《Saltline》，把两条发展了很久的技术路线接在了一起：
一条是从20世纪末到今天一直在演进的程序化内容生成技术。
另一条是近年进步很快的AI软件开发能力。
前者让计算机按简洁规则搭出复杂虚拟世界；后者开始能编写并组织这些规则。
1.4MB不意味着游戏开发成本消失了，但它提醒我们：构造虚拟世界所需的知识，正以不同于以往的方式被生产和使用。
或许，这才是《Saltline》比“国产3A大作”这个名字更值得聊的地方。
资料来源与延伸阅读
Felix Rieseberg，2026年11月9日《Saltline》发布帖：https://x.com/felixrieseberg/status/2119925633564463609 《Saltline》原始试玩页面：https://claude.ai/artifact/BGY1SztrAYcJQHSsnHHGmp Felix Rieseberg 个人网站及履历：https://felixrieseberg.com/ Three.js 官方的技术说明文档收在 threejs.org/manual/pages/fundamentals.html。 2005年，Game Developer 刊出过《.kkrieger》开发者的访谈，链接是 gamedeveloper.com/design/interview-frugal-fragging-with-i-kkrieger-i-。 Dominic Szablewski 在2021年写过一篇《Q1K3 – Making Of》，发布在 phoboslab.org/log/2021/09/q1k3-making-of。 js13kGames 的官网地址为 js13kgames.com。 AIGamer 在2026年11月11日对《Saltline》项目做了报道，原文见 aigamer.gg/games/saltline。
