Claude Code：Claude Code 是什么，为什么用它

时效说明：本文内容以 2026 年 3 月为基准。

1.1 从"复制粘贴给ChatGPT"到Claude Code

你可能有过这种经历：写了一段 Spring Boot 的 Controller，逻辑有点绕，想让 AI 帮忙看看。于是你打开浏览器，登录 ChatGPT 或者 Claude 网页版，把代码手动复制进去，然后描述问题，等 AI 给出建议，再把修改后的代码粘贴回 IDE。

这个流程有几个让人抓狂的问题：

问题一：上下文残缺。 你只能给 AI 看一个文件，或者一个片段。它不知道这个方法被哪些地方调用，不知道你项目里的其他 Service 是怎么写的，不知道你用了哪个版本的框架。AI 只能看到你粘贴过来的那一小段代码，给出的建议经常是"想象中的答案"——看起来对，但套进你的具体项目就跑不通。

问题二：手动来回。 AI 给的建议你还要自己动手改，改完之后如果有新问题，你得重新描述，再粘贴，来来回回好几轮。遇到要改多个文件的情况更麻烦，你要一个文件一个文件地粘贴，然后再一个文件一个文件地把修改后的内容粘贴回去。

问题三：上下文丢失。 每次重新开聊天窗口，之前的对话全没了。昨天跟 AI 讨论了半天的设计方案，今天想继续，得从头解释一遍。

问题四：特别明显的 Java 项目痛点。 一个成熟的 Spring Boot 微服务，少则几十个类，多则几百个。涉及继承链、多层 Service 调用、MyBatis Mapper、DTO/VO/Entity 转换……这种项目给网页版 AI 看，你能粘贴进去的内容不到整个项目的 1%，AI 根本建立不起来有效的理解。

典型的痛苦场景：

• 想让 AI 帮你排查一个 NPE，但它看不到 A 类调用了 B 类，B 类里才是真正出问题的地方
• 想让 AI 帮你重构 UserService，但重构完之后你发现 OrderService 里有三个地方调用了被你改掉的方法签名
• 接手一个陌生项目，想让 AI 帮你梳理架构，但没办法把几百个文件都粘贴给它

Claude Code 解决的正是这些问题。它不跑在浏览器里，而是跑在你的终端里，直接读取你本地的项目文件，能看到整个代码库。你说"帮我优化一下 UserService 里的分页查询"，它会自己找到这个文件，分析上下文，然后给你展示一个 diff，你确认之后它直接改文件——不需要你手动复制粘贴任何东西。

1.2 Claude Code 的本质：操作本地环境的 AI Agent

很多人第一次接触 Claude Code，容易把它理解成"更方便的 ChatGPT"。这个理解不太准确。

Claude Code 的本质是一个 AI Agent，不是聊天工具。

两者的区别在于：聊天工具的职责到给出回答为止，而 Agent 还会执行后续操作。你问 ChatGPT "这段代码怎么优化"，它告诉你答案，执行是你的事。但 Claude Code 不一样，它能调用工具：

• 读文件：扫描你的项目，读取任意文件内容
• 写文件：创建新文件，修改现有文件
• 执行 shell 命令：运行 mvn test、git diff、grep，甚至启动你的应用
• 调用 git：查看提交历史，理解代码变更上下文
• 联网搜索：查询最新的文档和技术信息（可选功能）
• 启动子代理：把大任务拆成多个并行子任务执行

它有一个任务循环（Task Loop），在这个循环里它会自己判断下一步该做什么，直到任务完成。这不是"AI 告诉你该怎么做"，而是"AI 帮你做好这件事"。

打个你熟悉的比方：ChatGPT 像是给你发邮件提建议的顾问，而 Claude Code 像是能 SSH 进你服务器的实习生——当然，在你确认之前它不会擅自动你的代码。

这个 Agent 本质也是为什么这门课专门用一整章来讲 Claude Code。我们整个课程讲的是 Agent 开发，而 Claude Code 本身就是一个设计精良的 Agent 应用。你在用它的过程中，自然就能理解 Agent 的核心机制：工具调用、上下文管理、循环推理、人在回路（Human in the Loop）。这些概念不再是抽象的，你可以直接观察 Claude Code 是怎么做到这些的。

1.3 Claude Code 的核心工具能力

了解 Claude Code 有哪些工具，能帮你更有效地使用它，也能让你理解它为什么能做到那些看起来"神奇"的事情。

1.3.1 文件读写工具

