01
万能 Bug 描述模板
【问题描述】- 我在做什么:(例:在测试页面点击选项)- 我期望的结果:(例:跳转到下一题)- 实际发生的:(例:没反应,页面不动)- 截图/录屏见附件【请你先做(重要)】1. 不要改任何代码2. 列出 2-3 个可能的原因3. 告诉我你最怀疑哪一个,为什么4. 告诉我需要我提供什么信息才能确认【约束】- 修复时只改和这个 bug 直接相关的代码- 不要顺手优化其他地方- 改之前请先 git commit 存档- 解释清楚再动手,等我确认后再 apply
02
存档 & 回滚(保命)
在改任何代码之前,请先执行 git commit,把当前的工作状态保存下来。commit message 写:「修复 [问题简述] 前的稳定版本 + 当前日期时间」确认 commit 成功后再开始修改。
刚才的修改没有解决问题,反而引入了新的问题。请立刻撤销刚才所有的改动,使用 git reset --hard 回到上一个 commit 的状态。回滚后告诉我现在的代码状态,确认干净后我们重新分析问题,不要在烂代码上继续修。
03
限定 AI 的活动范围
这次修改请严格遵守以下规则:1. 只允许修改与当前 bug 直接相关的代码2. 不允许重写整个文件3. 不允许"顺手"优化其他你觉得写得不好的地方4. 如果你认为必须改其他文件或功能,先停下来告诉我原因,等我同意再改5. 改完之后,列出你具体改了哪些文件的哪几行,方便我检查
我现在有多个问题需要修复,但我们一次只解决一个。现在只处理这一个问题:[具体描述这一个问题]其他问题先不要管,等这个问题修复并测试通过后,我们再开始下一个。请确认你理解了这个规则再开始。
04
陷入死循环时的急救包
停。不要再继续改代码了。我观察到你已经反复修改这个问题但都没解决,这说明我们对 bug 的判断方向是错的。请回答以下问题:1. 你之前判断的根本原因是什么?2. 这个判断有没有可能是错的?3. 还有什么其他可能的原因是我们没考虑过的?4. 我能提供什么具体信息(例如哪个文件的日志、哪个按钮的截图、哪段操作的录屏)帮你重新判断?在我提供新信息之前,不要再写任何代码。
现在不要试图修复这个 bug 了。请在相关的关键函数里加上 console.log,输出关键变量的值和执行流程。我会运行一次,然后把控制台的输出原样贴给你。你根据真实的日志输出来判断问题在哪,而不是猜。加日志的时候不要修改任何业务逻辑,只是单纯加打印语句。
最后总结下:小白的六条铁律
一、改之前永远先存档
git commit 是你的存档点,跟游戏一样。没存档前不许 AI 动手。
二、先问"为什么",再让它"动手"
让 AI 先分析原因、列假设,你确认方向后再让它改。猜的代码 = 烂的代码。
三、一次只改一个问题
永远不要打包式提问。一个问题修好、测试、commit,再开始下一个。
四、改完立刻测,不行立刻退
绝对不要在改坏的代码上继续让它修。烂代码 + AI = 雪崩。
五、描述"现象",别猜"原因"
你只说"我做了什么 / 期望什么 / 实际发生什么",原因留给 AI 判断。
六、圈定范围,禁止顺手优化
"只改 XXX,其他不许动"——这一句话能避免 50% 的连环 bug。
夜雨聆风