企业官网建设流程全解析

最近 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 的转换”。下面这张表可以帮你快速判断它值不值得试：

从材料看，这件事的关键不是模型能力，而是“过程控制”。你有两种做法：

• 人工在中间协调：用 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.html，CSS 和 JavaScript 内联在同一个文件里。 需求： - 游戏名称：接苹果的小篮子 - 玩法：鼠标控制篮筐左右移动，接住从顶部掉落的苹果，苹果落地则减命 - 界面：顶部显示分数和剩余生命，背景使用浅色渐变 - 兼容：在 Chrome 和手机上都能玩，手机端通过触摸控制 - 加分项：每接住 10 个苹果，下落速度提高一档

这个 Prompt 的关键信息含量很高：有角色设定、有交付物格式、有玩法描述、有界面约束、有平台兼容要求、有明确的迭代方向。你还可以继续要求“整个项目控制在 300 行以内”“给关键函数写注释”等，把 Agent 的输出约束到更容易审查的范围内。

4.2 生成第一版代码

拿到 Prompt 后，把内容粘贴到 AI 工具里，它通常会生成一个完整的index.html。如果是网页版对话工具，输出框里会有完整源码，你需要复制到一个文件里保存。如果用的是 Cursor 或 Copilot 这类编辑器工具，可以直接让它在项目目录中新建文件并写入。

下面给出一个非常小但完整的单文件游戏示例，它代表 Agent 常见输出风格：一个 Canvas 画布、几行游戏逻辑、一段内联 CSS。这个例子不是某个特定 Agent 的产物，而是展示“单文件浏览器游戏”的最小形态：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.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 id="game" width="400" height="600"></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.js：

npx 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 vercel

CLI 会引导你登录、关联项目、选择部署范围，最后输出一个线上 URL。这个命令适合手动触发；如果你想要更自动化的流程，见第 6 节。

5. 功能测试与效果验证

Agent 把游戏生成出来、部署上线，这只是起点。真正判断它靠不靠谱，要看能不能过一轮系统化测试。下面是一套可以套用的验证清单：

如果你在测试中发现 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/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 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-pages@v4 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, json=payload, headers=headers, timeout=120) content = response.json()["choices"][0]["message"]["content"] with open("index.html", "w", encoding="utf-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 在修改代码时，可能把原来的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 能自动交付的不只是一个游戏，而是一整套轻量前端产物的生产线。