Claude Code：实用技巧总结

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

13.1 输入框的四种前缀

Claude Code的输入框支持四种特殊前缀，这是新手最容易错过的功能。

13.1.1 /——斜杠命令

/开头是调用斜杠命令。内置命令（/clear、/compact、/model等）和你自定义的项目命令（/project:deploy-check）都用这个前缀触发。

不确定有什么命令可用？直接输入/然后停下来，会弹出命令补全列表。

13.1.2 @——精准引用文件

@开头是引用文件或目录。这是比复制粘贴代码更好的方式，因为Claude知道这个文件的具体路径，在项目里能建立更完整的上下文联系。

引用单个文件：

@src/main/java/com/company/order/OrderService.java 这个文件的create方法逻辑有问题，帮我看看

引用整个目录：

@src/main/java/com/company/order/ 帮我分析整个order模块的代码结构

引用多个文件：

@OrderService.java @OrderRepository.java 这两个类之间的关系是否合理？

引用时的Tab补全：输入@src/后按Tab，Claude Code会自动补全文件路径，和shell的Tab补全类似。

什么时候用@引用比直接说更好：当你需要Claude精确操作某个文件，或者对话里要频繁提到这个文件时。"帮我修改UserService"不如"@UserService.java帮我修改这个文件"精确——后者Claude能直接定位到文件，不会搞混有多个类名相似的文件。

13.1.3 !——直接执行Shell命令

!开头是直接执行Shell命令，结果会显示在对话里。

!git status
!mvn test -pl order-service
!ls src/main/java/com/company/ -la
!curl -s localhost:8080/api/health | python3 -m json.tool

和普通让Claude执行命令的区别：Claude通过Bash工具执行命令时，它会先告诉你它要做什么，然后等你确认。用!前缀是你直接执行，跳过Claude的中间层，适合你就是想看个命令输出，不需要Claude做任何分析的场景。

执行后让Claude分析：

!mvn test 2>&1

等结果出来之后，直接说"帮我分析一下这些失败的测试"，Claude会基于刚才的输出做分析。比你手动复制粘贴测试输出要快得多。

组合使用技巧：先用!快速检查一下项目状态，再描述你的任务：

!git log --oneline -5
!git diff HEAD~1

看完这两个输出，再告诉Claude"帮我基于这些改动生成一份改动说明"。

13.1.4 #——写入持久化记忆

#开头是写入记忆，内容会被写入CLAUDE.local.md（个人本地记忆，加入.gitignore，不提交git）。

# 我们的数据库是MySQL 8.0，禁止使用存储过程，复杂逻辑必须在Service层实现

# 生产环境的Redis地址是redis-cluster.internal:6379，不要在代码里hardcode

# 项目里的BaseResponse类在 com.company.common.response 包下，新接口的返回值必须用这个包装

写进去之后，每次对话Claude都会遵守这些规则，不用每次重新解释。

#和手动编辑CLAUDE.md的区别：

• #写入的是CLAUDE.local.md——你的个人笔记，不分享给团队
• 手动编辑CLAUDE.md——团队规范，提交到git，所有人共享
• #适合记录你个人的偏好、临时想法、不想分享的背景信息

清理旧记忆：随着时间推移，CLAUDE.local.md里可能积累一些过时的规则。定期用/memory打开看看，清理掉不再有效的条目。

13.2 提示词技巧：写出让Claude更好理解的任务描述

13.2.1 分步骤描述复杂任务

一股脑说需求，Claude容易误解或者抓不住重点。复杂任务拆成步骤，明确告诉Claude执行顺序：

差的描述：

帮我重构OrderService，提升性能，加上缓存，还要保证测试通过

好的描述：

帮我按以下步骤重构OrderService：
1. 先运行 mvn test -Dtest=OrderServiceTest 确认当前测试都通过（基准线）
2. 分析 getOrderById 方法，找出N+1查询问题
3. 用 @EntityGraph 解决N+1，在service层加上 @Cacheable 缓存
4. 再次运行测试，确认还是通过
5. 给我看缓存命中率大概会提升多少（估算）

分步骤之后，Claude有明确的执行路径，每一步完成都能看到具体进展，出错了也更容易定位是哪一步的问题。

13.2.2 提供约束条件

没有约束的任务，Claude会按它觉得最好的方式来，可能和你的实际情况不符：

// 不好：让Claude自由发挥
帮我优化这个查询

// 好：给出具体约束
帮我优化这个查询，约束条件：
- 不能增加新的数据库索引（DBA已确认索引不能再加了）
- 不能改变返回的数据结构（前端已经上线）
- 只能改Service层和Repository层的代码
- 不使用缓存（这个数据实时性要求高）

