5 个我每天都在用的 Claude Code 工作流，效率至少翻倍

发表于 更新于 分类于 阅读次数： 本文字数： 4k 阅读时长 ≈ 4 分钟

cover

用了三个月 Claude Code，我发现一个规律：大多数人把它当”智能问答机器人”用——遇到问题问一句，拿到答案粘贴进去。

这就像买了一辆跑车，只用它去楼下超市买菜。

Claude Code 真正的威力，在于工作流。不是单次对话，而是一套可重复的、结构化的操作模式。一旦你找到适合自己的工作流，效率提升不是 10%、20%，而是成倍的。

今天分享 5 个我每天都在用的工作流。不是理论，都是实战中打磨出来的。每一个都附具体操作步骤，看完就能用。

工作流 1：先规划再动手——Explore-Plan-Execute

这是 Anthropic 官方推荐的核心工作流，也是我认为 Claude Code 最重要的使用模式。

很多人上来就说：”帮我加一个用户认证模块。”Claude Code 会立刻开始写代码。问题是，它可能对你的项目结构理解不完整，写出来的东西和现有架构冲突。

正确的做法分三步：

第一步：探索（Explore）

1
2
先阅读这个项目的整体架构。看看 src/ 目录下的文件结构，
理解现有的认证逻辑、路由设计和数据库模型。不要改任何代码。

让 Claude Code 先”看地图”，而不是直接”开车”。

第二步：规划（Plan）

按 Shift+Tab 进入 Plan Mode。在这个模式下，Claude Code 只会生成方案，不会修改任何文件。

1
2
基于你对项目的理解，制定一个添加 JWT 认证的方案。
列出需要修改的文件、新增的文件，以及每一步的具体操作。

Claude Code 会输出一份详细的执行计划。你可以用 Ctrl+G 编辑这个计划——删掉不需要的步骤，调整执行顺序，补充约束条件。

第三步：执行（Execute）

确认计划后，按 Shift+Tab 切回 Edit Mode，让 Claude Code 按计划执行。

Boris Cherny（Claude Code 的创造者）强调过：”别直接要解决方案，先要一个计划，然后锁定它。“这一步看起来多花了 2 分钟，实际上能省掉 20 分钟的返工。

SFEIR 的培训团队总结得好：”Plan Mode 把 Claude Code 从一个执行者变成了一个架构师——任何超过单文件的任务都应该用它。”

工作流 2：测试驱动——先写测试，再写代码

这是我最喜欢的工作流，也是 Claude Code 最佳实践中被反复提及的一条。

传统 TDD 的问题是什么？写测试太慢了，很多人坚持不下来。但用 Claude Code，写测试的成本几乎降到零。

具体步骤：

1
2
3
4
5
6
7
8
我要给 UserService 添加一个 updateProfile 方法。
先帮我写测试用例，覆盖以下场景：
1. 正常更新成功
2. 用户不存在时返回 404
3. 邮箱格式无效时返回 400
4. 并发更新时的处理

不要写实现代码，只写测试。

Claude Code 生成测试后，你先看一遍。测试用例其实就是需求文档——它精确定义了这个方法应该做什么。

确认测试用例正确后：

1
2
现在根据这些测试，实现 updateProfile 方法。
每实现一部分就跑一次测试，确保通过。

这个工作流的妙处在于：测试是 Claude Code 的”外部验证器”。 DataCamp 的最佳实践指南专门提到：”在实现之前写测试，让 Claude 有一个外部标准来验证自己的输出。”

不过有一个坑要注意。一位开发者的经验是：AI 有时候会写出”通过但错误”的测试——测试会根据错误的代码调整自己来通过。所以测试用例本身也要审查。

工作流 3：结构化调试——不要直接贴报错

这是初学者最容易犯错的地方。遇到报错，直接把错误信息丢给 Claude Code：”帮我修这个 Bug。”

结果呢？Claude Code 可能会”头疼医头”——改了报错的那一行，但没有理解根本原因。

我的调试工作流是这样的：

第一步：描述上下文

1
2
3
4
5
我在运行 npm run dev 时遇到了一个错误。
这个功能原本是正常的，是在我添加了 Redis 缓存层之后开始报错的。
以下是错误信息：

[粘贴完整的错误堆栈]

关键是告诉 Claude Code 什么时候开始出问题的，以及你做了什么改动。这比光贴一个 Error 有用得多。

第二步：让它先分析，不要直接修

1
先分析可能的原因，不要直接修改代码。给我 3 个最可能的根因。

第三步：验证和迭代

确认了最可能的原因后，让 Claude Code 修改代码并运行测试验证。

Boris Cherny 的建议是：”强制 Agent 用命令来证明改动是有效的。“不要只改代码就结束，要让它跑测试、看输出、确认修复。

一位开发者分享了他调试 NestJS 端点的经验：花了 40 分钟排查一个只在特定环境下失败的 API。最后发现是环境变量缺失。他把整个过程保存为一个 session summary 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
# 2026-03-15-api-debug-session.md
## 确认有效的
- 请求到达了 Controller
- DTO 验证通过
- 找到了缺失的 SANDBOX_API_KEY

