Claude Code 实战使用指南：从入门到精通

原创于 2026-06-18 14:27:46 发布 · 258 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#AI #人工智能

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅

本文系统梳理了 Claude Code 的核心功能与高级技巧，涵盖记忆系统、Skills、子代理、Hooks、MCP、插件等六大扩展机制，以及模型配置、常用工作流、上下文成本优化等实战经验，帮助开发者从"会用"到"用好"Claude Code。

一、Claude Code 是什么

Claude Code 不是一个简单的"AI 聊天机器人"，而是一个有手有脚的 AI 代理（Agent）。它能操作你的文件系统、执行终端命令、搜索整个代码库，通过"读取上下文 → 调用工具 → 检查结果 → 继续下一步"的代理循环，自主完成复杂的开发任务。

它内置的工具主要分为几类：

文件操作：Read / Write / Edit
搜索：Grep / Glob
终端执行：Bash
网络访问：WebFetch
代码智能：LSP 跳转定义、查找引用等

实用技巧：你可以用自然语言引导 Claude 的工具选择。比如"先搜索一下哪些文件引用了这个函数"，它会优先用 Grep 而不是直接 Read 整个目录。给出清晰的步骤指引，比笼统地说"帮我改一下代码"效果好得多。

二、六大扩展机制

Claude Code 的强大之处在于其灵活的扩展体系。以下六大机制各有定位，理解它们的区别和适用场景，才能构建出高效的开发工作流。

2.1 记忆系统：让 Claude 记住你的项目

每次新会话，Claude 都是从零开始的。记忆系统就是为了解决这个问题，让 Claude 能够记住项目约定和你的偏好。

CLAUDE.md：你写给 Claude 的说明书

CLAUDE.md 是你主动编写的指令文件，Claude 在每个会话开始时自动读取。它有三个层级，从广到窄依次生效：

层级	路径	用途
用户级	`~/.claude/CLAUDE.md`	个人偏好，所有项目通用
项目级	`./CLAUDE.md`	团队共享约定，提交到 git
本地级	`./CLAUDE.local.md`	个人在项目里的偏好，加到 .gitignore

还有一个实用的机制：.claude/rules/ 目录。你可以把规则拆分成多个文件，并且按文件路径限定生效范围。比如 API 规则只在处理 src/api/ 下的文件时才加载，前端规则不会干扰后端代码，同时节省上下文空间。

写好 CLAUDE.md 的关键原则

控制在 200 行以内：超出的话，考虑把特定场景的规则移到 .claude/rules/ 里按需加载
具体到可以验证："使用 2 空格缩进"比"格式化好代码"有效得多
避免矛盾：定期审查，清理冲突的规则
用 @path/to/file 导入外部文件：比如 @README.md，但注意导入的内容同样占用上下文

自动记忆：Claude 自己做的笔记

除了你写的 CLAUDE.md，Claude 还会自己给自己记笔记。当你纠正它（"这个项目用 Bun 不用 npm"）、或者它自己发现了有用的信息（"测试需要先启动本地 Redis"），它会自动保存。

用 /memory 命令可以随时查看和编辑这些记忆。如果发现 Claude 反复犯同一个错误，与其每次纠正，不如直接说"把这个记下来"或者手动加到 CLAUDE.md 里。

2.2 Skills 技能系统：Claude Code 的超级武器

Skills 是 Claude Code 中最强大也最被低估的功能。简单来说，Skill 就是一个可复用的工作流包——你把某个任务的步骤、注意事项、甚至实时数据查询打包在一起，Claude 在需要时加载它，按照你定义的流程执行。

为什么 Skills 重要

想象一下这些场景：

你每次让 Claude 做代码审查，都要重复说"先检查类型安全，再看错误处理，最后看性能"
你有一个多步部署流程，每次都要从头解释
你想让 Claude 在分析代码前先跑几个命令获取当前状态

这些重复的、多步骤的、需要特定上下文的工作流，就是 Skills 要解决的问题。

创建你的第一个 Skill

Skill 本质上就是一个包含 SKILL.md 文件的目录，放在 .claude/skills/ 下。SKILL.md 由两部分组成：YAML frontmatter（元数据）和 Markdown 正文（具体指令）。

