Claude Code 入门必会：@、!、Slash Commands，一篇讲清楚

Claude Code 入门必会：@、!、Slash Commands，一篇讲清楚

摘要： 用 Claude Code 写代码，不只是"把需求发给 AI"。学会 @、! 和 /，就能更明确地提供上下文、执行终端命令、管理开发流程。本文用直观例子讲清三者的区别、常见用法、实战组合与安全边界。

一、先记住这张图：三个符号分别负责什么？

Claude Code 是面向终端和代码项目的 AI 编程工具。它可以阅读项目文件、根据指令修改代码，并在获得相应权限时调用工具执行任务。刚上手时，最容易混淆的是三个看起来很简单的符号：

• @：引用上下文。 告诉 Claude "重点看哪个文件或目录"。
• !：运行 Shell 命令。 在支持的交互界面中，直接执行一条终端命令。
• /：调用命令或工作流。 管理会话、切换工作方式、调用内置命令或自定义 Skill。

可以把它们想象成一个开发团队里的三种动作：@ 是把资料递给同事，! 是自己在终端敲命令，/ 则是选择一套已经约定好的流程。它们不是同一种功能，也不能互相替代。

符号	核心问题	常见场景	例子
@	让 Claude 重点看什么？	分析代码、定位文件、比较实现	@src/service/OrderService.java
!	现在要执行什么命令？	查看 Git 状态、跑测试、构建	!git status --short
/	我要调用什么功能或流程？	帮助、规划、上下文管理、代码审查	/help、/compact

二、@：让 Claude 看对文件，回答才不跑偏

AI 编程最常见的问题之一，不是模型不会写代码，而是它没有足够准确的项目上下文。只说"帮我修复退款问题"，可能让它先猜业务流程；如果明确指出相关服务、控制器和测试文件，分析通常会更聚焦。

1. 怎么用？

在 Claude Code 的输入框里输入 @，根据界面提示选择或补全文件、目录等路径。也可以在提示词中直接写出路径，例如：

@src/main/java/com/example/pay/RefundService.java
请解释退款状态流转，检查重复退款和并发请求的风险。
先分析，不要修改代码。

这段提示做了两件事：一是明确分析对象，二是限定任务边界------先解释和检查，不立即修改。对于支付、订单、权限等业务代码，这个边界尤其重要。

2. 引用一个文件，还是整个目录？

优先引用最相关的文件。 如果问题发生在退款服务，就先提供服务类、调用入口和对应测试；如果要理解一个模块的整体结构，再引用目录或补充相关文件。上下文并不是越多越好：无关文件会增加阅读成本，也可能让关键细节被淹没。

可尝试这样的提示词：

@src/main/java/com/example/pay/RefundService.java
@src/test/java/com/example/pay/RefundServiceTest.java

请对照实现与测试：
1. 说明当前业务规则；
2. 找出测试没有覆盖的边界条件；
3. 给出最小修改方案；
4. 在我确认前不要编辑文件。

3. @ 不等于"自动理解整个项目"

引用路径只是为当前任务提供线索，不代表 Claude 已经完整掌握整个仓库。遇到跨模块问题，应明确指出关键调用链；如果不确定文件在哪，可以先让 Claude 搜索项目，再将找到的关键文件纳入分析。涉及大型仓库时，还可以用项目根目录的 CLAUDE.md 记录架构、常用命令、编码规范和测试方法。

三、!：把终端命令融入工作流

在 Claude Code 的交互模式中，! 可用于进入 Bash 命令执行模式，后面接 Shell 命令。它适合执行开发者本来就需要在终端完成的操作，例如查看 Git 状态、检查日志、运行测试或构建项目。具体行为可能受版本、终端和配置影响；如果当前环境表现不同，请以本机帮助信息为准。

1. 最常见的几个例子

!git status --short
!git diff -- src/main/java/com/example/pay/RefundService.java
!mvn test -Dtest=RefundServiceTest
!mvn -pl pay-service -am -DskipTests package

这些命令分别用于查看工作区状态、检查具体改动、运行指定测试，以及构建指定 Maven 模块及其依赖模块。示例中的模块名和测试类名需要替换成你自己项目中的真实名称。

2. ! 和"让 Claude 执行命令"有什么不同？

你可以直接用自然语言要求 Claude 运行测试，也可以在 ! 后亲自输入命令。前者由 Claude 理解任务并决定下一步，后者是你明确指定要执行的命令。需要快速、精确地检查某个状态时，直接输入命令往往更直观；需要根据输出继续诊断时，再让 Claude 分析结果即可。

例如，先运行 !git status --short，确认有哪些文件发生变化；再运行 !git diff 检查具体改动；最后让 Claude 结合差异解释风险。这种做法比只问一句"代码改好了吗"更可靠。

3. 安全边界不能忽视

! 不是安全沙箱的替代品。命令可能读写文件、访问网络、执行脚本，甚至影响远程服务。尤其要谨慎对待递归删除、批量覆盖、数据库变更、部署、推送代码和生产环境操作。不要为了减少确认提示而盲目放开权限，也不要将密钥、令牌、客户数据或生产日志直接粘贴进对话。

建议遵循一个简单原则：先查看，再执行；先测试环境，再考虑生产；先审查差异，再提交。

四、Slash Commands：用 / 管理会话和流程

输入 /，Claude Code 通常会显示当前环境可用的命令列表。命令可以控制会话、检查配置、管理上下文，也可以触发某些打包的 Skill 或自定义工作流。可用命令会随着 Claude Code 版本、安装方式、插件和配置变化，因此不要把网上某一份命令表当成所有环境的绝对清单。

1. 新手先认识这些命令

