Claude Code 深度使用与进阶技巧

金王大帝k 焰灵焚心

162人浏览 · 2026-07-19 21:24:36

金王大帝k 焰灵焚心 · 2026-07-19 21:24:36 发布

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 几个字，端口号使用3000
AI 会依次执行以下操作（每一步都会请求你确认）：

[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);
});
claude-express-workflow

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”
project-tree-git-flow

3.5 Claude Code 最佳实践
3.5.1 Prompt 编写技巧（针对 Claude Code 场景）

任务描述要具体，不要模糊

差：帮我做一个登录功能
好：在 /api/auth/ 目录下创建登录 API：

POST /api/auth/login
接受 { email, password }
使用 bcrypt 验证密码
成功返回 JWT token
使用项目已有的 prisma client 查询 User 表

引用已有代码作为参考

好：参考 /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

开发流程：

git commit → 保存当前状态（“存档”）
让 AI 实现新功能
测试功能是否正常
├── 正常 → 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.18
3.5.5 大型代码库最佳实践（Anthropic 官方推荐）
以上技巧偏通用。如果你接手的是一个多人协作、几十万行以上的大型代码库，Anthropic 官方在大型代码库实践中给出过多条专门建议。核心矛盾是：即使模型上下文已经很长，真实代码库仍然可能远超窗口上限。前 3 条是纪律，后 3 条是武器。

① 用 /init 自动生成 CLAUDE.md（项目初始化）

第一次在一个新项目里跑 Claude Code，第一件事就是 /init：

/init
AI 会自动浏览项目目录、识别技术栈、读 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 三个容易被忽视的官方进阶建议
这三点在官方博客里被反复强调，但实际使用中最容易被新手跳过。

在子目录初始化 Claude，别从仓库根目录开始

这点在 monorepo 里反直觉但极重要：

反例：在 monorepo 根目录下启动
user@monorepo $ claude

AI 看到三百个服务、上千个包，上下文污染严重

正解：进入你要改的子目录启动
user@monorepo $ cd services/payment
user@monorepo/services/payment $ claude

Claude 会自动向上遍历加载所有 CLAUDE.md（根目录的也会加）

但工作范围被精准限定在了相关代码区域

配套做法：每个子目录都放一份小的 CLAUDE.md，写明该目录专用的测试与 lint 命令。不要让 AI 改了一个服务就去跑整个仓的测试套件——那就等着超时吧。

配置要定期审查（每 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 可能还停在三个月前。

团队内应该有个“人”负责 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 个命令，放到任何项目里就能用。

3.6.2 第一个文件：CLAUDE.md
CLAUDE.md 是 Claude Code 启动时第一个读的文件。写在里面的东西，Claude 在每一次对话里自动遵守。全局 CLAUDE.md 的精简模板：

沟通方式

默认中文回复；代码、命令、变量名、文件路径保持英文
结论先行，简洁直接，不先铺垫背景
不谄媚，不夸"这是个很好的问题"，不以"当然可以"开头
给真实判断——方案有问题直接指出，发现更好做法主动说明

Git

不自动 git commit 或 git push，除非我明确要求
提交前先展示将要提交的变更摘要
commit message 使用简洁英文

红线操作

以下操作即使在 auto-accept 模式下也必须先问我：

删除文件、目录或 git 历史
修改 .env、密钥、token、证书、CI/CD 配置
git push、git rebase、git reset --hard、强制推送
公开发布（npm publish、生产部署等）
项目级的 CLAUDE.md 再加一层：技术栈、目录结构、commit 格式、禁区（如不要碰 migrations/ 目录）。两个文件叠加，Claude 第一次打开项目就知道——跑测试是 pnpm vitest run 而不是 npm test，数据库操作全在 src/lib/services/ 里。

维护策略：每被 Claude 坑一次，立刻加一条到 CLAUDE.md。过时的规则删掉，内容保持精炼。三个月下来，这个文件就是"这个项目 Claude 犯过的所有错误的预防清单"。最有生产力的一句话是：“更新 CLAUDE.md，让这件事不再发生”。

3.6.3 第二个文件：settings.json
用 Claude Code 最烦的就是弹窗。这个文件把"该放行的放行、该锁住的锁住"写死：

{
“permissions”: {
“allow”: [
“Read”, “Glob”, “Grep”, “Edit”, “MultiEdit”,
“Write(src/)", "Write(tests/)”,
“Bash(npm *)”, “Bash(pnpm *)”, “Bash(git status)”, “Bash(git diff *)”,
“Bash(git log *)”, “Bash(git add *)”, “Bash(git commit )",
“Bash(cat )", “Bash(head )", “Bash(tail )", “Bash(find )"
],
“deny”: [
"Read(**/.env)”, "Read(**/.pem)”, "Read(**/.key)”,
“Read(/secrets/)”, “Read(/credentials/)”,
"Write(**/.env)”, “Write(/secrets/)”,
“Write(package-lock.json)”, "Write(.github/workflows/)”,
“Bash(rm -rf *)”, “Bash(sudo *)”, “Bash(git push *)”,
“Bash(git merge *)”, “Bash(git rebase *)”,
“Bash(docker *)”, “Bash(curl * | sh)”, “Bash(chmod *)”
],
“defaultMode”: “acceptEdits”
}
}
allow 白名单：日常安全操作，不应该每次都问——读文件、写源码、跑测试、git 日常命令。