---
name: code-review
description: 审查代码变更的质量、安全性和性能
---

# 代码审查流程

当被要求审查代码时，按以下步骤进行：

1. 先读取变更的文件列表（用 git diff）
2. 逐个文件审查，关注：
   - 类型安全和边界条件
   - 错误处理是否完整
   - 是否有性能隐患
3. 给出分级反馈：
   - 🔴 必须修复：会导致 bug 或安全问题
   - 🟡 建议改进：代码质量可以提升
   - 🟢 可选优化：锦上添花

触发方式

Skill 有两种触发方式：

显式调用：输入 /code-review，Claude 会加载这个 Skill 并按照里面的流程执行
自动触发：Claude 也会根据任务上下文自动匹配并加载相关 Skill。Skill 的 description 字段写得越准确，自动匹配的命中率越高

Skills 的四大高级特性

自包含的深度指令：当 Skill 需要在子代理中运行时，子代理看不到主对话的上下文，因此 Skill 正文必须自包含——把所有需要的指令、上下文数据、判断标准都写清楚
在子代理中隔离执行：当一个 Skill 需要读取大量文件、做深度分析时，让 Claude 在子代理中执行，中间过程不会占满你的主对话上下文
深度推理信号：通过 /effort 命令控制 Claude 的推理深度，从 low 到 max 共 5 个级别
捆绑 Skills 联动：内置的 /run 和 /verify 等 Skill 可以相互配合，实现启动-验证的完整闭环

Skills 的实战建议

从你的重复工作开始：你发现自己第三次向 Claude 解释同一个流程时，就该把它做成 Skill
保持单一职责：一个 Skill 做一件事，不要写一个"万能 Skill"试图覆盖所有场景
步骤要具体："npm test -- --coverage"比"跑测试"好得多
包含验证步骤：告诉 Claude 怎么确认任务完成了
记录踩过的坑：在 Skill 里写上注意事项，Claude 就不会再犯同样的错
重型分析用子代理隔离：代码库审计、大规模搜索这类任务，隔离执行不会污染你的主对话

2.3 Subagents 子代理：独立的 AI 工作者

子代理是在独立上下文窗口中运行的 AI 助手。当某个辅助任务会产生大量中间信息（搜索结果、日志分析、文件内容），而你不会再用到这些细节时，交给子代理——它只返回摘要。

内置子代理

子代理	模型	用途
Explore	Haiku	只做只读操作，适合搜索和代码探索（快速、便宜）
Plan	继承主会话	在 Plan Mode 下收集上下文，为制定计划提供依据
General-purpose	继承主会话	能读能写能执行，处理复杂的多步骤任务

创建自定义子代理

子代理也是 Markdown 文件，放在 .claude/agents/ 或 ~/.claude/agents/ 下。关键配置字段包括：

tools：限制子代理能用的工具。审查类任务只给 Read, Glob, Grep 就够了，不给写权限
model：可以给子代理指定不同的模型。简单任务用 haiku，复杂分析用 opus
isolation: "worktree"：让子代理在 git worktree（隔离的仓库副本）中运行

成本控制：子代理最大的价值不只是"隔离"，还有成本控制。一个用 Haiku 模型跑代码搜索的子代理，成本远低于在主会话中用 Opus 做同样的事。把探索性的、中间产物多的任务交给子代理，主会话保持干净。

2.4 Hooks：确定性的自动化

如果说 Skills 是"教 Claude 怎么做"，那 Hooks 就是"不管 Claude 怎么想，这件事一定会发生"。Hooks 是在 Claude Code 生命周期特定节点自动执行的命令，提供的是确定性控制。

什么时候用 Hooks

场景	Hook 类型
Claude 每次编辑完文件，自动跑格式化工具	PostToolUse
阻止 Claude 执行某些危险命令	PreToolUse
上下文压缩后重新注入关键信息	SessionStart

配置示例

Hooks 在 .claude/settings.json 中配置。比如，每次 Claude 编辑文件后自动用 Prettier 格式化：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