这是最基础也最核心的能力。Claude Code 能读取项目里的任意文件，也能创建或修改文件。

读文件时，它不是随机读的，而是有策略的：先读项目结构（目录树），再根据你的任务判断需要读哪些文件。对于 Java 项目，它通常会优先读 pom.xml（了解依赖和版本）、主要的配置文件（application.yml），然后才是具体的业务代码。

写文件时，它会把改动展示给你看（diff 形式），你确认后才真正写入。这是一个非常重要的设计：AI 决定改什么，人决定是否生效。

1.3.2 Bash 执行工具

Claude Code 能执行 shell 命令，这让它能做很多单纯"读写文件"做不到的事情：

# 它能运行测试，看测试是否通过
mvn test -Dtest=UserServiceTest

# 它能查代码里的引用
grep -r "findActiveUsers" --include="*.java" .

# 它能看 git 历史，理解最近改了什么
git log --oneline -20

# 它能编译检查有没有语法错误
mvn compile -q

执行 shell 命令也需要你确认（默认情况下），除非你明确授权某些命令可以自动执行。

1.3.3 联网搜索工具

当 Claude Code 遇到它知识库里没有（或者不确定）的最新信息时，它可以联网搜索。比如：

• 某个库的最新版本号
• 某个错误信息的解决方案
• 最新的 Spring Boot 迁移指南

这个功能在处理版本兼容性问题时特别有用。不过联网搜索需要开启相应权限，国内网络环境下有时也需要代理。

1.3.4 子代理（Sub-agent）

对于复杂的大型任务，Claude Code 能启动多个子代理并行执行。比如你让它"给所有 Controller 加上完整的 Javadoc 注释"，它可能启动多个子代理，每个负责一批文件，并行完成。

这个能力对于大型项目批量处理任务非常有用，后面专门的章节会讲这个用法。

1.4 Anthropic 用 Claude Code 开发 Claude Code 本身

这一点值得单独说，因为它不只是一个有趣的小知识。

Anthropic 在开发 Claude Code 时，团队自己就在用 Claude Code。工程师用它来写代码、跑测试、审查 PR，模型在真实使用中暴露问题，然后被修复，再继续使用。这个自我迭代的闭环让 Claude Code 进步非常快——它不是一个实验室里做出来然后推出去的产品，而是在真实工程场景里磨出来的。

对你来说，这意味着什么？意味着 Claude Code 在理解工程化代码方面特别强，因为它的开发者就是工程师，用它干的活就是真实的工程任务。它对代码库结构、git 工作流、单元测试这些场景的处理，明显比通用聊天 AI 更贴近实际。

同时，这也说明 Anthropic 足够信任它自己的工具。一个连自己产品都不敢用来开发自己产品的团队，凭什么让你用它来开发你的产品？

1.5 后端程序员为什么特别适合用它

对于 Java 后端工程师来说，命令行本来就是家。你每天都在用 mvn clean install、git commit、kubectl apply，终端不是陌生的地方。Claude Code 跑在终端里，跟你原有的工作流融合起来很自然，不需要切换到另一个应用，不需要改变开发习惯。

还有几个特别适合 Java 后端的场景：

场景一：阅读陌生大型项目。 接手了一个几年前的老项目，几十万行代码，没有任何文档。以前你只能慢慢点文件看，现在可以直接问："这个项目的整体架构是什么？数据库访问层用的是什么？有哪些定时任务？" Claude Code 能在几分钟内给你一个清晰的架构梳理。

场景二：大范围重构。 把 MyBatis 换成 MyBatis-Plus，把旧的日期 API 换成 java.time，把所有的 System.out.println 换成 slf4j……这类"改动很多文件但每个改动都很机械"的任务，Claude Code 做起来又快又准，而且每个改动都让你确认。

场景三：写测试。 这是很多后端程序员最烦的事情之一。你可以直接让 Claude Code："给 UserService 里所有的 public 方法写 JUnit 5 单元测试，用 Mockito mock 依赖。" 它能读懂你的代码逻辑，生成真正有意义的测试用例，而不是那种只会走 happy path 的测试。

场景四：排查问题。 遇到一个诡异的 bug，你把错误日志粘贴给它，让它顺着调用链找下去。它能自己翻文件，一层一层追调用，找到可能的原因，比你自己加断点调试快很多。

1.6 Claude Code vs 其他工具的详细对比

这几个工具经常被放在一起比较，但它们的定位其实差别挺大。