有了约束，Claude的方案才能真正落地，而不是给你一个理论上最优但实际没法用的方案。

13.2.3 指定输出格式

Claude的默认输出格式不一定符合你的需求，明确说出来：

分析这次代码改动，用以下格式输出：
1. 用一段话说明这次改动做了什么（给产品经理看的，不要用技术术语）
2. 技术变更摘要（给技术负责人审查的，要有具体类名和方法名）
3. 潜在风险点（如果有的话，按高/中/低分级）

不需要代码示例，只要文字说明。

13.2.4 引用具体文件增加上下文

任务描述越具体，Claude越不容易走偏：

// 不好：泛泛而谈
帮我实现用户登录功能

// 好：引用具体文件，指明位置
@UserController.java @AuthService.java
在 UserController 里已经有 /api/v1/users/register 接口，参照这个接口的代码风格，
在同一个Controller里新增 /api/v1/users/login 接口。
AuthService 里已经有 validatePassword 方法可以用。
认证成功后生成JWT，JWT工具类在 JwtUtils 里。

后一种描述里，Claude知道在哪里加代码、用什么风格、有哪些现成的工具可以用，产出质量会好很多。

13.2.5 用"先解释，再执行"模式处理复杂任务

对于你不太确定的复杂任务，先让Claude解释它打算怎么做，确认思路对了再让它执行：

我想把 UserService 里的方法从事务型改成事件驱动的，发领域事件，
让其他服务异步处理。
先告诉我你打算怎么改，涉及哪些文件，用什么方案，
不要直接改代码，等我确认了再动。

这样能避免Claude改了一大堆文件，方向不对又要全部回滚的情况。

13.3 大型项目的使用技巧

13.3.1 如何处理超大代码库

当项目有几十万行代码，你没法把整个项目都塞进上下文。需要主动引导Claude关注正确的范围。

先给Claude一个地图：

我们的项目是一个电商平台，主要模块有：
- order（订单）：创建、支付、取消
- inventory（库存）：扣减、回补
- user（用户）：注册、登录、地址管理
- payment（支付）：对接支付宝、微信

我现在要处理的问题是库存扣减失败的情况。
相关代码在 @src/main/java/com/company/inventory/ 目录下。

先说整体结构，再聚焦到要处理的模块。这样Claude知道项目全貌，在需要跨模块分析时有更好的判断。

按需引入文件，不要一股脑引入所有：

// 不好：引入太多文件，分散注意力
@src/ 帮我找一下库存扣减的bug

// 好：精准引入
@InventoryService.java @InventoryRepository.java
这两个文件里的 deductStock 方法有时候会在并发情况下出问题，帮我找出原因

利用!命令快速探索大项目：

!find src -name "*.java" | grep -i inventory
!grep -rn "deductStock" src/ --include="*.java"

先用Shell命令搞清楚哪些文件和你的任务相关，再有针对性地引入，比直接引用整个目录要精准得多。

13.3.2 如何引导Claude关注特定模块

给Claude角色限定：

你现在的任务只涉及 payment 模块（src/main/java/com/company/payment/）。
其他模块的代码不需要修改，如果你认为需要修改其他模块，先来问我。

明确边界：

只修改Service层，不要碰Controller层（那不是这个任务的范围），
也不要修改数据库表结构（需要DBA审核才能改）。

用TODO注释引导Claude：

在代码里写// TODO: Claude - 需要在这里加缓存这样的注释，然后告诉Claude：

!grep -rn "TODO: Claude" src/
帮我处理所有标了 "TODO: Claude" 的地方

这是一个很实用的工作流：你先扫视代码，在觉得需要AI帮助的地方打上标记，然后让Claude批量处理这些标记。

13.3.3 如何避免Claude改了不该改的地方

这是大项目里最常见的问题：你让Claude修复一个小bug，它改了七八个文件，其中一半是不该动的。

预防措施1：明确说"只改这几个文件"

只修改 @OrderService.java，不要改其他文件。
如果觉得需要改其他文件，先告诉我为什么，等我同意再改。

预防措施2：让Claude改完后汇报

改完之后，给我列出所有修改过的文件，以及每个文件改了什么。

这样你能快速检查有没有意外改动。

预防措施3：用git暂存区保护

重要改动前，先commit一次：

!git add -A && git commit -m "checkpoint before AI refactoring"

这样如果Claude改出问题，git diff HEAD能清楚看到所有变更，git checkout .能一键还原。

预防措施4：批准模式调整

在做大改动时，把批准级别设回ask（即使平时用auto）：

/config
# 把自动批准级别改成ask

