调试

这一课你将能做到

1. 用「假设→插桩→复现→分析→修复→验证」的科学调试流程，让 AI 高效参与
2. 写出让 AI 能精准定位 bug 的最小复现和错误描述
3. 区分「AI 能独立修的 bug」和「必须人工介入的 bug」

为什么要学

AI 时代调试的场景变了：以前是你对着代码想「哪里错了」，现在是 AI 生成了一段代码，跑着跑着出问题了，你要判断「是 AI 写错了，还是我的需求描述错了，还是环境/数据的问题」。

人话：AI 把「写代码」的成本降到接近零，但「调试」的成本没变，甚至因为代码不是你写的，理解成本更高了。不会调试的 Vibe Coder，就像不会修车的司机——车是租来的，坏了只能干瞪眼。

真实开发中，AI 辅助调试的最大价值不是「让 AI 替你找 bug」，而是加速「假设→验证」的循环：AI 帮你快速插桩、快速分析日志、快速生成测试用例，把原来半小时的排查压缩到五分钟。

先建立图像

AI 辅助调试的循环：
┌─────────────────────────────────────────┐
│ 1. 假设：AI 帮你列出可能的原因             │
│ 2. 插桩：AI 生成日志/断点/测试代码         │
│ 3. 复现：你跑一遍，拿到现象               │
│ 4. 分析：AI 解读日志，缩小范围             │
│ 5. 修复：AI 生成修复方案                   │
│ 6. 验证：AI 跑测试确认没有回归             │
│    ↓ 如果没修好，回到 1，带着新信息        │
└─────────────────────────────────────────┘

跟着做

步骤 1：给 AI 一个「可调试」的错误描述

假设你的文章列表接口返回空数组，但数据库里有数据。差的描述：

接口返回空，帮我看看

AI 只能瞎猜。好的描述：

现象：GET /articles 返回 { code: 0, data: { records: [], total: 0 } }，但数据库 article 表有 5 条数据。

复现步骤：
1. 启动应用（Spring Boot 3 + MyBatis-Plus）
2. 直接访问 http://localhost:8080/articles
3. 不登录、不带任何参数

相关代码：
[贴 ArticleController.list 和 ArticleService.list]

预期：返回 5 条数据
实际：返回空数组，total 也是 0

已排查：
- 数据库连接正常（其他接口能查到数据）
- 没有报错日志

步骤 2：让 AI 生成「排查清单」

基于以上信息，列出最可能的 5 个原因，按概率排序，每个给出验证方法。

AI 可能会给出：

1. MyBatis-Plus 的 QueryWrapper 条件拼错了 → 打印生成的 SQL
2. 分页参数 page=1, size=10 但插件没注册 → 检查 MybatisPlusConfig
3. 字段映射问题，实体类字段和表字段不匹配 → 检查 @TableField
4. 有全局拦截器/过滤器改了返回 → 检查拦截器链
5. 逻辑删除了，但查询没加 deleted=0 → 检查 @TableLogic

步骤 3：让 AI 生成插桩代码

帮我生成临时日志代码，验证第 1 和第 2 个假设：
1. 打印 MyBatis-Plus 实际执行的 SQL
2. 打印分页插件是否生效

AI 会给你：

// 临时插桩：打印 SQL
Page<Article> page = new Page<>(pageNum, pageSize);
log.info("查询条件: {}", queryWrapper.getSqlSegment());
Page<Article> result = articleMapper.selectPage(page, queryWrapper);
log.info("实际 SQL: {}", page.getSqlSegment()); // 需要配置
log.info("返回总数: {}, 当前页条数: {}", result.getTotal(), result.getRecords().size());