Claude Code 实战工作流
3.4.1 官方推荐工作流：Explore → Plan → Implement → Commit
Claude Code 的常见推荐工作流可以概括为四阶段：
- Explore（探索）：Plan Mode 下读代码、搜引用，搞清楚现状
- Plan（规划）：出方案、评估边界情况，你审核
- Implement（实施）：切出 Plan Mode，按方案执行
- Commit（提交）：生成 commit message，提交
一轮结束后，回到第 1 步开始下个任务。
各阶段详解：
| 阶段 | 你该做什么 | AI 在做什么 | 推荐模式 |
|---|---|---|---|
| ① Explore（探索） | 告诉 AI 要改动的区域 | 读相关文件、grep、跟引用 | Plan Mode |
| ② Plan（规划） | 让 AI 出详细方案并由你审核 | 生成计划、评估边界情况 | Plan Mode |
| ③ Implement（实施） | 切出 Plan Mode 按计划执行 | 按顺序修改文件、运行构建 | Normal / Auto-Accept |
| ④ Commit（提交） | 让 AI 生成提交消息并 commit | 生成 commit message、可选开 PR | Normal |
提示：为什么要分阶段？试想一下这种体验：你说”加个软删除功能”，15 分钟后 AI 改了 14 个文件、动了全局查询过滤器、破坏了 3 个现有接口——你只能一个一个手工回退。这就是不规划直接干的代价。在 Plan Mode 里多花 5 分钟讨论方案，换来执行阶段节省 30 分钟返工。Plan Mode 的详细用法在4.9 节详讲。
3.4.2 项目设置（6个应该习惯性做的动作）
在开始一个新项目之前，完成以下 6 项设置能让后续开发顺利多倍：
Step 1: 项目初始化 ↓ 描述项目目标 → AI 生成项目骨架 Step 2: 建立 CLAUDE.md（项目上下文） ↓ 可运行 `/init` 让 AI 自动生成 Step 3: 配置权限与默认模式 ↓ .claude/settings.json、复杂项目可默认 plan 模式 Step 4: 功能开发 ↓ 一次一个功能，逐个 Explore→Plan→Implement Step 5: 代码审查与测试 ↓ 用 /review 让 AI 生成测试并跑起来 Step 6: 提交代码 ↓ git commit 保存进度3.4.3 完整示例：用 Claude Code 创建一个 Express Hello World API
Step 1：初始化项目
# 创建项目目录 $ mkdir hello-api $ cd hello-api # 启动 Claude Code $ claude在 Claude Code 的plan mode中输入：
> 我想要使用node.js构建一个前端页面，最后能显示出hello ai coding 几个字，端口号使用3000AI 会依次执行以下操作（每一步都会请求你确认）：
[Claude Code] 将运行命令: npm init -y → 确认？(y/n) y [Claude Code] 将运行命令: npm install express → 确认？(y/n) y [Claude Code] 将创建文件: app.js → 确认？(y/n) y预期生成的核心代码（app.js）：
// 引入 Express 框架 const express = require('express'); // 创建应用实例 const app = express(); // 定义端口号 const PORT = 3000; // 定义 GET /hello 路由 app.get('/hello', (req, res) => { // 返回 JSON 格式的响应 res.json({ message: 'Hello AI Coding!' }); }); // 启动服务器 app.listen(PORT, () => { console.log(`服务器已启动，访问 http://localhost:${PORT}/hello`); });Step 2：运行并验证
在 Claude Code 中输入：
> 请启动这个服务器，然后用 curl 测试 /hello 端点AI 执行的操作：
[Claude Code] 将运行命令: node app.js → 确认？(y/n) y 输出: 服务器已启动，访问 http://localhost:3000/hello你也可以打开浏览器访问http://localhost:3000/hello，应该看到：
{ "message": "Hello AI Coding!" }验证：如果浏览器能看到上面的 JSON 响应，恭喜！你用 Claude Code 成功创建了第一个 API！
Step 3：提交代码
> 请帮我初始化 Git 仓库并提交当前代码，commit message 为 "初始化 Express Hello World API"AI 会执行：
git init git add . git commit -m "初始化 Express Hello World API"3.5 Claude Code 最佳实践
3.5.1 Prompt 编写技巧（针对 Claude Code 场景）
1. 任务描述要具体，不要模糊
差：帮我做一个登录功能 好：在 /api/auth/ 目录下创建登录 API： - POST /api/auth/login - 接受 { email, password } - 使用 bcrypt 验证密码 - 成功返回 JWT token - 使用项目已有的 prisma client 查询 User 表2. 引用已有代码作为参考
好：参考 /api/bookmarks/route.ts 的风格， 为 /api/tags/ 创建类似的 CRUD 接口。 数据模型参见 prisma/schema.prisma 中的 Tag 表。3. 先让AI制定计划，确认后再执行
好：我想给书签管理器添加搜索功能。 请先分析一下需要修改哪些文件，列出计划， 等我确认后再开始实现。4. 一次只做一件事
差：帮我同时添加搜索功能、标签管理、用户认证和导出功能 好：帮我先实现书签搜索功能。具体需求： - 在书签列表页面添加搜索框 - 支持按标题和描述搜索 - 搜索时实时过滤结果（前端过滤即可）3.5.2 上下文管理策略（快速参考）
上面/compact详解已覆盖核心操作，这里给你一个快速决策表：
| 你观察到的情况 | 是什么问题 | 该怎么做 |
|---|---|---|
| 响应变慢、质量下降 | 上下文快满了 | /context看占比 → 高于 60% 就/compact |
| AI 开始"遗忘"早期约定 | 早期信息被挤出窗口 | 立即/compact |
| AI 重复问已回答过的问题 | 上下文混乱 | /clear开新会话 |
| 要切换到完全不同的任务 | 避免上一个任务的思路污染 | /clear开新会话 |
| 想永久记住某条规则 | 跨会话记忆 | /memory开启 Auto Memory 或写入 CLAUDE.md |
3.5.3 Git 集成最佳实践
在深入 Git 技巧之前，先给你一个直观理解：Git 就是你的"游戏存档系统"。哪怕你不是程序员，只要在用 cc 做项目，Git 都是你的生命线。
想象你玩一个 RPG 游戏：打到 BOSS 前存个档 → 打输了就读档重来 → 打赢了就存新档继续。Git 在项目中就是完全一样的东西：打到一个满意的节点存一档，后面翻车就读档回来。
注意：cc 有不确定性，这不是 bug 是特性：cc 不管是写代码还是其他文档操作，都有不确定性——同一个需求问两次，可能得到不同的实现。所以养成一个肌肉记忆：每做完一步就让 cc 存档一步。有 Git 兜底，你才能安心让 cc 去尝试各种方案。
Mac 自带 Git，Windows 让 cc 帮你装。最好建个 GitHub 账号——远程仓库可以让你在其他电脑上拉下存档点继续工作，也方便协作。Git 的下载、安装、登录、提交、回滚，全都可以让 cc 用自然语言帮你完成，比如说：
> 帮我下载 Git 并跟我的 GitHub 账号绑定 > 帮我把现在的代码提交到远程仓库 > 回滚到上一个存档版本黄金法则：在让AI做大修改之前，先 commit 开发流程： 1. git commit → 保存当前状态（"存档"） 2. 让 AI 实现新功能 3. 测试功能是否正常 ├── 正常 → git commit → 继续下一个功能 └── 有问题 → git checkout . → 回到步骤1，换个方式重试# 实际命令示例 # 1. 开始新功能前，先保存 $ git add . && git commit -m "开始添加搜索功能前的存档" # 2. 在 Claude Code 中实现功能... # （如果功能做坏了） # 3. 回退到存档点 $ git checkout . # （如果功能做好了） # 3. 保存新功能 $ git add . && git commit -m "完成搜索功能"避坑：很多初学者不 commit 就让 AI 大改特改，结果改坏了却无法回退。这是AI编程中最常见也最痛苦的失误。"改之前先存档"，记住这句话。
3.5.4 费用控制策略
| 策略 | 方法 | 节省比例 |
|---|---|---|
| 分级使用 | 简单任务用 Haiku/DeepSeek，复杂任务用 Sonnet | 30-50% |
| 精准描述 | 减少来回修改次数 | 20-30% |
| 及时 /compact | 避免重复发送长上下文 | 10-20% |
| 使用 /cost 监控 | 实时了解消耗 | - |
| 设置预算上限 | Anthropic Console 中设置月度限额 | 防止超支 |
> /cost AI: 当前会话费用统计： 输入 Token: 15,234 输出 Token: 8,721 估算费用: $0.183.5.5 大型代码库最佳实践（Anthropic 官方推荐）
以上技巧偏通用。如果你接手的是一个多人协作、几十万行以上的大型代码库，Anthropic 官方在大型代码库实践中给出过多条专门建议。核心矛盾是：即使模型上下文已经很长，真实代码库仍然可能远超窗口上限。前 3 条是纪律，后 3 条是武器。
① 用/init自动生成 CLAUDE.md（项目初始化）
第一次在一个新项目里跑 Claude Code，第一件事就是/init：
> /initAI 会自动浏览项目目录、识别技术栈、读 README 和关键配置文件，生成一份初版CLAUDE.md。然后你只要在它的基础上手工补充三类信息：
| 必补内容 | 为什么 | 示例 |
|---|---|---|
| 项目目录地图 | 让 AI 知道“去哪儿找代码” | 认证逻辑在 src/auth/，UI 组件在 src/components/ |
| 不要碰的禁区 | 防止 AI 改坏 | 不要修改 prisma/migrations/，不要动 vendor/ |
| 团队约定 | 风格统一 | 所有 API 必须返回 { success, data, error } |
提示：CLAUDE.md 是“起点上下文”，不是“全部上下文”。它就像一份给新人的入职手册，AI 看完后再现场探索代码——这正是 Agentic Search 的工作方式（参见 2.2.1 节）。
② 任务粒度要小且聚焦（避免“万能 prompt”）
大型代码库里最害人的就是“一句话扔给 AI 整个大需求”。正确做法：
反例：帮我重构整个支付模块，加入新风控、新对账、新通知、新报表 正解：第一步——在 src/payment/risk/ 下抽出风控规则引擎， 接口签名见 docs/risk-rules.md，先不动调用方代码经验值：每个 Claude Code 任务 ≤ 涉及 5 个文件 / 200 行代码改动。超过这个量级就该拆。
③ 频繁重置上下文（/clear是好朋友）
很多新手以为对话越长 AI 越懂自己，这恰恰是大型代码库里最大的坑：
- 上下文里塞的越多，无关代码片段越多，AI 越容易抓错重点
- 上一任务的失败尝试、错路径、错假设，会污染下一个任务
官方建议：
| 时机 | 操作 | 区别 |
|---|---|---|
| 一个独立任务结束（PR 提交后） | /clear | 完全清空对话，从零开始 |
| 同一任务内对话过长 | /compact | 压缩历史摘要，保留关键决策 |
| 想换条思路重做 | 退出claude重新启动 | 连状态栏模式都重置 |
核心心法：宁可“多 clear 几次重新介绍背景”，也不要“一直聊一直聊”。每个
/clear都是给 AI 一次重新聚焦的机会。
④ 复杂任务从 Plan Mode 起手（权限控制）
详见 4.9 节。一句话：陌生代码库或一动牵全身的修改，永远先/plan或Shift+Tab×2，让 AI 在只读模式下先勘探出方案再动手，回退成本几乎为零。
⑤ 用 Skills 与 Subagents 卸载长任务
大型代码库里有些“调研型任务”天生很费 token：
- 找出所有调用了某废弃 API 的地方
- 梳理某个模块的依赖图
- 跨 50 个文件的批量重命名前的影响评估
这类任务不要让主会话亲自做，而是：
- 派 Subagent：让一个独立的子代理去调研，最后只把结论带回主上下文（Plan Mode 下会自动调用）
- 写成 Skill：把高频调研流程封装成 Skill，每次一键触发（详见第四部分）
这样主会话的上下文窗口尽量留给“看结论、做决策、写代码”这些核心动作。
⑥ 接入 MCP / LSP（给 AI 装上团队协作工具）
一个真正的工程师不是只看代码，还会查 Jira、读 Confluence、连数据库、用 IDE 的“跳到定义”。Claude Code 通过MCP（Model Context Protocol）把这些能力接进来：
| 接入对象 | 解决什么 | 典型场景 |
|---|---|---|
| GitHub MCP | 读 PR、Issue、CI 日志 | “这个 bug 在 PR #1234 里讨论过，看一下” |
| 数据库 MCP（Postgres / MySQL） | 直接查数据 | “线上 user 表里有多少条 deleted_at 不为空的” |
| Jira / Linear MCP | 读任务卡 | “按 PROJ-123 的需求实现” |
| LSP（语言服务器）集成 | 精确跳转、查类型、找引用 | 等同于 IDE 的“查找所有引用” |
| Sentry / Datadog MCP | 读告警、堆栈 | “上一小时的 5xx 错误调一下” |
提示：配置入口：
.claude/settings.json中的mcpServers字段，或运行claude mcp add ...。MCP 详细配置在第四部分 3.6 节讲解。
3.5.6 大型代码库最佳实践速查表
| 实践 | 命令/入口 | 何时做 | 收益 |
|---|---|---|---|
| 项目初始化 | /init+ 手工补充 | 第一次进入项目 | 让 AI 知道地图与禁区 |
| 任务拆分 | 心法（无命令） | 每次提需求前 | 避免 AI 改坏一大片 |
| 上下文重置 | /clear//compact | 任务结束 / 上下文过长 | 避免污染、节省 token |
| 规划优先 | /plan或Shift+Tab×2 | 复杂任务起手 | 先勘探后动手 |
| 任务卸载 | Subagent / Skill | 高频调研类任务 | 保护主上下文 |
| 工具接入 | claude mcp add ... | 项目初配 | 让 AI 看见“代码之外” |
3.5.7 三个容易被忽视的官方进阶建议
这三点在官方博客里被反复强调，但实际使用中最容易被新手跳过。
1. 在子目录初始化 Claude，别从仓库根目录开始
这点在 monorepo 里反直觉但极重要：
反例：在 monorepo 根目录下启动 user@monorepo $ claude # AI 看到三百个服务、上千个包，上下文污染严重 正解：进入你要改的子目录启动 user@monorepo $ cd services/payment user@monorepo/services/payment $ claude # Claude 会自动向上遍历加载所有 CLAUDE.md（根目录的也会加） # 但工作范围被精准限定在了相关代码区域配套做法：每个子目录都放一份小的CLAUDE.md，写明该目录专用的测试与 lint 命令。不要让 AI 改了一个服务就去跑整个仓的测试套件——那就等着超时吧。
2. 配置要定期审查（每 3-6 个月）
为当前模型写的指令，在下一代模型上可能适得其反。官方举了两个真实例子：
| 过期配置 | 何时有效 | 为何失效 |
|---|---|---|
CLAUDE.md里要求“每次重构只改一个文件” | 老模型需要保持专注 | 新模型能跨文件协调编辑，这条反而是枷锁 |
Hook 每次文件写入时跑p4 edit | Claude 未原生支持 Perforce 时 | Claude Code 已原生支持 Perforce，这个 Hook 变多余 |
提示：实践建议：设个日历提醒，每 3-6 个月、或每次大模型发布后，重读一遍
CLAUDE.md/.claude/settings.json/.claude/hooks/.claude/skills，问三个问题：“这条还需要吗？”“现在有更好的写法吗？”“这条是在弥补哪代模型的缺陷？”
注意：预警信号：如果你觉得 Claude Code 表现到了某个瓶颈怎么也上不去，问题很可能不在模型，而在你的配置没跟上。模型都已经往前跑了，你的 CLAUDE.md 可能还停在三个月前。
3. 团队内应该有个“人”负责 Claude Code（DRI / Agent Manager）
这点是面向团队使用者的，个人开发者可以跳过。Anthropic 观察到：推广最快的组织，都是“先有一小队人把基础设施搭好”才大面积开放的。
| 规模 | 必须人选 | 职责 |
|---|---|---|
| 小团队（< 20 人） | DRI（直接责任人），选一个有兴趣的人选充当 | 项目级 CLAUDE.md、共享的 Skills、Plugins 选型 |
| 中型企业 | Agent Manager（半PM 半工程师） | 跨团队推行、权限策略、接入安全与合规 |
| 大型/金融医疗受监管企业 | 跨职能工作组 | 工程 + 安全 + 治理 + 合规代表同桌定义需求与路线图 |
提示：为什么重要：开发者第一次接触 Claude Code 的体验决定了后面全公司顺不顺推。如果第一次就是“AI 乱改东西”，要翻盘就难了。“野蛮生长”能激发热情，但缺了组织层面的收敛，好实践会变成“部落知识”。
3.5.8 企业级部署三阶段（面向团队负责人）
如果你是要在企业里推广 Claude Code 的人，Anthropic 推荐的路径是：阶段 1 先由小队搭好工具链和规范 → 阶段 2 小范围试点 → 阶段 3 大面积推广。核心原则是”开发者第一次接触就能跑通”，第一印象坏了后面很难翻盘。
3.6 新项目启动套件：5 分钟配好，以后每个项目都不用再教
本节目标：掌握一套可复用的配置模板，新项目打开 Claude Code 就能直接干活
3.6.1 为什么需要启动套件
每个新项目打开 Claude Code，它都像个刚入职的新人——不知道你的技术栈、不知道哪些文件不能碰、不知道你的规范。你得从零教起：
- 改一个 API，Claude 直接在组件文件里写 SQL——它不知道你的数据库操作全在
src/lib/services/里，没人告诉过它 - 每执行一个命令弹一次权限确认，一个下午点了 30 次 Allow
- commit message 格式每次都靠临时编
默认的 Claude Code 是什么都能做、什么都不知道的通用助手。通用不是好事。
这套配置把"通用"变成"你的项目的专属"。核心思路：把一次性的解释成本，变成可复用的配置文件。4 个文件 + 9 个命令，放到任何项目里就能用。
