最近 Hacker News 上出现过一个很吸睛的标题Show HN: My AI agent built and shipped a browser game on its own。翻译过来就是我的 AI Agent 自己写完了一个网页小游戏并且自己把它发布上线了。这个标题能引起讨论不是因为 AI 会写代码而是“自己发布”这四个字写代码的工具已经很多但完整走完需求转述、代码生成、本地验证、Bug 修复、静态部署、线上可访问这条链路才是 Agent 价值真正外溢的地方。如果你平时关注 AI Agent 开发应该能感觉到现在最大的难点不是让模型“生成一段代码”而是让它像一个真正的开发者那样对结果负责跑起来、看到报错、自我修复、最终把产物放到一个能被别人访问的地址。浏览器游戏恰好是一个非常适合验证这条链路的载体。它不用 GPU、不用后端数据库、不需要处理复杂鉴权一个 HTML 文件加上内联的 CSS 和 JavaScript就可以成为完整的交付物。把这类任务交给 Agent 来跑既能看到它在多步任务中的规划能力也能观察到它在出错时的恢复能力。这篇文章会把“AI Agent 独立构建并发布浏览器游戏”从概念拆成可复现的流程。我会围绕三类读者来写想用 AI 快速做网页小游戏原型的前端开发者、在研究 Agent 工作流的 AI 应用开发者以及完全没接触过 Agent但想知道这事到底有没有实用价值的产品和内容从业者。你会看到一套完整的操作路径环境准备、Prompt 设计、代码生成、本地验证、自动部署、常见问题排查以及上线前必须注意的合规边界。需要先说明一点原始 Show HN 帖子只保留了标题没有附带完整的公开仓库和实现细节。因此下面不会去“解读某个特定游戏项目的源码”而是按这一类项目最通用的工程流程展开。你可以直接照这套流程用自己手上的 Agent 工具复现同样的事情并且把它稳定化、工程化。1. AI Agent 构建浏览器游戏的核心能力速览在开始之前先给一个总览。了解 Agent 自动构建并发布浏览器游戏这件事本质上是一场“自然语言需求到线上 URL 的转换”。下面这张表可以帮你快速判断它值不值得试能力项说明任务类型从自然语言需求生成 HTML/CSS/JS 网页游戏并部署到静态托管平台输入一句游戏描述或结构化的需求文档输出可运行的网页源码、可访问的线上链接常见实现方式对话式 AI 编程 静态托管或 Agent 自动执行命令并部署代表工具Claude、ChatGPT、Cursor、GitHub Copilot 等 AI 编程工具配合 GitHub Pages、Vercel、Netlify、Cloudflare Pages 等托管平台最低硬件门槛能开浏览器的电脑即可游戏生成阶段依赖云端模型本机不需要 GPU是否支持 API取决于底层模型服务是否开放 API多数主流大模型对话服务提供 API是否支持批量任务单次生成一个游戏通常不是批量场景但 Agent 可以复用流程批量生成多个页面或改版适合场景原型验证、活动页小游戏、教学示例、内部工具前端、独立开发者的快速冷启动从材料看这件事的关键不是模型能力而是“过程控制”。你有两种做法人工在中间协调用 AI 编程工具生成代码自己手动在本地验证再手动推到 GitHub、Vercel 等平台发布。这种方式可控性最高适合新手。让 Agent 自动化更多环节Agent 直接操作终端、调用 Git 命令、运行本地服务器、调用托管平台 CLI 完成部署。这种方式更接近标题里的“on its own”但需要你提前配置好工具权限和触发条件。无论哪种做法浏览器游戏本身都是很轻量的产物通常只要一个静态页面就能跑起来。这也是为什么它很适合作为 Agent 自动化的演示场景省去了服务器、数据库、容器编排等大量干扰项让注意力集中在 Agent 的任务拆解和工具调用上。2. 适用场景与使用边界AI Agent 自动做网页游戏适合谁首先适合前端开发者做快速原型。你有一个游戏创意连设计稿都不用画直接一段 Prompt 扔给 Agent几分钟后得到一个可以在浏览器里玩的页面。你在这个基础上再修改美术风格、补充关卡逻辑比从空文件开始写要快得多。其次适合 AI 应用开发者研究 Agent 工作流。浏览器游戏是一个“小而完整”的任务非常适合用来测试 Agent 的规划能力、工具调用能力、报错恢复能力。你可以拿它当基准测试集让同一个 Agent 连续生成十个不同玩法的小游戏统计一次通过率、平均迭代次数、卡点在哪里。这就是一个很具体的 Agent 评测方法。不适合什么场景如果你要做的是大型商业游戏、需要复杂后端联机的网页游戏、包含大量美术资源和音频资源的 3D 项目现阶段不建议把整条链路交给 Agent 全自动完成。Agent 能给你一个可行的框架但资源管理、性能优化、用户体验调优仍然需要人工深度介入。使用边界也需要提前讲清楚。Agent 生成的游戏素材、图标、音效版权归属取决于你使用的模型服务条款和素材来源如果是用 AI 生成的角色或图片上线前需要确认服务是否允许商用。如果你把游戏部署到公共平台要避免在游戏里收集用户隐私信息或嵌入未知的第三方脚本。涉及用户上传内容、排行榜、社交互动时还需要考虑内容审核和未成年人保护。不是所有流程都适合“全自动”至少上线这一步建议保留人工检查。3. 环境准备与前置条件在开始之前可以把需要的环境分成两块本机环境和线上平台账号。本机环境并不复杂。你需要一个现代浏览器这是验证游戏的主战场还需要一个代码编辑器比如 VS Code方便查看 Agent 生成的代码如果你打算在本地启动静态服务推荐装一个 Node.js 或 Python用来跑本地 HTTP 服务器。这部分不依赖 GPU也没有显存概念绝大多数开发机都能满足。线上平台账号方面至少需要准备一个 GitHub 账号。GitHub 的免费仓库可以配合 GitHub Pages 直接托管静态页面这对发布浏览器游戏非常友好。如果你想用更自动化的方式可以再注册一个 Vercel 或 Netlify 账号它们支持从 Git 仓库自动拉取代码并部署也支持通过命令行工具直接上传。云平台账号的注册和实名认证规则以官方最新说明为准。还需要一个可用的 AI 编程工具。你可以用网页版的 Claude、ChatGPT也可以用 Cursor、GitHub Copilot 这类深度集成到编辑器的工具如果你打算走 API 自动化就提前准备好 API Key。这里有一个容易被忽略的点网页版 AI 通常不能直接帮你执行终端命令因此“自动部署”这一步往往需要借助支持工具调用的 Agent 框架或者通过复制粘贴、手动运行命令来完成。选择哪种方式取决于你想在“自动”这条路上走多远。最后是习惯层面的准备。我建议你为这类项目单独建一个目录比如ai-browser-game-lab不要让 Agent 生成的代码散落在桌面或下载文件夹里。目录结构可以这样安排ai-browser-game-lab/ ├── game-001-apple-catcher/ │ ├── index.html │ └── README.md ├── game-002-2048-clone/ └── shared/这样后续做批量测试、版本对比、回滚时会很省事。磁盘空间需求很低单个浏览器游戏通常不到 1MB一个实验室目录放几十个游戏也才几十 MB。4. 从零到上线给 Agent 下任务4.1 需求描述与 Prompt 设计Agent 生成游戏的上限取决于你给出的需求描述。最省事的 Prompt 模板是指定角色、交付物、玩法规则、界面要求、兼容性要求、加分项。下面给你一个可以直接复制的模板你是一个前端开发工程师。请把下面的需求实现为一个可在浏览器直接玩的游戏输出一个 index.htmlCSS 和 JavaScript 内联在同一个文件里。 需求 - 游戏名称接苹果的小篮子 - 玩法鼠标控制篮筐左右移动接住从顶部掉落的苹果苹果落地则减命 - 界面顶部显示分数和剩余生命背景使用浅色渐变 - 兼容在 Chrome 和手机上都能玩手机端通过触摸控制 - 加分项每接住 10 个苹果下落速度提高一档这个 Prompt 的关键信息含量很高有角色设定、有交付物格式、有玩法描述、有界面约束、有平台兼容要求、有明确的迭代方向。你还可以继续要求“整个项目控制在 300 行以内”“给关键函数写注释”等把 Agent 的输出约束到更容易审查的范围内。4.2 生成第一版代码拿到 Prompt 后把内容粘贴到 AI 工具里它通常会生成一个完整的index.html。如果是网页版对话工具输出框里会有完整源码你需要复制到一个文件里保存。如果用的是 Cursor 或 Copilot 这类编辑器工具可以直接让它在项目目录中新建文件并写入。下面给出一个非常小但完整的单文件游戏示例它代表 Agent 常见输出风格一个 Canvas 画布、几行游戏逻辑、一段内联 CSS。这个例子不是某个特定 Agent 的产物而是展示“单文件浏览器游戏”的最小形态!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title接苹果的小篮子/title style body { margin: 0; display: flex; justify-content: center; align-items: center; min-height: 100vh; background: linear-gradient(180deg, #bfe0f5, #f7f2d8); font-family: sans-serif; } canvas { background: #ffffff; border-radius: 12px; box-shadow: 0 10px 30px rgba(0,0,0,0.15); } /style /head body canvas idgame width400 height600/canvas script const canvas document.getElementById(game); const ctx canvas.getContext(2d); let basket { x: 175, width: 80, speed: 6 }; let apples []; let score 0; let lives 3; let speedUp 1; let keys {}; const player { width: 80, height: 20 }; document.addEventListener(keydown, e { keys[e.key] true; }); document.addEventListener(keyup, e { keys[e.key] false; }); // 手机端触摸控制 canvas.addEventListener(touchmove, e { const rect canvas.getBoundingClientRect(); const touchX e.touches[0].clientX - rect.left; basket.x touchX - basket.width / 2; e.preventDefault(); }); function spawnApple() { apples.push({ x: Math.random() * (canvas.width - 30), y: 0, size: 26, speed: (2 Math.random() * 1.5) * speedUp }); } function loop() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 键盘控制 if (keys[ArrowLeft] basket.x 0) basket.x - basket.speed; if (keys[ArrowRight] basket.x canvas.width - basket.width) basket.x basket.speed; // 生成苹果 if (Math.random() 0.015) spawnApple(); // 绘制与碰撞 apples apples.filter(apple { apple.y apple.speed; ctx.beginPath(); ctx.arc(apple.x, apple.y, apple.size / 2, 0, Math.PI * 2); ctx.fillStyle #e74c3c; ctx.fill(); const hit apple.y apple.size / 2 canvas.height - player.height apple.x basket.x apple.x basket.x basket.width; if (hit) { score 1; if (score % 10 0) speedUp 0.1; return false; } if (apple.y canvas.height) { lives - 1; return false; } return true; }); // 绘制篮筐 ctx.fillStyle #8e44ad; ctx.fillRect(basket.x, canvas.height - player.height, basket.width, player.height); // 分数与生命 ctx.fillStyle #333; ctx.font 18px sans-serif; ctx.fillText(分数: score, 12, 30); ctx.fillText(生命: lives, 320, 30); if (lives 0) { requestAnimationFrame(loop); } else { ctx.fillStyle #333; ctx.font 28px sans-serif; ctx.fillText(游戏结束, 115, 290); ctx.font 16px sans-serif; ctx.fillText(刷新页面重新开始, 120, 330); } } loop(); /script /body /html保存为index.html后双击用浏览器打开你就能看到一个可玩的基础游戏。如果你的 Agent 输出类似这个结构说明它理解了单文件交付的约束。4.3 本地验证把页面跑起来双击打开 HTML 文件确实能玩但最接近线上环境的验证方式是启动一个本地静态服务器。这样做的好处是后续部署到 GitHub Pages 或 Vercel 时页面资源路径不会因为file://协议而产生偏差。在项目目录下执行python -m http.server 8080或者如果你装了 Node.jsnpx serve -l 8080 .然后浏览器访问http://localhost:8080看到游戏页面可以正常操作后再做下一步。4.4 把报错反馈给 Agent完成自修复第一版代码很可能不是完美的。你把它跑起来后把出现的现象复制给 Agent最好的方式不是只说“不行”而是给出具体现象和控制台报错。比如游戏运行后苹果掉到篮筐位置没有计分控制台报错 Uncaught TypeError: Cannot read properties of undefined (reading x) 请定位 bug 并修复保持单文件结构。这种带上下文、带目标、带结果要求的反馈能明显提高 Agent 的修复准确率。你可以反复这个循环直到满足验收标准。4.5 发布上线GitHub Pages 或 Vercel本地验证通过后就可以发布。最稳妥的做法是新建一个 GitHub 仓库把index.html和必要的说明文件推送到仓库然后在仓库设置里开启 GitHub Pages选择 main 分支作为发布源。GitHub Pages 适合纯静态页面打开仓库设置里的 Pages 选项选择分支即可一般几分钟内就能通过https://用户名.github.io/仓库名/index.html访问。如果想让访问地址更干净可以用 Vercel。安装 Vercel CLI 后在项目目录里执行npm install -g vercel vercelCLI 会引导你登录、关联项目、选择部署范围最后输出一个线上 URL。这个命令适合手动触发如果你想要更自动化的流程见第 6 节。5. 功能测试与效果验证Agent 把游戏生成出来、部署上线这只是起点。真正判断它靠不靠谱要看能不能过一轮系统化测试。下面是一套可以套用的验证清单测试项测试方式通过标准页面可访问性打开线上 URL页面加载无白屏基础玩法按需求操作一遍核心玩法可完成键盘交互用方向键操作操作响应正常触摸交互用手机浏览器访问触摸可控制无误触计分逻辑连续得分和失分分数、生命值变化正确边界条件游戏结束、刷新重开状态能正确重置控制台报错打开 DevTools Console无红色报错移动端适配DevTools 设备模拟布局不严重溢出资源加载Network 面板检查无 404 或超大资源如果你在测试中发现 AI 生成的游戏有逻辑缺陷不要急着嫌弃 Agent 能力不行。第一个要检查的是需求描述是否足够具体。比如你没有说“苹果落地后要重置生命值”Agent 可能默认不做这个逻辑。这类问题不是模型幻觉而是需求缺项。第二要检查的是反馈信息是否完整把控制台报错、期望行为、实际行为三样东西一起给 Agent修复率会明显提高。为了让测试更有说服力我建议你对同一个 Prompt 跑多轮生成对比不同模型的输出差异。比如分别要求生成“同一种玩法的三个版本单文件、模块化、带本地存储最高分”然后观察结构质量、代码风格、处理边界事件的差异。这种横向对比比单次“生成成功”更有参考价值。6. 让 Agent 自动完成“构建 发布”自动化链路标题里说的“on its own”最核心的看点其实是自动化部署。单纯让 AI 写代码并不新鲜但写完后自动推到仓库、自动触发部署、自动拿到 URL就是一条完整的 Agent 工作流。实现它有两种常见路径。6.1 路径一走 GitHub Actions 持续部署第一种是把 Agent 生成的代码推到 GitHub然后让 GitHub Actions 自动构建并发布到 GitHub Pages。下面是一个纯静态页面的 GitHub Actions 工作流示例如果你的项目只是单 HTML 文件构建步骤可以直接省略name: Deploy to GitHub Pages on: push: branches: [main] permissions: contents: write jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install dependencies run: npm ci - name: Build run: npm run build - name: Deploy to GitHub Pages uses: peaceiris/actions-gh-pagesv4 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./dist如果游戏没有依赖npm ci和npm run build可以考虑去掉。核心逻辑是Agent 每次修改代码并推送到 main 分支工作流自动把构建产物发布到 Pages。这已经在“自动部署”上走出去了。6.2 路径二Agent 直接调用 CLI 或平台 API第二种是让 Agent 在本地环境里直接执行打包和部署命令。只要你的 Agent 工具支持终端调用它就可以在写完代码后自动运行git add、git commit、git push或者直接运行vercel --prod。这本质上不是模型会“自己动”而是你给了它一组工具权限。从工程安全角度我不建议让 Agent 每一步都全自动执行。更稳妥的方式是加入一个人工审批点代码生成后先让 Agent 停下来等你在本地验证通过后再执行部署命令。你可以把流程设计成这样Agent 负责写代码、自查、给出运行说明。人工负责本地验证、运行git push。Agent 或 CI 负责部署到线上。6.3 通过 API 将 Agent 输出接入部署流程如果你希望从模型 API 直接拿到代码并保存为文件再触发部署可以参考下面的通用 Python 调用模板。这里以常见的 Chat Completions 风格接口为例具体接口地址和模型名要以你实际使用的服务为准import requests api_url https://api.example.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { model: your-model-name, messages: [ {role: system, content: 你是一个前端开发工程师只输出可运行的单文件 HTML。}, {role: user, content: 生成一个 2048 小游戏输出为 index.html。} ], temperature: 0.3 } response requests.post(api_url, jsonpayload, headersheaders, timeout120) content response.json()[choices][0][message][content] with open(index.html, w, encodingutf-8) as f: f.write(content)拿到index.html后你可以把它提交到 Git 仓库GitHub Actions 会自动完成部署。这样一条链路下来“AI 生成代码 - API 接收 - 写入文件 - 提交 - CI 部署”就全串起来了。6.4 批量任务的思路浏览器游戏本身不是高频批量任务但同一套流程可以用于批量生产其他静态页面。比如你有一个活动需求需要生成 30 个不同主题的抽奖页面、答题页面或营销落地页。你可以写一个脚本读取 CSV 或 JSON 里的需求列表逐条调用模型 API把结果写入不同的目录再统一部署到静态托管平台。生成的配置示例{ task_name: batch-game-generation, input_file: ./tasks.json, output_dir: ./generated-games, deploy: { platform: github-pages, repo: yourname/ai-game-lab, branch: main } }这比一个一个手动生成效率高很多但建议每次批量前先做小样本测试确认输出质量稳定后再扩大规模。7. 资源占用与性能观察浏览器游戏本身的资源占用很低但它也值得观察几个性能点。页面加载后打开 Chrome DevTools 的 Performance 面板录制一段游戏操作可以看 FPS帧率是否稳定在 60 附近、主线程卡顿时间多长、内存有没有持续上升。Canvas 游戏常见的性能问题包括每帧创建太多临时对象、没有使用requestAnimationFrame、粒子数量和苹果对象没有对象池限制。如果 Agent 生成的游戏在低端手机上明显掉帧优先检查几个地方是否每帧都在绘制大面积渐变背景如果是可以用静态背景层替代。碰撞检测是否遍历了所有对象对象多时可以简化。resize 事件是否触发了频繁重绘可以做防抖处理。音效和图片资源是否过大适当压缩。对于 Agent 本身资源占用不是一个核心问题。网页版 AI 工具的计算发生在云端本地只消耗浏览器内存走 API 调用时主要消耗的是网络带宽和 API 额度。真正需要关注的是 API 调用超时长生成任务可能超过默认超时时间建议在调用代码里设置合理的 timeout并把生成任务拆成小步骤。8. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 生成的代码打开是白屏JS 存在运行时错误打开 DevTools Console 查看报错把报错反馈给 Agent让其修复本地可以运行部署后样式丢失资源路径写成了相对或绝对路径混乱F12 看 Network 面板请求状态统一使用相对路径或改用单文件内联部署后访问 404GitHub Pages 发布分支或路径配置错误检查仓库 Settings 里的 Pages 选项确认发布分支和目录正确手机上无法触摸操作代码未监听 touch 事件检查事件绑定代码补充 touchstart/touchmove 监听API 调用超时模型生成过长文本或网络波动查看服务日志和响应时间增加 timeout减少单次输出长度Agent 总是改错位置需求描述不清晰检查 Prompt 是否包含角色、格式、验收标准用结构化 Prompt 模板重试游戏画面闪烁或卡顿Canvas 性能优化不足用 Performance 面板分析减少每帧绘制量使用对象池推送到仓库后没有触发部署GitHub Actions 配置或分支名错误查看 Actions 运行日志检查分支名和 secrets 配置还有一个很容易踩的坑Agent 在修改代码时可能把原来的index.html整体重写导致你自己写好的额外功能丢失。所以每次让 Agent 修改前建议先提交一次 Git 版本或者把当前文件备份一份。这样迭代出错时可以快速回滚。9. 最佳实践与使用建议第一先小参数测试再扩大规模。第一次让 Agent 生成游戏不要直接提“做一个完整的 RPG”先选一个 100 到 200 行能搞定的玩法比如贪吃蛇、打砖块、简易跑酷。跑通全流程后再增加复杂度。这个策略既能让模型更容易给出高质量结果也能让你更快掌握验证和部署方法。第二把 Prompt 当成项目文档来维护。如果你要生成一系列游戏建议维护一个prompts目录每个游戏对应一个.txt文件里面写清需求版本、修改记录、已知问题。后续让 Agent 做修改时把历史 Prompt 和当前目标一起提供它能更快理解上下文。第三上线前必须做人工检查。即使 Agent 全自动完成了构建和发布人工检查这一步不应该省。至少要看一眼页面能不能打开、有没有明显的敏感内容、输入框有没有注入风险。如果游戏要发布到公开网络还要检查生成素材的授权范围。这里不只是合规问题也是责任问题发布者要对线上内容负责不能把全部判断交给 Agent。第四给公网访问加边界。如果你的游戏只是内部演示可以用 Vercel 的访问保护功能或者把部署平台的项目设置为 private。公开项目则不要放 API Key、数据库连接字符串、个人信息等敏感内容。Git 历史里也检查一下确保没有把密钥提交进去。10. 总结与下一步这个 Show HN 标题背后最值得尝试的点不是“AI 会写游戏”而是一条从想法到 URL 的完整自动化链路。浏览器游戏作为验证场景成本低、反馈快、可公开访问非常适合用来测试 Agent 的任务拆解和工具调用能力。如果你现在就想动手建议按这个顺序来先用一个最简单的单文件游戏 Prompt 跑通生成再在本地验证并修复一轮 Bug然后把项目推到 GitHub 开启 Pages最后再尝试用 GitHub Actions 或 Vercel 做自动部署。每一步都是上一个步骤的自然延伸不需要一下子追求全自动。最容易踩的坑是跳过验证直接发布。AI 生成的代码看着像模像样但逻辑错误、路径问题、兼容性缺陷都很常见。先跑通本地验证再谈自动化发布整个流程会更稳。后续你可以继续扩展给游戏加排行榜、接数据库保存成绩、用 AI 生成多套美术风格做 A/B 测试甚至把同一套 Agent 流程复用到别的静态页面生产任务上。这条路走通之后Agent 能自动交付的不只是一个游戏而是一整套轻量前端产物的生产线。