Claude Code 八个月实战:5层工作流告别“重复解释”,把AI训练成资深队友

很多人把 Claude Code 当成高级版 ChatGPT 用:打开终端、问个问题、关闭。第二天再打开,又要把项目背景从头到尾解释一遍。

症状: 每次对话,20% 的时间都浪费在重新建立上下文。
病根: 没有项目记忆,也没有工作流纪律。

这篇内容是我连续 8 个月每天使用 Claude Code 后,提炼出的 5 层实战工作流。每一层都建立在前一层之上,跳过任何一层,整体都会垮掉。


第一层:CLAUDE.md —— 项目的“记忆锚点”

这是地基。没有它,后面的技巧全部失效。

CLAUDE.md 是一个放在项目根目录的文件。每次开启新对话,Claude 会自动读取它。它负责告诉 Claude:

  • 这个项目是做什么的(一句话说清楚)
  • 技术栈具体是什么(不要只写“Python 后端”)
  • 整体架构长什么样(那些你需要翻 3 个文件才能理解的逻辑)
  • 项目独有的约定(不是“要写干净代码”这种废话)
  • 质量优先级是什么

反面教材(你可能写过类似的):

<!-- 这种写法太笼统,对 AI 没有任何额外价值 -->
# My Project
A web application built with Python and FastAPI.

## Development
<!-- 下面这些都是通用常识,Claude 本来就知道 -->
- Write clean code
- Add unit tests
- Use Git

正确示范:

# CLAUDE.md

## Project Overview
<!-- 一句话定位,让 AI 秒懂业务场景 -->
Internal RAG knowledge base serving 500+ employees.

## Tech Stack
<!-- 明确技术栈,防止 AI 猜错框架或版本 -->
FastAPI + LangChain + Milvus + PostgreSQL + Redis

## Commands
<!-- 常用命令写清楚,AI 执行时就不会瞎猜 -->
- Start: `uvicorn app.main:app --reload --port 8080`
- Test: `pytest -x --cov=app --cov-report=term-missing`

## Architecture
<!-- 用文本画架构图,AI 一眼看懂数据流向 -->
Request flow: router → service → retriever → Milvus
                             → generator → LLM API
Key directories:
- app/router/  - API layer
- app/service/ - Business logic orchestration
- app/retriever/ - Retrieval strategies (vector/BM25/hybrid)
- app/generator/ - LLM calls and prompt management

## Key Conventions
<!-- 只写这个项目特有的规矩,通用的不用提 -->
- All APIs return `{"data": ..., "error": null}`
- Retrieval results MUST include source field
- Milvus collection naming: `{env}_{doc_type}`

核心原则: 只写对你们项目“独一无二”的东西。Git 怎么用、要写好代码,这些不用你教。


第二层:Plan Mode —— 先开枪,先画靶

触发条件: 任何涉及 3 个以上文件或影响架构的改动。

操作方式:

  1. 让 Claude 先探索现有代码(模块、数据流、API 结构)
  2. 由 Claude 设计一份实现方案
  3. 你看完方案,确认或修改
  4. 确认无误后,Claude 才开始写代码

常见翻车现场: 你丢一句“重构整个鉴权模块”,Claude 一口气改了 12 个文件,结果全崩了,你根本不知道从哪开始修。

正确姿势: 先说“我想加个混合搜索,我们先规划一下”。Claude 探索完代码后给出架构提案,你确认无误,再分步实施。


第三层:Small Tasks —— 一次只做一件事

每个任务只改动一个逻辑单元。每完成一步,项目都要能跑通。

错误示范:

<!-- 任务太大,一次动 8 个文件,翻车概率极高 -->
You: "Refactor the entire retriever module."
Claude: [changes 8 files] → total chaos

正确示范:

<!-- 把大任务拆成小步骤,每步只改一个文件 -->
You: "Step 1: Extract BM25 logic into retriever/bm25.py"
Claude: [changes 1 file, tests pass]
You: "Step 2: Add RRF fusion in retriever/fusion.py"
Claude: [changes 1 file, tests pass]
You: "Commit these two steps."

为什么这么干: 每次提交都是一个检查点。一旦出问题,你能瞬间定位到是哪个改动引起的。


第四层:Git —— 你的“后悔药”

每完成一个小任务就提交。这不只是版本控制,更是你的项目日记。

# 每次提交聚焦一个功能点,提交历史就是最好的项目日志
feat: extract BM25 retriever into standalone module
feat: add RRF fusion for hybrid search
fix: Chinese tokenization for BM25 queries

半年后回头看,你能从记录里追溯清楚每一个设计决策的来龙去脉。


第五层:Worktree —— 并行开发不打架

当你正在开发功能 A,却突然要紧急修复 Bug B,不想切换上下文时:

# 基于当前分支,创建一个独立的工作目录
git worktree add ../bugfix .claude/worktrees/hotfix
cd ../bugfix
# 在完全隔离的环境里修复 Bug B
# 修复完提交后,返回原分支
cd -
# 清理临时工作区
git worktree prune

或者更简单地告诉 Claude:“Use a worktree for this.” 它会自动帮你搞定隔离。


额外加成:Context Compounding —— 知识的复利

你做的每一个技术决策、发现的每一个模式,都要记下来。它会不断复利增值。

  • 项目级:靠 CLAUDE.md 存档。存放架构设计、代码规范、关键决策。
  • 会话级:靠记忆系统存档。存放你的个人偏好、反馈和纠正记录。
  • 知识库级:靠笔记关联存档。存放方法论、通用模式和抽象概念。

8 个月后,AI 不只懂你的项目,它甚至懂你的思维方式。


把它们串起来

假设你要加一个“CSV 导出”功能,整个流程是这样的:

# 第一步:自动加载项目背景,AI 知道路由和逻辑在哪
CLAUDE.md      → Auto-loads project context. Claude knows where the API routes live.
# 第二步:先规划 CSV 导出功能,确认方案后再动手
Plan Mode      → "Let's plan the CSV export feature first" → Approval before code.
# 第三步:拆成小步骤执行,比如先加路由、再加按钮
Small Tasks    → Step 1: Add export route. Step 2: Add frontend button.
# 第四步:每步完成后提交,随时能回滚
Git            → Commit after each step. Rollback if needed.
# 第五步:与此同时,用 worktree 并行修登录 Bug,互不干扰
Worktree       → Meanwhile, fix a login bug in isolation.

结果: 功能交付更快,Bug 可追溯,每次打开新项目都自带完整上下文。


快速上手清单

# Day 1: 花 30 分钟写好 CLAUDE.md,只写项目特有的东西
Day 1: Write a proper CLAUDE.md (30 min — just write the unique stuff)
# Day 2: 涉及多文件改动前,先说 "Let's plan first"
Day 2: Say "Let's plan first" before cross-file changes
# Day 3: 把一个大任务拆成 3 到 5 个小步骤
Day 3: Break one big task into 3-5 small steps
# Day 5: 尝试用 worktree 处理并行需求
Day 5: Try Worktree — "Use a worktree for this"
# Day 7: 做完第一个设计决策后,把它记录下来
Day 7: After your first design decision, write a Memory
# Day 14: 回顾两周的提交记录,你会发现值得固化的模式
Day 14: Review two weeks of commits — you'll see patterns worth documenting

两周之后,你就不再是“跟 Claude 聊天”了,而是在高效地产出

类似文章