前言

经过前三篇的入门，你已经了解了 Claude Code 的安装配置、多模型适配以及权限系统的设计。本篇将回归到日常开发中最基础也最核心的部分：如何高效使用 Claude Code。我们将系统梳理启动方式、核心操作、项目级记忆文件 CLAUDE.md、常用命令、典型使用场景以及高质量 Prompt 的写法。无论你是新手还是老手，这篇文章都能帮你更充分地发挥 Claude Code 的潜力。

1. 启动与会话管理

Claude Code 提供了多种启动方式，适配不同的使用场景。

1.1 交互模式（最常用）

直接运行 claude 进入交互式对话界面，适合持续性的开发任务：

claude

进入后，你可以连续输入多轮指令，Claude Code 会在当前项目目录的上下文中工作。

1.2 单次任务模式

将指令以参数形式传入，Claude Code 执行完毕后自动退出，适合脚本调用或快速查询：

# 快速查询
claude "统计 src 目录下有多少个 TypeScript 文件"

# 搭配管道使用，将外部输入传递给 Claude Code
cat error.log | claude "分析这段日志中的报错原因"

# 结合 git diff 做代码审查
git diff HEAD~1 | claude "审查这次提交的代码变更，指出潜在问题"

1.3 恢复上次会话

继续上一次未完成的对话，保留完整的上下文：

claude -c
# 或完整写法
claude --continue

适用场景：中途关闭终端后想继续之前的任务，或者需要基于上次对话结果做后续操作。

1.4 恢复指定会话

如果你有多个历史会话，可以交互式地选择要恢复哪一个：

claude -r
# 或完整写法
claude --resume

1.5 指定工作目录

在不切换终端目录的情况下，让 Claude Code 在目标项目中工作：

claude --cwd /path/to/project

2. 核心操作

Claude Code 的核心能力可以归纳为三类：读取理解、编辑生成、命令执行。

2.1 读取文件

让 Claude Code 阅读并分析文件内容：

> 读取 src/config.ts 并逐项解释每个配置字段的作用
> package.json 中有哪些 devDependencies？各自的用途是什么？
> 对比 src/utils/old.ts 和 src/utils/new.ts 的差异

Claude Code 会自动定位并读取文件，无需手动提供文件内容。如果文件路径模糊，它会先搜索项目结构再确认。

2.2 编辑与生成文件

创建新文件或修改已有文件：

> 创建一个 .gitignore 文件，包含 Node.js 项目常见的忽略规则
> 在 src/utils/date.ts 中添加一个将 ISO 字符串转为本地日期的函数
> 将 src/api/user.js 从 JavaScript 转换为 TypeScript

关键行为：Claude Code 会先展示即将进行的变更内容（以 diff 形式），等待你确认后才真正写入文件。你可以在确认前审查每一处修改。

2.3 执行终端命令

Claude Code 可以代你执行 shell 命令：

> 运行测试并总结失败的用例
> 安装 zod 和 @types/node 作为开发依赖
> 执行 npm run build，如果报错就分析原因并修复

同样，命令执行前会显示具体内容并等待确认。对于「分析报错并修复」这类复合指令，Claude Code 会自动形成 执行 → 分析 → 修复 → 验证 的工作循环。

3. 项目初始化与 CLAUDE.md

3.1 使用 /init 命令

在新项目中首次使用 Claude Code 时，建议先运行 /init：

> /init

Claude Code 会自动完成以下步骤：

• 扫描项目结构 — 识别目录组织、文件类型分布

• 识别技术栈 — 检测框架、语言、构建工具、包管理器等

• 生成 CLAUDE.md — 在项目根目录创建配置文件，记录项目约定

3.2 CLAUDE.md 的作用

CLAUDE.md 是 Claude Code 的项目级记忆文件。每次启动时，Claude Code 会自动读取该文件，据此调整行为。它的作用类似于团队的开发规范文档，但面向的读者是 Claude Code。

典型的 CLAUDE.md 内容（以 Vue 3 项目为例）：

# 项目说明

这是一个基于 Next.js 14 + TypeScript 的电商后台管理系统。

## 技术栈