关键区别：Hooks 和 CLAUDE.md 的区别很重要。CLAUDE.md 是"请求" Claude 做某事（它可能会忘），Hooks 是强制执行（不管 Claude 怎么想都会跑）。对于 lint、格式化、安全检查这类必须执行的操作，用 Hooks 而不是在 CLAUDE.md 里写"记得跑 lint"。

2.5 MCP 服务器：扩展 Claude 的能力边界

MCP（Model Context Protocol）是 Claude Code 扩展生态的核心机制。通过 MCP，你可以为 Claude 添加任意外部工具的能力——从数据库查询到浏览器自动化，从 Jira 集成到自定义 API 调用。

核心概念

MCP 的本质是让 Claude 能够调用外部工具。你可以把它理解为给 Claude 装上了"插件"——每个 MCP 服务器提供一组工具，Claude 可以根据任务需要主动调用这些工具。

与 Hooks 不同，MCP 是双向交互的：Claude 决定何时调用、调用什么参数，MCP 服务器执行后返回结果。而 Hooks 是事件驱动的，在特定事件发生时自动执行，Claude 不参与决策。

MCP 与 Hooks 的区别

维度	MCP 服务器	Hooks
触发方式	Claude 主动调用	事件自动触发
用途	提供新工具/能力	自动化既定操作
交互性	双向交互，Claude 决定何时用	单向执行，到点就跑
上下文	结果返回给 Claude，进入上下文	通常不进入上下文

实战场景

数据库查询：通过 PostgreSQL/MySQL MCP，Claude 可以直接查询数据库，帮你调试 SQL、分析数据
浏览器自动化：通过 Playwright MCP，Claude 可以直接操作浏览器，测试 Web 应用的实际运行状态
项目管理集成：通过 Jira/Linear MCP，Claude 可以读取 issue、更新状态、创建任务
自定义 API 集成：如果你的团队有内部 API，可以开发自定义 MCP 服务器

最佳实践

最小权限原则：MCP 服务器应该只暴露必要的工具
环境变量管理：敏感信息用环境变量传递，不要硬编码
错误处理：MCP 服务器应该返回清晰的错误信息
性能考虑：长时间运行的工具考虑返回任务 ID，让 Claude 轮询状态
上下文成本意识：MCP 工具的定义在会话开始时加载到上下文中，只添加真正需要的工具

2.6 插件系统：共享和分发扩展

Claude Code 的插件系统允许你安装、共享和分发包含 Skills、Agents 和 MCP 配置的扩展包。这是团队协作和社区分享的核心机制。

插件是什么

一个插件是一个打包好的扩展，可以包含：

Skills：可复用的工作流指令
Agents：自定义子代理定义
MCP 服务器配置：预配置的外部工具连接
Hooks：事件驱动的自动化操作

插件的本质是把多个扩展机制打包在一起，方便分发和安装。你可以把它理解为"功能包"——安装一个插件，就获得了一整套工作流。

插件 vs 直接配置

维度	插件	直接配置
适用场景	需要分发给多人	个人使用
更新方式	更新 Git 仓库后重新加载	手动修改文件
版本管理	有版本号	无

团队知识沉淀：插件是团队知识沉淀的最佳载体。把你验证过的最佳实践（代码审查流程、部署步骤、调试套路）打包成插件，新同事入职就能直接用上。但要注意——插件不是万能的，如果只是个人使用，直接配置 Skills 和 Hooks 更简单。

三、权限模式：控制 Claude 的自主程度

Claude Code 能读写文件、执行命令，这意味着它有可能做出你不想要的操作。权限模式就是你对它的"信任度调节器"。

模式	命令	特点	适用场景
Default	`/permissions default`	每次编辑或运行命令都会问你	刚开始使用
Accept Edits	`/permissions accept-edits`	自由编辑文件，但运行命令需批准	实时审查代码变更
Plan	`/plan`	只能读文件和分析，不能修改	重大重构前先出方案
Auto	`/permissions auto`	完全自主，但有安全分类器审查	信任任务方向，不想被打断

实用技巧：做重大重构或修复杂 bug 时，先进 Plan 模式让 Claude 出方案，你确认思路没问题再切回去执行。这比让它直接动手然后一堆不想要的改动要高效得多。在 CLI 中按 m 键可以快速切换模式。

