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

1. 从“给 AI 配团队”到“全砍掉”的完整心路

去年有一阵子，我在用 AI 辅助做一款小体量的网页游戏。项目不大，但架不住我贪心——既然大模型能写代码，那我干脆给它配一套完整的“研发团队”不就行了？于是我在工作流里塞进了两个角色：一个架构师 Agent，负责在写代码之前先出模块划分和接口定义；一个代码审查 Agent，负责在代码生成之后逐行挑毛病、提修改意见。听起来很美好对吧？一个负责“想清楚”，一个负责“把好关”，中间那个写代码的 AI 只管埋头干活。

结果这套东西跑了大概三周，我把它全砍了。不是因为它不工作，而是因为它“工作得太认真了”，认真到把整个开发节奏拖垮。这篇文章我想把这段踩坑经历完整拆开讲：我当初为什么这么设计、每个 Agent 具体怎么配的、跑起来之后到底出了什么问题、最后我是怎么一步步做减法的。如果你也在用 AI 做游戏开发，或者正在搭多 Agent 协作的编程工作流，这篇应该能帮你少走一段弯路。

先说清楚适用人群：这篇适合已经用过大模型写代码、想进一步搞多 Agent 协作的开发者；也适合做微信小程序游戏、Godot 或 Unity 独立开发、想用 AI 提效但还没找到节奏的朋友。如果你连单 Agent 写代码都还没跑顺，建议先跳过架构师那部分，直接看代码审查踩的坑，那个更普适。

核心关键词我先摆出来：AI 游戏开发、代码审查、架构师 Agent、测试驱动、多 AI 协作。这几个词贯穿全文，后面每一节都会围绕它们展开。

2. 我当初为什么要给 AI 配“架构师”和“审查员”

2.1 单 Agent 写代码的三个真实痛点

最开始我是纯单 Agent 流：把需求描述丢给大模型，让它直接吐代码，我复制粘贴进项目里跑。跑了大概两周，暴露出三个让我很难受的问题。

第一个是结构漂移。同一个游戏，第一次让它写“玩家移动”，它给你搞了个PlayerController类；第二次让它加“跳跃”，它又新建了一个PlayerMovement，两个类里各有一套速度变量，互相打架。因为每次对话它都是“从零思考”，没有全局视角，模块边界全靠它当场发挥。

第二个是隐性 bug 反复出现。比如空引用、边界条件没处理、异步回调里改了已经销毁的对象。这些问题单看代码不明显，跑起来才炸，而且同一个坑它能在不同文件里踩好几次。

第三个是需求理解偏差累积。我说“敌人巡逻”，它理解成直线来回走；我说“加个视野”，它给我做了个全屏探测。偏差一旦写进代码，后面所有依赖它的逻辑都跟着歪。

这三个痛点让我产生了一个很自然的想法：既然人类团队靠“架构师定方案 + 审查员把关”来解决这些问题，那我给 AI 也配一套不就行了？

2.2 架构师 Agent 的职责设想

我当时的设想是这样的：架构师 Agent 不写具体业务代码，它只做三件事。

• 拆模块：把“做一个塔防游戏”拆成地图、路径、塔、敌人、波次、经济、UI 七个模块，明确每个模块的职责边界。
• 定接口：规定模块之间怎么通信，比如敌人死亡时通过事件总线通知经济系统加钱，而不是直接互相引用。
• 排依赖顺序：先写哪个后写哪个，避免循环依赖。

我给它喂的提示词大意是：“你是一名资深游戏架构师，请针对以下需求输出模块划分、每个模块的公开接口、以及模块间的依赖关系图（用文字描述），不要写实现代码。”这个思路本身没问题，问题出在后面——它输出的东西太“重”了。

2.3 代码审查 Agent 的职责设想

审查员 Agent 的设想更直接：每次代码生成完，先不落地，丢给审查员过一遍。审查员按几个维度打分并提修改意见：

• 命名规范是否统一
• 是否有空引用风险
• 边界条件是否处理
• 是否违反架构师定的接口约定
• 是否有性能隐患（比如每帧 new 对象）

我甚至给它定了个“不通过就打回重写”的机制：审查员输出问题列表，写代码的 Agent 根据列表改，改完再送审，最多循环三轮。听起来是不是特别像正规军？我当时也这么觉得。

2.4 测试驱动这个念头是怎么加进来的

