报名表单显示”提交成功”，后台却只收到一半人。

前面四篇，我们把排错的各个招式拆开讲了：贴报错、找逻辑错、查性能、读老代码。这一篇不教新招式，而是从头到尾还原一个真实的 Bug——让你看清楚一个问题从”完全懵”到”彻底解决”，中间到底发生了什么。

因为很多人的问题不是不会某一招，而是——

手上有一堆锤子，但不知道先抡哪个。

咱们开始。

一、事故现场

背景：你用 AI 工具做了一个小站，功能很简单——一个活动报名表单。

用户填四个框：姓名、手机号、公司、备注。点提交，页面弹出”报名成功”，后台管理页能看到报名名单。上线三天一切正常，第四天活动负责人找过来，脸不太好看：

“有人跟我说他报名了，可名单里没有他。你查一下。”

你打开后台名单，数了数：87 条。

活动群里的人数：112 人。

你心里咯噔一下。

这就是最难受的一类 Bug：

• 页面没有报错
• 用户看到的是成功
• 数据确实丢了
• 而且不是全丢，是丢了一部分

新手这时候最常见的反应是两种，两种都是错的：

1. “是不是服务器不稳定？” —— 把锅甩给玄学，然后什么都不做。
2. 直接打开代码，从提交那一段开始一行行看。 —— 大海捞针，看两小时也看不出来。

二、第一步：复现——把”听说”变成”我看到了”

排错的第一步永远不是改代码，而是：你自己让 Bug 再发生一次。 为什么？因为你亲眼看到之前，手上的信息全是二手的：用户说”我提交了”可能没点按钮，说”显示成功”可能记错了，你以为丢的 25 条也可能有人压根没报名。

没复现之前，你连”有没有 Bug”都不确定，改什么？

复现要抓三个要素：

于是你去群里问了一句：”哪几位报名后没在名单里的，麻烦举个手，告诉我你填的内容。”

三个人回复了。你拿到三份填写内容。

你自己照着填了一遍第一个人的内容——提交成功，名单里出现了。

咦？没复现出来。

这时候千万别放弃。 换第二个人的内容，再填一遍——

页面显示”报名成功”，名单里没有。

复现了。

这一刻你赢了一半——手里有了两个宝贝：一个必然失败的例子、一个必然成功的例子。

三、第二步：差异法——偶发不是玄学

只有一部分人丢单，说明不是所有情况都出问题。

那必然存在一个条件变量：满足它就挂，不满足就好。

找它的方法叫差异法：

把”成功的那次”和”失败的那次”摆在一起，一栏一栏比，看差在哪。

你把两份填写内容并排贴出来：

看到没有——备注字段的长度差了几十倍，这就是最可疑的条件变量。

把这份对比丢给 AI，它能帮范围收得更窄。注意：别问”为什么丢数据”，要问”这两组差异可能触发什么问题”。

我的表单有偶发丢数据的问题。同样的代码，有的提交成功并入库，有的
显示成功但库里没有。

我找到了一组对照：
【成功的一次】姓名：张伟 / 手机：138xxxxxxxx / 公司：甲科技 / 备注：（空）
【失败的一次】姓名：李娜 / 手机：139xxxxxxxx / 公司：乙传媒 / 备注：（约240字的中文长文本）

请你：
1. 指出这两组数据最值得怀疑的差异点（按可疑程度排序）
2. 针对最可疑的那一点，列出 3~5 个可能的技术原因
3. 每个原因给我一个"我怎么快速验证它是不是真凶"的动作
4. 先不要改代码

我是新手，请用大白话解释。

AI 给了你一串可能：字段长度限制、编码问题、数据库字段类型太短、校验规则拦截、请求体大小限制……

注意：这些都还只是猜测。下一步是验证，不是相信。

四、第三步：划界——判断到底在哪一段断的

一个表单提交，数据要走四段路：

浏览器 → 网络请求 → 后端处理 → 数据库写入

你现在的任务不是找出哪行代码错了，而是先确定：数据是在哪一段路上掉的。

这一步叫四段划界法，做法很朴素——每一段路口都装个”摄像头”：

第 1 段：浏览器有没有把数据组装对？

按 F12 打开开发者工具（Windows 按 F12，Mac 按 Command+Option+I），切到 Network（网络） 标签，然后提交那份会失败的内容。

你会看到列表里多出一条请求。点进去看 Payload / 请求负载，那里显示的就是浏览器实际发出去的内容。

结果：四个字段都在，备注那 240 字也完整。

