企业官网建设流程全解析

1. 一个不会写游戏的人，怎么把微信小游戏做上线

先说背景。我做了七八年后端和运维，前端只会改改样式，游戏开发经验为零。Unity 没碰过，Cocos 只听说过名字。去年年底想做一个自己的微信小游戏，纯粹是因为看到一个很小的玩法点子，觉得有意思，想验证一下能不能跑通。从有想法到正式上线，前后大概两个月，其中备案卡了 27 天，真正写代码的时间加起来不到两周。

这篇文章不讲虚的，就把整个过程摊开：怎么用 AI 把一个模糊的想法聊成能跑的 MVP，微信开发者工具里踩了哪些坑，备案为什么拖了 27 天，以及哪些环节是真正卡住非游戏开发者的地方。如果你也是后端、前端或者完全跨行，想自己做个小游戏上线，这篇应该能帮你省掉不少试错时间。

核心结论先放这儿：AI 能帮你写代码，但帮不了你做决策。玩法设计、性能取舍、审核规避这些事，AI 给的答案往往是"正确的废话"，真正管用的还是你自己对产品的判断。AI 最大的价值在于把"我不会写游戏"这个门槛从"不可能"降到了"有点烦但能搞定"。

下面按实际推进顺序拆开讲。

2. 用 AI 聊出 MVP：从一句话想法到可玩原型

2.1 为什么选择"聊天式开发"而不是直接让 AI 写代码

很多人一上来就跟 AI 说"帮我写一个微信小游戏"，结果拿到一堆跑不起来的代码。我试过，AI 会给你一个看似完整但缺胳膊少腿的工程，canvas 初始化、触摸事件、渲染循环全都有问题，你还得一点点 debug，比自己写还累。

我的做法是先聊清楚再写代码。具体分三步：

第一步，把玩法用大白话讲给 AI 听，让它帮你梳理成"输入-处理-输出"的结构。比如我的想法是"屏幕上有个小球，点击屏幕小球往上跳，碰到障碍物就结束"，AI 会帮你拆成：触摸事件监听、物理模拟（重力+速度）、碰撞检测、分数统计、游戏状态机（准备/进行/结束）。

第二步，让 AI 给出技术选型建议。这里有个关键点：微信小游戏支持原生 Canvas 2D、WebGL，也可以用 Cocos、Laya、Egret 这些引擎。我一开始想用 Cocos，因为听说"专业"，但 AI 提醒我：如果玩法简单、没有复杂动画和物理，原生 Canvas 反而更轻、包体更小、审核更快。最后我选了原生 Canvas 2D，整个游戏包体压到 200KB 以内。

第三步，让 AI 生成最小可运行代码，而不是完整游戏。我让它先写一个"点击屏幕出现一个方块，方块往下掉"的 demo，跑通了再往上加逻辑。这样每一步都有反馈，不会一次性堆一堆代码然后发现全错。

提示：跟 AI 聊玩法时，尽量用"如果...就..."的句式描述规则，AI 对条件逻辑的理解比自然语言描述准得多。

2.2 MVP 的功能边界怎么划

非游戏开发者最容易犯的错是想做的太多。我一开始列了十几个功能：排行榜、皮肤系统、音效、分享奖励、每日任务……AI 直接跟我说，这些全做完至少一个月，而且大部分功能对验证玩法没帮助。

最后我砍到只剩四个核心功能：

• 点击/长按控制角色
• 障碍物随机生成
• 碰撞检测与游戏结束
• 本地最高分记录

排行榜、分享、广告这些全部砍掉。理由很简单：MVP 的目的是验证"这个玩法好不好玩"，不是验证"这个游戏完不完整"。如果玩法本身没意思，加再多功能也留不住人。

这里有个实操技巧：让 AI 帮你做"功能优先级排序"。我把所有想做的功能列出来，让 AI 按"对核心玩法的影响程度"和"实现难度"两个维度打分，最后砍掉了 80% 的功能。这个排序过程 AI 做得比我好，因为它没有"这个功能很酷我想做"的情感包袱。

2.3 用 AI 生成代码的正确姿势

聊清楚之后进入写代码阶段。我的工作流是这样的：

1. 让 AI 生成单个模块的代码，比如"写一个处理触摸事件的函数，支持点击和长按两种操作"
2. 把代码贴进微信开发者工具，跑一下，看报错
3. 把报错信息贴回给 AI，让它修
4. 修好之后，再让 AI 写下一个模块

这个循环看起来笨，但实测下来比"一次性生成完整项目"效率高得多。因为 AI 生成的代码经常有 API 版本问题（比如微信小游戏的wx.createCanvas()在不同基础库版本行为不一样），一次性生成的话，你根本不知道是哪个模块出的问题。

