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的主产物我选择生成纯HTML5JavaScript游戏运行环境是浏览器。这个选择背后有几个实际考量。首先是环境约束。智能体要能“自己运行自己生成的东西”如果生成了一个需要编译、装依赖、配服务端的项目那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开发日志”出来应该比这篇更零碎、也更有意思。 AI智能体自动化游戏开发：从零到可玩HTML5游戏的迭代实践
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的主产物我选择生成纯HTML5JavaScript游戏运行环境是浏览器。这个选择背后有几个实际考量。首先是环境约束。智能体要能“自己运行自己生成的东西”如果生成了一个需要编译、装依赖、配服务端的项目那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开发日志”出来应该比这篇更零碎、也更有意思。