Debug 与修复闭环

Debug 与修复闭环

本节摘要:写代码必然出 Bug,AI 时代也不例外。本节讲解 AI 辅助 Debug 的完整工作流:粘贴错误日志 → 让 AI 分析根因 → 生成修复方案 → 验证修复效果。同时直面 AI Debug 的常见翻车场景(自信地给错误修复、修了 A 坏了 B、对运行时错误束手无策),给出「何时用 AI、何时自己来」的判断标准,以及建立「AI 修 → 你验」信任循环的方法。

一、AI Debug 的标准工作流

四步闭环

第一步:收集错误信息

给 AI 的错误信息越完整,修复越准确。最低要求:

运行 npm run dev 后,浏览器控制台报错:

Uncaught TypeError: Cannot read properties of undefined (reading 'map')
    at TaskList (src/components/TaskList.tsx:23:18)
    at renderWithHooks (react-dom.development.js:16305:18)

相关代码(@src/components/TaskList.tsx 第 20-30 行):
const TaskList = ({ tasks }) => {
  return (
    <div>
      {tasks.map(task => <TaskCard key={task.id} task={task} />)}
    </div>
  );
};

父组件传入:
const { data } = useFetch('/api/tasks');
return <TaskList tasks={data?.tasks} />;

请分析原因并修复。
​

信息清单(能给多少给多少):

• 完整错误消息(不要截断)
• 报错的文件和行号
• 相关代码片段
• 触发条件(什么操作后报错)
• 环境信息(框架版本、Node 版本)

💡 技巧:不要只说「我的代码报错了,帮我看看」。这就像跟医生说「我不舒服」——信息太少,只能得到泛泛而谈的回答。

第二步:让 AI 分析根因

AI 通常会给出:

1. 错误原因(如「data 初始为 undefined,首次渲染时 tasks 为 undefined」)
2. 修复方案(如「加默认值 tasks = [] 或条件渲染」)
3. 可能的关联问题(如「其他组件是否有同样的问题」)

审查 AI 的分析:

• 根因是否合理?(对照代码逻辑验证)
• 修复方案是否治本?(不是简单加 ?. 掩盖问题)
• 有没有副作用?(改了这里会不会影响别处)

第三步:执行修复

简单修复:让 AI 直接改(Agent 模式或 Inline Edit)。

复杂修复:先确认方案,再分步执行:

你的分析正确。修复方案:
1. TaskList 组件加 tasks 默认值 []
2. useFetch 返回的 data 加类型守卫
3. 其他使用 useFetch 的组件做同样处理

请先改第 1 和第 2 点,第 3 点我确认后再做。
​

第四步:验证修复

• 重新运行,确认错误消失
• 测试相关功能是否正常(不只是「不报错了」,还要「功能对了」)
• 跑一遍测试套件(如果有)

二、常见翻车场景与应对

场景一:AI 自信地给出错误修复

表现:AI 非常确定地说「问题在于 X」,但你改了之后错误依旧。

应对:

你上一次的修复没有生效,错误完全相同:
[重新贴错误信息]

请重新分析。这次请:
1. 先列出 3 个可能的原因(从最可能到最不可能)
2. 对每个原因给出验证方法
3. 不要急着给修复方案,先确认根因
​

⚠️ 注意:AI 的「自信程度」跟「正确程度」没有相关性。它用同样的语气说出正确答案和错误答案。永远用「运行结果」而非「AI 的语气」来判断。

场景二:修了 A 坏了 B

表现:原来的错误消失了,但另一个功能不工作了。

应对:

修复了 TaskList 的 undefined 错误后,出现新问题:
任务创建后,列表不再自动刷新(之前是正常的)。

请检查:
1. 你的修复是否影响了 useFetch 的重新请求逻辑?
2. 给出修复方案,确保两个问题都解决。
​

预防:每次修复后,不只测试报错的功能,还要测试「相邻功能」。

场景三:运行时/环境错误

表现:不是代码逻辑错误,而是环境问题(端口占用、权限不足、依赖安装失败)。

Error: listen EADDRINUSE: address already in use :::3000
​

这类问题 AI 通常能给出标准答案(杀进程/换端口),但如果涉及你的具体环境配置(如公司内网代理、特殊环境变量),AI 可能无能为力。

判断标准:如果错误信息是「通用的」(网上能搜到),AI 能帮;如果是「你环境特有的」,优先自己排查或问同事。

场景四:性能问题

表现:功能正常但很慢。

AI 对性能问题的帮助有限,因为:

• 它看不到你的运行时数据(数据量、并发数)
• 它无法 profiling
• 它给的优化建议通常是「教科书式」的,不一定命中你的瓶颈

正确做法:先用工具定位瓶颈(Chrome DevTools / py-spy / EXPLAIN ANALYZE),把具体数据给 AI:

这个 SQL 查询在数据量到 10 万条时从 50ms 涨到 3s:

SELECT * FROM tasks WHERE project_id = 1 ORDER BY "order";

EXPLAIN ANALYZE 结果:
Seq Scan on tasks (cost=0.00..25432.00 rows=50000 width=200)
  Filter: (project_id = 1)

请给出优化方案(加索引?改查询?分页?)。
​

三、何时该放弃 AI 自己排查

💡 技巧:给自己设一个「3 次规则」——同一个问题让 AI 修 3 次还不行,就切换为自己排查。继续让 AI 试只会浪费更多时间,因为它的思路可能从一开始就是错的。

四、建立「AI 修 → 你验」的信任循环

信任是逐步建立的

初期:AI 每改一行,你都跑一遍验证
     ↓ (发现 AI 在简单问题上靠谱)
中期:简单修复(类型错误/拼写错误)直接接受,复杂修复仍验证
     ↓ (积累了「AI 擅长什么」的经验)
成熟:按问题类型决定是否验证——CRUD 类直接过,状态管理/并发类必验
​

记录 AI 的「能力边界」

建议维护一个心理清单(或笔记):

AI 擅长的:

• 语法错误 / 类型错误
• API 用法错误(调用了不存在的方法)
• 简单的逻辑错误(条件写反、off-by-one)
• 配置错误(路径、环境变量)

AI 不擅长的:

• 复杂状态交互(多组件联动的时序问题)
• 性能瓶颈定位
• 安全审计
• 环境特有问题

Debug Prompt 模板

## 错误信息
{完整错误消息}

## 相关代码
{报错文件的关键代码段}

## 上下文
- 触发条件:{什么操作后出现}
- 预期行为:{应该怎样}
- 实际行为:{实际怎样}
- 已尝试:{你/AI 之前试过什么,没生效}

## 要求
1. 分析根因(不要只治标)
2. 给出修复方案(代码)
3. 说明如何验证修复成功
​

本节要点回顾

1. 四步闭环:收集信息 → AI 分析 → 执行修复 → 验证效果,未通过就循环
2. 信息完整度决定修复质量:错误消息 + 代码 + 触发条件 + 环境,越全越准
3. 审查 AI 的分析:自信 ≠ 正确,用运行结果判断,不被语气误导
4. 3 次规则:同一问题 AI 修 3 次不行就自己来,避免越修越乱
5. 分场景信任:简单问题信 AI,复杂问题(并发/性能/安全)自己把关
6. 预防优于修复:每次修复后测试相邻功能,防止「修了 A 坏了 B」

Bug 修完了,项目也基本成型。最后一节,我们跳出具体代码,从全局视角复盘:AI 编程的效率飞轮到底怎么转?