大多数人用 AI 调试的方式是：贴报错 → AI 猜一个方案 → 不行再猜。这是最低效的方式。系统化的 AI 调试应该是：收集证据 → 分析根因 → 验证假设 → 精确修复。
不要让 AI 猜。让它看。
# 让 AI 看错误日志
跑一下 pnpm test src/api/users.test.ts，把完整输出贴出来。
# 让 AI 看最近改动
git log --oneline -10 看看最近改了什么。
git diff HEAD~3 看看最近三次提交改了哪些文件。
# 让 AI 看堆栈
看 src/services/payment.ts 第 78 行附近的代码，
这是堆栈指向的位置。
基于以下证据分析可能的原因：
1. 报错信息：[贴出来]
2. 最近改动：[相关 commit]
3. 相关代码：[文件和行号]
列出 2-3 个最可能的原因，按可能性排序。
不要直接给修复方案。
你认为原因是 [假设]。
怎么验证这个假设？
给我一个最小的验证方案（加个 console.log / 写个测试 / 改个参数）。
根因确认是 [原因]。
现在给出修复方案。
要求：
1. 只改必要的代码
2. 不要顺手重构
3. 加一个测试覆盖这个 case
4. 修完跑一下测试验证
❌ 差：测试挂了帮我修
✅ 好：跑 pnpm test -- --reporter=verbose，
把失败的测试用例和错误信息贴出来。
然后看对应的源码和测试代码，
分析是源码的 bug 还是测试写错了。
线上报错：[错误信息]
影响范围：[哪些用户/功能]
请按以下步骤排查：
1. 看 git log 最近 24 小时的部署
2. 看报错堆栈定位到代码位置
3. 分析是代码 bug、配置问题还是外部依赖问题
4. 给出临时修复方案（快速止血）和根本修复方案
[接口/页面] 响应时间从 200ms 变成了 3s。
排查步骤：
1. 看是不是数据库慢查询（检查 SQL 日志）
2. 看是不是 N+1 查询问题
3. 看是不是外部 API 调用变慢
4. 看是不是最近的代码改动引入了性能回归
用排除法，一个一个确认。
| 反模式 | 为什么不好 | 正确做法 |
|---|---|---|
| 贴报错就让 AI 猜 | AI 的猜测成功率 < 30% | 先收集证据再分析 |
| 一个方案不行换另一个 | 没找到根因就换方案 = 碰运气 | 验证假设，确认根因 |
| 让 AI 改了不测试 | 可能引入新 bug | 改完必须跑测试验证 |
| 同一个 bug 循环 5 次 | 说明方向错了 | 停下来重新分析，换个角度 |