无论哪种模式（除 CI/CD 的特殊模式外），对 .git/、.vscode/、.claude/ 等目录的写入都需要确认。这是防止 Claude 意外破坏仓库状态或自身配置的安全网。

四、模型配置与工作量调节

4.1 选择合适的模型

模型	别名	特点
Fable 5	`fable`	最新一代模型，综合能力最强，适合复杂任务
Sonnet	`claude-sonnet-4-6`	日常编码的主力，速度和能力的平衡点
Opus	`claude-opus-4-8`	复杂推理、架构设计、疑难 bug。更贵但更聪明
Haiku	`claude-haiku-4-5`	简单任务、快速搜索。最便宜最快

用 /model 随时切换，或者在启动时指定 claude --model opus。

opusplan 是官方支持的混合模式别名：在 Plan Mode 中使用 Opus 进行复杂推理，执行时自动切换到 Sonnet。用 /model opusplan 启用。

4.2 工作量级别

工作量级别控制 Claude "想多深"：

级别	适用场景
`low`	简单直接的任务，比如重命名变量、格式化代码
`medium`	常规编码，平衡成本和质量
`high`（默认）	大多数编码任务的合适选择
`xhigh`	复杂问题需要深入分析时
`max`	最深入的推理，但可能过度思考，收益递减

用 /effort 切换。一个实用的技巧：对于特别复杂的单次请求，可以用 /effort max 触发更深推理，不需要改变全局设置。

4.3 快速模式

/fast 开启快速模式——同样是 Opus，但响应速度提升最多 2.5 倍，代价是每个令牌更贵。适合交互式调试、实时迭代这类对延迟敏感的场景。

成本优化：快速模式在会话开始时开启最划算。中途开启需要为整个已有上下文支付快速模式的溢价。

五、常用工作流与最佳实践

5.1 代码库探索：快速理解陌生项目

刚接手一个项目，或者隔了很久再看以前的代码，Claude Code 能帮你快速建立全局认知。

快速获取全局视图

给我一个这个代码库的整体概览，包括主要模块、技术栈和架构模式

Claude 会扫描目录结构、读取关键配置文件，然后给你一个结构化的概述。

追踪特定功能的执行流程

用户认证的流程是怎样的？从前端登录按钮点击到后端鉴权完成，完整追踪一下

Claude 会用 Grep 搜索相关关键词，Read 读取涉及的文件，然后给你一个完整的调用链。

经验：探索代码时，从宽泛的问题开始（"整体架构是什么"），然后逐步缩小到具体领域（"认证模块怎么工作的"）。不要一上来就问特别细节的问题，先建立全局心智模型。

5.2 Bug 修复：从症状到根因

Bug 修复是 Claude Code 最实用的场景之一。关键是给 Claude 足够的上下文，让它能快速定位问题。

5.3 重构：安全地改进代码结构

重构是 Claude Code 最擅长的场景之一，因为它需要同时理解多处代码的关联关系。

标准流程

先进 Plan Mode 分析影响范围：让 Claude 搜索所有引用，列出需要修改的文件，评估工作量
讨论方案：Claude 可以给你多个方案，你选择最合适的
执行重构：确认方案后，切回正常模式开始执行
验证无回归：跑完整测试套件，确保没有破坏现有功能

重构时的提示词技巧

"保持向后兼容"：如果你需要保持 API 不变
"分步进行，每一步之后代码都应该是可运行的"：避免一次性改太多
"先改最核心的部分，然后逐步扩展"：降低风险

5.4 测试编写：生成高质量的测试用例

Claude 可以生成遵循你项目现有模式和约定的测试。关键是给它足够的上下文。

识别未测试的代码：找到 NotificationsService 中没有被测试覆盖的函数
生成测试：为 notification service 添加测试，遵循项目现有的测试风格
覆盖边界情况：分析这些函数的代码路径，找出我可能遗漏的边界情况和错误条件

5.5 会话管理：跨会话保持连续性

claude --continue：恢复上次中断的会话，上下文完整保留
claude --resume：显示最近的会话列表，选择恢复哪一个
/compact：手动压缩上下文，保留关键信息，丢弃不重要的中间过程

