我的实战分享 · 所有截图和记录都是真的

我让 Claude Code 和 Codex 搭伙,
一起开发了我的 iOS 游戏

没用任何多 agent 框架,也没写一行胶水代码。一个 git 仓库、三份 Markdown 文件,就让两家的 AI 一个当工程师、一个当美工,五天干完两轮 UI 改版。这篇把我的真实文件、真实截图、踩过的坑全部摊开,你可以直接抄。

项目:Star Pairs(iOS 记忆翻牌游戏,SpriteKit + Swift)· 2026 年 6–7 月
01

📱 先看效果,再讲怎么干的

左边是 Claude Code 独立开发时期的主菜单,右边是 Codex 接手做完整体改版后的样子。中间隔了 5 天,我自己没写一行 Swift:

改版前的主菜单:扁平狐狸头、绿色 Play 按钮、简单森林背景
改版前(Claude 独立开发期)
改版后的主菜单:毛绒狐狸、奶油面板、糖果色按钮、散落的记忆卡片
改版后(Codex 做的软糖森林风)
右图就是 Codex 自检时留下的截图(仓库里的 design/starpairs-ui-check-menu.png),不是我摆拍的。毛绒狐狸、奶油面板、糖果色按钮、散落的卡片,整套都是它改的。

游戏里 18 张卡面,也全部被 Codex 重画成了和狐狸图标一个风格的毛绒质感:

18 张毛绒风卡面:狐狸、兔子、刺猬、猫头鹰、青蛙、蜜蜂、蝴蝶等森林生物
重画归重画,文件名、张数、顺序一个都不许动——这是我在任务里写死的规矩,不然玩法映射就乱了。
68
整个项目的 commit 总数
41 : 27
Claude 和 Codex 各自的提交
5 天
Codex 干完两轮 UI 任务
0 次
两个 AI 之间的代码冲突

这些数字不是我拍脑袋的——两个 AI 的提交格式不一样(后面会讲),打开 git log 数一遍就是这个数。

02

🤔 我为什么要拉第二个 AI 入伙

这个游戏从 0 到上架 TestFlight,是 Claude Code 一个人干的:27 天,从可玩原型一路做到内购、广告、100 关、成就系统,测试版发到了 build 7。这个阶段我基本只做两件事:确认方向、试玩提意见。

但上线之后我发现,剩下的活儿性质变了。不再是「加功能」,而是没完没了的调 UI:道具图标三个地方大小不一致、商店行距太挤、开屏动画节奏不对、配色想整个换掉……这种活有三个特点:

我不想让 Claude Code 陷在这种活里——它手上还有测试、构建、上架这些正经工程活。所以我的想法很直接:再雇一个 AI 专门当美工。选了 OpenAI 的 Codex,它跟 Claude Code 一样是命令行里的编码 AI,会自己改代码、跑命令、提交 git。

💡 一个前提条件,先自查
我这个游戏的 UI 全部是代码画出来的(SpriteKit,没有拖拽式的可视化界面),所以"改 UI"就等于"改 Swift 代码"——这正好是编码 AI 干得了的活。如果你的项目 UI 靠拖拽编辑器,这套打法要先打个问号。

顺便把几个名词交代了,熟悉的直接跳过:Claude Code 是 Anthropic 家的编码 AI,Codex 是 OpenAI 家的,都在终端里干活;TestFlight 是苹果的测试版分发渠道;fastlane 是 iOS 的发布工具,一条命令就能把包传上去——正因为它威力大,后面你会看到我把它设成了 Codex 的绝对禁区。

03

✂️ 分工思路,一句话:Claude 管"对不对",Codex 管"好不好看"

拉第二个 AI 进项目,我最担心的就是俩 AI 互相踩:你改我的文件、我覆盖你的提交。所以动手之前,我先把地盘划死了。划分的标准不是"哪些是 UI 文件",而是问一个问题:

