多AI协作开发游戏踩坑记：我为什么砍掉了架构师和代码审查AI

1. 从“给AI配团队”到“全砍掉”一个反直觉的工程决策去年有一阵子我特别迷恋给开发流程里的 AI 加“角色”。起因很简单单靠一个通用大模型写游戏逻辑它经常写出那种“看起来能跑、一跑就崩”的代码。于是我想既然人类团队里有架构师把关设计、有代码审查兜底质量那我给 AI 也配上一套不就行了说干就干。我搭了一条流水线需求先丢给“架构师 AI”让它输出模块划分和接口定义然后“开发 AI”照着架构文档写实现写完再交给“代码审查 AI”挑毛病最后跑一遍测试。听起来是不是挺像那么回事我甚至一度觉得这套东西可以复用到任何项目上。结果跑了大概三周我把架构师和代码审查这两个角色全砍了只留下一个精简过的开发环节。不是它们没用而是它们带来的收益远远覆盖不了它们引入的麻烦。这篇文章就把这段踩坑经历完整拆开讲包括我当初为什么这么设计、每个角色具体怎么拖后腿、砍掉之后用什么替代、以及如果你也想搞多 AI 协作哪些坑可以提前绕开。先给结论免得你看到一半才发现方向不对在游戏开发这种“逻辑强耦合、状态多、反馈快”的场景里给 AI 加中间审查层最大的问题不是审查得不好而是审查本身制造了新的不确定性。一个 AI 的幻觉你还能定位三个 AI 互相“确认”之后的幻觉你连从哪查起都不知道。这篇文章适合两类人看一是正在折腾 AI 辅助编程、想知道多智能体协作到底靠不靠谱的开发者二是做游戏开发、想用 AI 提效但被各种“AI 工作流”绕晕的独立开发者。我会尽量说人话把每一步的取舍讲清楚。2. 我当初为什么笃定“架构师 AI 代码审查 AI”能成2.1 单模型写游戏的三个典型翻车现场在配“团队”之前我用单个大模型写游戏逻辑踩的坑非常集中基本就三类。第一类是状态管理混乱。比如做一个角色移动加跳跃的功能模型会把“是否在地面”“当前速度”“输入方向”这些状态散落在好几个函数里跳跃和重力更新各改各的跑起来就是角色偶尔能二段跳、偶尔卡在空中。它每次只盯着你让它改的那个函数没有全局状态的概念。第二类是接口对不上。我让它先写一个敌人 AI再写一个战斗系统两边对“伤害”这个数据的定义完全不一样——一边用整数、一边用浮点一边传对象、一边传 ID。等我把两段代码拼起来编译都过不了。第三类是改一处崩三处。游戏逻辑耦合度高模型改一个移动速度顺手把碰撞检测的判定也动了因为它觉得“这样更合理”。它没有“最小改动”的意识。这三类问题恰好对应人类团队里架构师和代码审查要解决的事架构师管全局结构和接口代码审查管改动边界和质量。所以我很自然地想那就把这两个职责交给专门的 AI 角色。2.2 多智能体协作的诱惑分工听起来太美了当时我看了不少关于多 AI 协作multi-agent的讨论核心思路就是“让专业角色干专业事”。一个负责规划、一个负责执行、一个负责检查形成闭环。这套思路在写文档、做调研这类任务上确实有效因为那些任务对“一致性”的要求没那么苛刻错了重来成本低。游戏开发不一样。游戏是一个持续运行的状态机任何一处逻辑错误都会在运行时被放大。我当时的判断是正因为游戏逻辑容易错才更需要架构师提前把结构定死、需要审查在合并前拦住问题。这个判断本身没错错的是我低估了“让 AI 扮演这些角色”的执行成本。2.3 我搭的第一版流水线长什么样具体说一下我最初的流水线方便你对照自己的方案。架构师环节我把游戏需求比如“做一个横版跳跃关卡含移动、跳跃、敌人巡逻、受伤重置”整理成一段描述让模型输出一份架构文档要求包含模块划分、每个模块的职责、模块间接口、关键数据结构。输出格式我卡得比较死要求用列表和代码块。开发环节把架构文档作为上下文加上具体某个模块的实现要求让模型写代码。一次只写一个模块写完我手动贴进项目。审查环节把刚写的代码连同架构文档一起丢给审查 AI让它找出“与架构不符”“潜在 bug”“边界条件遗漏”三类问题输出修改建议。测试环节跑我手写的单元测试和手动试玩。这套流程跑第一个模块的时候效果确实惊艳。架构文档结构清晰开发代码基本符合接口审查还真的挑出了两个边界问题。我当时觉得成了。3. 架构师 AI 是怎么一步步变成瓶颈的3.1 它设计的架构开发 AI 根本执行不了问题从第二个模块开始暴露。架构师 AI 给出的接口设计在纸面上非常漂亮——抽象层次分明扩展性强。但开发 AI 拿到之后经常“理解不了”或者“自作主张改掉”。举个具体的例子。架构师设计了一个事件系统要求所有模块通过事件总线通信模块之间不直接引用。这个设计在大型项目里是对的但对于一个只有几个模块的小游戏它引入了大量样板代码。开发 AI 每次写一个模块都要先写一堆事件注册、事件派发的代码写着写着它就烦了开始直接调用其他模块的函数——因为那样“更简单”。结果就是架构文档说一套实际代码做一套。而审查 AI 拿着架构文档去审就会报一堆“违反架构”的问题但这些问题的根源是架构本身对这个项目规模来说过度设计了。这里的关键教训是架构的“好坏”是相对于项目规模而言的。AI 架构师没有“项目规模感”它默认往“规范、可扩展”的方向走而小游戏项目最不需要的就是过度抽象。3.2 架构文档越详细开发 AI 越容易跑偏我一开始以为架构文档写得越细开发 AI 执行得越准。实测恰恰相反。当架构文档详细到“每个函数的参数类型和返回值”时开发 AI 会变得非常死板。它严格照着文档写但文档里没覆盖到的情况它就完全不管。比如文档写了“受伤函数接收伤害值”但没写“伤害值为负时怎么办”开发 AI 就真的不处理运行时负数伤害反而给角色回血。更麻烦的是文档越详细我维护文档的成本越高。改一个设计要同步改文档、改代码、再让审查重新跑一遍。到后来我发现我花在“维护这套 AI 流程”上的时间已经超过了我自己直接写代码的时间。3.3 一个真实案例事件系统被设计成了迷宫说个最典型的。架构师 AI 为我的游戏设计了一套三层事件系统底层是原始输入事件中间层是游戏逻辑事件上层是 UI 事件三层之间通过转换器连接。听起来很专业对吧实际开发时我想加一个“暂停”功能。按这套架构暂停要经过输入层捕获按键 → 转换成逻辑层的暂停事件 → 逻辑层通知 UI 层显示暂停菜单。为了这一个功能我改了四个文件还因为某一层的事件没正确传递调试了整整一个下午。最后我把这套事件系统全删了改成最朴素的一个全局状态对象谁需要谁读改状态就改这一个对象。代码量少了三分之二暂停功能十分钟搞定。这件事让我彻底想明白AI 架构师倾向于“教科书式正确”而游戏开发很多时候需要的是“够用就好”。它不会替你判断“这个项目值不值得上这套架构”而这个判断恰恰是最重要的。4. 代码审查 AI 的幻觉它审出的问题比它拦住的还多4.1 审查意见的“正确但无用”困境代码审查 AI 最典型的行为是给你一堆“正确但无用”的意见。比如它会说“这个函数没有处理输入为 null 的情况。”——可这个函数的调用方保证了永远不会传 null加这个判断纯属噪音。再比如它会说“建议把这个魔法数字提取成常量。”——那个数字就用了一次提取成常量反而增加了阅读跳转成本。这些意见单看都没错但它们是通用最佳实践不是针对当前上下文的判断。人类审查者知道什么时候该较真、什么时候可以放过AI 审查者不知道它只会把所有能挑的都挑出来。我统计过一段时间审查 AI 平均每个模块报 15 条问题其中真正需要改的不到 3 条。剩下 12 条我要么手动忽略要么花时间判断“这条到底要不要改”。这个判断成本比我自己写代码还高。4.2 它会把“风格差异”当成“逻辑错误”更头疼的是误报。审查 AI 经常把“和它预期不一样的写法”判定为错误。有一次开发 AI 用了一个for循环遍历数组审查 AI 说“建议改用map更符合函数式风格”。可那个循环里有副作用修改外部变量用map反而是错的。审查 AI 只看到了“遍历”这个模式没看懂循环体在干什么。还有一次开发 AI 写了一个状态判断用了switch审查 AI 说“建议用策略模式重构”。一个只有三个分支的状态判断用策略模式纯属杀鸡用牛刀。这些误报的代价是我要逐条读、逐条判断、逐条决定改不改。审查 AI 没有帮我省时间它把“写代码”的负担转移成了“审审查意见”的负担。4.3 最致命的审查 AI 和开发 AI 会“互相说服”这是压垮我的最后一根稻草。有一次开发 AI 写了一段有 bug 的代码。审查 AI 没看出来反而夸它“结构清晰”。我手动发现 bug 后把问题反馈给开发 AI 让它改。开发 AI 改完审查 AI 又说“这个改法引入了新问题”——而那个“新问题”其实不存在是审查 AI 的幻觉。两个 AI 就这样来回拉扯每一轮都消耗我的 token 和时间最后我不得不手动介入把两边都关掉自己改。多 AI 协作最危险的地方在于它们会互相确认彼此的幻觉。一个 AI 错了另一个 AI 基于错误的前提继续推理错误被层层放大而你作为人类要花成倍的时间去追溯错误到底从哪一层开始的。5. 砍掉两个角色之后我换成了什么5.1 用“一份活的接口约定”替代架构师 AI砍掉架构师 AI 之后我没有完全放弃“先定结构”这件事而是把它从“AI 生成文档”改成了“我手写一份极简接口约定”。这份约定很短通常就一页只写三样东西模块列表、每个模块对外暴露的函数签名、关键数据结构。不写实现思路、不写设计模式、不写扩展性考虑。它的唯一作用是让开发 AI 知道“边界在哪”。为什么手写因为只有我知道这个项目现在需要多少结构。AI 不知道我的项目下周会不会加新功能也不知道我是不是只想做个原型。这个判断必须由人来做而且做起来很快十分钟就能写完。5.2 把“审查”降级成“针对性提问”代码审查 AI 我也砍了但不是完全不要检查。我改成了一种更轻的方式写完一个模块后我自己先扫一遍只针对我不确定的地方向 AI 提问。比如我觉得某段状态更新可能有问题我就问“这段代码在角色同时受到两个伤害时状态会怎样变化”让 AI 针对具体问题分析而不是让它泛泛地“审查全部代码”。这样做的效果立竿见影。AI 在回答具体问题时准确率远高于泛泛审查因为它有了明确的焦点。而且我只在真正需要的时候才调用它token 消耗和判断成本都大幅下降。5.3 测试驱动让测试当真正的“审查者”真正替代代码审查的是测试。我现在写游戏逻辑的流程是先写这个模块的测试用例哪怕只是几个断言再让开发 AI 写实现然后跑测试。测试不过把失败信息丢回给 AI 让它改直到通过。测试的好处是它是客观的、无幻觉的。AI 可以骗过审查 AI但骗不过一个断言expect(player.hp).toBe(50)。测试通过就是通过不通过就是不通过没有“正确但无用”的意见也没有“互相说服”的空间。代价是我要写测试。但写测试的时间远少于我审审查意见的时间。而且测试写完可以复用审查意见看完就没了。6. 如果你也想搞多 AI 协作这几条经验能帮你少走弯路6.1 角色越多不确定性越大不是越小很多人直觉上觉得“多加一层检查会更稳”但在 AI 协作里每加一个角色就多一层幻觉来源。三个 AI 串联出错概率不是相加而是相乘。我的建议是能用两个角色解决的绝不用三个。一个开发、一个按需提问足够了。架构和审查这两个职责在中小型游戏项目里人来承担比 AI 承担更划算。6.2 让 AI 做“执行”别让它做“判断”AI 擅长的是执行明确的任务写一个函数、改一个 bug、解释一段代码。它不擅长的是判断“这个项目需不需要这套架构”“这条意见该不该采纳”。所以我的分工原则是判断归人执行归 AI。架构判断、优先级判断、要不要重构的判断我自己来具体的代码实现、具体的 bug 修复交给 AI。这样既享受了 AI 的执行效率又避免了它的判断偏差。6.3 上下文要给“边界”不要给“蓝图”给开发 AI 的上下文重点是告诉它“边界在哪”这个模块负责什么、不负责什么、对外接口是什么。不要给它一份详细的实现蓝图那会限制它的发挥也会让它在你没覆盖到的地方完全失能。边界清晰 实现自由是我试下来效果最好的组合。6.4 保留“一键回退”的能力不管 AI 流程多顺一定要用版本控制每完成一个可运行的小步骤就提交一次。因为 AI 改代码经常是“改对了 A、改坏了 B”没有回退能力你会在一个坏状态里越陷越深。我现在的习惯是AI 每改完一个模块、测试通过立刻提交。这样即使后面发现方向错了也能干净地退回来。7. 写在最后砍掉不是否定是认清边界回头看这段经历我并不觉得给 AI 配架构师和代码审查是错的尝试。它让我非常清楚地看到了 AI 在软件工程里的能力边界它能高效执行但不能替代判断它能生成结构但不能理解规模它能挑出问题但不能分辨轻重。砍掉那两个角色不是因为我否定多 AI 协作而是因为我认清了这个项目、这个阶段什么样的协作方式才是真正提效的。对独立开发者和小团队来说最贵的从来不是写代码的时间而是判断和决策的时间。任何增加判断负担的流程哪怕它看起来再“专业”都应该被砍掉。如果你现在也在折腾 AI 工作流我的建议就一句先用最简单的方案跑起来遇到具体问题再加角色而不是一开始就把团队配齐。角色是解决问题的不是用来显得专业的。