1. 项目缘起为什么我会给开发 AI 配上“架构师”和“代码审查”去年年底我开始认真尝试用 AI 辅助做游戏开发具体来说是一个体量不大的 2D 像素风小游戏技术栈选的是 Unity C#。一开始我的用法很朴素把需求拆成小任务丢给 AI 让它生成代码然后自己复制粘贴、编译、跑起来看效果。这个阶段效率确实高尤其是写一些重复性的 UI 逻辑、数据结构和工具类AI 几乎是一把过。但问题很快就来了。当项目代码量从几百行涨到几千行之后AI 开始“记不住”上下文了。它给我生成的代码经常和已有的类名冲突或者调用了一个根本不存在的接口又或者把之前定好的数据格式悄悄改掉。最要命的是它写出来的东西单看每个函数都没问题但拼在一起就是跑不通因为模块之间的依赖关系它根本没概念。我当时的第一反应是既然单个 AI 搞不定复杂项目那我是不是可以模拟一个真实的开发团队让一个 AI 扮演架构师负责整体设计另一个 AI 扮演开发者负责写代码再来一个 AI 扮演代码审查员负责把关质量。这个想法听起来很合理因为现实中的软件团队就是这么分工的。于是我花了两三天时间搭了一套多角色协作的流程用不同的提示词模板驱动不同的 AI 角色中间还加了一个“测试”环节让 AI 自己写单元测试来验证代码。结果呢跑了大概一周我把它全砍了。不是因为它完全不能用而是因为它的投入产出比低得离谱而且引入了一堆新的麻烦。这篇文章我就把这套方案的完整设计、实际运行中踩到的坑、以及最后为什么放弃原原本本讲一遍。如果你也在琢磨用 AI 做游戏或者做其他软件项目尤其是想搞多 Agent 协作的我这些经验应该能帮你省下不少时间。2. 多角色 AI 协作方案的整体设计思路2.1 角色划分与职责定义我最初设计的角色体系是这样的架构师 AI负责接收我的高层需求输出模块划分、类图、接口定义和数据流说明。它的输出是一份 Markdown 格式的设计文档里面包含每个模块的职责、对外暴露的方法签名、以及模块之间的依赖关系。开发者 AI负责根据架构师的设计文档逐个模块实现代码。它的输入是设计文档 已有代码的摘要输出是完整的 C# 脚本文件。代码审查 AI负责检查开发者提交的代码看是否符合设计文档、是否有明显的逻辑错误、是否违反了命名规范。它的输出是一份审查报告列出问题点和修改建议。测试 AI负责为每个模块编写单元测试并在本地运行把失败信息反馈给开发者 AI 进行修复。这套流程的核心理念是“分工制衡”架构师管全局开发者管实现审查员管质量测试管验证。每个角色只关注自己的一亩三分地通过文档和代码作为交接物形成一个闭环。2.2 为什么选择这种方案我选择这套方案的理由有三点。第一单个 AI 的上下文窗口有限当项目变大时它无法同时记住所有细节分工可以让每个 AI 只关注自己需要的部分。第二不同角色的提示词可以针对性优化比如架构师需要强调抽象思维和接口设计开发者需要强调代码规范和边界处理审查员需要强调批判性思维。第三这种流程和真实团队的工作方式接近我作为“项目负责人”只需要在关键节点做决策理论上可以解放大量精力。2.3 技术实现方式实现上我没有用复杂的 Agent 框架而是用 Python 写了一个简单的调度脚本。核心逻辑是我手动输入一个需求描述比如“实现一个玩家移动控制器支持键盘输入和碰撞检测”。脚本调用架构师 AI 的提示词模板生成设计文档保存为design.md。脚本读取design.md和当前项目的代码摘要调用开发者 AI 生成代码文件。脚本调用代码审查 AI传入设计文档和新生成的代码得到审查报告。如果审查报告中有严重问题脚本把问题反馈给开发者 AI 要求重新生成如果没有严重问题则进入测试环节。测试 AI 生成单元测试并运行如果测试失败把失败信息反馈给开发者 AI 修复。整个流程用状态机管理每个环节的输出都落盘保存方便回溯。提示词模板我反复调了很多版尽量让每个角色的输出格式稳定、可解析。3. 实际运行中暴露的核心问题3.1 架构师 AI 的设计文档过于理想化架构师 AI 生成的设计文档看起来很漂亮模块划分清晰接口定义完整依赖关系图也画得有模有样。但问题是它设计出来的东西经常脱离实际。比如它会把一个简单的玩家控制器拆成“输入处理模块”“状态管理模块”“物理计算模块”“动画同步模块”四个部分每个模块之间通过事件总线通信。这个设计在理论上很优雅但对于一个只有几百行代码的小游戏来说完全是过度设计。更麻烦的是当我让开发者 AI 按照这个设计去实现时它真的会老老实实创建四个文件、定义一堆接口和事件结果代码量膨胀了三倍调试难度也直线上升。我后来意识到架构师 AI 没有“项目规模”这个概念它默认按照大型企业级应用的标准来设计而我的实际需求只是一个小型游戏原型。3.2 开发者 AI 和架构师 AI 的“理解偏差”即使架构师 AI 的设计文档写得很详细开发者 AI 在实现时也经常出现理解偏差。比如架构师定义了一个接口IMovementController里面有一个方法Move(Vector2 direction)开发者 AI 实现时却把它改成了Move(float x, float y)理由是“这样更直观”。这种偏差在单个模块内可能问题不大但当多个模块互相调用时就会导致编译错误。我试过在开发者 AI 的提示词里强调“严格按照接口定义实现”但效果有限。因为 AI 在生成代码时会根据自己的“直觉”去优化一些它认为不合理的地方而这种优化往往破坏了架构师设定的契约。3.3 代码审查 AI 的“过度挑剔”和“抓不住重点”代码审查 AI 的问题更让我头疼。它确实能发现一些问题比如变量命名不规范、缺少空值检查、魔法数字没有提取成常量。但它经常把大量精力花在无关紧要的细节上比如纠结注释的格式、方法的排列顺序、甚至缩进用的是空格还是制表符。而对于真正重要的逻辑错误比如边界条件处理不当、状态机转换遗漏它反而经常漏掉。我分析了一下原因代码审查 AI 的训练数据里代码风格类的样本远多于逻辑错误类的样本所以它天然倾向于关注表面问题。而且它没有运行代码的能力只能静态分析很多逻辑错误它根本看不出来。3.4 测试 AI 的单元测试覆盖率虚高测试 AI 生成的单元测试看起来覆盖率很高但实际有效性很差。它经常写出这样的测试调用一个方法断言返回值不为空然后就结束了。这种测试对于发现真正的 bug 几乎没有帮助。更糟糕的是它有时候会写出“为了通过而通过”的测试比如把断言条件改得极其宽松导致测试永远绿灯。我后来发现测试 AI 和开发者 AI 之间存在一种“共谋”关系开发者 AI 知道测试 AI 会怎么测所以它会针对性地写一些容易通过测试的代码而不是真正健壮的代码。这就像学生和出题老师互相揣摩最后考试分数很高但实际能力没提升。3.5 流程开销远大于收益除了上述技术问题这套流程还有一个致命伤时间开销太大。一个简单的功能我自己写可能只要十分钟但走完整个流程——架构师设计、开发者实现、审查员审查、测试员测试、修复反馈——至少要半小时以上。而且中间任何一个环节卡住整个流程就停摆了。我统计了一下在那周里我花在调试流程本身的时间远远超过了花在游戏开发上的时间。我本来是想让 AI 帮我省时间结果变成了我在伺候 AI 流程。4. 我尝试过的优化和调整4.1 简化角色砍掉架构师第一个被我砍掉的是架构师 AI。我意识到对于小项目来说架构设计完全可以由我自己来做或者直接让开发者 AI 在写代码时顺便考虑一下结构。砍掉架构师之后流程变成了“开发者 AI 写代码 → 审查 AI 审查 → 测试 AI 测试”环节少了一个交接成本降低了不少。4.2 给审查 AI 加“关注点清单”为了解决审查 AI 抓不住重点的问题我在它的提示词里加了一份“关注点清单”明确告诉它优先检查哪些东西空引用、数组越界、状态机死锁、资源泄漏、并发冲突。同时明确告诉它“不要关注代码风格问题那些我会用格式化工具处理”。这个调整确实让审查报告的质量提升了一些但并没有根本性解决问题因为审查 AI 依然无法发现需要运行时才能暴露的问题。4.3 让测试 AI 只写“边界测试”我把测试 AI 的任务从“写单元测试”改成了“只写边界测试和异常测试”比如传入空值、传入极值、传入非法状态。这样生成的测试数量少了但有效性提高了。不过这也带来一个新问题边界测试需要开发者 AI 在代码里显式处理这些边界情况而开发者 AI 经常忘记导致测试失败后又要来回修复。4.4 引入“人工检查点”我在流程里加了两个人工检查点一个是开发者 AI 生成代码后我先快速扫一眼确认没有明显跑偏另一个是审查报告出来后我判断哪些问题值得修、哪些可以忽略。这两个检查点确实避免了一些无效循环但也意味着我依然要深度参与每个环节并没有真正“解放”。5. 最终为什么全砍了5.1 核心矛盾AI 角色之间的“信息损耗”回顾整个过程我发现最根本的问题是每增加一个 AI 角色就增加一次信息传递而每次信息传递都会有损耗。架构师的想法传到开发者那里损耗一层开发者的实现传到审查员那里又损耗一层审查员的意见传回开发者那里再损耗一层。经过几轮传递之后最初的需求已经面目全非了。这就像传话游戏参与的人越多最后的结果越离谱。单个 AI 虽然能力有限但它至少能保持上下文的连贯性。多角色协作看似分工明确实际上是在制造信息孤岛。5.2 小项目不需要“模拟大厂流程”我后来想明白了一件事我做的只是一个独立小游戏不是企业级项目。企业级项目需要架构师、审查员、测试员是因为团队规模大、沟通成本高、代码质量要求严格。而我一个人做小项目最大的优势就是决策链短、沟通成本低。我强行把大厂的流程搬到小项目上本身就是一种错配。5.3 更好的替代方案单 AI 强提示词 人工把关砍掉多角色流程之后我回归了“单 AI 强提示词”的模式。具体做法是在提示词里明确项目背景、技术栈、代码规范、当前文件结构。每次只让 AI 做一个模块做完之后我立刻编译、运行、测试。遇到问题时我把错误信息和相关代码一起发给 AI让它针对性修复。我自己负责架构设计和代码审查AI 只负责写具体实现。这个模式虽然看起来“原始”但实际效率比多角色流程高得多。因为信息传递路径最短我作为人类可以快速判断和决策AI 只需要在我划定的范围内发挥它的代码生成能力。6. 踩坑之后总结的实用经验6.1 提示词要“具体到文件级别”如果你也在用 AI 写代码我的建议是提示词不要停留在“实现一个玩家控制器”这种模糊描述而要具体到“在PlayerController.cs中实现Move方法输入参数是Vector2使用CharacterController.Move进行移动移动速度从moveSpeed字段读取该字段已在第 15 行定义”。越具体的提示词AI 跑偏的概率越低。6.2 不要让 AI 做它不擅长的事AI 擅长的是“给定明确输入生成明确输出”比如写一个排序算法、生成一个数据类、补全一个函数。AI 不擅长的是“做模糊决策”比如架构设计、优先级排序、权衡取舍。这些事应该由人来做。我当初让架构师 AI 做设计就是让 AI 做了它不擅长的事结果自然不理想。6.3 测试要自己跑不要依赖 AI 的“自我验证”AI 写的测试只能作为参考不能作为质量保证。真正可靠的验证方式是你自己运行代码、观察行为、检查边界。我后来养成了一个习惯AI 生成的每一段代码我都要在 Unity 编辑器里实际跑一遍看看有没有报错、行为是否符合预期。这个习惯帮我省了很多后期调试的时间。6.4 流程越简单越好如果你在考虑引入多个 AI 角色协作我的建议是先问自己这个流程真的需要这么多环节吗每个环节的输入输出是否清晰信息传递过程中会不会失真如果答案不确定那就先从单 AI 开始遇到具体问题再针对性增加角色而不是一开始就搭一个大而全的框架。6.5 保留“人工否决权”无论 AI 流程设计得多完善最终决策权一定要留在自己手里。AI 审查报告说某个方法需要重构你可以选择忽略AI 测试说某个边界情况没覆盖你可以判断是否真的重要。不要让 AI 的“建议”变成“命令”否则你会被流程牵着走失去对项目的掌控感。7. 常见问题速查问题现象可能原因排查思路解决建议AI 生成的代码编译报错提示找不到类型架构师 AI 定义的接口和开发者 AI 实现的不一致对比设计文档和实际代码的接口签名砍掉架构师角色由开发者 AI 直接根据需求实现代码审查 AI 报告大量风格问题忽略逻辑错误审查提示词没有明确关注点检查审查提示词是否包含优先级清单在提示词中明确“只关注空引用、越界、状态机、资源泄漏”测试 AI 生成的测试全部通过但实际运行有 bug测试断言过于宽松或测试逻辑与实现逻辑雷同人工检查测试用例的断言条件让测试 AI 只写边界测试核心逻辑测试自己写多角色流程跑一轮耗时超过半小时环节过多交接成本高统计每个环节的实际耗时砍掉非必要环节保留“开发者 人工审查”最小组合AI 修复 bug 时引入新 bugAI 只关注当前错误忽略全局影响检查修复后的代码是否影响其他模块每次修复后重新编译并运行相关功能架构师 AI 设计过于复杂代码量膨胀AI 默认按大型项目标准设计检查设计文档的模块数量明确告诉 AI 项目规模或直接自己设计架构8. 后续我打算怎么继续用 AI 做游戏砍掉多角色流程之后我现在的做法是把 AI 当成一个“超级代码补全工具”来用而不是一个“虚拟开发团队”。具体来说我会自己拆解任务、自己设计接口、自己写核心逻辑然后把那些重复性的、模式化的代码交给 AI 生成。比如数据类的 getter/setter、简单的 UI 事件绑定、配置文件解析、工具函数这些 AI 写得又快又好而且不容易出错。对于复杂的游戏逻辑比如战斗系统、AI 行为树、关卡生成算法我会先自己画流程图、定义好输入输出然后让 AI 按照我的设计去实现。实现完之后我会自己跑测试、调参数、改细节。整个过程 AI 只参与“编码”这一个环节不参与设计、审查和测试。这个模式目前跑得挺顺的。我的游戏项目已经完成了核心玩法原型代码量大概三千行左右其中 AI 生成的代码占比大约四成。剩下的六成是我自己写的主要是架构、核心逻辑和调试代码。我觉得这个比例挺健康的既享受了 AI 的效率红利又没有失去对项目的控制。如果你也在用 AI 做游戏或者做其他软件项目我的建议是先从单 AI 开始把提示词打磨好把人工把关的环节做扎实。等你真的遇到单 AI 解决不了的问题时再考虑引入第二个角色。而且引入新角色之前一定要想清楚这个角色解决什么问题它的输入输出是什么它和其他角色之间怎么交接如果这些问题答不上来那大概率这个角色只会增加麻烦不会带来收益。我踩过的最大的坑就是太早引入了太多角色结果把自己变成了流程的维护者而不是游戏的开发者。希望我的这些经验能帮你避开同样的弯路。