ShiBin's Wiki

Appearance

Published at:

第 22 章：场景三：大规模重构 ​

在上一章中，我们用 Claude Code 从零搭建了一个新功能——那是"在白纸上画画"。本章要面对的场景恰恰相反：你有一个已经运行了两年的前端项目，15 个页面组件，每个组件里都散落着重复的 API 调用和日期格式化代码，整个项目还停留在 JavaScript 时代。

这是 Claude Code 真正大放异彩的场景——大规模重构。这类任务的特点是：改动范围广、文件数量多、但逻辑本身并不复杂。对人来说，这是体力活（在 15 个文件里重复做同样的事）；对 Claude 来说，这是它最擅长的领域——批量、精确、不疲倦地执行重复性变更。

本章目标：掌握使用 Claude Code 进行大规模重构的完整方法论——从评估规划到分步执行，从增量验证到安全保障，建立"小步快跑、每步验证"的重构节奏。

22.1 场景描述 ​

假设你接手了一个前端管理后台项目，基本情况如下：

项目规模：
  - 15 个页面组件（src/pages/）
  - 8 个通用组件（src/components/）
  - 全部使用 JavaScript（.jsx），没有类型标注
  - 使用 axios 进行 API 调用

当前痛点：
  1. 每个页面组件里都内联了 axios 调用逻辑（baseURL 重复配置、拦截器重复定义、错误处理各写各的）
  2. src/components/ 里有 3 个组件各自实现了日期格式化（moment 版本不一致、格式不统一）
  3. 项目计划从 JavaScript 逐步迁移到 TypeScript
  4. 缺乏单元测试，重构风险高

这不是一个虚构的场景——当项目从"快速迭代期"进入"长期维护期"，这类技术债务几乎是必然的。好消息是：Claude Code 处理这类问题有着天然的优势——它能同时看到全部 15 个文件，理解每个文件里的重复模式，并以一致的方式批量修改。

22.2 Step 1：评估与规划 ​

不要让 Claude 直接开改 ​

很多人在面对重构任务时的第一反应是直接下指令："帮我把所有组件里的 axios 调用提取出来"。这种一步到位的指令有三个风险：

  1. 范围不可控：Claude 可能改了你不希望改的文件，或者漏掉了应该改的文件
  2. 方向可能偏：你心里想的方案和 Claude 理解的方案可能完全不同
  3. 回滚代价大：如果改了 12 个文件后发现方向错了，回滚和重来的成本都很高

正确的做法是先让 Claude 做一次全面的项目分析。

让 Claude 分析项目当前的问题 ​

用 Plan mode（详见第 9 章）发出第一条指令：

分析当前项目的代码，找出以下问题并给出重构方案：
1. API 调用散落在哪些文件中？列出了哪些重复的 baseURL 配置和拦截器？
2. 日期格式化的重复代码在哪些文件中？格式化方式有哪些不统一的地方？
3. 有哪些 .jsx 文件需要优先迁移到 TypeScript？（按复杂度排序）
4. 给出分阶段的重构计划：每个阶段改哪些文件，预期风险是什么？

Claude 收到这个指令后，会执行的步骤：

1. [Grep] 搜索所有包含 "axios" 的文件
2. [Grep] 搜索所有包含 "moment" / "format" / "formatDate" 的文件
3. [Glob] 列出所有 .jsx 文件及其行数
4. [Read] 读取每个匹配文件，分析具体实现
5. 输出分析报告

Claude 输出的分析报告示例 ​

一份好的 AI 分析报告应该是可操作的——不只是列出问题，而是给出具体的行动方案：

📊 项目重构分析报告

一、API 调用散落情况
─────────────────────────────
扫描到 12 个文件包含 axios 调用：

重复的 baseURL 配置（5 处）：
  - src/pages/UserList.jsx:3 — baseURL: 'https://api.example.com'
  - src/pages/ProductList.jsx:4 — baseURL: 'https://api.example.com'
  - src/pages/OrderList.jsx:3 — baseURL: 'https://api.example.com'
  - src/pages/Dashboard.jsx:5 — baseURL: 'https://api.example.com/v1'（不一致！）
  - src/pages/Settings.jsx:4 — baseURL: 'https://api.example.com'

重复的请求拦截器（4 处）：
  - 4 个文件各自定义了 token 附加逻辑，实现完全相同
  - 2 个文件各自定义了 401 处理逻辑，但重定向路径不同

