AI 助手改了你的游戏，留下这次改动之前该怎么检查？

把改动的文件和任务对照，从删除的部分开始读 diff，亲自运行检查，玩一遍改动的地方，然后才提交 commit。

按这个顺序看四样东西：哪些文件变了，diff 删掉和加上了什么，你亲自运行检查时结果如何，以及改动落到的地方玩起来怎么样。只有四样都与你的要求一致时才留下改动，并且以 commit 的形式留下。只要有一样不一致，就撤销改动，换一个更好的任务重新提。助手的报告告诉你该看哪里；它本身不是检查。

为什么“完成了”还不够？

因为那是一句说法，证据是改动本身。助手可能只确认了代码能构建，就说功能可以用了；也可能说只动了一个文件，而它运行的一条命令其实改写了三个。

其中有些东西在编辑器里根本看不到。Visual Studio Code 关于检查 AI 所做编辑的页面说：待处理的编辑已经保存到磁盘；通过终端命令或脚本做的修改不会出现在它的编辑列表里；它的检查点不会撤销终端命令或部署。这是该页面 2026 年 10 月 29 日的内容，最后更新于 10 月 21 日。无论用什么工具，可靠的视图来自版本控制：每一个与你上一次 commit 不同的文件。

所以第一步要在助手开始之前做：把能运行的版本保存为一个 commit。没有它，改动就没有可比的对象，也没有可以退回的地方。

先看什么？

先看改动文件的列表。两条命令可以给出它：

git status
git diff --stat

git status 列出每个改动的文件和每个新文件。git diff --stat 再加上每个文件增加和减少了多少行。注意，单独的 git diff 不显示尚未加入 Git 的新文件；git status 会显示，所以两者都要看。

然后把列表和你的任务对照。如果你写的是一个说明改动放在哪里、什么不能改的任务，这只需要几秒钟。

这些本身都不一定是错。但每一项都是你原本没打算检查的东西，所以要先看。

不会编程，怎么读 diff？

把它当作一张清单：删掉的行（红色，标 -）和加上的行（绿色，标 +），先看删掉的。消失的一行最容易漏看，玩的时候也最难发现：一个防止玩家穿墙的检查，分数的清零，一个防止空存档的保护。

然后找几种不懂编程语言也看得出的迹象：

• 变了的数字：速度、生命数、计时器、价格。每一个都应该出现在你的任务里。
• 被改成注释的代码，或者整块被删掉、在别处重新写了一遍。
• 和旧函数很像的新函数：同一件事做了两遍，两份以后会越走越远。
• 玩家能看到的文字：菜单、提示、错误信息。它们还正确、还在原来的位置吗？

遇到读不懂的行，就问助手这一行做什么、谁会调用它。问一句不花什么成本，而一个与代码对不上的回答本身就是发现。

哪些检查要亲自运行？

任务里点名的那些，由你来运行，而不是听报告。任务要求了测试，就运行测试并读结果。任务要求页面加载时没有错误，就打开浏览器控制台再打开游戏。亲眼看到通过的检查，比一句“已通过”更有分量。

绿色的测试只能证明它测到的东西。如果同一个 diff 里测试文件也改了，就读那一部分：一个原来期待重开后分数为 0、现在期待“代码返回什么就是什么”的测试，已经什么也不检查了。

留下改动之前要玩什么？

先玩改动本身，按任务描述的方式。然后在游戏其余部分走一条短路线，每次都一样，因为一处的改动常常会弄坏另一处：

1. 从新打开的页面启动游戏；
2. 每个操作都用一次，键盘上用，如果游戏有触控操作，手机上也用；
3. 暂停、失败、重新开始；
4. 存档、刷新页面、读档。

这条路线只要几分钟，能抓住测试很少覆盖的问题：不再响应的按钮、离不开的界面、读不回来的存档。如果改动加了一个按键或一个界面，要确认用触控也能操作；自从我们给 KittenGalaxy 加上触控操作以来，一直遵守这条规则。

怎么留下改动，或者丢掉它？

要留下，就提交 commit，写一句用玩家的话说明改了什么的信息：“每一波比上一波快 10%，最高到起始速度的两倍”。一个任务，一个 commit。以后出问题时，你能找到是哪次改动造成的，只撤销那一次。

要丢掉，就回到上一个 commit。在 Git 里，git restore . 会把 Git 已经跟踪的文件恢复到上一次 commit 的样子，除非这些改动已经用 git add 暂存；助手新建的文件不会被它删掉，所以再看一次 git status，手动删除它们。自带撤销或检查点的编辑器也能做到同样的事，但以它们说明的范围为限。然后写一个更好的任务：说明哪里出了错，并加上一个本来能抓住它的检查。

很容易想留下一个大体正确的改动，剩下的在下一个任务里修。只有当你说得出哪里不对、而且问题很小时才这样做。你看不懂的改动，在下一个改动叠上去之后不会变得更好懂。用助手做的游戏就是这样失控的，这也是为什么小小的第一个游戏更容易保持可运行。

能让另一个 AI 来检查吗？

它可以和你一起读 diff：解释代码行，指出被删的检查，问新函数是做什么用的。这很有帮助，尤其是你不读代码的时候。但它无法判断游戏是否仍然做着你想要的事，因为只有你知道，它也不能替你玩游戏。把它当作第二位读者，永远不要当作批准。

常见问题

一次检查该花多长时间？ 改动越小，检查越快。如果读 diff 比写任务还花时间，任务多半太大了；把下一个拆开。

这需要 Git 吗？ 你需要某种能看到改了什么、并能退回去的办法。Git 是常用的办法，而且免费；大多数编辑器和助手都能配合它使用。

改动是对的，但代码看着乱怎么办？ 如果它能用、你也看得懂，就留下，再单独写一个整理的任务，用同样的检查。不要把整理混进新功能的改动里。

美术、声音和关卡文件的改动也要检查吗？ 要，但靠看和玩，而不是读 diff。改动文件的列表仍会告诉你该看哪些。

什么时候可以让别人来玩？ 当上面的路线在新页面上能走通，而且陌生人不靠你帮忙就能玩完游戏的时候。那时你可以把它提交到 HeapPlay。