几天前，我在和 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 合作共赢的产物。