FBox 的诞生 — 一个人用 AI 做出来的游戏平台

FBox 的诞生 --- 一个人用 AI 做出来的游戏平台

这不是一篇技术说明书，而是一个普通开发者和 AI 一起"造东西"的故事。

如果你也想用 AI 做产品，希望这个故事能给你一些参考。

为什么做这个项目

我小时候玩过很多游戏 --- 贪吃蛇、俄罗斯方块、推箱子、数独... 这些游戏简单却耐玩，不氪金不联网，点开就能玩。

后来工作了，发现身边很多人通勤路上、午休时间，想找个不复杂的小游戏放松一下都很难 --- 要么是满屏广告的"砍一刀"，要么是必须联网的重度游戏。

于是我想：能不能做一个"经典游戏聚合平台"？ 几十款小游戏，装一个 App 就能全玩，不联网也能玩，有新游戏还能自动更新。要做成类似那个奇妙工具箱的App，无广告，连办会员充值都不容易找到付费页面的那种，给人第一眼就是很干净清爽，心情愉悦。

这就是 FBox 的起点。

做了什么东西

FBox 分成三块，我自己叫它"三端"：

1. 后端（fbox-backend）--- 管事的"仓库管理员" 代码仓库

一台服务器，负责管理所有游戏。哪个游戏上线了、哪个游戏更新了、哪几个游戏该上热门、App 有没有新版本... 都归它管。还带一个简单的管理后台，我可以在网页上增删改查游戏。

2. 手机 App（fbox）--- 用户看到的"游戏厅" 代码仓库

一个 Android 应用，打开就是四个 Tab：首页、收藏、特色推荐、游戏仓库。点开任意一款游戏直接玩，不用跳转不用登录。模拟器游戏（NES/GBA/SFC）和 H5 小游戏都支持。

3. Web 小游戏（webgame）--- 一堆"独立小作品" 代码仓库

18 款用纯 HTML/CSS/JS 写的小游戏，每款一个独立文件夹，自带一个 manifest.json 说明自己的版本号。可以单独打包、单独上传、单独更新。

怎么一步步做出来的

第一步：先让手机能玩游戏

最开始我什么后端都没做，就一个想法：先让手机能玩上游戏。

所以第一步肯定是技术调研，有AI辅助，在技术选型上容易了很多。最开始我只是想玩某一款NES游戏。所以AI给我规划了开发思路和技术选型并完成了roadmap.md文档的编写。这一步很重要，在编码之前先把开发路线规划好形成文档，AI Agent开发的时候不容易跑偏。

使用的AI Agent工具是zed, 它是款AI编辑器，类似vscode加各种AI插件。选它只是因为我的电脑老，心里感觉这个rust开发的AI编辑器可能对电脑硬件要求低。deepseek充值了，凑一起就开干。

我没有开发安卓应用的经验，更没有开发过游戏，但是AI在都不是事，不懂问就对了，每天只有下班后折腾，几天后本来不想安装安卓Android studio也安装了，Android开发环境也配置好了，再折腾几天用手机连接adb测试App这个方法终于搞定了。然后让zed+deepseek按AI写的开发路线文档roadmap.md开始开发。

稀里糊涂对接了FCEUX 模拟器，为了支持其它平台的游戏，还给我规划了一堆要对接的模拟器，结果开发到虚拟手柄后各种调试虚拟手柄总是有问题。看了下deepseek账单，有点心疼，得赶紧想办法，顺便薅Trea得羊毛，刚好字节发布了Trea work, 安装体验下。同时问AI有没有人开发过类似的软件，别人怎么干的。

结果它给我找了一个开源项目Lemuroid做参考，我下载了app一体验，好吗，有这么成熟的开源项目不告诉我，让我自己开发。另外吐槽下某应用商店和某些手机厂商的内置游戏APP，你们真是不思进取，害我瞎折腾。

但是这块开源app体验下来就是太老外了，UI真不习惯，再加上已经折腾这么多天了也不想放弃自己的初衷，所以继续搞吧，模拟器的方案就照搬Lemuroid，省去了自己找AI开发c代码做JNI适配还总是有问题的麻烦。事实证明，要想出成果，决策方向很重要，要一条路黑下去可能这个项目就胎死腹中开不了源了。

