试玩 → 修复循环：写给编程智能体的问题报告

用途

第一版已经做出来、进入「试玩 → 报告 → 修复」阶段后就用它。它处理两类问题：

• Bug：发生了不该发生的事（穿过地板、门永远打不开、分数算了两遍）。需要复现步骤、预期与实际，以及证据。
• 手感问题：功能都正常，但玩起来飘、滑、迟钝或者打击无力。需要一个测量值和一个目标值，因为「手感再好一点」等于邀请模型加粒子、加屏幕震动、再加一个你根本没要的冲刺。目标数值见 手感调校。

这个循环建立在五条规则上，就算你从来不贴模板，也值得照做：

1. 一轮只解决一个问题。 一轮改两处，变好或变坏时你都说不清是哪一处的功劳。
2. 先找原因，再写代码。 模型先列出最多三个可能原因，每个都写明怀疑的文件和函数，再去验证排第一的那个。这能防止它在别处掩盖症状，比如速度被叠加了两次，它却去调大摩擦力。
3. 用最小的改动验证原因。 设硬上限（1–2 个文件、约 20 行、不重构、不加新依赖），每个 diff 一分钟内就能看完。
4. 改之前和改之后都要测。 如果问题还没法变成一个数字或一行日志，这一轮唯一的任务就是先把读数加上。
5. 要么保留，要么回滚，不要层层叠加。 没起作用的改动，在试下一个想法之前先撤掉，代码里才不会堆满半成品修复。

一轮 3–10 分钟。十轮干净利落的循环，比一下午「还是不对，再试试」推进得多。