那一瞬间的想法其实挺草率的我盯着 GPT 6.1 的对话框脑子里忽然蹦出来一句——“让它照着《红色警戒》的玩法写一个能玩的即时战略游戏行不行”三天以后这个项目真的能开矿、能造兵、能拉一支部队去推对面基地我还把它开源到了 GitHub 上仓库地址就是标题下方那串 github.com/lanr。这篇不是来炫耀玩具的而是想把“用 AI 从零搓一个 RTS”的完整过程复盘一遍为什么选这个类型、怎么拆需求、哪些环节 AI 很擅长、哪些环节 AI 反复翻车、开源以后社区又教了我什么。如果你也在用 AI 做游戏或者单纯好奇代码生成这件事的边界在哪这篇应该能提供一些不太一样的参考。1. 为什么是红警拿 RTS 当 AI 编程的试金石1.1 RTS 的复杂度正好是压力测试很多人用 GPT 做过小游戏但绝大多数是贪吃蛇、俄罗斯方块、飞机大战这个量级。说实话这类项目对现在的代码模型来说已经不太能暴露问题了。我之所以直接选《红警》这种即时战略RTS是因为它同时踩中了游戏开发里好几座大山单位系统每个单位有血量、攻击、视野、速度、生产队列、所属阵营还得有移动和战斗状态。寻路与避让几十个单位同时从基地出发去同一个目标点不能全挤成一团也不能卡死在墙角。战争迷雾地图分成“已探索、可见、不可见”三种状态视野要跟随单位实时更新。敌方 AI对面不能是木桩得会发展经济、爆兵、选时机进攻。完整交互框选、右键移动、编队快捷键、Shift 排队指令、生产队列 UI这些缺了哪一个都“不像游戏”。性能底线RTS 是实时渲染加逻辑计算单位一多掉帧问题立刻现形。这八个字总结下来就是它逼着 AI 输出一套互相依赖的模块而不是一坨孤立函数。如果 GPT 6.1 能把 RTS 从零搭到“可玩”那说明它在长上下文、跨文件一致性和工程结构上的能力是真的能打如果搭不出来我最多损失三天时间换一个更真实的“AI 编程能力边界报告”。所以这个选题本质上是一次压力测试。1.2 技术栈选型为什么落到 TypeScript Canvas技术栈是刚开始就要定的事。我给 GPT 6.1 的要求很明确用 TypeScript Vite Canvas 2D不要任何重型引擎。理由有三条。第一分发成本低。Web 游戏开箱即玩开源出去之后任何人打开浏览器就能跑不需要装客户端这决定了开源项目的参与门槛。第二理性规模匹配。红警这种俯视角 2D RTSCanvas 2D 完全够用不需要上 WebGL 或 Three.js引入 3D 渲染反而会稀释“AI 写游戏逻辑”这个核心命题。第三新手和 AI 都好调试。TypeScript 的类型系统能帮 AI 兜住一大批低级错误Vite 的开发服务器能在保存后一秒内热更新我可以在浏览器里立刻看到改动的效果反馈回路极短这是高压迭代的生命线。架构方面我没有让 AI 上严格的 ECS实体组件系统而是用组件化的普通类加集中管理器。简单解释一下ECS 是大型游戏的标准答案但对于一个规模在五千到一万行左右的项目它引入的抽象成本大于收益。我更希望单位是一个可读性强的对象它有position、hp、state这些字段而不是拆成十几个组件再靠系统去遍历。这个决定在后期帮了大忙否则我大概率要一遍遍向 AI 解释“组件事件总线”是怎么回事而不是让它直接写业务逻辑。2. 三小时跑通原型从一句话需求到可点击的战场2.1 把红警拆成 7 个模块再逐个交给 GPT我见过太多人用 AI 做项目的失败方式上来一句话“帮我写一个红警”然后期待奇迹。结果 AI 给了一个几百行的大文件运行起来各种缺漏。正确的姿势是把需求拆开让 AI 逐模块交付。我拆成 7 块按依赖顺序推进模块交付内容验证方式主循环requestAnimationFrame 驱动的 update render 骨架打开页面能看到背景色刷新地图与网格地图数据、障碍物、格子坐标换算能渲染出基地地图单位系统移动、攻击、生产、状态切换手动放置单位验证移动资源系统金钱、矿场、采集逻辑能看到矿车往返带钱回来命令系统框选、右键移动/攻击、编队能选中并指挥单位敌方 AI经济调度、爆兵、进攻时机挂机观察几分钟UI/HUD生产列表、血量条、小地图完整跑一局每个模块单独开一轮对话完成并验证后再带着新代码进入下一轮。这个策略很关键让 AI 每次只专注一个上下文边界清晰的子任务生成的代码质量会高很多如果一次性铺开后面的代码经常会把它自己早先的定义覆盖掉。2.2 分阶段生成的核心 Prompt 长什么样第一阶段的主循环 Prompt我是这样写的我们正在用 TypeScript Vite Canvas 做一款 2D RTS 游戏。现在实现第一阶段主循环。需要支持稳定的 60 FPSupdate(dt) 负责逻辑render() 负责绘制代码写到 src/core/GameLoop.ts用类封装实例在 src/main.ts 中创建。所有纯逻辑函数请导出后续方便写测试。不要使用外部依赖。注意几个细节指定精确的文件路径是为了让 AI 的输出落位到已有工程结构里强调“导出纯函数”是为了后面能对核心逻辑做单元测试“不要使用外部依赖”是因为 RTS 的循环依赖一旦引入 npm 包版本兼容问题会消耗大量时间。事实证明只要 prompt 里写清楚了“哪个文件、什么接口、什么边界”GPT 6.1 的第一版代码质量就会高得离谱几乎不需要大改。2.3 让 AI 延续项目记忆的会话管理技巧GPT 6.1 的上下文窗口虽然大但长会话到了后半段它会逐渐“遗忘”早期定好的架构约定。比如第 10 轮对话之后它可能把之前约定的Vector2类型写成了两个独立数值或者把unit.state从枚举改成了字符串。这个问题比想象中严重因为 RTS 是强耦合系统一个字段类型变化会引发连锁编译错误。我的解决办法是维护一份ARCHITECTURE.md里面用极简的语言记录全局约定单位位置类型所有单位用{ x: number; y: number }禁止拆开传参。状态枚举idle | move | attack | collect | build。渲染分层地图层canvas 0、单位层canvas 1、特效层canvas 2、UI 层HTML 覆盖。性能铁律单位对象必须走对象池禁止在 update 中连续创建新对象。每轮开新对话之前我都会把这份文档和相关的两三个文件源码贴进去让 AI 在正确的约束下续写。这事看起来麻烦实际上是保住项目结构不崩的最大功臣。还有一个小技巧当一个模块变得特别复杂时主动开一个新的会话语境把架构摘要 该文件当前完整代码粘进去再继续改比在旧会话里硬扛效果好得多。3. 真正的硬骨头寻路、迷雾和敌方 AI 的生成与修复3.1 寻路A* 生成很快但“不堵路”改了三轮第一版寻路GPT 6.1 交出来的 A* 是标准得不能再标准的教科书实现单单位从 A 点走到 B 点路径完全没毛病。但一旦同时指挥 20 个单位走同一条路画面瞬间变成春运火车站现场所有单位精确地挤在同一条路径上互相穿插速度越快卡顿越明显。问题不在于 A* 本身而在于“路径规划”只是移动的一部分下面还要解决“路径平滑”和“单位间避让”。第二轮我让 AI 给每个单位施加一个随机的路径扰动作用微乎其微单位还是在路口堵死。第三轮我想明白了一个关键点单位不应该永远只看到最终目标点它们需要额外的局部避让逻辑。最终我让 GPT 在 A* 的基础上给每个单位加了“轨道偏移”与“弹性斥力”机制路径计算完成后每个单位在垂直方向叠加一个很小的偏移量同时在移动碰撞检测中加入推挤力。单位之间距离过近时互相推开但推挤力会在空闲状态逐渐衰减避免整个阵型乱掉。核心代码如下// 在 A* 结果上叠加轨道偏移避免所有单位走同一条直线 function smoothPath(rawPath: Vector2[], unitId: number): Vector2[] { const offset ((unitId % 7) - 3) * 0.35; // 固定偏移避免阻塞 return rawPath.map((point, index) ({ x: point.x offset, y: point.y (index % 2 0 ? offset : -offset), })); }这轮改完之后20 个单位同时行进终于不会互相卡死了。回头再看这个坑我的体会是AI 能完整写出 A*但“单位堵成一线”这种从生产效率层面冒出来的问题需要的是游戏设计的直觉而不是算法知识。这正是 AI 代码生成最容易翻车的地方——它做的事情在算法上是对的玩起来是错的。3.2 战争迷雾离屏 Canvas 的可见性更新战争迷雾是所有 RTS 迷心中的灵魂设定但代码实现里它是典型的“看起来简单、一写全是坑”。GPT 6.1 第一次实现时在每一帧渲染循环里遍历了地图上所有格子逐个判断是否处于任何单位的视野范围内然后更新像素。小地图80×80 格还能扛把地图加大到正常 RTS 的 160×160 之后帧率直接跌到 20 FPS 以下。性能瓶颈很明显每帧全图遍历做的是 O(n²) 量级的工作大量计算还被浪费在已经探明的区域里。我让 AI 换了思路用一块离屏 Canvas 保存迷雾层的遮罩平时不动它只有当单位真正移动并触发视野更新时才在局部范围增量重画。单位移动时以视野半径画一个圆形的“清除遮罩”区域到离屏 Canvas再整体贴回主画布。这样视野更新量从“全图格数”降为“单位视野圆面积”帧率立刻回到 60。这个阶段我学到的一个很重要的事让 AI 优化性能不能直接说“太卡了优化一下”它会给你一堆隔靴搔痒的微调。你必须先自己定位到瓶颈在哪然后给出明确的优化指令比如“把迷雾更新从全图遍历改为离屏 Canvas 增量绘制视野变化只更新局部区域”。这就是你和工具协作的边界——分析方向是你的活把它变成代码是 AI 的活。3.3 敌方 AI从“傻站着”到“会偷袭”敌方 AI 是三个难点里最“玄学”的。GPT 6.1 第一版给的 AI 逻辑是一个非常简单的状态机生产到 5 个兵就冲锋死了再继续造。效果呢对面基地就像一个流水线不停地派小兵出来送死玩家毫无压力。这个 AI“能跑”但完全没有“像活人”。那时我意识到RTS 的敌方 AI 本质上是一套带策略的决策系统。我让 AI 把决策周期设置为每 10 秒一次每次评估三个指标当前兵力、当前金钱、玩家兵力估算。只有当兵力优势超过 1.5 倍时才进攻否则先攒钱发展和补兵。另外我还让 AI 进攻时随机选择两三个入口方向而不是永远从正面压过来这样玩家至少需要同时留意侧面和后方。function decideNextMove(ai: AiState, enemy: PlayerState): Action { const ratio ai.armyPower / enemy.armyPower; if (ai.cash 1200 ratio 1.5 ai.armySize 12) { const entry ai.getRandomEntryPoint(); // 正面 / 左侧 / 右侧 return { type: attack, target: entry }; } if (ai.cash 300) return { type: build, unit: rifle }; return { type: wait, duration: 5 }; }改完之后敌人终于学会了“猥琐发育、一波推进”的节奏玩家必须跟 AI 拼运营而不是无脑防守。这里我想说的是AI 生成的敌方 AI 逻辑不足不是因为模型不会写状态机而是它不知道“什么样的迟滞时间和进攻阈值能形成趣味”。参数这个东西始终得靠真人来调。4. 从“能跑”到“能玩”我替 GPT 补的那些工程课4.1 右键指令、编队快捷键与交互细节跑通核心玩法是一回事但距离“能玩”真的还有很长一段路。第一版里移动单位只能点击屏幕上的按钮体验像网页 Demo 而不是游戏。我花了整整一天让 GPT 6.1 补齐了整套交互左键框选、左键单击选中。右键移动、右键点敌方单位进攻。Shift 右键进入队列指令单位执行完一条移动命令后自动执行下一条。Ctrl 数字键为当前选中编队双击数字键跳转到该编队位置。双击某个单位时选中屏幕上所有同类型单位。这些交互初看都是零散需求但它们需要一套统一的命令缓冲系统。先记录所有鼠标和键盘事件再结算为一个个指令对象进入单位的行为队列。顺序不对就会出现“边走路边攻击”“剔出队形”的傻行为。让 AI 一次性实现全部组合几乎不可能不崩所以我按“单选加右键移动 → 框选加编队 → Shift 队列 → 双击同类型”四步走每完成一步就试玩几十局。交互细节对 RTS 的重要性不亚于单位平衡性你可以理解为它是玩家和游戏之间的语法语法错了脑子里的战术再厉害也使不出来。4.2 单位上限与对象池性能问题不靠换机器解决原型阶段我迷信机器性能觉得单位多就多,卡就卡。结果一队 50 个单位同屏之后掉帧直接掉到 25 FPS 以下。这批性能问题的根源在于每个单位都是独立对象单位一多垃圾回收压力会瞬间爆炸。我做的第一件事是让 AI 加对象池单位创建时从池中取出死亡时不是delete而是回收并放入空闲队列重置状态下次需要时复用。这个改动直接把同屏单位数量从 50 拉到 120。第二件事是 Canvas 分层单位图层、特效图层与地图图层分离单位移动时只重绘单位层不再让整个地图跟着反复重画。第三件事是设置合理的单位上限我给玩家和 AI 分别设置了 150 和 200 的同屏上限超过后就停止生产新单位并自动解散最老的编队。上限限制听上去有点土但在 RTS 设计里其实是老传统的性能策略。优化项优化前优化后对象池每个单位独立 new 和 delete复用对象后丢弃GC 压力大减Canvas 分层单画布全图重绘单位层/地图层/特效层分离同屏单位50 单位 25 FPS120 单位稳定 60 FPS这一步带给我的震动很大AI 生成的代码在单点上总是很漂亮但它不会像资深前端那样主动思考“对象生命周期”“重绘范围”这类工程问题。性能优化就像打扫房间你不能只说“把房间弄干净”要能指出“地板上这些书应该整整齐齐放进书架里”。4.3 平衡性与胜负逻辑为什么还要自己调参数GPT 6.1 生成的初始伤害数值堪称灾难坦克 500 血量、100 攻击力步兵 80 血量、12 攻击力。看起来数值写得很“合理”但实际玩起来一辆坦克能把一群步兵碾压到不能自理游戏在开局十分钟内就会结束。数值这东西很神奇它不是技术问题但比很多技术问题都影响体验。我给自己定了一套笨办法挑出五个关键指标包括坦克造价、机枪兵造价、DPS、移动速度、视野范围每次只调一个变量然后让 AI 自动对战十局统计胜负率。最后我把数值拉成更平滑的曲线机枪兵造价黄金 100DPS 12坦克造价黄金 700DPS 70但坦克血量压到 280让它对步兵群时能吃住伤害但不至于无敌。这套数值完全不严谨但它让这个“玩具红警”变得有来有回。所以别指望 AI 能帮你做平衡设计因为平衡本质上是对抗与乐趣的映射AI 不理解乐趣它只理解“数字合理性”。5. 开源这步棋仓库怎么组织社区反馈怎么接5.1 许可证与 README开源的第一步是“让人敢用”项目做到能玩之后我几乎没犹豫就决定开源。代码放出来简单但“开源得体”很难。第一步是选许可证我选了 MIT理由很简单允许别人自由使用、修改、再分发也允许商用学起来没有法律负担。如果你也想开源类似项目建议在文件头写清楚版权与许可不然别人根本不敢碰你的代码。第二步是写 README我在 README 里放了以下几样东西一张试玩动图、一段两分钟的视频演示、开发环境运行命令、架构图用一个文本树形图描述模块划分、以及完整的目录结构。src/ core/ # 主循环、事件总线、命令队列 map/ # 地图数据、迷雾、路径寻路 units/ # 单位基类、生产、战斗 ai/ # 敌方决策状态机 render/ # 分层渲染器 ui/ # HUD、生产面板、小地图说实话README 里最有价值的不是功能列表而是“如何通过环境变量和配置项切换不同调试模式”这十几行说明。它直接决定了陌生人会不会在五分钟内放弃你的项目。5.2 结构化分支与自动化构建让陌生人能一键跑起来开源之后最怕的提问是“为什么我 npm install 之后跑不起来”。我构建项目的时候用的是 npm但我很快发现package-lock.json在不同 Node 版本下会制造大量版本冲突问题。所以我把构建流程调整成使用 pnpm 固定 lockfile并配置了 GitHub Actions每次 push 到 main 分支都会自动执行安装、类型检查、构建然后发布到 GitHub Pages。这样任何人在线打开链接拿到的是经过自动化验证的产物不会出现“我自己本地能跑别人一跑就炸”的经典悲剧。还有一个细节Action 里我把 Node 版本钉在 LTS并在package.json里加了engines声明防止大家环境不一致产生不必要的兼容问题。开源项目的第一次体验至关重要自动化构建就是守门员。5.3 从 Issues 里学到的三个游戏开发教训项目挂到 GitHub 之后收获了不少反馈其中三个 Issue 给我上了一课。第一个有人报告“鼠标在 Canvas 边缘之外框选会失效”。原因是我的事件监听器绑定在 Canvas 元素上而不是 document 层。这个 bug 属于典型的“自己玩永远不会遇到别人玩一玩就炸”的边缘情况。第二个有人反馈“单位中文名显示为方块”。排查发现是我的渲染用了系统字体而对方系统没装中文字体包。解决方式是把字体文件打包进项目用 CSSfont-face强制加载。第三个也是最有价值的教训有玩家抱怨“游戏后期太卡但单位已经到上限了”仔细定位之后发现是对象池里单位“死亡”后它身上挂着的路径缓存没有清空导致旧的路径点一直在内存里堆积。老玩家用脚投票找出的 bug比我自己闷头测试精确得多。这三个 Issue 让我更坚定了一个想法开源接反馈本质上是免费的 QA 工场。代码里你觉得无关紧要的小问题新手用户会在第一分钟就踩到。而这种硬核用户给的反馈对项目的打磨价值是任何代码审查工具都给不了的。6. 写在最后AI 写游戏的人机协作边界6.1 GPT 6.1 是结对搭档不是代码自动机整个项目做下来我粗略统计了一下大约 65% 的代码由 GPT 6.1 直接生成或大幅改写剩下的 35% 是结构设计、性能修复、参数调试和数百次试玩后的微调。有人可能会觉得“用 AI 写游戏 只需要动嘴”但实际情况远没这么简单。如果把做游戏比作包饺子GPT 6.1 就是一台能把面团和肉馅处理得很漂亮的机器但和面加多少水、肉馅调料怎么配、包出来的饺子怎么捏出花样这些“从可以吃到好吃”的差距还是得靠人手一点点调。它最大的价值在于极大地压缩了从想法到“能跑的半成品”的时间但后面那个“从半成品到成品”的过程并没有魔力可以省掉。6.2 最后一招让 AI 先写测试再写实现如果让我分享一个最希望当初一开始就做的习惯那就是让 GPT 6.1 先用测试描述行为再写实现。比如“寻路函数输入起点和终点返回的路径长度必须大于 0最后一个点必须等于终点”再比如“移动命令的目标点必须经过单位半径的碰撞检测”。先写测试等于先把验收标准写清楚AI 后续迭代时就不会瞎改接口也不会因为我换了个需求角度就把旧功能全盘推翻。这是我踩过最深的一个坑换来的经验没有测试兜底的 AI 生成代码越改越乱直到某个节点你只能推倒重来。回头再看这个三天速成的“玩具红警”它当然没法跟原版《红色警戒》相提并论单位动画简陋音效还是我从免费素材库里抓来的数值平衡基本靠感觉。但它真真切切能玩而且整个项目从零到开源的全过程是我近几年经历过最好的 AI 协作实验。如果你也想试着让 AI 做一个规模不小的游戏我的建议很简单别从贪吃蛇开始直接从你觉得“这 AI 肯定做不出来”的项目开始拆解它喂给它然后看它怎么翻车——因为翻车的过程才是你真正学会和它协作的过程。