下载 App
开发复盘｜用 Codex + Cocos 3.8，把《方块不听话》做上线
大家好，我们是枳夏游戏屋。《方块不听话》已经在 TapTap 创意工坊和大家见面了。上次和大家介绍了玩法，这次想聊聊它是怎样从一个想法，走到真正能试玩的版本。
如果你也想和 AI 一起做一款小游戏，可以先把问题问清楚：玩家要做什么，这一局怎样开始、怎样结束，第一版做到什么程度才算完成。等这些有了答案，再一步步把它变成真正能打开、能操作、能提交的平台版本。
这次开发用到了 Codex、Cocos Creator 3.8、funplay MCP、oops-framework 和 TapTap MCP。下面按开发顺序展开，也分享怎样把“画面太死”“这里操作不对”这样的反馈，变成下一轮能执行的任务。希望能给想动手做游戏的朋友一点具体参考。
本次开发的推进顺序。功能、视觉与测试会反复回到前面的步骤，并非只走一遍。
01 先让 Codex 理解要做什么
最开始，我们想做的是一款适合碎片时间的休闲游戏：单手拖动彩色方块，在棋盘里规划位置，填满一行或一列就能消除。规则容易理解，但留空间、调整顺序和连续消除，应该能让人多想一步。
把这个想法交给 Codex 时，我们还补上了几个条件：使用 Cocos Creator 3.8 和 TypeScript，竖屏设计尺寸为 720×1280；画面走明亮、圆润、有玩具质感的方向；既有经典冲分，也有带收集目标的冒险模式；底部要给广告预留独立区域。
这些条件看起来琐碎，却会直接影响工程。比如先确定竖屏，后面就不会按横屏界面重新安排棋盘；先说清广告区域，按钮和暂存槽就不容易做到最后才被迫挤位置。把约束写出来，Codex 才能据此安排任务，也能在后续修改时检查有没有偏离。
我们的体会是，同时讲清目标、约束和下一步交付物，沟通会更有效。下面这类提示词可以直接换成自己的项目需求。文中的对话配图均为复盘时整理的任务示例，不是原始聊天记录截图。
提示词整理示意：先明确规则和交付物，再进入实现。
02 把想法写成能执行的设计文档
文档阶段，我们让 Codex 把“拖方块、消一行”继续拆开。棋盘是 8×8，颜色不影响消除；消除以后，没被清掉的方块保持原位；一次落子同时填满行和列时，要一起结算，交叉格里的宝石只能收集一次。
再往下，还有容易被一句话带过的边界：拖到非法位置怎么办？暂存槽已经有方块，还能不能放第二块？最后一个候选存进暂存槽后，要不要补发下一批？冒险目标完成的同一刻，应该先判胜利，还是先判断棋盘无处可放？
这些问题如果留到写代码时才决定，界面、规则和存档很容易各有一套理解。我们把它们放进同一份文档，再列出首页、玩法、教学、设置、语言、皮肤、成就和结算等页面，写清页面之间怎样跳转。
技术安排也一起确定：规则逻辑独立保存，界面使用可编辑的 Prefab；先考虑公共按钮、棋盘、候选槽、暂存槽这些可复用的部件，再搭具体页面。与此同时，为每个阶段写上验收条件，例如第一版必须完成真实拖放、合法性判断、消除和结算。
这份文档后来一直在更新。新增六种语言、调整暂存规则、增加皮肤时，先把规则改清楚，再同步实现和测试。这样下一轮对话就有了共同依据，不需要每次从头描述整个游戏。
03 先确定效果图 再把画面拆成资源
玩法有了边界，接下来才是画面。我们先生成整屏效果图，讨论棋盘大小、顶部信息、底部候选和工具的位置，以及方块、角色和按钮是否属于同一种风格。竖屏页面直接按 720×1280 制作，底部的广告预留区也一起展示。
视觉方案阶段的玩法界面，用于确定构图、比例和美术方向；它与最终实机画面并非完全相同。
效果图阶段适合解决“想做成什么样”。比如按钮是否太抢眼，棋盘是否显得局促，弹窗会不会遮住必要的信息。等方向确认，再逐项准备背景、边框、方块、图标、按钮和弹窗资源。
落地时，我们没有把整张界面图直接铺进游戏。标题、文字、图标、进度条和按钮都要能独立编辑，棋盘里的方块还要随回合变化。图里的柔和阴影、圆角和高光，也需要转换成可以复用的素材与组件。
这个阶段很容易低估工作量。看起来接近效果图，只是第一步；换一个长屏手机，按钮仍然完整，弹窗没有挤压，文字切换语言后还能读清楚，才算把画面落进了游戏。
04 用 funplay MCP 连上编辑器 用 oops-framework 整理工程
这套工具里，Codex 负责理解任务、读写代码和组织检查；Cocos Creator 负责场景、组件、资源和构建；funplay MCP 则把 Cocos 编辑器里的操作能力接给 Codex。oops-framework 负责项目里的运行时基础结构，TapTap MCP 负责平台侧的相关操作。各自做什么，开始时就要分清楚。
让 Codex 能检查正在运行的 Cocos 项目
funplay MCP for Cocos 以 Creator 扩展的形式安装。按照它的说明，在编辑器打开 Funplay > MCP Server，使用客户端配置功能连接 Codex。连接地址以当前项目面板实际显示的 URL 为准，多个项目同时打开时尤其要核对项目身份。
连上以后，先让 Codex 读取当前项目、场景和脚本诊断，确认它看到的正是要修改的工程。接着才通过 execute_javascript 等工具，在编辑器或场景上下文里完成节点、组件、资源检查和保存，并用截图核对结果。[1]
对我们来说，它很有用的一点，是把“代码已经写好”继续推进到“资源实际挂上了”。修改一个按钮后，还要看它所在的节点、Sprite 引用、事件绑定和页面显示。Prefab 保存到工程里之后，也要重新加载、实例化和检查，避免只在临时运行状态里看起来正确。
让后续修改有稳定的工程结构
项目里接入的是 oops-framework。我们用它组织界面和资源加载：AppRoot 继承框架的 Root，通过 oops.gui 管理页面与弹窗，通过 oops.res 加载资源。启动场景保留必要的启动结构，进入某个页面时，再加载对应 Prefab。
核心回合规则单独放在 RoundModel，存档、本地化和广告适配分别放在对应服务中。这样调整消除规则时，不必同时改所有页面；修改一个弹窗的间距，也不会顺手碰到计分逻辑。
如果是从零开始，可以先让 Codex 阅读项目实际使用的框架版本，确认入口、目录和现有 API，再安排实现。对于这次项目，沿用清楚的分层和原生 Prefab，让我们后面几轮修改都更容易定位。
05 第一版先把一局完整跑通
进入编码后，我们先收紧目标：能从首页进入，拿起一个候选方块，拖到棋盘，合法时放下，填满行列后消除，没地方放时进入结算，再开始下一局。
这条操作链跑通之后，再加入冒险收集、暂存、刷新、存档、皮肤和多语言。每加一个系统，都重新走一遍旧流程。例如暂存会影响候选区什么时候补牌，刷新会影响连击和宝石分配，切换语言则不能重建或清空当前对局。
经典模式实机画面。界面、落点、候选区和暂存都需要在真实输入中检查。
任务也尽量拆得能当场验证。与其一次要求“把所有功能都完善”，我们更愿意先完成一个明确目标，比如“允许任意候选拖进空暂存槽，并在最后一块存入后正常补牌”，完成后就操作一遍，再继续下一项。
首版能玩之后，后续讨论会具体很多。你可以指着屏幕说这一块拿起来太小，这个提示挡住了棋盘，或者这个按钮点完看不出有没有响应。此时每一次反馈，都能落到一个实际状态上。
06 初版画面太死 继续把它做活
初版跑起来以后，有一个很直接的感受：功能是有了，但画面太死。首页角色站着不动，按钮点完变化不明显，方块放下和消掉虽然都有结果，却缺少让人感受到“这一手成功了”的反馈。静态效果图里看着不错，连续操作起来仍然少了点意思。
于是我们继续和 Codex 对话。最开始的反馈可以很直白：“这一版画面太死了，想让它活起来。”接下来再把这句话拆成具体任务：哪些地方需要动、玩家做了什么之后动、动到什么程度，以及什么时候结束。
提示词整理示意：从“画面太死”的直观感受，拆到具体动作和验收条件。
首页先给角色加轻微呼吸和跳动，让 Logo 偶尔小幅摇摆；按钮补上按下和回弹，弹窗有进入、退出的过渡。进入玩法，再补方块拿起、抬高、落点预览和放下时的轻压。这样玩家移动手指时，画面会跟着给出明确回应。
消除也继续打磨：行列扫光、短促碎粒、加分和连击提示，胜利时再给一小段彩纸。普通消除和多线消除的反馈要有区别，达成目标时，也要让人马上知道这一关已经完成。大部分效果使用 Tween 和受限数量的特效来实现。
每补一轮就实际玩一遍：是不是更有反馈了，会不会晃得太多，消除后等下一手的时间是否太长。觉得不合适，就继续给 Codex 描述具体状态，缩短时长、减小幅度或调整出现顺序，再运行比较。
动起来以后仍要检查操作。按钮的热区要稳定，特效别挡住落点，动画结束后能够马上继续下一手。我们希望玩家感到游戏有了精神，也能顺畅地把注意力留在棋盘上。
07 提交审核前 把自测和修复走完整
从这里开始，开发进入反复的循环：运行、操作、记录问题、修复，再走回原来的操作路径。我们让 Codex 保留测试报告和运行截图，同时自己在目标手机上检查。
第一层是规则检查。放不下的方块是否原样退回？横竖交叉消除有没有重复计分？冒险目标有没有重复收集？广告取消后，暂存和候选供给能否完整恢复？这些问题可以先在独立于 Cocos 的逻辑里反复验证。
第二层是实际交互。点击首页入口，完成教学，拖进棋盘，再拖进暂存槽；打开设置，切换语言，然后回到原来那一局继续玩。这里只调用游戏内部的某个方法还不够，还要验证实际输入能不能命中，以及页面切换后的状态是否正确。
第三层是布局和构建。我们检查不同尺寸、长宽比、安全区和页面组合，也单独运行构建后的产物，观察资源是否完整、是否出现脚本或加载错误。冒险的十个关卡则保留了不依赖刷新和复活的参考解，用来检查关卡是否能正常完成。
提示词整理示意：给出操作路径、预期结果和保留证据的要求，便于复现与回归。
遇到 bug 时，我们把自己看见的情况继续交给 Codex：在哪个页面，从哪一步开始，做了什么操作，现在出现什么结果，希望它应该怎样表现。能附截图就附截图；涉及连续动作时，把前后步骤写完整。即使暂时不知道是哪段代码出问题，也能先给出可复现的现象。
例如可以这样描述：进入教学后完成指定拖放，观察到方块的消除表现不一致。请先按这条路径复现，说明你定位到的问题，再修改。修复以后重新操作同一步，并检查普通玩法里的消除是否仍然正常。这里是复盘整理的沟通示例。
等 Codex 完成修改，再沿着同一条路径亲自操作一次：原来的问题是否消失，旁边的功能有没有被影响。没有达到预期就继续反馈，必要时补上设备和页面状态。一次对话没改对，就把实际结果带回下一轮，直到复现、修复和复测能对得上。
尤其要把这轮工作放在提交审核之前。先运行最终包，自己从首页到教学、玩法、结算完整玩一遍，再检查目标手机里的布局、触摸和平台功能。别因为编辑器预览没有报错，就急着把版本提交出去。
如果把问题拖到首版上架后再迭代，首批玩家先遇到的就是 bug，开发者还要重新改包、复测、上传，承担下一轮审核和发布的等待。根据版本所处状态，修复也可能赶不上原定的首发安排。提交前省下的那一点自测时间，很容易换来更多返工，得不偿失。
08 手感要用小改动反复调出来
规则正确之后，我们仍然花了不少精力调整拖放手感。方块抬起多高，才不会被手指挡住？靠近暂存槽时，是先缩小预览，还是松手才缩小？拖到非法位置后，退回的速度会不会让人觉得迟钝？
暂存功能就是一轮轮细调的结果：空槽接受任意候选；进入热区时，浮动方块缩小并居中预览；离开热区恢复棋盘尺寸；已经存下的方块可以取回棋盘。每改一处，都要再次检查剩余次数、补牌和存档。
给 Codex 的反馈也逐渐从“这里不顺”变成了具体描述：发生在哪个页面、手指经过哪里、画面出现了什么、希望它什么时候响应。必要时一次只改一个距离或一段动画，再实际拖几次比较。
这些修改很难靠一张截图判断完。看起来好看、操作起来明确、连续玩几局仍然舒服，是需要分别感受的事情。AI 可以加快改动和检查，人仍然要给出自己真正体验到的反馈。
09 先备齐物料 再用 TapTap MCP 串起上架
游戏能玩之后，还要面对物料、构建、平台资料和版本状态。我们这次发布的是 TapTap 创意工坊 H5 版本，TapTap MCP 让其中不少重复步骤可以直接交给 Codex 调用。
项目使用的服务包是 @taptap/instant-games-open-mcp，环境中需要有可用的 Node.js 和 npx。以 Codex 的 STDIO 配置为例，可以在 MCP 配置中加入下面的服务项。服务包名来自本项目接入说明，Codex 配置结构可查官方 MCP 文档。[2]
[mcp_servers.taptap-minigame]
command = "npx"
args = ["-y", "@taptap/instant-games-open-mcp"]
command = "npx"
args = ["-y", "@taptap/instant-games-open-mcp"]
连接后，第一次使用需要完成 TapTap 账号授权。然后列出账号下的开发者和应用，由开发者明确选定这次操作的游戏，再继续处理。多项目账号里，确认目标应用这一步尤其重要。
我们的实际流程可以分成四段。第一段，先把上架物料准备好：游戏名称和简介、分类与竖屏方向、图标、宣传封面、实机截图，以及平台要求的隐私政策等资料。需要演示素材时，也提前从最终版本实际操作中准备。图片尺寸、格式和数量，按当前平台要求逐项检查。
这一步值得单独留时间。玩法截图要能看清游戏，封面和图标要和游戏形象一致，简介要说清核心玩法和模式。别等包已经构建好了，才发现封面没做、截图还是旧版、介绍没写完，最后一边补物料一边赶着上传。资料和构建产物一起备齐，上架流程才容易顺着走下去。
图片准备好后，可以通过 MCP 先上传，再把返回的地址写入应用资料。保存后重新读取或检查后台，确认平台收到的是这次准备的内容。
第二段是构建和检查。通过 Cocos 的发布任务产出 H5，确认目录中有 index.html，检查启动场景、资源引用和正式构建配置，再运行一次最终产物。本项目把共享美术、界面和音频拆成独立 Asset Bundle，避免资源重复打包，也方便按需加载。
第三段是上传。把已经确认的构建产物相对目录交给 prepare_h5_upload 检查，核对应用、目录和相关信息后，再调用 upload_h5_game。这里要提供真正的构建目录，不能只把 Creator 的源工程目录当成 H5 包。
第四段是平台自测、提审和状态回读。用实际上传的版本再做一轮手机自测，发现 bug 就先修复、复测，确认包体与上架资料都准备好以后再提交审核，然后读取版本状态。本文整理时，工具实时返回《方块不听话》已上线。
如果把它叫作“一键上架”，我们更看重的是：开发者可以用一段明确的任务，让 Codex 依次组织资料、检查、上传和状态核对，减少来回复制和切换页面。账号授权、目标确认、真机自测与平台审核，仍然属于这条流程。本项目的提交审核也结合了开发者后台操作，MCP、构建脚本与后台各自完成它们支持的环节。
可以这样下任务：请先确认当前 TapTap 目标应用，检查已构建的 H5 目录和上架物料，列出缺项。信息核对后再上传，保留本次包体和版本标识；真机自测通过后，再处理提审，并回读最终版本状态。
10 这次最有用的是每一轮都有实际结果
回看整个开发过程，Codex 帮我们做了大量拆解、编码、资源组织和测试工作。funplay MCP 把编辑器操作接进来，oops-framework 让项目有可持续修改的结构，TapTap MCP 再把平台侧的一部分工作接上。
推进最顺的时候，任务通常都很具体：这一轮交付文档，下一轮交付效果图，再下一轮交付一条可以实际操作的玩法链。出了问题，能找到对应场景、截图和步骤；修好以后，还能回到同一条路径上验证。
如果你也准备这样做，我们建议先选一个范围可控的玩法，把第一版做小，把完成标准写清楚。先完整跑通一局，再逐个加入系统；每次修改后都验证，而不是等所有功能堆在一起才开始试玩。
最后 邀请你来玩玩方块不听话
说了这么多开发过程，还是想把游戏交给你亲手试试。它的规则很简单：把不同形状的彩色方块放进棋盘，填满行列就能消除。经典模式里挑战自己的最高分，冒险模式里通过消除收集宝石，暂存和刷新则为调整顺序留出一些空间。
冒险模式实机画面。目标是通过消除收集宝石，首版提供 10 个关卡。
我们还准备了表情软糖、猫猫方块、星际机甲、霓虹街机和棉花团子等造型，支持简体中文、英语、西班牙语、葡萄牙语、法语和阿拉伯语。游戏含广告，部分额外刷新、暂存、复活与皮肤解锁机会，可自愿观看激励视频获得。
想试试最终的游戏，可以点击帖子末尾的《方块不听话》游戏卡片，或者在 TapTap 搜索游戏名。欢迎来玩一局，告诉我们哪次消除最舒服、哪个地方还不顺手，也欢迎晒晒你的最高分。
对我们来说，这也是上线后的下一轮开发：从玩家真实遇到的问题开始，继续把方块摆得更顺手。如果你也在用 AI 做游戏，欢迎在评论区聊聊自己最容易卡在哪一步；如果你已经试玩，也想听听你对动效和拖放手感的真实感受。
