大家好，最近我用 Cocos Creator 3.8.8 做了一款竖屏箭头解谜小游戏——《今天你箭了吗？》。这个项目比较特别的地方，是从原型、玩法规则、编辑工具到小游戏适配，整个过程中我都在和 Codex 协作。
先说结论：Codex 并不是输入一句话就能“吐出一款完整游戏”的按钮。它更像一个能进入仓库、阅读上下文、改代码、运行测试并继续排错的结对开发者。真正有效的方式，是我来确定产品方向、玩法手感和验收标准，让 Codex 负责快速实现、分析问题、补测试和整理工程，再通过 Cocos 编辑器、浏览器和真机反复验证。
这篇文章想分享的不是某一段提示词，而是这套协作方式如何落到一个真实的 Cocos 项目里，以及中间最费时间的几个技术难点。
一、这是一款什么游戏
《今天你箭了吗？》的核心规则很简单：画面里有一组方向各异、互相阻挡的箭头。玩家点击一个箭头，如果它前进的射线上没有其他箭头阻挡，它就能飞出棋盘；如果存在阻挡，就需要重新判断移除顺序。
规则看起来像一句话，但要把它做成“看得懂、点得准、不卡顿”的小游戏，背后会牵涉到：
-
折线箭头的绘制、碰撞与点击判定必须一致；
-
棋盘需要同时支持点击、拖动和双指缩放；
-
UI 要适配不同屏幕比例和安全区域；
-
资源不能全部挤进小游戏首包；
-
Web、微信小游戏及其他平台的登录、广告、分享、振动等能力不能写死在玩法代码里；
-
内容制作需要工具化，并在进入游戏前完成规则校验。
这些问题也构成了我和 Codex 协作的主要内容。
【配图建议】此处可放不包含关卡编号或玩家信息的游戏加载画面。
二、从想法到可运行原型：先把规则写成“可验证的代码”
项目刚开始时，我先把玩法、页面流程、竖屏尺寸和目标平台整理成需求。Codex 根据这些约束搭出了 Cocos Creator 工程骨架和第一版 TypeScript 逻辑。
我认为这一步最重要的不是“代码写得快”，而是尽早把玩法规则从场景脚本里拆出来。
项目中，Cocos 组件主要负责节点、动画、音效和输入；箭头能否离开、提示应选择哪个箭头等规则，则尽量写成不依赖引擎的纯函数。核心判断可以简化理解为：
function canExit(current, remaining, board) {
const ray = createRayFromArrowHead(current, board)
return remaining
.filter(item => item.id !== current.id)
.every(item => !rayIntersectsArrow(ray, item))
}
这样做带来了三个直接收益：
-
规则可以脱离 Cocos 场景单独测试；
-
编辑器、求解器和游戏端可以复用同一套数据含义；
-
后续调整渲染、缩放和 UI 时，不容易误伤玩法规则。
Codex 在这里很适合做“全仓库一致性检查”：当箭头格式发生变化时，它可以同时检查类型定义、游戏端判定、编辑器导入导出和测试，而不是只改到当前打开的文件。
三、技术难点一：箭头的“画出来、点到它、判断阻挡”必须是同一条线
这是项目里最容易出现体验问题的地方。
直线箭头比较简单，但折线箭头由多个点和线段组成。假如渲染使用一套坐标，碰撞使用另一套简化坐标，就会出现玩家肉眼看到没有挡住、程序却判断被挡住的情况。反过来，点击区域如果只用节点矩形，也会发生点到空白处却选中箭头，或者点中弯折处没有反应。
最后采用的原则是：路径数据是唯一事实来源。
-
渲染时，根据同一组路径点绘制箭身和箭头；
-
阻挡判断时，把其他箭头拆成线段，与箭头尖端发出的射线做相交检测；
-
点击时，计算触点到各段折线以及箭头三角形的距离；
-
飞出方向由最后一段路径决定，而不是只依赖一个预设的上下左右字段。
这里还有一个很现实的细节：数学上的“严格相交”并不等于手机上的“体验正确”。浮点误差、线宽和屏幕缩放都会影响结果，所以需要一个与视觉线宽匹配的容差，同时避免容差过大导致隔壁箭头被误判。
Codex 能快速补齐线段相交、点到线段距离、折线采样这些基础代码，但最终的容差和点击手感，仍然需要人在实际画面里反复试。AI 能帮我缩短计算过程，却不能替代手感验收。
四、技术难点二：点击、拖动、双指缩放之间会“抢手势”
棋盘较复杂时，玩家需要放大观察，也需要拖动画面。问题是：一次触摸刚开始时，系统并不知道玩家接下来是想点击箭头，还是想拖动棋盘；第二根手指加入后，状态又要立刻切换为缩放。
项目里把手势拆成了几个明确状态：
idle → pending → tap
├→ pan
└→ pinch
-
手指按下后先进入
pending，记录初始位置和候选箭头； -
移动超过阈值后才转为
pan，避免轻微手抖触发拖动； -
第二根手指加入后转为
pinch，根据双指距离变化计算缩放； -
手指抬起时，只有仍满足点击条件才执行箭头操作；
-
缩放后对棋盘位置做边界约束，避免内容被拖到屏幕外找不回来。
这一部分最初并不是一次完成的，而是经历了“能缩放但误触”“拖动顺了但点选变差”“画面居中了但不同屏幕比例偏移”等多轮修正。Codex 每次根据现象定位状态转换或坐标换算问题，再把可独立计算的部分提取出来补测试。相比只在一个巨大的触摸回调里不断加条件，状态机更容易继续维护。
五、技术难点三：Cocos UI 不只是改几张图片
这个项目的 UI 也经历过多轮调整。AI 可以生成背景和图标，也可以批量修改 Prefab，但 Cocos UI 真正难的是节点层级、锚点、Widget、字体、点击区域和安全区域要共同工作。
我在实践中总结出几个比较有用的做法：
1. 背景图和可交互 UI 分离
生成式图片只承担背景、装饰和氛围，不把按钮文字直接画死在图里。按钮、标题、弹窗和合规文案仍然保留为 Cocos 节点，方便多语言、适配和后续修改。
2. 页面控制器与 Prefab 解耦
主页、游戏页、设置、弹窗等分别由控制器管理，通过清晰的绑定入口连接 Prefab。这样替换一套视觉资源时，不需要重写完整业务流程。
3. 把安全区当运行时问题处理
全面屏设备、小游戏胶囊按钮和浏览器预览的可用区域并不相同。项目把安全区计算单独封装，在运行时调整顶部、底部和对话框布局，并为纯计算部分保留测试。
Codex 对批量、规则明确的 UI 修改效率很高，但当 Prefab 层级很深时，一次改动可能影响大量序列化内容。因此我会要求它每次只处理一个页面，完成后立刻预览和截图核对，而不是把所有页面一起重写。
六、技术难点四：小游戏包体、远程资源与版本更新
随着内容和美术资源增加，把所有东西都塞进首包并不现实。项目后来把可延后加载的内容放进独立 Asset Bundle，并采用“当前需要优先、其他内容后台分批”的策略。
加载流程大致是：
-
启动时只加载资源索引和当前需要的内容；
-
玩家主动进入某项内容时，直接加载拥有最高优先级；
-
邻近内容在后台小批量预加载；
-
每批之间主动让出执行时间，避免和游戏操作抢网络、抢主线程；
-
超时或失败时允许重试，但预加载失败不能阻塞玩家的直接请求。
真正踩坑的是：Web、小游戏和原生平台生成的 Bundle 引导文件并不完全一样，开启 MD5 Cache 后还要保证配置文件、脚本映射和资源 Hash 属于同一版本。只替换远端文件，却没有同步主包中记录的版本，很容易出现“服务器明明有文件，客户端仍请求旧 Hash”的情况。
为减少人工发布失误，Codex 帮我把构建准备、产物检查和资源暂存写成了脚本。发布前自动检查 Bundle 配置、版本入口和必要文件；发布资源时先在临时目录准备完整副本，校验后再切换。这里 AI 的价值不只是写业务代码，而是把一次次踩坑转成以后不会忘记的工程护栏。
七、技术难点五：同一套玩法如何适配多个平台
玩法代码如果到处出现 wx.*、浏览器 API 或原生桥接调用，后续增加平台会非常痛苦。项目因此抽象了一层 PlatformService，把登录、激励广告、插屏、分享、振动和数据上报等能力放到平台实现里。
Game / UI
↓
PlatformService
├─ Web
├─ WeChat Mini Game
├─ Douyin Mini Game
└─ Native Host
游戏逻辑只问“广告是否完整播放”“是否分享成功”“是否需要振动”，不关心底层是哪个 SDK。Web 预览可以提供安全的模拟实现，真机平台再接入真实能力。
这层抽象也是 Codex 比普通代码补全更有价值的地方：它能看到多个平台实现，修改接口时同步更新调用方，并通过类型检查找到漏改的位置。
八、Codex 在这个项目中真正承担了什么
回头看整个过程，Codex 主要承担了以下工作：
-
根据需求建立 Cocos Creator + TypeScript 的可运行骨架；
-
把玩法规则拆成纯函数，并补充自动测试；
-
实现折线路径、阻挡检测、点击命中和飞出动画；
-
迭代触摸、拖动、缩放和不同屏幕适配；
-
整理页面控制器、Prefab 和 UI 资源；
-
搭建独立的可视化内容编辑工具及校验流程；
-
抽象多平台能力，减少玩法层的平台判断；
-
编写资源构建、检查和发布辅助脚本；
-
通过浏览器预览、日志和截图持续做回归排查；
-
把最终结构、启动方式和容易踩坑的地方写成项目文档。
我负责的则是玩法方向、视觉选择、功能优先级、体验验收和最终发布决策。两者的边界越清楚，合作越顺。
九、我认为比较有效的 Codex 协作方式
1. 不要只说“帮我做个游戏”
把任务写成可验收的结果，例如：
棋盘支持双指缩放和单指拖动；轻微移动仍视为点击；缩放后不能把棋盘完全拖出可视区域；不要修改玩法判定。
这种描述同时给出了功能、边界和不能破坏的内容。
2. 一次解决一个可验证的问题
先修点击，再修缩放，再做安全区。每一步都预览、测试、截图。任务越具体，AI 越容易找到真正原因，也越容易发现回归。
3. 让 AI 运行项目，而不是只输出代码
我更看重 Codex 能不能完成“阅读现有实现 → 修改 → 编译/测试 → 看日志或画面 → 再修正”的闭环。只生成一段看起来正确的代码，离可上线还有很长距离。
4. 把反复出现的问题变成脚本和测试
只靠聊天记录记住发布步骤是不可靠的。凡是可以机械判断的内容，都尽量写进测试或构建校验。这样下一次换 UI、换资源或改平台接口时，项目会主动告诉我们哪里不一致。
5. AI 改 Prefab 后必须进编辑器检查
Prefab 是序列化资源，文本层面合法不代表视觉一定正确。节点引用、锚点、遮挡顺序、字体裁切和触摸区域，最终仍要以 Cocos 编辑器和真机效果为准。
十、最后推荐一下《今天你箭了吗？》
如果你喜欢不需要复杂教程、拿起来就能玩，但又需要观察和推理的轻量解谜游戏，可以试试《今天你箭了吗？》。它的规则很直观：找到没有被挡住的箭头，让它们依次离开；真正玩起来，则经常会遇到“看上去能走，仔细一看还差一步”的小陷阱。
开发这款游戏的过程，也让我第一次比较完整地体验了“人负责判断，AI 负责加速执行”的工作方式。Codex 没有替我做决定，但它把许多原本需要反复查文档、写样板代码和人工核对的工作压缩了下来，让我能把更多时间放在玩法和体验本身。
欢迎大家扫码体验，也欢迎 Cocos 开发者交流 Creator 3.8、小游戏资源更新、触摸手势以及 AI 辅助开发方面的经验。
微信扫码体验《今天你箭了吗？》
感谢阅读！