Claude Code 命令手册：终端 AI 编程工具高频指令与实战

1. 为什么你需要这份 Claude Code 命令手册

1.1 从一次“卡在终端里”的经历说起

我第一次打开 Claude Code 的时候，跟很多人的体验一模一样：装完了，敲下claude，进到交互界面，然后整个人愣住了。这个终端界面没有漂亮的图形按钮，没有鼠标菜单，只有一个闪烁的提示符。我下意识输入了一句“帮我写一个 Python 脚本”，它真的开始工作了。但第二个问题立刻出现：我想切到别的会话、想清空上下文、想换一个更快的模型，却根本不知道该按哪个键、输哪条命令。这种感觉就像拿到一台性能极强的跑车，却找不到换挡杆在哪里。

后来我用了一整天，把它能用的斜杠指令、快捷键和常见场景全部整理了一遍，才有了这份速查性质的手册。严格来说，Claude Code 是 Anthropic 推出的终端命令行 AI 编程工具，它直接跑在本地终端里，把 Claude 模型的能力嵌入了开发者的日常工作流。你可以在命令行里和它对话，让它读写项目文件、执行 shell 命令、运行测试、提交 Git，甚至自动完成多文件跨模块的修改。和网页版的对话式 AI 相比，Claude Code 最大的优势是“离代码更近”：它能直接看到你的项目目录结构，能编辑文件，能跑命令，能持续跟踪整个代码库的上下文。

这篇内容的核心目标读者有三类：第一类是刚装好 Claude Code、准备从零上手的新手，你可以把它当作一份“查字典”式的命令手册；第二类是用过一段时间、但总觉得效率差一口气的进阶用户，里面的工作流梳理和建议会帮你把工具用得更有章法；第三类是还没决定要不要把 Claude Code 集成进日常开发流程的观望者，看完你可以更清楚地判断它在哪个环节最值得投入。下面我不会去抄官方文档，而是按照我实际干活时的使用路径，从安装到高频命令，从快捷键到完整工作流，一步一步带你把这块“终端里的 AI 拼图”拼完整。

1.2 它到底解决了什么问题

很多人一开始把 Claude Code 理解成“终端版的网页 AI”，这个理解不算错，但太粗了。如果只是要对话，大可以开个网页。Claude Code 真正解决的是“AI 与你的项目之间那条天然的隔离墙”。在传统对话式 AI 中，你想让 AI 修改一个文件，得把文件内容复制粘贴过去，改完再把结果复制回来，一来一回非常低效，而且一旦文件变大，粘贴都有上限。但在 Claude Code 里，它工作在你的项目目录之中，可以自己定位相关文件、读入关键代码、做出修改并直接写回文件。修改完之后，你甚至可以让它立即跑一遍测试来验证结果，整个过程一气呵成。

它还能帮你解决“上下文记忆”的问题。开发一个稍大点的功能，往往涉及多个文件、多个函数之间的关联。普通对话式 AI 每次对话是独立的，你很难让它跨文件理解整体结构。Claude Code 通过系统提示词、工作目录扫描和持续的会话上下文维护，让模型在同一个会话里保持对项目状态的感知。配合/compact这类压缩命令，长对话也不会因为上下文窗口耗尽而突然失忆。这也是为什么我在做多文件重构或者跨模块排查时，特别愿意把它拉起来干活的原因之一。它不是一个替代程序员的“答题机器”，更像一个随时待命、能看懂项目全局的资深结对伙伴。

2. 装好环境、启动第一个会话

2.1 安装前置条件

安装之前先确认三件事：系统环境、Node.js 版本、以及终端工具。以我实测过的环境为例，macOS 和 Linux 下都走得很顺，Windows 上我推荐先装好 WSL 再用，因为大量基于 shell 的工作流（比如执行git、npm test这类命令）在原生 Windows 终端里容易碰到路径转换和权限问题。当然你如果只是做纯文本对话和简单文件读写，Windows 原生的 PowerShell 也能跑，但体验会打折扣。这里的推荐理由很简单：Claude Code 大量能力依赖 shell 命令执行，你给它一个接近 Linux 的环境，它发挥起来最顺畅。