后来我又看到“测试驱动开发”这个词，心想既然都配团队了，那再加个测试环节呗。于是流程变成：架构师出方案 → 写代码 → 写测试 → 跑测试 → 审查员审查 → 通过才合并。一个需求走完这条流水线，中间要经过四个 AI 角色。

现在回头看，这就是典型的“过度工程”。我把一个本该轻量的个人开发流程，硬生生搭成了一个需要协调四个角色的“虚拟公司”。而虚拟公司的沟通成本，最后全压在我一个人身上。

3. 架构师 Agent 具体怎么配、怎么跑

3.1 提示词设计与输出格式约束

架构师 Agent 的提示词我改过好几版，最后稳定下来的结构是这样的：

角色：资深游戏架构师，擅长小团队快速迭代 任务：针对需求输出架构方案 输出格式： 1. 模块清单（模块名 + 一句话职责） 2. 每个模块的公开接口（方法名 + 参数 + 返回值 + 一句话说明） 3. 模块依赖关系（A 依赖 B，B 不依赖 A） 4. 建议的实现顺序 约束：不输出任何实现代码，接口描述用伪代码即可

我特意强调“不输出实现代码”，是因为早期版本它总忍不住把方法体也写了，导致架构和实现混在一起，后面写代码的 Agent 反而被带偏。

3.2 一次真实的架构输出记录

我拿“塔防游戏核心循环”做测试，架构师给出的模块清单大致是：

接口部分它写了Enemy.takeDamage(amount)、Tower.findTarget()、EventBus.emit(event, payload)这些。单看这份输出，质量其实不差，甚至比我随手写的还规整。

3.3 架构师带来的第一个好处与第一个坑

好处很直接：模块边界清晰了。以前写代码的 Agent 东一榔头西一棒子，现在它有了明确的“施工图”，生成的文件结构确实整齐了很多，命名也统一了。

但第一个坑马上来了：架构师定的接口太理想化。比如它规定Tower依赖Enemy，但实际实现时塔需要知道敌人的位置、血量、是否在射程内，这些细节架构阶段根本没法定死。写代码的 Agent 一看接口对不上，就开始“自作主张”扩展接口，扩展完又和架构文档不一致。于是我要么回去让架构师改方案，要么放任代码偏离文档——两条路都很烦。

3.4 架构文档和实际代码的“对不上”问题

最要命的是，架构文档是一次性快照。游戏开发过程中需求一直在变，今天加个“减速塔”，明天加个“护盾敌人”，每次变动架构文档就过时一点。我试过让架构师跟着更新，但它更新一次要重新读一遍全部代码，token 消耗巨大，而且更新出来的版本和上一版经常自相矛盾。

到第二周，我已经不怎么打开架构文档了。它变成了一个“写完就没人看”的摆设，而写代码的 Agent 依然按自己的理解在扩展。架构师这个角色，实际上名存实亡。

4. 代码审查 Agent 的配置与真实表现

4.1 审查维度的提示词拆解

审查员 Agent 的提示词我写得更细，因为审查这件事本身就需要明确的检查项：

角色：严格的代码审查员 检查项： 1. 空引用与未初始化变量 2. 数组/字典越界 3. 异步回调中的对象生命周期 4. 命名一致性（驼峰/下划线） 5. 是否违反架构接口约定 6. 每帧是否产生垃圾对象 输出格式：问题列表，每条包含【严重级别】【文件行号】【问题描述】【修改建议】

4.2 审查员抓到的真问题和假问题

跑起来之后，审查员确实抓到过真问题。有一次它指出“敌人死亡后仍被波次管理器引用，可能导致内存泄漏”，这个我人工看代码时真没注意到，算是实打实的价值。

但更多时候它在报假问题。比如它说“for循环里创建了临时对象，建议对象池化”，可那是个初始化时只跑一次的循环，根本不在每帧里。还有一次它坚持认为某个变量“可能为空”，但那个变量在上一行刚被赋值，它没读到上下文。这类误报大概占了它输出的一半以上。

4.3 三轮打回重写机制的实际代价

我设的“最多三轮打回”机制，实际跑下来是这样的：第一轮审查报 8 个问题，其中 3 个真 5 个假；写代码的 Agent 老老实实按 8 条全改了，结果改出 2 个新 bug；第二轮审查又报 6 个问题……一个本来 10 分钟能搞定的功能，在审查循环里耗了快一个小时。

更糟的是，写代码的 Agent 会为了“讨好”审查员而过度修改。审查员说“建议加个空检查”，它就把每个变量都加一遍空检查，代码变得又臭又长。审查员说“命名建议更语义化”，它就把hp改成currentHealthPoints，全项目跟着改一遍。