和 Copilot 的关系：
Copilot 是"你写代码时 AI 帮你补全"，Claude Code 是"你描述任务，AI 帮你完成"。前者是输入增强，后者是任务委托。两者不冲突，可以同时用。Copilot 负责你打字时的实时补全，Claude Code 负责更大粒度的任务。

和 Cursor 的关系：
Cursor 是 VS Code 改造版，更适合写代码过程中随时问 AI。Claude Code 更适合明确的任务型操作，比如"给这个模块加测试"、"按照这个需求文档实现功能"。另外，Cursor 需要你切换 IDE，如果你原来用 IntelliJ IDEA，可能不愿意为了 Cursor 换编辑器。Claude Code 不要求你换编辑器，你用什么 IDE 还是用什么。

Claude Code 的真实使用体验：

用了一段时间之后，你会发现 Claude Code 最大的价值不是"帮你写代码"，而是"帮你不写代码"。很多机械性、重复性的工作——加注释、加日志、加异常处理、格式化代码、补全缺失的测试——你不需要亲自做了。这些事情 Claude Code 做得比你快，而且在你确认每一步的前提下，风险是可控的。

1.7 Claude Code 的局限性

诚实地说，Claude Code 也不是万能的。知道它的局限，能帮你在合适的场景用合适的工具。

局限一：不适合需要你"在状态里"的创造性编码。
如果你正在做一个全新的、需要大量思考的架构设计，Claude Code 可能反而会打断你的思路。它适合执行明确的任务，不适合在你思维模糊时替你思考。这时候老老实实自己写，或者用网页版 AI 讨论设计，比开着 Claude Code 强行推进要好。

局限二：对超大代码库的理解有上限。
Claude Code 能处理的上下文是有限制的。一个几百万行代码的超大单体，它扫描一遍已经占满了上下文窗口。这种情况下，你需要明确告诉它聚焦在哪个模块，而不是指望它理解整个代码库。

局限三：它可能自信地给出错误答案。
AI 模型都有这个问题：有时候它的回答看起来很有把握，但其实是错的。尤其是涉及到你的业务逻辑时，它不了解你公司的上下文，可能给出"技术上没错但业务上有问题"的改动。所以始终要仔细看 diff，不要因为 AI 给的所以就直接全部确认。

局限四：不适合直接操作生产环境。
Claude Code 能执行 shell 命令，所以理论上你可以在生产服务器上运行它。但这非常不建议。即便它的每个操作你都确认，生产环境的容错空间很小，一个疏忽就可能造成事故。把 Claude Code 用在开发和测试环境，生产部署还是走你们的标准发布流程。

局限五：对 GUI 工具无能为力。
如果你的项目调试依赖 Nacos 控制台、Arthas 诊断工具的 GUI 界面，或者你的工作流里有大量点击操作，Claude Code 帮不上太多忙。它的强项是命令行和文件操作。

1.8 第一次用的正确姿势

很多人第一次用 Claude Code，容易走两个极端：要么太保守（只让它解释代码，不让它动文件），要么太激进（直接让它重构核心模块）。正确的姿势是循序渐进。

第一步：先从只读任务开始。
让它解释代码、分析架构、找代码里的潜在问题。这些任务没有任何风险，但能让你快速感受到它的能力边界。比如：

这个项目用了什么设计模式？在哪些地方？

UserService 里有没有明显的性能问题？

第二步：小范围的修改任务。
找一个影响范围小、容易验证的任务，比如给一个工具类加注释，或者修一个明确的小 bug。观察它给出 diff 的方式，感受确认流程，建立信任。

第三步：稍大的任务，但要在可恢复的状态下做。
在 git 仓库里做修改，修改前先 git stash 或者新建一个分支，这样即使 Claude Code 的改动不满意，git checkout . 一秒恢复。不要在未纳入版本控制的目录里让它做大范围修改。

第四步：复杂任务，配合 CLAUDE.md 规范文件。
当你要做较复杂的任务时，先在项目根目录创建 .claude/CLAUDE.md，把项目的技术栈、编码规范、禁止改动的文件都写进去。这样 Claude Code 的每次操作都会在你设定的约束内进行。后面的章节会详细讲 CLAUDE.md 的写法。

最不该做的事：

• 在没有 git 的目录里让它做大改动（改坏了找不回来）
• 一上来就让它改核心业务逻辑（先建立对它的理解再信任它）
• 全选 a（全部确认）然后不看 diff（你还是得认真看每一处改动）
• 在生产环境的服务器上运行它