Node.js 是必须的。Claude Code 官方推荐 Node.js 18 以上的版本，建议直接用 LTS 版本，别追最新。我的一个教训是：有一次我用了某个非 LTS 的新版本，装完 Claude Code 后一启动就报模块兼容错误，最后降级到 LTS 版本就好了。装完 Node.js 后，在终端里敲node -v确认版本，能正常输出版本号再继续。这一步看起来简单，但能省掉后面大量排查时间。

另外一个容易被忽略的点是：npm 全局目录的权限。在 macOS 或 Linux 上，如果之前装过全局包，可能会遇到EACCES权限错误。遇到这个情况不建议直接sudo npm install -g硬改，因为那样会让全局目录的所有权变成 root，后续升级会很麻烦。比较稳妥的办法是把 npm 的全局安装目录设置到用户目录下，具体做法是在用户目录下建一个.npm-global文件夹，然后修改 npm 配置指向它，并把这个目录加进PATH。这样做一次以后，后续的全局包安装就再也不用碰 sudo 了。

2.2 安装与在线升级

安装命令本身非常简单，在终端里执行 npm 全局安装：

npm install -g @anthropic-ai/claude-code

装完之后输入claude --version能看到版本号，说明安装成功。这里我要强调一下检查版本的必要性：你手上拿到的命令手册，对应的版本特性可能已经变了。Claude Code 迭代速度很快，隔一两个星期就可能更新版本，新增斜杠指令或调整快捷键也是常有的事。所以每次进入一个新项目环境，我第一件事就是跑一下版本号，确认自己在跟哪个版本打交道。

所以养成“在线升级”的习惯很重要。新版启动时会自动检查更新，多数情况下你重启终端、再进入会话就能看到升级提示。如果升级过程中遇到 npm 缓存或者权限问题，清理一下缓存再重装即可。具体操作上，我遇到最多的问题就是“全局目录权限不对”，导致升级失败。这时候先看看当前目录归属，别盲目用 sudo，先修权限，再重新执行安装，通常能解决。

安装完之后，首次运行会在终端里引导你完成登录授权。这个过程会遇到“需要打开浏览器进行授权”的提示，按流程走完就能绑定你的账号。这里有个小细节：授权完成后，终端窗口不要急着关，部分版本在授权回跳时如果终端被强制关闭，会导致 token 文件没写全，下次启动还得重新授权。我身边的人出现过好几次这种情况，都是因为授权页面跳转后太兴奋，手一抖把终端关了，结果又要走一遍流程。

2.3 启动会话与最基本的操作

一切就绪后，在任意项目目录下输入claude就能启动会话。你也可以在启动时指定参数，比如直接恢复之前的对话、指定初始任务。启动后进入的就是交互界面。

第一次进会话，我建议先别急着派大任务，先用最基础的方式“热下身”：随便输入一句指令，比如“统计一下当前项目的 Python 文件数量”，看看它能不能准确定位目录、读取文件并给出回答。这个过程能让你直观地感受到 Claude Code 和网页对话的差异：它的回答会带着对本地环境的感知，而不是完全依赖你粘贴内容。

会话里输入和普通终端不太一样，它是多行输入友好的。第一行输入不算提交，想真正发出指令，需要按对应的提交快捷键。很多新手在这里会卡住，我自己的经验是：进入会话后按Ctrl+Enter提交指令，如果发现光标不对或者输入被提前执行了，检查一下是否误触了别的快捷键。关于这些快捷键细节，我在后面会专门用一整章来拆解。

3. 高频斜杠指令全拆解

3.1 会话管理类指令：/clear、/resume、/compact

斜杠指令是 Claude Code 里最像“快捷按钮”的功能，以/开头，输入时会有自动补全提示。我先把最常用的会话管理类指令讲清楚，因为这几条决定了你一天的工作体验。

/clear用于结束当前会话，清空上下文并开启一个新的对话。为什么要特意提？因为 Claude Code 的上下文是有长度上限的。长时间处理一个大项目，对话越长，它会越“吃力”，出现反应变慢、细节遗漏、甚至答非所问的情况。这时/clear是最直接的“重置”方案。但注意，它不是万能的——清空之后，它不再记得之前聊过的任何内容。所以在执行/clear之前，如果你觉得这次会话里有些重要结论需要保留，先让它把关键信息汇总到文件里，或者自己做好记录。我自己的习惯是，准备清理会话前，先敲一句“把当前任务的完成进度和遗留问题整理成一段文字，我准备清空会话”，然后再/clear。

