1. 从“给AI配团队”到“全砍掉”的折腾始末去年年底我开始用AI辅助做一款小体量的2D网页游戏技术栈选的是Godot加TypeScript导出Web美术资源靠AI生成代码部分则交给大模型来写。一开始我的想法很朴素既然AI能写代码那我给它配一套完整的“开发团队”不就行了于是我在工作流里塞进了两个角色——一个“架构师”负责拆解模块、定义接口一个“代码审查”负责在每次生成后挑毛病、提修改意见。听起来很美好对吧结果跑了不到三周我把这两个角色全砍了。这篇文章就是把这中间踩过的坑、试过的方案、以及最后为什么选择“裸奔”式单Agent开发完整地摊开来讲。如果你也在用AI做游戏开发或者正在折腾AI Agent工作流尤其是涉及代码生成、测试驱动、多角色协作这些环节那这篇内容应该能帮你省下不少试错时间。我不会讲什么“AI将改变游戏开发”这种大话只聊具体操作怎么配的、哪里崩的、怎么改的、最后为什么放弃。全文基于我自己的项目实践涉及Godot、TypeScript、DeepSeek和Claude的混合使用以及一套自建的提示词流水线。先说结论多角色协作在AI游戏开发里不是不能做而是成本收益比在中小项目里极不划算。架构师角色容易过度设计代码审查角色容易陷入“为审查而审查”的循环两者叠加后我每天花在协调AI角色上的时间比写游戏逻辑还多。砍掉之后开发效率反而提升了将近一倍。下面我从头拆解这个过程。1.1 为什么一开始会想到配“架构师”和“代码审查”我最初的项目是一个类似《吸血鬼幸存者》的割草类网页游戏核心循环很简单玩家移动、自动攻击、敌人波次刷新、经验升级、道具掉落。按传统开发思路这种体量一个人两周就能撸完。但我想试试AI能不能把速度再压一压于是设计了一套多Agent流水线。架构师角色的职责是接收我的自然语言需求输出模块划分、接口定义、数据结构、以及每个文件的职责说明。代码审查角色的职责是接收架构师的定义和AI生成的代码检查是否符合接口、是否有边界问题、是否违反SOLID原则然后给出修改建议。我当时的设想是这两个角色能把AI生成的代码质量拉到“可维护”的水平避免后期改不动。这个想法来源于我过去在传统软件团队里的经验有架构师把关代码不会乱有代码审查兜底bug不会多。但问题在于AI角色和人类角色有本质区别。人类架构师会考虑团队能力、工期、技术债务的取舍而AI架构师只会按照“最佳实践”往复杂里设计。人类审查者会判断哪些问题值得改、哪些可以放过而AI审查者会事无巨细地挑刺导致无限循环。1.2 第一版工作流的具体配置我用的工具链是这样的DeepSeek负责架构设计和代码审查因为它长上下文便宜适合塞大量代码Claude负责具体代码生成因为它在Godot的GDScript和TypeScript上表现更稳。中间用了一个简单的Node.js脚本做消息路由把架构师的输出格式化后传给代码生成再把生成的代码传给审查角色。提示词方面架构师角色的系统提示词大概是这样写的“你是一个资深游戏架构师负责将需求拆解为模块定义每个模块的接口、数据结构和依赖关系。输出格式为JSON包含modules数组每个模块有name、responsibility、interfaces、dependencies字段。”代码审查角色的提示词则是“你是一个严格的代码审查者检查代码是否符合架构定义、是否有潜在bug、是否违反单一职责原则。输出问题列表每个问题包含severity、location、suggestion。”第一周跑下来架构师输出了7个模块、23个接口、4层继承关系。我当时还觉得挺专业现在回头看一个割草游戏根本不需要这么多抽象层。但当时我被“专业感”迷惑了直接让代码生成角色按这个架构去写。结果就是光是定义接口和类型就花了三天真正写游戏逻辑的时间被压缩得所剩无几。2. 架构师角色为什么成了“过度设计发动机”2.1 AI架构师的“最佳实践”陷阱AI架构师有一个很明显的倾向它会把你给的需求当成一个“企业级系统”来设计。我输入的需求是“玩家自动攻击最近的敌人”它输出的接口定义里包含了IAttackStrategy、ITargetSelector、IDamageCalculator、IAttackCooldownManager四个接口还建议用策略模式来支持未来可能出现的多种攻击方式。问题是我的游戏里只有一种攻击方式而且短期内不打算扩展。这种过度设计的根源在于AI的训练数据里充满了“可扩展、可维护、高内聚低耦合”的教条但它没有“工期”和“实际需求”的概念。人类架构师会问“你确定未来会加多种攻击方式吗不确定的话先写死。”AI架构师不会问它默认所有东西都要可扩展。结果就是我花了大量时间在实现这些抽象接口上而游戏的核心玩法反而没时间打磨。更麻烦的是一旦架构定义好了代码生成角色就会严格遵循。即使我后来发现某个接口根本没必要想删掉代码审查角色又会跳出来说“删除接口会导致架构不一致”。整个系统陷入了一种“为了架构而架构”的自我循环。2.2 接口定义与游戏逻辑的脱节游戏开发和普通应用开发有一个很大的区别游戏逻辑高度依赖实时反馈和手感调优。一个攻击间隔是0.3秒还是0.35秒手感完全不同。但架构师角色定义的是“AttackCooldownManager.shouldAttack(currentTime)”它不关心具体数值只关心接口签名。代码生成角色拿到这个接口后会写一个通用的冷却管理器然后我需要在一个配置文件里调数值。听起来没问题对吧但实际操作中每次调数值我都要改配置文件、重新导出、在浏览器里测试。而如果直接写死在攻击逻辑里我改一行代码就能立刻看到效果。架构师带来的“配置化”优势在这个体量的项目里完全被“调参链路变长”的劣势抵消了。我后来统计了一下光是攻击冷却这一个功能因为要适配架构师的接口我多写了大约120行胶水代码包括配置加载、类型定义、默认值处理、边界检查。而这些代码在砍掉架构师之后全部被删掉了攻击逻辑回归到一个简单的if (now - lastAttack 0.3)判断。2.3 架构变更时的连锁反应第三周的时候我决定把敌人的移动方式从“直线追踪”改成“绕障碍物寻路”。这是一个很常见的需求变更。但在有架构师的系统里这个变更触发了连锁反应架构师需要重新定义IMovementStrategy接口代码生成需要重写移动模块代码审查需要检查新模块是否符合架构然后我发现新的接口和旧的ITargetSelector有冲突又得回去改架构。整个变更花了整整两天而如果是我自己写代码这个改动大概两个小时就能搞定。AI架构师把“变更成本”放大了因为它强制所有模块都通过接口通信而接口一旦定义就很难改。人类架构师会权衡“这个接口未来会不会变”AI架构师则默认接口是稳定的变更时就要付出代价。注意如果你非要用AI架构师建议把它的输出限制在“模块列表职责说明”层面不要让它定义具体接口。接口定义交给代码生成角色在写代码时自然形成后期再重构。3. 代码审查角色如何拖垮开发节奏3.1 审查粒度过细导致的“修改-审查”死循环代码审查角色的本意是好的每次AI生成代码后让它检查一遍有问题就改。但实际跑起来是这样的代码生成角色写了一个敌人刷新逻辑审查角色说“第47行没有处理敌人数量为0的情况”代码生成角色改了审查角色又说“第52行的数组越界检查不够严谨”代码生成角色再改审查角色继续说“第58行的变量命名不符合驼峰规范”……一个简单的敌人刷新函数被审查了7轮才通过。每一轮都要调用一次大模型消耗token不说时间也全浪费在这种细枝末节的修改上。更关键的是很多被审查出来的问题在实际运行中根本不会发生。比如“敌人数量为0”的情况在我的游戏里敌人数量永远不会为0因为波次系统保证至少有一个敌人。但审查角色不知道这个业务规则它只会按照通用编程规范去挑刺。我后来算了一笔账代码审查角色平均每个函数要提出4.3个问题其中只有0.8个是真正需要修复的bug其余3.5个都是风格建议、防御性编程建议、或者“未来可能用到”的扩展建议。为了这0.8个真bug我要处理4.3个问题效率极低。3.2 审查角色与生成角色的“对抗模式”更微妙的问题是当审查角色和生成角色都是AI时它们会陷入一种“对抗模式”。生成角色写代码时会下意识地“防御”审查角色的挑刺比如加一堆没必要的空值检查、写冗长的注释来解释为什么这么写。而审查角色看到这些防御性代码后又会提出新的问题比如“注释过于冗长建议精简”。这种对抗导致代码风格越来越扭曲。我后来翻看那段时间生成的代码发现里面充斥着if (enemy ! null enemy ! undefined enemy.isAlive)这种三重检查而实际上在我的类型系统里enemy永远不可能是null或undefined。这些检查完全是审查角色逼出来的它们让代码变得臃肿且难以阅读。3.3 审查意见的“正确但无用”困境审查角色提出的意见单独看每一条都是“正确”的。比如“建议使用常量代替魔法数字”、“建议添加错误处理”、“建议拆分长函数”。但这些建议叠加在一起就会导致代码过度工程化。一个原本20行的函数按照审查意见改完后变成了80行拆成了5个小函数每个函数都有错误处理和日志记录。在游戏开发里这种“正确但无用”的审查意见尤其致命因为游戏逻辑往往需要紧凑和直接。一个攻击判定函数如果拆成“获取攻击者”、“获取目标”、“计算距离”、“判断是否在范围内”、“执行伤害”五个函数每个函数都加错误处理那性能开销和代码复杂度都会飙升。而实际上这个函数只需要三行代码就能搞定。我印象最深的一次是审查角色建议我给一个纯函数添加try-catch理由是“防止运行时错误”。但那个函数只是做简单的数学运算根本不可能抛异常。我按照建议加了try-catch后代码变成了这样function calculateDamage(base: number, multiplier: number): number { try { return base * multiplier; } catch (e) { console.error(Damage calculation failed, e); return 0; } }这段代码在审查角色眼里是“健壮”的但在我眼里是荒谬的。一个乘法运算加try-catch除了增加代码量和降低可读性之外没有任何实际作用。4. 砍掉两个角色后的“裸奔”方案与实测效果4.1 单Agent直出代码的配置调整砍掉架构师和代码审查之后我的工作流简化成了一个代码生成角色接收我的自然语言需求直接输出可运行的代码。提示词也大幅简化“你是一个Godot游戏开发者用TypeScript写游戏逻辑。代码要简洁直接不要过度抽象不要添加不必要的错误处理。优先保证可运行和可读性。”这个调整带来的变化是立竿见影的。以前一个敌人刷新功能要走“架构定义→代码生成→审查→修改→再审→再改”的流程现在直接“需求→代码→运行测试”。时间从平均45分钟压缩到了8分钟。而且生成的代码更符合我的预期因为它不再被架构师的接口和审查角色的规范束缚。我举一个具体的例子。割草游戏里有一个“经验值达到阈值后升级”的逻辑。在有架构师的版本里这个逻辑被拆成了IExperienceCalculator、ILevelUpHandler、IUpgradeSelector三个接口代码分散在四个文件里。砍掉之后我直接让AI写了一个checkLevelUp()函数20行代码搞定逻辑一目了然。4.2 测试驱动作为替代质量保障砍掉代码审查后我用测试驱动来兜底。具体做法是每次AI生成一个功能模块我立刻写一个简单的测试用例在浏览器控制台里跑一遍。比如敌人刷新功能我写一个测试脚本模拟10秒的游戏时间检查敌人数量是否在预期范围内、是否有报错、帧率是否稳定。这种“运行测试”比“代码审查”有效得多因为它检查的是实际行为而不是代码风格。AI审查角色会告诉你“这个变量名不好”但运行测试会告诉你“这个功能有bug”。在游戏开发里后者才是真正重要的。我用的测试框架很简单就是浏览器自带的console.assert加上一些手动写的检查函数。比如function testEnemySpawn() { const game new Game(); game.start(); for (let i 0; i 600; i) { game.update(1/60); } console.assert(game.enemies.length 0, Enemies should spawn); console.assert(game.enemies.length 200, Enemy count should be reasonable); console.log(Enemy spawn test passed); }这种测试虽然粗糙但能抓住90%的实际问题。而且写测试的时间远少于处理审查意见的时间。4.3 效率对比与质量评估我统计了砍掉两个角色前后各两周的数据。砍掉之前平均每天完成3.2个功能点其中约40%的时间花在协调AI角色上。砍掉之后平均每天完成6.7个功能点协调时间降到5%以下。代码质量方面砍掉之前因为过度抽象代码行数多了约60%但实际bug数量并没有显著减少。砍掉之后代码更紧凑bug主要集中在逻辑错误上反而更容易定位和修复。当然单Agent方案也有代价。最大的代价是架构一致性下降。因为没有架构师统一规划不同模块之间的接口风格可能不一致后期重构成本会高一些。但对于一个预计两周完成的小游戏来说这个代价完全可以接受。如果项目周期超过两个月或者团队有多人协作那可能还是需要某种形式的架构约束但不一定是AI架构师。实操心得砍掉角色后我保留了一个“轻量级架构笔记”就是自己在Markdown里记一下模块划分和关键接口。需要的时候手动喂给AI不需要的时候就不管。这比让AI维护一套完整的架构定义灵活得多。5. 多AI协作在游戏开发中的适用边界5.1 什么情况下多角色协作反而有效多AI角色协作不是完全没用但它有明确的适用边界。根据我的实践以下几种情况可能值得保留多角色大型项目的前期架构设计如果项目预计超过3个月模块超过20个那让AI架构师做一次性的架构规划是有价值的。但规划完之后就应该把架构文档固化不要让架构师角色持续参与每次代码生成。多人协作的接口对齐如果有多个人同时用AI写代码那需要一个统一的接口定义来避免冲突。这时候AI架构师可以作为“接口仲裁者”存在。安全关键或性能关键的代码审查如果游戏涉及网络同步、存档加密、支付逻辑等敏感模块那让AI审查角色专门检查这些模块是值得的。但不要让它审查所有代码。5.2 什么情况下单Agent直出更优对于中小体量的游戏尤其是个人开发者或小团队单Agent直出几乎总是更优的选择。原因很简单游戏开发的核心是快速迭代和手感调优而不是代码的完美性。一个能跑但代码有点乱的游戏比一个代码完美但玩法无聊的游戏有价值得多。单Agent直出的另一个优势是上下文一致性。在多角色系统里架构师、生成者、审查者各自维护自己的上下文信息在传递过程中会丢失或扭曲。而单Agent只有一个上下文它记得自己之前写过什么风格更统一。5.3 我的最终工作流配置目前我的工作流是这样的一个主Agent负责所有代码生成提示词里明确要求“简洁、直接、可运行”。我自己维护一个轻量级的架构笔记只在需要时手动注入。测试驱动作为质量保障每个功能模块写完立刻跑测试。如果遇到复杂逻辑我会把问题拆成多个小步骤让AI一步步生成而不是一次性生成一个大模块。这套配置跑了一个月完成了游戏的核心玩法、UI、存档、音效集成。代码量大约3000行bug率在可接受范围内。最重要的是我每天都能看到游戏在变好而不是在跟AI角色扯皮。6. 踩坑之后总结的几条硬核经验6.1 不要用AI模拟人类团队结构人类团队有架构师和审查者是因为人类有沟通成本、有认知偏差、有工期压力。AI没有这些限制它可以直接从需求跳到代码中间不需要“角色”来协调。强行给AI配角色相当于给一辆自动驾驶汽车配一个“方向盘操作员”和一个“油门踩踏员”除了增加复杂度之外没有任何好处。6.2 审查角色的替代方案是“运行测试”代码审查的本质是“在运行之前发现问题”。但AI审查者只能检查代码的“形式”不能检查代码的“行为”。而游戏开发中行为才是关键。所以与其让AI审查代码不如让AI生成测试用例然后运行测试。测试失败的地方才是真正需要修改的地方。6.3 架构师角色的替代方案是“手动笔记”AI架构师的问题是它不知道项目的实际边界它会按照理论最优去设计。而你自己知道项目要做多大、要做多久、哪些地方可以妥协。所以架构决策应该由你自己做AI只负责在你给定的架构下生成代码。如果你不确定架构可以先让AI生成一版代码跑起来之后根据实际痛点再调整。6.4 提示词要“做减法”而不是“做加法”我一开始的提示词写得很长塞了各种规范、约束、最佳实践。后来发现提示词越长AI越容易陷入“满足提示词”而不是“解决问题”。现在我的提示词只有一句话“用TypeScript写Godot游戏逻辑代码简洁直接不要过度设计。”效果反而更好。6.5 砍掉角色后开发节奏回归正常砍掉两个角色后我最大的感受是“节奏回来了”。以前每天要花大量时间在AI角色之间传话、协调、处理冲突现在这些时间全部用来写游戏逻辑和调手感。游戏开发本来就应该是一件直接的事情想一个玩法写代码跑起来调再跑。AI角色把这件事搞复杂了砍掉它们之后事情回到了它本来的样子。最后分享一个我最近在用的技巧如果你不确定某个功能要不要抽象就先让AI写一个最直接的版本跑起来。如果跑起来之后你觉得需要抽象再让AI重构。大多数情况下你会发现根本不需要抽象。游戏开发里能跑的代码就是好代码其他的都是废话。