接下来火力全开，Trea work额度用完订阅最便宜的速通，全面转向开源模拟器框架（LibretroDroid），把几个经典的模拟器核心塞进去 --- NES 的、GBA 的、SFC 的。然后写了 7 款纯 Java 的小游戏（贪吃蛇、俄罗斯方块这些），直接用 Canvas 画。

这一步做完，加上我自己收集的老游戏rom，手机上已经能玩十几款游戏了。没有网络，没有后端，但核心体验已经跑通 --- 点开就玩。

刚开始的窘迫和困难都牢骚完了，说的有点多，接下来简略地说一下项目开发的具体情况和一些心得体会吧

💡 经验一：先做最小可用版本

不要一上来就想做完整产品。先让"最核心的一件事"跑通，其他的都是锦上添花。我第一步就只做"手机能玩游戏"，后端、在线更新这些都是后面的事。

第二步：写一批 H5 小游戏

模拟器游戏好玩，但有个问题 --- 需要找 ROM 文件，版权敏感。于是我开始写自己的游戏。

我用纯前端技术写了 18 款逻辑解谜小游戏：推箱子、数独、消消乐、华容道、水管工... 每款游戏一个文件夹，结构很简单：

复制代码

web_snake/
├── index.html      # 游戏页面
├── manifest.json   # 写着 "version": "1.0.0"
└── game.js         # 游戏逻辑

为什么要每款游戏都带个 manifest.json？因为这样后端就能知道"这个游戏现在是什么版本"，如果有更新就能提示用户。

💡 经验二：约定大于配置

早点定下规则（比如"每个游戏都要有 manifest.json"），后面所有流程都能顺着这个规则走。AI 也会记住这个规则，每次开发新游戏都自动遵守。

第三步：搭个后端管起来

游戏越来越多，我需要一个地方统一管理。于是用 Spring Boot 搭了个后端。

后端做的事很朴素：

管理游戏列表（增删改查）
管理游戏包文件（上传到服务器，App 下载）
管理配置（首页放哪几个游戏、热门游戏选哪些）
管理 App 版本（上传新版 APK，客户端自动检测更新）

我还做了一个简单的管理后台网页，用 Thymeleaf 服务端渲染，够用就行，没搞前后端分离。

💡 经验三：够用就好，别过度设计

后端最初就是"能管游戏"，配置管理、版本管理都是后面慢慢加的。如果一开始就想做完所有功能，可能到现在还没上线。

第四步：让手机连上后端

后端有了，手机要能连上。这一步我加了一个关键的机制 --- "离线优先"。

什么意思呢？就是 App 每次请求后端，都默认"可能失败"。失败了不报错，而是悄悄回退到本地数据：

请求热门游戏失败 → 不显示热门模块，其他功能正常
请求游戏仓库列表失败 → 显示本地内置的游戏
检查 App 更新失败 → 静默不提示，下次再试

这样用户在地铁里、电梯里没信号，App 依然能玩。有信号了，数据自动同步。

💡 经验四：离线优先是移动端的命

手机的网络环境比你想象的复杂得多。所有"在线功能"都要有"离线兜底"。这个道理 AI 知道，但"哪些场景必须兜底"需要你来定。

第五步：热门游戏怎么做

后端要支持"热门游戏"展示在首页。我一开始想简单点 --- 后台手动选几个游戏放上去。后来觉得不够智能，应该按下载量自动排序。

最后做了双模式，后台一个开关就能切：

自动模式：按下载量从高到低，自动取前 20 个
手动模式：我手动指定游戏列表

配置用一个 JSON 字段存：{"mode":"auto","count":20} 或 {"mode":"manual"}。不用改数据库表结构，老配置也能兼容。

💡 经验五：用 JSON 字段扩展配置

需求会变，但改数据库表结构很麻烦。把可变配置存成 JSON，灵活又省事。

第六步：让内置游戏也能被更新

App 内置了 7 款原生小游戏，问题来了 --- 如果我发现某个游戏有 bug，修复后怎么让用户拿到新版本？

一开始内置游戏的代码是写死在 App 里的，改一次就要重新发 App。这太笨了。

