AI编程使用心得：昨天token晕了，然后让他复刻了一个我的儿时的情怀。大航海时代

我为什么觉得这个玩法值得看

这类“拿老游戏截图，让 Codex 去复刻”的思路，不是单纯图个新鲜。它真正有价值的地方，是把“我脑子里想要什么”变成“模型能看懂的参考”，再把它转成可运行的界面和交互。对独立开发者、做 Demo 的产品经理、想快速试原型的站长来说，这比空口描述需求更高效。

它解决的不是“完全自动做出一个成品游戏”，而是把前期最费沟通成本的部分先跑起来：布局、按钮、UI 风格、基础操作。只要你手里有清晰截图，Codex 这类工具就可能把一个怀旧小游戏、复刻页面，甚至手机端的简化版，先搭出雏形。

我看到的亮点

• 截图比口述更容易对齐目标。老游戏、老界面这类内容，本来就很适合视觉驱动。几张图比一大段需求说明更能让模型理解“你要复刻什么”。

• 适合做“半自动迭代”。先让模型生成一个能跑的版本，再根据截图继续修正，能把很多细节改到接近原目标。

• 更适合做 MVP，不适合一口气做大项目。复刻一个怀旧游戏的基础界面、简单战斗/航行逻辑，往往比从零设计一个复杂产品更合适。

怎么落地更靠谱

1. 先拆成“界面”和“规则”两层。先别急着让它复刻全部玩法，先做首页、菜单、地图、状态栏这类可见部分。

2. 截图要尽量干净。把关键区域截清楚：主界面、弹窗、按钮状态、地图/战斗画面。模糊图、遮挡图会让模型猜得更多，返工也更多。

3. 一次只改一个点。比如先让它把地图板块改对，再修按钮位置，最后再调交互逻辑。不要一口气要求“画面、玩法、音效、存档全对齐”。

4. 让它先输出可测试版本。哪怕是很粗糙的网页或移动端原型，只要能点、能跑，就能进入“看图改图”的迭代阶段。

5. 用“对比清单”验收。例如：主菜单是否居中、地图块是否对应、按钮是否可点击、状态切换是否符合预期。这样比“感觉不像”更容易把问题说清楚。

哪些场景适合，哪些不适合

适合的场景通常有三个：一是怀旧内容复刻，二是教学演示原型，三是轻量级小游戏或工具页。尤其是那些“看起来很复杂，但实际交互不多”的老项目，AI 很容易先搭出可用版本。

不适合的情况也很明显：复杂数值系统、多人联机、强依赖精确物理或大量素材的项目，单靠截图和提示词很难稳定复刻。还有一种情况是你手上的参考图太少，模型就只能“像个样子”，细节很容易跑偏。

我会提醒的坑

• token 不一定省。反复让模型猜界面、改细节，消耗会比想象中快。最好先规划好迭代顺序。

• “像”不等于“能用”。界面复刻得像，交互逻辑可能仍然很粗，需要人工补规则。

• 版权和素材边界要先想清楚。复刻灵感可以有，但如果要公开发布、做商业化，老游戏名称、图形资源、音效和玩法表达都可能涉及风险，具体要按实际素材确认。

• 移动端改造不是顺手一键完成。如果原始设计是桌面端，改手机屏幕时，按钮尺寸、布局重排、触控逻辑都要重新检查。

如果你想自己试，建议这样做

先选一个你熟悉、结构简单的老游戏或旧界面，准备 3 到 5 张关键截图，然后让 Codex 先做“可运行原型”。跑通后，只改一个维度：要么改视觉，要么改交互，不要一起改。等你确认模型真的理解了目标，再考虑把它继续扩展成完整项目。

如果你的目标是“快速验证一个怀旧游戏能不能做成轻量版”，这个方法很有用；如果你想直接做成正式产品，人工设计、测试和版权排查还是绕不过去。

我之前写过一篇关于AI编程的文章：《Codex踩坑记录：大家最近是不是经常刷的des很火，对不对？也有不少的朋友让我去分》，如果你想把这个话题继续看深一点，也可以一起对照着读。

常见问题

Q：没有完整素材，只有几张截图能做吗？
A：可以做原型，但更适合做界面和基础交互。玩法细节越多，越需要你补规则说明。

Q：Codex 适合直接复刻完整游戏吗？
A：更适合先做可运行的 MVP。复杂逻辑、平衡性和内容资产，通常还要人工继续打磨。

Q：做成手机端会不会更容易卖？
A：移动端确实更适合传播，但能不能做、能不能发布，还要看交互适配、性能和版权边界，不能只看“能跑起来”。