企业官网建设流程全解析

1. 项目整体设计与思路拆解

1.1 从想法到范围：怎么定义一款“能上线”的小游戏

2025年春节后我休假回来，顺手点开微信小游戏排行榜，看到一款合成类产品已经跑了3年还在赚钱。当时脑子里就冒出一个念头：这类玩法我能不能在20天内自己搞一款出来。

这不是拍脑袋。微信小游戏的现成优势摆在那里：点开即玩，不需要下载安装；自带社交关系链；分享、排行、组队这些天然带传播属性。对个人开发者来说，这是目前门槛最低、离钱最近的游戏分发场景之一。但一个人做游戏，最大的问题不是写代码，而是范围失控。今天想加联机，明天想加时装，20天连个Demo都做不出来。

所以我给自己定了三条硬约束：

• 核心玩法必须单点且完整，不能贪多。我选了“堆叠合成”作为基础玩法：屏幕上散落各种道具，点击收集到下方槽位，三个相同道具自动合成更高一级，合成到一定等级就能过关。
• 所有功能只做MVP版本。排行榜、每日挑战、激励视频广告，这三个必须有，因为它们是留存和变现的支柱。多语言、账号系统、商城全部砍掉。
• 美术用AI生成加上简单几何素材，够用就行，不请人、不买复杂素材包。

这三条约束定了之后，整个项目从“做一个游戏”变成了“做一个用AI工具链快速交付的微信小游戏”。后面所有工具选型、代码结构、时间分配都围绕这个目标展开。

1.2 为什么是微信小游戏，以及一个人如何扛住四个岗位

很多人问我，做游戏为什么不直接做App。理由很简单：App的获客成本可以吃掉绝大部分独立开发者的利润，而微信小游戏天然带社交裂变属性。用户看到好友在玩，点进去就开始了，没有下载转化漏斗，这个优势是个人开发者必须抓住的。另外一个现实原因是，小游戏平台支付、登录、广告组件都有现成能力，相当于平台帮我把基建都搭好了，我只要做好游戏本身。

一个人扛四个岗位，听起来很玄，本质是把工作分成四类：

• 策划岗：定玩法规则、数值节奏、关卡配置。这部分靠“脑子”和经验，我花了2天把核心循环和数值表拉到纸上。
• 程序岗：游戏逻辑、UI交互、排行榜、广告接入。这是最重的活，也是Cursor和Codex介入最深的部分。
• 美术岗：图标、背景、道具图形。我用AI生成素材然后统一调色，没有一张人工手绘。
• 发行运营岗：注册、打包、提审、公告、埋点。这部分主要是踩平台的坑，后面会详细说。

我在项目里实际是这样分工的：凡是“需要上下文理解”的工作，比如设计模式、代码重构、调试排查，我用Cursor；凡是“目标明确、可以批量执行”的工作，比如生成1000个关卡配置、批量修代码风格、写单元测试，我用Codex。这套组合拳打下来，等于把过去一个3人小团队的工作量压缩到了一个人的时间窗口里。

1.3 20天排期怎么排

我的20天不是连续整块时间，而是996式突击加上碎片时间。排期表如下：

这个排期里最重要的不是每个阶段做了多少事，而是每天结束都必须要有一个“可运行”的东西。第3天我手里已经能跑起一个最小循环，之后每一天都在这个循环上加功能，而不是从头搭建。这样即使某天进度爆炸，产品始终处于可用状态，不会出现“第19天还在搭架子”的灾难。

2. AI开发工具链搭建

2.1 Cursor当主力IDE，先解决中文配置和全局规则

整个项目我几乎所有代码都在Cursor里写。不夸张地说，Cursor已经从一个“带AI的编辑器”进化成了“会帮你扛项目的IDE”，对个人开发者来说，这玩意比多招一个初级程序员靠谱。

很多新手装上Cursor之后第一反应是英文界面看不惯，其实中文设置很简单：打开Cmd/Ctrl+Shift+P，输入"Configure Display Language"，选择“中文(简体)”并重启，界面就汉化了。如果你想更彻底一点，也可以在设置里搜Locale然后把语言改为zh-cn。这个操作属于一次性配置，改完就不用再动。

但真正影响开发效率的不是界面语言，而是项目规则文件。我会在每个项目根目录放一个.cursor/rules文件，把项目的技术栈、目录结构、代码风格、禁止事项全部写进去。比如我这份规则里明确写了：