🎯 划界的唯一标准
这块代码改坏了,是"变丑"还是"变错"? 改坏了顶多丑的(布局、配色、动画、素材),归 Codex,随便折腾;改坏了会出 bug 的(游戏逻辑、计分、经济、测试、发布配置),Codex 一根手指都不许碰。
✅ Codex 随便折腾区 📁 Scenes/ — 各场景的布局排版动画 📁 Rendering/ — 卡面卡背怎么画、粒子 📁 Resources/ 和 design/ — 图片素材 📄 GameConfig.swift 的"半个文件" 只许动配色和外观参数(圆角、间距、动画时长) 共同点:改坏了顶多丑,游戏不会坏 ⛔ 碰了就出事区 📁 Engine/ — 游戏逻辑核心 📁 Tests/ — 测试(归 Claude 维护) 📄 GameConfig.swift 的另外半个 计分、金币、价格、难度这些玩法数值 📄 构建和发布配置(fastlane 等) 🚫 以及:绝不许执行任何上传命令
我最得意的一笔是把 GameConfig.swift 一个文件切成两半:配色和外观参数归 Codex,玩法数值归 Claude。地盘不是按文件划的,是按"改坏了的后果"划的。

划完地盘,两个 AI 的角色就清楚了:

🔧 Claude Code(工程师)🎨 Codex(美工)
干什么游戏逻辑、测试、构建、传 TestFlight布局、间距、配色、动画、重画素材
守什么规矩CLAUDE.md(它家 AI 进仓库自动读这个)AGENTS.md(它家 AI 进仓库自动读这个)
验收标准101 项测试全过才许上传能编译 + 截图看一眼不炸就行
发布权限有,但每次都要等我说 go没有,想都别想
04

📝 实操第一步:给 Codex 写一份"入职须知"

这里有个很多人不知道的点:这两家的 AI 进仓库时,都会自动读一份约定好名字的说明文件——Claude Code 读 CLAUDE.md,Codex 读 AGENTS.md。所以规矩不用每次开对话重复交代,写一次放在仓库根目录,它每次进来都守。

更省事的是,这份给 Codex 的入职须知,我是让 Claude Code 替我写的。我只说了大概意思——"你把 UI 打磨的活整理出来交给 Codex,把它该守的规矩写清楚"——它就生成了 AGENTS.md 和任务清单,这个提交现在还在 git 里:

# 协作模式的起点,git 里查得到
f010bec  docs: add Codex UI-collaboration scaffold (AGENTS.md + UI-TASKS.md)

AGENTS.md 开头第一段就把话说死了,我原文贴给你:

「本文件是给 Codex 的工作说明。逻辑、构建流程、上线由 Claude Code 负责(见 CLAUDE.md);你(Codex)只负责 UI / 视觉打磨。两个 agent 通过 git + UI-TASKS.md 串行交接,同一时间只有一个 agent 在改代码——你接手时,Claude 已经 commit 完毕。」
—— 我仓库里 AGENTS.md 的开篇原文

整份文件不长,就五块内容。我的心得是:写给 AI 的规矩,要像写给一个第一天入职的外包——说人话、给现成命令、给明确的判断标准:

  1. 项目一句话是个什么游戏、什么技术栈、UI 是代码画的。三行讲完,别让它猜。
  2. 你能碰哪些(白名单)就是上一节那个"随便折腾区",精确到目录和文件段落。
  3. 你绝对不能碰哪些(黑名单)逻辑、测试、玩法数值、发布配置。最后加一句死命令:"绝不执行 fastlane beta / release"——发布这种事永远不能让美工顺手干了。
  4. 改完怎么自检直接把命令贴给它:跑 xcodebuild,看到 BUILD SUCCEEDED 才算过;再装进模拟器截个图,确认没黑屏没丢素材。连"截图前先杀掉模拟器里另一个会抢前台的 app"这种坑我都写进去了(这个坑后面细说)。
  5. 怎么交作业去任务清单里挑活、做完打勾、commit 用统一格式、拿不准的别自作主张。下一节展开。
05

📋 实操第二步:开一张工单文件,所有活都走它