→ 第 1 段没问题，排除前端组装。

第 2 段：请求有没有到后端？

同一个面板里看这条请求的 Status（状态码）：

显示 200。

→ 通了，第 2 段没问题。

第 3 段：后端处理有没有出错？

这一段看不见，需要日志。翻到刚才那个时间点的后端输出——居然有一行红字，服务没挂还在跑。

→ 抓到了。问题在第 3 段。

第 4 段：数据库——不用查了，第 3 段就断了，压根没走到第 4 段。

这一步的价值：范围缩小了 90%。 你原本要在几百行代码里找，现在锁定在”后端保存那一小段”里找。

五、第四步：取证——把真凭实据交给 AI

现在你有日志了。这时候才轮到把东西贴给 AI。

记住前面第 71 篇讲过的铁律：报错贴原文，一个字都别转述。

我的表单提交接口出现问题：接口返回 200 和"成功"，但数据没有写进
数据库。后端日志里有一段异常，但服务没有崩溃。

【后端日志原文】
[把那一段红字完整粘贴，包含前后各几行]

【接口对应的完整代码文件】
[粘贴整个文件，不要只贴片段]

【触发条件】
备注字段填约 240 字时必现；备注为空时正常。

请你回答：
1. 这段日志说的是什么问题（用大白话）
2. 为什么出了异常，接口还会返回成功给前端
3. 定位到具体是哪一行引发的
4. 先解释，暂时不要给我改好的代码

我是新手，请一步步说清楚。

AI 的回答让你恍然大悟，真相有两层：

第一层：为什么数据会丢？

保存前有一段校验：备注不能超过 200 字，超了就抛异常——李娜写了 240 字，被拦下。

第二层（更关键）：为什么页面还显示成功？

代码里有一段”捕获异常但什么也不做“的写法——出错了，它把错误吞掉，然后继续往下走，最后照常返回了”成功”。

用大白话说就是：

快递员把包裹弄丢了，但还是给你发了”已签收”的短信。

这就是假成功——页面上的”成功”，只代表”程序跑完了”，不代表”事情办成了”。

六、第五步：修——只改一处，别顺手重写

到这一步，很多人会犯一个错：让 AI “帮我把这个文件优化一下”。

千万别。 你现在只搞明白了一个问题，一次只解决一个。

而且这次的修法要分两层，因为真凶其实有两个：

• 表面凶手：备注超 200 字被拦
• 幕后黑手：异常被吞掉，导致失败伪装成成功

只修表面凶手（把 200 放宽到 1000）是治标——下次换个别的原因失败，你照样收到”成功”、照样丢单。

两个都要修：

现在我明白问题了，请帮我修，但请严格遵守：

1. 只修下面这两处，其他代码一律不要动，不要顺手优化、不要改格式
   （a）备注字段的长度上限，从 200 放宽到 1000
   （b）不要再静默吞掉异常：出错时必须记录日志，并且给前端返回失败，
       不能再返回成功

2. 返回给前端的失败提示要写给普通用户看，比如"备注最多 1000 字"，
   不要把技术错误原文丢给用户

3. 输出改动后的完整文件，不要给片段

4. 在文件外面单独告诉我：你一共改了哪几行、每行改了什么、
   为什么这么改

我是新手，请顺便说明我改完之后应该怎么验证。

这段提示词里有四个”新手保命条款”：

• 只改这两处，其他别动 —— 防止 AI 顺手重写导致新 Bug
• 输出完整文件 —— 防止你不知道片段该贴在哪
• 列出改了哪几行 —— 让你看得懂它动了什么
• 告诉我怎么验证 —— 修完不是终点

七、第六步：回归验证——三条必测

改完立刻测，而且必须测三条，一条都不能少：

第三条最重要。

因为它验证的不是这一个 Bug，而是”以后再出问题，你能不能第一时间发现”。

三条全过，才算修完。

然后你回群里补一句：”报过名但不在名单里的朋友，麻烦重新提交一次。”

——87 条变成了 110 条。

八、第七步：复盘——让这次经验值钱

Bug 修完，还剩最后一件事，也是最多人跳过的一件事：

问一句：同样的坑，项目里还有几个？

我刚修好一个问题：某处校验失败抛出异常，但异常被静默吞掉，
导致接口仍然返回成功，数据其实没保存。

【项目里其他几个接口的代码】
[粘贴其他接口文件]

