开源 Codex Skill：把游戏录屏还原成可运行的 iOS 游戏

这次又开源了一个新的 Codex Skill：video-to-ios-game。

它想解决的问题是：如果手里只有一段游戏录屏，能不能让 Codex 帮忙把它还原成一个可以运行的 iOS 游戏？

这里的「还原」不是把视频塞进 App 里播放，而是让 Codex 先理解视频里的玩法，再生成 SwiftUI 游戏代码和关卡配置，最后完成构建与测试。

一段视频，怎么变成一个游戏

这个 Skill 的完整流程是：

游戏玩法视频
↓
分析玩法和关卡
↓
生成需求文档
↓
用户确认
↓
实现 SwiftUI 游戏
↓
构建、测试和模拟器检查

第一步不是马上写代码，而是先分析视频。

Skill 要求录屏里至少有 3 个真正可以玩的关卡。它会观察游戏目标、点击或滑动方式、关卡状态、成功反馈、重置逻辑，以及不同关卡之间发生了什么变化。

这些内容会被整理成一份需求文档，并区分哪些是视频里直接观察到的，哪些是根据画面推断出来的。

只有需求文档确认之后，才会进入实现阶段，这样才能保证质量。

为什么要加这一步？

因为我试过直接让 AI 看完视频就写代码，很容易得到一个「看起来像」的界面，但玩法规则、关卡数据和交互细节可能完全不对，然后就要反反复复地改。

先把视频变成一份可确认的产品说明，后面实现时就有了明确依据。

从视频复刻成配置化游戏

这个项目不希望每次都生成一个只能跑一次的 Demo，所以我把游戏内容和游戏逻辑分开了。

以仓库里的 Word Spin 示例为例，关卡里包含图片线索、答案、棋盘行列、字母初始布局、难度和提示次数。

新增普通关卡时，只需要增加一份配置和经过授权的图片，不需要重新修改 SwiftUI 页面或移动规则。

示例展示了原版游戏录屏、需求文档、配置化 SwiftUI 游戏和模拟器录屏之间的对应关系，还提供了 Level 10、Level 11 和 Level 12 的原版与生成结果对比图。

复刻版本的游戏，图片都是 Codex 从视频抽帧生成的。

Level 10 STAR 原版与生成结果对比

Level 11 SNEAKER 原版与生成结果对比

Level 12 APPLE 原版与生成结果对比

这也是我觉得这个 Skill 比一次性代码生成更有价值的地方：视频负责提供玩法证据，配置负责承载关卡内容，代码负责实现可以重复使用的游戏规则。

Codex 还要负责验证

实现游戏只是中间过程，后面还需要构建、单元测试、UI 测试和模拟器视觉检查。

比如要验证滑动一行或一列之后，字母是否按照规则移动；答案完成后，成功状态和下一关是否正常；重新打开 App 时，关卡进度是否能够保留。这些验证也被写进了 Skill 的工作流程里。

我还增加了一条 AdMob 的接入建议：

如果后面要接入 AdMob，放在核心游戏完成之后。默认可以接入底部 Banner、从第 5 个有序关卡开始的自动插屏广告，以及用户主动点击道具时触发的激励视频；但广告不可用时，游戏本身仍然应该可以正常运行。

为什么开源

我把这个项目开源，是因为我觉得「看视频做游戏框架」可能会成为一种新的原型方式，做简单游戏生成 App 的门槛已经非常低了。

以前的流程通常是：先拆玩法，再画界面，再写规则，再手动补关卡。

现在也可以先从一段录屏开始，让 Codex 帮忙完成分析、需求整理、实现和验证，最后再用结构化的数据去替换关卡。

当然，它不是一个完全自动化的万能按钮。视频质量、玩法复杂度、素材版权和 Xcode 工程状态，都会影响最后结果，但至少这条链路已经被整理成了一个可以复用的 Skill。

项目地址：

• github.com/youxichuhai/video-to-ios-game

如果你经常需要根据竞品录屏做玩法原型，或者想把一个已有玩法快速改造成自己的 iOS 游戏，然后上架 App Store 去赚广告费，可以试试这个项目。

这个 Skill 的边界

最后补充一下这个 Skill 的边界：用 SwiftUI 复刻出来的游戏，大概能打到 59 分。

• 动效太复杂的，还是需要手动调整；
• 尺寸的细节，复刻还是会有差异，要自己去调；
• 关卡数据、每一关的图片、题库、题目的初始状态，还是需要自己去配置；
• 不同操作的手感，以及震动反馈，也需要手动调整。

好处是框架已经搭好了，你只需要去填空和打磨。