和 AI 一起修 Bug 心得体会

几天前，我在和 AI 协作写代码时，遇到一个很小的 Bug：一个函数总是返回 null。于是我心想：交给 AI 修一下吧。

---

场景一：错误的修复方式

我：
“AI，帮我修一下这个函数，它总是返回 null。”

AI：
“经过分析，可能是因为你没有正确初始化对象。我帮你加上对象检查逻辑，增加一个 fallback，还顺便优化了类型判断。”

接着，AI啪啦啪啦输出了一大堆修改：新加了三个 if 判断，封装了一个工具函数，还顺带调整了数据结构。

Bug 的确没了。可我盯着这份改动后的代码，内心却很复杂：

• 文件行数膨胀了 30%
• 新逻辑我也没完全理解
• 真正问题还是没搞清楚

就这样，Bug 是修掉了，但我的项目默默朝着“屎山”方向迈进了一步。

---

场景二：外科手术式修复（真实版）

这次我决定换个思路，尽量让 AI 聚焦在问题根源。

我：
“AI，为什么会返回 null？请先告诉我最可能的根因，不要直接给我大段修改。”

AI：
“可能是数据库返回空值，因为你查询的条件不完整。我建议加一个默认值处理逻辑。”

我一看，觉得不太对劲。于是继续追问：
“等等，你确定是数据库条件问题吗？你能给我更具体的证据吗，比如哪一行代码导致了条件不成立？”

AI：
“嗯，你调用时传的 uesrId 参数拼写错误，所以数据库根本查不到结果。”

这一刻，才终于拨云见日。真正的问题只是一个拼写错误：uesrId → userId。

整个过程来来回回拉扯了五六轮，我甚至几次在心里暗骂：
“你丫的分析怎么老跑偏啊？”
“这不就是瞎扯么，根本说不通！”

可正是这种拉锯，让我始终保持清醒，逼着自己去思考到底哪部分靠谱、哪部分值得怀疑。虽然过程痛苦，但最后收获的是对问题本质的理解，而不是一坨看不懂的新代码。

---

错误 vs 正确的对比

场景	过程	结果	隐患
错误修复	AI 输出大量修改：增加 if 判断、工具函数、数据结构改动	Bug 消失	代码臃肿，团队难以维护，根因未解决
正确修复（真实）	多轮拉锯，AI 先跑偏 → 我质疑 → AI 解释 → 再次追问，最终找到拼写错误	改动几个字母	精准高效，理解问题本质，虽然过程痛苦，但学习到更多

---

提示词示例

错误提示词（Bad Prompt）：

帮我修复这个函数的 bug

（AI 可能会直接输出一大堆修改，结果虽然能跑，但你完全不知道问题根因。）

正确提示词（Good Prompt）：

不要直接修改代码，请先分析返回 null 的根本原因，并指出具体是哪一行可能导致了这个问题。  
如果你的结论不够确定，请告诉我你有哪些假设。  

（这种方式会逼 AI 给出推理依据，而不是立刻给“补丁方案”。）

---

修 Bug 的核心原则

从这次经历，我提炼出三个协作原则：

• Root Cause Analysis（根因分析）
  不停追问“为什么”，直到找到真正的源头。
• Surgical Fix（外科手术式修复）
  改动要精准，别让一个小 Bug 变成大翻修。
• Avoid Patch Work（避免打补丁）
  抵制“堆代码解决一切”的诱惑。

AI 协作编程是未来趋势，但人类工程师不能沦为“AI 打补丁机器”的奴隶。正确的姿势是：让 AI 成为放大镜，帮我们找到问题的源头；而不是变成铲子，把代码越堆越厚。

最终，修 Bug 不只是为了跑通代码，更是一个学习和成长的过程。
优雅的代码，是人和 AI 合作共赢的产物。