- 框架：Next.js 14（App Router）
- 语言：TypeScript（strict 模式）
- 样式：Tailwind CSS
- 状态管理：Zustand
- API 请求：基于 fetch 的自定义封装（src/lib/request.ts）

## 代码规范

- 组件使用函数式组件 + Hooks，禁止使用 class 组件
- 文件命名：组件用 PascalCase（如 UserCard.tsx），工具函数用 camelCase（如 formatDate.ts）
- 禁止使用 any 类型，必须显式声明类型
- 每个 API 路由必须包含错误处理和参数校验

## 常用命令

- `pnpm dev` — 启动开发服务器
- `pnpm build` — 构建生产版本
- `pnpm test` — 运行测试（Vitest）
- `pnpm lint` — 执行 ESLint 检查

## 目录结构

- src/app — 页面路由
- src/components — 可复用组件
- src/lib — 工具库和通用逻辑
- src/types — TypeScript 类型定义

建议：/init 生成的内容是起点，你应该根据实际情况持续维护和完善 CLAUDE.md。项目特有的约定越清晰，Claude Code 的输出质量越高。

3.3 CLAUDE.md 的层级

Claude Code 支持多层级 CLAUDE.md 文件：

位置	作用域	典型用途
~/.claude/CLAUDE.md	全局（所有项目）	个人偏好、通用编码风格
项目根目录/CLAUDE.md	当前项目	技术栈、项目规范、常用命令
项目根目录/CLAUDE.local.md	个人本地	个人偏好，不提交到 Git
子目录/CLAUDE.md	特定模块	模块特有的约定或注意事项

多个层级的文件会合并生效，更具体的层级优先级更高。

3.4 CLAUDE.md 的维护策略

CLAUDE.md 不是一次性生成的静态文档，而是需要持续维护的活文档。它的质量直接决定 Claude Code 的长期输出水平。

3.4.1 编写原则：写什么、不写什么

应该写入的内容：

类别	说明	示例
项目特有的约定	只记录本项目特殊规则	「本项目的 request 函数已内置 token，不要手动添加 Authorization header」
Claude Code 反复犯错的点	纠正一次不够，写入 CLAUDE.md 才能根治	「创建组件时禁止使用 Options API，必须使用 <script setup>」
可运行的代码示例	比纯文字描述更精确，Claude Code 可以直接模仿	在 API 请求约定后附上一段完整的请求函数示例
常用命令和脚本	避免 Claude Code 猜测或使用错误的命令	明确列出 dev / build / test / lint 的完整命令
目录结构和文件职责	帮助 Claude Code 知道代码该放哪里	「页面组件放 views/，可复用组件放 components/」

不应该写入的内容：

• 通用编程常识（「变量命名要有意义」这类规则 Claude Code 本身就知道）

• 临时性的 TODO（用 issue 或注释追踪）

• 大段复制的外部文档（只写项目对框架的特殊用法）

• 过于细碎的格式规则（由 ESLint/Prettier 等工具强制执行）

3.4.2 更新时机：什么时候该动 CLAUDE.md

将以下场景作为更新 CLAUDE.md 的触发信号：

• 纠错后立即记录：当你纠正了 Claude Code 的错误，立刻考虑这个错误会不会再犯？如果会，写入 CLAUDE.md。

• 技术栈变更时：升级框架、替换依赖、调整构建工具时，同步更新技术栈和命令说明。

• 新成员反馈 Claude Code 不好用时：通常意味着 CLAUDE.md 中缺少关键约定。

• 定期审查：每月一次，对照检查清单清理过时内容。

3.4.3 组织策略：如何结构化管理

• 根级 CLAUDE.md 保持精简：控制在 150–200 行以内，聚焦全局性约定。

• 子目录 CLAUDE.md 承载模块细节：将模块级别的详细规范下沉到对应子目录中，Claude Code 只在操作该目录下的文件时才会加载对应的子 CLAUDE.md，既节省 Token 又更精准。

• 全局个人偏好放在用户级 CLAUDE.md：在 ~/.claude/CLAUDE.md 中放置跨项目通用的个人偏好。

3.4.4 常见误区