经验：如果你发现压缩后 Claude 反复"忘了"某些指令，说明这些指令应该写在 CLAUDE.md 里，而不是依赖会话上下文。

六、上下文成本：选对扩展机制

Claude Code 提供了多种扩展机制，但它们的"上下文成本"差异很大。理解这一点，才能做出正确的架构选择——不是所有功能都应该无脑堆上去。

6.1 各机制的上下文成本对比

机制	成本	说明
CLAUDE.md	最高	始终加载，每个会话开始时自动加载，无论你这轮对话做什么
MCP 服务器	较高	工具定义常驻上下文，即使你今天没调用也占用空间
Skills	中等	按需加载，只在你调用或自动匹配时才注入上下文
路径范围规则	较低	只在处理匹配文件时加载，多个规则互不干扰
Subagents	零成本	独立上下文窗口运行，主会话只接收最终摘要
Hooks	零成本	事件触发执行，通常不占用上下文空间

6.2 决策流程

一个实用的决策流程，帮你选择合适的扩展机制：

这条规则每次都需要吗？ 是 → CLAUDE.md
这个流程多步骤且可复用吗？ 是 → Skill
这个任务会产生大量中间信息吗？ 是 → Subagent
这个操作必须执行、不能靠 Claude 自觉吗？ 是 → Hook
需要 Claude 主动调用外部工具吗？ 是 → MCP 服务器
这条规则只对特定文件有效吗？ 是 → .claude/rules/
需要把多个扩展打包分发给团队吗？ 是 → 插件

6.3 常见错误

把所有规则都塞进 CLAUDE.md：后果是遵守度下降，上下文空间不足。解决：把特定场景的规则移到 .claude/rules/ 或 Skills 里
在主会话中做重型分析：后果是中间过程占满上下文。解决：把重型分析交给 Subagents
在 CLAUDE.md 里写"记得跑 lint"：后果是 Claude 可能忘记。解决：用 PostToolUse Hook 自动跑
给所有文件类型都写路径范围规则：后果是规则太多，管理复杂。解决：只给真正需要区分的文件类型写规则

七、动态工作流：编排大规模任务

当你需要做的事情规模很大——审计整个代码库、批量迁移 500 个文件、交叉验证多个来源的研究——单个 Claude 会话可能不够用。动态工作流（Dynamic Workflows）就是为这种场景设计的。

7.1 核心思想：把计划移入代码

在普通的 Claude 会话中，Claude 是编排者，每个中间结果都进入上下文窗口。这在任务规模大时会遇到两个问题：

上下文爆炸：中间结果太多，上下文窗口装不下
不可重复：下次想再做一遍，得从头解释

动态工作流的解决方案是：脚本持有循环和中间状态，Claude 的上下文只保留最终结果。

7.2 何时使用工作流

工作流、子代理、Skills 和 Agent Teams 都可以运行多步骤任务，区别在于谁掌握计划：

维度	子代理	Skills	工作流	Agent Teams
谁决定下一步	Claude，逐轮	Claude，遵循提示	脚本	主导代理，逐轮
中间结果在哪	上下文窗口	上下文窗口	脚本变量	共享任务列表
规模	与子代理相同	每轮几个委派任务	数十到数百个代理	少数几个长期运行

使用工作流的典型场景

代码库范围的错误扫描：扫描所有模块，寻找特定模式的问题
大规模迁移：500 个文件需要更新 API 调用方式
交叉检查研究：从多个角度调查一个问题，然后交叉验证来源
困难计划：值得从多个独立角度起草，然后相互权衡的方案

7.3 内置工作流：/deep-research

最快的体验方式是运行 /deep-research，这是 Claude Code 内置的工作流，用于跨多个来源调查问题：

/deep-research Node.js v20 到 v22 之间权限模型有什么变化？

Claude 会：

在多个角度上扇出网络搜索
获取并交叉检查找到的来源
综合一份带引用的报告

运行在后台进行，你的会话保持空闲。最后你得到一份报告，而不是逐轮的搜索记录。

八、Code Review：自动化代码审查

Claude Code 有两种代码审查方式：

本地 /code-review 命令：在任何会话中运行，审查当前 git diff，无需额外安装
托管 Code Review 服务（Team/Enterprise 订阅）：GitHub App，自动分析 PR 并发布内联评论