• 本项目使用TypeScript，禁止使用any类型。
• UI组件放在resources/components目录下，业务逻辑放在scripts目录下。
• 所有排行榜相关代码必须走开放数据域，不允许直接操作主域文件。
• 公共方法必须写JSDoc注释，关卡配置必须从JSON读取。

有了这份规则之后，Cursor生成的代码会主动遵守你定下的边界，不会出现“生成一时爽，重构火葬场”的情况。我给所有用AI编程的朋友同一个建议：先写规则文件，再让AI干活，这比任何提示词技巧都管用。

2.2 Codex CLI安装与跑通：从安装到换模型

Codex是OpenAI出的一个Agent式编程工具，和Cursor的差别在于：它在终端里运行，可以自主完成“读代码、改代码、跑测试、提交commit”这一整条链路。我把它当作项目里的“无人值守工程师”：只需要把任务丢给它，它自己会翻代码库、写改动、验证，最后把结果告诉你。

安装Codex比较简单，前提是电脑里已经有Node.js环境（建议用18以上版本），然后在终端执行安装命令，它会自动下载CLI并配置好运行环境。第一次启动需要用账号登录，绑定API Key，之后就能正常调用模型。

这里要特别提醒一个坑：国内网络环境下，经常会出现cc switch local proxy failed while handling codex endpoint /responses这类报错。第一次遇到这个报错，我先以为是Codex安装包坏了，重装了两遍问题依旧。后来排查发现，问题出在API转发的本地服务上：Codex默认会走一个本地端口的代理网关，如果这个网关没有正常响应，就会报local proxy failed。解决思路是把网关地址重新指到可用的API转发服务上，然后在Codex的配置文件里更新模型接入地址，重启进程，问题就消失了。

很多工具使用问题，其实都是环境配置或者网络联通性导致的，不要一上来就怀疑工具本身。我把解决路径放到后面的“问题排查速查表”里，按顺序检查一遍比瞎折腾强十倍。

另外我配置Codex的时候直接接入了DeepSeek的API，不是为了省那点钱，主要是为了多一个模型选择。Cursor里写业务逻辑时我习惯用Claude的能力，按键精灵式的批量配置生成则交给Codex调用大模型来做，两条线互不干扰。你不需要在工具上绑定某一个模型，按任务难度和成本灵活切换，才是最成熟的用法。

2.3 人机协作流程：Cursor负责“懂”，Codex负责“干”

我搭建这套工具链的核心原则只有一条：AI负责把“确定的活”干完，但“为什么这么干，往哪个方向干”必须由人来拍板。

按照这个原则，我把工作流程拆成三步：

第一步，需求描述。我会把具体需求写成一个任务文档，包括背景、输入、输出、验收标准。比如“排行榜页面的滚动区域，需要适配不同屏幕比例，数据来自开放数据域的JSON数组，每条数据包含昵称、头像、分数、排名，渲染时要求前3名有特殊样式”。这一步描述越细，AI越不容易产生歧义。

第二步，让Cursor做讨论和细化。我在编辑器对话里先问几句：“这个方案行不行？有没有更优的做法？如果数据量到10万条会不会卡？”Cursor会根据代码库上下文给我分析，这个“讨论”环节帮我避开了不少坑。

第三步，把明确后的任务交给Codex批量执行。Codex更像是“一边读代码一边干活”的Agent，你给它一个清晰的任务目标，它能自己在项目里定位文件、做主流程改造、补测试，最后还能跑一遍构建脚本验证。20天里，我用Codex生成了900多关的配置数据、批量重写了UI组件的样式前缀、跑了三次全量代码风格检查。这些活如果手工干，至少占用我一周的时间，用Codex基本是挂后台运行，我该干嘛干嘛。

有一点要想清楚：AI生成代码的效率取决于你定义任务的能力。任务描述越具体，AI干活越靠谱。凡是“给我做个游戏”这种模糊指令，任何AI工具都只能给你一个号称完整的半成品，与其抱怨AI弱，不如想想自己是不是需求没写清。

3. 核心玩法与朋友圈排行榜实现

3.1 游戏主循环和合成逻辑怎么设计

微信小游戏的本质是H5加了一层原生容器，性能上不如原生App，但2D玩法的表现力完全够用。我在引擎选型上用了Cocos Creator，因为它在小游戏的适配和包体控制上比Unity省心很多，后面会详细对比。主场景只有一个，我用单场景加多UI节点的方式管理整个游戏流程，避免场景切换带来的加载白屏。

