怎样给 AI 助手写一个结果可以检查的任务？
只要求一处改动，说明改在哪里、什么不能变，给出一个能判定通过或失败的检查，并要求汇报做了什么。
只要求一处改动，小到几分钟就能试完。说明它放在哪里、什么必须保持原样、怎样检查它能用，以及你希望听到什么答复。这样写的任务，回来的是你能判断的东西：一份很短的已改文件清单、一个通过或失败的检查，以及一个你可以亲自玩一遍来确认的游戏。含糊的任务回来的是一大堆“看起来做完了”的改动，检查的活就全落到你身上。
什么样的任务才能检查？
五个部分。大多数任务五个都需要，每个用一两句话就能写完。
| 部分 | 写什么 | 为什么有助于检查 |
|---|---|---|
| 1. 改动 | 游戏要做得不一样的一件事 | 你能看出它有没有发生 |
| 2. 位置 | 它所属的文件、画面或函数 | 改动留在一个地方 |
| 3. 不能变的东西 | 操作、存档、其他画面、库 | 清单之外的任何改动都很显眼 |
| 4. 检查 | 一个测试、一条命令，或要玩的步骤 | 它给出通过或失败，而不是一种印象 |
| 5. 汇报 | 改了哪些文件、运行了哪些检查、什么没测 | 你读的是证据，而不是把活重做一遍 |
这些都不是新建议。GitHub 的为 Copilot 写提示的指南要求请求简单、具体，拆成步骤，并给出一两个你期望结果的例子。Claude Code 的最佳实践把助手自己能运行的检查放在第一位，因为没有它，“看起来做完了”就是助手唯一的信号。2026 年 10 月 25 日这两个页面都是这样写的。下面把它们用到一个小游戏上。
一个任务应该多小？
小到能用一句话描述这个改动，并在几分钟内试完。“加一个暂停画面”是一个任务。“加一个暂停画面、一个设置菜单和声音”是三个，出了问题你不会知道是哪一个造成的。
如果一个任务需要更长的描述，先要一个计划，代码留到后面。Claude Code 的页面正是这样建议的：让助手先读代码，提出哪些文件会改，你自己读这个计划，然后才让它动手写。一个牵动半个项目的计划，说明这个任务应该拆开。
这和让第一款游戏保持小巧是同一条规则：每个功能都要和其他所有功能一起正常工作，所以一次加三个功能的任务会让检查成倍增加。
含糊的任务和可检查的任务放在一起是什么样？
下面是给一个小射击游戏的同一个请求，写了两遍。
| 含糊 | 可检查 |
|---|---|
| “让游戏更难。” | “在波次的代码里，让每一波比上一波快 10%，最多到初始速度的两倍。不要改玩家的速度、生命数和操作。” |
| “修一下分数的 bug。” | “重新开始后，分数从旧分数开始，而不是从 0 开始。找到重新开始时重置游戏的地方，让它把分数也重置，并加一个测试：重新开始两次，期望分数为 0。” |
| “加上手机操作。” | “在触摸屏上显示左、右和开火按钮，发送与键盘相同的按键事件。用键盘玩的方式不能改变。告诉我哪些画面还没有触摸操作。” |
右边一栏更长，但每一行都能检查。第三行接近我们给 KittenGalaxy 加触摸操作时的做法：按钮发送键盘会发送的按键事件，所以游戏本身不需要改。
怎样告诉助手如何检查自己的工作？
给它一个能回答“是”或“否”的东西。
- 一个测试，助手可以运行，情况要写清楚：“重新开始后分数为 0”。
- 一条命令，结果可以读出来：构建完成，页面加载时控制台没有错误。
- 你自己要玩的步骤，在改动之前写下：“开始，失去所有生命，按重新开始，分数显示 0”。
让助手运行检查并展示输出，而不是说它通过了。贴出来的测试结果或没有错误的控制台日志几秒钟就能读完；一句“一切正常”什么也证明不了。
有些东西只有人能判断：跳跃的手感对不对，一个关卡公不公平。对这些，写下你要看什么，然后自己玩。不要让助手的汇报代替这一步。
助手做完后应该告诉你什么？
在同一个任务里要求一份简短的汇报，按这个顺序：
- 改了哪些文件，每个用一行说明为什么；
- 运行了哪些检查，结果是什么；
- 没有测试什么，为什么；
- 改了哪些你没要求改的东西。
最后一项最重要。超出请求的改动不一定错，但它总是你没打算检查的东西。把文件清单和你任务的第 3 部分对照：本不该改的文件，就是最先要看的地方。
什么应该放在项目文件里，而不是写进每个任务？
凡是你本来要反复说的：怎样运行游戏和测试，哪些文件夹不能碰，代码的规则。大多数助手会在会话开始时读这样一个文件（Claude Code 把它叫做 CLAUDE.md）。让它保持简短；Claude Code 的页面提醒，文件一长，重要的规则就会被淹没。
一条规则值得放进去，是因为忘了它会把游戏弄坏。我们为 KittenGalaxy 记的笔记里写着：每当加一个按键、一个画面或一个游戏状态，就在同一次改动里加上它的触摸操作，否则用手机玩的人到不了那里。这样，任务里只需要说新的东西。
结果不对时怎么办？
先退回去，再用更好的任务重新要求。
每个任务之前，用版本控制里的一次提交保存一个能用的版本，这样一次糟糕的改动一步就能撤销。检查失败时，可以要求修一两次。如果两次纠正都失败了，Claude Code 的页面建议用一个更好的开头请求开始新的会话，而不是一遍又一遍地纠正，因为失败的尝试会留在对话里。撤销改动，把你学到的东西补进任务，再发一次。
常见问题
写这样的任务需要会编程吗？不需要。第 1、3、5 部分讲的是游戏做什么，用平常的话就行。至于第 2 部分，先问助手这个改动该放在哪里，再让它去改。
长任务比短任务好吗？本身并不。要求很多改动的长任务，比只要求一处改动的短任务更难检查。长度只有在加上一个检查或一条限制时才有帮助。
小游戏也要让助手写测试吗？对那些能说得很精确的规则（分数、生命、计时器、存档），要。之后每次改动都可以低成本地再跑一遍。手感和乐趣仍然要靠玩。
如果助手问我问题怎么办？在它开始写之前，在任务里回答。早问一个问题，比改错一次代价小。
游戏什么时候可以给别人看？当一个陌生人能从一个链接打开它，并且不需要你帮忙就能玩完的时候。那时你可以提交到 HeapPlay，已验证的开发者还可以记录每个新版本以及改了什么。
ai-assistants workflow testing
正在做游戏？把它提交到 HeapPlay，并了解开发者能得到什么。