重复的错误处理（6 处）：
  - 6 个文件中各自写了 try-catch + message.error() 模式

二、日期格式化重复代码
─────────────────────────────
扫描到 3 个文件有日期格式化：

  - src/components/UserTable.jsx：moment(date).format('YYYY-MM-DD HH:mm:ss')
  - src/components/OrderTable.jsx：dayjs(date).format('YYYY/MM/DD HH:mm')（格式不同！分隔符不同！）
  - src/components/LogList.jsx：moment(date).format('YYYY年MM月DD日')（中文格式！）

问题：
  - 使用了两个不同的日期库（moment 和 dayjs）
  - 三种不同的格式字符串
  - moment 已进入维护模式，建议统一迁移到 dayjs

三、JS → TS 迁移优先级
─────────────────────────────
按复杂度排序的 .jsx 文件：

优先级 高（复杂度低，适合第一批迁移）：
  1. src/pages/Login.jsx（120 行，逻辑简单，无外部依赖类型）
  2. src/pages/Settings.jsx（85 行，纯表单，PropTypes 完整）
  3. src/components/Loading.jsx（30 行，无 Props）

优先级 中：
  4. src/pages/UserList.jsx（200 行，有表格和分页）
  5. src/pages/ProductList.jsx（180 行，有搜索和筛选）
  ...（共 8 个）

优先级 低（复杂度高，最后迁移）：
  12. src/pages/Dashboard.jsx（350 行，多个 chart 库引用）
  ...（共 4 个）

四、建议的重构计划
─────────────────────────────

阶段 1：提取公共工具函数（风险：低）
  目标：消除日期格式化重复
  文件：创建 1 个新文件，修改 3 个组件
  时间：约 10 分钟

阶段 2：提取 API 层（风险：中）
  目标：创建统一的 API 客户端和模块化接口
  文件：创建 4 个新文件，修改 12 个页面组件
  时间：约 25 分钟
  风险提示：需确保所有 API 路径映射正确，建议按模块分批修改

阶段 3：JS → TS 迁移（风险：中）
  目标：按优先级逐文件迁移
  文件：每迁移一个文件验证一次
  时间：每个文件约 5-15 分钟（取决于复杂度）

建议执行顺序：阶段 1 → 阶段 2 → 阶段 3
（阶段 1 最简单最快，可以建立信心和验证工作流）

审阅计划的关键问题 ​

拿到 Claude 的分析报告后，不要立即说"执行"。花几分钟过一遍这三个问题：

审阅维度问题本章案例的答案
范围改动的文件列表是否合理？Dashboard 的 baseURL 末尾多了 /v1——这是故意的还是配置错误？需要确认
方向技术方案的选择对吗？dayjs 替代 moment 是合理的（体积小 97%），但需要确认 team 是否有其他偏好
风险最大的风险点在哪？阶段 2 改 12 个文件的 API 调用——如果路径映射出错，页面会直接白屏。应该按模块分批次改

这一轮审阅通常只需要 3 分钟，但它能在后续节省数小时的回滚时间。

22.3 Step 2：分步重构策略 ​

规划确认后，接下来的执行原则是：一个阶段一个阶段来，一个模块一个模块改，每步验证。

阶段 1：提取公共工具函数 ​

这是最安全的起点——改动范围小（3 个文件），逻辑清晰，验证方便。

指令：

src/components/ 里有 3 个组件都写了日期格式化逻辑，帮我提取成公共函数。

具体要求：
1. 统一使用 dayjs（替换现有的 moment）
2. 创建 src/utils/formatDate.ts，导出以下函数：
   - formatDateTime(date)：格式 YYYY-MM-DD HH:mm:ss
   - formatDate(date)：格式 YYYY-MM-DD
   - formatChineseDate(date)：格式 YYYY年MM月DD日
3. 修改 UserTable.jsx、OrderTable.jsx、LogList.jsx，改为引入公共函数
4. 完成后运行项目的测试（如果有的话）

Claude 的执行过程：

1. [Read] 读取 3 个组件文件，确认当前实现
2. [Read] 检查 package.json 确认 dayjs 是否已安装
3. [Write] 创建 src/utils/formatDate.ts
4. [Edit] 逐个修改 3 个组件：
   - UserTable.jsx：删除 import moment，改为 import { formatDateTime } from '@/utils/formatDate'
   - OrderTable.jsx：删除 import dayjs，统一使用公共函数
   - LogList.jsx：删除内联 format，统一使用 formatChineseDate
