企业官网建设流程全解析

1. 一个写文档的，凭什么做微信小游戏

先交代一下我的背景：我平时的工作是写技术文档、做产品需求梳理，连一次正经的游戏开发经验都没有，Cocos 和 Unity 只停留在"听说过"的程度。之所以会碰微信小游戏，纯粹是因为一个朋友做的小游戏在朋友圈火了几天，让我意识到这个赛道并不完全是专业游戏团队的天下——特别是现在 AI 写代码的能力已经到了一种"你只需要把需求说清楚，剩下的交给它"的程度。

我的出发点和大多数非游戏开发者一样：想低成本验证一个"小游戏能不能跑起来、有没有人玩"的想法，而不是一上来就搞一个完整的商业产品。所以我的目标很明确：花尽量少的时间，用 AI 辅助做出一款能上线微信小程序平台的游戏 MVP（Minimum Viable Product），走通从想法到上线全流程，并且把过程中的真实成本、时间和坑记录下来。

这篇文章就是我完整实践记录的整理。如果你也是非游戏开发者，或者你手里有个游戏创意但一直被"不会写代码"拦住，那么这篇文章就是为你写的：它不会教你怎么成为一个游戏开发者，而是告诉你一个普通人如何借助 AI 工具完成"从聊天到上线"的整个过程，以及最容易被忽视的那些环节——尤其是备案审核那 27 天的等待。

先给所有想复制这条路径的人一个总的时间表，后面我会逐个阶段展开。

这条路径走下来，最核心的工具只有一个：对话式 AI 编程助手。如果你以为它只能用来写写代码片段、回答几个技术问题，那你就低估它了。我用它完成了从游戏规则设计、代码生成、Bug 修复到 UI 界面调试的全过程。但这中间也有大量细碎的坑，不是在 ChatGPT 里敲一句"帮我做个游戏"就能解决的。

2. 选型逻辑：为什么非游戏开发者应该从 HTML5 原型起步

刚开始我犯了个典型错误：一上来就想去学 Cocos Creator。网上搜索"微信小游戏开发"，铺天盖地的教程都是 Cocos 或 Unity 的，我跟着配环境配了半天，还没到写代码就已经被编辑器界面劝退了。这也是很多非游戏开发者死在这个阶段的原因——你被专业工具的门槛拦住，根本没机会接触到真正的编程部分。

冷静下来后，我换了一条路径：先用 AI 生成一个纯 HTML5 版本的游戏原型，跑通玩法逻辑，再转成微信小游戏版本。为什么这样选？

微信小游戏本质上是一个运行在微信环境中的游戏应用，但它有一个很特殊的点：它不支持直接操作 DOM（网页文档对象模型），游戏画面是通过 Canvas（画布）来绘制的。这导致一个结果——你在浏览器里写一个网页游戏很简单，但要让它在微信小游戏里跑起来，需要做一层适配转换。

大多数 AI 编程助手对普通 HTML/JavaScript 的熟悉程度，远超过它对微信小游戏 API 的熟悉程度。如果你直接让 AI 写微信小游戏代码，它会生成一堆wx.createCanvas、wx.createContext之类的调用，但这些 API 的细节经常随着微信基础库的更新而变化，AI 的知识库很容易滞后。而如果你先做 HTML5 版本，AI 会把 99% 的精力放在游戏逻辑本身——碰撞检测、计分系统、动画帧循环——这些是核心，也是 ChatGPT 最擅长的部分。

我的最终技术方案是这样的：

• 开发语言：JavaScript，因为它是微信小游戏唯一原生支持的语言，不需要转译
• 原型阶段：HTML5 + Canvas，在浏览器里直接把游戏逻辑跑通
• 转换阶段：基于微信小游戏适配层，把浏览器 API 替换为微信小游戏 API
• 开发工具：微信开发者工具，这是微信官方提供的 IDE，用于预览、调试和上传代码

如果你也是零基础，我建议你把游戏玩法控制在三分钟以内能上手的休闲品类。我做的是类"跳跃收集"型小游戏：玩家控制一个小方块在平台间跳跃，收集金币，躲避障碍物。这个品类逻辑简单，没有复杂的物理引擎需求，非常适合 AI 生成代码。

