2.5 高效调试心法

---

1. 为什么要学这个?

你可能会遇到这种情况:代码报错了,你把错误信息发给AI,AI改了,还是报错,再发给AI,又改了,还是报错...

想象你去看医生。

• 错误方式:你说"我不舒服",医生随便开药,吃了没用,再换药,还是没用。
• 正确方式:医生先问症状,再做检查,找到病因,对症下药。

关键问题:

• 为什么AI改了代码还是报错?
• 怎么快速定位bug的根本原因?
• 怎么避免陷入无限调试循环?

高效调试的核心是:先诊断,再治疗。

---

2. 核心概念

2.1 调试的三个层次

技术定义:调试分为表面修复、症状处理、根因解决三个层次。

就像看病的三个层次。

• 表面修复:头痛医头,脚痛医脚。快但治标不治本。
• 症状处理:找到症状的直接原因。比如头痛是因为发烧。
• 根因解决:找到根本原因。比如发烧是因为感染。

2.2 AI调试的常见陷阱

技术定义:AI容易陷入"幻觉修复"——看起来在改bug,实际上在瞎改。

就像庸医乱开药。

• 幻觉修复:AI看到报错,随便改一改,看起来很积极,实际上没找到根因。
• 循环修复:改了A导致B报错,改了B导致C报错,永远修不完。
• 过度修复:为了修一个小bug,把整个文件重写了。

graph TD
    A[发现bug] --> B{AI是否理解根因?}
    B -->|理解| C[对症下药]
    C --> D[bug解决]
    
    B -->|不理解| E[幻觉修复]
    E --> F[新的bug]
    F --> E
    
    style A fill:#e1f5ff
    style C fill:#e8f5e9
    style D fill:#e8f5e9
    style E fill:#ffebee
    style F fill:#ffebee

---

3. 高效调试5步法

🔍 Step 1: 复现bug

先确保能稳定复现bug。

# 好的bug报告
"每次点击登录按钮,控制台就报错:TypeError: Cannot read property 'email' of undefined"

# 不好的bug报告
"登录好像有问题"

📋 Step 2: 收集完整信息

把所有相关信息都给AI。

# 必须提供的信息
1. 完整的错误信息(不要截断)
2. 出错的文件和行号
3. 触发bug的操作步骤
4. 相关的代码片段(不要粘贴整个文件)

# 示例
"@LoginButton.tsx 第23行报错:
TypeError: Cannot read property 'email' of undefined
at handleLogin (LoginButton.tsx:23)

触发步骤:点击登录按钮
相关代码:第20-30行"

🎯 Step 3: 让AI诊断根因

不要直接让AI改代码,先让它分析。

# ❌ 不要这样
"帮我修复这个bug"

# ✅ 应该这样
"分析一下这个错误的根本原因是什么,不要直接给代码"

💊 Step 4: 确认方案后再执行

AI给出方案后,先确认理解正确。

# AI的诊断
"根因是user对象可能为null,需要添加空值检查"

# 你的确认
"明白了,那就在访问user.email前先检查user是否存在。执行修复。"

✅ Step 5: 验证修复

改完后必须测试,确保没有引入新bug。

# 验证清单
1. 原bug是否解决?
2. 有没有新的报错?
3. 相关功能是否正常?

---

4. 避坑指南

❌ 不要这样做	✅ 应该这样做	为什么
只发"报错了"	发完整错误信息+触发步骤	AI需要足够信息才能诊断
直接让AI改代码	先让AI分析根因	避免幻觉修复
粘贴整个文件	只粘贴相关代码片段	减少Token消耗,提高准确度
AI改一次就信了	改完后必须测试验证	AI可能引入新bug
陷入循环后继续改	重新开始,换个思路	循环修复只会越改越乱

---

5. 真实案例

---

6. 本章小结

1. 🔍 先诊断再治疗:不要直接让AI改代码,先让它分析根因
2. 📋 提供完整信息:错误信息+触发步骤+相关代码
3. 🎯 避免幻觉修复:AI改了3次还没解决,立刻停下来重新审视
4. ✅ 必须验证:改完后测试,确保没有引入新bug
5. 🔄 跳出循环:陷入循环修复时,重新开始,换个思路