5. [Bash] 运行 pnpm test（如果配置了测试）
6. [Bash] 运行 pnpm build 确认构建通过

关键细节：注意 Claude 在修改 OrderTable.jsx 时，不仅改了 import，还自动修正了日期格式——从 YYYY/MM/DD（斜杠分隔）统一为 YYYY-MM-DD（短横线分隔），消除了之前的不一致。

阶段 1 完成后的验证：

用户：跑一下测试，确认阶段 1 没有引入问题

Claude：
[执行 pnpm test]
测试结果：12/12 通过 ✓
构建结果：成功 ✓

阶段 1 变更总结：
  新增：src/utils/formatDate.ts（45 行）
  修改：src/components/UserTable.jsx（-8 行, +2 行）
  修改：src/components/OrderTable.jsx（-6 行, +2 行）
  修改：src/components/LogList.jsx（-5 行, +2 行）
  
是否提交这次变更？

确认无误后，立即提交：

bash
git commit -m "refactor: 提取日期格式化公共函数，统一使用 dayjs"

小步快跑的第一原则：每完成一个阶段立即 commit。 这是你最重要的安全网——如果阶段 2 的改动出了问题，你可以精准回退到阶段 1 完成后的状态，而不是全部重来。

阶段 2：提取 API 层 ​

这是整个重构中最核心、改动面最大的一步。12 个文件的 API 调用需要被提取和替换。策略是按模块分批，而不是一次改完所有文件。

第一步：创建 API 基础设施

先创建 API 层的基础设施，不修改任何已有组件：

1. 创建 src/api/client.ts：
   - 创建统一的 axios 实例，配置 baseURL、超时、拦截器
   - 请求拦截器：自动附加 token（从 localStorage 读取）
   - 响应拦截器：统一处理 401（跳转登录页）、通用错误提示

2. 创建 src/api/users.ts：
   - 封装用户相关的 API 调用（getUserList、getUserDetail、updateUser、deleteUser）
   - 从 UserList.jsx、UserDetail.jsx 中提取实际的 API 路径和参数格式

3. 创建 src/api/products.ts：
   - 封装产品相关的 API

4. 创建 src/api/orders.ts：
   - 封装订单相关的 API

Claude 收到这个指令后会先通读所有相关文件，找到每个 API 调用的路径、方法、参数格式，然后在新的 api 模块中按照一致的风格封装。

第二步：逐个模块替换

基础设施建好后，分模块替换——每次只动一个页面的组件：

现在修改 src/pages/UserList.jsx：
- 删除文件内的 axios 导入和调用
- 改为从 @/api/users 导入对应的函数
- 确保所有调用的参数和返回值处理保持一致
- 改完后立即运行这个页面的测试（如果有的话）

改一个，验证一个，确认无误再改下一个。这种节奏虽然稍慢，但每步都是安全的：

UserList.jsx      → 修改 → 验证通过 ✓ → Commit
UserDetail.jsx    → 修改 → 验证通过 ✓ → Commit
ProductList.jsx   → 修改 → 验证通过 ✓ → Commit
...共 12 个文件...

如果在修改第 8 个文件时发现验证失败：

用户：改完 ProductList.jsx 后测试不通过了，帮我检查一下

Claude：
[读取错误日志]
发现错误：TypeError: Cannot read property 'data' of undefined

问题定位：ProductList.jsx 中原来的 axios 调用使用了旧的响应结构
  axios.get('/api/products').then(res => res.data)
而新创建的 api/products.ts 中 getProductList 已经解包了 data 层

修复方案：
  方式 A：修改 components 中的调用，去掉 .data（推荐）
  方式 B：修改 api/products.ts，保留原始响应结构

建议选择方式 A——在 API 层解包是更好的实践，调用方不需要关心 HTTP 细节。
是否按方案 A 修复？

阶段 2 完成后的检查清单：

□ 12 个页面组件的 axios 导入都已替换
□ 所有 API 路径映射正确
□ baseURL 不再在组件中硬编码
□ Token 附加逻辑统一在拦截器中
□ 401 处理行为一致
□ pnpm build 通过
□ pnpm test 通过（或手动检查了关键页面）