两个 AI 之间怎么传需求?我的答案土得掉渣:仓库里放一个 UI-TASKS.md,当工单用。Claude 往里写任务,Codex 从里面领活,规矩就三条:

贴一条真实的任务,你感受一下这个格式。红色那行 ❗ 是我特意划的红线,防止它调排版时顺手把价格也"优化"了:

## 第 1 批(2026-07-09 交接)

- ☑ 商店行距体检(ShopScene.swift):每行 y -= 50,section 之间 y -= 8。
  在 iPhone 17 上截图看,行与行的呼吸感是否合适;必要时微调,
  让「Power-ups / Get coins / More」三块视觉分组更清楚。
  - ❗ 不要改任何价格、金币数、道具数值——只动排版。
  - 改动: GameConfig.swift 增加商店排版节奏常量; ShopScene.swift
    行步进调为 52、section 上方间距调为 18,强化分组。 ← Codex 交的作业

有一条任务的结果我印象很深:我让它检查深色模式下有没有文字看不清,它查完回了一句"扫描了相关代码,没发现问题,不需要改"——然后照样提交了一个 commit 把这个结论记录在案。"查了没问题"也是工作成果,这个习惯比很多人类外包强。

✍️ 我的心得:验收标准比任务描述值钱
对比一下就明白了。写"把道具图标弄统一",它可能给你统一出一个新丑法;写"目前商店里的图标是 32×32 圆角 9,以这个为基准,把另外两处对齐,验收:三处看上去像同一套组件"——它就没有发挥空间。给基准、给数值、给"怎么算好了",返工率直线下降。
06

🔄 实操第三步:轮流上场,git 当交接台

俩 AI 怎么协调?我压根没让它们"对话"。规矩简单到有点无聊:同一时间,只有一个 AI 在改代码。Claude 把任务清单 commit 进仓库后退场,Codex 才进场;Codex 干完全部 commit,Claude 再回来。git 仓库就是交接台,提交记录就是交接单。

① Claude 写好工单 任务 + 验收标准,commit 后退场 ② Codex 进场领活 挑 ☐ 的做,只碰自己的地盘 ③ 自检两件事 编译通过 + 截图不炸 ④ 打勾交作业 ☑ + 改动记录 + ui: 开头的 commit ⑤ Claude 回场跑全测 101 项测试,把质量关 ⑥ 我上手玩,提意见 满意收工;不满意变新任务 蓝色 = Claude · 绿色 = Codex · 紫色 = 我 全程没有任何"多 agent 框架",就是 git + Markdown
整个循环转起来之后,我的参与就剩两件事:⑥ 里提意见,以及偶尔在 ❓ 上拍板。

提交格式:让 git log 自己会说话

还有一个小设计我特别推荐:给两个 AI 定不同的提交格式。Codex 的提交一律 ui: 开头、不带署名;Claude 的提交带里程碑前缀和它的署名尾注。这样翻 git log,谁干的一目了然,出了问题也知道找谁:

# 我仓库 git log 的真实片段 ——

Codex 的提交(ui: 开头,没有署名):
038b5f3  ui: replace green card backs
8e6c9a4  ui: enlarge candy card backs
81ff315  ui: apply soft candy palette

Claude 的提交(里程碑开头,带署名尾注):
1716691  M13: TestFlight build 7 uploaded — sync build number to 7
         ...
         Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

文章开头那个"41 : 27"就是这么数出来的。不用装任何审计工具,提交格式定好了,git log 本身就是审计日志。

07

✅ 验收怎么分:美工别跑测试,测试全归工程师

这一条是我整套打法里最"反直觉"的设计:我明确规定 Codex 不许跑测试。它的自检就两件事——编译能过、截图不炸,完事。全套 101 项测试(98 个单元测试 + 3 个 UI 测试),由 Claude 在合并回来之后统一跑一遍。