3. 五天聊出一个 MVP：我是怎么让 AI 理解需求的

从开始到跑通一个可玩的 MVP，我用了五天的下班时间。这五天里，我几乎每天都在和 AI 对话，前三天像是产品经理和研发的对谈，后两天像是测试和开发的拉扯。

3.1 第一天的核心动作：写出一份"人话版"需求文档

第一天我做的事情，可能和你想的不太一样——我花了大半天时间写需求文档，但这份文档不是给 AI 看的"项目说明"，而是给 AI 的结构化描述。我发现和 AI 协作的第一条铁律是：你说得越具体，它写得越准确。

我的第一版对话大概是这样：

请帮我用 JavaScript 写一个微信小游戏，画布尺寸 375x667，玩家是一个蓝色小方块，可以通过点击屏幕跳跃，从左边平台跳到右边平台，每跳上一个平台得 1 分，如果掉出底部就游戏结束。请用 Canvas 绘制所有元素，保持代码在浏览器里可以直接运行。

这个描述看起来很简单，但里面包含了 AI 生成代码所必需的五个要素：画布大小、核心玩法、交互方式、计分规则、结束条件。

结果 AI 第一次生成的代码就能在浏览器里跑起来了，画面很简单，就是几个平台方块和一个小方块在跳。但体验很粗糙：跳跃高度固定，无法控制跳跃距离，平台间距也是写死的。这时候我明白了一个事实——游戏体验不是 AI 凭空想出来的，而是你通过需求迭代逼出来的。

3.2 第二到三天的迭代：把"好游戏"拆解成"可描述的规则"

第二、三天，我开始逐一细化体验。这里我分享一个关键思路：不要对 AI 说"优化手感"，要说"把跳跃高度改成按屏幕点击时长变化"。AI 听不懂抽象的美学描述，但它能准确执行具体规则。

我每天的迭代清单都会拆成几个具体的小任务：

• 要求跳跃力度等于点击屏幕的时长，点击超过 0.5 秒按 0.5 秒计算
• 平台间距从固定值改为随机范围，但要确保有斜向跳台让你们有选路空间
• 增加金币系统，金币随机出现在平台上方，碰到金币加 5 分
• 画一个障碍物，碰到障碍物游戏结束
• 增加一个简单的分数显示，用白色文字绘制在左上角

这个过程中我踩了一个到现在都觉得无语的坑：我以为 AI 生成的代码一定是前后一致的，结果发现每轮对话它在修改一个功能时，可能把之前已经好好的功能弄坏。比如第三轮我让它加障碍物，它把平台的碰撞检测逻辑改得互相矛盾了，导致方块直接穿透平台掉下去。一开始我很崩溃，后来才悟到一个关键的协作习惯：

每次让 AI 修改代码前，我都会让它先输出完整的新代码，而不是只输出修改片段；同时我会手动保存每个稳定版本的副本，回退时直接把旧代码贴回去。这就像你在写文章时要频繁存稿，因为 AI 不像人，它不会记得自己上一版写过什么——它只会根据当前对话上下文继续发挥。

3.3 第四到五天的"测试驱动"：让 AI 自己找 Bug

当游戏功能齐备后，我还剩一个任务：把游戏从"能跑"变成"稳定不崩"。这个过程我用了特殊的方法——让 AI 当测试员。

我会把完整的代码复制到对话里，然后要求：

这是目前完整的游戏代码，请仔细阅读并找出所有会导致游戏崩溃或体验异常的问题，比如数组越界、空对象访问、帧率不稳定、碰撞逻辑错误。

有意思的是，这种"让 AI 审视自己代码"的方式确实能找出不少问题。它发现了一个我在浏览器里完全没注意到的 Bug：当方块速度过快时，可能直接跳过一整块平台，导致穿模（穿透平台掉下去的情况）。它的建议是增加一个"连续碰撞检测"的逻辑——在移动前先计算方块在这帧会移动到的位置，再和平台做碰撞判断，而不是每帧只判断当前坐标。

