当 AI 编程助手第一次能补全一个函数时很多人觉得它不过是个“高级输入法”后来它能通过对话生成一整个页面大家又认为这是更聪明的“搜索聚合”但如果一个 AI agent 接到一句“做个浏览器游戏并上线”的需求然后自己完成编码、调试、提交、部署事情就开始变得不一样了。最近 Hacker News 上有一个很受关注的帖子标题大意是“我的 AI agent 自己构建并发布了一款浏览器游戏”。很多人的第一反应是这游戏是不是太简单了但真正值得关注的不是游戏本身而是“Agent 独立完成交付闭环”这件事。作为开发者我们真正该问的问题不是“Agent 会不会取代程序员”而是一个 Agent 要在什么条件下才能把“从需求到上线”这条链路跑通它为什么选择浏览器游戏作为验证场景如果我想复现这个流程应该怎么设计任务、配置环境和控制风险这篇文章会从原理讲到落地先拆解 AI Agent 与普通编程助手的本质区别再给出一个可以照做的浏览器游戏交付流程包括任务描述、文件结构、代码示例、验证命令和部署配置。文末会补充常见问题和安全边界尽量让看完的人能自己动手跑一遍而不是停留在“AI 很厉害”的感叹里。1. 一个把“想法”变成“已上线游戏”的 Agent意味着什么先看这个 Show HN 帖子的核心事实一位开发者给 AI agent 下了一个任务让它在浏览器里做一个可玩的游戏并且要求最终能发布上线。Agent 自己完成了项目初始化、代码编写、本地运行检查、问题修复、Git 提交甚至可能还包括触发部署流水线的操作。最终一个可以通过链接访问的浏览器游戏诞生了。如果只看“做了一个石头剪刀布”或者“做了一个贪吃蛇”你可能会觉得这没什么。但关键在于这个任务是“端到端”完成的。它不再是一问一答的代码生成而是 Agent 在模仿一个真实开发者的工作方式接收需求。拆解任务。创建文件和目录。编写代码。启动服务验证。读取报错并修复。提交代码。触发部署。确认线上结果。这串流程里最容易被低估的环节是“验证”和“修复”。很多 AI 编程工具都能生成代码但如果生成的代码运行不起来用户还是要自己复制、粘贴、执行、看报错再手动反馈给模型。Agent 的价值在于它可以把“生成—运行—报错—再生成”这个循环自己跑完直到任务达到预设的完成标准。浏览器游戏成了这类验证的绝佳场景原因也很直接它是纯前端项目产物是静态文件不需要复杂后端。交付标准明确“页面能打开、游戏能玩”就是完成。可以自动化验证比如启动本地服务后用 curl 检查返回状态。部署简单直接托管到 GitHub Pages 或静态服务器即可。交互反馈明显游戏功能对不对一测就知道。所以说这个 Show HN 帖子真正传递的信号不是“AI 已经会做游戏了”而是“AI agent 的自主执行能力已经可以覆盖一条完整的交付链路”。对于开发者来说这意味着我们评估 AI 工具的标准要从“它能不能写代码”升级到“它能不能对结果负责”。2. AI 编程工具的三级跳Copilot、生成式对话与 Agent 到底差在哪要理解 Agent 的突破先要搞清楚它和过去几类 AI 编程工具有什么区别。第一类是补全型工具代表是各种 IDE 里的代码补全插件。它的工作方式是“预测你接下来要写什么”给出单行或几行建议。它解决的是“打字速度”问题不会主动创建文件也不会帮你运行程序。第二类是对话型生成工具。你可以在对话框里描述需求它返回一段代码或一个可复制的文件。它解决的是“从零生成样板代码”的问题但你仍然要做搬运工把代码复制进项目、手动安装依赖、运行、看报错、再粘贴给模型。整个过程是“人驱动”的模型没有操作系统文件或执行命令的能力。第三类才是 Agent。它不是一个单次问答而是一个会循环执行任务的系统。Agent 的核心差异有四个能力维度补全型工具对话型生成工具AI Agent交互方式逐行建议一问一答一次任务多步执行工具调用无无或有限可读写文件、执行命令、调用 API验证能力无无可以运行测试、查看结果、自动修复完成标准用户自己判断用户自己判断可设定“完成定义”并自我检查如果打个比方补全型工具像一个词汇量很大的输入法对话型生成工具像一个能替你写初稿的实习生而 Agent 更像一个“收到需求后会自己干活干完再向你汇报”的远程协作者。当然Agent 并不是万能的。它本质上仍然依赖底层大模型的推理能力。如果模型不理解需求后面的执行步骤都会跑偏。它还需要“工具”——没有文件读写、命令执行、网络请求这些能力Agent 就只是一个高级聊天机器人谈不上“自主构建”。所以当你看到一个 Agent 自己发布了一款浏览器游戏时背后的技术栈至少包含三样东西一个能理解任务并生成代码的大模型。一个能调用外部工具的 Agent 运行框架。一个明确的“完成定义”让 Agent 知道做到哪一步才算结束。下一节会把这三样东西拆开来讲。3. Agent 构建浏览器游戏的核心原理计划、执行、验证、修正如果只用一个词总结 Agent 的工作方式我会选“循环”。它不是一个“输入—输出”的过程而是“计划—执行—验证—修正—再执行”的循环。3.1 计划把大任务拆成小步骤接到“做一个浏览器游戏并发布”这个需求后Agent 需要把它拆成可操作的子任务确定游戏类型和规则。创建 HTML/JS/CSS 文件。实现游戏逻辑和界面交互。启动本地静态服务器。验证页面能否访问。检查 JavaScript 是否有语法错误。运行游戏逻辑确认核心功能可用。提交代码并触发部署。这一层相当于一个开发者拿到需求后做的“技术方案”。Agent 怎么做计划取决于底层模型的推理能力。这也是为什么任务描述写得越清楚Agent 的执行效果越稳定。3.2 执行调用工具而不是只输出文本Agent 和普通聊天工具最本质的区别在这里体现得最明显。普通聊天工具只会输出 Markdown 代码块剩下的事全部交给用户。而 Agent 会直接用文件写入工具创建index.html。用终端工具执行npm install或npx serve。用 Git 工具执行git add和git commit。用 API 工具触发部署。每一步都对应真实的系统动作。这也意味着Agent 的权限范围直接决定了它能做什么。如果它没有文件写入权限就不可能“构建”任何东西如果它没有网络权限就不可能“发布”任何东西。3.3 验证Agent 如何知道自己做对了这是很多初识 Agent 的人最容易忽略的一点。Agent 不能靠“感觉”判断代码对不对它需要主动去检查。常见的验证方式包括启动本地服务用curl查看 HTTP 状态码。用 Node.js 运行 JavaScript 文件检查是否有语法错误。打开浏览器开发者工具查看 Console 是否报错。用git status确认所有文件都在。访问部署后的 URL确认线上服务正常。验证能力决定了 Agent 是一个“会写完就跑”的工具还是一个“能交付结果”的工具。在上面的 Show HN 案例中Agent 能持续运行直到游戏可玩说明它的工作流里包含了“验证失败→读取错误→修复→重新验证”的闭环。3.4 修正反馈循环是 Agent 的灵魂如果验证通过Agent 会进入下一步如果验证失败它会把报错信息作为新的上下文重新生成代码。这个循环可以反复执行直到满足终止条件。这个机制也解释了为什么 Agent 经常需要“记忆”或“上下文管理”。每一轮循环都会产生新的日志和报错如果 Agent 不保留关键信息它很容易忘记原始需求或者在同一个错误上反复打转。所以Agent 的工程实现里上下文管理和任务状态追踪往往决定了它能不能稳定跑完复杂任务。3.5 为什么浏览器游戏适合做验证场景浏览器游戏对这个循环几乎友好到“量身定做”产物是静态文件创建和验证的成本低。不需要数据库不涉及鉴权减少不确定性。部署到 Pages 类服务后可以通过 URL 访问验证链路完整。出错时能直接看到页面表现反馈直观。如果你是一个刚开始接触 Agent 开发的开发者我建议你的第一个 Agent 任务也选这种“范围小、反馈强”的静态项目。先跑通闭环再逐步增加任务复杂度。4. 复现一个 Agent 游戏项目前需要准备的环境与工具下面是准备环节。这里不写死具体版本号因为不同 Agent 框架、模型服务和部署平台的要求一直在变。核心思路更重要。4.1 硬件与系统环境你只需要一台能运行代码的电脑Windows、macOS 或 Linux 都可以。浏览器游戏是纯前端项目对硬件要求很低。Agent 本身的运行开销主要体现在模型推理上如果使用远程模型 API本地几乎不需要 GPU如果你打算在本地部署开源模型则需要看模型的参数规模来决定硬件配置。4.2 编程语言与运行时需要安装 Node.js因为静态服务器、JavaScript 语法检查等工具通常依赖它。具体版本请以你项目实际需要为准一般建议使用当前 LTS 版本。4.3 Agent 运行框架你可以选择市面上流行的 Agent 开发工具也可以自己写一个简化版。不管选哪种核心能力必须满足可以接收多步骤任务描述。可以调用文件读写工具。可以执行终端命令。可以读取命令输出并作为下一步决策依据。可以设置最大循环次数或成本上限。如果你选择自己搭建最小实现思路是用一段脚本来驱动模型循环每轮根据模型输出决定调用什么工具然后把工具结果返回给模型再进入下一轮。4.4 大模型服务Agent 的“脑子”来自大模型。常见的选择包括热门商用模型 API 和开源模型。你只需要在 Agent 框架中配置好模型服务的访问密钥。这里要特别注意密钥属于敏感凭证不要把包含密钥的配置提交到公开仓库。4.5 代码仓库与部署平台为了让 Agent 实现“发布”你需要一个代码托管平台和静态网站服务。很多平台支持从 Git 仓库自动部署静态页面比如 GitHub Pages 就是一个常见方案。你可以提前创建一个空仓库并配置好部署权限。4.6 本地目录准备建议把所有实验文件放在一个独立目录中例如mkdir ai-browser-game-demo cd ai-browser-game-demo git init这样做的原因是Agent 会在目录中自由创建和修改文件。如果把它放在系统关键目录或者和生产项目混在一起风险会明显增加。5. 核心流程拆解从“一句话需求”到“游戏上线”前面准备完成后下面是一个典型的 Agent 自主交付流程。你不需要完全照搬重点是要理解每一步它做了什么、为什么需要这一步。5.1 编写任务描述任务描述是整个流程中最关键的输入。你可以把 Agent 的初始提示词设计成下面这样你是本项目的开发工程师。请在一个空目录中从零创建一个可直接上线运行的“石头剪刀布”浏览器游戏。 要求 1. 使用原生 HTML、CSS、JavaScript不使用框架不引入远程依赖。 2. 页面在桌面和手机浏览器都能正常显示。 3. 记录玩家与电脑的比分。 4. 完成后启动本地静态服务器用 curl 验证页面可以访问并检查 JavaScript 语法。 5. 最后在 Git 仓库中提交全部文件推送到 main 分支触发 GitHub Pages 部署。注意第 4 条和第 5 条。它们不是游戏需求而是“完成定义”。这会告诉 Agent它不能只生成代码就算完还要自测、提交、部署。很多 Agent 任务半途而废就是因为“完成定义”不清晰它做完自己理解的一步就停了。5.2 Agent 拆解任务并创建文件收到任务后Agent 会先规划文件结构。一个典型的纯前端游戏项目会包含ai-browser-game-demo/ ├── index.html ├── style.css ├── game.js └── .github/ └── workflows/ └── deploy.yml然后它会逐个创建文件。每创建一个文件理论上都可以通过文件写入工具完成。5.3 运行验证当核心代码写完后Agent 会执行类似下面的命令npx serve .然后尝试用curl检查页面curl -I http://localhost:3000如果返回200说明页面能访问。如果 JS 有语法错误它可能会用 Node 做一次检查node --check game.js如果这一步发现错误Agent 会读取错误信息定位到问题行修改代码然后重新验证直到通过。5.4 提交代码并触发部署验证通过后Agent 会执行 Git 操作git add . git commit -m feat: rock paper scissors game git push origin main如果你的仓库配置了 GitHub Pages 部署工作流push 动作就会自动触发部署。5.5 验证线上结果最后一步是访问线上地址确认游戏真的可以打开。这一步也是验证闭环的终点。如果部署失败Agent 需要检查流水线日志修复后再次推送。6. 完整示例让 Agent 交付一个“石头剪刀布”浏览器游戏下面给出完整的示例代码。这些代码展示的是 Agent 在完成该任务时通常需要产出的文件形态。你可以把它们放到一个空目录中手工复现整个项目也可以把这些内容作为“参考答案”用来检查 Agent 的输出是否合格。6.1 文件结构ai-browser-game-demo/ ├── index.html ├── style.css ├── game.js └── .github/ └── workflows/ └── deploy.yml6.2 index.html!-- 文件路径index.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0 / title石头剪刀布/title link relstylesheet hrefstyle.css / /head body main classgame h1石头剪刀布/h1 p classscore 玩家 span idplayerScore0/span span idrobotScore0/span 对手 /p div classchoices button>/* 文件路径style.css */ body { margin: 0; font-family: system-ui, sans-serif; background: #f5f0eb; display: grid; place-items: center; min-height: 100vh; } .game { background: #ffffff; border-radius: 12px; padding: 32px; box-shadow: 0 8px 24px rgba(0, 0, 0, 0.08); text-align: center; width: min(90vw, 420px); } .choices { display: flex; gap: 12px; justify-content: center; flex-wrap: wrap; margin: 24px 0; } .choices button { font-size: 18px; padding: 12px 24px; border: none; border-radius: 8px; background: #3b7cff; color: #ffffff; cursor: pointer; transition: transform 0.1s ease; } .choices button:hover { transform: scale(1.05); } #result { font-size: 18px; min-height: 28px; }6.4 game.js// 文件路径game.js const choices [rock, paper, scissors]; const nameMap { rock: 石头, paper: 布, scissors: 剪刀 }; let playerScore 0; let robotScore 0; document.querySelectorAll(.choices button).forEach((button) { button.addEventListener(click, () { const playerChoice button.dataset.choice; const robotChoice choices[Math.floor(Math.random() * choices.length)]; const result getResult(playerChoice, robotChoice); updateScore(result); document.getElementById(result).textContent 你出了${nameMap[playerChoice]}对手出了${nameMap[robotChoice]}。${result}; }); }); function getResult(player, robot) { if (player robot) return 平局; const winMap { rock: scissors, scissors: paper, paper: rock }; return winMap[player] robot ? 你赢了 : 你输了; } function updateScore(result) { if (result 你赢了) { playerScore; } if (result 你输了) { robotScore; } document.getElementById(playerScore).textContent playerScore; document.getElementById(robotScore).textContent robotScore; }这段代码的核心逻辑在getResult函数里。它用一个映射表winMap描述三种出招的克制关系石头赢剪刀剪刀赢布布赢石头。这个写法的好处是逻辑清晰、容易验证Agent 在自测时也能很快找到规则错误。6.5 GitHub Pages 部署工作流# 文件路径.github/workflows/deploy.yml name: Deploy game to GitHub Pages on: push: branches: [main] permissions: contents: read pages: write id-token: write jobs: deploy: runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - name: Checkout repository uses: actions/checkoutv4 - name: Configure GitHub Pages uses: actions/configure-pagesv5 - name: Upload static artifact uses: actions/upload-pages-artifactv3 with: path: . - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pagesv4这是一个常见的静态站点部署工作流。它的思路是只要有代码推送到main分支流水线就会被触发把当前目录作为静态文件发布出去。这里要提醒一句工作流中的 action 版本号会更新你在实际使用时以当前可用版本为准。7. 运行与验证如何判断 Agent 真的把游戏做完了判断 Agent 是否完成不能只看它说“完成了”要用命令验证。7.1 启动本地服务npx serve .7.2 检查页面是否可访问curl -I http://localhost:3000预期输出中会出现HTTP/1.1 200 OK或HTTP/2 200状态码。7.3 检查 JavaScript 语法node --check game.js如果没有任何输出说明语法检查通过。如果有报错会显示具体行号。7.4 查看 Git 提交状态git log --oneline确认最新的提交记录了游戏相关文件。7.5 检查线上部署部署触发后等待几分钟然后访问你的 Pages 地址。如果页面能正常显示并且游戏可以交互整个闭环才算真正打通。这里要强调的是Agent 的自验能力和我们手动验证是一致的。它只有通过curl、node --check、git status等命令拿到真实反馈才能确认任务完成。这也是为什么让 Agent 做纯前端游戏时结果更可控——所有验证都可以用命令行完成。8. 常见问题与排查思路Agent 不是一跑就通下面列出几个常见问题问题现象可能原因排查方式解决方案Agent 生成代码后停止没有继续验证任务描述里没有定义完成标准查看 Agent 运行日志确认它在哪一步停止在初始提示词中明确要求启动服务、curl 验证、提交并部署生成的页面在浏览器中白屏JS 文件路径错误或存在运行时异常打开浏览器 Console 查看报错让 Agent 读取浏览器日志修复相对路径和语法问题Agent 在同一个错误上反复修改上下文窗口被大量日志占满丢失原始需求检查上下文内容确认 Agent 是否还知道最终目标手动打断给它简明错误摘要或把任务拆成更小的子任务部署流水线失败GitHub Actions 配置或权限不正确查看 Actions 运行日志定位失败步骤检查工作流中的权限配置和 artifact 路径模型调用费用偏高验证循环次数太多或初始需求过于模糊检查 Agent 的执行步数和模型调用次数设置最大迭代数把初始需求写得更具体减少试错空间Agent 没有权限执行命令运行框架的终端工具未开启检查 Agent 的工具配置在受控环境中开启必要的命令执行权限在实际操作中最常踩的坑是两个。第一任务描述里只写了“做一个游戏”没有写“怎么算做完”所以 Agent 生成了文件就停了。第二Agent 被赋予了文件读写权限但没有部署权限结果是代码在本地能跑却无法上线发布。一定要在任务开始前想清楚“完成”包含哪些动作。9. 安全边界与工程最佳实践我在上面反复强调 Agent 的本质是“自主执行命令的系统”。既然它能执行命令就必须控制边界。下面是几条比较重要的建议。9.1 用独立目录隔离项目不要让 Agent 在自己的生产项目目录里直接操作。新建一个空目录或者使用容器环境把任务限制在最小范围。这样即使 Agent 误删文件或改错配置影响也有限。9.2 小权限原则给 Agent 的最小权限是它能完成任务所需要的权限。比如如果任务只是写代码就不需要给它生产环境的凭据如果任务是发布到 Pages只需要给它推送指定仓库的权限。不要直接把云服务器管理员密钥暴露给 Agent。9.3 密钥和敏感信息单独管理像模型 API 密钥、部署令牌这类信息应该通过环境变量或密钥管理服务注入而不是写在任务的提示词里更不应该提交到 Git 仓库。Agent 可能会把上下文中的内容写进文件一旦密钥被提交到公开仓库后果很严重。9.4 设置循环上限和成本上限Agent 的循环机制在解决复杂问题时很有效但也可能因为目标不明确而陷入无限循环。max_iterations: 20 max_cost: 5上面的配置是一种最朴素的思路代表“最多执行 20 步最多消耗价值 5 个单位的模型费用”。不同 Agent 框架的配置方式不同但这两个概念值得在所有场景中使用。9.5 使用分支和人工确认发布操作不要完全无人值守。可以要求 Agent 先推送到一个临时分支开发者在本地产看后再合并到main分支触发部署。这样既保留了 Agent 的自主性也给人工审查留了一道闸门。9.6 记得审查 Agent 生成的依赖如果 Agent 选择引入第三方依赖需要人工确认这些依赖是否安全。对于纯前端静态游戏尽量要求“不引入远程依赖”这样可以显著减少供应链风险。9.7 保留运行日志Agent 在哪个步骤做了什么事情日志里都应该有记录。如果后续出现问题或者需要复现某一个操作完整日志就是最直接的证据。10. 从“会写代码”到“能交付结果”Agent 的边界在哪里回到开头那个 Show HN 帖子。AI agent 能够自行构建并发布浏览器游戏是一件值得关注的事但关注点不应该停留在“游戏”上而应该放在“交付闭环”上。它说明当前 AI 编程的方向正在从“辅助人写代码”转向“对结果负责”。开发者在这个趋势里最需要掌握的新能力是如何定义任务、如何设定期望、如何设计验证标准。这篇文章展示了从需求到上线的完整路径给定一个清晰的浏览器游戏需求在独立目录中赋予 Agent 文件读写、命令执行和部署权限它就能通过“计划—执行—验证—修正”的循环交付一个可访问的线上页面。如果你现在想把 Agent 用在真实项目中建议从一个小范围的静态项目开始。把任务描述写得足够具体把“完成定义”写清楚把运行目录和密钥权限控制好。跑通第一个“让 Agent 独立交付一次”的流程比研究各种复杂框架都更有价值。后续你还可以继续尝试更有挑战的方向比如让 Agent 自己处理更复杂的用户交互、接入真实数据库、或者在一个受限环境中完成带后端的项目。那时你会更清楚地体会到Agent 开发真正考验的不是模型有多聪明而是你定义问题和控制边界的能力。