我以前最烦的事情之一，是盯着 jenkins 发呆。

构建部署要跑 8 分钟，我就坐在那里刷手机，每隔 30 秒看一眼终端。

后来我发现，Claude Code 最强的能力，根本不是写代码。

而是处理那些人类不想盯着看的脏活累活。

接下来，我们就讲讲：如何真正把 Claude Code 融入你的工作流。

第一部分：上下文管理

技巧 1：主动压缩上下文，别等 Claude 自动压缩

因为 Claude Code 的上下文窗口是 200k tokens，但系统提示就占了 18k。

步骤：

第 1 步：让 Claude 写 handoff 文档

把当前进度写入 handoff.md，包括：
1. 已完成的工作
2. 尝试过但失败的方案
3. 下一步要做什么
4. 重要的上下文信息

第 2 步：Claude 生成文档

# Handoff Document

## 已完成
- 实现了用户注册 API
- 添加了密码加密（bcrypt）
- 配置了 JWT token 生成

## 尝试过但失败
- 尝试用 Passport.js，但配置太复杂，改用 jsonwebtoken

## 下一步
- 实现登录验证中间件
- 添加 token 刷新机制
- 写单元测试

## 重要上下文
- 使用 Express.js 框架
- 数据库是 PostgreSQL
- JWT secret 存在 .env 文件

第 3 步：开新对话，只加载 handoff 文档

# 新对话
读取 handoff.md，继续完成剩余工作

为什么这样做？

新对话 = 新鲜的 Claude = 更好的性能。

很多人以为上下文是 AI 的记忆。会玩的人，已经开始主动管理 AI 的记忆了。

我的建议：

• 关闭自动压缩：/config → 关闭 auto-compact

• 每次压缩前让 Claude 更新 handoff 文档

• 在后续对话中继续更新这个文档

技巧 2：懒加载 MCP 工具，按需加载

如果你配置了多个 MCP servers，它们的工具定义会在每次对话开始时全部加载。

解决方案： 启用懒加载。

配置：

{
  "env": {
    "ENABLE_TOOL_SEARCH": "true"
  }
}

MCP 工具只在被调用时加载，节省初始上下文。

技巧 3：搜索历史对话，快速找到之前的方案

上周写的代码，现在想不起来怎么实现的？

所有对话存储位置：

~/.claude/projects/<project-path>/

搜索示例：

# 搜索包含 "Reddit" 的对话
grep -l -i "reddit" ~/.claude/projects/*/*.jsonl

# 搜索今天的对话
find ~/.claude/projects/*/*.jsonl -mtime 0 -exec grep -l -i "keyword" {} \;

# 提取用户消息
cat conversation.jsonl | jq -r 'select(.type=="user") | .message.content'

或者直接问 Claude：

搜索我的历史对话，找到关于 Reddit 的讨论

第二部分：高级工作流

技巧 1：Git Worktrees ，多分支并行工作

需要同时开发多个功能，但切换分支很麻烦？

什么是 Worktree？

• 一个 worktree = 一个分支 + 一个目录

• 可以同时在多个分支工作

• 不用来回切换

使用方法：

# 让 Claude 创建 worktree
创建一个 git worktree 用于 feature-x

# Claude 会执行：
git worktree add .claude/worktrees/feature-x -b feature-x
cd .claude/worktrees/feature-x

适用场景：

• 同时开发多个功能

• 测试不同方案

• 紧急修 bug 不想打断当前工作

技巧 2：多标签页工作流

用多标签页方式管理多个任务。

我的方法：

Tab 1: 语音转录系统（常驻）
Tab 2: Docker 容器配置
Tab 3: 检查磁盘空间
Tab 4: 工程项目
Tab 5: 写教程 ← 当前

原则：

• 新任务开在最右边

• 从左到右扫描（老任务 → 新任务）

• 最多同时 3-4 个任务

• 完成的任务关闭标签

为什么这样做？

方向一致，不会乱。容易追踪进度。

技巧 3：手动指数退避，等待长时间任务

解决方案： 让 Claude 用指数退避检查状态。