这样Claude每改一个文件都要经过你确认。操作慢一点，但对重要代码库是值得的。

13.4 团队协作技巧

13.4.1 统一团队的Claude Code使用规范

一个团队里，如果每个人用法不同，产出的代码风格会很不统一。通过CLAUDE.md把规范固化下来：

建议在团队CLAUDE.md里写的内容：

# 团队Claude Code使用规范

## 代码风格
- Java代码遵循Google Java Style Guide
- 类名用大驼峰，方法名用小驼峰，常量全大写下划线
- 方法不超过50行，超过就拆分

## 技术栈约定
- Java 17，Spring Boot 3.2
- 数据库：MySQL 8.0（禁止存储过程）
- 缓存：Redis（用@Cacheable，不要手动操作RedisTemplate）
- ORM：Spring Data JPA（禁用原生JDBC，除非性能问题经DBA确认）

## 禁用项
- 禁止在Controller层处理业务逻辑
- 禁止在循环里调用数据库（N+1问题）
- 禁止log.info打印密码、手机号、身份证等敏感信息
- 禁止使用Lombok的@Data（用@Getter @Setter分开）

## 测试要求
- 新增功能必须有单元测试
- Service层测试覆盖率不低于70%
- 测试用例命名：方法名_场景描述_预期结果

## 分支规范
- feature/功能名-JIRA编号
- fix/bug描述-JIRA编号
- 禁止直接push到main分支

这个文件提交到git，所有人克隆项目后Claude Code自动加载，不需要额外配置。

13.4.2 共享有效的自定义命令

把团队共用的命令放在.claude/commands/目录里提交到git，所有人自动获得。

建议每个项目标配的命令：

.claude/commands/
├── code-review.md      # PR合并前的代码审查
├── deploy-check.md     # 部署前的完整检查清单
├── bug-report.md       # 生成标准化的bug报告
├── release-notes.md    # 自动生成发布说明
└── onboard.md          # 新人项目引导

这些命令提交之后，新人入职克隆仓库就有了一套完整的工具链，不需要手动配置。

13.4.3 在PR流程中集成Claude Code

一个实用的团队工作流：

提交PR前（开发者做）：

# 1. 先用Claude做代码审查
/project:code-review

# 2. Claude发现P0问题，修复
# 3. 再次review，没有P0/P1问题了

# 4. 生成PR描述
/project:generate-pr-description

generate-pr-description.md命令示例：

# 生成PR描述

基于以下信息生成一份清晰的PR描述：

1. 运行 `git log main..HEAD --oneline` 查看提交历史
2. 运行 `git diff main --stat` 查看变更文件列表
3. 读取变更的主要文件，理解改动内容

用以下格式输出PR描述：

## 改动说明
（一句话说清楚这个PR做了什么）

## 改动原因
（为什么要做这个改动）

## 主要变更
- 文件名：改动说明

## 测试方式
（reviewer如何验证这个改动是正确的）

## 注意事项
（reviewer需要特别关注的地方，如果有的话）

Reviewer做code review时：

# 拉PR的代码
!git fetch origin pull/123/head:pr-123
!git checkout pr-123

# 让Claude帮助review
/project:code-review

这样AI辅助的review会在人工review之前先过滤一遍明显的问题。

13.5 成本优化的进阶技巧

13.5.1 Sonnet初步分析，Opus最终决策

实际使用中，大多数任务用Sonnet就够了。有一个简单的判断标准：

用Sonnet的场景：

• 写代码（给出明确需求，让Claude实现）
• 解释代码（理解现有代码在做什么）
• 常规bug修复（定位明显、修复直接）
• 格式调整、注释补充
• 生成测试用例

切到Opus的场景：

• 系统架构设计（需要权衡多种方案）
• 复杂bug根因分析（需要深度推理）
• 安全漏洞分析（需要精准判断）
• 代码重构方案（影响面大，需要谨慎）

一个省钱的工作流：先用Sonnet快速探索，发现方向后用Opus做决策，再切回Sonnet执行：

# 1. Sonnet快速了解问题
/model sonnet
帮我分析一下这个接口为什么响应慢，先快速扫一遍

# 2. 发现问题复杂，切Opus深入分析
/model opus
刚才Sonnet发现N+1问题，但不确定最佳解决方案。请深入分析，给出三种可能的解法和权衡

# 3. 得到方案后切回Sonnet实现
/model sonnet
按照上面的方案2（EntityGraph解法），帮我把OrderService里的所有N+1都修复

这个工作流能在效果和成本之间找到较好的平衡点。

13.5.2 /compact的使用时机

上下文越长，每次对话消耗的Token越多。定期compact可以显著降低后续对话的单价。

