我一直在打造Fallowborn，一个浏览器级的战略游戏，一个家族可以从农奴制到帝国皇位。 生成性AI广泛用于生成和修订代码、撰写和编辑文本以及生产四个预览翻译（法语、德语、意大利语、西班牙语）。源代码是公开的。 一个不寻常的约束是，交付的游戏是纯粹的ES5风格的JavaScript：没有框架、包、构建步骤、服务器或外部艺术资产。它从“file://”运行。世界上约有460个县，确定性随机性，以及一个可序列化的状态对象。我的工作流程不是“一个完美的提示”，而是仓库治理。一个根“AGENTS.md”修复了架构、脚本加载顺序、代码风格、本地化规则、测试边界和发布纪律。每个系统都有一个设计文档。代理检查这些之前更改代码，并将行为更改添加到Playwright回归中； 运行测试并进行视觉、触摸和游戏感觉检查仍由所有者控制（这主要是由于我的硬件约束）。我还保留了艺术代码本地化。地图从地理种子点进行了程序化渲染，纹章是生成的，剩余的视觉语言使用浏览器绘图和系统 emoji。人物肖像绘制在画布上。没有生成性AI图像或声音被交付。游戏部署到itch使用他们的命令行工具，以及通过dockerfile到运行Coolify管理容器的服务器（一个用于游戏，一个用于网站/日志）。这是一个相当轻量级的设置，每次推送到主分支都会自动重建游戏，因此它始终是最新的。玩：https://dli9431.itch.io/fallowborn 最新：https://play.fallowborn.com 源代码：https://github.com/dli9431/fallowborn 代理规则：https://github.com/dli9431/fallowborn/blob/main/AGENTS.md 我迄今为止的主要教训是持久约束和可审查的架构比逐渐复杂的提示更重要。其他人是如何在代码库增长时保持长期代理构建项目的一致性的？