从主界面到核心玩法拆解关卡设计与 AI 协作

一个拆螺丝小游戏，看起来只有“点螺丝、装盒子”几个动作。真正动手还原，我们才发现：画面只是入口，背后还有关卡配置、颜色策略、资源加载、弹窗事件和一连串动画。少接一个环节，游戏就会显得“哪里不太对”。

这篇文章分享我们用 AI 辅助移植这个项目的实际过程。我们会从主界面与核心玩法讲起，拆解模型遮挡、颜色匹配和关卡难度，再分享资源移植、动画恢复与 AI 批量验收的方法。读完之后，你应该能把一款游戏拆成可执行、可核对的工作清单。

图 1 项目实际 App 截图第一轮先打通加载 主界面和关卡界面

我们最有用的经验：给 AI 明确的材料和验收标准。资源从哪里来、行为依据是什么、改完怎么验证，都要说清楚。

先把游戏读懂再让 AI 写代码

接手项目时，我们先整理已有材料：原场景、预制体、图片图集、字体、音效、材质、关卡配置，以及可用于分析原逻辑的程序信息。每类材料回答的问题不同，放在一起才有完整答案。

可以把预制体理解成“搭好的舞台”，配置表是“节目单”，代码是“演出规则”。拿到舞台，并不意味着按钮已经接好；看到一份类名列表，也不意味着里面的方法有真实实现。

图 2 我们采用的恢复闭环每轮都从证据走到真实运行

第一步先定一个小闭环：加载界面能出现，主界面能进入关卡，关卡能收集并返回。这样每次改动都有落脚点，也能尽早发现层级、字体和场景切换问题。

AI 在这里适合做整理员：批量查找类与资源的对应关系，梳理按钮入口，把散落的信息整理成清单。我们给它的约束是：优先使用原资源、原层级和原配置；缺少证据的地方单独记录，别凭感觉补成另一套游戏。

一个可直接复用的任务写法

“先读取项目流程和相关配置，列出这个界面的入口、预制体、数据来源和关闭路径。依据原逻辑恢复，完成后编译 App，检查真实按钮、状态变化和游戏内截图，并记录尚未恢复的部分。”

任务越具体，结果越容易检查。把整个游戏压成一句“帮我完整复刻”，往往会让完成范围和实际质量脱节。

主界面先回答玩家接下来做什么

主界面是整款游戏的导航中心。我们把它拆成四块来理解：顶部的资源与设置、中间的关卡路线、当前关卡的 Play 按钮，以及底部的四个页签。玩家每次回来，都应该能看懂自己走到哪里、下一步点哪里。

图 3 主界面实际截图当前关卡与 Play 是视觉重心

顶部体力和金币负责解释资源状态，设置入口负责声音、音乐等偏好。中间用纵向路线呈现关卡进度，当前关突出显示；Play 把这个进度转换成一次真实的关卡加载。底部依次是商店、主界面、主题活动和排行，位置与选中态沿用原预制体。

恢复这类界面时，我们先画入口关系，再接事件：点击金币加号切到商店页，点击 Play 进入 loading，再进入当前关；关卡暂停后回到主界面，应看到对应的进度。图标、选中态和页面显示必须一起切换，才不会出现“底栏选中了，内容没换”的情况。

还要注意开放条件。原入口规则是前 10 关优先进入玩法，11 关起才进入主界面。为了验收早期主界面，我们使用显式测试入口；正式启动仍按原规则走。这类差异来自流程设计，不能仅凭一张截图反推启动行为。 

主界面恢复要把展示和业务分开核对

我们给主界面建立了三张清单：有哪些区域，每个区域显示什么数据，每个按钮要走到哪里。资源、进度、购买、解锁看起来都只是几行文字，但它们应当来自各自的状态管理模块。否则，下一次打开页面就可能出现数值回退或进度不同步。

