企业官网建设流程全解析

“AI agent 自己写代码、自己测试、自己把游戏发布上线”这件事，最近在开发者社区里被讨论得很多。我把它当成一个很值得实测的课题：让它独立做完并且发布一个浏览器游戏，从一句自然语言需求开始，到最终用户能在浏览器里打开即玩。这种任务的真正价值不在于“AI 能不能写一段游戏代码”，而在于一条完整的闭环——需求理解、代码生成、运行验证、错误修复、部署交付——是不是真的能由 agent 自己走通。

适合看这个主题的人有三类：正在用 AI 编程工具做小产品的开发者，想了解 AI agent 能力边界的产品经理，以及想低成本验证游戏创意的独立开发者。

先说我的核心判断：在“单页、无后端、静态部署”的游戏项目上，AI agent 已经能做到相当高的完成度。但“shipped”这个词很容易被低估——把代码推到线上不等于交付完成，真正的发布还包括域名访问、移动端体验、资源加载、故障回退这些环节。下面按我从需求到发布实际跑一遍的顺序拆开讲。

1. 先搞清楚：“AI 自己做完并发布”到底包含了哪几步

1.1 从提示词到产品，中间不是只有写代码一件事

很多人对 AI agent 的想象是：给它一句话，它哗哗生成一个文件夹，然后就能玩了。真实流程比这长得多。一次完整的“让 AI agent 独立完成并发布浏览器游戏”至少包含五个阶段：

1. 需求拆解：把“做一个 XX 游戏”拆成玩法、界面、交互、得分、音效、移动端适配等子任务。
2. 技术选型：决定用纯 HTML/CSS/JavaScript，还是 Canvas 绘图，还是引入某个轻量框架。
3. 代码生成与文件组织：生成 index.html、样式、脚本、资源文件，并且让内部引用关系正确。
4. 运行验证：启动静态服务器，打开页面，检查控制台报错，实际操作一遍关键流程。
5. 发布部署：把文件推送到静态托管服务，配置访问入口，验证真实线上地址是否可用。

这五步任何一步断了，都不能算“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 没有产品直觉，你说“做一个好看的游戏”，它永远不知道什么叫好看。所以要提前把验收条件写清楚。我一般会用这样一组标准：

这些标准最好一开始就放进提示词，而不是等它写完了再补。原因是 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”拆成四个判断标准：

1. 地址能访问。
2. 首屏在合理时间内正常渲染。
3. 核心玩法至少 95% 的操作路径可完成。
4. 多次访问后没有崩溃和资源错误。

很多 agent demo 只满足第一条。真正的发布还意味着：用户不需要做任何额外设置，不需要本地跑代码，打开链接就能玩。如果游戏必须本地起服务器才能跑，那它只是“生成完成”，不是“发布完成”。

5. 怎么判断 Agent 是真的完成了

5.1 打分维度

我给人审环节设计了一个简单的评分表，按这个打分基本能看出 Agent 是“真做完了”还是“表面完成了”：

这个打分表不是给 AI 跑的，是给人用的。AI 做完了，你要拿它做最终仲裁。

5.2 需要人工复核的关键点

在自动化完成的东西里，有几个位置仍然值得人去看一眼：

• 提示词有没有被曲解：比如你要竖屏适配，它做成了横屏。
• 有没有引入来源不明的资源包：如果 Agent 从网上下载了素材，要确认授权情况。
• 部署账号和密钥：如果部署过程涉及账号登录，要检查密钥有没有被写进公开文件。
• 线上是否可回滚：发布版本和源代码要能对应上。

这些不是代码问题，而是“产品交付”问题。Agent 不会替你考虑版权和运维，它只会按指令执行。你负责的是边界、安全和最终判断。

6. 常见失败模式与排查链路

6.1 现象分类

跑这类任务时，失败现象基本集中在五类：

6.2 排查顺序

遇到问题，我建议按这个顺序排查，不要上来就让 AI 重写：

1. 先看现象发生位置：本地还是线上，首次打开还是操作后出现。
2. 再看浏览器控制台：有没有红色报错，报错指向哪个文件哪一行。
3. 再看网络面板：有没有资源 404、超时、跨域。
4. 再看代码结构：报错文件是哪一层逻辑，引用顺序是否正确。
5. 最后再决定是让 AI 修改，还是人工介入。

一个很实用的原则：把原始报错信息原样丢给 Agent，而不是转述。转述会丢失细节，Agent 很容易在错误的方向上打转。如果你觉得 Agent 越修越乱，就退回上一版，把修改范围缩小，一次只改一个问题。

7. 我建议怎么玩这件事

7.1 适合场景与上手节奏

如果你想自己试，我的建议顺序是：

1. 先选一个 300 行内能写出来的小游戏，比如贪吃蛇、打砖块、飞机射击。
2. 用上面的验收标准做模板，让 Agent 完成第一版。
3. 本地跑通后，再让它做发布。
4. 上一步稳了，再把玩法复杂度加上去，比如增加关卡、道具、音效。
5. 最后再考虑多人、排行榜、数据上报等功能。

之所以不建议一上来就做大项目，是因为 AI agent 的上下文和纠错能力都有边界。项目越大，越容易出现“前面写得好，后面忘了约束”的情况。小游戏正好能暴露这些问题，而且返工成本低。

如果只是学习，默认配置和简单部署通常够用。我一般会先用小样本验证：跑通一个小游戏，确认流程中的每一步都能控制，然后才把更复杂的项目交给 agent。

7.2 边界：什么情况不要指望全自动

必须说清楚几个不适合全自动的场景：

• 需要登录、支付、用户数据的游戏：涉及后端和合规，Agent 很难一次搞定。
• 需要大量原创美术、音频的项目：Agent 生成素材质量不稳定，版权也不容易保证。
• 对性能要求很高的实时 3D 游戏：需要很多手工优化，自动化只能做初稿。
• 需要持续运营、埋点、数据分析的产品：发布只是开始，后面才是大头。

真正的经验是：把 AI agent 当成一个能快速完成初稿的执行者，而不是替代你思考的产品负责人。它擅长的是把明确需求变成可运行代码，并且能自动完成静态站点的部署。它不擅长的是帮你定义“好玩”和“值得做”。

踩过几次之后我发现，很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。提示词里的边界条件写得越清楚，Agent 翻车的概率越低；验收标准定得越明确，你判断“做完”和“没做完”就越容易。

所以，所谓“on its own”，不是它从零到一替代了你，而是你把验收标准、边界条件和人工检查点设计好之后，它能把整个执行路径走完。能做到这一步，已经比单纯用代码补全工具前进了一大截。