1. 项目概述：当“游戏开发者”变成AI智能体
这几年我一直在折腾AI辅助开发的落地场景，Web应用、脚本工具、数据管线都试过，但说实话，最让我觉得“有内味”的，还是拿AI智能体去自动化跑游戏开发。不是让AI帮你写几段代码，而是把整个游戏从设计到可玩版本的迭代闭环，全部交给一连串自主决策的智能体去推进。这次的实验项目，代号叫Tesana AI，目标很简单：输入一个极简的游戏构想，AI智能体自动完成搭建骨架、生成核心机制、填充关卡内容、循环迭代修复问题，最终产出一个能运行、能玩、有一定完成度的HTML5游戏。
为什么选择游戏开发作为试验场？因为游戏是一个“反馈极其明确”的软件形态——运行报错、界面错位、逻辑不成立、手感不对，这些问题在几秒钟内就能被验证。这种即时反馈恰好是AI智能体循环迭代最需要的土壤。你给智能体一个报错信息，它能自己定位问题、修改代码、重新运行，不需要人一步步引导。相比写业务系统那种“看似跑通、实则有很多隐藏问题”的状态，游戏开发的验证成本足够低，能让我清清楚楚看到智能体到底是在干活还是在摸鱼。
可能有人会问，这不就是拿AI写小游戏吗？和直接用ChatGPT生成一个贪吃蛇有什么本质区别？
区别很大。直接对话生成游戏，是一次性、单轮指令的产物。你让它生成，它生成，你再提意见，它再改，本质上是“人类驱动、AI执行”的结对编程。而Tesana AI这个项目里，AI智能体自己是“项目经理+开发+测试+美术”的结合体，人类只负责设定目标和验收标准，中间的所有决策——比如下一个迭代改什么、Bug怎么修、数值怎么调、关卡怎么扩——都由智能体基于自身对游戏状态的评估来推进。这是从“工具辅助开发”到“让AI拥有持续开发能力”的关键切换，也是我这次最想验证的事情。
这套思路适合谁参考？如果你对AI智能体的工程化落地有兴趣，或者你在做内容生成、自动化生产的工具链，再或者你手头有大量“需要反复迭代修正”的重复性开发任务，这篇文章里的架构拆解、工作流设计和坑位盘点，都能给你一些参考。
2. 整体架构：四个角色组成的“虚拟游戏工作室”
2.1 不是单个AI，而是一组分工明确的智能体
很多人对“AI智能体”有个误区，以为就是一个超强的聊天机器人挂在后台。实际上，真正能落地干活的智能体系统，更像一个分工明确的团队。Tesana AI里我拆了四个角色：设计Agent、开发Agent、测试Agent、统筹Agent。
设计Agent负责把模糊的游戏想法转成结构化描述——玩法机制、核心循环、目标用户、美术风格关键词。开发Agent负责把设计文档转成实际代码，按照约定好的目录结构和编码规范输出。测试Agent负责运行游戏、捕获报错、甚至通过截图或日志判断游戏是否正常运行。统筹Agent则像一个缩微版的技术负责人，管理迭代顺序、汇总各个角色的产出、决定什么时候可以验收结束。
这个分工不是炫技，而是工程上的必然。如果只用一个Agent串联所有任务，最大的问题是“上下文污染”——游戏需求、代码实现、Bug日志、修改计划全都塞在同一个上下文窗口里，几百轮之后，模型会忘记早期设计意图，甚至自己改出来的代码自己都不认识。拆开角色之后，每个Agent的上下文边界是清晰的，设计Agent只需要关注需求，开发Agent只需要关注代码和Bug描述，测试Agent只需要关注运行结果，决策压力则集中在统筹Agent这一层。
2.2 循环迭代机制：让AI“自己玩自己”
Tesana AI的核心机制是“生成→运行→反馈→修改→再运行”的循环。听起来简单，真正实现起来有几个关键设计点。
第一，每个迭代周期要有明确的“变更目标”，不能无脑让AI“改一改”。统筹Agent每次只会选一个优先级最高的问题作为本轮迭代目标，比如“修复暂停功能无响应”或者“增强敌机生成频率的随机性”。目标太宽泛，模型输出的改动会漂移；目标太具体，又容易让迭代停在局部最优。
第二，测试Agent产出的“反馈报告”必须是结构化数据，不是自然语言。比如“运行失败，报错信息XXXX”“运行成功，存在异常：人物可移动出边界”“运行成功，逻辑正常，待增强项：缺少音效”。结构化反馈最大好处是后续Agent解析准确率高，不会出现“AI理解错AI反馈”的套娃事故。
第三，循环必须设置终止条件，否则AI会把项目改到天荒地老。我的策略是三层终止：达到验收标准立即终止；超过最大迭代轮数强制终止并输出当前进度；连续N轮没有实质进展，触发回滚到上一个稳定版本，换一条修改路线。
这个循环迭代的思路，其实是把敏捷开发里的“短反馈循环”搬到了AI身上。人类开发者的迭代周期是“写代码→编译→测试→改代码”，往往以天或小时为单位，AI智能体可以把这压缩到分钟级。游戏这种对迭代速度极度敏感的领域，天然适合拿来验证这套机制。
2.3 为什么选择纯前端技术栈
Tesana AI的主产物，我选择生成纯HTML5+JavaScript游戏，运行环境是浏览器。这个选择背后有几个实际考量。
首先是环境约束。智能体要能“自己运行自己生成的东西”，如果生成了一个需要编译、装依赖、配服务端的项目，那AI还得会处理环境问题，复杂度直接翻倍。浏览器是几乎所有机器上都有的运行时，零安装成本，生成的HTML文件直接双击就能跑。
其次是验证成本低。纯前端游戏的所有逻辑都在浏览器里跑，测试Agent可以用无头浏览器加载文件、检查控制台报错、截取游戏画面，整个验证链路非常干净。
第三是内容丰富度高。Canvas、2D物理、音效播放、键盘鼠标事件，这些能力已经足够做出相当有完成度的游戏了。贪吃蛇、俄罗斯方块、飞行射击、简单平台跳跃，全部覆盖。
当然，纯前端也有代价，最大的问题是环境安全沙箱让游戏不方便直接使用外部资源（比如下载美术素材），所有的图像和音效要么用代码生成，要么用极简的占位。我后面会详细讲怎么处理这个限制。
3. 核心细节解析：让智能体真正“干活”的关键设计
3.1 任务拆解：从一句话到可执行的开发工单
智能体驱动开发，最怕的就是“需求不清导致模型自由发挥”。自由发挥的产物看着像回事，但往往后期完全无法扩展。所以Tesana AI的第一步，永远是把一句话想法拆成标准化的开发工单。
我会让设计Agent按照固定模板输出工单，模板包含以下条目：游戏名称、核心玩法（一个玩家动作 + 一个世界响应）、胜利条件、失败条件、需要实现的最小功能列表（按优先级排序）、美术风格关键词（用于代码生成占位素材）、声音元素（有或无）、目标难度曲线。
举个例子，如果输入“空战射击游戏”，模板会要求设计Agent填出类似这样的内容：核心玩法是“玩家控制战机移动和射击，敌机从顶部随机生成并向下移动”；失败条件是“玩家生命值归零”；最小功能列表是“战机移动、子弹发射、敌机生成、碰撞检测、得分计算、游戏结束画面”。这张工单会成为后续所有开发Agent的操作依据。
这一步看着繁琐，但价值极大。它把“想法”变成了“可验收的规格说明书”，也让循环迭代有了判断依据——如果开发Agent说“做完了”，测试Agent拿工单里的“最小功能列表”逐条核对，而不是凭感觉判断。
3.2 上下文管理：不让AI“失忆”的秘诀
单个Agent处理大规模代码项目，最大的技术瓶颈是上下文窗口。“改着改着忘了自己最初的设计”，这是所有AI辅助开发实践里最常见的问题。Tesana AI用了三个手段来对抗。
第一，在每次迭代开始时，开发Agent只接收当前版本的“核心文件快照”，而不是整个项目。我的处理方式是：每个迭代周期前，统筹Agent汇总一份状态报告，包含最新可运行版本的文件清单、本轮要修改的目标描述、相关文件的关键代码片段（截取函数签名和核心逻辑）。开发Agent在这一轮只需要基于快照做修改，不需要理解项目全局。
第二，关键决策信息持久化成“项目记忆库”。每次迭代验收通过后，设计Agent会总结这一版的“稳定特性”，存成一份markdown文档。比如“第3版开始，敌人类型有两种：普通直线型和追踪型”。后续新版本的开发Agent会读取这份记忆库，确保不会把已经存在的功能删掉或改坏。
第三，代码本身要遵循高度模块化、高度可读的约定。我要求开发Agent严格按“一个功能模块一个文件”来组织代码，函数命名前缀必须有上下文语义，比如initPlayer、updateBullets、checkCollisions。这种做法让AI在只看局部代码时也能大致理解自己在改什么。
3.3 自动生成策略：先跑通，再丰富，最后打磨
自动生成游戏内容，如果不设节奏，AI很容易“想一口吃个胖子”。第一版就试图搞出十个关卡、五种敌人、三种武器系统，结果几乎必然是一堆不可运行、充满耦合的坏代码。Tesana AI的生成策略严格遵守“三步走”节奏。
第一阶段是“最小可玩版本”（MVP），目标只在跑通。一个玩家对象在屏幕上能移动，一个敌人对象出现，碰撞检测生效，就足够了。这个阶段的代码可以丑、可以粗糙，但运行不能报错。
第二阶段是“功能完备版”，目标是把设计工单里的最小功能列表全部实现。这个阶段会有大量的逻辑扩展和Bug修复，也是循环迭代最密集的时期。
第三阶段是“体验打磨版”，目标转向手感、数值平衡、视觉反馈。比如发弹速度是不是太快、敌人的生成间隔是否合理、击中敌人有没有爆炸动画、游戏结束能不能重新开始。
这套节奏的好处是：每个阶段都有明确的验收标准，Agent在被测试Agent打回时能清晰知道自己在哪个层面出了问题。我见过太多AI辅助开发失败的案例，根源就在于让AI同时在“功能实现”和“体验打磨”两个维度上跳来跳去，结果哪个都做不像。
4. 实操过程与核心环节实现
4.1 开发环境：轻量级工具箱组合
Tesana AI本身不是一个现成的商业产品，而是我用一套开源工具链搭出来的实验性系统。核心框架用的是LangChain做Agent编排，底层的语言模型接的是GPT-4o系列（备选了Claude 3.5 Sonnet做对照测试）。浏览器自动化用的是Playwright，用来加载HTML、捕获控制台日志、截图游戏画面。
整体工作流是：统筹Agent用LangChain的任务队列驱动各个环节，设计Agent的输出格式是JSON工单，开发Agent的输出是代码文件，测试Agent的输出是JSON格式的测试报告。四个Agent之间不直接对话，全部通过一个共享的工作目录交换文件。工作目录的结构大概是这样的：
tesana_workspace/ ├── project_spec/ # 设计工单、需求文档 ├── source/ # 生成的游戏源码 │ ├── index.html │ ├── css/ │ └── js/ ├── test_reports/ # 测试报告和截图 └── memory/ # 项目记忆库这个目录结构有讲究。所有Agent只和文件系统打交道，某个Agent的产出就是下一个Agent的输入，这样即使换了一个模型，只要遵循相同的文件格式约定，也能正常接替工作。这种“文件即消息”的Agent间通信方式，比让Agent之间直接对话要稳定得多。
4.2 迭代工作流：一个周期的完整流程拆解
一次循环迭代的完整流程，可以拆成六个步骤。
第一步，统筹Agent读取当前项目状态，结合测试报告判断本轮优先要解决的问题。如果上一轮测试通过，本轮就进入下一阶段的功能开发；如果测试没通过，本轮就定位为修复Bug。
第二步，统筹Agent把这轮的目标和项目记忆库写给开发Agent。开发Agent读取需要修改的文件，输出修改后的代码，覆盖或新增到工作目录。
第三步，测试Agent启动Playwright，加载工作目录里的最新HTML文件，设置一个最大运行时间（比如5秒），查看控制台有没有报错，再模拟几次关键操作，比如按下方向键、点击开始按钮。这些操作和断言都定义在配置里，每次测试都会执行相同的“冒烟用例”。
第四步，测试Agent把结果写成结构化JSON，包括：运行是否成功、控制台错误列表、模拟操作是否完成、游戏是否到达可玩状态、截图。
第五步，统筹Agent读取JSON报告。如果结果是“成功”，更新项目记忆库，进入下一轮迭代或者准备验收；如果结果是“失败”，带着报错去找开发Agent要求修改。
第六步，重复以上步骤，直到达到终止条件。
我拿一个实际案例来说明：我给Tesana AI定的第1轮测试目标是“游戏能启动，玩家能在画布上左右移动”。测试Agent运行后，报告了错误：Cannot read properties of null (reading 'addEventListener')。从报错内容判断是canvas元素还没加载完就执行了JS，典型的DOM未就绪问题。开发Agent拿到这个错误后，把脚本从head挪到了body末尾，并且加了DOMContentLoaded包装。第2轮测试立即通过，游戏正常启动并响应键盘操作。
4.3 可玩性验证：如何让AI“看”游戏
纯跑通代码不算成品，游戏还得“能玩”“好玩”。Tesana AI用了几层验证手段，从硬到软逐步递进。
最硬的一层是自动化冒烟测试，主要验证“游戏没有白屏，没有JS报错，核心交互可以执行”。比如在Playwright里模拟玩家连续按了10次“向右移动”，然后截图，判断游戏画布上的玩家位置是否发生变化。这个验证能挡住一大部分“代码能运行但完全没有功能”的问题。
中间层是逻辑规则校验。我在测试Agent里配置了一组“游戏规则断言器”，比如：玩家的坐标值不能超出画布边界；发射子弹后子弹数量应该+1；击中敌人后得分应该增加；游戏结束后应该显示“游戏结束”文字。这些断言通过检查游戏暴露出来的全局状态变量（比如window.gameState.score）来实现。这就要求开发Agent写代码时把关键状态挂到全局对象上，方便测试读取。
最软的一层是AI主观评价。让一个独立的评价Agent看游戏截图，结合玩法描述给出手感评价：“画面是否杂乱”“UI是否清晰”“第一次打开时玩家是否知道该做什么”。这层的评价不够稳定，也不能作为验收硬指标，但它能给出有价值的优化方向，帮助统筹Agent判断什么时候该从“功能阶段”切到“打磨阶段”。
4.4 自动生成的经典难题：代码质量守卫
自动生成最容易翻车的，是代码风格的失控。AI的代码生成习惯波动很大，有时用构造函数，有时用类，有时又是纯函数，几轮迭代下来代码风格会逐渐“熔断”——不同模块之间的接口约定对不上，最终成为一团乱麻。
Tesana AI的代码质量守卫机制，核心是“接口约定检查”。在设计工单里，我对每个游戏类型指定了必须暴露的全局函数和状态变量，并在测试阶段增加了一个“API一致性检查”步骤。比如空战游戏类必须暴露：initGame()、startGame()、update(deltaTime)、render(ctx)、gameOver状态。测试Agent每次跑完冒烟用例，还会检查这些函数是否存在、参数是否匹配。不一致就直接报错，要求开发Agent修正，而不是任由AI用新风格重写旧功能。
另一个质量问题是死代码膨胀。AI每轮修改喜欢保留所有旧的写法，注释掉的大段代码、永远不会触发的分支、冗余的变量，累积几轮后文件变得巨大且混乱。我在每次迭代的验收环节，会额外要求开发Agent“清理本轮修改区域内无用的代码和注释，确保交付的代码风格统一”。虽然这个要求没法被完美执行，但至少能抑制住最坏的情况。
4.5 给智能体“配眼镜”：用自动化测试数据喂模型
还有一个小技巧，对于提升迭代效率特别有用。我在开发过程中发现，让开发Agent直接凭空改代码，效果远不如给它提供“可参考的错误复现路径”。“光说Bug描述”——比如“敌人碰到玩家时游戏没有结束”——开发Agent经常改错地方，因为它对代码的静态理解有限。
所以我在测试Agent里加了一个“错误复现数据导出”功能。当某个冒烟用例失败时，测试Agent会把导致失败的完整操作序列、出现错误时的控制台日志、那一刻的截图，打包成一个“复现包”，随测试报告一起交给开发Agent。这相当于给AI戴了一副“能看见问题的眼镜”。
这个经验类比到人类开发世界，就是“能复现的Bug报告，胜过一百句场景描述”。实际用了之后，开发Agent的Bug修复准确率提升了非常明显。尤其是渲染类问题（物体位置偏移、碰撞判定不精确），给了截图之后，模型往往能一眼定位原因。
5. 常见问题与排查技巧实录
5.1 智能体“自作聪明”改坏功能
这是最常见、也最让人头大的问题。循环迭代到第8轮，一切正常，第9轮从一个看似无关的小需求出发，结果测试直接失败。排查后发现，开发Agent在一处与此前稳定功能有交叉的代码中，顺手改了别的逻辑，把之前好的功能干掉了。
我的解决方案是“强制快照回滚机制”。每次迭代通过验收后，工作目录的source会打一次zip快照。一旦某轮测试失败并且连续修复两轮仍未通过，统筹Agent会直接回滚到最近通过验收的快照，重新带着更详细的指令发起新一轮迭代。这套机制有效制止了AI在局部问题上的无限内耗，就算AI跑偏，代价也只是一个快照的差距，不至于把项目搞到不可收拾。
5.2 测试Agent误报“游戏运行成功”
Playwright加载页面之后控制台没有报错，不代表游戏逻辑正常。有一轮生成的是滚动躲避类游戏，测试Agent说“成功”，但打开截图发现画面空白，玩家和障碍物都不见了。原因是没有报错是因为代码逻辑正常跑完了，但渲染状态为零——所有物体座标是NaN。
排查这类问题，光看控制台日志远不够。后来我在冒烟测试里增加了“视觉像素断言”：截图后统计游戏区域内的非背景色像素占比，如果低于阈值（比如1%），就判定为“渲染异常，可能画面空白”。对于“能不能玩”这类问题，机器视觉和人为经验一样，都要有冗余手段叠加。
5.3 上下文越来越长导致模型“失去重点”
这是纯工程问题。迭代得越多，测试报告、记忆库、代码快照堆积的文本越长，模型进入长上下文的稳定期越短。如果每个Agent都接收全量信息，很快上下文就超载了。
我调整成“层级摘要”机制。统筹Agent在迭代开始前，先用一个较小的模型（比如GPT-4o mini）把项目记忆库压缩成一份精简摘要，只保留关键特性和遗留问题。开发Agent和测试Agent都只接收这份摘要，加本周期的定向信息。实测下来，不仅上下文使用量更可控，模型的“注意力漂移”现象也明显减少。
5.4 提示词阶段的一个高频坑：让Agent写“硬编码关卡”而不是“程序化生成”
在“生成内容”这件事上，模型有一个天然倾向：用硬编码数据凑数。比如让它做10个关卡，它就真的写10个{...}关卡对象，塞进代码里。这么做短期看没问题，但后续迭代如果涉及到关卡调整，开发Agent要在一大段数据里到处挖，极易改错。
我在设计工单里明确要求：“所有的关卡和敌人配置必须通过程序化生成（基于种子随机算法）或数据配置文件驱动，不允许在逻辑代码中硬编码关卡数据”。这之后生成的代码质量上了一个台阶。后面再接迭代扩展，比如增加关卡难度曲线，只需要调整一个参数，不用动逻辑代码。
5.5 如何判断当前工程“是不是该停了”
很多人在用AI做迭代开发时，没有明确的“验收标准”，最后陷入无限循环：AI一直在“优化”，但人类总觉得“还差一点”。Tesana AI的解法是“验收门”机制。
每一次迭代结束时，统筹Agent会严格对照设计工单里的验收清单，逐条检查是否满足。验收清单里有硬性条件和软性条件两类：硬性条件是代码可运行、无致命Bug、核心功能全部存在；软性条件是手感、视觉、音效等方面的评分。只有当硬性条件全部满足，软性条件达到预设阈值时，整个周期才宣告结束。
停止迭代这个决定，交给AI本身判断，人类只负责验收标准，这样才能真正发挥自动化生产的效果。否则和“用AI帮我写代码的聊天框”没有本质区别。
6. 一点实践体会
回到标题里的Tesana AI，本质上不是某一个模型，也不是某一个框架，而是我把“AI智能体如何真正落地到内容生产”这件事的完整思考。游戏开发这个场景让我验证了几件重要的事：AI智能体能基于结构化反馈自主决策，循环迭代可以做到“人的参与度极低”，而自动生成的代码只要配合工程化约束，完全能达到可维护、可扩展的质量水平。
我第一次跑通完整的“生成一个可玩的太空射击游戏，再从MVP迭代到带三种子弹、两种敌人、关卡波次、计分系统的完整版本”，全程只花了不到四十分钟。中间人类做的唯一一次干预，是在第5轮迭代时，测试Agent连续报了两个版本“画面渲染异常”，我人工确认了一下是代码逻辑问题而不是测试环境问题，然后把反馈数据校准了一下，后面就一路自己跑了。
如果让我总结这套方法最值得复用的经验，我觉得有三点：一是角色拆分的Agent架构，比单Agent指令式开发稳定得多；二是结构化、可验证的反馈链路，是整个迭代闭环的心脏，没有它，AI只会生成“看着像游戏的东西”；三是“验收门”和“快照回滚”这两个工程化兜底设计，决定了这个系统到底是在“自主开发”还是在“无限试错”。
至于后续扩展方向，我在筹备让Tesana AI支持更复杂的游戏类型——比如简单的RPG（有剧情对话、升级系统、背包逻辑），这类游戏的状态管理更复杂，对智能体迭代机制的挑战也更真实。同时也在试做“多局对比评估”机制，让AI能通过自动开多局游戏，统计胜率、通关率、平均用时等指标，把“好玩”这个主观概念尽量数据化。
将近二十轮迭代的完整日志我都留着，回头整理一份“从错误中学习的AI开发日志”出来，应该比这篇更零碎、也更有意思。