以一次完整旅程为例：玩家从主界面进入当前关，收集完成后推进存档，再点继续进入下一关；返回主界面时，当前关的高亮和 Play 的目标也应随之更新。如果只检查“这个按钮点得动”，整条旅程中的错位就会漏掉。

图 4 主界面与关卡的连接示意每次返回都要重新读取进度

商店页承担资源补给，主题页和排行页则是内容扩展入口。文章里需要把范围说明白：这次已经恢复商店展示与免费金币等交互，活动、排行榜的完整业务和实际支付服务仍有待完成。把入口摆出来，不代表它背后的计时、排名或交易链已经通过验收。

主界面有三个值得单独验证的细节。第一，滚动后是否仍能定位当前关；第二，关闭二级页面后，底层页面是否恢复点击；第三，切换窗口比例后，顶部、安全区和底栏是否仍然对齐。手机参考截图的留白来自安全区，桌面窗口不必照抄同一段像素距离。

这一部分适合交给 AI 做批量核对：搜索原预制体里的按钮和文本引用，追踪监听方法，再列出缺失实现。人工负责检查视觉重心与真实路径。我们优先还原能走通的入口，随后逐个补全活动等长链业务。

可复用的验收要求

“进入主界面后核对当前关；切换四个页签并检查选中态；从金币加号进入商店再返回；点击 Play 确认 loading 可见；完成或重试关卡后检查进度与页面状态。对未完成的业务单独列明。” 

核心玩法是一道空间判断与收纳题

这款游戏的目标，是把立体模型上的螺丝拆下来，按颜色收进盒子。每个收集盒装三个同色螺丝，装满后离开并补入新盒。没有当前匹配盒子的螺丝，先进入有限的暂存孔；玩家需要在空间解锁和暂存容量之间安排顺序。

图 5 关卡实际截图顶部收纳决定取舍 中部模型提供空间判断 底部道具提供解围方式

玩家先旋转或缩放模型，寻找露出的螺丝。点到螺丝并不一定能直接取下，还要通过遮挡和可点击判定；按压模型时的透明反馈帮助观察内部结构。拆掉固定件后，相应部件会释放，可能露出下一层可操作区域。

初始数据里有四个盒子槽位，其中两个开放、两个锁定；暂存孔初始为五个。它们提供了两种不同资源：盒子决定哪些颜色能立即收集，暂存孔允许玩家暂时拿走“不合适”的颜色，换取更深层的操作机会。

因此，玩家每一步都在问：这颗螺丝能直接入盒吗？如果先占一个孔，能否换来一颗关键螺丝？旋转一下，是否存在更好的入口？这些选择，比单纯增加点击次数更能构成玩法。

一次点击背后有五个相连的状态

我们把核心步骤按实际数据流拆开：模型上、暂存孔、收集盒、特殊临时区、已收集。每次操作都要同时更新数据状态和画面位置，避免螺丝看似飞进盒子，数据却仍留在模型上。

图 6 核心收集流程示意同色入盒与异色暂存最终汇入换盒链

第一步先判定能否操作。遮挡、暂停、弹窗和当前动画状态都会影响接收输入。第二步改变归属：有可用的同色盒子就入盒；否则占用一个暂存孔。第三步播放旋出、移动、拧入等表现，让结果可观察。

第四步检查是否装满三个。满盒进入收集与换盒动画，新的盒子在落定前保持接收锁定。第五步查找暂存孔中的同色螺丝并自动补入；如果又满三个，继续换盒。这个自动链路结束后，才进入稳定的可操作状态。

胜负判定也要放在正确的时点。完成看的是已收集数量是否达到总数，不是模型上暂时已经看不到螺丝；暂存孔占满时，还要考虑是否存在正在结束的换盒或补入动作，避免在马上能腾出空位时提前判负。

举个普通操作例子：两个盒子分别收蓝色和黄色，暂存孔已有两颗绿色。玩家拆下第三颗蓝色完成一盒，下一盒若是绿色，就会在落定后自动接走那两颗绿色，暂存压力随之下降。这里“下一盒是什么颜色”和“何时补入”，共同决定了体验。

