1. 从“给AI配团队”到“全砍掉”的折腾始末去年下半年我开始认真折腾用 AI 辅助做游戏这件事。不是那种“让 AI 写个贪吃蛇”的玩具项目而是真的想跑通一条从需求到可玩 Demo 的完整链路。当时我的想法很朴素既然 AI 能写代码那我给它配上架构师角色负责顶层设计再配一个代码审查角色负责质量把关三个 Agent 各司其职不就等于我白捡了一个小型开发团队这个念头一旦冒出来就压不住了。我花了大概两周时间搭了一套多 Agent 协作流程一个负责拆解需求、输出模块划分和接口定义的“架构师”一个负责按架构写具体实现的“开发”还有一个专门挑刺、检查代码质量与潜在 Bug 的“审查员”。听起来很美好对吧但实际跑起来之后我踩的坑一个接一个最后不得不把架构师和代码审查这两个角色全部砍掉只保留最核心的开发环节。这篇文章就是把这整个过程完整复盘一遍。我会讲清楚当初为什么这么设计、每个角色具体怎么配的、踩了哪些坑、为什么最后选择砍掉以及砍掉之后我是怎么保证代码质量的。如果你也在用 AI 做游戏或者正在设计多 Agent 协作流程这些经验应该能帮你少走不少弯路。2. 为什么我会想到给 AI 配“架构师”和“代码审查”2.1 单 Agent 写代码的天花板在哪里最开始我是单 Agent 模式一个对话窗口从头写到尾。小项目还行一旦代码量上去问题就暴露得很明显。最典型的是上下文漂移写到第三四个模块的时候AI 已经忘了第一个模块里定义的接口长什么样开始自己发明新的函数名和参数格式。等你回头去对接发现两边根本对不上。另一个问题是缺乏全局视角。你让 AI 写一个“玩家移动”的功能它会老老实实写出来但它不会主动考虑这个移动逻辑跟后面的碰撞检测、动画状态机怎么衔接。每个模块单独看都没问题拼在一起就各种冲突。这就像让一个很会砌墙的工人直接盖房子他没做过设计砌到一半发现承重墙位置不对只能拆了重来。我当时的判断是这些问题的根源在于 AI 缺少一个“先想清楚再动手”的环节。如果有一个架构师角色先把模块划分、接口定义、数据流向都定下来开发角色只需要按图施工理论上就能避免上下文漂移和接口不一致的问题。2.2 多 Agent 分工的理论优势从软件工程的角度看这个思路其实很合理。传统开发团队里架构师负责技术选型和模块拆分开发负责具体实现代码审查负责质量兜底三者配合确实能大幅提升代码质量。我把这套流程搬到 AI 上期望值是这样的架构师 Agent输入是游戏需求描述输出是模块清单、每个模块的职责、模块间的接口定义、关键数据结构。这份架构文档作为后续开发的“宪法”所有代码都必须遵守。开发 Agent输入是架构文档加具体任务描述输出是符合接口规范的代码实现。代码审查 Agent输入是开发产出的代码输出是问题清单和改进建议开发根据审查意见修改。理论上这套流程能解决单 Agent 模式下的接口不一致、全局视角缺失、代码质量参差不齐等问题。而且每个 Agent 的上下文窗口只需要装自己那一部分信息不会因为项目变大而爆掉。2.3 我实际搭建的第一版流程第一版流程我搭得比较粗糙就是用提示词把三个角色串起来。架构师先跑输出一份 Markdown 格式的架构文档然后我把架构文档拆成若干任务逐个喂给开发 Agent开发写完一个模块我把代码丢给审查 Agent审查 Agent 返回问题列表我再把问题列表转给开发 Agent 让它改。整个流程跑在一个对话窗口里靠提示词切换角色。比如我会说“现在你是架构师请根据以下需求输出架构文档”等它输出完我再说“现在你是开发请根据架构文档实现模块 A”。这种方式很原始但能快速验证想法。跑完第一个小项目之后我发现了一些有意思的现象。架构师输出的文档确实让开发阶段的接口一致性好了很多但架构师本身经常给出过于理想化的设计比如把一个简单的 2D 游戏拆成十几个模块每个模块之间的依赖关系画得跟蜘蛛网一样。开发 Agent 拿到这种架构文档反而不知道从哪下手了。3. 架构师 Agent 的配置细节与踩坑记录3.1 架构师角色的提示词设计我给架构师写的提示词大概长这样你是一位资深游戏架构师擅长将游戏需求拆解为可独立开发的模块。 你的任务是 1. 分析游戏核心玩法识别出必要的功能模块 2. 为每个模块定义清晰的职责边界 3. 定义模块间的接口函数名、参数、返回值 4. 输出关键数据结构定义 5. 标注模块间的依赖关系和开发顺序 输出格式要求 - 使用 Markdown 表格列出模块清单 - 每个模块用代码块给出接口定义 - 最后给出建议的开发顺序这个提示词看起来没什么问题但实际跑起来之后架构师输出的文档经常出现几种典型毛病。3.2 架构师过度设计的典型表现最常见的问题是过度设计。我让它设计一个简单的“打砖块”游戏它给我输出了这样的模块划分游戏状态管理、输入处理、物理引擎、碰撞检测、渲染管线、音频管理、关卡加载、分数系统、UI 系统、存档系统、配置管理、事件总线。十二个模块。一个打砖块游戏而已我原本预期三四个模块就够了。这种过度设计的直接后果是开发 Agent 的工作量暴增。每个模块都要写接口、写实现、写测试而且模块之间的依赖关系复杂到开发 Agent 经常搞混。比如事件总线和游戏状态管理这两个模块职责边界很模糊开发 Agent 有时候把状态变更逻辑写在事件总线里有时候又写在状态管理里最后两边代码互相打架。我后来分析了一下原因。架构师 Agent 的训练数据里肯定包含大量企业级软件架构的案例它默认把“模块化”等同于“拆得越细越好”。但游戏开发和普通软件开发有个很大的区别游戏的核心循环是高度耦合的你很难把渲染、物理、输入完全解耦成独立模块。强行解耦的结果就是引入大量胶水代码复杂度不降反升。3.3 接口定义与实际实现的脱节第二个问题是接口定义太抽象。架构师给出的接口经常长这样class IGameEntity: def update(self, delta_time: float) - None: ... def render(self, renderer: IRenderer) - None: ... def get_component(self, component_type: type) - Any: ...这种接口在架构层面没问题但开发 Agent 拿到之后完全不知道怎么实现。IRenderer是什么component_type具体有哪些Any返回值到底是什么类型架构师没有给出这些细节开发 Agent 只能自己猜。一猜就出问题不同模块对同一个接口的理解不一致对接的时候各种报错。我试过让架构师把接口定义得更具体比如把IRenderer展开成具体的方法列表。但这样一来架构文档的篇幅急剧膨胀架构师 Agent 的上下文窗口很快就不够用了。而且架构师给出的具体接口往往跟实际实现需求有偏差开发 Agent 照着实现反而更别扭。3.4 架构文档的维护成本被严重低估第三个问题是我一开始完全没预料到的架构文档的维护成本。游戏开发过程中需求变更是常态我经常写着写着发现某个模块的设计需要调整。这时候架构文档就过期了我需要重新跑一遍架构师 Agent让它根据新的需求更新架构文档然后再把更新后的文档同步给开发 Agent。这个同步过程极其痛苦。架构师更新文档之后开发 Agent 之前写的代码可能就不符合新架构了需要回炉重写。而且架构师更新文档时经常“顺手”改一些不相关的地方导致我很难判断哪些变更是必要的、哪些是它自己发挥的。有一次我让架构师把“玩家移动速度”这个参数从配置模块移到玩家模块它顺便把整个配置模块的接口全改了导致所有依赖配置模块的代码全部报错。4. 代码审查 Agent 的配置与失效分析4.1 审查角色的提示词与检查项代码审查 Agent 的提示词我是这么写的你是一位严格的代码审查员负责检查游戏代码的质量。 请从以下维度审查代码 1. 接口一致性实现是否符合架构文档中定义的接口 2. 边界条件是否处理了空值、越界、除零等异常情况 3. 性能问题是否有不必要的循环、重复计算、内存泄漏风险 4. 可读性命名是否清晰、逻辑是否易懂 5. 潜在 Bug逻辑错误、状态不一致、竞态条件 输出格式 - 按严重程度分级阻塞/严重/一般/建议 - 每个问题给出具体行号和修改建议这个提示词覆盖的维度挺全的审查 Agent 也确实能发现一些问题。比如它经常能指出“这个循环里每次都重新计算了数组长度建议提到循环外面”或者“这里没有处理 delta_time 为 0 的情况”。这些建议本身没错但实际用下来审查 Agent 的问题比它解决的问题还多。4.2 审查意见的“正确但无用”困境审查 Agent 最让人头疼的地方是它给出的意见技术上正确但实际无用。举个例子它审查一段玩家移动代码时指出“如果 delta_time 为负数玩家会向反方向移动建议增加参数校验。”这个意见在理论上完全正确但实际游戏中 delta_time 永远不可能为负数加这个校验纯粹是浪费代码行数。类似的意见还有“建议为所有公共方法添加类型注解”、“建议将魔法数字提取为常量”、“建议增加日志输出便于调试”。这些建议放在企业级项目里都是好习惯但放在一个快速迭代的游戏 Demo 里每一条都增加了开发负担却没有带来实际收益。我统计过一轮审查意见大概 70% 属于“正确但无用”20% 属于“吹毛求疵”只有 10% 是真正有价值的问题。但为了处理那 10%我得把 100% 的意见都过一遍时间成本太高了。4.3 审查与开发的“踢皮球”循环更麻烦的是审查 Agent 和开发 Agent 之间的“踢皮球”。审查 Agent 提出意见开发 Agent 修改修改完之后我再让审查 Agent 复查。审查 Agent 复查时经常又提出新的意见有些是新引入的问题有些是它上一轮没看出来的。开发 Agent 再改审查再提如此循环。我遇到过最夸张的一次一个简单的“敌人追踪玩家”功能审查和开发来回改了七轮。第一轮审查说“没有处理玩家死亡的情况”开发加了判断第二轮审查说“玩家死亡后敌人应该停止追踪但你的代码只是跳过了移动状态没有重置”开发改了状态重置第三轮审查说“状态重置时没有清理寻路缓存”……每一轮审查都能找到新的问题但这些问题在实际运行中根本不会触发因为玩家死亡后游戏就结束了敌人停不停止追踪根本不重要。这个循环的根源在于审查 Agent 的目标是“找出所有可能的问题”而开发 Agent 的目标是“让审查 Agent 满意”。两个目标叠加就会陷入无限优化的死循环。我后来意识到代码审查在真实团队里之所以有效是因为审查者有“这个项目的时间预算”和“这个功能的重要性”这两个隐含上下文而 AI 审查 Agent 没有这些上下文它只会机械地执行“找问题”这个指令。4.4 审查 Agent 的上下文窗口瓶颈还有一个技术层面的问题审查 Agent 需要看到完整的代码上下文才能做出准确判断但游戏项目的代码量很快就超过了单个上下文窗口的容量。我试过把代码分块喂给审查 Agent但分块之后它看不到模块间的调用关系经常误报。比如它看到某个函数没有被调用就建议删除但实际上这个函数是在另一个文件里被调用的只是审查 Agent 没看到那个文件。我也试过让审查 Agent 只看 diff变更部分但 diff 模式下它缺乏足够的上下文来判断变更是否合理。有一次开发 Agent 修改了一个函数的返回值类型审查 Agent 只看到 diff 里的类型变更没看到调用方也需要同步修改结果漏报了一个严重的接口不一致问题。5. 砍掉两个角色之后我的替代方案5.1 为什么最终决定全部砍掉压垮骆驼的最后一根稻草是一个周末。我本来计划用两天时间完成一个塔防游戏的核心玩法结果两天里大部分时间都花在了架构文档更新和审查意见处理上。架构师 Agent 把塔防拆成了十五个模块审查 Agent 对每一行代码都提出了至少一条意见开发 Agent 在两者之间疲于奔命。两天结束游戏连个能跑的 Demo 都没有。那天晚上我复盘了一下架构师和审查 Agent 理论上能提升代码质量但实际带来的收益远远抵不上它们消耗的时间和注意力。更关键的是它们引入的复杂度让我失去了对项目的掌控感。我本来是想用 AI 加速开发结果变成了伺候三个 AI 互相配合我自己反而成了瓶颈。第二天我把架构师和审查 Agent 的提示词全删了只保留一个开发 Agent重新开始。神奇的是项目进度反而快了很多。那个塔防游戏的核心玩法单 Agent 模式下一天就跑通了。5.2 单 Agent 模式下的质量保障手段砍掉两个角色不代表放弃质量。我摸索出了一套单 Agent 模式下的质量保障方法核心思路是把质量检查从“独立环节”变成“开发环节的一部分”。具体做法是在开发 Agent 的提示词里加入质量要求让它在写代码的同时就考虑质量问题。比如我会在提示词里写“写代码时请遵循以下规则所有函数必须有明确的输入输出类型状态变更必须集中管理每写完一个模块在代码末尾用注释列出该模块对外暴露的接口。”这样开发 Agent 在写代码时就会主动遵守这些规则而不是等审查 Agent 来挑毛病。另一个手段是阶段性人工检查。我不再让 AI 审查 AI而是自己每隔一段时间检查一次代码。检查的重点不是细节问题而是整体结构是否合理、模块划分是否清晰、有没有明显的设计缺陷。人工检查的频率不用很高大概每完成一个功能模块检查一次就行。这样既能及时发现问题又不会陷入审查循环。5.3 用“约束前置”替代“事后审查”我后来总结出一个原则约束前置比事后审查有效得多。与其让审查 Agent 事后挑毛病不如在开发 Agent 的提示词里就把约束写清楚。比如接口一致性问题我不再依赖架构师定义接口而是直接在开发提示词里规定“所有模块间的通信必须通过一个统一的 EventBus 类EventBus 的接口定义如下……你在实现任何模块时如果需要与其他模块通信必须使用 EventBus不得直接引用其他模块的内部函数。”这样开发 Agent 在写代码时就会遵守这个约束根本不会产生接口不一致的问题。再比如代码风格问题我会在提示词里规定命名规范、注释规范、错误处理规范。这些规范写一次就行后续所有开发任务都自动遵守。这比让审查 Agent 每次重新检查一遍高效得多。5.4 架构决策由我自己来做砍掉架构师 Agent 之后架构决策由我自己来做。这听起来好像增加了我的工作量但实际上并没有。因为架构师 Agent 给出的架构文档我本来就要花大量时间理解和修正与其这样不如我直接花十分钟想清楚模块怎么划分、接口怎么定义然后把这个决策写进开发 Agent 的提示词里。我自己做架构决策的好处是我对游戏的整体设计有完整的掌控不会出现架构师 Agent 那种“设计出来的架构跟实际需求脱节”的问题。而且我可以在开发过程中随时调整架构不需要同步给另一个 Agent。这种灵活性在快速迭代的游戏开发中非常重要。6. 多 Agent 协作在游戏开发中的适用边界6.1 什么情况下多 Agent 确实有用说了这么多多 Agent 的坑但我也得承认多 Agent 协作在某些场景下确实有价值。根据我的经验以下几种情况适合引入多 Agent任务高度独立且可并行比如同时开发多个互不依赖的小游戏每个游戏一个 Agent互不干扰。需要不同专业视角比如一个 Agent 负责游戏逻辑一个 Agent 负责 UI 布局两者的知识领域差异很大分开处理反而更清晰。流程标准化程度高比如批量生成游戏关卡数据每个关卡的处理流程完全一致可以用多个 Agent 并行处理。但游戏开发的核心玩法实现恰恰不属于以上任何一种情况。核心玩法开发是高度迭代、高度耦合、需要频繁调整的多 Agent 协作的协调成本远大于收益。6.2 协调成本与收益的量化对比我后来做了一个简单的量化对比。假设一个游戏项目有 10 个功能模块每个模块平均需要 3 轮迭代。单 Agent 模式下每轮迭代的成本是写代码10 分钟 自测5 分钟 15 分钟。10 个模块 3 轮迭代总成本约 450 分钟。多 Agent 模式下每轮迭代的成本是架构师更新文档5 分钟 开发写代码10 分钟 审查5 分钟 开发修改5 分钟 25 分钟。10 个模块 3 轮迭代总成本约 750 分钟。而且这还没算上架构文档同步、审查意见沟通、踢皮球循环等额外开销。实际跑下来多 Agent 模式的总耗时大概是单 Agent 模式的 2 到 3 倍。而代码质量的提升根据我的主观评估大概只有 10% 到 20%。这个投入产出比显然不划算。6.3 我的最终工作流经过这一轮折腾我最终稳定下来的工作流是这样的需求分析阶段我自己想清楚游戏的核心玩法、模块划分、关键数据结构。这个阶段不借助 AI因为 AI 对游戏设计的理解往往过于理论化。开发阶段单 Agent 模式一个对话窗口从头写到尾。提示词里包含接口约束、命名规范、错误处理规范。阶段性检查每完成一个功能模块我自己跑一遍检查功能是否正常、代码结构是否合理。问题修复发现问题后把相关代码和问题描述一起喂给开发 Agent让它修复。修复时要求它只改相关部分不要动其他代码。收尾阶段所有功能完成后让开发 Agent 做一次全局检查重点是接口一致性和未处理的边界情况。这套工作流比多 Agent 模式简单得多但实际效率高很多。我现在做一个中等复杂度的游戏 Demo大概两三天就能跑通核心玩法一周左右能出一个可玩的版本。7. 常见问题与排查技巧实录7.1 AI 写游戏代码的典型问题速查表问题现象可能原因排查方法解决思路模块间接口对不上缺少统一的接口定义检查各模块的函数签名是否一致在提示词中固定接口定义要求所有模块遵守代码越写越乱上下文漂移AI 忘了之前的约定对比早期代码和最新代码的命名风格定期回顾关键约定在提示词中重复强调功能实现与预期不符需求描述有歧义让 AI 复述一遍它理解的需求用更具体的例子描述需求避免抽象词汇性能问题AI 默认使用低效实现检查循环、递归、频繁内存分配在提示词中明确性能要求如“避免每帧分配新对象”状态管理混乱状态分散在多个模块搜索所有状态变量的读写位置集中状态管理所有状态变更走统一入口7.2 提示词工程在游戏开发中的实操心得提示词写得好不好直接决定了 AI 写代码的质量。我踩了无数坑之后总结出几条实用心得。第一条是用具体例子代替抽象描述。不要说“实现一个流畅的移动系统”而要说“实现一个移动系统玩家按下方向键后角色以每秒 200 像素的速度移动加速度为每秒 1000 像素松开按键后减速度为每秒 1500 像素”。具体的数字和条件能让 AI 准确理解你的意图。第二条是把约束写成清单。与其在提示词里长篇大论地解释为什么要这样做不如直接列一个约束清单“1. 所有类名用 PascalCase2. 所有函数名用 camelCase3. 所有常量用 UPPER_SNAKE_CASE4. 每个函数不超过 30 行5. 每个文件不超过 300 行。”AI 对清单的执行力很强对抽象原则的理解力很弱。第三条是要求 AI 先复述再动手。在提示词末尾加一句“在开始写代码之前请先用三句话总结你对这个任务的理解”。这样你能快速判断 AI 有没有理解偏避免它写了一堆代码之后你才发现方向错了。7.3 代码质量的人工兜底策略AI 写的代码最终质量还是得靠人来兜底。我的策略是分层检查第一层功能检查。跑一遍游戏看功能是否正常。这一层最直观也最容易发现问题。第二层结构检查。打开代码文件快速浏览一遍看模块划分是否清晰、命名是否一致、有没有明显的重复代码。第三层关键路径检查。找到游戏的核心循环比如每帧执行的 update 和 render仔细读一遍确保没有性能问题和逻辑错误。第四层边界检查。手动触发一些边界情况比如玩家死亡、关卡切换、暂停恢复看有没有崩溃或状态异常。这四层检查不需要每次都做全套根据项目阶段和代码变更范围灵活选择。比如小改动只需要做第一层大重构就需要做全套。7.4 什么时候该放弃 AI 辅助自己动手有些情况下AI 辅助反而会拖慢进度这时候应该果断自己动手。我的判断标准是逻辑特别复杂且需要精确控制比如复杂的寻路算法、物理模拟、状态机AI 经常写出看似正确但实际有微妙 Bug 的代码调试成本比手写还高。需要频繁试错和调整比如游戏手感调优、数值平衡这些需要快速迭代和主观判断AI 的反馈循环太慢。涉及外部资源集成比如接入第三方 SDK、处理特定平台的 APIAI 对这些具体环境的了解往往不够准确容易给出过时的方案。这些情况下我自己写代码可能只要半小时让 AI 写再调试可能要两小时。时间账算清楚之后选择就很明确了。8. 我现在的 AI 游戏开发工作流8.1 从需求到 Demo 的完整流程我现在的工作流已经稳定下来了从需求到 Demo 大概分四个阶段。第一阶段设计文档。我自己写一份简短的设计文档包括核心玩法、操作方式、胜负条件、关键数据结构。这份文档不用很详细但必须把核心循环说清楚。比如“玩家控制角色在网格上移动每移动一步敌人也移动一步玩家目标是到达出口敌人目标是拦截玩家”。第二阶段骨架搭建。把设计文档喂给开发 Agent让它生成项目骨架包括主循环、状态管理、输入处理、渲染框架。这个阶段不实现具体玩法只搭架子。骨架跑通之后我会仔细检查一遍确保结构合理。第三阶段功能迭代。逐个实现游戏功能每个功能一个独立的对话轮次。每轮开始前我会把相关的接口定义和约束条件重新贴一遍避免 AI 忘记。每轮结束后我跑一遍游戏确认功能正常再进入下一轮。第四阶段打磨收尾。所有功能完成后让 AI 做一次全局检查重点是接口一致性和边界情况。然后我自己跑几轮完整游戏记录问题逐个修复。8.2 每个阶段的关键检查点每个阶段都有几个必须检查的关键点漏掉任何一个都可能导致后期返工。设计文档阶段的关键检查点是核心循环是否闭环。也就是说玩家操作、游戏状态更新、画面反馈这三个环节必须形成完整循环。如果设计文档里只写了“玩家可以移动”没写“移动后画面如何更新”那开发 Agent 很可能写出一个移动了但画面不刷新的版本。骨架搭建阶段的关键检查点是主循环是否稳定。我会让游戏空跑几分钟看帧率是否稳定、内存是否持续增长、有没有报错。骨架不稳后面所有功能都是白搭。功能迭代阶段的关键检查点是接口是否一致。每完成一个功能我会检查它对外暴露的接口是否跟设计文档一致。不一致的地方要么改代码要么改设计文档绝不能放着不管。打磨收尾阶段的关键检查点是边界情况是否覆盖。我会列一个边界情况清单比如“玩家在出口处死亡”、“敌人数量为零”、“同时按下多个按键”逐个测试。8.3 工具链与项目结构建议工具链方面我现在的配置很简单一个代码编辑器、一个 AI 对话窗口、一个版本控制工具。版本控制很重要每次 AI 完成一个功能模块就提交一次这样出问题可以快速回滚。项目结构我建议按功能划分目录而不是按类型划分。比如game/ player/ player.py player_input.py player_state.py enemy/ enemy.py enemy_ai.py level/ level.py level_loader.py core/ game_loop.py event_bus.py state_manager.py这种结构的好处是每个功能模块的代码都集中在一起AI 在实现某个功能时只需要关注对应的目录上下文更清晰。而且功能模块之间的依赖关系一目了然方便检查接口一致性。8.4 后续可以继续优化的方向这套工作流还有不少可以优化的地方。我最近在尝试的一个方向是用测试用例替代人工检查。具体做法是让 AI 在实现功能的同时生成对应的测试用例我只需要跑测试就能知道功能是否正常。这样能大幅减少人工检查的时间。另一个方向是建立提示词模板库。把常用的提示词片段比如接口定义模板、错误处理模板、性能优化模板整理成模板库每次开发新功能时直接组合使用减少重复写提示词的时间。还有一个方向是自动化代码结构检查。写一个简单的脚本检查代码文件的命名规范、函数长度、模块依赖关系不符合规范的自动报警。这样能把一部分结构检查的工作交给工具我只需要关注更高级的设计问题。这些优化方向我还在摸索中等跑通之后再来分享。如果你也在用 AI 做游戏欢迎交流你的工作流和踩坑经验。