核心玩法的状态机是游戏主循环的关键。一局游戏里，玩家处于“选择道具”或者“自动合成”的状态，当槽位里出现三个相同道具时，触发合成动画，然后检查是否达成过关条件。整个状态转换用TypeScript写出来后不到300行，但这是整个游戏的骨架，不能出错，所以我让Cursor在这个模块上反复review了三遍，并且写了几组单元测试。

道具合成逻辑是数值驱动的。每种道具有一个等级字段，等级从1到12，同等级三个合成升一级，每级对应的分数和特效不同。这段逻辑代码本身很简单，但真正的坑在于手感：合成动画的播放时长、点击道具时的反馈音效、槽位满时的抖动提示，这些细节决定了玩家能不能感受到“爽”。我花了很大的精力在调这些参数上，动画时长我最终定在0.25秒，太快太慢都会让人觉得卡。

3.2 好友排行榜完整实现：开放数据域和Canvas渲染

微信小游戏的排行榜是我这次项目里最容易被卡住的模块，单独拿出来讲。

首先要理解微信小游戏的安全模型：为了不让个人开发者随便读取用户关系链数据，微信强制把排行榜功能拆成“主域”和“开放数据域”两部分。主域是你的正常游戏逻辑，开放数据域是一个独立运行的环境，只有这个环境里才能调用wx.getFriendCloudStorage这类社交API，而且开放数据域里不能操作主域的东西，两者之间只能通过postMessage传消息。

所以排行榜的完整实现分四步：

第一步，在主域里配置开放数据域目录。我用Cocos Creator构建微信小游戏工程后，会把开放数据域的代码独立放在子包里，用game.json的openDataContext字段指向入口文件。

第二步，往微信的云存储里写分数。玩家每次过关，主域调用wx.setUserCloudStorage把玩家的最高分和关卡进度写进托管数据里。注意这个方法只能写一个KVObject数组，key和value都要符合微信的格式规范，value必须是JSON字符串。

第三步，在开放数据域里读取数据。当排行榜UI打开时，主域给开放数据域发一条消息，开放数据域调用wx.getFriendCloudStorage取出好友数据，并过滤出自己的分数和排名。

第四步，在Canvas上渲染排行榜。开放数据域不能直接用cocos的UI组件，但可以在Canvas 2D上绘制文本、头像和背景。我用一个Canvas渲染了整个排行榜列表，根据排名动态计算每行的高度和Y坐标，前3名用不同的颜色和字体大小标出。头像先用wx.createImage加载，加载完后画到Canvas上，注意头像可能因为隐私设置加载失败，要有默认头像兜底。

这套流程说起来简单，实际踩坑主要在postMessage的数据结构上。微信对主域和开放数据域之间的消息大小有限制，一开始我用一个超长的JSON把整局游戏状态传过去，结果直接没反应，看日志才明白是消息体太大。后来只传当前分数和页签状态，数据量降下来，通信就稳定了。

3.3 用Codex批量生成关卡配置

如果说排行榜是技术的深水区，关卡配置就是体力的深水区。我的玩法有12个关卡主题，每个主题里有一系列小关，每关规定生成哪些种类、多少数量、难度怎么递增。手工配的话，20天光配数值就够呛。

我把整个配置表写成了JSON Schema，定义好每关的字段：目标分数、道具生成权重、障碍物位置、限定时长、奖励道具。然后我给Codex写了一段详细的任务提示，要求它按照递增曲线生成全部配置，并做两轮自检，第二轮校验能不能按规则正常通过。

最终Codex一次性生成了900多关配置文件，我抽查了其中50个文件，没有发现字段缺失和明显数值不合理的情况。这给了我一个重要的启发：如果你能让AI做“根据结构化模板批量产出内容”，它能比人更快速、更稳定。但前提是你得先把模板和校验规则定得足够严谨，否则批量生成的是批量垃圾。

配置生成完了，还要注意包体大小。900关的JSON文件全部塞进代码包里，体积会非常可观。我的做法是：首次加载时拉一个全量配置到本地，然后把游戏里真正用到的数据拆成按关卡号加载的模块，用微信的分包加载机制做懒加载，这样首包体积控制在了3M以内，远低于平台限值。

4. 微信小游戏打包、适配与提审

4.1 Cocos导出微信小游戏的流程和个人体会