我加了一个同步机制：App 在线时，后端返回的游戏数据会自动同步到本地。包括内置游戏。这样我修复了某个 H5 游戏的 bug，上传到后端，用户下次打开 App 就自动拿到了新版。

关键细节：同步时只更新"可变字段"（版本号、Logo、下载地址这些），平台信息保留本地值 --- 因为后端可能不返回这个字段，直接用会导致 App 崩溃。

💡 经验六：同步数据要"留一手"

后端返回的字段可能不全，同步时要保留本地的关键字段。这种"防御性编程"AI 能帮你写，但要你告诉它"哪些字段必须保留"。

第七步：App 自动更新

这是花时间最多的一块。我想让 App 能自动检查更新、下载 APK、安装 --- 跟主流应用商店一样。

做这个的过程中踩了一堆坑：

坑 1：检查更新的代码是"死代码"

我把检查更新的逻辑写在一个 SplashActivity（启动页）里，结果这个 Activity 忘了在 Manifest 里注册，代码从来没执行过。后来干脆删掉启动页，把检查逻辑挪到 MainActivity 里。

坑 2：一点开就闪退

更新对话框用的主题和 App 不兼容，AppCompat 要求用特定的主题，我用了系统默认的主题，结果一弹对话框就崩。改用一个继承 AppCompat 的主题就好了。

坑 3：下载 404

APK 下载链接拼错了。后端存的是相对路径 /apps/xxx.apk，但 CDN 的访问路径是 /cdn/apps/xxx.apk，少了 /cdn 前缀。补上就好了。

坑 4：强制更新能被绕过

强制更新模式下，用户点"前往应用市场"，跳出去再切回来，对话框就没了，能继续用旧版 App。修复方法：强制更新时点市场按钮不关闭对话框，而且用户切回 App 时再检查一次。

💡 经验七：每个坑都是一次学习

AI 能帮你快速定位技术问题（比如闪退看日志就知道是主题不兼容），但业务逻辑的漏洞（比如"切到市场再切回来能绕过强制更新"）需要你来发现。AI 不会主动告诉你"这个流程有漏洞"。

第八步：提示频率别太烦人

强制更新做好了，但非强制更新有个问题 --- 每次打开 App 都弹一次"发现新版本"，用户烦死。

我研究了下主流 App 怎么做的，发现大家基本是三招组合：

跳过该版本 --- 用户不想更新这个版本，永久不再提示
稍后提醒 --- 24 小时内不再提示
强制更新不受限 --- 必须更新的时候，该弹还是得弹

我用 SharedPreferences 把这两个标记存下来，逻辑很简单：

用户点"跳过该版本" → 记住 versionCode，这个版本永远不弹
用户点"稍后再说" → 记住时间戳，24 小时内不弹
强制更新或用户手动检查更新 → 绕过所有限制，该弹就弹

💡 经验八：体验问题不是纯技术问题

AI 能帮你写代码，但"什么场景该弹、什么场景不该弹"是产品判断。比如"手动检查更新应该绕过频率限制"这种决策，AI 不会主动想到，需要你提出来。

我和 AI 是怎么配合的

这个项目从头到尾都是我和 AI 一起做的。我负责想"做什么、为什么做"，AI 负责"怎么写代码"。配合下来有几个心得：

1. 把需求说清楚

跟 AI 说话不能太笼统。"加个更新功能"这种话，AI 会给你一个通用方案，可能不符合你的项目。

我会这样说：

"App 启动时静默检查更新，要等探活完成后才发请求，避免离线时被拦截。强制更新时对话框不能关闭，用户切到应用市场再切回来要重新检查。"

业务场景 + 技术约束 + 边界条件，三样都说清，AI 给的方案才靠谱。

2. 一步一步来，每步都能验证

我从来不一次让 AI 写一整个模块。都是"先写最小版本 → 真机测试 → 发现问题 → 修 → 再测 → 通过了再清理代码 + 更新文档"。

这样即使 AI 写错了，也能马上发现，不会错太远。

3. 测试是"验收契约"

AI 写完代码我会让它补单元测试。测试通过了我才放心进入下一步。

