最近一段时间，使用 AI 工具连续开发了两个任务：一个是把 Cocos Creator 2.x 老项目里的 JS 代码升级成 TS，另一个是给 Cocos Creator 3.x开发的小游戏接入微信官方的擂台赛组件。
这两个任务做完后，最大的感受是：以前我们讨论 AI 编程，更多是在讨论“哪个模型更强”。但真正到项目里落地后发现，模型固然重要，但工具链可能更重要。同样一个模型，放在不同的 Agent 或 IDE 里，表现可能差很多。
一、先说 Cocos 2.x 老项目 JS 升 TS
这个项目原来是 Cocos Creator 2.x + JS。JS 代码当然能跑，但维护久了后问题比较明显：类型不明确，很多对象点进去看半天才知道结构；组件之间的调用关系不够直观；老代码里动态字段很多，阅读成本比较高。所以我决定把这个项目从 JS 升级到 TS。
一开始，我是在 Trae IDE 里使用 miniMax-M3 来做。miniMax-M3 模型本身一直在用，写一些局部代码、解释逻辑、改小问题，整体感觉还可以。但这次做 JS 升 TS 这种批量工程改造时，就暴露出不少问题。
第一个问题是文件名修改。
比如：我让它把 a.js 改成 a.ts，Trae 默认的操作方式是：先删除 a.js，然后新增一个 a.ts，再把 JS 代码改成 TS 代码。
普通项目这么做没问题，但 Cocos 项目里不是这样。因为 Cocos 的脚本文件可能已经和某个组件绑定了，如果直接删除旧的 JS 文件，再新增一个 TS 文件，就会导致组件绑定丢失，出现脚本引用报错，最后还得手工重新拖脚本。
后面我只能让 Trae 专门把这个操作做成一个 skill，要求它不要用“删除再新增”的方式处理文件迁移，这个问题才算解决。
第二个问题是模块引用修改不完整。
JS 文件和 TS 文件的引用方式有差异，迁移时很多地方都要一起改。实际使用中，我发现 Trae 经常会出现“已经修改完了，但一运行还有模块漏改”的情况。结果就是它改完了，我提心吊胆地运行项目，看到报错，再手工或让它继续修。
甚至，出现了好几次 JS 文件中的函数丢失，没有迁移到新 TS 文件的情况，直到运行后报错才发现。
第三个问题是上下文很快就满了。
JS 升 TS 不是一个单文件任务，而是一批类似文件的持续迁移。前面迁移中出现的问题，后面最好能一直记住。但在 Trae 里，一个会话的上下文很快就满了，同类任务不得不新开一个会话，新会话又要重新交代规则。
二、换成 Claude Code 后，体验明显提升
后来我改用 Claude Code + ccswitch + miniMax-M3 来继续做 JS 升 TS 的工作。
需要说明的是，底层模型还是 miniMax-M3，并没有换成 Claude 模型。但实际体验明显好了很多，甚至可以说像脱胎换骨。
最直接的感受是：它更像是在“做一个工程任务”，而不是在“回答一个代码问题”。Claude Code 会天然先制定计划，然后按模块推进。它每修完一个模块就停下来，等我测试确认没问题后，再提交到仓库，然后继续下一个模块。对老项目迁移来说，节奏稳点很重要。如果 AI 一口气改完几十个文件，出了问题很难定位；按模块推进，每一步都能测试确认，风险就小很多。
更关键的是，用 Claude Code + miniMax-M3 做迁移时，我没有遇到一次前面那种“说改完了，其实漏改”的情况。在我这次任务里，它对引用关系、文件迁移、上下文规则的保持都明显更稳定，绝大多数模块都是一次性修改通过。
这就引出一个问题：模型同样是 miniMax-M3，为什么在 Claude Code 里表现比在 Trae IDE 里好这么多？
我觉得原因不在于模型突然变聪明了，而在于两套工具使用模型的方式不一样。
首先是上下文组织能力不同。AI 编程不是简单把当前文件丢给模型，然后让模型猜。真正复杂的工程任务，需要工具主动帮模型理解项目结构：这个文件被谁引用，这个组件挂在哪里，同类文件之前怎么改，项目里已有的封装方式是什么。如果只给当前文件和少量片段，模型很容易局部正确、全局出错。
其次是执行循环不同。普通 IDE 里的 AI 很多时候像聊天窗口，用户问，它答；用户让改，它改一段。Claude Code 更像一个能持续工作的 Agent，它的流程更接近：
理解任务 -> 搜索代码 -> 修改文件 -> 运行检查 -> 看到错误 -> 继续修复这种闭环对代码迁移特别重要。迁移任务不是一次生成就结束，而是要不断根据项目反馈修正。所以我现在的看法是：主流大模型本身都有不错的代码能力，但工具链会极大影响它的发挥。
三、Codex + GPT 5.5 接入微信小游戏擂台赛
另一件事情，是给一个 Cocos Creator 3.x开发的小游戏接入微信官方的擂台赛玩法。
这个任务比 JS 升 TS 更复杂一些。它不只是前端调用一个 API，而是前后端都要改。首先，游戏后端需要接入微信消息推送和道具礼包发货的能力。然后，前端接入擂台赛相关 API，提供玩家进入擂台赛、发起挑战、查询排名、处理奖励等能力。
这个我是用 Codex + GPT 5.5 来做的。做法很简单：把微信官方的文档链接发给 Codex，然后告诉它项目里前端发起擂台赛的入口在哪里，以及后端工程的代码目录。接下来前后端代码基本都是它写的，我主要负责 review 和测试。
执行过程非常省心，前后端代码全都是一次性通过，而且很多细节考虑的很全面，对 Cocos 前端代码的理解能力也超出我预期。举两个具体例子。
第一个例子是 wx.getRankManager() 的类型声明。
前端接入微信官方的擂台赛时，需要调用微信平台提供的 wx.getRankManager() 方法。逻辑本身不复杂，如果只是从功能角度看，直接写：
wx.getRankManager()似乎也没问题。但在实际 Cocos + TypeScript 项目里，如果类型声明文件里没有这个方法，编辑器就会飘红。代码能跑，但开发体验不好。
Trae 默认情况下会直接帮你写 wx.getRankManager()。从运行逻辑上说没错，但它没有顺手解决类型声明问题。Codex 的处理就比较贴心。它会先找到项目里的类型声明文件 define.d.ts，把 getRankManager 的类型声明补上，然后再写真正的业务逻辑代码。
这就是AI所谓的“工程感”。它不是只把当前功能跑通，而是知道类型声明也是工程质量的一部分。
第二个例子是平台API封装。
原来的项目里，平台相关调用基本都封装在 PlatformMgr 类中，业务逻辑不直接依赖具体平台，这样如果要适配其他平台，改动范围会小很多。
还是同样的 wx.getRankManager() 调用。Trae 默认情况下直接在逻辑代码里调用 wx.getRankManager()。这样功能也能实现，但破坏了项目原来的平台隔离方式。
而 Codex 在没有特别强调的情况下，自动把 wx.getRankManager() 封装到了 PlatformMgr 里，然后业务逻辑再通过 PlatformMgr 去调用。
这个细节让我印象很深刻。因为它说明 Codex 不只是看懂了“我要调用微信 API”，还看懂了“这个项目原本是怎么组织平台代码的”。代码本身很简单，也没有什么技术含量，但这种判断能力，才是复杂编程任务里真正拉开差距的地方。
四、Codex + GPT 5.5 强在哪里？
Codex + GPT 5.5 的体验好，是 Agent 工具链和底层模型能力叠加的结果。如果非要分主次，我倾向于认为：GPT 的底座能力决定上限，Codex 的工程化能力决定落地稳定性。
复杂编程任务最难的不是写几行代码，而是持续理解一个工程。比如接入微信小游戏的擂台赛组件，模型要同时理解微信官方文档、后端消息推送、道具礼包发货、前端入口、平台 API 封装、TypeScript 类型声明，以及现有项目的架构约束。
模型必须有较强的工程理解能力，才能判断“代码应该写在哪里”，而不是只判断“这段代码怎么写”。这也是我觉得 GPT 在复杂编程任务上仍然领先国产大模型的地方，GPT 的综合判断能力还是更稳。
当然，Codex 本身也很关键。如果只是把 GPT 放在普通聊天窗口里，然后手工贴代码、复制代码、运行报错、再把错误贴回去，那体验肯定不会这么好。Codex 的价值在于它能直接进入项目工作：读文件、搜引用、改多个文件、运行命令、看错误、继续修。
所以更准确地说：
GPT 负责想明白怎么改
Codex 负责把修改稳定落到真实项目里五、Claude Code 和 Codex 有什么区别？
从大类上说，Claude Code 和 Codex 都属于 AI 编程 Agent。
它们都不是传统意义上的编码辅助工具，而是可以围绕一个目标持续工作的工程助手。它们都会读项目、搜代码、改文件、运行命令、根据错误继续修复。但两个工具的气质不太一样。
Claude Code 给我的感觉更像一个贴身的终端开发助手。它交互轻，节奏快，很适合老项目迁移、批量重构、修编译错误、解读历史代码。
Codex 给我的感觉更像一个工程化程度更高的代码执行系统。它对任务边界、改动范围、验证闭环、代码 review 的意识更强。做完整功能，尤其是前后端联动、平台接入、需要读文档并落地到项目架构里的任务时，Codex + GPT 的组合非常稳。
如果简单分类，我会这么看：
日常改代码、迁移、重构：Claude Code 很顺手
复杂功能、前后端联动、一次性落地：Codex + GPT 更稳两个任务刚好给了一个很直观的对比：
Claude Code + miniMax-M3：证明好的 Agent 框架可以明显放大模型能力
Codex + GPT 5.5：证明强模型加工程化 Agent，在复杂任务上成功率很高所以评价 AI 编程工具，不能只看模型名字。还要看它怎么组织上下文，怎么拆任务，怎么修改文件，怎么验证结果，怎么减少返工。
六、总结
之前，Cursor 和 Trae 是我的主力开发工具，感觉要指定具体的代码，看着 AI 修改才踏实。但现在，Claude Code 和 Codex 变成了我的主力开发工具，IDE 只是作为代码的阅读和少数情况下的编辑器。
当然，并不是说 AI 已经可以完全替代程序员。人还是要做 review，要测试，要判断架构是否合理，性能是否需优化，要决定哪些改动可以接受，哪些地方需要回滚或调整。具体到游戏开发领域来说，很多的UI和动画编辑工作，目前还是需要人工完成。
但程序员的工作方式确实在变化：AI 负责大部分重复性和工程性实现，人负责设定目标、提供上下文、验证结果、把控方向。
七、交流
- 微信公众号：楚游香
- 个人网站：https://www.chuyouxiang.com/
我的公众号和博客会不定期更新 AI 研发、游戏开发技巧和上线实战经验，欢迎常来逛逛，一起交流。