/resume则是反向操作：重新载入历史会话。它后面可以跟上会话 ID 或序号，通常输入/resume后会弹出历史会话列表让你选择。这个指令对“隔天继续干活”的场景特别有用。我经常前一天晚上把代码改到一半，第二天到公司第一件事就是在上次那个会话里继续，避免了上下文全部丢失、重新解释需求的过程。使用时有一点要注意：历史会话列表和当前所在目录是关联的。你换了一个目录启动 Claude Code，可能就看不到上一个目录里的历史会话了。所以如果准备明天继续，尽量在同一个项目目录里启动。

/compact是我认为的“保命级”指令。当会话已经很长、上下文快满的时候，不需要粗暴地用/clear重置一切，而是用压缩的方式把前面讨论过的内容提炼成精简摘要，再接续当前会话。这有点像开会时让秘书把两小时废话浓缩成五分钟要点。使用之后，Claude 会对已有上下文做一次总结，然后在这个总结的基础上继续工作。它会丢失一部分细节，但整体方向和结论能保留住，代价和收益需要你根据具体场景取舍。我的经验是：如果任务复杂，且压缩后还要继续修改大量文件，建议把关键结论先落到文档里，再压缩，这样更保险。

3.2 上下文控制与模型切换：/model、/status、/config

/model用来切换当前会话使用的模型版本。Claude Code 支持在不同模型之间切换，比如在速度和效果之间做权衡。什么时候切最划算？我总结的规律是：普通问答、清上下文、快速起草，用速度快的模型；复杂重构、疑难排查、多文件关联问题，切到能力更强的模型。切换是即时的，不需要重启会话，这个设计很实用。值得注意的是，不同模型计费可能不同，如果对成本敏感，建议在长时间任务开始前就确定好模型，别频繁来回切，以免产生不必要的费用。

/status是查看当前会话状态的好帮手。输入之后，它会展示模型名称、剩余上下文用量、当前会话的配置信息等。我的习惯是：每工作一段时间或者感觉回答质量开始下降时，就敲一下/status，看上下文是不是快满了。如果用量到了百分之八十以上，我就会考虑/compact压缩一下，或者快速把当前结论保存好，然后/clear换个新会话。这套“体检”动作看起来不起眼，但能显著减少对话中后期“模型突然变傻”的体验。

/config是打开配置面板或查看配置文件的指令。Claude Code 有很多可调项，比如自定义系统提示词、调整输出风格、设置命令白名单等。不同的版本入口略有不同，有些版本直接弹出配置界面，有些版本会跳转到配置文件目录。配置文件的改动需要谨慎，改之前最好备份一份原始配置。我见过有同事把系统提示词改得过于激进，结果模型回答的语气变得很奇怪，最后还是要恢复默认。所以我的建议是：配置文件是你和模型之间的“契约”，每一次修改都要想清楚目的，别为了“好玩”乱调。

3.3 诊断与辅助类指令：/doctor、/help、/init

当 Claude Code 环境出问题时，/doctor会跑一遍环境自检，检查 Node 版本、token 文件、目录权限、依赖完整性等项目。它的优缺点都很明显：优点是能快速定位问题，缺点是它只是标识问题，不一定自动修复。不过对排查来说，能指出方向就省了一大半时间。比如有一次我突然发现所有命令执行都会卡住，跑完/doctor发现是磁盘空间满了，清理之后一切恢复正常。这种问题要是靠手动排查，不知道要折腾多久。

/help是最该被频繁使用的指令。它会把当前版本支持的所有斜杠指令列出来，并附上简要说明。有人觉得进了/help反而更懵，因为这跟打开了工具文档一样，信息量大且没有重点。我的建议是把/help当成“应急字典”，别指望它教会你，先把指令列表截图或复制到本地，再结合这份速查手册来用，效果会好很多。一旦版本更新导致某些指令过期，/help也是你最快了解新指令列表的途径。

/init会初始化一个系统生成的文件或提示词模板，帮助你规范会话工作方式。具体到项目里，它的作用是让 Claude 先生成一个项目级的工作指引，后续会话会自动加载。对一个大型项目而言，这个指引可以让 Claude 从一开始就理解项目结构、编码约定和注意事项，而不是每次从零开始探索。第一次尝试/init时，我明显感觉后续会话进入状态的速度快了很多。尤其是接手一个别人留下的老项目时，/init能快速让 AI 掌握项目“画风”，减少风格不符的修改。