为什么这么设计?你想想 UI 打磨是什么节奏:改 4 行间距,提交;换 6 个色值,提交。如果每次小改都要跑十几分钟的全套测试,美工的迭代速度就死了。而它的地盘本来就是"改坏了顶多丑"的安全区,测试极难被它改挂。所以:

🚦 我的验收原则
让快车道轻装快跑,把重型关卡设在汇合口。 Codex 改十次,Claude 汇总跑一次全测;上传 TestFlight 之前必须 101 项全绿,而且还得等我亲口说 go。质量一点没松,速度提了一大截。

实际跑下来,Codex 交付第二批的收尾记录就是按这个标准来的:构建成功 + 一张模拟器截图(就是文章开头那张新菜单)。测试的事它提都没提——因为规矩里写了那不是它的活。

08

🍬 一次完整实战:整体改版是怎么跑下来的

第一批任务是 7 条小打磨(统一图标、调行距、修动画节奏这类),Codex 从下午 5 点半干到晚上 9 点半,7 条任务 7 个 commit,当天清完。我一看,活儿干得不错,胃口就大了:干脆整体改版吧——把整个游戏从原来的"清新森林风"改成更软更萌的"软糖森林风"。

大改版跟小打磨不一样,不能直接开干。我们(我 + 两个 AI)走了一条完整的流程:

  1. 先出几版"样板间"让我挑动手改代码之前,先做了好几版视觉方向的网页预览稿(这些 HTML 现在还留在仓库里)。我看图说话,拍板选了软糖森林 + 毛绒狐狸头图标。
  2. 把定稿写成文档,色值全部写死选定方向后落成一份定稿文档:整套配色精确到十六进制(奶白青 #BDECEF、暖橘 #F39A35、莓粉 #F58AB5……),外加一条硬规矩:18 张卡面可以重画,但文件名、张数、顺序一个不许动——换皮不换骨。
  3. 拆成 7 个任务,每个任务干完必须编译 + 提交改版被拆成:配色 → 图标和徽章 → 卡面卡背 → 开屏和菜单 → 对局界面 → 商店结算设置 → 最终截图验收。每个任务的最后一步固定是"跑构建、更新工单、commit"。所以 git 里留下了 20 个粒度均匀的提交,哪步出问题都能精确回滚。
  4. 我上真机看效果,不满意就返工改版"完成"不等于结束。我上手玩了几把,嫌卡背图案太小、后来又嫌绿色卡背不好看——这些意见变成"追加修复"任务,又多了好几个 commit。下面这两个提交名,就是我逼它返工的证据:ui: enlarge candy card backs、ui: replace green card backs。

放一张改版前的对局画面,你对比开头那张新菜单,感受一下这次改版的跨度:

改版前的对局画面:纯绿色卡背配白色叶子图案,橙色道具栏
改版前的对局(绿底叶子卡背)
改版后的主菜单,毛绒狐狸和糖果色按钮
改版后的门面(同一个游戏)
左图这种卡背,就是后来被我连环打回的对象——卡背这一个元素前后改了三轮才过我这关。审美验收这事,AI 替代不了你。
🔑 插一个我"打脸 AI"的故事
其实在拉 Codex 入伙之前,Claude 就用 AI 设计过一版新 App 图标,做完也提交了。我看了一眼:不行,原来那个扁平金星更好看。它二话不说无损回退,新图标源文件留档了事。这件事让我定了一条心法:方向和审美的决定权永远在我手里,AI 做得再顺手也一样。后来给 Codex 的规矩里那条"拿不准的写 ❓ 别自作主张",就是这么来的。

还有一个细节值得说:App 图标平时在 Codex 的禁区里(它属于发布资产)。这次改版要重做图标,我没有口头说"这次可以",而是让这个授权白纸黑字写进工单:"用户确认:整体 logo 包含 App Icon,本批明确允许修改"。跟 AI 协作,例外情况尤其要落在文件上——它们不长记性,你说过的话下次进来就忘了,写下来的才算数。

09

🕳️ 我踩过的坑,你可以绕着走

坑一:模拟器"串台",截图截到别的 app

这是最哭笑不得的一个。同一个 iPhone 模拟器上装着我另一个 app(一个阅读类的),它的测试进程会不定时把自己拉到前台。结果就是:AI 截图自检时,截到的是我的阅读 app 而不是游戏;UI 测试还会偶发性失败,因为断言"游戏在前台"的瞬间恰好被抢了。排查了半天才确认不是游戏的 bug。

解决办法很糙但有效——截图前先把那个 app 杀掉:

xcrun simctl terminate booted com.mingyuyang.suiread   # 先杀掉抢前台的家伙
xcrun simctl launch booted com.mingyu.starpairs         # 再启动游戏、截图

重点不是这条命令,而是接下来这个动作:我把这个坑连同命令一起写进了给 Codex 的入职须知。效果是 Codex 从第一天起一次都没踩过这个坑。跟 AI 协作,环境里的坑不写下来,每个新进场的 AI 都会原地摔一遍。

坑二:别指望"两个 AI = 快一倍"

轮流上场的模式下,同一时间只有一条车道在动,总速度并不会翻倍。这套打法换来的是分工专业化 + 零冲突:五天两轮改版,俩 AI 没有发生过一次代码冲突。要并行提速,得上更复杂的分支策略,我权衡之后觉得不值——调 UI 这种活,顺序干反而省心。

坑三:规矩是"软"的,要有兜底

说实话,AGENTS.md 拦不住一个不守规矩的 AI——它就是一份 Markdown,没有任何强制力。我的兜底是三层:地盘划清(它没理由碰红区)、git 随时可回滚(真改坏了一条命令撤销)、发布权限物理隔离(上传命令只有 Claude 有,而且要等我说 go)。实际跑下来 Codex 全程守规矩,但兜底不能省。

坑四:"好不好看"永远自动化不了

AI 能自检"编译过、画面不炸",但它检不出"丑"。卡背改三轮、图标被我打回,都是我亲眼看真机才发现的。所以流程里必须给自己留一个雷打不动的环节:每轮改完,我上真机玩一遍。这十分钟省不得。

10

📦 想抄作业的,按这个清单来

把我的做法浓缩成 8 步,任何项目都能照着搭:

  1. 先让主力 AI 把项目带到"能分工"的状态核心逻辑稳定、测试齐全、一条命令能构建。双 AI 是打磨期的放大器,别从第一天就双开。
  2. 划地盘,标准只有一个问"改坏了是丑还是错"。只把"顶多丑"的区域给第二个 AI,必要时精确到一个文件的某几段。
  3. 写两份规矩文件,放仓库根目录CLAUDE.md 给 Claude Code,AGENTS.md 给 Codex,各家 AI 进门自动读自家的。第二个 AI 的那份要有:项目一句话、白名单、黑名单、自检命令、交作业格式。可以让主力 AI 代笔,你审核。
  4. 开一个 TASKS.md 当工单每条任务带验收标准,红线用 ❗ 就地标注;做完打勾 + 写改动记录;拿不准写 ❓ 等你拍板。
  5. 定提交格式,让 git log 会说话给副手一个专属前缀(比如 ui:),主力保留署名尾注。谁干的、干了多少,git log 一目了然。
  6. 轮流上场,不许同时改代码牺牲一点并行度,换来零冲突,值。
  7. 验收分两级副手只管"编译过 + 截图不炸";全套测试和发布,收口到主力 AI,发布必须等你确认。
  8. 环境坑写进文件,例外授权也写进文件AI 不长记性,口头说的都会忘,写下来的才算数。

🏁 最后说两句

这次实验对我最大的启发是:让两家的 AI 合作,根本不需要什么高大上的基础设施。git 是现成的交接台,Markdown 是现成的合同和工单,提交格式是现成的审计日志——缺的从来不是工具,是把规矩想清楚、写清楚的那半天功夫。说到底,这套东西就是人类工程团队用了几十年的老办法:划清职责、书面交接、验收分级、关键决定留给人。只不过这一次,读文档和守规矩的,是两个 AI。