AI 做的游戏出了 Bug，不懂代码该怎么修？

游戏已经能玩了，收集、计分和结束画面都在。你让 AI 加一个暂停按钮，再打开游戏，发现“重开”只重置了画面，时间还接着上一局往下走。AI 回复“已修复”，你再试一次，问题依然存在。

没有编程经验，也可以参与这段排错过程。你需要把“哪里不对”变成一组别人能重复的操作，再用同一组操作检查修改结果。这篇会用三个可以亲手操作的故障，练习怎样向 AI 提供线索、限定修改，以及在改坏时退回可用版本。

如果你还没有能运行的游戏，可以从制作第一个可玩游戏开始。已经有原型的读者，可以直接打开排错练习场。三个故障都是教学专门设置的，分别配有修复版，上一篇的“灯塔快递”保持原样。

修改前，留下一份确实能打开的版本

先确认自己正在修改哪个项目、浏览器打开哪个地址。电脑里有两份相似文件夹，AI 修改了一份，浏览器却显示另一份，也会造成“怎么修都没变化”的错觉。

接着保存当前项目。如果有一个更早、能够正常游玩的版本，也一起保留，并写清两者的状态：例如 09-26-暂停功能加入前-可通关 和 09-26-暂停功能加入后-重开异常。一个有故障的版本仍值得保存，它能帮助你检查问题是从哪里开始的。

按你的工作方式选择保存方法：

• **在本地文件夹制作：**停止正在修改文件的任务，把代码、素材和项目配置一起复制或打包。请 AI 说明启动方式，然后打开副本确认能运行。不要覆盖原文件夹。
• **在带历史记录的网页工具制作：**找到最近可用的版本，预览它；如果支持导出，再保存一份导出文件。Rosebud 的官方教程目前给出的做法是从 History 查看旧版本，预览后再决定如何继续。
• **已经使用 Git：**让 AI 查看当前改动，说明哪些属于本次任务，再保存检查点。尚未保存的素材和改动也要核对，不能只记下一个提交编号。

不熟悉备份操作时，可以把这段话交给 AI：

我要排查一个故障。先不要改代码。
请确认当前项目目录、启动方法和预览地址，列出已经修改但尚未保存的内容。
告诉我怎样保留当前版本，并确认保存的副本可以启动。
不要删除、覆盖或恢复已有文件。需要这些操作时，先说明目标和影响。

练习包没有账号、云存档或外部数据库；带这些服务的项目还需要单独考虑数据备份，复制代码不会复制服务器上的玩家数据。

把“游戏坏了”写成一次能重复的操作

一份有效的反馈，至少让 AI 知道：你在哪个版本上，用什么设备，做了哪些动作，本来应该发生什么，实际看到了什么。

“重开有问题”可以写成：

页面：排错练习场，案例 03，故障版。
环境：电脑 Chrome，使用鼠标。

复现步骤：
1. 刷新页面，点击“开始夜航”。
2. 等到约剩 22 秒，点击“暂停”。
3. 点击工具栏中的“重开”。

预期：新一局从 30 秒开始，漂流灯 0/5，船体 3/3，小船回到码头。
实际：收集数和位置重置了，时间仍然从约 22 秒继续。
频率：请填写你实际重复了几次、出现了几次。
最近改动：加入了暂停和继续功能。

请先复现并说明原因，再修改重开相关逻辑。
保留继续游戏的行为，不改地图、移动速度、胜利条件和美术。

不要为了让反馈看起来专业而猜原因。看见小船不动，可以记录“小船位置一直是 108, 270”；“事件系统坏了”已经是一个需要证明的判断。

截图适合表示位置、数字和界面状态。问题涉及先后顺序时，补一段从刷新页面到出现故障的短录屏，或者写下完整步骤。分享前遮住账号、密钥和无关窗口。

有些 Agent 能直接操作本地预览。当前 OpenAI 的浏览器文档说明，桌面端的 Codex 可以在获得相应访问许可后操作页面、检查状态和验证结果。可以让它照步骤重现；如果当前工具无法打开你的游戏，就由你操作，把观察结果带回来。

案例一：鼠标能动，触屏没有反应