3.4 斜杠指令速查表

为了让你快速定位，我把常用斜杠指令整理成一张速查表，同时附上我在实际项目中总结的适用场景。

这张表是我根据自己的实际使用习惯整理的，频率因人而异。但有一条经验是通用的：斜杠指令大部分支持前缀匹配，输入前几个字母就能看到候选列表，不用反复完整输入。指令一旦多了，配合 Tab 补全会比硬记全部拼写靠谱得多。

4. 不用斜杠也能用的核心交互技巧

4.1 把指令写成“任务描述”而不是“问题”

很多人把 Claude Code 当成搜索引擎，指令写得非常模糊。比如“帮我看看报错”这种话，模型只能看到你当前目录的文件，很难猜出是哪个程序、哪一行报错。真正高效的指令写法是“任务描述”式：先交代背景，再说目标，最后给出约束。比如我会写成这样：“当前项目是一个 Flask 应用，启动时在 config.py 里报 KeyError，帮我定位可能的原因，并给出修改方案，不要改变其他模块的配置逻辑。”

这里的关键是“上下文前置”。Claude Code 虽然能感知项目文件，但它不知道你当前心里想的是哪个问题。把背景、目标、约束一次性讲清楚，它第一次回答的准确率会高很多，省去来回追问的成本。我实测下来，指令从“模糊提问”改成“任务描述”后，整个会话的往返次数至少减少一半。尤其在 AI 编程工具这种场景里，指令的质量直接决定输出质量，这不是玄学，而是输入与输出之间的“信息守恒”。

4.2 @ 引用文件与 ! 执行命令

@符号用于显式引用文件。虽然 Claude Code 自己会按需读取文件，但当你特别指定某个文件时，它会优先把该文件内容纳入上下文。多文件关联的问题场景下特别有用。比如排查跨文件调用链时，我会直接写“@app/routes.py @services/user.py 帮我检查这两个文件里的接口参数是否一致”。这样做避免了模型“猜文件”的不确定性，也减少了不相关的文件被塞进上下文造成的干扰。如果项目文件很多，显式@引用能显著提高定位速度和省 token。

!是执行命令的前缀。在对话中直接输入以!开头的指令，Claude Code 会在本地 shell 里执行它，并把结果展示在会话中。这个设计让“让 AI 执行命令”和“自己执行命令”之间没有边界。我经常先让模型给出一个修改方案，然后自己用!git diff检查变更是否符合预期，再决定是否继续。需要特别注意的是权限边界：执行!命令是有实际系统影响的，比如!rm -rf、!git reset --hard这类危险命令，一定要确认目标路径和影响范围后再运行。Claude Code 有权限确认机制，但你自己也要保持警惕。

4.3 多行输入与批量操作技巧

Claude Code 的输入框支持多行，适合粘贴代码块或者长文本。我第一次用的时候不知道这点，把一大段日志拆成十几条短消息往里发，结果模型上下文瞬间塞满还被打断。正确做法是：一次粘贴完整上下文，让它一次性处理，效率完全不一样。多行输入的处理机制和普通终端不同，回车不会直接发送，而是要等提交快捷键，这给了你一个“整段组织、整段发送”的机会。

批量操作也是 Claude Code 的高频场景。比如你想让它在整个项目里统一调整某个函数命名，或者多处重复代码抽取公共函数。这类任务适合一次性把范围说清楚：“在整个 src 目录下，找到所有调用fetchData的地方，改为调用新的getRemoteData，并保持参数不变。”模型会先扫描文件列表，再逐文件修改，最后生成变更摘要。这个场景里，使用@指定相关文件范围比让它全项目搜索更可控。批量操作最怕误伤，所以要求模型“先列出改动计划，等确认后再执行”是非常有效的保险手段。

5. 快捷键全套整理

5.1 最常用的几个快捷键

Claude Code 的快捷键设计偏“程序员向”，很多习惯和终端编辑器类似。最常用的是提交指令的快捷键。进入多行输入后，敲Ctrl+Enter（macOS 上对应Cmd+Enter）才会把整段内容提交给模型。如果你只按普通回车，光标只会换行，不会发送。这个设计初看反直觉，用久了会发现很合理：多行输入本来就是刚需，而且能有效防止手滑误发。