网上一搜“Unity微信小游戏打包”和“微信小游戏打包”的区别，能搜到一堆资料，我这里结合自己的实操给个结论：如果你做的是2D休闲玩法，Cocos Creator是更好的选择；如果团队已经有用Unity写的成熟玩法，或者玩法依赖3D物理和特效，才值得走Unity转换微信小游戏这条路。

Cocos Creator搭建微信小游戏工程没有想象中复杂。先在构建面板选择微信小游戏平台，填上小游戏AppID，然后一键构建，编辑器会生成一个完整的wechatgame目录，这个目录就是可以直接用微信开发者工具打开的项目。

构建完成后，有几个点必须手动处理：

• 首次打开微信开发者工具，需要把“不校验合法域名”选项勾上，否则本地开发时所有网络请求都会被拦。
• 资源加载要改用微信的FileSystemManager，不能被Cocos默认的XHR方式卡住。
• 代码包如果超过主包限制，就得分包加载。Cocos构建面板里可以直接设置初始场景的资源放到主包，其他资源走子包或远程包。

我在第16天的时候，遇到一个恶心的机型适配问题：部分安卓机屏幕上排行榜按钮位置偏了，iPhone上也偶尔出现顶部刘海遮挡。排查后发现，问题的根源在于Cocos默认用的是固定设计分辨率，但不同机型的屏幕比例差异极大，需要手动适配安全区。

解决办法是读取微信的wx.getSystemInfoSync()拿到safeArea和statusBarHeight，然后把UI根节点的顶部偏移动态计算出来。这个改动很小，但覆盖面极广，建议所有做小游戏的人都要尽早处理，不要等到测试反馈。

4.2 Unity开发微信小游戏值得关注的一套转换路径

很多做Unity的朋友问过“Unity怎么打包成微信小游戏”，尤其是“Unity2022国际版开发微信小游戏如何获取好友排行榜”这种热搜词里最常见的问题。我最早也试过Unity方案，这里给一个实用总结。

Unity项目并不是直接“导出成小游戏”，而是先把项目构建成WebGL版本，再用微信官方提供的适配层把这个WebGL产物转换为小游戏可运行的代码包。实际操作中，老大难问题有三个：

• WebGL的内存分配和微信小游戏的底层运行环境不兼容，需要在启动参数里手动调整内存和渲染线程。
• 排行榜一样的开放数据域问题。Unity主工程里不能直接调用微信好友排行能力，也需要单独写一个开放数据域入口，用Canvas绘制榜单。
• 首包体积和加载时间。Unity的WebGL模板导出后基础文件就很大，不做分包和资源压缩的话，微信小游戏的包体限制会让人很难受。

我的建议是：Unity转小游戏只适合两种情况，一是你已有的Unity游戏逻辑复杂、重构成本高；二是你的游戏核心就是3D或者用到了Shader特效，Cocos做不出来同样效果。如果是新项目且是2D玩法，从零开始千万别用Unity硬刚小游戏，那不是技术问题，是时间成本问题。

4.3 提审前必须排查的10个问题

微信小游戏提审不像App Store那么玄学，但也别指望随随便便就过。我把这次踩的审核问题整理成清单，发布前对着过一遍，能帮你避免至少三天的等待时间：

1. 游戏必须有完整的开始、结束、复活流程，没有卡死的死循环。
2. 涉及用户数据的操作必须有隐私弹窗说明，尤其是排行榜会读取好友关系数据。
3. 广告组件的位置不能遮挡操作按钮，关闭按钮不能被故意做小。
4. 游戏内容不得诱导用户分享，不能出现“分享才能复活”这种强制逻辑。
5. 录屏功能使用的API必须是当前基础库支持的范围，不能越权调用。
6. 分享卡片里的图片和文案要符合实际游戏内容，不能做诱导点击。
7. 游戏内支付必须走平台虚拟支付能力，不能接外部支付。
8. 排行榜数据要保证展示的是真实好友数据，本地假数据不能用于线上。
9. 音视频资源不能涉及版权问题，背景音乐和音效要有来源记录。
10. 适龄提示要符合玩法内容，含广告的产品要在后台开启对应的标记。

我第一次提审就是因为第二条被打回，原因是隐私弹窗文案没有明确写出“好友排名数据会被用于排行榜功能”，修改后重新提交，第二天就过了。所以提审前一定自己先读一遍平台的运营规范，至少把跟自己功能相关的条款过一遍，比你提交三次盲改有效得多。

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

5.1 Codex本地代理报错的排查路径

Codex在运行过程中报cc switch local proxy failed while handling codex endpoint /responses是网上问得最多的一个错误，我这次也踩到了，这里把排查路径完整写出来。