4.4 审查员和写码员的“互相甩锅”

跑到后面还出现了一种诡异现象：审查员报的问题，写码员改完，审查员又说“你改的方式引入了新问题”，写码员再改，审查员再挑……两个 Agent 陷入了一种“礼貌地互相否定”的循环。我盯着屏幕看它们来回，突然意识到：我在用两个 AI 模拟一场没有终点的会议。而这场会议的每一个来回，都在烧我的时间和 token。

5. 测试驱动环节是怎么把流程彻底拖垮的

5.1 让 AI 写测试的初衷

加测试环节的初衷很朴素：审查员靠“看”代码找问题，不如让测试靠“跑”代码找问题。逻辑上测试更可靠，因为它是可执行的验证。我让写码员在实现功能的同时写单元测试，然后跑一遍，绿了才送审。

5.2 测试用例本身的质量问题

问题是，AI 写的测试经常是“为了通过而写”。比如它测Enemy.takeDamage，只测了“血量减少”这一条，没测“血量减到负数时是否归零”“死亡后是否触发事件”。测试全绿，但功能其实是残的。我后来要求它“覆盖边界条件”，它又开始写一堆重复的、意义不大的用例，测试文件比业务代码还长。

5.3 测试、审查、重写三者叠加的时间账

我记过一次完整流程的耗时。一个“添加减速塔”的需求：

• 架构师更新方案：约 3 分钟
• 写代码：约 5 分钟
• 写测试：约 4 分钟
• 跑测试 + 修失败：约 6 分钟
• 审查 + 修改：约 15 分钟
• 我人工复核：约 5 分钟

合计接近 40 分钟。而如果我自己直接写这个功能，大概 15 分钟。也就是说，这套“豪华团队”让我的效率降低了六成以上。这个账算清楚的那一刻，我就知道这套东西该砍了。

5.4 一个具体案例：减速塔功能的完整流水线记录

减速塔这个案例特别典型。架构师说“Tower 增加 slowFactor 属性，Enemy 增加 applySlow 方法”。写码员实现时发现，减速要作用在敌人移动逻辑里，而移动逻辑在 Enemy 内部，于是它改了 Enemy 的移动方法。审查员一看，说“你违反了架构约定，Enemy 不应该被 Tower 直接修改状态”，要求改成事件驱动。写码员改成事件驱动，测试又挂了，因为事件是异步的，测试里没等事件触发就断言了。修测试、再审查、再改……一个减速效果，折腾了四轮。

6. 我为什么最终把架构师和审查员全砍了

6.1 沟通成本大于收益的临界点

砍掉的直接原因是沟通成本超过了收益。多 Agent 协作的本质是“用 AI 之间的对话替代我脑子里的思考”。但 AI 之间的对话是有损耗的：信息在传递中失真、上下文在多次调用中丢失、每个 Agent 都只看到局部。当角色超过两个，损耗就指数级上升。我算过，四个角色的流程里，真正用于“产生价值”的时间不到三成，剩下七成都在协调。

6.2 小体量项目根本不需要重型流程

更根本的原因是项目体量不匹配。我做的是一款小游戏，代码量撑死几千行，一个人一周能写完核心玩法。这种体量根本不需要架构师——模块划分在我脑子里就是清楚的。也不需要正式审查——跑一遍游戏，哪里不对一眼就看出来。我犯的错是把大厂的重型流程套在了个人小项目上，而 AI 只是把这个错误放大了。

6.3 砍掉之后我保留了什么

全砍不代表回到原始状态。我保留了三样东西：

• 一份轻量的模块清单：不再是架构师 Agent 生成的长文档，而是我自己维护的十几行 Markdown，写清楚每个文件干什么。
• 一个精简的审查提示词：只查“空引用、越界、生命周期”三类硬伤，其他一律不管，而且只在我主动要求时才跑。
• 测试只写核心逻辑：经济计算、伤害公式这种容易算错的写测试，UI 和表现层不写。

6.4 单 Agent + 人工把关的新工作流

现在我的流程简单到有点“寒酸”：一个写代码的 Agent，我给它清晰的单文件任务描述，它生成，我跑，我改。遇到复杂逻辑我让它先讲思路再写。审查靠我自己扫一眼加跑一遍。效率反而回到了正常水平，而且我对代码的掌控感强了很多——因为每一行都是我“过手”的，不是四个 AI 传话传出来的。