AI 在恢复这段逻辑时，最需要的是明确的状态表和步骤顺序。只要求“点一下飞过去”，很容易漏掉第三颗触发、自动连收、失败时机和动画中重复输入等边界。 

四种道具分别改变了什么

道具设计要放回核心循环里看。它们改变的是容量、收纳位置、收集对象或空间结构；如果只恢复图标和粒子，玩家可能看见很热闹的效果，却没有得到对应的解围结果。

图 7 四种道具的 App 实际效果截图中的状态来自不同验收步骤

电钻增加暂存孔，扩展的是容错容量。验收要检查孔位数量、库存消耗和上限，新增孔出现时还要沿用原布局与动画，避免把整排孔挤出屏幕。

扫帚把暂存孔里的螺丝转移到特殊临时区，释放当前孔位。它并非直接删掉这些螺丝，也不应凭空增加完成数。后续遇到匹配盒子时，临时区中的螺丝仍要继续进入收集链。

磁铁按数据规则挑选盒子所需颜色的螺丝，帮助完成当前收集目标；锤子进入部件选择状态，处理所选部件上尚未移除的螺丝，并释放部件。二者既要对齐选取对象，也要对齐粒子、冲击位置与实际数据结果。

我们的检查顺序是：能否使用、扣了几次、效果是否出现、数据改变是否正确、结束后输入是否恢复。尤其要在动画中再次点击一次，确认库存只消费一次。手机触感和广告回调还需要各自的真机或服务验收，桌面效果通过不能代替它们。

关卡设计先拆成结构和规则两层

以下关卡分析来自项目配置和已恢复的原逻辑；后文的编排方法则是据此整理的设计建议。我们没有用素材数量推断完整策划意图，也没有把加载成功当成关卡已经平衡。

结构层描述模型怎样组成：有哪些部件、螺丝位于哪里、属于哪个部件、层级如何、移除后如何释放，以及模型默认朝向和缩放。规则层描述这一局怎么运行：使用哪些颜色、采取哪套难度策略、盒子如何接续，以及可用容量与道具状态。

图 8 不同关卡的实际模型外形变化之外还要关注视野与可操作范围

为什么只替换一个漂亮模型还不够？因为同样是几十颗螺丝，均匀分布在外表面，和分布在互相遮挡的多层部件里，需要的判断完全不同。关卡的难点往往来自“为了解开里面，先移除外面”，而不是文件本身有多大。

实际移植时，我们沿着关卡所属分包查找模型版本，保留原层级、螺丝索引和部件关联。一个同名模型的旧版本，即使外形接近，也可能让配置指向错误的孔位或部件，继而破坏释放顺序。

最实用的梳理方法，是把模型看成一张依赖图：某些螺丝挡住部件释放，某些部件又挡住后方螺丝。图里既要记录几何上的遮挡，也要区分“转动后能看见”和“必须先拆掉前方部件”两种情况。画清这张图，才知道玩家每一步实际上获得了什么。

颜色与盒子策略决定收纳压力

项目里的初始颜色并非简单复制模型上的材质颜色。初始化会按三颗一组准备颜色数量，再分配给螺丝；盒子用颜色索引匹配，而不是从屏幕像素里识别颜色。这让模型结构与本局配色成为可组合的两层数据。

更值得注意的是下一盒的选择。已恢复的策略读取当前盒子的颜色与剩余容量、暂存孔占用、可见螺丝、被哪些部件遮住的螺丝，以及当前收集进度。难度配置按进度阶段选择策略，使用道具和复活还会进入相应的策略数值。

图 9 本项目下一盒颜色选择的输入示意实际选择由配置规则决定

因此，“固定随机种子”只能让一次测试更容易重现，并不能替代原策略。若把下一盒改成随便抽色，可能出现暂存孔里已有两颗绿色，却迟迟没有绿色盒子的情况；也可能始终发最容易完成的颜色，让原有节奏消失。