打开触屏故障版，在触屏设备上开始一局，按住左上方的第一盏灯。电脑鼠标在这个版本里仍然有效，因此只在电脑上点击一下，会漏掉故障。

练习页下方有一个“运行中的观察值”面板。它只显示状态，不能代替你移动小船或设置通关结果。触屏故障版可以看到：触摸次数增加，小船位置没有变化，收集数仍然为 0。

把范围缩到这个输入差异：

同一个页面，鼠标按住水面能移动，触屏按住水面没有移动。
我已经点了开始，计时正在减少。
观察面板显示收到触摸，但小船位置不变。

请检查触摸输入在哪一步没有传给移动逻辑。
只处理输入问题，保留鼠标、键盘、移动速度和碰撞规则。
完成后分别检查按住、拖动、松手，以及重新开始后再次触摸。

这个练习的故障点是一条过滤条件：它直接忽略触摸类型的输入。修复版允许主要触摸输入驱动小船。浏览器的 Pointer Events 能区分鼠标、触摸和笔，相关技术依据见 MDN 文档；你可以让 AI 阅读和检查这部分实现，无需自己记住事件名称。

打开触屏修复版，再次按住同一盏灯。应该能看到位置变化并收集到灯，松手后小船停止。随后再试方向键，确认原来能用的输入仍然正常。

这里的两张截图来自浏览器触屏模拟。你准备分享给手机用户时，还要在自己的实际手机和目标浏览器上重复操作。如果原项目的问题是页面滚动、遮罩挡住画布，或坐标偏移，修复方式会不同；相似的现象不能直接套用这个练习的代码结论。

案例二：已经收齐五盏灯，却没有胜利画面

打开通关故障版。依次收集五盏灯，再回灯塔旁的光圈。可以先取左上、上方、右侧三盏，再绕过礁石收集右下和下方两盏，最后绕开左侧礁石返航。

问题出现时，停下来核对三个值：收集数是不是 5/5，是否已经位于码头，游戏是否仍然显示“游玩中”。还要确认时间没有归零，船体没有耗尽。这样就能把“可能还没满足规则”与“满足了却没有结算”区分开。

这时给 AI 的反馈可以很短：

收集数是 5/5，观察值显示位于码头，时间尚未结束，游戏仍然没有通关。
规则是：收集五盏灯，并在时间内回到码头。

请检查结算条件和界面显示使用的规则是否一致。
修复后检查三种情况：
- 不满五盏回码头，继续游戏。
- 收齐五盏但没回码头，继续游戏。
- 收齐五盏再回码头，出现胜利画面。
不要增加第六盏灯，也不要取消返航要求。

练习故障把胜利条件写成了六盏，而地图和界面都只提供五盏。修复需要让结算遵守已有规则。这个例子也说明：游戏完全可能没有红色报错，却仍然算错结果。

在通关修复版里重复同一条路线。收齐的瞬间应提示返航，进入码头后才出现胜利画面。只展示一张胜利截图还不够，前面两种“不应通关”的情况也要检查，防止 AI 为了让结果出现，顺手放宽了胜利条件。

如果你的游戏没有观察面板，可以要求 AI 暂时显示与问题有关的几个值，例如“当前收集数”“目标数量”“是否进入终点”“游戏状态”。数值标签要让人看懂，排错完成后再决定是否保留这个调试界面。

案例三：暂停以后重开，时间却接着上一局走

打开重开故障版，按前面的反馈步骤操作：开始、等到约剩 22 秒、暂停、重开。故障版会把旧倒计时带进新一局。

“继续”和“重开”看起来只差一个按钮，但对进度的要求不同。继续应该保留时间、收集数和位置；重开应该重新初始化这一局。让 AI 把这两组行为分别写清楚，再去修改，能避免为了修好一个按钮而改变另一个。

这里的修复版创建新一局时恢复 30 秒。用修复版检查暂停后的重开，再从超时画面重开。两条入口都应获得完整的新一局。

可以让 AI 补上一条自动检查：给一局设置较少的剩余时间，执行重开后确认回到 30 秒。这样的检查适合守住明确的规则；按钮是否真的连到正确动作、手机点击是否有效，仍需要在运行中的页面上检查。

页面空白或报错时，补上可读取的错误信息

