10｜遇到 Bug，怎样一步步找原因、改好和求助？

本章任务：先弄清问题怎样出现，再一段段看它卡在哪里；想清楚再改，改一小步就试一次。
准备材料：出问题的那版代码、专门拿来试的环境、当时的报错和最近改过的地方。
本章产出：别人照着也能看见问题的说明、查到的原因、改完的检查结果；实在查不清，就整理好材料去求助。

先别连续发送“还是不行”

图解：没有新增证据时，先停止扩大修改。 查看大图

Bug 就是程序做错了、没按要求工作的地方。比如取消报名后提示成功，刷新却还是“已通过”。

你把这个现象告诉 AI，它改了页面。你说“还是不行”，它又改保存程序。第三次它想删表重建。现在原来的问题还在，审核也被改坏了。

先停。现在最缺的不是另一个改法，而是：刚才到底发生了什么？

下面就拿“取消后又变回来”这件事，带着你查一遍。没有证据的想法可以先记着，但别一想到就立刻改代码。

第一步：先看要不要停止操作，免得继续出事

如果只是测试页面显示错了，可以慢慢查。如果正在影响真实报名，得先保护已经有的东西。

比如每点一次取消，就多放出一个名额；或者某个账号能看到不该看的名单。不要为了拍十张截图，又重复做十遍。

按事先约好的办法暂停有关操作，告诉甲方目前知道的影响。需要停哪个入口、是否退回旧代码，要在你被允许的范围里处理，拿不准就找懂的人帮忙。

日志是程序运行时留下的记录，比如“20:10 收到取消请求，20:10 保存失败”。先保留这类记录、发生时间和代码版本，不要先清空，免得把找原因的线索一起擦掉。

第二步：写出照着做就能再看见问题的步骤

把问题再做出来，叫“复现”。比如登录、打开一条已通过的报名、点取消、刷新，每次都会变回原状态，这就是能复现。

别只写“取消坏了”。先按下面的样子记录，缺什么再补什么。

要记什么	这次可以这样写
在哪里试	测试地址、代码是哪次保存的、几点发生
开始前是什么样	活动没截止，报名已通过，按规则允许取消
你怎么做的	登录报名端 → 打开记录 → 点取消 → 刷新
应该发生什么	一直显示已取消，并按规则释放一个名额
实际发生什么	先提示成功，刷新又变成已通过
多常出现	试了3次，3次都出现；或者只有快速连点才出现
留下什么	报错原文、时间、截图、有关程序记录

然后少做几步再试。如果不必打开活动列表，直接进报名记录也会出错，就把无关步骤去掉。但不能删掉“报名已通过、还没截止”这些会影响结果的条件。

偶尔才发生，也如实写偶尔。比较成功和失败时哪里不同，不要因为这次没出现，就宣布已经好了。

第三步：沿着数据走的顺序，一段段看

图解：观察、推测与确认原因要分开。 查看大图

数据流就是信息从哪里到哪里。像查快递：先看有没有寄出，再看送到了哪，不能一上来就认定是最后一站丢了。

取消报名大致也是这样：你点按钮，页面发话，处理程序检查并保存，再把结果告诉页面。刷新时，页面又去查一次。

这里“请求”就是页面发出去的话，比如“请取消这条报名”；接收并处理这些话的程序叫“后端”。例如后端检查是否截止，允许才改记录。

你可以让 AI 带你看，但先看事实，别先改：

先看见了什么	接下来查什么
点了按钮，根本没发出请求	页面是不是没执行到那一步，有没有先报错
请求发出，但被拒绝	是没登录、没权限、内容不对，还是确实已经不能取消
对方说成功，保存的记录却没变	保存那一步到底做了没有，失败后是不是还说了成功
记录已经取消，刷新却查出旧结果	查的是不是另一条记录，有没有读到旧副本

数据库就是长期存记录的地方，例如报名状态昨天改了，今天打开还能查到。需要查它时，优先用只查看、不改动的办法，别为了排查直接把数据清空。

还有一种叫缓存的东西，是为更快读取而暂存的副本。比如数据库已经取消，页面却拿到之前保存的“已通过”。这是一种可能原因，要查过才能确定，不是看到旧结果就直接删缓存。

第四步：一次只查一个主要猜测

现在你猜“根本没保存成功”，就先比较取消前后的那条记录。真的没变，再看保存时发生了什么；已经变了，就换方向查查询和显示。

不要同时改页面、换工具版本、清缓存、重写保存。就算这次好了，你也不知道究竟是哪一步起了作用，下次再坏仍然无从下手。

仅作为示例，不建议作为实际项目中的提示词使用。

我已经给出出问题的代码版本、操作步骤、应该怎样和实际怎样，还有隐藏了敏感内容的记录。请先列出真正看见的事实，再列可能原因。先用不改数据的办法查，一次验证一个猜测。告诉我看见什么结果就支持这个猜测，看见什么就该排除。资料不够先问，暂时不要改代码，更不要扩大到换工具版本、重写无关功能。

