AI-Wiki

文档概览

这篇文章是一次面向 Codex 的实战复盘，核心不是展示“AI 自动写了多少代码”，而是展示一种更接近工业制作的协作模式：人负责产品方向、体验标准、审美把关和验收红线，AI 负责高密度执行，包括代码生成、资源整理、切图脚本、音频粗筛、自动化检查和预览编译联动。

作者的目标从一开始就不是一个“合成棋盘 Demo”，而是一个能在微信开发者工具里流畅预览、功能闭环完整的微信小游戏试玩版。这个试玩版明确要求包含：

完整任务系统
剧情推进
道具链
多级生成器
场景修复
奖励飞行特效
原生音效反馈
新手引导

并且要满足两个现实约束：

不能爆包，必须压在微信小游戏首包主包约 4MB 红线附近
不能只在浏览器跑，要在微信开发者工具乃至真机预览环境中稳定运行

文章按开发过程分为几个关键阶段：先确认没有现成商业级开源底层可复用；再自行搭建六层工程骨架；接着把“爽感”拆解成 AI 可执行的微交互规范；之后用本地 H5 工作台承载复杂配置关系；再处理素材采购、筛选与切图；最后进入微信环境下的验收、烟测与包体审计。

关键事实

项目周期与产出规模

作者给出的开发周期与产出数据如下：

概念梳理和素材沉淀从 6 月 11 日开始
密集开发期为 6 月 12 日到 19 日
总周期约 8 天
小程序源码提交约 58 次
工作台与经验沉淀文件约 59 个
工程文件总数约 363 个
图片类视觉素材约 296 个
音频资源文件 11 个
核心 JS 逻辑代码约 7790 行
微信预览包体大小约 3.9MB 到 4.1MB

这些数字不是装饰性统计，而是用来说明该项目已经不是聊天框里一句提示词生成的简陋玩具，而是具备中型小游戏雏形的可试玩工程。

游戏核心配置规模

试玩版内部的策划配置规模也被明确量化：

主线任务：45 个
基础与高级道具：57 个
多级物品生成器：10 个
剧情线索条目：12 条
场景修复目标：8 个
支线委托任务：9 个

这说明项目不是只有一个二维数组合成盘，而是已经包含任务推进、资源生产、剧情线索和场景修复等多套互相联动的数据系统。

工程骨架拆分

由于作者没有找到可以直接复用的商业级开源微信小游戏源码，只能自行从零搭建底层。最终，工程被强制拆成六层骨架：

game.js：游戏唯一入口，负责初始化微信 Canvas 上下文
data.js：核心配置层，管理 57 个道具、45 个任务等联动关系
state.js：全局状态机，负责存档、金币、体力和棋盘格子状态
input.js：输入与视口交互层，处理手指点击、长按、拖拽和吸附逻辑
renderer.js：Canvas 渲染核心，负责动效绘制、粒子特效和帧率控制
audio.js：声音管理器，控制 11 种高频反馈音效的并发播放

作者的经验是，在缺少同类开源底层的情况下，先把入口、数据、状态、输入、渲染、音效这些基础职责切清楚，后续迭代才有稳定落脚点。

对 AI 能力边界的关键判断

文中的核心判断是：AI 会写代码，但不会自发理解游戏为什么“爽”。

作者踩到的最大坑不是 Codex 写不出功能，而是它在指令模糊时会很快生成一个“功能看似完整、体验却非常难玩”的版本。例如：

棋盘能合成，但界面死气沉沉
拖拽存在卡顿和生硬回弹
合成发生时没有足够的视觉爆点
任务完成后只是弹文字，没有奖励承接与资源飞行动画

因此，作者不是继续追加大而泛的需求，而是把体验拆成可执行的微交互规则，再交给 AI 实现。

重要细节

1. 项目目标不是 Demo，而是完整试玩闭环

作者一开始就明确否定两种常见误区：