• 误区 1：把 CLAUDE.md 当百科全书（写了 500 行，关键规则被淹没）→ 正确做法：根级文件精简，细节下沉。

• 误区 2：只写规则，不给示例 → 正确做法：紧跟一段符合规范的完整代码示例。

• 误区 3：写入后从不更新 → 正确做法：将 CLAUDE.md 纳入日常维护流程。

• 误区 4：团队成员各自维护互相覆盖 → 正确做法：通过 PR 审查修改，指定 owner。

• 误区 5：用 CLAUDE.md 替代 lint 工具 → 正确做法：格式化规则交给 ESLint/Prettier，CLAUDE.md 只需写一句引用。

3.5 CLAUDE.md 的模板

下面提供几份经过实战打磨的模板，覆盖主流前后端技术栈，你可以根据自己的项目直接复制后修改。模板中用 「」 标注的地方需要替换为你的项目实际信息。

模板1：Vue 3 前端项目

# 项目说明

「项目名称」— 基于 Vue 3 的「项目简要描述，如：企业级后台管理系统」。

## 技术栈

- 框架：Vue 3.4+（Composition API + <script setup> 语法）
- 语言：TypeScript（strict 模式）
- 构建工具：Vite 5
- 路由：Vue Router 4
- 状态管理：Pinia
- HTTP 请求：Axios（封装在 src/utils/request.ts）
- UI 组件库：Element Plus
- 样式方案：SCSS + CSS Modules
- 包管理器：pnpm

## 代码规范

### 组件规范
- 必须使用 <script setup lang="ts"> 语法，禁止 Options API
- 组件文件使用 PascalCase 命名（如 UserProfile.vue）
- 组件 props 必须使用 defineProps<T>() 显式声明类型，禁止运行时声明
- 事件使用 defineEmits<T>() 声明，事件名使用 camelCase
- 组件内逻辑超过 100 行时，应提取到同目录的 useXxx.ts composable 中

### TypeScript 规范
- 禁止使用 any，确需跳过类型检查时使用 unknown 并做类型收窄
- 接口定义放在 src/types/ 目录，按业务模块分文件（如 user.d.ts、order.d.ts）
- API 响应类型必须定义，不允许直接使用 res.data 未断言的返回

### 样式规范
- 组件样式必须使用 scoped 或 CSS Modules，禁止全局样式污染
- 颜色、字号等设计变量使用 src/styles/variables.scss 中的变量
- 响应式断点使用项目预设的 mixin：@include respond-to(mobile)

### 命名规范
- 目录名：kebab-case（如 user-management/）
- 工具函数文件：camelCase（如 formatDate.ts）
- 常量文件：UPPER_SNAKE_CASE 导出（如 export const MAX_PAGE_SIZE = 50）
- composable 函数以 use 开头（如 useUserList.ts）

## 目录结构

- src/views/ — 页面组件（与路由一一对应）
- src/components/ — 全局可复用组件
- src/components/business/ — 业务组件（仅在特定模块复用）
- src/composables/ — 全局 composable 函数
- src/api/ — API 请求函数（按模块分文件，如 api/user.ts）
- src/types/ — TypeScript 类型定义
- src/stores/ — Pinia store（按模块分文件）
- src/utils/ — 工具函数
- src/styles/ — 全局样式和变量
- src/router/ — 路由配置
- src/assets/ — 静态资源

## API 请求约定

- 所有请求函数在 src/api/ 目录中按模块组织
- 请求函数命名规则：动词 + 资源名（如 getUserList、createOrder、deleteProduct）
- 请求函数必须声明入参和返回值类型
- 示例：

  // src/api/user.ts
  import request from '@/utils/request'
  import type { UserInfo, UserQuery } from '@/types/user'

  export function getUserList(params: UserQuery) {
    return request.get<PageResult<UserInfo>>('/api/users', { params })
  }

## 常用命令

- `pnpm dev` — 启动开发服务器（默认端口 5173）
- `pnpm build` — 构建生产版本
- `pnpm preview` — 本地预览生产构建结果
- `pnpm lint` — ESLint 检查
- `pnpm lint:fix` — ESLint 自动修复
- `pnpm type-check` — TypeScript 类型检查