有一次 AI 写的测试里，JSON 字段名写错了（应该是 gameId 写成了 id），测试直接红了。这种 bug 人工 review 不一定看得出来，测试一跑就暴露。

4. 把规则写进"项目记忆"

AI 有记忆功能，我把项目的规则都沉淀进去：

游戏包要传到哪个目录
文件要怎么命名
卡片一排几个、背景什么颜色
版本号必须单调递增

这些规则写一次，后面所有改动 AI 都自动遵守，不用每次重复说。

5. 重复流程做成"技能"

App 发布流程（改版本号 → 打包 → 上传 → 触发更新）要反复做，我就把它封装成一个"技能"，以后一句话就能触发，AI 自动执行全套流程。

6. 文档同步更新

每做完一个功能，我立刻让 AI 更新文档。文档不同步是技术债的源头，今天欠一点明天欠一点，最后就没人看得懂了。同时也方便操控AI不偏离主线，让AI按文档设计好的路线继续开发

AI 更新文档成本极低，几分钟搞定，一定要养成习惯。

踩过的坑汇总

遇到的问题	为什么会这样	怎么修的
版本管理页面打不开	请求路径多拼了一层 `/api`	把路径改对
App 打开不提示更新	检查更新的代码写在一个没注册的页面里	把逻辑挪到主页面
弹更新框就闪退	对话框主题不兼容	换个兼容的主题
APK 下载失败	链接少了 `/cdn` 前缀	补上前缀
强制更新能被绕过	跳到市场再切回来对话框就没了	不关对话框 + 切回来再检查
非强制更新每次都弹	没有频率控制	加了"跳过版本"和"24 小时冷却"

每一个坑修完，我都会记进项目记忆里，这样 AI 下次就不会再踩同样的坑了。

重要的话：这只是一个练手项目

FBox 是我用来学习 Android 开发、后端架构、以及 AI 辅助编程的练手项目，不用于任何商业用途。

如果你看了这个项目，也想拿去做商业产品，请务必先做完下面的合规审查：

1. 版权问题

项目里用到的模拟器核心（libretro、FCEUmm、mGBA 这些）都是开源的，但开源协议各不相同，商业化要遵守各自的协议
绝对不要内置任何有版权的商业游戏 ROM --- 超级马里奥、宝可梦这些，自己玩可以，商业化就是侵权
游戏的图标、封面图也要确认版权来源

本项目内置的 7 款原生小游戏和 18 款 H5 小游戏都是我自己写的，没有版权问题。但模拟器核心的开源协议要自己确认。

2. 内容审查

所有游戏内容要符合当地法律法规，涉及未成年人的内容要格外小心。

3. 数据合规

如果要收集用户数据，要遵守《个人信息保护法》，App 要有隐私政策和用户协议。

4. 应用商店上架

各应用商店（华为、小米、OPPO、vivo、应用宝）都有自己的审核要求，模拟器类 App 在部分商店可能会受限。

5. 签名安全

本项目默认用的是 debug 签名，正式发布必须换成专用签名，而且签名文件要保管好，泄露了别人就能冒充你的 App。

免责声明

本项目作者不对任何基于本项目进行的商业化行为承担责任。商业化要自己做好合规审查，自己承担法律责任。

练手可以自由，商业化必须守法。

给后来人的几句话

如果你也想用 AI 做产品，这是我总结的几句话：

AI 是放大器，不是替代品。 它能放大你的效率，但做什么、为什么做，得你自己想。
先做能用的，再做好的。 别追求一步到位，先让最小版本跑起来。
每一步都要能验证。 别让 AI 一次写太多，写一点测一点，错了马上改。
把规则写下来。 项目的约定、规范，写进文档、写进 AI 的记忆，一次说清，终身受用。
测试是最好的验收。 AI 写完代码让它补测试，测试过了才算完。
离线优先。 手机端的网络永远比你想象的差，所有在线功能都要有离线兜底。
文档同步更新。 做完一个功能立刻更新文档，别等技术债堆成山。
合规先行。 练手可以自由，一旦要商业化，版权、数据、上架这些合规问题必须先解决。

希望这个故事对你有帮助。

祝你做出自己想做的产品。

--- FBox 项目作者