请你帮我检查：
1. 还有哪些地方存在"吞掉异常后照常返回成功"的写法？逐个指出行号
2. 还有哪些地方"前端提示成功"和"实际结果"可能不一致？
3. 按危险程度排序，告诉我哪个最该先改
4. 给我一条简单的自查规则，以后写代码时怎么避免这类问题

先列清单，不要改代码。

AI 一查——另外两个接口也有同样的写法。

你顺手把它们也修了。

这就是复盘的价值：修一个 Bug 只值一次，找到这类 Bug 的规律值一辈子。

九、把这次流程压成八个字

回头看整个过程，其实是固定的八步：

复现 → 划界 → 差异 → 取证 → 假设 → 修复 → 回归 → 复盘

口诀记法：现界差证，设修归盘。

新手和熟手的差距，八成不在第六步”修复”，而在第一步和最后两步。

十、这一篇最该记住的三句话

第一句：没复现之前，你查的是传说，不是 Bug。

第二句：先划界，再看代码。范围没缩小之前看代码，等于大海捞针。

第三句：页面上的”成功”，只代表程序跑完了，不代表事情办成了。

最后再补一条心态上的：

Bug 不丢人，查不出来也不丢人。丢人的是每次都从零开始瞎撞。

你今天走完这八步，下次再遇到”数据莫名丢了”“偶尔才出错”这类问题，会发现流程一模一样。

📦 提示词模板盒子

模板一：对照找条件变量（偶发问题必用）

我遇到一个偶发问题：同样的操作，有时候正常，有时候不正常。

【现象】
正常时：[描述]
不正常时：[描述]

【我找到的一组对照】
成功的一次输入：[逐字段列出]
失败的一次输入：[逐字段列出]

请你：
1. 按可疑程度排序，指出这两组数据最值得怀疑的差异点
2. 针对最可疑的那一点，列出 3~5 个可能的技术原因
3. 每个原因给我一个"怎么快速验证它是不是真凶"的动作
4. 先不要改代码

我是新手，请用大白话解释。

模板二：四段划界（判断在哪一段断的）

我的功能出问题了：[描述现象]。

我想先确定数据是在哪一段丢的，一共四段：
浏览器 → 网络请求 → 后端处理 → 数据库

请你针对我这个功能，给我一份逐段排查指引：
1. 每一段我具体该看哪里（说清楚点哪个菜单、看哪个字段）
2. 每一段"正常"应该长什么样，"异常"长什么样
3. 按从易到难排序，我先查哪一段最省事

我完全没用过开发者工具，请把点击步骤写细一点。

模板三：取证提问（拿到日志后）

我的功能出现问题：[一句话现象]。

【日志/报错原文】
[完整粘贴，前后各多贴几行，不要转述、不要截断]

【相关的完整代码文件】
[粘贴整个文件]

【触发条件】
[什么情况下必现，什么情况下正常]

请你回答：
1. 这段日志说的是什么问题（大白话）
2. 为什么会出现"表面成功、实际失败"（如适用）
3. 定位到具体是哪一行引发的
4. 先解释，暂时不要给我改好的代码

我是新手，请一步步说清楚。

▸ 外科手术式修复：让 AI 只改指定几处、输出完整文件、列出改了哪几行；并要求出错时记录日志、向用户返回失败而非静默吞掉（原模板四）。 ▸ 回归验证清单：改完让 AI 列三类验证——原来失败的、原来正常的、极端的，每条写清操作与期望（原模板五）。 ▸ 复盘扫雷：修好后让 AI 在其它文件里找同类问题、按危险排序，并给一条自查规则（原模板六）。

🔖 速查卡：排错八步

1. 复现 —— 自己看到才算数，拿到"必失败"和"必成功"两个例子
2. 划界 —— 浏览器 / 网络 / 后端 / 数据库，先确定断在哪一段
3. 差异 —— 成功与失败逐字段对比，找出那个条件变量
4. 取证 —— 贴日志原文 + 完整文件，不转述、不截断
5. 假设 —— 让 AI 列可能性清单，你负责逐个验证
6. 修复 —— 只改一处，输出完整文件，要它列出改了哪几行
7. 回归 —— 三条必测：修好的 / 原本好的 / 极端的
8. 复盘 —— 同类问题还有几个，顺手一起扫掉

👉 下篇预告

第 76 篇《调试类小结——把排错思路彻底沉淀下来》。 下一篇把 71~75 这五篇收口，交给你三样东西：一张排错总决策树、一套万能排错提示词母版、一份新手八大误区清单。看完那篇，你手上就有一套完整的”AI 排错工具箱”了。 我们下篇见。