传统调试：读报错 → 猜原因 → 加 console.log → 重新运行 → 再猜。 Claude Code 调试：把报错粘贴过去。 它会读源码、分析堆栈、定位根因、提出修复方案，甚至直接帮你改好再验证。

基础用法

# 最简单: 直接粘贴报错信息
> 运行 npm start 报了这个错:
TypeError: Cannot read properties of undefined (reading 'map')
    at UserList (/src/components/UserList.tsx:23:18)
    at renderWithHooks (/node_modules/react-dom/...)

# Claude 会:
# 1. 读 src/components/UserList.tsx 第 23 行
# 2. 分析为什么 .map() 的对象是 undefined
# 3. 提出修复方案 (可能是初始值或空值检查)
# 4. 直接用 Edit 工具修复

# 带上下文的诊断
> 用户登录后跳转到 /dashboard 页面报 403，但管理员账号正常
> 帮我看看 src/middleware/auth.ts 是不是权限检查有问题

# 让 Claude 运行命令复现
> 运行 pytest tests/test_api.py 看看哪些测试挂了，帮我修

Claude 的诊断流程

不同错误类型的调试技巧

让 Claude 生成测试是它最可靠的能力之一—— 因为测试有明确的对错标准：运行通过或不通过。 Claude 会读你的代码，自动选择正确的测试框架， 生成覆盖正例、边界和异常的测试用例。

基础用法

# 为一个函数生成测试
> 为 src/utils/formatDate.ts 写单元测试
# Claude 会:
# 1. Read formatDate.ts 理解函数签名和逻辑
# 2. 检查项目已有的测试文件了解框架 (Jest? Vitest? Mocha?)
# 3. 生成测试文件 src/utils/__tests__/formatDate.test.ts
# 4. 包含正例、边界值、无效输入等 case

# 为整个模块生成测试
> 为 src/services/auth/ 目录下所有公共函数写测试

# 为 API 端点生成集成测试
> 为 POST /api/users 端点写集成测试，覆盖成功创建、
> 重复邮箱、缺少必填字段三种场景

# 补充现有测试的覆盖面
> 看一下 tests/test_cart.py 还缺哪些边界场景，补上

Claude 生成测试的特点

进阶: 指定测试策略

# 指定你想要的测试粒度
> 为 calculateDiscount 函数写测试，要求:
> 1. 每个分支路径至少一个 case
> 2. 测试折扣百分比为 0、50、100 的边界
> 3. 负数价格要抛出 Error
> 4. 不要 mock 数据库，用真实连接

# 在 CLAUDE.md 中定义测试规范
# 这样每次生成测试都会遵循:
## 测试规范
- 使用 Vitest 作为测试框架
- 测试文件放在 src/__tests__/ 目录
- 命名格式: {module}.test.ts
- 每个测试用 describe/it 组织
- 数据库测试用真实连接，不要 mock
- API 测试使用 supertest

Test-Driven Development 与 Claude Code 是天然的好搭档—— 你用自然语言描述你想要什么行为， Claude 把它翻译成测试用例，然后写代码让测试通过。 测试成了你和 Claude 之间的"验收合同"。

TDD 三步曲

用 Claude 做 TDD 的示例

# Step 1: Red — 先描述需求，让 Claude 写测试
> 我要实现一个 parseCSV 函数，要求:
> - 输入: CSV 字符串
> - 输出: 对象数组，第一行作为 key
> - 支持引号内的逗号
> - 空字符串返回空数组
> 先只写测试，不要写实现
# Claude 生成 parseCSV.test.ts，运行后全部 FAIL ✓

# Step 2: Green — 让 Claude 写实现
> 现在实现 parseCSV 函数，让所有测试通过
# Claude 写 parseCSV.ts，运行测试直到全部 PASS ✓

# Step 3: Refactor — 让 Claude 重构
> 重构一下 parseCSV，确保测试仍然通过
# Claude 优化代码结构，每次改动后重跑测试 ✓

# 迭代: 追加需求
> parseCSV 还需要支持自定义分隔符
> 先加测试 case，再改实现

Claude Code 不只是生成测试——它能运行测试并智能解读结果。 测试失败了？Claude 会分析失败原因，区分是代码 Bug 还是测试写错了， 然后帮你修复正确的那一方。

基础用法

# 让 Claude 运行测试
> 跑一下测试
# Claude 会自动识别项目的测试命令:
# - npm test / npx vitest / npx jest
# - pytest / python -m pytest
# - go test ./...
# - cargo test

# 运行特定测试文件
> 只跑 tests/test_auth.py

# 运行单个测试 case
> 只跑 test_login_with_expired_token 这个测试

# 运行并修复失败
> 跑测试，失败的帮我修掉
# Claude 会: 运行 → 分析失败 → 修复 → 重跑 → 直到全部通过