不是“帮我写个合成棋盘 Demo”的网页玩具
不是只画几张 UI 概念图的自嗨原型

真正目标是“功能闭环、体验完整”的微信小游戏试玩版。它至少要同时具备任务系统、剧情推进、道具链、多级生成器、场景修复、奖励飞行特效、音效反馈和新手引导，还要在微信开发者工具内稳定预览。

这一目标设定直接决定了项目后续所有工作流：不能只追求单点功能实现，而必须同步考虑状态机、数据结构、资源体积、输入手感、动效节奏和平台限制。

2. 找不到现成源码后，先撕开“商业源码”的遮羞布

作者认为，使用 AI 做游戏的高效路径通常是先在 GitHub 或其他开源社区中找到同类项目底层，让 AI 先理解已有工程结构，再替换题材和资源进行改装。

但这次针对《绯闻港口》《Merge Mansion》这一类吸金合成经营品类，作者没有找到可开箱即用的微信小游戏级源码。能找到的东西主要只有两类：

只有二维数组合成矩阵的极简 Demo
和微信环境无关的普通 Web 页面

也就是说，缺的不是“合成逻辑概念”，而是一个能承载商业玩法闭环、适配微信小游戏环境、并且可继续扩展的数据与渲染底层。

在这种情况下，作者的应对方式不是继续盲目让 AI 从主循环开始散写，而是先按传统软件工程思路拆出六层骨架。这个动作的意义在于把问题空间收窄：以后每一项需求都可以明确归属到数据、状态、输入、渲染或音频某一层，而不是在一个巨型脚本里缠成一团。

3. “爽感”必须拆到微交互级别

文中最关键的方法论，是把体验标准拆成 AI 能执行的微交互清单。

作者举出的具体要求包括：

每次点击生成器时，要有轻微下凹的物理反馈
点击同时要配一声清脆的“啵”类音效
道具拖到相邻格子时，要有零点几秒的磁力吸附感
不能让道具松手后生硬弹回原位
两个道具重合合成的瞬间，必须在原地爆开一圈金色粒子
合成结果不能只是静态替换，需要有由小变大再回弹的缩放动画，即 Juice 效果
任务完成不能直接跳一段文字
应该先弹出结算牌
点击确认后，金币要沿贝塞尔曲线飞向右上角资源栏
顶部资源栏还要再闪烁一下，作为奖励落袋的确认反馈

作者甚至给出了一个简化后的 playJuiceEffect(x, y) 动效逻辑示例：先在前 10 帧每帧放大 0.04，再在 25 帧前每帧缩小 0.03，最后回到 1.0。这类实现不算复杂，但如果没有人先把“什么时候变大、什么时候回弹、为什么这样做”定义清楚，AI 很难主动补到这个程度。

作者还提到另外两个具体的体验调整：

不要一上来就把所有生成器都摆出来，而要跟随任务逐步解锁
不要用冰冷的“锁”字去挡格子，而要改成神秘的沙地迷雾，让探索感更自然

这说明微交互拆解并不只覆盖动画，也覆盖解锁叙事和界面表现语义。

4. 为什么要用本地 H5 工作台替代 Markdown 大纲

作者明确反对在复杂合成经营项目中只依赖 Markdown 大纲式策划文档。原因很直接：游戏运行时并不理解宏大叙事，它只认结构化数据。

当系统里同时存在 45 个任务、57 个道具、10 个生成器时，必须解决下列问题：

每个道具的前置是什么
每个道具后续可以合成什么
生成器的产出概率是多少
哪个任务会解锁哪一块沙地
线索道具合出后对应哪一段剧情推进

只要其中一个 ID 没对上，就可能造成：

合成后剧情不弹出
任务推进中断
状态机进入死锁
玩家面对无反馈屏幕不知所措

因此作者让 Codex 帮忙写了一整套可交互的本地 H5 策划与素材管理系统，而不是继续堆聊天记录和 Markdown 文档。