Claude Code 核心工作流：别把它当聊天框，让它真正干活

leoZ231

125人浏览 · 2026-07-28 07:53:18

leoZ231 · 2026-07-28 07:53:18 发布

Claude Code 核心工作流：别把它当聊天框，让它真正干活

本文是《Claude Code 实战》系列第 2 篇。第 1 篇讲了 Claude Code 的定位——它不是补全插件，而是一个能在终端里读写文件、执行命令、自主推进任务的 AI agent。本篇解决更实际的问题：怎么和它配合，才能稳定、可控地完成一次真实开发任务。

同样一个需求，两种结局

给一个 Node.js 项目加一个批量导出功能。

新手丢一句"帮我加个导出功能"，Claude 哗啦啦改了 6 个文件，新增路由、修改 ORM 层、替换了依赖，还顺手"优化"了三个不相关的模块。你翻 git diff 翻了 20 分钟，最后 git reset --hard。

老手先让它读 src/routes/ 和 package.json，然后说"只看不要改，先告诉我你打算怎么加"。等计划确认后，指定"只动 export.ts 和 routes/index.ts，加完跑 npm test"。15 分钟收工，diff 清爽，测试全绿。

差别不在工具，在工作流。

一次好任务的组织：四段式结构

把一次任务拆成四个阶段，每一步人和 AI 各司其职：

阶段	人做什么	Claude Code 做什么
喂上下文	`@`引用关键文件，告诉它"先读哪几个"	读取并理解代码结构与现状
定目标与约束	明确结果、范围、验收标准	提出实现方案，走 Plan 模式先想清楚
执行	切换到 acceptEdits 或 Manual，逐轮 review	编辑文件、跑命令、验证改动
审查	`git diff` 或直接用 Claude 审查输出	跑测试/构建证明改动正确，给出 diff 摘要

这不是理论框架。它直接对应 Claude Code 的三个核心能力：读文件、改文件、跑命令。而控制这三者的阀门是权限模式和提示策略。

喂上下文：让 AI 先"看懂"再动手

Claude Code 的上下文窗口是它最重要的资源。每一条消息、每一个文件读取、每一次命令输出都占据窗口，上下文越满，模型表现越差——开始"遗忘"早先指令，犯更多错误。

所以不是塞得越多越好，而是塞得越精越好。具体做法：

用 `@` 精准喂文件

不要描述"utils 目录下有个文件处理函数"，直接 @src/utils/file.ts。Claude 会先读文件再回应。比手打路径描述快且准。

让 Claude 自己去读

你不需要手动贴代码。告诉它"先读 src/controllers/ 下所有文件，搞清楚现有的 CRUD 模式"，它会自己遍历读完再汇报——比你自己翻代码快。

CLAUDE.md：跨会话的持久记忆

有些东西每轮都要用——构建命令、代码规范、项目架构。把它们写进项目根目录的 CLAUDE.md：

# Build & test commands
npm run build  # TypeScript compilation
npm test       # vitest, coverage in ./coverage/

# Architecture
- src/routes/   : API route definitions
- src/services/ : business logic
- src/db/       : Prisma schemas and migrations

IMPORTANT: Never modify files under src/db/migrations/ directly.
Use `npx prisma migrate dev` instead.

每次会话启动时 Claude 自动加载它。执行 /init 可以让 Claude 自己根据项目结构生成初稿。没有它，每次都要重新解释一遍。

有经验的用户还会给特定目录放子级 CLAUDE.md——Claude 进入该目录干活时自动加载，适合微服务架构中的每个子项目有自己的规范。

先探索，再规划，再动手

不要把"建模、设计、编码"揉成一句话丢进去。拆开：

// 第一步：探索
"切换到 Plan 模式。先读 src/api/ 和 prisma/schema.prisma，
告诉我现在的数据结构和接口是怎样的。"

// 第二步：规划
"基于上面的分析，给添加批量导出功能出一个详细实现计划。
要动哪些文件、每个文件改什么、验收标准是什么。"

// 第三步：执行
"切换到 acceptEdits。按照计划实现，只动 export.ts 和 routes/index.ts。
改完后跑 npm test，测试不过就修复。"

Plan 模式下 Claude 只读不改，可以放心让它随意探索代码库。这是保护机制，也是效率工具——在它真正动刀之前，你有机会纠正方向。

Claude Code 官方文档也推荐这个四段式：Explore → Plan → Implement → Commit。明确说"如果改动用一句话就能描述清，跳过 Plan；改动跨多文件或你对代码不熟悉时，Plan 最有用。"

从对话到多文件改动：读—改—验证循环

Claude Code 做完一次目标不是"改完文件"，而是"改完且验证通过"。它的循环是：

读文件（理解现状）
  → 编辑（按计划改动）
    → 跑命令（测试/构建/lint）
      → 读输出（判断是否通过）
        → 没通过？修复，回到第三步
        → 通过了？报告结果