## 确认无效的
- 用 Mock payload 重试没有改变结果
- 绕过验证并非根本原因

## 待处理
- 添加启动时的环境变量校验
- 补充缺失环境变量的测试覆盖

每次调试完，保存一份总结。 这样下次遇到类似问题，Auto Memory 或者你自己都能快速找到答案。

工作流 4：原子化提交——用 /commit 养成好习惯

很多人写代码的节奏是这样的：连续写两小时，改了 15 个文件，然后一个 git add . 全部提交，commit message 写个”update”。

Claude Code 的 /commit 命令（或自定义的提交 Skill）彻底改变了这个习惯。

我的做法：每完成一个小功能，立刻提交。

1
/commit

Claude Code 会自动分析你的 diff，生成一条结构化的 commit message。它会区分是 feat、fix、refactor 还是 chore，描述改了什么、为什么改。

更进一步，你可以自定义一个提交 Skill，加入团队特定的规则。比如：

  • 必须关联 Issue 编号
  • commit message 必须中英双语
  • 超过 5 个文件的改动需要先跑 lint

SFEIR 的培训指南提到，Anthropic 内置的 /commit 和 /review 命令是很好的”入门套件”。但对于有特定规范的团队，自定义 Skill 才是长期方案。

Boris Cherny 的建议也呼应了这一点：”把 Git 当安全网。让 Agent 总结 diff，标出风险，列出不兼容的变更。“

好的提交习惯不只是为了 git log 好看。它是你的”撤销按钮”。当 Claude Code 某次改动出了问题，你可以精确回退到某一步，而不是面对一个巨大的 diff 无从下手。

工作流 5：代码清扫——改完就 /simplify

这是我最近养成的新习惯，来自 Claude Code 2 月更新的内置 Skill。

每次 Claude Code 帮我完成一个功能，在提交之前，我都会跑一次：

1
/simplify

它会启动多个并行的 AI Agent，扫描你刚才改动的所有文件，检查：

  • 有没有可以复用的代码（你写了一个新的 helper，但项目里已经有一个功能一样的）
  • 代码质量有没有问题
  • 有没有违反 CLAUDE.md 里定义的编码规范
  • 有没有明显的性能问题

然后自动修复。

这相当于在每次提交之前，自动做了一次 Code Review。

TurboDocx 的指南里提到一个细节我很喜欢：”/simplify 很聪明，对于小改动（修个 typo、改个配置），它知道不需要走完整的审查流程，会直接跳过。”

把 /simplify 和 /commit 串在一起用，就形成了一个闭环：写功能 → /simplify 清扫 → /commit 提交。

如果你想更进一步，可以用 Hooks 把这个流程自动化——在 Claude Code 每次 Stop 时自动触发 linter，或者在 commit 前自动跑 /simplify。

把这 5 个工作流串起来

单独看，每个工作流都很简单。但串在一起，就是一套完整的开发循环：

  1. Explore-Plan-Execute：接到任务，先探索、规划、再执行
  2. TDD：先写测试定义”完成标准”，再实现代码
  3. 结构化调试：遇到 Bug 不慌，分析→假设→验证
  4. /simplify：改完代码，自动清扫质量问题
  5. /commit：原子化提交，每一步都可追溯

这 5 步不是线性的。你可能在执行阶段遇到 Bug（进入工作流 3），修完 Bug 后做一次清扫（工作流 4），然后提交（工作流 5），再继续执行计划的下一步（回到工作流 1）。

重点不是严格按顺序来，而是每个环节都有一个清晰的操作模式。不用每次都从头想”我该怎么用 Claude Code”。

一个额外的建议：管好上下文

所有工作流能跑顺的前提是：Claude Code 始终理解你的项目。

三个关键习惯：

  • 写好 CLAUDE.md：技术栈、代码规范、常用命令、项目结构。每一行都问自己：”去掉这行，Claude 会不会犯错？”
  • 及时 /clear：任务之间用 /clear 清理上下文。Builder.io 的指南建议在上下文使用到 60% 时就主动清理。
  • 用 –continue 恢复会话：中午吃饭回来，用 claude --continue 恢复上一次的会话。给重要会话起个名字（claude -n "auth-module"），方便后续用 --resume 找回来。

写在最后

Claude Code 的能力上限很高，但大多数人只用了它 20% 的能力。不是因为功能不知道，而是缺少一套结构化的工作方式。

这 5 个工作流不是什么高深的技巧。它们的价值在于可重复——每天都用，每次都用，慢慢就成了肌肉记忆。到那个时候，你会发现自己已经不是在”使用一个工具”，而是在和一个搭档协作。

Boris Cherny 说过一句话我特别认同：”AI 编程不是’写 Prompt’，它是一套工作流——紧密的反馈循环、清晰的约束、几个让模型保持高效而不是失控的习惯。”

你有自己常用的 Claude Code 工作流吗？或者有什么提高效率的小技巧？欢迎在评论区分享，我们一起优化彼此的开发流程。