游戏里可以破产。存档丢失却是开发者的问题

经济游戏可以严苛。玩家可能做错决定、亏掉钱，并发现自己对商业的理解需要更新。但如果因登录系统变化而丢失进度，这种教育方式就相当值得怀疑了。

Alistera Game 是一款以迪拜为背景的商业策略游戏。项目明确将游戏创意和开发归于 Andrey Merzhalilov。我在这里展示的是技术平台与开发工具工作：独立应用、玩家迁移、数据结构，以及借助 AI 进行受控变更。

这里打开的是 Alistera Game 中一家虚构公司的团队。可以查看成员、工作负荷和可用的游戏操作；此窗口不使用真实玩家的存档。

公司团队

归档界面 · 演示数据

迁移进度之前，先确认是谁

应用使用 React、TypeScript 和 Vite，后端采用 Cloudflare Workers 和 D1。注册通过电子邮件与 magic link 验证。从旧系统迁移时，不能仅凭输入了熟悉的邮箱地址就确认现有玩家的身份。

必须与之前经过验证的身份建立关联，然后才能迁移积累的成果。否则，漂亮的新登录入口可能把别人的存档发出去，也可能让所有人从头开始。

这是同一家公司完成第一个项目后的预设状态。它让你无需重走所有前置步骤，就能看到游戏情节继续发展。

公司第二周状态

归档界面 · 演示数据

对用户来说，这应当平稳无事。对开发者来说，这是有价值状态的迁移，“差不多是同一个人”在这里完全不可接受。

游戏规则也需要来源

项目有正式的游戏设计模型，以及将模型编译成关联视图的工具。索引与图谱帮助理解游戏结构，而不是另建一套独立规则。平衡检查针对特定模型；一张好看的图本身不能证明平衡。

独立服务 Dubai Numbers 按自己的计划生成数据快照。游戏通过服务间连接获取这些快照。这比在回合中让语言模型编造一个看似合理的城市当前数字更好。快照有日期，数据有来源及适用边界。

作者需要一款不会意外接管整个游戏的工具

为修改项目，Alistera Author 正在开发中：一个通过 MCP 与 AI 协作的私有界面。它可以查看源代码并准备变更。每项修改都有基础修订版、预期文件状态和保存的 patch。

随后检查特定版本，准备 staging 并进行验收。收到工具回复本身不等于变更通过检查。这一流程不应把每次顺利的对话自动合并到 production。

这在游戏中尤其有意思：改一行很容易，影响却可能很多回合之后才出现。智能体能提出新机制，围绕它的系统则应该帮助我们弄清最终会得到怎样的游戏。

我在这个案例中的工作是技术平台与可验证变更流程。游戏的作者仍是 Andrey。演示中的团队和第二周状态可用于查看游戏进程；它们本身既不能证明游戏平衡，也不能证明所有作者工具都已准备就绪。

相关故事：工作室与共同工作 · Alistera 运营 CRM。