一个后端工程师把 FastAPI 引擎做成全家游戏，20 个晚上上线，核心是这套架构拆分
Hacker News 上有人发了个 Show HN，叫 TowerPanic，一个家庭聚会多人游戏，核心卖点是它跑在一个很小的 FastAPI 实时引擎上。作者是位后端工程师，说整个产品大约用了 20 个晚上做完，从零写到上线。我不打算复述他的自夸，真正值得看的是这套拆分思路——它说明了「一个人 + AI + 流行技术栈」到底能把事做到什么程度。
游戏本身不复杂：四个人各站一座塔，每轮有些塔开裂、有些倾斜，最后一座塌掉，你要躲开那座。多人、无暴力、无陌生人、无聊天、无广告，面向全年龄段，家长注册后其他人扫码或点链接加入。免费 14 天试用，之后付费通行证。这些都不算稀奇，稀奇的是背后引擎的设计。
作者说他是从 asyncio 和 FastAPI 练手开始的，先做了个可靠聊天应用，把通信抽成独立层，定义了「可靠客户端」接口和「状态机」接口。有了这两个接口，他就能让 AI 去生成其他工具和游戏，效果居然不错，部署到远程服务器后延迟也很好。注意这里的顺序：他不是先有游戏再硬套框架，而是先把通信层抽象稳定，再在上面长东西。这个顺序在我看来是整篇最值得抄的部分。
更关键的是他把服务拆成了两套 FastAPI 应用：游戏服务器只管内存里的房间，不持久化，房间有过期时间；账户服务器管所有持久数据，用数据库。因为这么拆，他能独立升级和扩容前后端，不显著影响用户。这决策看着简单，实际是很多人踩过坑才换来的：实时 session 和持久状态混在一个进程里，扩容时哭都来不及。
还有个容易被忽略的工程细节。因为 Python 有 GIL，单个后端进程只能吃一个核，所以他用 HAProxy 配合一致性哈希来分发房间，把用户路由到正确的后端进程。他说单台服务器可以并行处理几百个活跃房间，延迟没有明显下降。这里想提醒一句，几百个房间本身不代表高并发，但对他这种小规模上线来说够用了。
多地区部署也值得说。他先用人工延迟确认了跨地区会拖 UX，然后决定部署 EU、US、JP 三个区域，目标是把大多数地区的延迟压到 150ms 以下，房间建在最靠近用户的区域。这是很多独立开发者一开始不会考虑的事，他居然做了。法律文件（条款、隐私、退款）也靠 AI 帮忙搞定，前端 UI 是他设计的、代码由 AI 生成。
Hacker News 上有一条评论，说游戏运行良好，但注意到边缘塔更可能倒，可能是统计不显著，也可能是随机算法的问题。这算是个典型的小反馈，说明真实玩家已经在盯着概率分布了。
我比较感兴趣的是作者反复提到「AI 作为同行者」这个定位。他说 AI 帮他讨论负载分配方案、服务器选址、认证和支付在底层怎么工作，然后他做决策；AI 也补了他做不高效的部分，比如前端和法律文档。这话听着有点像口号，但他给了一张具体的时间账：从练手到完整产品上线，20 个晚上。对一个后端工程师来说，这就是当前 AI 写代码时代的真实产出速率。
当然要泼一点冷水。这个项目规模很小，几百个房间、家庭聚会场景，离真正的规模化高并发还有距离；GIL 和一致性哈希的方案在小集群里聪明，换到更大的流量下会有别的坑。付费模式也还早，14 天试用转付费的转化率未知。但作为一篇 Show HN，它展示的是一种可复制的路径：稳定抽象 + 小步迭代 + AI 补位 + 地理分布 + 服务拆分，然后一个人把它跑完。
想试玩的话，他提供了三个地区的演示房间，截止到 2026 年 10 月 19 日 22:00 UTC，每个地区两个房间、每房间最多 10 人，可以直接用链接加入，不需要注册。注意任何拿到链接的人都能进来。