这循环能跑起来的前提是你给了它可以运行的验证手段。这是 Anthropic 团队内部排在第 1 位的最佳实践——“给 Claude 一个它能跑的通/不通检查”。没有它，AI 只能靠"看起来对"来判断，错误会等着你来发现。

验证手段可以是：

npm test / pytest / go test
npm run build 的退出码
eslint --fix 的输出
甚至是一个对比产出的自定义脚本

一旦有了验证手段，你可以让 Claude 在同一轮里自循环修复：告诉它"改完后跑测试，不过就继续修，最多循环 3 次"。这样你从盯着屏幕变成偶尔扫一眼。

控制改动范围：权限模式是开关，不是装饰

Claude Code 提供了五种权限模式，由 Shift+Tab 循环切换。它们不只是"省得点击"，而是工作流的核心控件：

模式	行为	适合场景
Manual（默认）	每次编辑、每条非只读命令都弹确认	改核心逻辑、你不熟悉的代码
acceptEdits	文件编辑 + 常用命令（mkdir/rm/mv/sed）自动批准	已确认方向，信任具体实现
Plan	只读不写，所有编辑阻止	探索、出方案、需要你点头再动手
auto	分类器模型预审，只拦截风险操作	大任务、想长时间放手但怕出事
bypassPermissions	全部放行	沙箱环境、CI、你完全信任

实际使用中，一个高效的工作流节奏是这样：

Plan 模式探索 + 出方案 → 确认
acceptEdits 执行 → 一边干一边看 diff
遇到敏感操作切回 Manual → 逐条确认
改完切回 Plan → 让它审查自己的改动

acceptEdits 模式下，文件写入和 mkdir、mv、sed 等常用命令自动通过，但只限于工作目录和 additionalDirectories 内。超出范围或触及 .git、.claude/ 等受保护路径时仍会弹确认。这个设计让信任和安全的边界很清晰——你信任它在你划定的范围内干活，但不会给它全盘钥匙。

如果想让审批更省心，用 /permissions 把已知安全的命令（如 npm run lint、git status）加入 allowlist。更激进的做法是开启 auto 模式——一个独立分类器模型实时审查每条命令，只拦截风险行为（越权访问、未知基础设施操作等）。

一个完整示例：给模块加功能并补测试

假设项目是 TypeScript + vitest，要给 userService 加一个 getActiveUsers()。

第一步：喂上下文 + Plan

切换到 Plan 模式。

@src/services/userService.ts  @src/services/__tests__/userService.test.ts
先读这两个文件，告诉我当前的实现和测试覆盖情况。
然后出一个计划：怎么加 getActiveUsers()、怎么补测试。
只读不改，等我确认。

Claude 读完代码，输出计划：

当前 userService 有 getUser(id) 和 createUser(data)，使用 Prisma。
计划：

在 userService.ts 新增 getActiveUsers(filter)，查询 status=‘active’ 的用户

在测试文件中新增 3 个 test case：正常查询、空结果、filter 参数

改动仅限这两个文件

你确认：“计划没问题，开始。”

第二步：执行

切换到 acceptEdits。

按计划实现，完成后跑 npm test -- userService。
如果测试失败，分析原因并修复，最多循环 3 次。

Claude 动手：编辑 userService.ts 加入函数 → 编辑测试文件加入 3 个 case → 跑 npm test -- userService → 看到 3 个新测试全绿 → 报告完成。

第三步：审查

切换到 Plan 模式。

用 git diff 看一下你改了什么，给我一个改动摘要。
确认：没有改其他文件、新函数有类型注解、测试覆盖了边界情况。

Claude 列出 diff 摘要，确认只动了两个文件，函数有完整 JSDoc 和类型，测试覆盖正常/空/带参三种情况。

整个过程你做的：一次确认计划、一次批准执行、一次最终审查。三句话，15 分钟。

对比一把梭的后果：Claude 可能在不知情的情况下动了 prisma.schema、改了其他 service、或者写了个能跑但没测试的函数——等你发现时已经改了一堆，回滚也麻烦。

反模式：哪些用法会让它失控

目标模糊——“帮我优化下这个模块”。给 AI 一个明确的可验证目标：“把 getUser 的数据库查询从 3 次 N+1 减少到 1 次，用 include 预加载关联”。
一次要求太多——“重构整个 API 层”。拆成单文件、单模块的任务，每轮有明确边界。
不给上下文——不 @ 文件，不让它先读相关代码，让它自己猜。AI 会猜错，而且猜错的代价在代码里特别贵。
不 review 直接接受——acceptEdits 快速通过后不看 diff。autopilot 是能力，但代码最终是你的责任。
上下文耗尽后继续——上下文快满时 Claude 开始犯错。如果任务大，拆到多个会话做，用 CLAUDE.md 传递关键信息。或者用 /compact 压缩对话历史。