信件派送站 · 独立开发实录筹备上线
这不是一张设计图，是一个真实项目：从选品调研到 1.0.11 体验版上线的完整记录。所有数字来自开发日志与自动测试报告。点击图片可切换原始尺寸查看设计细节；在新窗口打开原图。
▲ V4 完整流程原型（2026-10-01）：32 关 8 场景版设计稿
这游戏玩什么
竖屏 2D 路线解谜：棋盘上是一群朝向各异的邮车，你要看清每辆车的方向与阻挡关系，按可行的顺序点击放行——清空棋盘，就是完成一个派送站。
听起来简单，难度是这样长出来的：
- 第一关 8 辆车、无计时，两步就能学会；
- 第二关直接 36 辆车 + 150 秒倒计时，每步平均 4–5 秒——考的不是手速，是路线规划的顺序；
- 后期加入七种机制：路口切换（L5）、单向街道（L7）、道岔（L9）、联动开关（L10）、红绿灯统一时钟（L13）、钥匙卡（L14）、成对隧道（L15）。
正式版规划 32 关、8 个场景（街区日常 / 路口街区 / 转角车站 / 山城隧道）。测试期先上了 12 关，每一关都有难度基线文档（车数、步数、秒表实测）。
它是怎么被做出来的
选品：不是拍脑袋，是读了 120 条真实榜单
立项前做了一轮真实调研：采集微信/抖音小游戏榜单连续 6 天的日榜，共 120 条记录，筛出三个候选玩法。最终选择这个方向的标准很工程化：实现成本最低、且关卡可以用求解器自动验证（这意味着每一关都可机器校验，不靠人试）。
开发：四 Agent 协作工作树
这个小游戏不是"一个人熬夜敲出来的"，而是用四条独立工作树协作完成的——这也是我给自己立的工作纪律：
| 角色 | 职责 | 纪律 |
|---|---|---|
| 主流程 | 需求、合并、账号、GUI 唯一负责人 | 合并权集中 |
| UI 工作树 | 界面设计与切图 | 独立分支 |
| 开发工作树 | 实现与自测 | 不能自己合并主分支 |
| QA 工作树 | 独立验证 | 必须拿精确提交 SHA + 构建包复验，缺回执不得标记可合并 |
技术栈：Cocos Creator 3.8.8 + TypeScript；仓库共 221 次提交。开发过程中沉淀成了自己的流水线工具（从 1.0.0 迭代到 1.3.8，含 28 项自测）。
测试：从 18 到 268 项自动化用例
每一轮功能合入前跑全量自动化测试，覆盖面随版本滚雪球：
18 → 95 → 126 → 147 → 169 → 201 → 230/230（最高纪录 268/268）· 独立 QA 专项 171/171
真实踩坑：三个有代表性的战场
① 包体死磕 4MiB：一张一张图抠出 360KB
微信小游戏对首包有硬性体积限制。第一次上传"预览"时，源码包 4523KB 被直接拒绝。解决方案没有黑魔法——把全部素材逐张解码成原始像素、比对后无损重压缩，硬生生省出 360,257 字节，落到 3987KB 才出码。包体是一座一座图搬出来的。
② 启动黑屏与 Logo：修了两版才根治
早期版本真机上会闪 Cocos 官方启动 Logo、然后黑屏一下。1.0.8 才彻底修掉（官方参数关闭 Logo + 首屏/引擎/相机统一成暖色不透明底色）——结果修完又暴露"首页前闪一帧局内 UI"的新问题，继续定位。启动路径的问题，只能真机一帧一帧看。
③ 小屏遮挡：一枚胶囊引发的全面排查
375 宽度的小屏手机上，微信"胶囊按钮"正好压住首页的体力显示和某一关的计时器。1.0.11 的修复不是"挪一下"那么简单——要按小游戏圈的规范留出安全区（48 逻辑像素），重排整个顶部区域的布局逻辑。
wx.reportEvent 初版重复上报、同步调用阻塞输入 80ms，改成 1 秒有界去重 + 下一 tick 调度才解决。美术迭代：从"太丑"到 60 个状态
第一版灰盒原型拿给用户看，得到的反馈非常直接："太丑、不好看"。邮车最初只是一个箭头，也被要求重做成"玩具邮政小卡车"的质感。于是有了正式 UI v7：60 个界面状态、120 张 375/390 双尺寸切图、32 条角色回复文案、8 枚邮票、8 张场景插画。上面的设计图就是这一版。
现在到什么进度了
| 事项 | 状态 |
|---|---|
| 微信体验版 | 1.0.11 已上传（12 关测试版，无激励广告，含 13 项埋点与异常监控） |
| 备案 | 已提交审核中（小游戏类目） |
| 正式版 | 32 关 + 七机制 + UI v7 待审图后实装；正式提审排期中 |
| 云能力 | 云存档/排行榜因第三方依赖安全审计风险，已主动取消——宁可砍功能，不带隐患上线 |
原创轻量时间管理小游戏：规划路线、按时送达每一封信。
微信版上线后将在主站放出体验二维码（敬请期待）。
aizhuozhi.com