这里我要插一个对于非游戏开发者特别重要的知识：游戏循环是"帧"驱动的。每一帧（通常是每秒 60 次）代码会执行一次：处理输入、更新位置、绘制画面。如果方块一帧移动了 10 像素，而平台厚度只有 5 像素，那么在某一帧里方块可能正好"跨"过平台——上一帧在平台上面，下一帧已经在平台下面，碰撞检测根本没机会触发。这就是"穿模"的本质原因。

这个问题的解决方案是让碰撞检测不只是检查"当前是否碰到"，而是检查"移动路径上是否碰到"。这条知识是我在 AI 提示下学会的，但理解了原理后，我后续修改碰撞逻辑就再也没出过问题。这就是 AI 协作的核心价值——它给你代码，你负责理解它为什么这么写，才能驾驭它。

4. 转成微信小游戏版本：适配层的核心原理和三大坑

原型跑通后，真正的挑战才开始。HTML5 游戏在浏览器里运行没有任何限制，但微信小游戏运行在一个受限的环境中，核心差异我总结为三点，对应三大坑。

4.1 坑一：没有 DOM，页面结构完全由 Canvas 接管

在浏览器里，你可以在 HTML 里写<div>标签来显示分数、按钮，但在微信小游戏里，没有 DOM 概念，所有画面都必须绘制在 Canvas 上。这意味着我之前用 HTML 元素实现的 UI（分数显示、开始按钮、结束提示）要全部改成 Canvas 绘制。

我手动改第一个 UI 元素时，挨个找 AI 生成对应的绘制代码，做得很痛苦。后来我学聪明了——在给 AI 的准备提示词里直接声明：

注意：微信小游戏环境没有 document、window。所有 UI 文本必须用 ctx.fillText 绘制，所有按钮要自己实现点击区域判断。

加上这句话之后，AI 生成的代码就规范了很多。它的启蒙知识是"微信小游戏有 wx.createCanvas() 这类特有的 API，不能直接用 document.getElementById"。实际上微信小游戏确实提供了一套全局 API：wx.*是一整套微信 SDK，包括触摸事件（wx.onTouchStart）、存储（wx.setStorageSync）、震动反馈（wx.vibrateShort）等。适配的关键就是把浏览器写法替换为这些微信 API。

4.2 坑二：触摸事件和鼠标事件是完全不同的逻辑

HTML5 游戏在桌面浏览器里用鼠标事件（click、mousedown），在手机上用 touch 事件。但微信小游戏只提供触摸事件（touchstart、touchmove、touchend），并且不支持 mouse 事件。

我的游戏是"点击屏幕跳跃"，在浏览器里我让 AI 用的是canvas.addEventListener('click', ...)，在微信里运行就完全没有响应。我花了整整一个晚上才找到原因——不是代码逻辑错了，而是事件根本就没绑定上。解决办法也很简单：把事件绑定换成wx.onTouchStart(function(e) { ... })。

这里我额外分享一个细节：微信小游戏的触摸事件 e 对象和浏览器触摸事件的结构有点差异，它拿不出 clientX/clientY，只能用e.touches[0].clientX。如果你直接在微信开发者工具里调试，这个差异不会暴露得很明显，但真机测试时会发现点击位置偏移。我在真机预览阶段就被这个坑害过，后来统一用e.changedTouches[0].clientX才稳定了。

4.3 坑三：主包大小限制与静态资源配置

微信小游戏主包体大小限制是 4MB（包含 main.js 代码和所有本地资源文件）。我的第一版游戏把所有图片、音效打包进去后，直接超了 500KB。这样的问题不懂游戏打包的人真的很难注意到。

解决方案有两个：一是代码压缩混淆，去掉空白字符和注释，这个让 AI 帮我处理；二是把静态资源放到 CDN（内容分发网络）上，用远程加载替代本地打包——我这里用的是微信云开发（就是微信官方提供的一个轻量后端），先把图片传到云存储，游戏启动时异步下载。

这一步的代码实现，我让 AI 写了一个资源加载管理器：先加载一个清单文件，清单里列出所有图片的远程 URL，全部加载完毕后显示"开始游戏"按钮，加载失败则重试 3 次。这个设计让我在上线初期规避了大量网络加载失败导致的崩溃。