阶段 3：JS → TS 迁移 ​

TypeScript 迁移最适合一次一个文件——这是 Claude Code 的强项，但也不能一蹴而就。

第一个文件（风险最低的）：

把 src/pages/Login.jsx 改成 TypeScript。

要求：
1. 分析现有的 PropTypes 定义，生成对应的 TypeScript 接口
2. 为 useState、事件处理函数添加类型标注
3. 文件名改为 Login.tsx
4. 不要改变任何业务逻辑
5. 如果遇到无法推断的类型，标注为 TODO 并说明原因

Claude 的典型执行过程：

1. [Read] 读取 Login.jsx 全部内容
2. 分析：
   - PropTypes 定义了 username、password、onLogin 等
   - 有 3 个 useState
   - 有 2 个事件处理函数
   - 调用了 auth API
3. [Write] 创建 Login.tsx：
   - interface LoginForm { username: string; password: string; }
   - interface LoginProps { onLogin: (token: string) => void; }
   - const [form, setForm] = useState<LoginForm>({...})
   - const handleSubmit = async (e: React.FormEvent) => {...}
4. [Bash] 运行 TypeScript 编译器检查 Login.tsx
5. 如果编译通过，删除旧文件 Login.jsx

第一个文件通过后，重复同样的模式处理第二个、第三个...直到全部完成。

迁移中的常见问题与处理：

问题Claude 的处理方式你的决策
PropTypes 不完整根据代码逻辑推断缺失的类型，标注 // 根据使用推测确认推断是否正确
第三方库缺少类型定义提示需要安装 @types/xxx确认后让它安装
动态属性无法推断使用 Record<string, any> 并标注 TODO决定是否接受，或手动补充精确类型
遗留的 any解释为什么用了 any（如 "此处依赖运行时传入的动态参数"）判断是否合理

迁移的推荐节奏：

起始：1 文件/15 分钟 → 确认工作流顺畅
熟练后：批量请求 "把接下来 3 个低优先级的文件也迁移了" 
收尾：复杂文件（如 Dashboard.jsx）留到最后，单独处理

22.4 Step 3：增量验证方法 ​

大规模重构的核心风险不是"某个改动是错的"，而是"不知道是哪个改动引入的问题"。增量验证的目标是让每一次改动都有迹可循、可被快速定位。

验证的四个层次 ​

层次一：语法/编译验证
  → pnpm build / tsc --noEmit
  → 目的：确保代码没有语法错误和类型错误
  → 时机：每次文件修改后

层次二：单元测试验证
  → pnpm test
  → 目的：确保逻辑行为没有退化
  → 时机：每个阶段/模块完成后

层次三：Lint 验证
  → pnpm lint
  → 目的：确保代码风格一致
  → 时机：每个阶段完成后（或配置为 pre-commit hook）

层次四：手动冒烟测试
  → 本地启动，检查关键页面
  → 目的：发现自动化测试覆盖不到的 UI/交互问题
  → 时机：每个大阶段完成后

Git Diff 检查——每个 commit 前必做 ​

在提交之前，让 Claude 帮你汇总变更：

帮我展示当前所有的 git diff，按文件汇总变更内容

Claude 的输出会类似：

📄 src/api/client.ts（新增 60 行）
  + 统一 axios 实例配置
  + 请求拦截器（token 附加）
  + 响应拦截器（401 处理、错误提示）

📄 src/api/users.ts（新增 35 行）
  + getUserList()
  + getUserDetail()
  + updateUser()
  + deleteUser()

📄 src/pages/UserList.jsx（-22 行, +8 行）
  - 删除内联 axios 调用（-22 行）
  + 导入 api/users 中的函数（+3 行）
  + 调用方式改为 getUserList()（+5 行）

📄 src/pages/Dashboard.jsx（+1 行, -1 行）
  ~ baseURL 从 'https://api.example.com/v1' 修正为统一配置

检查这份汇总时，特别留意：

  • 有没有不该被改动的文件出现在 diff 中？
  • 有没有意外的修改（如自动格式化导致的无关变更）？
  • Dashboard 的 /v1 修正后面有没有其他文件也使用了 /v1 而应该同步修改？

测试失败时的处理流程 ​