8.1 审查机制

当你运行 /code-review 时，Claude 会：

获取变更：运行 git diff 获取所有代码变更
多维度分析：逐个文件审查，检查类型安全、错误处理、性能隐患、安全漏洞
生成报告：输出分级的审查报告

8.2 审查结果分级

标记	含义	说明
🔴	重要	合并前应该修复的问题。会导致 bug、安全漏洞或数据丢失
🟡	小问题	值得改进但不阻塞。代码质量可以提升，但不影响功能
🟣	预先存在	代码库里本来就有、但不是这个 PR 引入的问题

8.3 本地使用方式

/code-review：审查自上次提交以来的所有变更
/code-review main：审查当前分支相对于 main 分支的所有变更
/code-review --fix：尝试自动修复发现的问题（主要是小问题）
/code-review --effort high：调节审查深度，high 或 max 会进行更全面的分析

知识传递：Code Review 的价值不只是找 bug，还有知识传递。审查报告会解释"为什么这是个问题"，帮助你和他人都能学到东西。定期查看审查报告，即使没有发现问题，也能了解 Claude 关注哪些方面。

九、实战案例：从零搭建任务管理 API

让我们通过一个完整的项目实例，看看这些功能如何在实际开发中协同工作。

9.1 项目背景

从零开始构建一个任务管理 API（Task Management API），技术栈选择 Node.js + Express + TypeScript + SQLite。项目目标：

支持任务的创建、查询、更新、删除
用户认证（JWT）
完整的测试覆盖
代码质量保障（lint、格式化、安全检查）

9.2 九步工作法

整个项目会经历以下九个阶段，每个阶段都会用到不同的 Claude Code 功能：

阶段	核心任务	使用的功能	为什么用这个
1	初始化项目与配置记忆系统	CLAUDE.md + 路径范围规则	设定项目基调，分流特定规则
2	创建 API 端点	Skills（/create-api）	封装可复用的多步骤工作流
3	代码质量保障	Hooks（PostToolUse + PreToolUse）	确定性执行格式化和安全检查
4	调试和重构	Subagents（隔离分析）	重型任务不污染主上下文
5	重大重构	Plan Mode + 模型切换	先分析后执行，复杂任务用 Opus
6	代码审查	/code-review + 工作量调节	内置流程，可调深度
7	自动化部署	CI/CD 集成 + GitHub Actions	自动化 CI/CD，云端运行
8	集成外部工具	MCP 服务器（数据库、项目管理）	连接外部系统，端到端自动化
9	团队工作流共享	插件（打包 Skills + MCP + Hooks）	团队知识沉淀和分发

这个顺序不是随意的——它反映了项目从"建立基础"到"持续交付"的自然演进。每一步都在前一步的基础上工作，功能之间相互协同。

9.3 关键要点

功能之间是协同工作的，不是孤立的。CLAUDE.md 设定基础规则，Skills 封装重复流程，Hooks 兜底确定性操作
按需引入，不要一开始就全上。从 CLAUDE.md 开始，逐步引入 Skills 和 Hooks，熟练后再尝试 Subagents 和 CI/CD
版本意识：新功能往往有最低版本要求，使用前确认当前版本支持

十、关键经验总结

10.1 关于记忆和上下文

CLAUDE.md 不是写得越多越好。超过 200 行后，Claude 的遵守度会明显下降。把特定场景的规则分流到 .claude/rules/ 里
上下文压缩后，重要信息可能会丢失。重要指令直接写进项目根目录的 CLAUDE.md 里
自动记忆不总是准确的。定期用 /memory 审查一下，清理掉错误或过时的内容

10.2 关于 Skills

Skills 最关键的用法是自包含的深度指令。当 Skill 在子代理中运行时，它看不到你的对话历史，所以所有前置信息收集步骤、判断标准、输出格式都要写在 Skill 正文里
子代理隔离是处理"重型"任务的利器。代码库审计、大规模重构分析这类任务，让它们在子代理里跑，主会话只收报告
用 /run 固化复杂项目的启动方式。每个团队都有"只有某个人知道怎么启动"的项目，把这个知识变成 Skill