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 依赖 BB 不依赖 A 4. 建议的实现顺序 约束不输出任何实现代码接口描述用伪代码即可我特意强调“不输出实现代码”是因为早期版本它总忍不住把方法体也写了导致架构和实现混在一起后面写代码的 Agent 反而被带偏。3.2 一次真实的架构输出记录我拿“塔防游戏核心循环”做测试架构师给出的模块清单大致是模块职责依赖GameMap管理格子、路径点无Enemy敌人属性与移动GameMapTower塔的属性与攻击EnemyWaveManager波次生成与节奏EnemyEconomy金币收支无EventBus全局事件分发无UIManager界面刷新Economy, WaveManager接口部分它写了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. 常见问题速查问题可能原因处理方式审查员大量误报提示词太宽泛检查项过多收窄到 2-3 类硬伤其余不管写码员反复改不对审查意见太模糊要求审查输出具体行号和改法流程跑不完没有轮次和 token 上限设硬性退出条件架构文档和代码对不上文档一次性、不更新要么定期更新要么直接弃用测试全绿但功能残测试用例覆盖不足人工补边界用例别全信 AI整体效率反而下降角色过多、协调成本高砍到单 Agent 人工复核10. 最后几句掏心窝的话这套“架构师 审查员 测试驱动”的配置我前后折腾了三周最后全砍。说不心疼是假的毕竟投入了不少时间调提示词、搭流程。但砍完之后我反而轻松了因为我又能专注在“把游戏做出来”这件事上而不是“维护一套 AI 团队”上。我现在的一个基本判断是AI 做游戏开发现阶段最大的价值在“单点提效”不在“流程自动化”。让 AI 帮你写一个具体函数、解释一段报错、生成一个测试用例这些它做得很好。但让它扮演一个团队、走一套流程它还没到那个火候。多 AI 协作不是不能做而是要等项目复杂度和团队规模真的到了那个份上否则就是给自己找活干。如果你正在搭类似的工作流我的建议就一句先问自己“这个角色砍掉会怎样”如果答案是“好像也没差”那就砍掉。我当初要是早点问这个问题能省下三周时间。