## 注意事项

- 路由懒加载使用 () => import() 语法，不要用 require
- Element Plus 使用按需导入（unplugin-vue-components 自动注册）
- 环境变量前缀为 VITE_，通过 import.meta.env.VITE_XXX 访问
- 所有表单提交前必须做前端校验，使用 Element Plus 的 FormRules
- 国际化使用 vue-i18n，文案文件在 src/locales/ 下

4. 常用斜杠命令

斜杠命令是 Claude Code 的内置快捷操作，以 / 开头输入：

命令	功能说明
/init	初始化项目，生成 CLAUDE.md
/help	显示帮助信息和可用命令列表
/clear	清除当前会话的对话历史
/compact	压缩对话上下文，释放 Token 空间
/config	查看或修改 Claude Code 配置
/cost	查看当前会话的 Token 消耗量
/doctor	检查运行环境和配置是否正常
/commit	基于当前变更智能生成 commit 信息

常用命令详解

• /clear — 当对话过长导致上下文混乱时，清除历史重新开始。

• /compact — 不想丢失上下文但 Token 消耗过高时，压缩对话历史。可以附加提示词指导压缩策略，例如 /compact 保留关于数据库迁移的讨论内容。

• /commit — 自动分析暂存区和工作区的变更，生成符合规范的 commit message，请求确认后执行 git commit。

5. Git 工作流

Claude Code 对 Git 操作有原生支持，可以用自然语言驱动常见的版本控制操作：

> 我修改了哪些文件？有哪些改动还没有暂存？
> 显示 src/main.ts 相对于上次提交的修改内容
> 创建一个 feature/user-auth 分支并切换过去
> 提交当前修改，commit message 使用英文，遵循 Conventional Commits 规范

6. 中断与取消

• Escape 键中断：在 Claude Code 思考或执行任务的过程中，按 Escape 可以中断当前的推理过程，取消正在进行的工具调用，立即返回输入状态，保留已有的对话上下文。这在 Claude Code 走偏方向或耗时过长时非常有用。

• 拒绝操作确认：当 Claude Code 请求确认文件修改或命令执行时，输入 n 拒绝。拒绝后你可以补充说明，引导它换一种方式：

Claude Code: 即将执行 rm -rf node_modules && npm install
是否确认？[y/n] n

> 不要删除 node_modules，只安装缺失的依赖就行

7. 典型使用场景

7.1 场景1：用 Claude Code 学代码

Claude Code 不仅能写代码，更擅长讲解代码。在学习阶段，它相当于一位随时在线的技术导师。

• 解释代码逻辑：明确你的知识水平，避免得到跳过关键细节的笼统回答。

> 假设我是刚学 React 的新手，请逐步解释这个 useEffect 的执行时机和清理机制
> 用通俗的方式解释 src/middleware/auth.ts 的鉴权流程，画出请求经过的步骤

对比实现方式：看到一段代码「能跑但不确定是否最优」时，让 Claude Code 从多个角度对比。

> 实现"数组去重"有哪些常见方式？请从性能、可读性、兼容性三个角度对比

• 逐行拆解复杂逻辑：面对嵌套层级多、分支复杂的代码，让 Claude Code 逐行解释。

7.2 场景2：用 Claude Code 写代码

写代码阶段的核心原则：从小而确定的需求开始，给出明确的输入输出约束。

• 从需求描述生成代码：低质量 prompt 往往目标模糊，高质量 prompt 则明确输入、输出、约束。

# 高质量 prompt
> 用 TypeScript 写一个邮箱校验函数：
> - 输入：string 类型的邮箱地址
> - 输出：{ valid: boolean; error?: string }
> - 使用正则实现，不依赖第三方库
> - 导出为命名导出

生成测试用例：Claude Code 会自动参考项目已有的测试风格和框架。

> 为 src/utils/date.ts 中的 formatDate 函数编写单元测试：
> - 使用项目现有的测试框架（Vitest）
> - 覆盖正常输入、边界值、异常输入三种情况
> - 不要引入新的测试库

7.3 场景3：用 Claude Code 改代码