我们恢复时先核对策略配置，再核对输入统计是否正确。例如，一颗螺丝肉眼露出一点边，是否满足实际点击条件？后方某颗螺丝要清理哪些部件才会可达？这些统计如果偏了，选色规则即使完全照搬，也会得到不同结果。

这类状态驱动的选择说明，关卡配置不是一条静止的盒子队列。但它也不意味着可以宣称系统“永远保证可解”或“专门制造失败”。这些结论需要另外的全路径验证与行为证据，不能由几个字段直接推断。

给开发者的经验是：保存每次选色前的输入摘要、命中的规则和选色结果。当玩家说“这一局明显不对”，可以沿着日志比较恢复前后的差异，而不是只对着一张失败截图猜原因。

从这个项目提炼五个关卡设计技巧

下面是面向自研和改编项目的设计建议，用来帮助组织关卡；示例参数是讲解用的小例子，不是原游戏的官方关卡配方。

技巧一 先安排玩家第一眼能理解的目标

开局最好能看懂一小段因果：拆下露出的固定件，部件离开，露出下一层。模型可以复杂，但第一步要清楚。教学时先让玩家完成一次同色装盒，再逐渐引入异色暂存、旋转观察和部件释放，避免同时解释全部机制。

技巧二 用遮挡组织顺序用颜色组织取舍

遮挡回答“先拆谁”，颜色回答“现在值不值得拆”。例如，关键红螺丝藏在一块前板后，移走前板要先取出两颗暂时没有盒子的绿螺丝。玩家必须判断：为获得红色入口，占两个孔是否值得。只增加螺丝数量会拉长流程，把结构与颜色组合起来才会增加选择。

技巧三 用暂存容量检验一条路线的代价

教学示例：暂存孔总共五个，已占三个。如果清开一层遮挡需要先拿走三颗都没有匹配盒子的螺丝，那么这条路线在没有途中腾位、其他视角或道具的前提下会被容量挡住。设计时要检查是否还有另一条路线，或是否明确希望玩家使用道具。总颜色能整除三，并不能证明每一步都走得通。

技巧四 安排紧张之后的释放

暂存孔接近满时，玩家会更慎重。随后通过新盒接走暂存螺丝、移走大部件或连收一盒，让压力得到可见释放，节奏才有起伏。连续很多步只占孔、不产生结构变化，玩家容易把困难理解成拖延。

技巧五 把可读性纳入难度预算

很小的点击区域、相近的颜色、默认镜头切掉模型边缘，都可能制造额外困难。先区分“需要思考”和“看不清点不到”，再调整关卡。设计还应照顾不同纵横比，保证盒子、暂存孔与主要操作区不会相互遮挡。

这些建议最终都要通过真实游玩验证。保留多个种子和操作路径，记录失败发生在哪一步、当时有哪些合法动作，再决定是调整结构、选色还是容量。不要只凭一条成功路径就判断整关已经合理。

让 AI 帮忙分析关卡而不是凭感觉凑难度

在有结构化配置之后，AI 才能更具体地参与关卡分析。我们会把任务分成三种：脚本计算确定事实，AI 解释异常与提出候选方案，人工在真实场景里判断体验。这样每一个建议都有可回查的输入。

第一种任务是静态体检。让脚本统计每关螺丝数、部件数、颜色集合、缺失引用和默认镜头范围，优先筛出索引错误、模型版本不符、极宽或极高模型。AI 再将异常按共同原因归类，减少逐文件排查。

第二种任务是路径检查。测试程序在当前状态枚举合法操作，沿每一步更新遮挡、暂存占用与盒子状态；规则完整时，再考虑搜索通关路线。AI 可以协助写工具和阅读轨迹，但它口头说“这关可解”，不构成解算结果。