中断正在进行的模型响应，用Ctrl+C。这一点必须熟记，因为模型的流式输出速度很快，如果发现方向不对，越早打断越省时间。打断之后，你可以直接输入新的指令纠正方向。注意这里的中断语义和普通终端略有不同：在 Claude Code 里，Ctrl+C更多是“停止当前响应”而不是“杀掉进程”，后续会话还能正常继续。

方向键上下可以翻阅历史输入记录，跟 shell 的 history 行为一致。当你连续测试多条指令，想微调上一条命令时，直接按上方向键再修改即可。Tab 键用于补全，不只是补全斜杠指令，还会补全文件名和路径，多按 Tab 会弹出候选列表，能省不少打字量。补全功能在长路径下尤其好用，我经常直接输入目录前几个字符，再按 Tab 展开完整路径，又快又准。

5.2 终端模式与 Vim 模式

Claude Code 支持 Vim 风格的按键模式，这个功能对习惯 Vim 编辑的老用户来说是福音。开启之后，输入框的按键含义变了：h、j、k、l移动光标，按i进入插入模式，按Esc回到普通模式。我身边用 Vim 的同事一开这个模式就直接进入状态，完全不觉得这是在“用 AI 工具”，更像是在编辑器里聊天。

不过我得给不熟悉 Vim 的新手一个预警：如果不知道当前处于什么模式，一顿乱敲很有可能造成奇怪的结果。我在一次演示中不小心按到了 Vim 模式，结果输入的文字全被当成命令处理，光标乱跳，整个场面非常尴尬。所以，不熟悉 Vim 的人建议保持默认模式即可，不用为了“更极客”去特意开启。工具是拿来提升效率的，不是拿来增加仪式感的。

5.3 IDE 与编辑器集成中的快捷键

Claude Code 不只存在于裸终端，它还能集成到 VS Code 等编辑器中。在 VS Code 里通过插件调用 Claude Code 后，你可以在编辑器内直接选择代码、右键发送给 Claude，修改结果会以 diff 形式呈现在编辑器里。这种情况下，编辑器自身的快捷键（比如提交、切换面板）会叠加在 Claude Code 的快捷键体系上。不同插件版本可能映射不同，装好后第一件事是看一下插件自带的快捷键说明，免得把编辑器快捷键和终端快捷键搞混。

我遇到过的一种混乱是：在 VS Code 里用Ctrl+Enter，结果触发了编辑器的默认“在当前行下方插入新行”，而不是 Claude Code 的“提交消息”。后来一看，插件版本升级后快捷键映射变了。这类问题没有标准答案，唯一的办法就是留意插件更新日志和快捷键配置页。如果你主要用 VS Code 工作，建议干脆把 Claude Code 的提交快捷键统一改成编辑器习惯的组合，减少肌肉记忆冲突。

6. 高效工作流实战

6.1 任务初始化工作流

所谓任务初始化，是指在开始一项新功能或新修复之前，先让 Claude Code 把项目背景、现有代码结构和约束条件梳理清楚。我的标准流程是三步：第一步，进入项目目录启动会话；第二步，用/init生成或加载项目级工作指引；第三步，向 Claude 描述本次任务，并明确要求它先输出执行计划再动手。

别看这只是一次“前置沟通”，它带来的收益非常大。有一次我直接让它实现一个用户登录功能，结果它闷头写了二十分钟，最后输出的代码风格和项目现有分层完全不一致。后来我改成先让它总结当前项目的目录结构和代码分层，再给任务，它给出的方案明显贴合项目实际。执行计划这一步的价值在于，它相当于让 Claude 先“想清楚再做”，能早点暴露目标理解偏差。好的执行计划一定包含这些要素：涉及的文件列表、改动顺序、验证方案、风险点。收到这样的计划，你就能在动手前判断方向对不对，而不是等它查完整个代码库才发现跑偏了。

6.2 代码审查工作流

Claude Code 做代码审查是它最成熟的场景之一。我通常的流程是：把改动涉及的文件用@显式引入，然后补充审查要求，比如“重点检查内存泄漏风险、边界条件是否处理、是否有安全隐患”。模型会基于项目上下文给出审查意见，而不只是泛泛而谈代码规范。