命令	用途	什么时候用
/help	查看帮助与可用命令	忘了命令怎么用
/init	为项目生成起始的 CLAUDE.md 指引	第一次进入项目
/clear	清理当前会话历史，开始新任务	话题已经完全切换
/compact	压缩较长对话的上下文	对话太长，需要保留重点
/doctor	检查安装或运行环境	启动、配置或工具异常时
/model	查看或切换当前可用模型	需要调整模型时
/permissions	查看或调整权限规则	希望明确哪些操作需要批准
/review	在支持的环境中触发代码审查工作流	修改完成后复核代码

注意：上述命令并非每个版本、账号或安装环境都一定可用；例如部分名称可能是 Skill，而不是硬编码的内置命令。最稳妥的方式是在自己的终端输入 /，查看实际菜单，再使用当前版本的文档确认行为。

2. /clear 和 /compact 不是一回事

这两个命令很容易混淆。/clear 的目标是清理当前对话，开始一个新的任务；项目级指引文件等持久配置不会因为清理对话而自动删除。/compact 则是对较长会话进行压缩，尽量保留后续工作需要的关键信息，适合当前任务还没完成、但上下文已经很长的情况。

简单说：换任务用 /clear，继续当前任务但上下文太长时考虑 /compact。 无论哪种方式，都应确保重要决策、未解决问题和验证结果已经写清楚，不能把关键知识只留在即将被清理的聊天记录里。

3. 把重复操作变成自定义命令或 Skill

如果每天都在重复"分析问题---定位代码---修改---跑测试---总结风险"，就可以考虑将稳定流程整理成自定义 Skill。当前推荐的 Skill 形式通常位于项目的 .claude/skills/<skill-name>/SKILL.md；旧版 .claude/commands/ 形式在部分环境中仍然兼容。自定义内容可以纳入 Git，便于团队协作和代码评审。

例如创建一个 review-change Skill，将以下要求写入说明：

1. 先阅读 git diff，不要假设所有变更都由本次任务产生；
2. 检查空值、异常处理、并发、权限和数据一致性；
3. 优先运行与变更相关的测试；
4. 没有实际运行的测试，不得声称"测试通过"；
5. 最终列出变更文件、验证命令、实际结果和遗留风险。

这样，/review-change 就不仅是一个快捷入口，而是团队可复用、可审查的工作约定。具体命名和调用形式以本机识别到的 Skill 为准。

五、把三个符号组合起来：一个真实开发节奏

假设你正在维护一个 Java 支付系统，用户反馈"退款接口偶尔重复处理"。不要一开始就让 AI 大范围重构，可以按下面的节奏推进。

第一步：用 @ 明确问题范围。

@pay-service/src/main/java/com/example/pay/RefundService.java
@pay-service/src/test/java/com/example/pay/RefundServiceTest.java
分析重复退款可能出现的原因。重点检查幂等性、事务边界和并发控制。
先给结论和证据，不要修改代码。

第二步：用 / 选择合适的工作方式。

对于涉及多个模块的复杂问题，可以使用当前版本支持的规划功能，例如 /plan 或相应的计划模式。要求 Claude 先列出调用链、可能根因、准备修改的文件和验证方案。规划功能的具体名称可能随版本变化，若命令不存在，就通过 / 菜单或文档查找对应入口。

第三步：确认方案后，再让 Claude 修改。

把改动控制在必要范围内。要求它说明为什么修改、是否改变接口行为、是否影响旧数据，以及哪些边界条件需要补测试。不要仅凭代码看起来合理就直接合并。

第四步：用 ! 运行验证命令。

!git diff --check
!mvn -pl pay-service -am -Dtest=RefundServiceTest test
!git diff --stat
!git status --short

如果项目使用不同的构建工具或测试命名，请换成对应命令。测试失败时，将完整的相关错误输出交给 Claude 分析；测试成功后，再检查实际差异。不要将"命令启动了"误认为"测试通过"。

第五步：用 / 或自定义 Skill 做最终复核。

在支持的环境中调用 /review，或者运行团队自己的审查 Skill。最终让 Claude 给出变更摘要、验证证据和遗留风险。支付类业务还应由开发者检查幂等键、事务一致性、重复请求和异常补偿等关键逻辑。

六、常见误区：避开这几个坑

1. 把 @ 当成自动读取全仓库。 引用能帮助聚焦，但跨模块问题仍需要明确调用链和关键文件。
2. 把 ! 当成普通文本。 在支持的交互模式中，它会触发命令执行；输入前应确认命令内容和作用目录。
3. 认为所有 /xxx 都是内置命令。 有些是 Skill，有些由插件或环境提供；以当前菜单为准。
4. 一味追求少确认。 权限提示虽然会打断节奏，但能提醒你注意文件写入、网络访问和高风险操作。
5. 只看 Claude 的总结，不看实际差异。 最终以代码、测试输出和运行结果为证据，而不是以"已经完成"的文字为证据。
6. 把关键项目规则只写在对话里。 把稳定的架构说明、构建命令和团队规范沉淀到 CLAUDE.md 或 Skill 中，后续会话更容易保持一致。

七、一页记住：日常使用口诀

• 先 @： 提供最相关的文件和上下文。
• 再 /： 选择合适的命令或工作流程。
• 需要时 !： 明确执行检查、测试和构建命令。
• 改完看 diff： 确认实际改了什么。
• 最后验结果： 测试跑过才报告测试通过，风险说明白才算交付。

这套方法并不要求你记住所有命令。更重要的是理解每个符号背后的工作方式：@ 帮助聚焦上下文，! 让命令执行更直接，Slash Commands 则把会话管理和重复流程组织起来。把它们组合进"理解---规划---修改---验证"的闭环，Claude Code 才能从一个会生成代码的助手，变成更可靠的日常开发搭档。