前两天在 GitHub 丢了个仓库README 第一行写着A mini RTS game inspired by Red Alert, playable open source. Built with GPT 6.1.朋友看到后第一反应基本都是你真让 AI 写了个红警能玩吗我说能而且不是 GIF 演示那种“能玩”是能选单位、能采矿、能造兵、能派坦克去怼对面基地那种“能玩”。仓库放出去没几天陆陆续续有人 Star有人提 issue甚至有个老哥直接提了 PR 加音效。这篇文章就把整个过程拆开讲讲——从技术选型、系统设计到怎么一步步让大模型把代码吐出来再到开源之后踩到的坑。想用 AI 辅助写小游戏的朋友这篇应该能帮你少走不少弯路。1. 先把话说清楚这个“红警”到底是怎么来的1.1 项目由头和最终成品形态事情得从一次闲聊说起。当时我在群里吹水说现在大模型写代码这么强能不能让它从零搓一个即时战略游戏出来大家起哄说有本事你真做。我平时主要写业务代码对游戏开发属于“玩过但没写过”的水平正好借这个机会试试水。于是我就开始了这个项目用对话式大模型作为主力编码工具目标是在两周内做出一个能在本地跑起来的迷你红警。最终产出的游戏规模不大但五脏俱全地图是 64×64 的格子地图每个格子 32 像素整体窗口 1280×720。玩家能造电厂、兵营、矿场和坦克厂。有采矿车自动采资源有步兵、火箭兵和坦克三个作战单位。敌方 AI 会自己发展经济、造兵、集结然后分波次来打你。有简单的战争迷雾视野外的地方看不见探索过但没视野的地方显示灰色。打赢条件是摧毁敌方基地打输条件是己方基地被拆。说白了这就是一个把红警的“资源—建造—战斗”核心循环压缩到最小可行版本的东西。代码总共大概 5000 多行纯 Python依赖只有一个 Pygame。仓库名字叫ra-mini目前是 MIT 许可证你要是想拿去改、拿去玩完全没限制。1.2 为什么叫 GPT 6.1这个得先解释一下免得有人较真。标题里说的“GPT 6.1”其实是我跟朋友之间的调侃说法意思是“当时手头能用到的最强对话模型”并不是说真有某个官方版本叫 6.1。圈子里朋友之间吹水习惯把“比上一版强一点”的模型叫作x.1叫着叫着就叫顺口了。所以下文提到 GPT 6.1 的时候你就把它理解成“当时那个负责写代码的大模型”就行。真正有意思的不是我用了哪个精确版本而是我和它之间的协作方式我把需求拆碎它负责快速产出可运行的代码我再验收、提问、让它修。整个开发过程里大概有七八成代码是它写的但架构判断和关键取舍全在我这边。1.3 它适合谁你能从里面拿走什么这个项目对三类人可能比较有用第一类是像我一样想用 AI 辅助做点东西的开发者你可以看看怎么把一个大需求拆成一堆小 Prompt让模型持续产出靠谱代码第二类是 RTS 爱好者哪怕不写代码看看迷你红警的模块拆解也挺有意思第三类是刚学 Python 的人这份代码是很好的游戏编程入门样本单位类怎么写、地图数据怎么组织、主循环怎么跑都有比较清晰的示范。我很反感那种“AI 一键生成整个项目”的吹法实际情况根本不是这样。后面你会看到AI 写代码的过程更像是在和一个记忆力超强但偶尔犯傻的同事结对编程你要不停给它反馈、给它兜底最后才能把东西磨出来。2. 技术选型拆解为什么是 Python Pygame2.1 备选方案对比Unity、Web 还是 Pygame动手之前我也纠结了一下技术栈毕竟 RTS 游戏可大可小选错了后面全是坑。我当时列了三个方向测下来各自的优缺点非常明显方案优点缺点适合场景Unity C#引擎成熟UI、物理、动画都有现成方案项目结构重打包麻烦AI 生成的 C# 代码经常得改很多才能跑做商业化游戏、需要跨平台发布的场景Web Canvas/TypeScript部署方便扔到网页就能玩处理游戏循环、输入、性能问题时要额外照顾浏览器行为想分享链接让别人直接玩Python Pygame依赖极简语法直接AI 训练数据里这类代码特别多性能上限低单位数量过千就会卡原型验证、学习练手、快速出结果我最后选了 Python Pygame最重要的理由是这个项目本身是“验证 AI 能不能帮我做游戏”的实验应该先把不确定性降到最低。Pygame 的代码模式非常固定——初始化窗口、写主循环、处理事件、更新逻辑、画图这套东西在互联网上有海量样本大模型对它的熟悉程度远高于对一套复杂引擎的熟悉程度。2.2 游戏主循环和渲染的基本框架Python Pygame 的经典结构其实是所有游戏的地基一个 while 循环每帧做三件事——处理用户输入、更新游戏逻辑、把画面画出来。帧率固定在 60 FPS也就是每秒钟循环 60 次。这个框架看着简单但它对后续所有功能都有约束力单位移动要按帧来算位移攻击冷却要按帧数来计数动画也要靠帧来切。我们的代码里主循环长这样while running: dt clock.tick(60) / 1000.0 handle_events() update(dt) draw(screen)dt是上一帧到这一帧的时间差单位是秒。早期版本我没传这个参数结果不同电脑帧率不一样游戏速度也忽快忽慢。后来统一用dt做时间基准单位速度不再按每帧固定像素走而是按每秒像素数乘上dt这才稳定下来。这个经验虽然基础但如果你没用 Pygame 做过东西十有八九会在这里栽一次。2.3 代码组织方式一个 RTS 游戏最怕的就是把所有逻辑堆在一个文件里。几千行代码放一起AI 后面根本没法接上下文我自己改起来也难受。所以项目从一开始就拆了模块main.py——入口负责初始化、主循环、事件转发。config.py——所有常量集中放包括窗口尺寸、颜色、单位属性表、建造价格。map_grid.py——地图数据结构、碰撞判断、寻路。entities.py——单位类和建筑类以及它们的渲染、移动、攻击逻辑。economy.py——资源、电力、人口的计算。ai_logic.py——敌方 AI 的状态机和决策逻辑。ui.py——侧边栏、建造菜单、选中信息面板。这个拆分方式还有个额外好处每次让 AI 干活时我只需要把相关模块的文件内容贴给它上下文不会爆炸。比如让它改ai_logic.py我只需要给它看这个文件加上兵种配置表就够了不用把渲染代码也塞进去。后来实践证明控制好每次请求的上下文范围是让 AI 输出高质量代码的关键手段之一。3. 核心系统是怎么一步步搭起来的3.1 地图与格子系统一切的地基RTS 的地图本质是一张二维数组。我们的地图是 64×64 个格子每个格子的值代表地形类型0 是平地1 是矿2 是障碍物比如树和岩石。渲染的时候按格子画色块平地画成浅绿矿画成黄色带小点障碍物画成深绿色。地图系统除了画格子还有一个更重要的职责碰撞和寻路。单位要移动的时候不能直接直线走过去得绕过障碍物。64×64 的网格不算大所以我让 AI 实现了一个 BFS 寻路算法。BFS 虽然不如 A* 高级但对这种规模的地图完全够用而且代码极其直观AI 不容易写错。这里有个很妙的简化我没让单位精确占据格子中心而是让每个单位有一个浮点坐标寻路时先把坐标换算到所在格子然后用 BFS 算出经过哪些格子再让单位沿着格子中心路径走。这样视觉上移动很平滑但底层的碰撞和寻路全是离散的省了大量计算。矿点和障碍物则单独维护一个集合刷地图的时候提前生成好。3.2 单位与建筑数据驱动设计单位系统是这个项目里我最坚持的一个设计决策所有兵种和建筑都用数据表描述逻辑代码不直接写死任何数值。举个例子兵种配置是这样一张 Python 字典表UNITS { soldier: {hp: 100, damage: 10, range: 80, speed: 120, cooldown: 0.6, cost: 200, population: 1}, rocketeer: {hp: 80, damage: 25, range: 140, speed: 100, cooldown: 1.0, cost: 400, population: 1}, tank: {hp: 350, damage: 40, range: 120, speed: 80, cooldown: 1.2, cost: 800, population: 2}, }单位类本身只负责读表、移动、开火、扣血不关心具体数值。这样做的好处非常多AI 出 bug 时往往只需要调数值就能修玩家反馈“坦克太弱了”我改一行配置就行后续加新兵种也只是往表里加一项。建筑也类似分成power_plant电厂、barracks兵营、mine矿场、war_factory坦克厂、base基地。每种建筑有占地尺寸、造价、建造时间和功能回调。建筑占地是个矩形区域建造时要检查这块地上的格子是否全部为空否则不能放。这个检查逻辑我专门让 AI 写了一个单元测试因为它是很多 bug 的来源。3.3 战争迷雾与视野系统RTS 游戏如果没有战争迷雾战略深度会大打折扣。我们的实现并不复杂每帧根据所有己方单位的视野半径在visibility数组上画出可见区域。这个数组同样是 64×64每个格子的值是 0从未探索、1探索过但现在看不见、2当前可见。渲染时有个关键优化不直接把整个地图画出来而是只画玩家屏幕可见范围内的格子并且不在视野内的单位一律不画。等视野外单位重新进入视野时才把它画出来。早期版本我把所有单位都画了结果对方基地的动向一目了然完全没有迷雾效果。后来改成渲染前先判断单位是否在可见格子上这才正常。战争迷雾这个功能看着简单但它涉及渲染和逻辑两个层面的配合。AI 最开始实现时只顾着画地图忘了把单位从迷雾里藏起来我试玩时发现了这个 bug跟它描述了一遍“单位不在视野里就不能显示”它很快就修好了。这种问题靠人眼验收非常快比写测试还高效。3.4 敌方 AI状态机让你的对手动起来敌方 AI 是整个项目里最容易被低估的部分。要让人感觉对面“像一个玩家在玩”其实只需要一个非常简单的状态机每个状态做固定几件事gather状态AI 基地持续生产采矿车采矿车自动去矿点采集运回基地换成钱。build状态当钱积累到一定程度AI 交替造兵营和坦克厂并开始出作战单位。attack状态当 AI 的作战单位数量达到阈值比如步兵 10 个或坦克 4 个它会集合这些单位向玩家基地方向发起一波进攻。这个状态机每 0.5 秒跑一次决策逻辑没必要每帧都跑。为了增加挑战性我给 AI 加了一点“作弊系数”它采矿的效率是玩家的 1.5 倍建造时间也比玩家短一点。否则以 AI 的决策水平基本打不过一个会玩的真人。最关键在于攻击路径AI 把单位送到玩家基地门口单位到达后会攻击视野内的玩家单位或建筑。这里我让 AI 给每个单位加了一个简单目标选择规则——优先攻击最近的敌对单位如果没有单位就攻击敌方基地。这套规则写起来很直接但效果已经能骗过大部分人了至少我朋友玩的时候真的产生了紧迫感。3.5 资源与经济循环经济系统是老 RTS 的灵魂没有经济压力玩家就会像玩沙盘一样乱造。我设计的循环非常简单采矿车从矿点挖矿运回矿场矿场把矿转换成资金电厂决定电力上限兵营和坦克厂生产单位需要消耗人口而人口上限由建筑数量决定。具体来说广场上有多个矿点每个矿点储量有限采完就枯竭你需要去更远的矿点。矿车的行为是个典型的“去—采—回—卸”循环状态机跟 AI 一样travel_to_resource去矿点→harvest采 2 秒→travel_to_base回矿场→unload卸货加钱。每个状态持续的时间用计时器控制。这个循环出现的 bug 很有意思矿车卸货时如果矿场正在被攻击导致血量过低它可能不知道该去哪里卸货。修法也简单在寻路函数里加了一个“找不到目标就回基地旁边发呆”的兜底逻辑。这类边界情况是 AI 不太容易自己想到的必须靠试玩才能发现。4. 实操实录我如何用 GPT 6.1 把想法变成代码4.1 第一批 Prompt目标越小产出越靠谱如果一开始我就对模型说“请帮我写一个红警”大概率会得到一堆稀碎且无法运行的代码。我的做法是先把项目拆成十几个可验证的小阶段每阶段只提一个明确目标。比如第一阶段的目标是在 Pygame 窗口里画出 64×64 的格子地图并且支持鼠标拖拽移动视角。我给模型的 Prompt 写得非常具体包括窗口大小、格子像素、地形数组的生成方式以及要求“移动视角用拖拽方式实现”。它一次就写出了可以运行的代码我看一眼没问题就进入下一阶段。前后总共拆成了这些阶段画一个 64×64 的格子地图支持拖拽视角。在格子上生成矿点和障碍物。定义单位类支持选择一个单位并显示属性面板。实现右键移动单位沿 BFS 路径行走。实现选择框框选多个单位。实现建造菜单点击建造建筑。实现电厂、矿场、兵营、坦克厂的功能。实现采矿车自动采集和卸货。实现生产列表和人口限制。实现敌方 AI 的发展、出兵、进攻。实现单位攻击、血条、死亡消失。实现战争迷雾。实现胜负判定和重启游戏。每个阶段基本在半小时到一小时之间完成。阶段越小模型犯错的概率越低我验收的成本也越低。这个节奏到了后半段尤其重要因为代码量上去之后一个大改动往往牵一发动全身。4.2 迭代式对话不是写代码是当监工真实的开发过程不像很多人想象的“问一句就完事”而是几十轮的持续对话。我经常在 AI 给的代码跑不起来时直接把报错信息完整贴给它然后加一句“请说明你做了哪些修改来修复这个问题。”这里有一个很关键的技巧让模型不仅给代码还要解释为什么。比如它修改了某个函数的参数顺序如果不说明原因我合入代码时根本不知道这个改动是否引入了新问题。后来我要求所有关键修改都附带一两句解释代码评审效率立刻提升。迭代过程中最常见的对话模式是这样的我现在点击兵营时没有弹出建造菜单检查一下 UI 层的事件绑定。它问题可能出在ui.py的handle_click方法事件坐标没有从屏幕坐标转换成世界坐标导致点击位置和建筑位置对不上。我修改了转换逻辑。我好的重新运行后菜单出现了但点建造按钮没反应。它那应该是建造按钮的矩形区域计算错误我打印了一下坐标发现按钮尺寸被设置成 0修正后测试通过。这种有来有回的调试过程占了整个开发时间的一半还多。AI 不像搜索引擎那样给你一堆链接它更像一个坐在你旁边的同事你说问题它给方案然后你去验证再回来告诉它结果。4.3 让 AI 代码“听话”的三个技巧经过这次项目我总结了三个让大模型输出质量直线上升的小技巧跟它本身的版本迭代无关更多是沟通层面的经验。第一个技巧是给例子而不是下定义。比如想让 AI 明白“建筑占多个格子”不要说“请实现占地面积逻辑”而是给出具体例子“基地占 4×4 格建造时这些格子必须全部是空地每个格子坐标都要做碰撞检测”。模型的抽象能力强但具体例子能大幅减少歧义。第二个技巧是要求它“写完立刻自测”。每段代码交付前让它自己检查是否存在明显的越界、空指针、逻辑死循环如果发现问题先修好再交给我。有些模型会偷懒只在 Prompt 明确要求时才带着测试跑一遍。我们的map_grid.py里就有它加的一段检查代码用来确保路径不会穿过障碍物。第三个技巧是控制代码块的颗粒度。遇到大功能时明确要求它“先给出这个模块的接口签名、全局变量列表以及各函数之间如何调用不要写实现”。等我把整体设计看过、确认没问题再让它分步填充实现。这相当于没让 AI 跳过设计阶段直接手写复杂系统。事实证明跳过设计直接生成的代码往往在模块边界上会出问题。4.4 哪些坑是 AI 填不了、只能自己动手的虽然大部分代码是 AI 写的但有两类问题它很难独立解决只能靠人工介入。一类是全局性性能问题。比如游戏后期单位一多帧率暴跌AI 给出的优化建议常常是零碎的——减少画布刷新率、优化单位数量上限但它看不到整体瓶颈在哪。我后来自己排查发现瓶颈主要是两个一是渲染时用了太多pygame.draw.circle绘制血条和选中框改成预渲染图片后明显变快二是 BFS 在每帧对每个单位都重新计算改成只有当起点或终点变化时才重算性能立刻改善。这类全局判断AI 没有完整上下文我做起来反而更快。另一类是数值手感问题。游戏好不好玩不在于代码对不对而在于数值调得顺不顺。AI 给出的数值往往很保守——步兵血量 100、坦克伤害 40听起来合理但实际玩起来要么太脆要么太肉。这个必须反复试玩一点一点调步兵要能扛住矿车探路时的零散火力坦克对步兵的压制力要明显矿车采集效率要刚好让经济有节奏感。这些经验完全不在 AI 的训练数据里它给不了太多帮助。所以最后的复盘结论是AI 写了八成代码但真正让它变成“一个能玩的游戏”的恰恰是我自己调的那两成。5. 开源之后仓库维护与社区反馈5.1 许可证和 README 是开源的第一步代码写得再漂亮如果 README 不行别人拿到手也是一脸懵。我的 README 开头放了一句话简介和一张 GIF 动图。动图是跑起来之后用录屏软件录的花了半分钟。别小看这张图很多访客就是靠它判断“这玩意到底能不能玩”。许可证选的是 MIT。理由很简单我希望别人下载之后随便改、随便用不需要顾虑版权问题。RTS 游戏的代码结构本身不复杂开源出去不会损害任何商业价值反而可能吸引别人来帮忙补功能。实际上开源之后真的有人提 PR虽然只是加音效和修了两个操作 bug但那种“陌生人在帮你改代码”的感觉还是很爽的。5.2 收到 issue 和 PR 之后我怎么处理开源之后收到的问题大概可以分成三类。第一类是环境问题比如有人用的 Python 版本太高导致 Pygame 装不上或者在中国网络环境下镜像源有问题这种一般回复里给一段安装命令就能解决。第二类是功能建议最多的是“希望能保存游戏进度”我暂时没做就在 issue 里标了feature-request让有兴趣的人自己提 PR。第三类是真 bug比如有人发现快速双击建造按钮会重复扣钱这个我复现之后两分钟就修了。处理 PR 的原则是“小改动直接合大改动先讨论”。加音效这种跟核心逻辑完全不冲突的直接合并如果有人改 AI 状态的我会先在本地跑几局确认不会把游戏搞失衡再合。开源不是把代码扔上去就完事而是持续维护一个小项目的运转节奏。5.3 常见问题速查表问题原因解决办法游戏后期单位一多就卡顿每帧重复计算 BFS、用绘图函数频繁画圆路径缓存、用预渲染贴图替代部分绘制AI 不进攻一直缩在家里状态机里attack的触发条件太严格调低出兵数量阈值或缩短集结等待时间建造建筑位置不对鼠标坐标没从屏幕坐标转世界坐标加上相机偏移量的换算单位卡在障碍物里BFS 路径和单位碰撞半径不一致单位移动时加一步碰撞检测超出就回退上一格中文乱码Pygame 默认字体不支持中文加载系统字体或改用英文界面这份表格是真实踩坑的记录也是开源社区里大家问得最多的几个点。每次有人问类似问题我把这个表格链接发过去就行省事了不少。6. 写在最后的真心话这次项目给我最大的感受不是“AI 能写游戏了”这种口号式的震撼而是“当你能把需求拆得足够细AI 产出的质量会出乎意料地高”。过去我们写代码最大的成本往往不是敲键盘而是想清楚边界、想清楚模块怎么划分、想清楚怎么验证——这些能力不因工具变化而贬值。如果你也想试试类似的事情我的建议很直接别一上来就做红警先从 2048 或者扫雷开始把 AI 协作的上手节奏跑通。等你能熟练地用小步迭代驾驭它了再挑战更复杂的游戏类型也不迟。做完这个项目之后我自己对 AI 编程的心态也变了。以前总觉得模型输出质量决定一切现在觉得真正决定天花板的是你能不能把一个大而模糊的想法翻译成一连串小而具体的任务。这个能力在任何时代都不会过时。