文：花椒军曹的杂货铺

从绿泡泡狂转的《几猫国产3A大作》，讲讲一场AI游戏开发实验，以及程序化生成技术的前世今生。

今日，一款名为《几猫国产3A大作》的游戏开始在中文社交媒体传播。

它的形式有些出人意料：没有安装程序，不需要下载几十GB的资源包，整个游戏只有一个约1.4MB的HTML文件。双击打开，浏览器里就能运行一款第一人称射击游戏。

游戏的背景是一座雨夜港口。集装箱、起重机、仓库、远处的船舶，以及手持枪械的玩家，构成了颇有现代商业射击游戏气质的场景。游戏还有武器射击、敌人、任务目标、弹药计数、导航界面等一整套基本功能。

这不免让人产生疑问：一款看上去颇为复杂的3D游戏，为什么只需要1.4MB？

更有趣的是，这款自称“国产3A大作”的游戏究竟从何而来？

一、从“几猫”到 Saltline：一次源码溯源

首先要说的是，这款游戏并不是中文网络上突然诞生的原创项目。

检查流传的HTML文件，可以看到一些相当明确的线索。

文件的网页标题已经被修改为“几猫3A大作”，游戏里也出现了“几猫兵工厂”“几猫远洋”“四号泊位”等中文标识。

但在JavaScript代码内部，依然保留着以下名称：

• SALTLINE_SKY
• SALTLINE_SHADOW
• SALTLINE_POST
• saltline-sky

这些分别对应游戏天空、阴影、后期处理等渲染模块。

它们指向了另一款游戏：《Saltline》。（点击阅读原文可以直接跳转）

2026年11月10日，软件工程师 Felix Rieseberg 在社交平台X上发布了一款浏览器FPS游戏《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在缺乏人工反馈的情况下，能够通过一次宽泛的任务指令完成多复杂的软件项目。

他的要求大意是：

制作一款第一人称射击游戏，尽可能达到现代AAA游戏的视觉观感，但把规模控制在很小的范围，例如一个短小的关卡。

随后，AI开始规划并制作游戏。

Rieseberg报告的实验数据颇为惊人：

开发时间约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的渲染库代码。

文件中标明的Three.js版本为r180。

那么，Three.js究竟是什么？

简单地说，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大作”这个名字更值得讨论的事情。

资料来源与延伸阅读

1. Felix Rieseberg，2026年11月9日《Saltline》发布帖：https://x.com/felixrieseberg/status/2119925633564463609
2. 《Saltline》原始试玩页面：https://claude.ai/artifact/BGY1SztrAYcJQHSsnHHGmp
3. Felix Rieseberg 个人网站及履历：https://felixrieseberg.com/
4. Three.js 官方技术介绍：https://threejs.org/manual/pages/fundamentals.html
5. Game Developer，2005年《.kkrieger》开发者访谈：https://www.gamedeveloper.com/design/interview-frugal-fragging-with-i-kkrieger-i-
6. Dominic Szablewski，《Q1K3 – Making Of》，2021年：https://phoboslab.org/log/2021/09/q1k3-making-of
7. js13kGames 官方网站：https://js13kgames.com/
8. AIGamer，2026年11月11日《Saltline》项目报道：https://www.aigamer.gg/games/saltline