测试失败 → 读错误日志 → 定位是哪个文件的改动导致的 → 修复 → 重新测试
                                     ↓
                              让 Claude 读日志
                              它会定位到具体文件

不要试图一次修复多个错误。如果测试失败报告了 3 个错误，逐一修复——每修一个就跑一次测试，确认修复了一个且没引入新的。

Commit 策略 ​

阶段 1 完成  → commit: "refactor: 提取日期格式化公共函数"
  ├── 模块 A 完成 → commit: "refactor: 提取 users API 模块"
  ├── 模块 B 完成 → commit: "refactor: 提取 products API 模块"
  ├── 模块 C 完成 → commit: "refactor: 提取 orders API 模块"
  └── 全部替换完成 → commit: "refactor: 完成 API 层提取，统一 axios 调用"
阶段 3：
  ├── Login 迁移  → commit: "refactor: 迁移 Login 页面到 TypeScript"
  ├── Settings 迁移 → commit: "refactor: 迁移 Settings 页面到 TypeScript"
  └── ...

每个 commit 都是你可以精准回退到的"安全点"。如果你在一个 commit 里塞了 8 个文件的改动，其中第 3 个文件有问题，你只能全部回退再手动挑拣——这违背了"小步快跑"的初衷。

22.5 Step 4：回退预案 ​

"改错了怎么办"不是杞人忧天——这是大规模重构中必须准备的预案。以下是从轻到重的回退手段。

轻量回退：Git 单文件恢复 ​

如果只是某个文件改错了：

用户：src/pages/OrderList.jsx 改得不对，帮我恢复到修改前的状态

Claude：
[执行 git checkout -- src/pages/OrderList.jsx]
已恢复 src/pages/OrderList.jsx 到 HEAD 版本。

中等回退：Git 按 commit 回退 ​

如果某个阶段的改动方向有问题：

用户：阶段 2 中 Product 模块的 API 提取方案不太好，帮我回退到阶段 2 开始前的状态

Claude：
查看 git log，确认需要回退的 commit 范围：
  abcd123 refactor: 提取 products API 模块
  efgh456 refactor: 修改 ProductList 使用新 API
  
回退方案：
  git revert efgh456
  git revert abcd123

这会创建两个新的 commit 来反转之前的改动，不会修改已有的历史。

重度回退：Git Worktree 隔离 ​

对于风险极高的大规模改动，使用 Git Worktree 在隔离环境中工作：

# 在主项目中创建一个隔离的工作目录
git worktree add ../project-refactor feature/refactor-ts

# 在隔离目录中做所有重构
# 主项目保持干净，随时可以切回去工作
# 重构完成后：
cd ../project-refactor
# 合并或创建 PR

Claude Code 支持 Worktree 模式（详见第 32 章），你可以在隔离环境中让 Claude 做任何危险操作，确认无误后再合并回主分支。

终极回退：Reject All + /clear ​

如果你在对话中发现 Claude 已经偏离了方向，而且改动了很多文件：

  1. 在 VSCode 的 Diff 审查区 Reject All
  2. 使用 /clear 清空当前对话（Claude 可能已经建立了错误的上下文）
  3. 重新开始，用更精确的指令
❌ 错误：继续在偏离方向的对话中纠正 Claude
✅ 正确：Reject All → /clear → 重新来。浪费的时间远少于错误的累积

变更总结 ​

重构全部完成后，让 Claude 生成一份变更总结——这在 Code Review 和后续排查时都很有用：

帮我总结一下这次重构的所有改动，按模块列出：
1. 新增了哪些文件
2. 修改了哪些文件
3. 删除了哪些文件
4. 每个阶段解决了什么问题
5. 整体的代码行数变化（新增多少行、删除多少行）

这样一份总结，既是对自己工作的复盘，也可以作为 PR Description 的素材。

22.6 复盘与技巧总结 ​

本章完成了一次完整的大规模重构——从评估规划到分步执行，从增量验证到回退预案。让我们回顾核心要点。

大规模重构的四个核心原则 ​

┌─────────────────────────────────────────────────┐
│                                                  │
│  1. 分阶段        不要一次性改完所有文件          │
│  2. 小步快跑      每次改一点点，改完立即验证      │
│  3. 每步验证      编译 + 测试 + lint + 手动检查   │
│  4. Git 保障       每个阶段 commit，错了能回退     │
│                                                  │
└─────────────────────────────────────────────────┘