这个报错的信息分两部分：前面是local proxy failed，后面是codex endpoint /responses。简单说，Codex进程本身没有坏，而是它在调用模型接口时走了本地代理转发，这个转发网关挂掉了或者配置不对，导致请求没有到达真正的模型服务。

排查路径可以这样走：

1. 先检查本地的API网关服务是否健康。我在终端执行一下服务自检命令，如果返回不是正常的JSON结果，说明网关服务进程没起来，重启服务即可。
2. 检查Codex的配置文件里模型地址是否指向了正确的API转发服务。很多人安装后没有改这个配置，默认地址指向了一个不可用的路径，自然就报了代理失败。
3. 检查网络连通性。直接请求一下模型服务的测试地址，看能不能拿到正常返回。如果这一步都通不过，说明是环境网络层面的问题，和Codex代码本身无关。
4. 如果以上都没问题，删掉Codex的本地缓存目录重新登录，干净环境再试一次，通常能解决90%以上的问题。

我最终是通过更新配置里的模型接入地址和重启网关服务解决的。整个过程花了半小时，但如果不知道这个思路，可能会卡上一整天。

5.2 Cursor额度和账号购买的常见困惑

Cursor的额度问题是社区里出现频率很高的内容。新用户有免费的试用额度，用完之后就需要付费或者等待额度重置。“无限续杯”这个说法，本质上是用一些非正规方式绕开额度限制，不建议大家去碰这类操作，不仅违反工具的使用条款，还有账号封禁风险，更没必要把自己的开发工作放在不可控的地基上。

如果你确实需要长期高强度使用Cursor，比较稳妥的做法是订阅专业版。这里有个细节要提醒：Cursor的订阅是从购买日算起的月周期，不是从额度重置日算起的，所以很多人“刚续费额度还是少”就会很困惑。你可以理解成它是按自然订阅周期走，不是按你的使用节奏走，这个坑记得提前避。

对于个人独立开发，如果觉得订阅价格高，可以考虑组合方案：日常开发用Cursor的免费额度加上本地代码推理，批量任务用Codex接入第三方API按量计费，整体成本能控制到每月几十块。AI工具不是越贵越好，关键是把任务类型和工具能力匹配起来，省下来的钱和时间都是自己的。

5.3 小游戏适配和入口配置的坑

最后说几个这次上线过程中最不起眼但最致命的适配问题。

第一是关于wx.getSystemInfoSync()已废弃。没错，微信官方在很多基础库里就标记了这个接口会逐步废弃，替代方案是wx.getWindowInfo()和wx.getAppBaseInfo()。如果你在小游戏里用了旧的获取系统信息方法，老版本还能用，但新版本基础库可能就返回空对象，直接导致安全区适配失效。

第二是屏幕方向。微信小游戏如果不主动声明，默认是竖屏，但iPhone的刘海和底部横条区域在横屏时会严重遮挡布局。我的做法是在game.json里明确指定设备方向，并且用安全区动态计算所有底部按钮的布局。

第三是分享图。分享卡片是微信小游戏最容易被人忽略的流量入口。很多开发者直接把截图当分享图用，但截图的尺寸、比例和平台要求不一致，显示出来很丑。我在项目里预先设计了几张带游戏角色大图和文案的分享图，尺寸严格按照5:4的比例做，分享出去的效果比默认截图好很多，拉新转化率差距肉眼可见。

第四是自定义数据上报。上线后要做基础的漏斗分析，比如从启动到开始游戏、从第一关到第二关的转化率。这些数据不上报的话，你根本不知道玩家卡在哪里，优化也无从下手。我用微信自带的数据分析接口埋了五个关键节点，虽然不复杂，但这个习惯帮我快速发现了新手引导过长的问题，改完之后次日留存涨了不少。

在整个项目的最后阶段，反而是这些“看着很小、不做没事、做了才知道有用”的事情在真正决定产品能走多远。技术上的AI提效只是让你跑得更快，“跑得对方向”还是得靠对平台、对用户的理解。

我个人这20天最深的一条体会是：工具永远只是杠杆，真正拉开差距的还是你脑子里对产品边界的判断。Cursor和Codex可以让你一个人干完四个人的活，但前提是你知道这四份活各自的标准和红线在哪。如果你也想用AI工具快速上线一款小游戏，我的建议很直接：先花一天把玩法文档和验收标准写死，再让AI进入战场，剩下的事，工具会替你还债。