第三种任务是体验归因。可以记录峰值暂存占用、连续未入盒步数、首次换盒前的操作数、需要旋转寻找入口的次数，以及道具使用前后状态。它们帮助解释压力来自哪里；这些指标是建议新增的分析维度，不是本项目已经完成的玩家数据统计。

一条更具体的 AI 任务示例

“读取指定关卡的部件与螺丝关联，整理可见入口和遮挡依赖；使用真实规则记录前 20 步的盒子颜色、暂存孔占用和合法动作。遇到无后续动作时保存状态，不自动修改规则。最后提出两种最小改动方案，说明各自影响哪项输入，再分别运行验证。”

调整时保留对照。一次只动一个主要变量，比如改变一层遮挡，或替换一组颜色规则；使用同一组种子复测。否则，模型、颜色和容量同时改变，即使体验改善，也很难知道哪个改动真正起作用。

还要把三种“通过”分开写：资源可以加载、核心规则能运行、玩家可以顺利理解并完成。前两种适合自动检查，第三种仍需要观察真实游玩。AI 能扩大检查规模，设计师仍需对学习节奏、操作反馈和失败感受负责。

资源导进来了还要找到使用规则

最初看到的关卡数量偏少，我们继续核对资源清单，发现还有官方动态资源。把这些资源批量整理导入之后，地图覆盖范围才完整起来。这里最容易误判的是：包内看到多少，就以为整个游戏只有多少。

在这次项目当时取得的清单中，我们整理出 3094 条地图配置：主线组 1521 条、另一配置组 1491 条、每日组 82 条。它们不等同于 3094 个顺序主线关卡；主线组还包含编号 0 的教程。

同样，模型文件的数量也不等于关卡数。多个关卡可以复用一个模型，不同分包还可能包含同名模型的不同版本。因此，加载时要沿着配置引用找到具体版本，不能只按文件名挑一个“看着一样”的资源。

批处理的价值就在这里。我们让脚本整理资源索引、校验缺失项、合并重复预览图，再把检查结果交给 AI 分析。最终保留 1616 个模型版本，预览图去重后为 2843 张。

批量导入之后启动为什么变慢了

资源齐全了，启动却变卡。排查后发现，大量模型和预览对象被启动注册表直接引用，首屏承担了太多加载工作。我们改为启动先读索引，进入关卡时异步载入当前模型和有限的预览，并恢复原来的 loading 流程。

图 10 项目历史构建对比具体秒数受设备和文件缓存影响

同一普通启动截图并退出口径，从 24.44 秒降到 7.29 秒，缩短约 70%。这包含原动画和验收等待，且未清空系统文件缓存。经验是：资源“拥有多少”和启动“加载多少”，要分开设计。

商店像了为什么按钮和数据还是错的

商店是一个很典型的案例：界面能打开，图片也齐全，但关卡商店关不掉，拖动到边界没有回弹，商品数量也令人怀疑。我们没有先调整图片，而是沿着“入口—显示—数据—关闭”逐段追查。

结果发现，关闭按钮的监听没有接上，商品填充的部分方法仍为空。屏幕里显示的是预制体自带的示例值，和真正按玩家状态筛选出来的商品是两回事。

图 11 恢复后的商店礼包和金币包来自官方配置

我们从 85 条商品目录里按类型筛选，接回 5 档礼包、6 档金币包和优惠展示，数量、标题、价格、折扣标签逐项核对。免费金币也恢复了 5 枚领取与 8 小时冷却，防止重复点击重复发放。

回弹则是另一种情况：两处商店原序列化的滚动方式都是边界夹紧。按这次体验反馈，我们将商店共用组件调整为弹性回弹，并保留原弹性和惯性参数。这属于明确的体验调整，记录时要和“恢复原逻辑”区分开。

这给我们的提醒很直接：UI 验收要检查“数据来自哪里、点下去发生什么”。商品展示正确，也不代表真实支付、收据和订阅权益已接通；本阶段完成的是展示与相关交互。