Claude Code 特别适合的重构类型 ​

Claude Code 在处理以下类型的重构时表现优异：

重构类型为什么适合本章示例
批量重命名精确识别所有引用点，批量修改文件名 .jsx → .tsx
提取公共代码能同时看到所有重复点，确保不遗漏日期格式化提取、API 层提取
类型迁移从 PropTypes 推断接口，批量添加类型标注JS → TS 迁移
API 重构理解调用链，保持接口一致性axios 调用统一封装

Claude Code 不太适合的重构类型 ​

不是所有重构都适合交给 AI：

重构类型为什么不建议建议
架构级重构需要深度业务理解和权衡人做设计决策，Claude 执行
性能重构需要实际测量和瓶颈分析用 Profiler 定位瓶颈，再让 Claude 优化
安全重构错误的代价太高人工审计所有涉及认证/授权的改动
数据库迁移数据一致性不能有差错Claude 生成迁移脚本，你审查后手动执行

总的原则：Claude 做执行，你做决策。 那些规则明确、范围清晰、验证方便的重构——放心交给 Claude。那些需要权衡取舍、对业务有深远影响的决策——自己把握方向。

关键技巧速查 ​

1. Plan mode 先行     → 先分析，再规划，最后执行。方向对了再跑
2. 从风险最低的开始    → 阶段 1 是最简单的（工具函数），建立信心和工作流
3. 按模块分批改        → 阶段 2 的 12 个文件不是一次改完，而是一个模块一个模块来
4. 改一个验证一个      → 编译 + 测试 + diff 检查，三者缺一不可
5. 验证完立即 commit   → 不要把验证通过的改动留在工作区
6. 遇到问题先读日志    → 让 Claude 读错误输出，它能精准定位问题文件
7. 回退要果断          → Reject All + /clear 的代价远小于在错误方向上继续
8. Worktree 隔离高风险 → 大改动在独立环境中进行，不影响主项目

重构的时间成本对比 ​

环节手动重构（估算）Claude Code 辅助
分析重复代码1-2 小时（逐个文件搜索阅读）2-3 分钟（Grep + Read 自动扫描）
提取日期函数（3 个文件）20-30 分钟5 分钟
提取 API 层（12 个文件）2-3 小时25 分钟
JS → TS 迁移（15 个文件）4-6 小时1-1.5 小时
总计8-12 小时2 小时左右
质量容易遗漏（人容易疲劳）一致性高（不会疲倦）

这不是说 Claude Code 替代了你的工作——而是它替你承担了那些有明确规则、有重复模式、体量大但不复杂的"体力活"，让你把精力集中在决策、设计和业务理解上。

22.7 本章小结 ​

本章通过一个真实的前端项目重构案例，完整展示了使用 Claude Code 进行大规模重构的方法论：

  1. 评估与规划：让 Claude 先扫描项目，输出分析报告和重构计划。用 Plan mode 校准方向，确认后再执行
  2. 分步执行：阶段 1（工具函数提取）→ 阶段 2（API 层提取）→ 阶段 3（JS → TS 迁移）。每个阶段都是下一个阶段的基础
  3. 增量验证：编译验证 → 测试验证 → Lint 验证 → 手动冒烟。四层防护确保每一步都是可靠的
  4. 回退预案：Git 单文件恢复 → Git commit 回退 → Git Worktree 隔离 → Reject All + /clear。从轻到重，随时可以回头

大规模重构不再是一件让人望而生畏的事。有了 Claude Code，它变成了一个可以被拆解、被自动化、被安全执行的工程流程。你不再需要手动修改 15 个文件中的每一条 axios 调用——你只需要告诉 Claude 你想要什么，审查它的计划，确认它的每一步改动。

但这并不意味着你可以"一键重构"。大规模重构的安全从来不在于 AI 有多聪明，而在于你建立的工程纪律：分阶段、小步跑、每步验、随时退。这套方法论适用于任何 AI 工具，也适用于纯手动重构——它本质上是软件工程中"降低变更风险"的通用原则，只不过 Claude Code 让它的执行效率提升了数倍。

下一步： 第 23 章将进入实战篇的第四个场景——调试与排错。我们将看到 Claude Code 如何帮助你从错误日志出发，一步步缩小范围、定位根因、验证修复。

Copyright © 2017-2026 Shi Bin