用FastAPI和SQLite打造AI公司经营模拟游戏原型

做一款 AI 公司题材的 tycoon 游戏表面上是在设计一串数字增长实际上是在模拟一家技术公司的资源分配过程。玩家手里有现金、算力、数据、工程师和声誉五类资源需要不断做出选择是先买数据训练模型还是先做市场投放是尽快上线一个效果一般的产品还是攒资源训练一个高质量模型。下面用一个最小可运行的工程把这条路走通后端使用 FastAPI存储使用 SQLite前端只保留一个简易操作页。最终会得到一个可以点击、可以验证、可以继续扩展的 AI 公司经营游戏原型。这个项目对开发者来说真正的价值不是“做一个游戏”而是练习后端状态管理、时间系统、数据持久化和数值平衡。对想接触 AI 工程实践的开发者它也能帮你理解模型训练、资源消耗和产品化之间的成本关系。需要先说明一点这里说的“训练模型”只是游戏里的数值模拟不是真实的大模型训练。这样设计是为了先把经营循环跑起来后面再按需替换成真实技术栈。文章会给出完整的数据表结构、核心引擎代码、API 接口和前端交互片段。代码不一定是最优实现但每个选择都有明确原因尤其是“为什么使用懒更新而不是后台循环”和“为什么把经济系统放到后端而不是前端”。1. 先拆解游戏核心AI 公司经营到底模拟什么1.1 玩家目标和核心循环tycoon 游戏或者说经营模拟游戏最核心的循环是赚钱投入产出再投入。AI 公司题材只是把“生产”环节替换成 AI 行业特有的动作。AI 公司题材的循环可以拆成五步玩家用现金购买数据和算力。雇佣工程师作为生产资源。工程师消耗数据和算力训练出一个模型。玩家将模型发布成产品产品持续产生收入。收入继续用于购买数据、扩充算力、招聘工程师和做市场投放。如果收入长期覆盖不了工资和采购成本公司就会破产。所以玩家的目标不是“训练出最好的模型”而是在现金流约束下让每条决策都更接近可循环的增长。1.2 五类资源与经营动作游戏里的资源不能设计得太复杂否则新手玩家很难理解。建议第一版只保留五类资源现金、算力、数据、工程师、声誉。资源作用初始值主要变化来源现金支付所有采购和工资100000产品收入增加招聘、买数据、市场投放减少算力训练模型时消耗50每 tick 自动恢复一部分训练时消耗数据训练模型时消耗100购买数据集增加训练时减少工程师训练任务必需的生产力0招聘增加工资按 tick 扣除声誉放大产品收入倍率0市场投放增加对应地第一版只需要五个经营动作招聘工程师消耗现金获得一个技能值随机但稳定的工程师。购买数据消耗现金增加数据量。训练模型占用一个空闲工程师消耗算力和数据经过一段时间后生成一个模型。发布产品选择最新训练完成的模型开始产生每 tick 收入。市场投放消耗现金增加声誉。这五个动作已经足够覆盖“资源投入、生产等待、产品变现、再投入”的闭环。后续要加特殊事件、研究树、竞品系统都是在这个闭环之上扩展。1.3 数值设计要回答的三个问题写代码之前要先把数值规则想清楚。否则会出现“每天收入很高但工资更高”“训练成本永远无法收回”“产品上线后收益没有感知”等情况。第一版需要回答三个问题每个 tick 有多长这里定义 1 tick 1 秒方便本地观察。生产环境可以改成 2 秒、5 秒或 10 秒。产品收入是否覆盖维护成本产品收入必须明显高于单个工程师的工资否则公司规模越大越容易破产。训练等待是否值得训练需要消耗数据、算力和时间所以模型质量上限要能带来显著收入提升玩家才愿意等待。这些数值不需要一开始完美但要有调参入口。全部集中在引擎文件顶部不要分散在代码里。2. 技术选型与整体架构用 FastAPI 和 SQLite 跑通最小闭环2.1 为什么选 FastAPI SQLite 原生前端选技术栈时第一版的目标是“能快速验证玩法”而不是“支撑十万玩家”。FastAPI 适合做这类原型因为它的接口定义简单可以直接返回 JSON开发体验接近写普通 Python 函数。SQLite 是零配置数据库文件即数据库适合本地开发和单机测试。前端使用原生 HTML JavaScript不需要 Webpack、Vite 等构建工具打开浏览器就能操作。需要说明的是这个组合适合学习和验证不代表生产环境也要这么选。真实项目通常会引入 PostgreSQL、Redis、异步任务队列和前端框架。如果后续规模扩大FastAPI 的接口层可以保留但存储和实时推送都需要替换。2.2 用懒更新来代替后台循环经营游戏最常见的技术问题是“时间怎么推进”。最简单的做法是启动一个后台线程或异步任务每 tick 更新一次数据库。但这个方案有三个问题服务重启后后台循环可能丢失。多个 worker 同时推进状态容易产生重复扣费或重复发工资。离线时间里状态无法自动推进。这里采用懒更新也叫 tick-on-read。做法是数据库里保存last_tick_at字段每次玩家请求状态时根据当前时间和上次更新时间的差值计算出应该推进多少个 tick然后一次性推进。这样不需要后台任务服务重启也能通过时间差继续推进也更容易控制单个请求的计算量。为了防止玩家离线很久后一次性循环几万次需要设置一个最大 tick 上限例如最多推进 120 个 tick超出部分直接丢弃或按上限结算。2.3 项目目录结构项目文件不多保持扁平即可ai-tycoon/ ├── main.py # FastAPI 入口和接口定义 ├── engine.py # 游戏引擎状态推进、经营动作、初始化 ├── schema.sql # SQLite 建表脚本 ├── requirements.txt # Python 依赖 └── static/ └── index.html #