一个空盒子的方向暴露了动画恢复的难点

最有代表性的一次反馈是：盒子装满以后，旧盒怎么走，新空盒又从哪里来？如果只凭印象，向上向下都能写出一段顺畅动画，却可能和原版体验完全不同。

我们核对原方法后确认：满盒先合盖、轻微下压，再向上飞走；在上方隐藏 0.05 秒并刷新，新空盒从上往下落回同一个槽位。其他盒子保持原位。

图 12 App 实际换盒过程截取顶部区域便于观察固定槽位

当前实现曾额外把新盒放到下方，导致进场方向相反。修复时，我们删除这一步，恢复原来的刷新时机和坐标变化，还把收集计数接回合盖落定时增加 3 的事件。

更关键的是动画背后的状态：新盒下降期间先锁定接收，落定后再把暂存孔里同色的螺丝补进来。若又凑满三个，就继续下一轮换盒；没有下一颜色时，槽位隐藏。

因此，验收也要看完整过程。我们逐帧记录了位置、隐藏时间和状态，覆盖 12 次换盒；原槽位保持不变，进入方向正确，暂存自动补入与计数同步都通过。合盖到换盒落定位约 0.983 秒，符合核对到的原时序。

对动画而言，“从哪到哪”只是第一层。什么时候刷新数据、什么时候开放操作、什么时候触发后续动作，同样决定手感。

特效也需要在目标平台里看

原平台的资源迁到桌面后，遮罩和透明混合也会出问题。项目里出现过订阅卡缺失遮罩 Shader 的情况。我们保留原组件和层级，补齐对应依赖，再在真实 App 中检查；单看资源文件，很难发现这类运行时缺失。

AI 能把工作做快验收要把结果做实

这次项目里，AI 最有帮助的地方，是把海量重复工作变成一套可执行的流程：读项目、查引用、整理配置、编写转换脚本、定位空方法、组织运行用例，再根据日志和截图继续修正。

我们保留人工判断的环节也很明确：目标范围怎么定、证据是否充分、体验是否一致，以及哪些问题还没完成。尤其是界面看起来已经很好时，更要追问数据与状态是否真实。

我们实际采用的验收方法

先编译同一个 App，再执行固定操作。每个用例记录输入参数、退出状态、数据变化和游戏内截图。改收集盒，就检查连续收集、最后一盒和自动补入；改商店，就检查打开、关闭、拖动、重开和领取冷却。

检查过专项之后，再回归相邻流程。本轮换盒修复最终通过 4 组专项、15 项基础流程和 4 种技能检查。此前全量资源扫描还覆盖了 3094 条地图的加载、按压与恢复，以及 230 个效果材质的 GPU 对照。

这些数字各有范围：地图扫描不等于逐关通关，材质检查也不等于所有粒子触发时序都已还原。每份报告都要说明测试了什么，避免用一个漂亮的通过率替代完整结论。

给准备动手的团队五条建议

• 先做三个验收界面，尽早跑通一个可玩的闭环。

• 保留原资源和配置引用，把缺失实现与体验调整分开记录。

• 把 AI 任务写成具体输入、明确改动和可观察结果。

• 重复工作写脚本，关键状态留日志，视觉问题看真实 App。

• 保留每次验收的构建来源，修完一处就回归相关流程。

回头看，这个项目最值得分享的，并不是 AI 一次写了多少代码，而是我们逐渐建立了一个能反复核对的工作方式：遇到差异，找到证据；恢复实现，实际运行；看到结果，再修正判断。

AI 时代，这套方法让小团队更有机会处理复杂项目。真正值得积累的，是资源、规则和验证之间的连接。下一个项目可以换玩法，这条工作链仍然能继续使用。

案例说明文中数字来自本项目截至 2026 年 10 月的阶段性记录；配图为项目 App 内截图及据记录绘制的示意图。商业发布与素材使用应另行核对相应权利和发布条件。