遇到 Bug 怎么高效让嗒啦啦修复？—— 游戏调试实战指南
05/0362 浏览开发心得
做游戏一定会遇到 bug。角色穿墙、按钮没反应、画面闪烁、分数不对……这些都是家常便饭。
很多人遇到 bug 的第一反应是跟嗒啦啦说"有 bug 帮我修"。然后嗒啦啦问"什么 bug"，你说"就是不对"，嗒啦啦再问"哪里不对"，你说"你自己看啊"——两三轮下来什么也没解决。
问题在于：嗒啦啦看不到你的屏幕。它不知道你遇到了什么现象，不知道你做了什么操作触发的，也不知道你期望的正确结果是什么样。
这篇帖子教你一套完整的"报 bug → 定位 → 修复 → 验证"的流程，让嗒啦啦帮你用最少的轮次把问题解决掉。
难度：零基础可上手
————————————————
第一章：报 Bug 的黄金公式
不管什么 bug，用这个公式描述就够了：
我在做 ___（什么操作）的时候，___（什么东西）出现了 ___（什么现象），但正常应该是 ___（什么效果）。
四个空填满，嗒啦啦就能准确定位问题。
来看几个例子：
例子一：
「我在点击跳跃按钮的时候，角色没有任何反应，但正常应该是跳起来大约两米高。」
例子二：
「我在杀死第三只怪的时候，分数从 20 直接变成了 100，但正常应该每只加 10 变成 30。」
例子三：
「我在打开背包界面的时候，之前装备的武器不见了，格子显示空白，但正常应该是铁剑的图标还在第一格。」
对比一下反面写法：
「跳跃有 bug」—— 什么 bug？跳不起来？跳太高？跳完卡住了？嗒啦啦得猜。
「分数不对」—— 不对是什么意思？多了还是少了？什么时候开始不对的？
「背包坏了」—— 坏了是什么坏法？打不开？东西消失了？显示错乱？
一个模糊的 bug 报告至少浪费两轮对话来澄清。一个精确的 bug 报告一轮就能修。
————————————————
第二章：六类常见 Bug 和对应的描述方式
游戏开发中 90% 的 bug 都属于以下六类。每类的描述重点不一样。
【第一类：画面显示不对】
特征：东西能看到，但位置、大小、颜色、层级不对。
描述重点：说清楚"现在长什么样"和"应该长什么样"。能截图最好。
示范：
「角色的血条显示在屏幕外面了，只能看到一小截红色边缘。血条应该显示在屏幕左上角，完整地显示出来。」
「得分文字和血条重叠在一起了。得分应该在血条下方，两者之间留一点间距。」
「背景图只铺了屏幕左半边，右半边是黑色。背景图应该铺满整个屏幕。」
小技巧：描述 UI 位置时，用"屏幕左上角"、"屏幕正中央"、"底部居中"这种说法，比"在那个东西上面"清楚得多。
【第二类：操作没反应】
特征：你点了/按了/滑了，但什么都没发生。
描述重点：说清楚你做了什么操作、期望什么反应、现在是不是完全没反应。
示范：
「点击开始游戏按钮，什么都没发生。按钮也没有按下去的动画效果。预期是点击后进入游戏场景。」
「用虚拟摇杆向左推，角色不动。向右推是正常的。向左应该也能正常移动。」
「在手机上触摸屏幕跳跃没反应，但用键盘按空格是可以跳的。手机触摸也应该能跳。」
小技巧：区分"完全没反应"和"反应不对"。这是两种不同的 bug。完全没反应通常是事件绑定的问题，反应不对通常是逻辑的问题。
【第三类：碰撞和物理不对】
特征：角色穿过了不该穿过的东西，或者被不该挡住的东西挡住了。
描述重点：说清楚两个物体之间的关系，以及穿过/卡住的方向。
示范：
「角色可以从左边穿过墙壁走到墙壁右边去，但应该被墙挡住。从右边往左走是正常的，会被挡住。」
「角色跳跃后落在平台上时，会从平台上缓慢往下滑，最后穿过平台掉下去。应该稳稳站在平台上。」
「两个敌人碰到一起时会卡住不动了，叠在一起抖动。它们应该互相推开。」
小技巧：物理类的 bug 经常跟方向有关——从上面碰、从下面碰、从左边碰的表现可能不一样。把方向说清楚，嗒啦啦能更快定位问题。
【第四类：数值不对】
特征：分数、血量、伤害、速度等数字跟预期不符。
描述重点：给出精确的数值，说清楚输入和输出。
示范：
「角色攻击力应该是 10，但打敌人时敌人掉了 20 点血。每次攻击应该扣 10 点血。」
「第一波是 5 只怪，第二波应该是 7 只，但实际刷了 15 只。应该每波增加 2 只。」
「金币显示买一把剑要 100 金币，但我有 150 金币还是提示不够。金币数量应该足够买。」
小技巧：数值类 bug 跟嗒啦啦说具体数字永远比说"太多了""太少了"有用。"太多了"是多多少？说不清。"应该是 10 但显示了 20"一句话就解决。
【第五类：时序和流程不对】
特征：事情发生的顺序不对，或者该发生的没发生、不该发生的发生了。
描述重点：说清楚事件的先后顺序。
示范：
「角色还没碰到终点旗帜，就弹出了过关界面。应该是角色走到旗帜位置并碰到旗帜才触发过关。」
「Game Over 弹出后，角色还在继续移动和攻击。应该是 Game Over 后游戏暂停，角色不能再操作。」
「第二关加载完之后，第一关的敌人还残留在画面上。切关的时候应该把上一关的东西全部清除。」
小技巧：时序 bug 最好用"先……然后……但实际上……"这种时间线的方式描述。嗒啦啦最容易理解这种顺序表达。
【第六类：构建报错】
特征：嗒啦啦写完代码点构建后出现了红色错误信息。
描述重点：你不需要做任何事，嗒啦啦自己就能看到错误信息。
但如果嗒啦啦修了一次之后还在报错，你可以帮它缩小范围：
「还是在报错，跟上次的错误一样。上一次可以正常构建的版本是在加 xxx 功能之前。你看看是不是加 xxx 时引入的问题。」
小技巧：构建报错通常是嗒啦啦自己能解决的。但如果它连续修了三次同一个错误还没修好，可以说"换一种写法试试，不要在原来的方法上修了"。
————————————————
第三章：截图是最强的 Bug 报告工具
一张截图顶一百个字。
在预览窗口右上角有截图按钮，点击后截图会自动插入到对话里。但光截图还不够，配上一句说明效果翻倍。
【截图 + 说明的正确姿势】
场景一：位置错误
截图 + 画个圈或箭头指出问题区域（如果能标注的话）
如果不能标注，就用文字描述位置：
「看截图，右下角那个按钮，它应该在屏幕底部居中的位置」
场景二：穿模/重叠
截图 + 「你看角色和墙壁重叠在一起了，角色的一半身体在墙壁里面」
场景三：显示异常
截图 + 「这个地方应该显示金币数量，但显示的是一串乱码」
场景四：对比效果
如果问题是"做出来的跟你想的不一样"，可以找一张参考图：
「我想要的效果像这张图（插入参考截图），但现在做出来的是这样（插入当前截图），主要差别是按钮的排列方式不对」
【什么时候必须截图】
以下情况强烈建议截图：
UI 位置/布局问题 → 文字很难描述精确位置，截图一目了然
颜色/风格问题 → "颜色不好看"没有信息量，截图让嗒啦啦直接看到
画面闪烁/异常 → 如果能截到异常画面的瞬间最好
物理穿模 → 角色卡在墙里、穿过地面的画面截下来
以下情况不用截图也行：
逻辑错误 → "金币应该加 10 但加了 20"，用文字说就够了
流程问题 → "过关后没有回到主菜单"，用文字说就够了
构建报错 → 嗒啦啦自己能看到错误信息
————————————————
第四章：一个 Bug 修三次还没修好怎么办
这是最让人崩溃的情况：嗒啦啦改了一轮又一轮，问题还在，甚至越改越多。
遇到这种情况，不要继续说"还是不对帮我再修"。停下来，换一种策略。
【策略一：让嗒啦啦解释它的思路】
「这个 bug 你已经修了两次了还没修好。先不要改代码，跟我解释一下你觉得这个问题的原因是什么，你打算怎么修。」
有时候嗒啦啦对问题的理解就是错的。让它先解释思路，你可以判断它是不是搞错了方向。
如果它的解释跟你看到的现象不符，你可以纠正：
「不是这样的。问题不是出在 xxx，而是 xxx。你重新分析一下。」
【策略二：让嗒啦啦换一种方案】
「这个方案改了三次还有问题，换一种完全不同的实现方式吧。不要在原来的代码上修了。」
有时候第一种实现方案本身就有设计缺陷，怎么修补都不完美。换一种方案可能反而简单。
【策略三：回到能用的版本重做】
如果你之前保存过代码（用 /git-save），可以让嗒啦啦回退：
「这个功能越改越乱了。帮我恢复到加这个功能之前的版本，然后用新的方案重新做。」
没保存过也没关系，你可以说：
「把 xxx 功能相关的代码全部删掉，回到没有这个功能的状态，然后我们重新做。」
重做听起来浪费时间，但比在烂代码上打补丁快得多。
【策略四：缩小问题范围】
如果你不确定 bug 出在哪：
「帮我排查一下。先把 xxx 功能临时去掉，只保留最基础的移动和显示。看看问题是不是还在。」
这就是程序员常说的"二分法排查"——把功能一个个关掉，直到找到罪魁祸首。你不需要懂代码，只要会说"把 xxx 去掉试试"就行。
————————————————
第五章：修一个 Bug 引出三个新 Bug
这种情况比"修不好"更头疼。嗒啦啦修了跳跃的 bug，结果移动也坏了。
为什么会这样？因为嗒啦啦修 bug 的时候，有时候会"顺手"改动其他相关的代码。这些改动解决了眼前的问题，但破坏了别的功能。
【预防方法一：提前划定范围】
修 bug 之前先说清楚不能动的地方：
「帮我修 xxx 的问题。注意：只改跟 xxx 直接相关的代码，不要动移动、射击和 UI 相关的代码。」
嗒啦啦有时候会觉得"顺便重构一下更好"，这句话能阻止它。
【预防方法二：修完之后检查清单】
修完一个 bug 之后，把其他主要功能快速试一遍：
修完跳跃 bug → 试试移动正不正常 → 试试攻击正不正常 → 试试 UI 正不正常
如果发现新问题，立刻告诉嗒啦啦：
「你刚才修跳跃 bug 的时候，把移动也弄坏了。现在角色移动速度变成了之前的两倍。请把移动恢复成修之前的状态，同时保持跳跃的修复。」
关键词是"恢复成修之前的状态"——告诉嗒啦啦，你不是要它重新修移动，而是要它撤销对移动的误改。
【预防方法三：每做完一个功能就保存】
跟嗒啦啦说 /git-save 就能保存当前版本。
建议在这些时机保存：
每个功能做完并验证通过之后
准备修一个复杂 bug 之前
准备做大改动之前
保存了之后，万一改坏了可以回退，不用从头重来。
————————————————
第六章：有些不是 Bug，是需求没说清
有一类"bug"其实不是代码的问题，而是你的需求没有说清楚，嗒啦啦按它的理解做的，跟你想的不一样。
怎么区分真 bug 和需求问题？
【判断方法】
问自己两个问题：
问题一：你之前有没有明确告诉嗒啦啦这个行为应该是什么样的？
如果没说过 → 不是 bug，是需求补充。
如果说过但做得不对 → 是 bug。
问题二：嗒啦啦做的结果在某种理解下是合理的吗？
合理 → 需求没说清楚，嗒啦啦选了另一种合理的理解。
不合理 → 真 bug。
【需求补充的正确说法】
不要说"这里有 bug"，直接补充你的需求：
「角色碰到敌人之后我设想的效果是弹开一段距离并闪烁两秒无敌时间，不是直接死亡。帮我改成弹开加无敌时间的方式。」
「我希望暂停后所有东西都静止，包括敌人和子弹，不只是角色停下来。帮我改成全局暂停。」
关键是描述你想要的效果，而不是说现在的做法"错了"。因为它可能没错，只是跟你想的不一样。
————————————————
第七章：手机上和电脑上表现不一样
你在电脑上预览一切正常，到手机上就出问题了。这类 bug 比较特殊。
【常见原因和描述方式】
原因一：屏幕比例不同
电脑通常是横屏 16:9，手机竖着拿是 9:16 或 9:20。
描述方式：
「在电脑上预览 UI 是正常的，但在手机上打开，按钮跑到屏幕外面去了。手机是竖屏模式。帮我做一下竖屏适配。」
原因二：触控和鼠标不同
鼠标有悬停效果，手机没有。鼠标可以右键，手机不行。
描述方式：
「鼠标悬停在按钮上有高亮效果，但手机上没有任何反馈。可以改成按钮按下去有缩放动画吗？这样手机上也有按压反馈。」
原因三：性能差异
电脑流畅，手机卡顿。
描述方式：
「在手机上运行特别卡，尤其是敌人数量超过 10 个的时候。电脑上没问题。有没有办法优化手机上的性能？」
原因四：刘海屏和安全区
手机顶部有刘海或药丸，底部有手势条，UI 被遮挡。
描述方式：
「手机上顶部的血条被刘海遮住了一部分。帮我加一下安全区处理，让 UI 避开刘海和底部手势条的区域。」
————————————————
第八章：Bug 修复的完整流程
把前面几章的内容串成一个标准流程，每次遇到 bug 按这个来：
第一步：发现问题
试玩时发现了异常。
第二步：判断是 bug 还是需求问题
你之前有没有明确告诉嗒啦啦这个行为应该怎样？
如果没说过 → 跳到第六步（补充需求）。
如果说过 → 继续第三步。
第三步：用黄金公式描述
我在做 ___（操作）的时候，___（东西）出现了 ___（现象），但正常应该是 ___（效果）。
第四步：截图辅助（如果是画面问题）
UI 位置不对、画面异常、穿模 → 截图发给嗒啦啦。
纯逻辑/数值问题 → 文字描述就够。
第五步：限定修改范围
「只改跟这个问题直接相关的代码，不要动其他功能。」
第六步：等嗒啦啦修复
第七步：验证修复
先验证这个 bug 是不是修好了。
再快速试一下其他主要功能有没有被影响。
第八步：确认或继续
修好了 → 「没问题了，继续做 xxx。」
没修好 → 回到第三步，补充更详细的描述。
修好了但弄坏了别的 → 「这个修好了，但 xxx 被弄坏了。请恢复 xxx 并保持这次的修复。」
————————————————
第九章：九句让修 Bug 效率翻倍的话
下面九句话在不同场景下直接复制使用。
第一句：精确描述 bug
「我在做 ___（操作）的时候，___（东西）出现了 ___（现象），但正常应该是 ___（效果）。」
第二句：限定修改范围
「只改跟这个问题直接相关的代码，不要改动其他功能的代码。」
第三句：让嗒啦啦先解释再动手
「先不要改代码，跟我解释一下你觉得这个问题的原因是什么。」
第四句：换方案
「现在的方案改了几次还有问题，换一种完全不同的实现方式吧。」
第五句：回退
「这个功能越改越乱了。把 xxx 功能相关的代码全部删掉，回到没有这个功能的状态，重新来过。」
第六句：恢复误改
「你修 xxx 的时候把 xxx 弄坏了。请把 xxx 恢复成修之前的状态，同时保持 xxx 的修复。」
第七句：缩小范围排查
「帮我排查一下。把 xxx 功能临时去掉，看看问题是不是还在。」
第八句：补充需求而不是报 bug
「我希望这里的效果是 xxx，帮我改成这样。」
第九句：确认修复
「这个问题修好了。其他功能我也试了，都正常。继续做下一个。」
————————————————
第十章：预防比修复更重要
最后聊聊怎么让 bug 少出现。
【习惯一：一步一验】
每做完一个功能就立刻试玩验证。不要连着做五个功能然后一起验证。
五个功能一起验证的问题是：发现 bug 了你不知道是哪个功能引入的。一个一个验，bug 出在最新的那个功能里，一目了然。
【习惯二：重要节点存档】
以下时机建议保存一次（/git-save）：
刚开始一个新项目的时候
每个核心功能做完并验证通过的时候
准备做一个大改动之前
一切运行正常你觉得可以交付的时候
保存不花时间，但关键时刻能救命。
【习惯三：简单优先】
功能能用简单方式实现就不要用复杂方式。复杂的代码出 bug 的概率高、修起来更难。
如果嗒啦啦给你的方案看起来特别复杂，你可以问：
「有没有更简单的实现方式？不需要这么多功能，能用就行。」
【习惯四：改一个测一个】
不要让嗒啦啦一次改五个地方。改一个，测一个，没问题再改下一个。
「先修第一个问题，我测试完了再修第二个。」
【习惯五：关键操作要让嗒啦啦加保护】
有些边界情况容易出 bug，提前让嗒啦啦处理：
「如果玩家血量已经满了，吃到血包不应该超过上限。」
「如果背包已经满了，捡到新物品应该提示背包已满，不要直接丢掉。」
「如果玩家连续点击攻击按钮，不应该同时播放多个攻击动画，要等上一个播完。」
提前说这些边界情况，比出了 bug 再修省事得多。
————————————————
常见坑
坑一：只说"有 bug"不说具体现象
嗒啦啦不是通灵师。"有 bug"三个字的信息量是零。哪怕多花二十秒，把你看到的现象写出来，效率提升十倍。
坑二：同时报五个 bug
一次只报一个。嗒啦啦修第一个的时候可能顺带把第二个也修了，也可能引出新问题。一个一个来，修一个确认一个。
坑三：改了又改不保存
嗒啦啦帮你修好了一个复杂的 bug，你开心地继续做下一个功能。结果下一个功能做砸了，想回退却发现没保存过。一切要推翻重来。养成保存习惯。
坑四：问题出在手机端却在电脑上描述
如果 bug 只在手机上出现，一定要说清楚"这个问题只在手机上有，电脑上是正常的"。不然嗒啦啦在电脑上怎么调都复现不了。
坑五：把需求不满意当成 bug
角色跳得不够高不是 bug，是你对数值的期望跟嗒啦啦的默认值不一样。这种情况直接说"把跳跃高度改成 xxx"，不要说"跳跃有 bug"。把需求调整和真正的 bug 区分开来，沟通会清晰很多。
坑六：在不相关的问题上纠缠太久
如果一个小问题修了四五轮还搞不定，而且这个问题不影响游戏核心玩法，考虑先跳过它做别的。等后面主要功能都做完了，再回来解决这个小问题。不要让一个小 bug 卡住整个项目进度。
————————————————
Bug 描述速查表
画面位置不对 →
「___（什么东西）显示在 ___（什么位置），但应该在 ___（正确位置）。」
东西消失了 →
「___（什么东西）在 ___（什么时机）消失了，但它不应该消失。」
操作没反应 →
「我 ___（做了什么操作），但 ___（什么东西）没有任何反应。预期是 ___（应该发生什么）。」
碰撞穿透 →
「___（角色/物体）从 ___（什么方向）穿过了 ___（什么东西），应该被挡住。」
数值异常 →
「___（什么数值）目前是 ___（当前值），但应该是 ___（正确值）。触发条件是 ___（什么操作）。」
流程中断 →
「在 ___（什么阶段）之后，应该进入 ___（下一个阶段），但实际上 ___（发生了什么/什么也没发生）。」
性能问题 →
「在 ___（什么情况下）游戏变得很卡。___（什么平台：手机/电脑）。其他时候是流畅的。」
————————————————
总结
高效修 Bug 的核心就四步：
第一步：用黄金公式描述 —— 操作、现象、期望，三要素缺一不可。
第二步：画面问题截图 —— 一张图顶一百字。
第三步：限定修改范围 —— 防止嗒啦啦改着改着把别的功能弄坏。
第四步：验证后再继续 —— 修完了不验证等于没修。
记住：嗒啦啦修 bug 的能力很强，但前提是你要把问题描述清楚。你的描述越精确，修复就越快。
下次遇到 bug，先别急着打字。花十秒钟想一想黄金公式里的四个空该填什么，然后把截图一起发过去。你会发现，一轮对话就能搞定。