这里要特别说明：不要把 Claude Code 的审查结果当成终审意见。它擅长发现逻辑问题、潜在异常分支、风格一致性等“静态能看出”的问题，但对于业务正确性，还是要靠人来判断。我见过有人直接把 AI 的审查意见发到团队群里，结果里面有一条针对历史遗留代码的误报，搞得同事白忙一场。正确的用法是把 AI 审查当成第一遍粗筛，人工再过一遍高优先级意见，把明显的误报剔除后，再讨论真正有价值的问题。在推送代码之前，让 AI 先过一遍“有没有打印调试信息、有没有注释掉的代码、有没有明显 bug”，这个用法性价比最高。

6.3 测试优先工作流

如果你写代码倾向于“先写测试，再写实现”，Claude Code 也能很好地配合。在 TDD 模式下，我会先向它描述预期的行为，让它生成对应的测试用例，再让它根据测试用例去实现功能，并反复运行测试直到通过。流程中，!执行命令会高频出现：每次它改完代码，我都会让它跑一遍测试命令，看到输出结果后决定是继续修补还是收工。

这个流程的经验之谈是：测试代码必须由人工先确认过预期行为是否正确。AI 生成的测试存在“自我增强”的风险——它写的测试可能刚好适配它写的实现，而不是真正验证需求。所以我会把测试用例当作第一道人工审核项，测试过了不代表功能对，测试设计本身错了才是大问题。实操建议是：让 Claude 先写测试，你来审测试用例里的“断言”是否符合需求语义，确认后才允许它进入实现阶段。这样做虽然多一道人工步骤，但整个开发流程会扎实很多。

6.4 大型重构工作流

大型重构是最能体现 Claude Code 价值的场景，也是风险最高的场景。我的建议是走“先规划、后执行、再验证”三步。第一步，让它扫描整个模块，列出受影响的文件清单和依赖关系；第二步，明确重构目标的约束（比如保持外部 API 兼容、不能改变现有数据库结构）；第三步，执行重构并用测试回归验证。

有一次我让它把一个老的单体模块拆分成多个子模块。拆分过程中，它连续修改了十几个文件，依赖关系发生了大面积变化。如果没有在指令里提前设定“每次批量修改后跑一遍现有测试”这个规则，整个过程会非常失控。设定好这个硬性约束后，它每次修改完都会自动验证，一旦有测试暴露问题就立刻回退，这种渐进式的重构节奏比一次性大改要安全得多。大型重构还有一个经验：要求 Claude 每次只改一个关注点，比如“先移动文件结构，不碰具体逻辑；再优化内部实现，不调整对外接口”。把大拆小，每一步可验证，才不会让 AI 的自动修改变成一锅乱炖。

6.5 Git 协作工作流

Git 命令天然适合和 Claude Code 串联。你可以让它读取git status和git diff，据此生成 commit message；也可以让它先分析冲突文件的上下文，再帮你手工解决冲突提供建议。我更习惯的做法是：重要改动提交之前，先让 Claude 总结改了什么，顺便检查有没有遗漏的未提交文件或者误入的调试代码。

这里有个非常重要的提醒：别把敏感信息交到 AI 的上下文中。如果你在代码里写了密钥或令牌，git diff输出里就会带着，Claude 在处理时会把它们读取进上下文。提交代码之前，务必先检查是否存在明文密钥，养成用.gitignore隔离敏感文件的习惯比任何技巧都重要。尤其是配置文件路径、API Key、数据库连接串，这些都应该从版本控制里排除出去。AI 工具再方便，也不能替你做安全兜底。

7. 常见问题与排查技巧实录

7.1 会话卡住或响应中断怎么办

最常遇到的“卡住”其实是网络波动导致的流式响应中断，或者上下文接近上限时的处理变慢。先不要急着关终端。我的排查顺序是：先按Ctrl+C中断当前输出，恢复控制权后输入/status查看上下文用量；如果用量高，执行/compact或/clear；如果还不行，重启会话。

在极端情况下，终端本身可能会无响应。这时可以先尝试连续按几次Esc退出当前状态，回到输入框，再不行就关闭终端进程重来。Claude Code 会自动保存历史会话，重开之后用/resume找到刚才的对话即可。你丢失的只是当前屏幕上的流式输出，核心对话历史基本还在。所以不用太慌，大部分“卡死”都能靠重开解决。我个人在遇到这种问题时，还会顺手记录一下“出现卡顿前我正在做什么”，以便恢复会话后快速衔接。

