“AI agent 自己写代码、自己测试、自己把游戏发布上线”这件事最近在开发者社区里被讨论得很多。我把它当成一个很值得实测的课题让它独立做完并且发布一个浏览器游戏从一句自然语言需求开始到最终用户能在浏览器里打开即玩。这种任务的真正价值不在于“AI 能不能写一段游戏代码”而在于一条完整的闭环——需求理解、代码生成、运行验证、错误修复、部署交付——是不是真的能由 agent 自己走通。适合看这个主题的人有三类正在用 AI 编程工具做小产品的开发者想了解 AI agent 能力边界的产品经理以及想低成本验证游戏创意的独立开发者。先说我的核心判断在“单页、无后端、静态部署”的游戏项目上AI agent 已经能做到相当高的完成度。但“shipped”这个词很容易被低估——把代码推到线上不等于交付完成真正的发布还包括域名访问、移动端体验、资源加载、故障回退这些环节。下面按我从需求到发布实际跑一遍的顺序拆开讲。1. 先搞清楚“AI 自己做完并发布”到底包含了哪几步1.1 从提示词到产品中间不是只有写代码一件事很多人对 AI agent 的想象是给它一句话它哗哗生成一个文件夹然后就能玩了。真实流程比这长得多。一次完整的“让 AI agent 独立完成并发布浏览器游戏”至少包含五个阶段需求拆解把“做一个 XX 游戏”拆成玩法、界面、交互、得分、音效、移动端适配等子任务。技术选型决定用纯 HTML/CSS/JavaScript还是 Canvas 绘图还是引入某个轻量框架。代码生成与文件组织生成 index.html、样式、脚本、资源文件并且让内部引用关系正确。运行验证启动静态服务器打开页面检查控制台报错实际操作一遍关键流程。发布部署把文件推送到静态托管服务配置访问入口验证真实线上地址是否可用。这五步任何一步断了都不能算“ship”。我之前见过不少 agent 生成的游戏代码看着完整一运行就白屏或者功能都在但没有任何一个可访问的入口。这类结果只能说“生成了代码”不能说“做完并发布了”。1.2 浏览器游戏为什么是很合适的“AI 全流程测试场”浏览器游戏天然适合做这种测试原因很直接产物自包含一个页面加若干资源文件没有复杂后端依赖。运行环境统一现代浏览器就是运行时不需要装数据库、中间件。部署简单静态文件可以扔到任意静态托管平台。反馈直观能不能玩、好不好玩肉眼和操作就能判断。这也是很多 AI 编程工具的演示都会选游戏场景的原因。它把“AI 编码能力”和“AI 交付能力”一起暴露出来代码写得好不好一打开页面就知道。但这里有一个边界要记住适合做测试场不等于浏览器游戏是 AI agent 最擅长的所有项目类型。凡是交互复杂、数据要落库、有用户体系的真实产品复杂度会高一个量级。做小游戏能跑通只能证明基础链路可行不能直接推导出复杂产品也能全自动交付。2. 跑通前要准备的工具、环境和验收标准2.1 工具选型选对话式编码助手还是自主型 Agent现在能让 AI 做这类任务的工具大致分两类。第一类是对话式编码助手比如集成在编辑器里的 AI 插件。特点是你在编辑器里和它对话它改代码、你按快捷键运行每一步你都有控制权。优点是可控性强适合第一次试缺点是你仍然是主要的执行者它更像高级补全。第二类是偏向自主执行的 Agent 工具。你给出任务描述它会自己列计划、生成文件、运行命令、读取报错、修改代码甚至自己执行部署命令。这类工具更接近“on its own”的含义但代价是你必须花更多时间检查它是不是跑偏了。我的建议是第一次做用第二类工具但保持人工监督熟悉流程后可以把常见步骤固化成你自己的操作清单。不需要迷信某个工具重点是看它能不能执行命令、读取错误输出、修改文件、调用外部命令。这几个能力决定了它有没有可能真正“独立”完成。2.2 本地运行条件这类任务对硬件要求不算高但也不是零要求系统Windows、macOS、Linux 都可以但路径处理有差异发布部署时要注意。内存8GB 以上体验较好16GB 更稳。AI 编码工具和浏览器同时开内存不够会明显卡顿。网络需要能访问 AI 工具服务发布阶段需要能访问静态托管平台。网络不稳定时部署环节最容易失败。浏览器建议备 Chrome 和 Firefox 两个用于做兼容性验证。静态服务器本地开发时用简单的静态服务器打开页面而不是直接双击 HTML 文件否则资源相对路径和浏览器安全策略会引出奇怪问题。这里最容易踩的坑是Agent 生成了文件但它无法像人一样“亲眼看到画面”它只能通过运行命令、读取日志、检查代码结构来判断结果。所以在任务描述里要明确让它“启动静态服务器并检查页面请求是否成功”而不是笼统说“你打开看看”。2.3 先把验收标准写出来这一点非常关键。Agent 没有产品直觉你说“做一个好看的游戏”它永远不知道什么叫好看。所以要提前把验收条件写清楚。我一般会用这样一组标准维度验收标准功能游戏可以启动并玩满一个完整流程能得分、能结束、能重开稳定性连续重开 10 次没有白屏、卡死、控制台红色报错兼容性Chrome 和 Firefox 都能正常运行宽度 360px 到 1920px 不布局崩溃资源图片、字体、音频都能加载弱网下不会长期白屏发布访问线上地址和本地效果一致资源路径无 404这些标准最好一开始就放进提示词而不是等它写完了再补。原因是 agent 的修改倾向是“顺着已有代码打补丁”等到后期再改兼容性成本会明显增加。注意验收标准是给人用的也是给 agent 用的。标准越具体agent 越不容易把需求理解偏。3. 实测流程Agent 从需求到发布的完整链路3.1 第一步把模糊需求拆成可执行规格实测时我一般不从“帮我做个游戏”开始那样容易得到四不像。更稳的提示词结构是游戏类型 目标平台 核心玩法 操作方式 界面要求 发布要求。一个参考模板请用纯 HTML CSS JavaScript 开发一个飞机射击浏览器游戏。 要求 1. 鼠标或键盘控制飞机移动空格发射子弹。 2. 敌机从上往下出现击中得 10 分撞到玩家扣一条命。 3. 有开始界面、游戏结束界面、当前得分和最高分。 4. 最高分用 localStorage 保存。 5. 适配手机横屏和桌面浏览器。 6. 运行方式本地静态服务器打开 index.html。 7. 完成后启动一个静态服务器并用命令检查页面返回 200。这个提示词里每一句都在控制验收维度。真正重要的不是“做游戏”这三个字而是后面的边界条件输入方式、计分规则、存储、适配、运行和验证方式。Agent 收到后通常会先列一个计划然后开始生成文件。这个阶段你要观察的是它有没有主动拆分任务是直接生成一大坨代码还是一步步来。能拆任务的 agent后面遇到报错时定位会快得多。3.2 第二步生成代码并自测Agent 写完代码后它会自己运行命令。常见动作包括初始化目录和基础文件。启动静态服务器。用命令行方式检查页面是否可访问。读取控制台输出或者日志文件。根据报错修改代码。这一步对应的是“具备自我验证能力”的关键节点。如果 Agent 只是生成代码而没有尝试运行那么它本质上还是编辑器补全工具谈不上“自己做完了”。我自己会同时盯几个东西文件是否完整index.html 是否引用了正确的 CSS 和 JS 路径。服务器端口是否正常默认端口被占用时Agent 有没有自动换端口。日志是否可读报错时它会怎么解释是直接重写还是先定位问题位置。3.3 第三步修错与迭代这几乎是最能看出 Agent 水平的一步。浏览器游戏的常见错误包括脚本加载顺序错误、Canvas 尺寸计算错误、键盘事件没有监听、requestAnimationFrame 循环没有停止导致内存占用持续上升、资源 404 等。Agent 的修错方式一般有两种一种是读报错信息直接改另一种是反复重试但每次都改到别处。前一种高效后一种容易进入死循环。我习惯设一个规则同一个错误让 agent 重复修三次还没好就停下来手动把报错信息和当前文件结构发给它缩小范围。另外一个小技巧把浏览器控制台的报错原文直接贴给 Agent比输入“出错了帮我修”有效得多。报错信息是 AI 最好的定位线索。如果 Agent 运行在无头环境里拿不到浏览器控制台可以先用脚本把页面运行时错误输出到日志文件再让 Agent 读取。3.4 第四步打包和发布静态站点的发布相对简单。Agent 需要完成确认入口文件是最终要暴露的那个文件。把所有资源路径改成相对路径否则部署到子目录时全部 404。推送到托管平台拿到线上地址。用线上地址再验证一次。这里要注意发布成功不等于游戏可玩。我见过几次线上地址返回 200但游戏页面里的 JS 文件因为路径问题 404玩家打开就是白屏。所以发布后的验证动作不能省。至少做三件事打开线上地址确认页面渲染、打开开发者工具看有没有资源错误、实际玩一个完整流程。如果 Agent 能自动完成“推送-拿地址-请求验证”这一串动作那才算真正走完了发布链路。很多演示只做到“本地能跑”然后人工拖文件上线严格说那不算 agent 自己发布的。4. 最容易翻车的地方代码能跑不代表游戏能玩4.1 视觉上“正常”但逻辑有隐患Agent 生成的游戏最容易出现一种状态打开页面看起来一切正常一玩就露馅。常见问题包括碰撞检测只做了一部分子弹穿过敌机没反应。游戏循环没有正确处理时间间隔帧率不同导致移动速度差异巨大。得分、血量等状态变量作用域混乱重开后残留上一次的数据。最高分读出来了但没写回去或者写到了不同的 key。这些都是“能运行但没验证”的典型表现。避免方法只有一个把“实际玩一遍完整流程”作为强制验收步骤并且要求 Agent 自己记录测试结果。如果 Agent 不具备这种自测能力就由人来补上。4.2 资源、兼容性、加载速度AI 生成素材时经常使用外部链接比如网络图片或字体。这有两个风险一是外链失效游戏界面突然裂开二是本地开发正常、上线后因路径或跨域问题加载失败。稳妥做法是要求所有静态资源下载到本地并确认引用的是相对路径。性能方面浏览器游戏要特别注意内存和帧率。一个常见错误是每帧创建新对象而不清理玩几分钟后明显卡顿低配置机器上更明显。验证方式是打开浏览器开发者工具看内存曲线连续玩五分钟后数值没有持续上升基本算正常。如果游戏卡顿优先检查三处有没有在循环里反复创建对象、有没有事件监听重复绑定、有没有大尺寸图片没有压缩。4.3 “发布成功”和“真的可用”的区别我把“shipped”拆成四个判断标准地址能访问。首屏在合理时间内正常渲染。核心玩法至少 95% 的操作路径可完成。多次访问后没有崩溃和资源错误。很多 agent demo 只满足第一条。真正的发布还意味着用户不需要做任何额外设置不需要本地跑代码打开链接就能玩。如果游戏必须本地起服务器才能跑那它只是“生成完成”不是“发布完成”。5. 怎么判断 Agent 是真的完成了5.1 打分维度我给人审环节设计了一个简单的评分表按这个打分基本能看出 Agent 是“真做完了”还是“表面完成了”维度判断方式合格线功能完整度跑完整流程试所有按钮和操作核心流程全部可走通代码可读性打开 JS 文件看结构是否清晰有没有大量重复死代码能在 10 分钟内定位到某个逻辑自测充分性看日志记录或测试脚本有没有覆盖关键路径至少覆盖启动、交互、结算三类发布完整性线上地址无 404静态资源均本地化无资源错误可维护性有基础文件结构不是只有单个巨型文件可以增量改功能这个打分表不是给 AI 跑的是给人用的。AI 做完了你要拿它做最终仲裁。5.2 需要人工复核的关键点在自动化完成的东西里有几个位置仍然值得人去看一眼提示词有没有被曲解比如你要竖屏适配它做成了横屏。有没有引入来源不明的资源包如果 Agent 从网上下载了素材要确认授权情况。部署账号和密钥如果部署过程涉及账号登录要检查密钥有没有被写进公开文件。线上是否可回滚发布版本和源代码要能对应上。这些不是代码问题而是“产品交付”问题。Agent 不会替你考虑版权和运维它只会按指令执行。你负责的是边界、安全和最终判断。6. 常见失败模式与排查链路6.1 现象分类跑这类任务时失败现象基本集中在五类现象常见原因优先排查位置白屏JS 报错中断执行或入口文件路径错误控制台报错、资源路径卡死无限循环、资源占用过高游戏循环、事件绑定功能缺失页面正常但按钮无响应事件绑定、作用域、脚本加载顺序发布后不一致本地正常、线上坏了相对路径、构建产物Agent 反复修改但问题不变它没拿到真正的报错信息日志收集方式、提示词信息量6.2 排查顺序遇到问题我建议按这个顺序排查不要上来就让 AI 重写先看现象发生位置本地还是线上首次打开还是操作后出现。再看浏览器控制台有没有红色报错报错指向哪个文件哪一行。再看网络面板有没有资源 404、超时、跨域。再看代码结构报错文件是哪一层逻辑引用顺序是否正确。最后再决定是让 AI 修改还是人工介入。一个很实用的原则把原始报错信息原样丢给 Agent而不是转述。转述会丢失细节Agent 很容易在错误的方向上打转。如果你觉得 Agent 越修越乱就退回上一版把修改范围缩小一次只改一个问题。7. 我建议怎么玩这件事7.1 适合场景与上手节奏如果你想自己试我的建议顺序是先选一个 300 行内能写出来的小游戏比如贪吃蛇、打砖块、飞机射击。用上面的验收标准做模板让 Agent 完成第一版。本地跑通后再让它做发布。上一步稳了再把玩法复杂度加上去比如增加关卡、道具、音效。最后再考虑多人、排行榜、数据上报等功能。之所以不建议一上来就做大项目是因为 AI agent 的上下文和纠错能力都有边界。项目越大越容易出现“前面写得好后面忘了约束”的情况。小游戏正好能暴露这些问题而且返工成本低。如果只是学习默认配置和简单部署通常够用。我一般会先用小样本验证跑通一个小游戏确认流程中的每一步都能控制然后才把更复杂的项目交给 agent。7.2 边界什么情况不要指望全自动必须说清楚几个不适合全自动的场景需要登录、支付、用户数据的游戏涉及后端和合规Agent 很难一次搞定。需要大量原创美术、音频的项目Agent 生成素材质量不稳定版权也不容易保证。对性能要求很高的实时 3D 游戏需要很多手工优化自动化只能做初稿。需要持续运营、埋点、数据分析的产品发布只是开始后面才是大头。真正的经验是把 AI agent 当成一个能快速完成初稿的执行者而不是替代你思考的产品负责人。它擅长的是把明确需求变成可运行代码并且能自动完成静态站点的部署。它不擅长的是帮你定义“好玩”和“值得做”。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。提示词里的边界条件写得越清楚Agent 翻车的概率越低验收标准定得越明确你判断“做完”和“没做完”就越容易。所以所谓“on its own”不是它从零到一替代了你而是你把验收标准、边界条件和人工检查点设计好之后它能把整个执行路径走完。能做到这一步已经比单纯用代码补全工具前进了一大截。