5. 备案那 27 天：微信小游戏最容易被忽略的隐形门槛

如果你以为小游戏写完代码就能立刻上线，那你跟我一样天真了。从开发者工具上传代码到正式上线，之间还隔着一道峡谷：备案审核。这段经历是我整条路径里耗时最长、也最没有确定性的环节，如果你也想做小游戏，这部分一定得提前规划。

微信小游戏备案全称叫"微信小游戏内容备案"，是从 2024 年开始成为新上架小游戏的强制要求。没有备案号，你的代码写得再好也传不到用户手机上。整个备案流程分为以下几步：

• 第一步：在小程序后台注册你的 AppID（就是你的游戏身份证），完成开发者认证
• 第二步：提交小游戏基本信息，包括游戏名称、游戏分类、游戏简介、视觉素材、隐私保护指引
• 第三步：提交主体信息，个人开发者需提供身份证信息，企业开发者需同步营业执照认证
• 第四步：等待审核，这也是最消耗时间的一步

我的备案时间线是这样的（其中具体工作日和初审/复审耗时根据官方流程估算）：

其中每个环节的填写都有容易返工的地方，我挑三个有代表性的说：

游戏名称：名字不是随便起的，一个是你不能用纯英文命名（除非你有商标），另一个是不能跟已有小游戏重名。我本来想用"跳跳方块"，一查已经被占了。我花了整整一下午在取名——不能违规、不能重名、还要有点记忆点，最后定了"跳跳金币"。

游戏分类：分类选错了，直接导致审核被驳回。小游戏的分类里有很多细类，比如休闲、动作、角色扮演、益智等。我一开始想选"休闲"，因为它是最大众化的分类；但提交时发现"休闲"需要勾选"游戏玩法是否涉及随机抽取"，因为我的游戏里有金币掉落机制——虽然没有付费，但平台判定这种随机掉落不属于"概率玩法"，只要不是抽卡、开宝箱这类强随机付费机制就不用额外说明。最终我选了"益智"分类，这个分类的审核要求相对宽松一些。

隐私保护指引：这个是最容易被个人开发者忽略的。微信要求游戏即使不涉及用户信息收集，也必须提交一份隐私保护指引，说明"本游戏不收集任何用户信息"。如果你偷懒不填，后台会直接提示你"隐私接口调用权限不足"，连真机预览都做不了。

备案等待期的无聊和焦虑，只有经历过的人懂。你无法催，也看不到具体的审核进度，只能干等。这 27 天实际上可以并行做很多事——我把这段时间用来做 UI 界面优化、增加游戏音效、写应用商店描述、准备上线素材。备案期间你以为自己啥也做不了，其实能做的确定性的活儿非常多，别傻等。

6. 提审与过审：非游戏开发者无从预料的细节规范

备案号下来后，我满心以为提审是走个流程。实际上，我又被现实教育了一顿——提审阶段依然有各种"看似不重要"的细节规范，稍不注意就被驳回。

6.1 类目选择与资质要求

游戏和普通小程序不一样，游戏需要单独的游戏类目。个人主体可以发布的游戏类目有休闲、益智等，但有几类游戏个人开发者不能碰：棋牌类必须要求营业执照且有相关资质，涉及虚拟支付的小游戏需要前置条件。如果你的游戏想做内购，个人主体通常是不行的——个人主体的小游戏不能开通虚拟支付，只能通过广告变现这类方式。这个我提前查过，所以我的 MVP 只做了激励视频广告（看完广告复活一次），绕开了支付限制。

6.2 审核人员到底在意什么

第一次提审被驳回时，反馈意见写了三条，每一条都是我没想过的问题：

• "游戏截图需包含网络加载界面的截图"——意思是你的游戏如果启动时有加载过程，素材里必须包含这个加载界面的截图
• "请补充游戏说明，说明中需描述游戏玩法、操控方式、元素含义"——听起来很蠢，但其实审核人员拿到一个陌生的游戏，确实需要通过你的说明来确认这个游戏没有违规内容
• "提示游戏英文内容需提供中文对照"——我的游戏分数显示用了 "SCORE" 英文，平台要求界面文字必须中文（或提供中英对照）