7.2 上下文溢出与模型“忘事”

症状很明显：对话进行到一半，模型开始重复之前已经讲过的话，或者忽略你几分钟前提到的关键约束。这一般就是上下文快溢出的信号。解决思路分两步：先用/compact压缩，如果压缩后仍频繁遗忘，说明核心信息已经丢了，建议把结论整理成文件，再开新会话并让 Claude 读取该文件继续工作。

把重要信息写进项目文件再让 AI 读取，是绕开上下文窗口限制的一条捷径。比如开发规范、接口约定、临时决策，都可以先写入REFERENCE.md，然后在每个新会话开头用@REFERENCE.md引入。这样既保留完整信息，又不用在对话里反复复制粘贴。这个做法在长周期项目里特别重要，因为它把“易失的对话上下文”转化成了“持久的项目资产”。AI 工具天然记不住几天前的对话，但你项目里的文档可以弥补这一点。

7.3 权限执行受限与危险命令确认

Claude Code 在执行有系统影响的指令前，通常会确认。如果你发现某些命令执行不了，先看是不是配置或权限问题；如果是它拒绝了危险操作，这是保护机制在起作用。我建议不要为了“省事”去调整全局的权限开关，不要用完全自动放行的模式，尤其当项目里存在rm、git reset --hard这类命令时。权限确认的初衷是防手滑，而不是给你添麻烦。保持这个默认安全机制，哪怕偶尔多点头一下，也远比某次误删整个目录划算。

还有一种常见情况：你在 Windows 原生终端里执行 Linux 命令失败。比如在 PowerShell 里输入rm，行为和语义与 Linux 完全不同。这种问题和权限无关，就是环境差异。统一到 WSL 或 Git Bash 环境下会稳定很多。

7.4 常见问题速查表

这张表是我排查问题时的“第一反应清单”，按它走能解决八成以上的日常困扰。剩下两成，多半要靠项目本身的特殊性来理解，但至少排查思路不会乱。

8. 我的实操体会与最后建议

8.1 踩坑记录：最该避开的五个问题

第一，别把 Claude Code 当全能代码生成器，它更适合“增量修改”而非“从零造楼”。从零写一个新模块时，它容易生成看起来完整但边界条件缺失的代码；但在已有代码基础上做修改、补测试、调逻辑，它的表现好得多。第二，别忽视输入法的中英文切换，在终端里输入斜杠指令时，如果被输入法拦截成中文标点，斜杠可能会变成全角字符，指令直接失效。这个坑我踩过很多次，后来养成了在终端里保持英文输入法的习惯。第三，别大批量提交未测试的改动，!git commit之前一定要让 Claude 先列出变更清单，你扫一眼再决定是否放行。第四，别把历史会话当成永久仓库，重要决策和进度一定要落盘，最好养成维护项目笔记的习惯。第五，别为了追求速度关掉权限确认，一次误操作的成本远远高于点头确认的时间。

8.2 个人推荐的最佳实践组合

如果只让我选一套组合拳，我会推荐：每个会话用/status开场，任务用“背景+目标+约束”三段式描述，重要修改用!git diff即刻检查，上下文过半就果断/compact，跨天任务用/resume续上。这套组合不追求花哨，但把 Claude Code 的上下文管理、权限控制和项目感知优势都发挥了。你不需要背下所有指令，只要把这几个核心动作变成习惯，日常效率就不会差。

再分享一个小技巧：把常用的项目级指引、代码规范、接口文档放一起，让 Claude 在会话开头统一读取。我在一个项目里维护了一份AI_GUIDE.md，内容涵盖了项目目录结构、常见模块说明、测试命令规范。每次新会话开始时，一条指令引入它，Claude 对项目的熟悉程度就接近一个“跟进了三个月的老成员”。这个做法在我连续处理十几个小需求时，帮我把每次会话的前置沟通成本降到了几乎为零。

最后想说，Claude Code 这类终端 AI 工具的进化速度很快，今天这份速查手册里的细节，可能半年后就会有大变化。但有一件事不会变：真正提升效率的不是某个具体的快捷键或斜杠指令，而是你对“如何描述任务、如何控制上下文、如何验证结果”这套方法论的理解。把这套东西想明白了，无论它以后怎么更新，你都能快速适应，用出顺手的状态。