量化一下：假设你的历史对话有50,000 token，每次新发一条消息，Claude都要"读"这50,000 token才能回答。如果compact之后历史被压缩到5,000 token，同样的消息，Token消耗降低90%。

建议的compact节奏：

• 做完一个小阶段（比如完成了一个功能模块）后compact一次
• /status看到上下文使用量超过50%时compact
• 感觉Claude回复开始"忘事"时compact

compact后要确认Claude还记得关键信息：

/compact

（compact完成后）
你还记得我们项目的哪些关键信息吗？列一下。

如果Claude遗忘了重要的背景（比如技术栈约定、架构决策），补充说一遍。

13.5.3 避免让Claude读大量不需要的内容

不要引用整个目录，只引用相关文件：

// 高成本（引用整个目录）
@src/ 帮我找一下订单相关的bug

// 低成本（精准引用）
@OrderService.java 这个文件第42行的逻辑有问题

不要让Claude重复分析已经分析过的内容：

// 高成本（让Claude重新分析）
帮我再分析一下这个架构

// 低成本（引用之前的结论）
基于你之前说的"建议用CQRS模式分离读写"，帮我评估具体实施方案

批量处理类似任务：

// 高成本（多次单独请求）
帮我给这个方法加注释
帮我给那个方法加注释
帮我给另一个方法加注释

// 低成本（一次批量处理）
帮我给 @UserService.java 里所有没有JavaDoc注释的public方法加上注释

13.5.4 用Plan模式检验方向

在不确定Claude理解对没有时，用Plan模式先检验再执行：

先给我一个计划，不要写代码：
我想把项目里所有的 HashMap 替换成 ConcurrentHashMap，
先告诉我会影响哪些文件，有什么潜在风险，大概需要改多少地方。

Plan模式的输出Token很少（只有文字描述），比直接让Claude写代码然后发现方向错了要省很多。

Shift+Tab切换到Plan模式也是同样效果——Claude先计划，你确认后再执行。

13.6 常见错误和解决方案

13.6.1 Claude改了错误的文件

症状：让Claude修复一个bug，它修改了多个文件，其中有不该动的。

解决方案：

1. !git diff HEAD 查看所有改动
2. !git checkout -- 不该改的文件 还原指定文件
3. 重新告诉Claude："只修改@OrderService.java，其他文件不要动"

预防：重要任务前先commit，出问题能直接git reset --hard HEAD。

13.6.2 Claude一直在犯同样的错误

症状：一遍遍提醒Claude不要做某件事，但它还是继续做。

解决方案：别靠对话来解决，写进CLAUDE.md里：

# 在CLAUDE.md里加一条
# 禁止在循环里调用数据库，这会导致N+1问题
# 批量操作必须用 findAllById() 或者 IN 查询

规则写进文件，每次对话自动生效，比每次提醒有效得多。

13.6.3 Claude给出的方案和项目实际情况不符

症状：Claude建议用某个库或方案，但项目里根本没有这个依赖，或者和现有架构冲突。

解决方案：在CLAUDE.md里明确说明项目的技术边界：

## 技术边界
- 缓存只用Redis，不引入本地缓存（Caffeine等）
- 消息队列只用RabbitMQ，不引入其他MQ
- 不使用Kotlin，只用Java
- 不引入新的依赖，除非在 pom.xml 里已经有了

13.6.4 Claude的回复越来越慢、越来越不准

症状：同样的问题，下午Claude的回答质量明显不如上午。

解决方案：上下文积累太长了。

/status  # 看上下文用量
/compact # 压缩上下文

压缩之后，重新说一下你现在在做什么：

我们在重构订单模块的支付流程，之前已经完成了XX，现在要做YY。

让Claude重新锚定当前任务。

13.6.5 Claude生成的代码无法编译

症状：Claude写的代码有语法错误或者引用了不存在的类。

解决方案：

1. 复制编译错误信息，直接发给Claude："编译报错：[错误信息]，帮我修复"
2. Claude通常能快速修复编译错误

预防：

• 如果项目有特殊的包结构或自定义类，在CLAUDE.md里说明
• 告诉Claude项目里有哪些工具类（JwtUtils在哪个包、BaseResponse怎么用）
• 让Claude引用现有的类而不是重新实现

13.6.6 成本控制相关的常见问题

13.7 快捷键速查

多行输入方式（根据终端类型选择适合的）：

最常用的三个快捷键：

1. Ctrl+C——Claude跑偏了立刻叫停，不要等它跑完
2. Shift+Tab——循环切换权限模式，快速在default/acceptEdits/plan/auto之间切换
3. Tab——@引用文件时的路径补全，用熟了之后很流畅