指令：

检查 docker build 状态，使用指数退避：
1 分钟、2 分钟、4 分钟、8 分钟

Claude 会：

# 第 1 次检查（1 分钟后）
sleep 60 && docker ps

# 第 2 次检查（2 分钟后）
sleep 120 && docker ps

# 第 3 次检查（4 分钟后）
sleep 240 && docker ps

# 直到构建完成

为什么不用 `gh run watch`？

gh run watch 输出太多，浪费 Token。手动退避更节省。

第三部分：实战场景

很多人觉得 AI 最适合写代码。我现在反而觉得，它最适合处理那些人类不想盯着看的东西。

技巧 1：PR 审查助手

需要审查一个复杂的 PR？

工作流程：

第 1 步：获取 PR 信息

获取 PR #123 并显示摘要

第 2 步：逐文件审查

逐文件审查变更，重点关注：
1. 潜在 bug
2. 安全问题
3. 性能问题
4. 代码风格

第 3 步：交互式讨论

为什么这里用 Promise.all 而不是顺序执行？

这个 SQL 查询有注入风险吗？

这个函数可以优化吗？

技巧 2：DevOps 工程师

GitHub Actions CI 失败了，需要排查原因。

工作流程：

第 1 步：查看失败的 run

调查最新 commit 的 GitHub Actions 为什么失败

第 2 步：分析日志

分析错误日志，找出根本原因

第 3 步：定位问题 commit

这是某个特定 commit 导致的吗？如果需要可以用 git bisect

第 4 步：创建修复 PR

创建一个 draft PR 来修复这个问题

技巧 3：完整的 write-test 循环

如果想让 Claude 自主工作，必须给它验证结果的方法。

示例：用 git bisect 找 bug

问题： /compact 命令突然报 400 错误，不知道哪个 commit 导致的。

解决方案： 让 Claude 用 git bisect 自动定位。

步骤 1：写测试脚本

# test-compact.sh
tmux kill-session -t test 2>/dev/null
tmux new-session -d -s test
tmux send-keys -t test 'claude' Enter
sleep 2
tmux send-keys -t test '/compact' Enter
sleep 1
tmux capture-pane -t test -p | grep -q "400" && exit 1 || exit 0

步骤 2：让 Claude 运行 bisect

用 git bisect 找出哪个 commit 破坏了 /compact。
用 test-compact.sh 验证每个 commit。

为什么这样做？

Claude 可以自主验证结果，不需要你手动测试每个 commit。

第四部分：避坑指南

技巧 1：CLAUDE.md 保持简洁

错误做法：

# CLAUDE.md (500 行)

## 项目介绍
这是一个用户认证系统...（100 行）

## 代码规范
...（200 行）

## 架构说明
...（200 行）

正确做法：

# CLAUDE.md (50 行)

## 核心规则
- 使用 Bun，不用 npm
- 提交前运行 bun test
- 当前 sprint：auth refactor

## 常见问题
- 数据库连接字符串在 .env
- API 文档在 docs/api.md

原则：

只写重复出现的规则，保持 < 60 行，详细文档放在单独文件。

技巧 2：验证 Claude 的输出

错误做法：

Claude: "完成了！"
你: "好的！" ← 直接信了

正确做法：

Claude: "完成了！"
你: "让我验证一下..."

验证方法：
1. 让 Claude 写测试并运行
2. 用 GitHub Desktop 查看 diff
3. 创建 draft PR 审查
4. 让 Claude 自己 double-check

我最喜欢的 prompt：

“

仔细检查你写的所有代码，验证每一处逻辑，最后做一个表格列出你能验证的内容

总结

上下文管理（技巧 1-3）：

• 主动压缩上下文

• 懒加载 MCP 工具

• 搜索历史对话

高级工作流（技巧 1-3）：

• Git Worktrees 并行工作

• 多标签页管理

• 手动指数退避

实战场景（技巧 1-3）：

• PR 审查助手

• DevOps 工程师

• write-test 循环

避坑指南（技巧 1-2）：

• CLAUDE.md 保持简洁

• 验证输出