查出猜错了，不是白忙。你已经少了一个不知道的地方。把“试了什么、结果是什么”记下来，比对着错误猜测连续修改更省事。

第五步：先约好什么时候停，改坏了退到哪里

改之前，先把当前工作保存好，找到最近那份确实能用的代码。也要知道退回去会丢掉哪些新改动，别把没保存的东西一并覆盖了。

代码退回昨天，不会自动把今天的数据改回去。比如错误多放出的名额已经被新报名占了，换回旧代码也不能凭空恢复，需要单独处理数据，不能自己猜着改。

遇到这几种情况，先停：

• 又试了几次，却没有查到任何新东西。
• 本来改一个按钮，现在要改十几个不相关的地方。
• AI 想删数据、重建表，或者修改你没被允许动的环境。
• 你已经说不清每处改动为什么需要。
• 原来好用的功能开始接连出错。

先整理已试过的办法，再决定退回哪份代码、换一种查法，还是找人帮忙。退回去之前也要确认不会盖掉想保留的工作；不要随手把整个数据库恢复成旧备份。

第六步：想清楚再改，改一小步就试一次

原因找到了，再选能解决它的改法。先写一句：为什么这样改，会碰到哪些地方，还有没有更简单的办法。

比如确认“取消已经保存，只是页面没有重新取结果”，就先修这个地方。不要顺手把审核、登录和文件夹结构也一起重做。

改完按原步骤再试。取消后刷新，还显示已取消吗？后台也一样吗？再试本来好用的地方：不允许取消时仍会拒绝吗？连点两次会不会多放出名额？

经常要重复检查的情况，可以写成自动测试，就是让程序替你重复操作并比较结果。比如重复取消两次，名额只能释放一次。先确认这种比较符合规则，再让它自动跑。

如果只是重启后暂时好了，却仍不知道原因，就写“暂时恢复，原因未查清”。不要把碰巧恢复说成已经修好。

第七步：把敏感信息藏好，再带着具体材料求助

图解：把密钥和个人信息遮掉，该留的线索留着。 查看大图

别只发一句“这个怎么修”，或者一张只剩红色报错、看不出前因后果的截图。对方第一次见你的项目，也得先知道你想做什么。

你可以整理成下面这样发过去。这是求助材料的例子，不是给 AI 的提示词：

想做什么：报名截止前，允许取消已通过的报名，取消后释放一个名额。
哪里出错：测试环境。取消时提示成功，刷新却又显示已通过。
怎样看到：用测试账号A登录，打开测试活动B的报名C，点取消后刷新。
出现几次：今天20:10前后试了3次，3次都出现。
本来应该：一直显示已取消，通过人数从30变成29。
最近改过：今天改了取消后更新页面的那一段；附上这次代码差异。
已经查过：请求发出，对方回答成功；保存的状态是否改变还没确认。
已经试过：只重启了一次，没有变化；没有清数据、没有重建表。
附带材料：代码版本、报错原文、对应时间的程序记录、必要截图。
想请你帮忙：先判断该怎样查保存结果，而不是直接重写取消功能。

“脱敏”就是把不能外传的真实信息藏起来。例如密码删掉，真实姓名换成“报名A”，手机号换成虚构号码。密钥就是能访问服务的秘密值，例如接口令牌，也不能一起发。

同一个账号或记录，前后要用同一个替代名字。不然一会儿叫A、一会儿叫B，对方可能以为是两条记录。错误时间、先后顺序和必要的数据格式则要保留，不要删到线索全没了。

私有项目的代码能不能发给对方，也先确认。可以先发上面的简短说明，需要时再提供能重现问题的一小份材料，不必一开始就发整个项目。

练习：取消偶尔失败

假设慢慢点一次没事，快速点两次才出错。分别试这两种情况，记下请求发了几次、状态怎样变、名额变化多少。

页面点完禁用按钮，只能减少手误；处理程序也得应付重复请求。想一想：如果用别的方式发两遍同样的请求，结果还正确吗？

再想一下：退回旧代码后，已经多释放的名额会自己变回来吗？你还需要查什么，才能决定接下来怎么办？

完成检查

• [ ] 知道要不要先暂停有关操作，没为了调查继续造成损失。
• [ ] 操作步骤、正确结果和实际结果已经写清楚。
• [ ] 看见的事实、还在猜的原因、已经确认的原因分开记了。
• [ ] 每次改动都能解释，改完马上试过，也有能退回去的代码。
• [ ] 原来的问题和可能被牵连的功能都试过，没弄清的没有假装完成。

本章带走： 一份能让别人接着查的问题说明，以及查过、改过、试过的记录。暂时解决不了也没关系，留下能用的代码和清楚的求助材料，比继续乱改更有帮助。