我踩过的一个典型坑：AI 生成的代码里用了requestAnimationFrame，但微信小游戏环境里这个 API 的行为和浏览器不完全一样，在部分安卓机型上会掉帧。后来改成微信自己的canvas.requestAnimationFrame才稳定。这种问题，只有跑起来才能发现。

注意：AI 生成的代码一定要在真机上测，不能只在开发者工具的模拟器里跑。模拟器和真机的差异在小游戏里比小程序还大，尤其是触摸事件和渲染性能。

3. 微信开发者工具实操：从零到能跑起来

3.1 环境搭建与项目初始化

微信开发者工具的下载和安装没什么好说的，官网直接下。但有几个细节新手容易卡住：

第一，小游戏和小程序是两个不同的项目类型。新建项目的时候要选"小游戏"，不是"小程序"。选错了后面很多 API 用不了，得重建。

第二，AppID 必须提前申请。个人开发者可以申请，但要注意：个人主体的小游戏有一些类目限制，比如不能做某些需要资质的品类。我做的休闲类没问题，但如果你想做带支付或者特定内容的，得先确认类目。

第三，基础库版本选择。开发者工具会让你选一个基础库版本，建议选"最新稳定版"而不是"最新版"。最新版有时候有 bug，而且用户端不一定都升级到了最新版。我选的是当时的最新稳定版，覆盖了 95% 以上的用户。

项目初始化之后，目录结构大概是这样：

├── game.js // 入口文件 ├── game.json // 配置文件 ├── project.config.json // 项目配置 └── js/ ├── main.js // 主逻辑 ├── player.js // 玩家对象 └── obstacle.js // 障碍物

game.json里有个关键配置是deviceOrientation，控制横屏还是竖屏。我的游戏是竖屏，设成portrait。这个如果设错，真机上画面会旋转，很尴尬。

3.2 核心代码结构与 AI 协作细节

我的game.js入口文件很短，主要就是初始化 canvas 和启动主循环：

const canvas = wx.createCanvas(); const ctx = canvas.getContext('2d'); const { width, height } = canvas; const game = new Game(ctx, width, height); game.start();

Game类里管状态机、更新和渲染。这部分代码是 AI 帮我搭的骨架，我自己填的玩法逻辑。AI 给的骨架有个好处：它会把"更新"和"渲染"分开，这是游戏开发的标准做法，但我一开始不知道。分开之后，逻辑帧率和渲染帧率可以独立控制，性能会好很多。

具体到玩法逻辑，我让 AI 帮我写了三个关键函数：

• updatePlayer(dt)：根据时间差更新玩家位置，处理重力和跳跃
• checkCollision()：检测玩家和障碍物的碰撞
• spawnObstacle()：按一定间隔生成障碍物

这里有个参数需要自己调：重力加速度和跳跃初速度。AI 给的是通用值，但手感完全不对。我调了大概二十几次才找到合适的值。经验是：重力别太大，否则角色下落太快，玩家反应不过来；跳跃初速度要让角色能跳过一个障碍物的高度，但不能太高否则失去挑战性。

实操心得：手感调参没有公式，就是反复试。建议把参数抽成常量放在文件顶部，改起来方便。我最后用的是重力 0.6、跳跃初速度 -12（canvas 坐标系 y 轴向下，所以向上是负值）。

3.3 真机调试与性能优化

开发者工具的模拟器只能做基础验证，真正的问题都在真机上。我遇到过的几个典型问题：

问题一：触摸事件延迟。模拟器里点击响应很快，真机上尤其是安卓机，有明显延迟。原因是触摸事件的处理放在了渲染循环里，导致响应不及时。解决办法是把触摸事件单独监听，用一个标志位记录状态，渲染循环里读标志位。

问题二：帧率不稳定。低端安卓机上掉帧严重。排查下来是两个原因：一是每帧都在创建新对象（障碍物），导致 GC 频繁；二是没有做对象池。改成对象池之后，帧率稳定了很多。

问题三：不同机型分辨率适配。canvas 的宽高在不同机型上不一样，如果写死坐标，画面会错位。解决办法是用相对坐标，所有位置都基于width和height计算。

性能优化这块，AI 能给的帮助有限，因为它看不到真机表现。我的做法是：先用 AI 生成一版能跑的代码，然后在真机上测，发现问题再针对性地问 AI"怎么优化对象创建频率"或者"怎么做 canvas 分辨率适配"。这样问，AI 给的答案会具体很多。

4. 备案 27 天：流程、卡点与避坑

4.1 备案流程全拆解

小游戏上线前必须备案，这是硬性要求。我整个备案流程走了 27 天，其中大部分时间是在等审核和补材料。流程大致是：

1. 在微信公众平台提交小游戏备案申请
2. 填写主体信息、游戏信息、内容说明
3. 等待初审（大概 3-5 个工作日）
4. 初审通过后，提交到相关部门审核（这一步最慢，我花了 15 天）
5. 审核通过后，微信侧做最终确认

