mirror of
https://github.com/luongnv89/claude-howto.git
synced 2026-07-07 11:17:48 +02:00
Luong NGUYEN
89e89d4aa3
Add Chinese (Simplified) translations for all documentation, organized under a dedicated zh/ directory that mirrors the English folder structure. Co-authored-by: tanqingkuang <tanqingkuang@users.noreply.github.com> Translations originally contributed by @tanqingkuang in #45. Restructured from *-CN.md suffix pattern into zh/ directory to prevent the EPUB builder (scripts/build_epub.py collect_folder_files) from picking up Chinese files via glob("*.md") inside module folders.
340 lines
8.7 KiB
Markdown
340 lines
8.7 KiB
Markdown
# 检查点示例
|
||
|
||
以下是一些在 Claude Code 中有效使用检查点的真实示例。
|
||
|
||
注意：每次用户提示都会自动创建检查点。你不需要手动保存。要回退，请连续按两次 `Esc`（`Esc+Esc`），或者使用 `/rewind` 打开检查点浏览器。
|
||
|
||
## 示例 1：数据库迁移
|
||
|
||
### 场景
|
||
你需要从 MySQL 迁移到 PostgreSQL，但想同时探索直接迁移和渐进式双写两种方案。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：我们来实现一个从 MySQL 到 PostgreSQL 的直接迁移方案
|
||
[检查点 A 自动创建]
|
||
|
||
Claude：我来实现直接迁移……
|
||
[更换数据库驱动、更新查询、修改 schema]
|
||
|
||
用户：运行测试
|
||
[检查点 B 自动创建]
|
||
|
||
Claude：正在运行测试……
|
||
❌ 15 个测试失败 - 连接池问题
|
||
|
||
用户：这个方案有问题。我们改试双写模式。
|
||
[用户按下 Esc+Esc，选择检查点 A，选择“恢复代码和对话”]
|
||
|
||
用户：现在实现双写模式，同时向两个数据库写入
|
||
|
||
Claude：我来实现双写迁移……
|
||
[实现双写层、渐进式迁移策略]
|
||
|
||
用户：运行测试
|
||
|
||
Claude：正在运行测试……
|
||
✅ 所有测试通过
|
||
|
||
用户：双写方案明显更稳妥。我们提交这个版本。
|
||
```
|
||
|
||
## 示例 2：性能优化
|
||
|
||
### 场景
|
||
尝试多种性能优化策略。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：我们来优化 API 响应时间。当前：450ms
|
||
[检查点“Baseline”自动创建]
|
||
|
||
Claude：我来加数据库查询缓存……
|
||
[实现 Redis 缓存]
|
||
|
||
用户：运行性能测试
|
||
|
||
Claude：结果：平均响应时间 280ms（提升 38%）
|
||
|
||
用户：我想试试另一种方法。
|
||
[用户按下 Esc+Esc，选择“Baseline”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：改试数据库查询优化
|
||
|
||
Claude：我来优化数据库查询……
|
||
[添加索引，优化 N+1 查询]
|
||
|
||
用户：运行性能测试
|
||
|
||
Claude：结果：平均响应时间 180ms（提升 60%）
|
||
|
||
用户：我也想试第三种方法。
|
||
[用户按下 Esc+Esc，选择“Baseline”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：尝试响应压缩和 CDN
|
||
|
||
Claude：我来添加压缩和 CDN……
|
||
[实现 gzip，配置 CDN]
|
||
|
||
用户：运行性能测试
|
||
|
||
Claude：结果：平均响应时间 320ms（提升 29%）
|
||
|
||
用户：查询优化最好。让我回到那个版本，再和缓存结合起来。
|
||
[用户按下 Esc+Esc，选择查询优化后的检查点，选择“恢复代码和对话”]
|
||
|
||
用户：现在在这些优化后的查询之上再加上 Redis 缓存
|
||
|
||
Claude：[在优化后的查询之上添加 Redis 缓存]
|
||
|
||
用户：运行性能测试
|
||
|
||
Claude：结果：平均响应时间 95ms（提升 79%）🎉
|
||
|
||
用户：完美！这就是最终方案。我们提交它。
|
||
```
|
||
|
||
## 示例 3：UI/UX 迭代
|
||
|
||
### 场景
|
||
为仪表板尝试不同布局。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：我们来把仪表板重设计成侧边栏布局
|
||
[检查点“Start”自动创建]
|
||
|
||
Claude：[实现侧边栏布局]
|
||
|
||
用户：给我看一张截图
|
||
|
||
Claude：[显示截图]
|
||
|
||
用户：侧边栏太拥挤了。我们试试顶部导航吧。
|
||
[用户按下 Esc+Esc，选择“Start”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：试试顶部导航布局
|
||
|
||
Claude：[实现顶部导航]
|
||
|
||
用户：给我看一张截图
|
||
|
||
Claude：[显示截图]
|
||
|
||
用户：好多了，不过我们再试试卡片式网格布局。
|
||
[用户按下 Esc+Esc，选择“Start”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：试试卡片式网格布局
|
||
|
||
Claude：[实现卡片网格]
|
||
|
||
用户：给我看一张截图
|
||
|
||
Claude：[显示截图]
|
||
|
||
用户：这个很不错！不过我们能把顶部导航和卡片网格结合起来吗？
|
||
[用户按下 Esc+Esc，选择卡片网格后的检查点，选择“恢复代码和对话”]
|
||
|
||
用户：给卡片网格布局加上顶部导航
|
||
|
||
Claude：[在卡片网格上添加顶部导航]
|
||
|
||
用户：完美！这就是最终设计。
|
||
```
|
||
|
||
## 示例 4：调试会话
|
||
|
||
### 场景
|
||
用多个假设排查一个难缠的 bug。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：应用里有内存泄漏
|
||
[检查点“Before debugging”自动创建]
|
||
|
||
Claude：让我来调查……
|
||
[分析代码]
|
||
|
||
用户：我觉得问题在事件监听器里。我们先修这个。
|
||
|
||
Claude：[修复事件监听器清理逻辑]
|
||
|
||
用户：运行内存分析器
|
||
|
||
Claude：仍然在泄漏内存 - 事件监听器不是问题所在
|
||
|
||
用户：让我回到之前，换个思路试试。
|
||
[用户按下 Esc+Esc，选择“Before debugging”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：也许是数据库连接的问题？
|
||
|
||
Claude：[实现连接池修复]
|
||
|
||
用户：运行内存分析器
|
||
|
||
Claude：还是在泄漏 - 也不是连接的问题
|
||
|
||
用户：我再回去，换另一个方向试试。
|
||
[用户按下 Esc+Esc，选择“Before debugging”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：我们检查一下有没有循环引用
|
||
|
||
Claude：[找到并修复缓存中的循环引用]
|
||
|
||
用户：运行内存分析器
|
||
|
||
Claude：✅ 内存泄漏修复了！缓存层里的循环引用就是罪魁祸首。
|
||
|
||
用户：太好了！我们提交这个修复。
|
||
```
|
||
|
||
## 示例 5：API 设计演进
|
||
|
||
### 场景
|
||
为 REST API 设计做多轮迭代。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：给我们的博客平台创建一个 REST API
|
||
[检查点“Before API design”自动创建]
|
||
|
||
Claude：[创建基础 CRUD API]
|
||
|
||
用户：这个太简单了。加上分页和过滤
|
||
|
||
Claude：[添加分页和过滤]
|
||
|
||
用户：我们需要更好的资源关系
|
||
|
||
Claude：[实现 HATEOAS 链接]
|
||
|
||
用户：其实我们改用 GraphQL，不用 REST 了
|
||
[用户按下 Esc+Esc，选择“Before API design”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：那就为我们的博客平台改实现 GraphQL API 吧
|
||
|
||
Claude：[实现 GraphQL API]
|
||
|
||
用户：我觉得 REST 更适合我们的场景。
|
||
[用户按下 Esc+Esc，选择 HATEOAS 之后的检查点，选择“恢复代码和对话”]
|
||
|
||
用户：那我们就把 REST 方案定下来。
|
||
```
|
||
|
||
## 示例 6：配置管理
|
||
|
||
### 场景
|
||
测试不同的配置方案。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：把配置迁移到环境变量
|
||
[检查点“Original config”自动创建]
|
||
|
||
Claude：[实现环境变量配置]
|
||
|
||
用户：在开发环境里测试
|
||
|
||
Claude：本地可用，但生产环境部署有问题
|
||
|
||
用户：我换个方案试试。
|
||
[用户按下 Esc+Esc，选择“Original config”检查点，选择“恢复代码和对话”]
|
||
|
||
用户：改成带校验的配置文件方案
|
||
|
||
Claude：[实现带 JSON Schema 校验的 YAML 配置]
|
||
|
||
用户：在开发环境里测试
|
||
|
||
Claude：✅ 运行良好，校验错误提示也很清楚
|
||
|
||
用户：我们也能为敏感值支持环境变量吗？
|
||
|
||
Claude：[为密钥添加环境变量覆盖]
|
||
|
||
用户：测试部署
|
||
|
||
Claude：✅ 所有环境都正常工作
|
||
|
||
用户：完美，这个已经可以用于生产。
|
||
```
|
||
|
||
## 示例 7：测试策略
|
||
|
||
### 场景
|
||
实现完整的测试体系。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：给 auth 模块添加单元测试
|
||
[检查点自动创建]
|
||
|
||
Claude：[添加 Jest 单元测试]
|
||
|
||
用户：运行测试
|
||
|
||
Claude：45 个测试通过，覆盖率 78%
|
||
|
||
用户：再加上集成测试
|
||
|
||
Claude：[添加集成测试]
|
||
|
||
用户：运行测试
|
||
|
||
Claude：89 个测试通过，覆盖率 92%，但测试太慢了（3 分钟）
|
||
|
||
用户：测试太慢了，我们来优化。
|
||
|
||
Claude：[优化测试设置，增加并行执行]
|
||
|
||
用户：运行测试
|
||
|
||
Claude：89 个测试通过，覆盖率 92%，35 秒完成 ✅
|
||
|
||
用户：很好！再给关键路径加上 E2E 测试。
|
||
|
||
Claude：[添加 Playwright E2E 测试]
|
||
|
||
用户：运行所有测试
|
||
|
||
Claude：112 个测试通过，覆盖率 94%，2 分钟完成
|
||
|
||
用户：很好，覆盖率和速度都平衡得不错！
|
||
```
|
||
|
||
## 示例 8：从检查点开始总结
|
||
|
||
### 场景
|
||
在一次很长的调试会话后，你想压缩对话内容，同时保留上下文。
|
||
|
||
### 工作流程
|
||
|
||
```
|
||
用户：[经过 20 多条消息的调试和探索之后]
|
||
|
||
[用户按下 Esc+Esc，选择较早的检查点，选择“从这里开始总结”]
|
||
[可选地提供指令：“重点保留我们尝试过什么，以及什么有效”]
|
||
|
||
Claude：[生成从该点开始的对话总结]
|
||
[原始消息保留在记录里]
|
||
[总结会替换当前可见对话，从而减少上下文窗口占用]
|
||
|
||
用户：现在继续推进那个有效的方案。
|
||
```
|
||
|
||
## 关键结论
|
||
|
||
1. **检查点是自动创建的**：每次用户提示都会创建一个检查点，不需要手动保存。
|
||
2. **使用 `Esc+Esc` 或 `/rewind`**：这两种方式都可以打开检查点浏览器。
|
||
3. **选择合适的恢复方式**：根据需要恢复代码、对话、两者都恢复，或者直接总结。
|
||
4. **不要害怕试验**：检查点让你可以安全尝试激进的改动。
|
||
5. **和 git 结合使用**：检查点用于探索，git 用于最终落地。
|
||
6. **长会话要及时总结**：用“从这里开始总结”来保持对话可管理。
|