7. 多 AI 协作做游戏开发，什么场景才值得上

7.1 适合上多 Agent 的三个信号

不是说多 Agent 一无是处，它有三个明确的适用信号：

• 项目体量大到一个人记不住：比如几万行代码、十几个系统，这时候架构文档确实能帮上忙。
• 团队多人协作：需要统一接口约定，AI 审查能减少风格冲突。
• 重复性审查需求高：比如每天大量 PR 要过，AI 初审能省人力。

7.2 不适合的典型场景

反过来，以下场景别折腾：

• 个人独立开发的小游戏
• 需求还在快速变化的原型阶段
• 你自己对代码结构还没想清楚的时候

因为多 Agent 的前提是“你已经有清晰的流程”，它只是把流程自动化。如果你自己都没想清楚，AI 只会把混乱放大。

7.3 如果非要上，怎么控制成本

如果你确实想试，我的建议是从两个角色起步，且必须有一个是“只读”的。比如只加一个审查员，且审查员只输出建议、不触发自动重写。这样你能先观察它的误报率，再决定要不要让它参与决策。另外，给每个 Agent 设硬性 token 上限和轮次上限，超过就停，别让它无限循环。

7.4 我的最终建议：先跑通单 Agent，再谈协作

最重要的一条：先把单 Agent 写代码跑顺。什么叫跑顺？你能用清晰的提示词让它稳定产出可运行、结构合理的代码，你能快速判断它哪里写错了并修正。这个基本功没练好，加再多 Agent 都是空中楼阁。我当初就是跳过了这一步，直接上多 Agent，结果把基本功的欠缺掩盖在了“流程复杂”的表象下。

8. 踩坑之后沉淀下来的几条实操经验

8.1 提示词要“窄”，不要“全”

我早期喜欢写“全能型”提示词，恨不得一个 Agent 干所有事。后来发现，提示词越窄，输出越稳。审查员就只查三类硬伤，别让它管命名和风格；写码员就只写一个文件，别让它顺手重构别的模块。窄提示词的误报率和跑偏率都低得多。

8.2 每个 Agent 都要有“退出条件”

多 Agent 最大的坑是无限循环。审查员报问题、写码员改、审查员再报……必须给每个环节设退出条件：审查最多一轮、修改最多两次、token 超限就停。没有退出条件的多 Agent 流程，就是个烧钱的无底洞。

8.3 人工复核环节绝对不能省

不管 AI 审查得多认真，最后过一遍的必须是人。我吃过亏：审查员说“通过”的代码，跑起来照样崩。AI 审查只能覆盖它“见过”的问题模式，没见过的一律漏掉。人工复核不是不信任 AI，而是 AI 的能力边界就在那里。

8.4 记录每次流程的耗时，用数据做决策

我强烈建议你记录每次 AI 流程的耗时。不用很精确，手机备忘录记个大概就行。记上一周你就会发现，哪些环节是真提效，哪些环节纯粹在自嗨。我砍掉架构师和审查员，就是靠这份耗时记录做的决定，而不是凭感觉。

8.5 工具选型：别被“多 Agent 框架”带节奏

市面上有不少多 Agent 协作的框架和工具，宣传得很热闹。我的建议是：先用最朴素的方式手动串起来，比如就用几个提示词模板加复制粘贴。等你手动跑顺了，确实觉得某个环节值得自动化，再考虑上框架。一上来就上框架，你连问题出在哪个 Agent 都定位不了。

9. 常见问题速查

10. 最后几句掏心窝的话

这套“架构师 + 审查员 + 测试驱动”的配置，我前后折腾了三周，最后全砍。说不心疼是假的，毕竟投入了不少时间调提示词、搭流程。但砍完之后我反而轻松了，因为我又能专注在“把游戏做出来”这件事上，而不是“维护一套 AI 团队”上。

我现在的一个基本判断是：AI 做游戏开发，现阶段最大的价值在“单点提效”，不在“流程自动化”。让 AI 帮你写一个具体函数、解释一段报错、生成一个测试用例，这些它做得很好。但让它扮演一个团队、走一套流程，它还没到那个火候。多 AI 协作不是不能做，而是要等项目复杂度和团队规模真的到了那个份上，否则就是给自己找活干。

如果你正在搭类似的工作流，我的建议就一句：先问自己“这个角色砍掉会怎样”，如果答案是“好像也没差”，那就砍掉。我当初要是早点问这个问题，能省下三周时间。