听起来简单，但每一步都有坑。

4.2 我踩过的三个备案坑

坑一：游戏名称和内容描述不一致。我一开始起的名字比较抽象，内容描述写得太简单，被退回来要求补充。后来把名称改得更直白，内容描述写清楚玩法、目标用户、内容特点，才通过。经验是：名称和描述要能让审核人员一眼看懂这个游戏是干什么的，别玩文艺。

坑二：类目选择错误。小游戏备案要选类目，我一开始选了一个不太相关的类目，被退回。后来选了"休闲益智"才对。类目选错不仅影响备案，还影响后续的推荐和广告接入。

坑三：材料格式问题。有些材料要求 PDF，有些要求图片，有些要求特定尺寸。我第一次提交的时候没注意，被打回来重新弄。建议提交前把所有材料列个清单，逐项核对格式要求。

注意：备案期间不要修改游戏的核心内容，否则可能需要重新备案。我有个朋友备案期间改了玩法，结果被打回重来，多花了两周。

4.3 备案期间可以做的事

备案虽然慢，但这段时间不能浪费。我做了几件事：

第一，继续优化游戏。备案不影响开发，我在这期间把音效、动画、难度曲线都调了一遍。

第二，准备上线素材。小游戏上线需要图标、截图、简介，这些可以提前做好。

第三，小范围测试。微信开发者工具支持生成体验版二维码，可以发给朋友试玩。我发了大概 20 个人，收集了一轮反馈，改了几个明显的体验问题。

这里有个细节：体验版二维码有有效期，默认好像是 7 天还是 30 天，过期要重新生成。如果要长期收集反馈，记得定期更新。

5. 常见问题与排查技巧实录

5.1 开发阶段高频问题速查

5.2 几个 AI 帮不上忙的坑

有些问题 AI 真的帮不了，因为它不知道你的具体环境。比如：

坑一：微信开发者工具的缓存问题。有时候代码改了但工具没更新，还是跑旧代码。解决办法是清缓存重新编译，或者重启工具。这个问题我遇到好几次，一开始以为是代码问题，查了半天。

坑二：真机调试的日志看不到。真机上的 console.log 不会直接显示在工具里，需要用wx.setEnableDebug开启调试模式，或者在真机调试面板里看。这个我摸索了一阵才搞明白。

坑三：不同安卓机的 canvas 行为差异。有些机型上 canvas 的getContext('2d')返回的上下文行为不一致，比如measureText的返回值不同。这种问题只能靠真机测试发现，AI 给不了通用解法。

5.3 上线后的数据观察与迭代

上线之后我盯了一周的数据，主要看三个指标：次日留存、平均游戏时长、分享率。次日留存只有 15% 左右，说明玩法吸引力不够。平均游戏时长 2 分钟，偏短。分享率几乎为零，因为我没有做分享功能。

基于这些数据，我做了两个调整：一是降低了前期难度，让新手能多玩一会儿；二是加了一个简单的分享按钮，分享后可以获得一次复活机会。调整之后次日留存涨到了 22%，虽然还是不高，但至少说明方向对了。

这里想说的是：AI 能帮你做出来，但做出来之后怎么改，还是得看数据。AI 不知道你的用户是谁、喜欢什么，这些只能靠你自己观察。

6. 非游戏开发者做小游戏的真实体会

最后说几个我自己的感受，不是总结，就是一些零散的经验。

第一，AI 把门槛降低了，但没有消除门槛。以前不会写游戏就是做不了，现在 AI 能帮你写出来，但你还是得懂基本的游戏开发概念，比如状态机、对象池、帧率控制。不懂这些，AI 给的代码你改不动。

第二，备案是最耗时的环节，不是开发。我开发加调试大概两周，备案花了 27 天。如果你打算做小游戏，一定要把备案时间算进去，别想着"做完就能上线"。

第三，真机测试的时间要留够。模拟器上跑通不代表真机能跑，真机上跑通不代表所有机型都能跑。我最后花了大概三天时间在各种安卓机上测，才把兼容性问题解决得差不多。

第四，玩法比技术重要。我见过很多技术很牛但不好玩的小游戏，也见过技术很简单但很上瘾的。AI 能帮你解决技术问题，但玩法设计还是得靠你自己。我的建议是：先用最简单的技术做一个能玩的版本，验证玩法，再考虑加功能。

第五，别怕代码丑。我第一版代码写得很乱，变量命名随意，函数拆得也不合理。但能跑。后来慢慢重构，才变得整洁。非游戏开发者最容易犯的错是追求"完美代码"，结果迟迟做不出能玩的东西。先跑起来，再优化。

如果你也在考虑自己做个小游戏，我的建议是：从最小的玩法开始，用 AI 帮你写代码，把备案时间算进去，真机测试留够时间，上线后看数据迭代。整个过程会比你想的慢，但比你想的可行。