这第三条把我逗乐了，但也提醒我一件事：微信小游戏的审核规则里，对内容本地化的要求比一般小程序更严格。我后来把 "SCORE" 改成了"分数"，并顺手把所有界面文字统一成了中文。

6.3 代码上传与版本管理

提审前最后一个技术细节是版本号管理。微信开发者工具上传代码时，需要填一个项目版本号，必须符合类似 的格式（三段式），而且每次提审提交的版本号必须比上一次大。这个看起来微不足道的细节，我在第二次提交时因为忘了改版本号，被后台直接拒绝——系统不会提示你"版本号重复"，它只会告诉你"提交失败，请检查版本信息"。

提审后，正常审核时长是 1-7 个工作日。我的版本在提交后第二天就显示"审核通过"，相比备案的 27 天，这个速度让我觉得很惊喜。但"审核通过"不等于"线上可用"——你还需要在后台操作"发布"，并且设置小游戏的正式版本体验范围。

7. 上线后的真实数据与运维：一个 MVP 的生命周期

上线比想象中的平淡，但也比想象中的复杂。我用 MVP 上线后的头两周做了几件事：

第一是数据埋点。我让 AI 在游戏代码里加了一套非常简单的数据上报逻辑：启动时有 launch 事件，游戏结束时上报 Playtime（游戏时长）和 Score（得分），点击广告复活时有 revive 事件。这套数据通过微信小程序后台的"数据助手"接口上报，我在后台能看到 DAU（日活跃用户数）、次日留存率、人均游戏时长这些核心指标。

第二是真机兼容测试。微信开发者工具里的模拟器跑得再流畅，换到真机上也会暴露问题。我最明显的一个体验是：iPhone 的刘海屏对全面屏的适配很糟糕。我的画布是固定的 375x667，在 iPhone 13 上实际显示偏小，而且底部有小黑条。我用微信提供的wx.getSystemInfoSync()接口读取了屏幕实际宽度和高度，动态计算了画布缩放比例，并且让游戏适配了安全区域（safeArea），才算基本解决。

第三是iOS vs Android 差异。同一个游戏，Android 端的帧率明显比 iPhone 端低——因为这个游戏的碰撞检测逻辑里频繁使用的Math.sqrt函数在低端 Android 机上性能压力太大。AI 的建议是把开方运算改成平方比较，也就是把distance < 50改成distanceSquare < 2500，省掉一次开方。这个优化在上线后明显提升了 Android 端的流畅度。

上线两周的数据不算好也不算坏：累计 DAU 峰值 480，次日留存率约 18%，人均游戏时长 2 分钟出头。作为零成本冷启动的 MVP，这个数据已经能说明问题：游戏玩法没有社交裂变属性，纯粹靠自然流量是起不来的。我的收获不在于数据本身，而在于我终于跑通了"一个非游戏开发者从零到上线"的完整闭环。

后续我的迭代计划是：加上排行榜功能（用微信开放数据域实现），因为排行榜是小游戏天然的"社交钩子"；再做一个"每日挑战限时关卡"来提升次日留存。这两件事里，排行榜的开放数据域 API 需要单独适配，每日挑战则纯粹是玩法配置，都可以继续用 AI 辅助完成。

最后聊几句实在的

整个项目从启动到上线，前后一共 40 天左右，真正花掉的现金成本只有指纹认证的 30 元认证费和少量云资源费用。备案那 27 天如果算进去，这确实是一个"慢启动"的过程，但如果你做好了心理准备，一次性跑通全流程的价值非常大——因为你知道这条路长什么样了，第二次、第三次只会越来越快。

最后分享一个我自己的切身体会：AI 最擅长的不是你让它"做一个好游戏"，而是你给它非常具体的小任务。每当我试图让 AI 一次完成太多事情，结果往往是一段连我自己都看不懂的混乱代码；当我冷静下来，把事情拆成"调整跳跃高度""增加一个音效""修复碰撞 bug"这样的小任务时，AI 的表现几乎从不让我失望。这不是什么高深的方法论，而是和 AI 相处就像带新人：你交代得越细，它干得越靠谱。希望我的这份完整实录，能帮后来者少走几个同样的弯路。