失败分析的智能判断

覆盖率分析

# 让 Claude 检查测试覆盖率
> 跑一下带覆盖率的测试，告诉我哪些函数没有被覆盖

# Claude 会:
# 1. 运行 npx vitest --coverage 或 pytest --cov
# 2. 解读覆盖率报告
# 3. 指出未覆盖的文件/函数/分支
# 4. 如果你让它补，它会针对性地生成缺失的测试

> 覆盖率低于 80% 的文件，帮我补测试

超越"粘贴报错"——这些进阶模式让你把 Claude 用成一个 更聪明的调试搭档， 处理那些没有明确报错信息的棘手问题。

场景化调试模式

# 1. 日志分析: 让 Claude 分析日志找线索
> 这是最近 100 行生产日志，找出有没有异常模式
> (粘贴日志)

# 2. 二分法定位: 让 Claude 帮你缩小范围
> 这个 Bug 在 v2.3 之后出现的，帮我用 git bisect 定位
> 是哪个 commit 引入的

# 3. 性能调试: 分析慢查询或慢接口
> /api/users 接口平均响应 3 秒，帮我看看是哪里慢
> 检查一下有没有 N+1 查询问题

# 4. 并发 / 竞态问题
> 这个接口偶尔返回错误数据，怀疑有竞态条件
> 帮我分析 src/services/orderService.ts 的并发安全性

# 5. 内存泄漏排查
> Node 进程内存持续增长，帮我检查有没有事件监听器泄漏
> 或者没有正确释放的资源

调试心法对照表

今天的练习围绕调试和测试。你可以在任何有代码的项目中操作—— 如果手边没有合适的项目，可以创建一个小项目来练习。

Lab 1 — 错误诊断体验

人为制造一个 Bug，让 Claude 帮你找到并修复。

# 准备: 在你的项目中故意引入一个 Bug
# 比如把一个变量名拼错，或者删掉一个必要的 null 检查

# 然后运行代码触发报错
$ npm start  # 或你项目的运行命令

# 把报错信息给 Claude
$ claude
> 运行报了这个错: (粘贴报错)
> 帮我找到原因并修复

# 观察:
# 1. Claude 是否正确定位了你故意引入的 Bug？
# 2. 它的修复方案是否合理？
# 3. 它是否验证了修复（重新运行）？

Lab 2 — 测试生成

选一个你项目中没有测试的函数，让 Claude 生成测试。

# 选一个没有测试覆盖的函数
> 为 src/utils/validate.ts 中的 validateEmail 函数写单元测试

# 运行生成的测试
> 跑一下刚才写的测试

# 如果有失败，让 Claude 分析
> 这两个测试失败了，是代码 Bug 还是测试写错了？

# 补充边界场景
> 还有哪些边界没覆盖？比如超长邮箱、Unicode 字符

Lab 3 — TDD 迷你实践

用 TDD 模式实现一个小功能——体验 Red → Green → Refactor 循环。

# 选一个小功能来 TDD，比如一个密码强度检查器
> 我要实现一个 checkPasswordStrength 函数:
> - 返回 weak / medium / strong
> - 8位以下 = weak
> - 有大小写 + 数字 = medium
> - 再加特殊字符 = strong
> 先只写测试，不要写实现

# 确认测试都 FAIL (这是正确的!)
> 跑一下测试，确认都失败了

# 让 Claude 实现
> 现在写 checkPasswordStrength 让测试通过

# 追加需求
> 还要检查密码中不能包含用户名
> 先加测试 case，再改实现

Lab 4 — 修复并验证

让 Claude 完成一个完整的"修 Bug + 写回归测试"循环。

# 如果你的项目有已知的 Bug 或 TODO
> 修一下 issue #12 的 Bug，然后写一个回归测试
> 确保测试跑过

# 或者让 Claude 找 Bug
> 跑一下所有测试，失败的帮我修掉
> 修完之后确保所有测试都通过

# 观察 Claude 的闭环:
# 运行测试 → 发现失败 → 分析原因 → 修复 → 重跑 → 全部通过

1. Claude 的调试闭环有哪几个步骤？为什么"验证"这一步不可省略？
2. 给 Claude 调试信息时，三样最重要的东西是什么？对比"它不工作了"和"用户登录后跳转 /dashboard 返回 403"的效果差异。
3. Claude 生成测试时会自动适配哪些东西？如果它选错了框架，你怎么纠正？
4. 描述 TDD 的 Red → Green → Refactor 循环。为什么说 "测试是你和 Claude 的合同"？
5. 测试失败时，Claude 需要判断"修代码还是修测试"——它的默认逻辑是什么？你怎么覆盖这个判断？