改代码比写新代码更考验对现有逻辑的理解，Claude Code 在这方面表现出色。

重构（不改变行为）：重构时一定要强调行为不变这个约束。

> 在不改变外部行为的前提下，重构 src/services/order.ts 中的 processOrder 函数：
> - 拆分过长的逻辑块
> - 消除重复代码
> - 改善变量命名

批量修改：

> 将 src/components 目录下所有 .jsx 文件转换为 .tsx，补充必要的类型注解

统一代码风格：

> 按照项目现有的风格规范，统一 src/utils 目录下所有文件的代码风格
> 只处理格式、命名和导入顺序，不要修改业务逻辑

8. 高质量 Prompt 的写法

Claude Code 的输出质量直接取决于 prompt 质量。掌握以下原则可以显著提升使用效果。

8.1 结构化 Prompt 模板

对于复杂任务，建议使用以下结构：

背景：
我正在开发一个用户管理模块，使用 Express + Prisma + PostgreSQL

目标：
实现用户注册接口，包含邮箱验证和密码加密

约束：
- 使用项目已有的 bcrypt 和 nodemailer 依赖
- 遵循 RESTful API 设计规范
- 错误响应格式与现有接口保持一致

输出要求：
- 路由定义、Controller 逻辑、Service 层实现
- 包含参数校验和错误处理

8.2 常见 Prompt 优化技巧

设置边界，防止 Claude Code 过度发挥：

> 不要引入新的依赖
> 不要修改函数签名
> 只修改我指定的文件
> 如果不确定，先问我再动手

指定输出格式：

> 用表格形式对比这三种方案的优劣
> 先给出结论，再展开解释
> 分步骤列出操作流程

提供参考示例：

> 参照 src/api/user.ts 的写法，为 product 模块创建同结构的 API 文件

9. 权限机制与安全注意事项

9.1 操作确认机制

Claude Code 在执行以下操作前会请求你的确认：

• 文件写入 — 创建、修改或删除文件

• 命令执行 — 运行 shell 命令

• Git 操作 — 提交、推送等版本控制操作

每次确认时，Claude Code 会明确展示将要执行的具体内容。务必仔细审查后再确认，尤其是涉及删除、覆盖或外部通信的操作。

9.2 需要特别注意的场景

• 敏感文件：确认操作不会意外修改 .env、密钥文件、生产配置等

• 破坏性命令：注意 rm -rf、git push --force、DROP TABLE 等不可逆操作

• 依赖变更：安装或移除依赖前确认是否符合项目需要

• 外部请求：注意涉及网络请求的命令，确认目标地址正确

9.3 权限模式

Claude Code 提供不同的权限模式来平衡效率和安全性：

• 对于信任的操作（如读取文件），可以在设置中配置为自动允许

• 对于高风险操作，建议始终保持手动确认

• 使用 /config 命令可以查看和调整权限设置

10. 实用技巧总结

• 善用 /compact：长时间对话后，Token 消耗会持续增长，适时压缩上下文可以降低成本并保持响应质量。

• 善用 /clear：切换到不相关的新任务时，清除历史避免上下文干扰。

• 善用 -c 恢复会话：中断后继续工作，无需重复说明背景。

• CLAUDE.md 持续迭代：发现 Claude Code 反复犯同一类错误时，将正确做法写入 CLAUDE.md。

• 先读后改：让 Claude Code 修改代码前，先要求它阅读并解释现有逻辑，确认理解无误后再动手。

• 拆解大任务：将复杂需求分解为多个小步骤，逐步确认，避免一次性产生大量难以审查的改动。

• 明确约束：Prompt 中越是明确「不要做什么」，越能减少返工。

结语

Claude Code 的强大能力需要正确的使用方法才能充分发挥。通过掌握启动方式、核心操作、CLAUDE.md 的维护、斜杠命令、Git 工作流以及高质量 Prompt 的写法，你可以将 Claude Code 无缝融入日常开发流程，让它成为你真正的 AI 编程伙伴。记住：工具的价值取决于使用它的人，持续优化你的提示词和项目文档，Claude Code 会回报给你更高的效率和质量。