前面三个练习故障都能在画面上观察到，不会故意制造 JavaScript 崩溃。遇到真实项目的白屏、无法启动或按钮直接报错时，再补充日志。

如果本地启动窗口已经显示错误，复制完整错误文字，连同你刚才执行的命令交给 AI。不要只截最底下一句“启动失败”。

在电脑 Chrome 中，Windows 或 Linux 可以按 Ctrl + Shift + J，Mac 可以按 Command + Option + J 打开 Console。保留这个窗口，回到游戏重复一次故障，复制与这次操作相关的错误和文件位置。需要刷新才能出现的问题，可以打开 Preserve log，让刷新前后的日志保留下来。这些入口见 Chrome 官方 Console 文档。

不需要在 Console 里粘贴陌生代码，也不要为了排错关闭浏览器安全保护。当前目标只是取得错误信息。错误中若带有访问令牌、个人信息或私有地址，分享前先处理敏感内容。

拿不到日志也没关系，告诉 AI“我没看到错误文字”，继续提供操作步骤和截图。没有日志时，不能把“没有发现报错”写成“检查通过”。

AI 说修好了以后，亲手重走原来的步骤

先看它实际检查了什么。“文件能编译”“检查脚本通过”“页面可以打开”“原故障不再出现”，分别回答不同的问题。要求回复里写明做过的操作和看到的结果，例如“暂停后点击重开，计时恢复到 30 秒”，比一句“测试通过”更容易核对。

每次修复至少检查两层：第一层是原故障的完整操作，第二层是紧挨着它的旧功能。修触屏后检查鼠标和键盘，修通关后检查不满足条件时不会通关，修重开后检查继续游戏仍保留进度。

一次小修改后，可以预留十分钟快速走一圈：

1. 刷新或重新启动游戏，确认打开的是当前版本。
2. 完整重复原故障步骤，记录预期和实际结果。
3. 走一遍正常游玩路径，包括收集或计分。
4. 检查胜利与失败，并从结果页重开。
5. 检查暂停、继续和重开各自应保留或清空的进度。
6. 在受影响的输入设备或屏幕尺寸上再试一次。

十分钟是给小型原型安排的检查时间，不是质量保证；账号、付费、存档、联网对战等功能需要各自的检查。更详细的记录可以用可下载检查清单。

连续修改没有进展时，暂停加补丁

第一次修改没有消除现象，就把同一组步骤和新结果发回去。接下来的一次修改，应该来自新的线索。如果 AI 只是反复调整同一段代码，却说不清多知道了什么，可以要求它停下来：

这次修改后，原来的复现步骤仍然失败。
先停止改代码，整理目前确认的事实、尝试过的修改，以及仍未排除的原因。
下一步只选一个能区分原因的检查，说明我要看哪里、怎样操作。
需要撤销时，列出准备恢复的文件和会丢失的改动，等我确认。

如果越来越多原本正常的功能开始出问题，保留当前故障版本和简短记录，另开一份最近可用的副本，重新处理最初那个问题。恢复前核对后面添加的素材和功能，别让一次回退把它们一起抹掉。

这种修改范围的管理也出现在实际开发记录中。Call the Cat: Galaxy 的作者描述了自己不读写代码、通过 AI 制作 Unity 游戏时的约定：记录改动前核对文件，只纳入当前任务涉及的修改。那篇日志讨论的是项目管理规则，并没有把它当成游戏已经无故障的证明。

当问题涉及支付、用户账号、不可恢复的存档丢失，或者 AI 无法解释为什么需要大范围重写时，先停止把新版本交给玩家。整理好的复现记录可以交给有经验的开发者，能让接手的人少走很多弯路。

把这次修复留下来，下次就有起点

最终留下一段很短的记录就够了：哪个版本有问题、怎样复现、改了哪些文件、重新检查了什么、下次遇到同类问题先看哪里。把它和可用版本一起保存。

你可以带走故障反馈模板、修复检查清单，或整套练习源码。源码包保留三种故障与修复分支，便于反复比较；它不会替换你原来的游戏项目。

修好一个问题后，再决定要加什么。能够反复打开、改动、验证和恢复的原型，才方便你继续调整玩法、加入美术，并交给朋友试玩。