1. 开工之前摸清 Claude Code 的运作逻辑再上手1.1 终端里的 AI 结对编程搭档到底能干什么先抛开那些花哨的宣传语直接说我的真实感受Claude Code 就是一个住在终端里的 AI 结对编程搭档。它不像传统 IDE 插件那样只负责补全代码而是以 Agent 的形态存在——你给它一个目标它会自己读文件、查目录、搜索关键字、改代码、跑测试甚至调用外部工具一步步把任务做完再向你汇报。刚接触的时候我犯过一个典型错误把它当成 ChatGPT 的终端版只会在里面发消息聊需求。后来才意识到它真正厉害的地方在于“能动手”。比如你让它“修复一下登录接口的报错”它不是给你贴一段建议代码而是真的会去读后端路由、定位日志、改完文件之后跑一遍测试给你看结果。这个差别非常关键决定了你后续所有工作流的组织方式。为什么强调这一点因为一旦你理解了它是“能执行操作的 Agent”你就能理解后面所有命令、权限、上下文管理的设计逻辑什么操作需要授权、什么信息要提前喂给它、什么时候该压缩历史、什么时候该重新开一个会话。这套速查手册的所有内容本质上都是围绕“如何让一个能动手的 AI 助手在你项目里安全高效地干活”展开的。顺带说一句它适合谁如果你是后端、前端、全栈开发者或者日常需要写脚本、改配置、折腾 CLI 工具的工程师它几乎是即插即用的存在。如果你完全不做开发那这篇速查表大概率不适合你不用硬看。1.2 安装、登录与 CLAUDE.md第一次启动该做什么安装本身不复杂常规做法是走 npm 全局安装npm install -g anthropic-ai/claude-code装完先确认版本claude --version然后在你的项目根目录运行claude第一次启动会走一遍登录授权流程完成之后就会进入交互式会话。此时你面对的是一行终端提示符可以直接输入自然语言需求也可以输入斜杠命令来操作会话本身。我第一次用的时候完全没概念直接就开始问问题结果发现每次新会话它都“记不住”项目上下文老是问我“这个项目用的什么框架”“测试命令是什么”。后来才明白Claude Code 的记忆靠的是一份叫 CLAUDE.md 的项目级文件。在项目里输入/init它会扫描当前项目自动生成一份 CLAUDE.md内容包括项目结构、技术栈、命令、约定等。这份文件会作为后续所有会话的长期上下文相当于你给每个 AI 助手配了一份“交接文档”。我个人的经验是这份文件值得手动打磨。自动生成只是起步真正好用的 CLAUDE.md 应该包含三块一是项目技术栈和关键路径二是常用命令和构建方式三是你踩过的坑和团队约定。写清楚这三块之后每开一个新会话Claude Code 就像换了个认识你项目的老员工而不是每次都要从零开始试探。2. 高频指令清单会话、权限、文件操作一次讲透2.1 会话生命周期指令从启动、压缩到恢复用了一段时间之后我发现真正高频的斜杠命令其实就七八个剩下的大多是被反复查询边缘功能的低频指令。这里先把生命周期相关的列清楚。/help随时查看帮助文档记不住别的命令先记住它。/status查看当前会话状态包括上下文占用比例、本次会话的 token 统计等。/clear清空当前会话历史开一个新的话题。适合一个任务彻底结束、或者聊岔了的情况。/compact压缩当前对话的上下文保留关键信息腾出新的续写空间。这是长任务里的救命命令后面会单独说。/resume列出历史会话选择恢复。适合隔天接着之前的工作继续做。/rewind回退到上一个操作节点。AI 改坏了代码又不知道怎么手动还原时直接回退非常快。退出会话没有输入时按CtrlC或CtrlD也可以输入/exit。这里我想特别强调/clear和/compact的选用场景。很多人习惯一个会话从头聊到尾等到上下文撑爆了才开始清理。正确做法是任务目标没变、只是对话太长用/compact任务已经结束、或者需求彻底变了用/clear。两者的区别在于/compact会尽量保留任务主线/clear则是直接清空所有临时记忆全部作废。举个例子我正在做一个模块的完整重构中间改了十几轮代码对话历史非常长。这时候用/compact它会把“目标、已完成改动、待办事项”压缩成摘要继续跑但如果我只是想问一个和当前重构毫无关系的小问题那就直接/clear不要让它带着一脑子旧代码乱猜。2.2 权限与模式配置给 AI 划定安全施工区Claude Code 默认的安全机制是做任何一个危险操作之前都要你确认包括写文件、执行 bash 命令等。这个机制在早期非常有用能防止 AI 在你自己都没反应过来的时候把项目改花。但用熟练之后每个操作都点确认会明显拖慢节奏。这时候你需要理解权限配置。核心入口是/permissions。在里面可以按工具或者按具体命令设置 allow、deny、ask 三种策略。举个例子如果我希望所有以npm test开头的命令都直接放行其他命令继续询问可以这样配Bash(npm test:*): true Read: true Edit: true这里Read: true和Edit: true表示读写文件不需要逐次确认Bash(npm test:*)表示只放行测试命令。其他 bash 操作保持默认的询问状态。这套策略是我日常最常使用的配置兼顾了效率和安全感。也有更激进的全放行模式启动时加参数claude --dangerously-skip-permissions这种模式会在整个会话里跳过所有权限确认AI 几乎可以为所欲为。我只有在一次性沙箱环境或者专门跑自动化实验的时候才会用日常项目里不建议开尤其是涉及生产环境、数据库、强推 git 分支这类操作时风险不可控。权限配置还有一个容易忽略的点非交互模式下同样生效。用claude -p ...跑自动化任务时如果没有提前配好允许规则AI 很容易卡在“等待确认”上而终端里根本没人能按 y。这时候要用启动参数提前声明允许列表或者通过--allowedTools指定。这个细节后面讲自动化时还会再提。2.3 文件、代码与 Git 操作真正干活的指令Claude Code 的多数文件操作并不需要你手动敲命令你用自然语言描述目标它会自己调用读文件、编辑文件、执行命令、全文搜索、文件名匹配等工具。但在实际项目里有一些经验能让它干得更准。第一明确工作边界。如果你说“帮我在项目里找一下支付回调相关的代码”它可能全仓库搜速度慢且可能搜歪。更好的说法是“先去src/payment/目录看下结构再定位回调相关文件”。给它一个“地图”效率会高很多。第二善用 git 类指令。我最常用的场景是让它自己查看改动历史比如先运行 git status 和 git diff --stat看看当前有哪些改动然后基于这些改动继续修复。这样它能基于实时状态做事而不是拿一个过时的记忆去猜测。提交时也可以让它按规范写提交信息但我会在提交前检查一次 diff避免它把临时调试代码一起提交进去。第三学会切换模型。输入/model可以切到不同规格的模型。轻量任务比如解释一段代码、写单元测试用响应更快的型号复杂重构再用更强的型号。这个切换是即时的不用重启会话按需切就行。我通常的思路是规划阶段用强模型重复性执行阶段切轻量模型这样既省钱又省时间。第四MCP 连接。输入/mcp可以查看当前会话接入了哪些外部工具服务。MCP 可以理解成给 Claude Code 扩展“外部器官”比如接上数据库查询能力、浏览器操作能力等。这块配置有些前期的搭建成本但如果你的项目重度依赖某些外部服务值得花时间研究。3. 快捷键与终端交互技巧手不离键盘的输入节奏3.1 中断、退出、多行输入最常用的 6 组快捷键Claude Code 的快捷键不算多核心的几组掌握了日常使用就很顺畅。快捷键作用使用时机Esc中断当前回答生成AI 跑偏、思路不对、输出太长CtrlC中断无输入时退出会话卡死或想整体终止CtrlD退出会话在输入框为空时使用ShiftTab切换多行输入模式粘贴大段需求、写详细说明输入/弹出斜杠命令候选列表记不住命令名时快速查看Tab补全命令/参数输入斜杠命令时加速我最常用的是 Esc。AI 正在长篇大论分析时如果我已经知道方向不对直接按 Esc 打断然后重新给一句更明确的指令能省下大量等待时间。注意一点Esc 只是中断输出它已经做好的改动不会自动撤销。如果它已经改了文件你需要在中断后用/rewind回退到安全节点。ShiftTab 是另一个容易被忽略但非常实用的键。默认情况下终端输入是单行模式回车就提交了想写多行需求会很难受。按 ShiftTab 切换进多行编辑器之后可以舒舒服服地把一段完整需求粘贴进去再统一发送。长需求一次说清比挤牙膏式发消息更容易让 AI 理解全貌。3.2 输入习惯与交互节奏让 AI 干活不再费劲快捷键只是表面真正影响体验的是输入习惯。我发现很多人的自然语言指令写得太模糊比如“优化一下这段代码”这个指令信息量几乎为零。换成“这段代码在数据量大时性能差先分析瓶颈再基于分析结果优化最后跑基准测试对比”AI 的表现会完全不同。准确、紧凑、有验收标准的指令才是和 Claude Code 高效配合的关键。交互节奏上我的一条经验是不要频繁用 Esc 打断它的小步骤。AI 执行多步任务时每一步之间会有短暂停顿很多人误以为卡住了就按 Esc结果任务链断裂反而要花更多时间重新对齐。正确做法是除非明显跑偏否则等它完成一个小阶段再反馈。还有一个常用技巧在长任务中间插入简短的引导语比如“这一步做完了下一步聚焦在错误处理上不要扩大改动范围”。这相当于给 AI 一个路标让它不会越跑越偏。4. 高效工作流把这套指令组合成项目流水线4.1 新功能从 0 到 1需求拆分与分步实现我现在的标准做法是接到一个新功能后先不要急着让 Claude Code 直接写代码而是走一套完整的流程。第一步确保 CLAUDE.md 已经初始化。如果项目还没生成过先/init。第二步把需求结构化。直接丢一句“帮我做一个用户注册功能”是灾难我会写成这样项目背景当前系统已有登录模块缺少注册能力。 目标在现有登录流程基础上增加邮箱注册。 验收标准 - 注册成功后自动登录并跳转到首页 - 邮箱格式校验在前端和后端都生效 - 重复邮箱返回明确错误提示 约束 - 复用现有用户表不加新库 - 改动范围控制在 auth 相关目录这样一段话丢进去Claude Code 会先读相关目录再给出实现计划。这时候我会让它先输出方案不要直接动手改。等方案确认了再让它分步实现。第三步分步实现。我习惯让它先改数据层和接口层再改前端最后联调。每一步之间我会抽查 diff确认符合预期后再放行下一步。这样即使中间出了问题也不会造成大范围返工。4.2 测试驱动修复循环让 Claude 自己找 Bug这个工作流非常适合“测试挂了但不知道哪改了”的场景。核心思路是让 AI 以测试结果为驱动自己完成“定位问题 → 修复 → 复跑测试”的闭环。具体操作是这样我会先把命令跑起来先运行 npm test把全部失败的用例列出来。 对每一个失败的用例定位到具体代码文件分析根因不要只改表面。 修复后重新运行 npm test确认全部通过。这里有两个关键细节。一是要求它“分析根因不要只改表面”。AI 很容易在测试报错时改测试来迎合实现或者把报错的地方用排除法试错。明确禁止它改测试内容否则修了个寂寞。二是修复后必须复跑测试并且把结果贴出来。这一步不能省我踩过很多次“它说修好了但实际没修好”的坑。如果整个修复过程很长上下文开始膨胀我会在任务中途用/compact压缩历史把“目标修复全部测试已完成修复了登录接口待办修复注册模块的校验逻辑”这类主线保留下来继续推进。4.3 多文件重构改造大模块前先画依赖图多文件重构是最能体现 Claude Code 价值、也最容易翻车的场景。翻车的主要原因一般是AI 对全局依赖关系的理解不够改了 A 文件却没发现 B 文件还在用 A 的旧接口。我现在的做法是先不急着改。第一步让它梳理现状梳理 src/modules/order/ 目录下的模块依赖关系找出所有被外部文件引用过的导出符号输出一份改动影响范围清单。拿到清单后再分阶段操作。阶段一只做接口层的兼容改造阶段二修改内部调用方阶段三清理旧代码。每个阶段都让它在 git 分支上进行做完一个阶段就在/permissions里收紧权限只放行当前阶段需要触碰的目录。如果中途改坏了优先用/rewind回退到上一个正确节点而不是手动改回来。手动改在复杂重构里非常容易引入新问题AI 的自动回退反而更干净。最后一步全量测试。重构完成不是终点跑完整个项目的测试、再顺手看看构建命令是否正常才是真正收尾。4.4 非交互模式把 Claude Code 接进自动化脚本Claude Code 不只能交互式使用还能用非交互模式跑一次性任务。最常见的写法是claude -p 检查 src/utils/ 下的日期函数列出潜在边界问题这样执行完任务后会直接输出结果并退出很适合在脚本里调用。加--output-format json还能拿到结构化输出方便后续程序解析claude -p 统计 src/components/ 下未使用的导入 --output-format json在我的实践里它最合适的自动化场景有三类一是代码库的批量分析和统计二是把重复性代码操作固化成脚本比如批量修改 import 路径三是接入 CI 流程在合并请求前自动做一次代码审查。但这里有一个必须要讲的坑非交互模式下没有人工确认环节AI 如果执行了危险操作没有任何缓冲。所以自动化场景下权限配置必须前置。我会用claude -p 修复 src/auth/login.ts 的类型错误 --allowedTools Read,Edit,Bash(npm run lint:fix)只允许读文件、编辑文件和运行 lint 修复命令其他全部禁用。千万别在自动化流程里加--dangerously-skip-permissions除非那个脚本运行在一次性容器里跑完即销毁。5. 常见问题与排查技巧实录5.1 输入没反应、退出卡住先按这份清单排查我遇到过几次“输入了命令但毫无反应”的情况第一反应别急着重启终端按下面顺序排查。是不是 AI 还在生成上一轮回答但界面没有刷新按一下 Esc 中断再重新输入。是不是上下文已经占满了输入处理变慢输入/status看看上下文占用比例如果接近上限用/compact压缩后再继续。是不是登录状态失效了这种情况通常会提示你再授权一次重新走一遍登录即可。是不是当前终端目录没有写权限Claude Code 需要读写项目文件如果你在一个只读目录里启动它会频繁报错或者沉默。这套清单能解决八成以上的“卡死”“没反应”问题。实在不行退出重进也不丢太多东西因为可以用/resume恢复历史会话。5.2 上下文爆掉导致答非所问压缩比清空更管用上下文撑爆之后最典型的症状是AI 开始遗忘早期需求、回答越来越短、动不动引用错误的文件路径。你会明显感觉它“变笨了”。这时候很多人的第一反应是/clear重开但这会把已经做好的工作记忆全部丢掉尤其是那些没有写进代码注释的隐性约定。更好用的命令是/compact。它会用摘要的方式压缩历史对话把关键决策和当前进度保留下来。压缩之后AI 不再纠结于每一条细节但还能沿着任务主线继续走。我通常在一个长任务的中后期会主动做一次压缩而不是等到它变笨了才救火。如果压缩之后还是频繁出错说明任务本身已经超出了单个会话的合理边界。这时候应该考虑拆分任务而不是硬撑着在一个会话里全部做完。把项目级约束写进 CLAUDE.md然后/clear开新会话往往比无限续杯更高效。5.3 权限拒绝和命令失败一张表定位根因权限和命令失败的问题非常常见我整理了一个快速定位表现象可能原因解决方式写文件被拒绝权限策略太严格在/permissions中放行 Edit 或针对该目录单独允许bash 命令执行失败命令本身报错或不被白名单覆盖先查看具体报错信息如果是权限拦截调整 Bash 规则卡在等待确认但没人确认非交互模式缺少权限配置启动前用--allowedTools指定允许列表AI 说“无法访问该路径”目录未加入工作区用/add-dir添加目录或启动时就位于项目根目录操作被强制拦截命令匹配了某个 deny 规则检查并修改/permissions中的 deny 项遇到权限问题不要凭感觉反复重试直接输入/permissions查看当前的规则集合然后再决定是放行、拒绝还是调整范围。5.4 实际使用中容易忽视的 4 个坑第一AI 自信但出错。它会用非常肯定的语气给出错误的方案尤其是面对不熟悉的第三方库或者复杂的业务逻辑时。所以我现在的习惯是重大改动后让它自己跑一遍验证命令不要轻信口头承诺。第二危险命令。在默认权限模式下AI 执行类似清空目录、强制推送这类命令时会请求确认但你如果开了--dangerously-skip-permissions这些动作都会被直接放行。我在本地玩没问题但牵扯到共享分支、线上环境时绝不这么干。第三大型仓库扫描耗时长。代码库很大时Claude Code 的搜索会很慢。这时最好先指定子目录或者让它先用文件匹配缩小范围别让它把整个仓库从头到尾读一遍。第四测试驱动容易落入“改测试迎合实现”的怪圈。这是我反复强调的点涉及测试相关任务时必须明确告诉它“不能为了通过测试而修改断言”否则它给你的结果毫无意义。6. 我的速查表使用心得与自定义建议6.1 把高频指令固化成你自己的模板用久了就会发现真正高频的操作就那么几类完全可以固化成个人模板。我在 shell 里加了几个别名减少输入成本alias ccclaude同时也准备了一套固定的 CLAUDE.md 模板里面包含项目导航、命令行、架构约定、常见陷阱四大块。每次接手一个新项目先花十分钟把这份模板填一遍后续所有会话质量都能得到明显提升。固定的提示词片段也很重要。我会保存几段常用的“开工指令”比如先查看项目结构和 README再根据我的需求输出实现方案。 建议保留现状不变的部分、新增的部分、需要修改的现有文件。 如果发现需求存在模糊之处先列出问题让我确认。这种统一的开工模式能让每次任务的起点质量都保持稳定而不是每次都用不同的口语说法导致 AI 理解水平忽高忽低。6.2 哪些场景可以放手让 AI 自动执行关于自动执行的信任尺度我现在的原则是分场景处理。在隔离的实验环境里我会大胆开自动执行权限。比如一个临时目录、一个演示项目、或者纯粹验证某个技术方案跑坏了直接删掉重建没有任何心理负担此时追求的是验证速度。在正经的业务项目里我用默认的逐次确认但把那些可预见的、低风险的操作提前放行比如读文件、编辑文件、运行测试命令。这样既不会频繁打断也不会让人失去对关键操作的掌控。在 CI 或自动化脚本里则是严格白名单。只允许和当前任务相关的工具和命令其他全部拒绝。最后再分享一个小习惯每次收工前我都会让 Claude Code 把当前进度写进 CLAUDE.md 的“进行中任务”部分。这样哪怕隔了一段时间再回来甚至换了一台电脑只要运行claude并输入/resume就能快速接续之前的上下文。这个习惯帮我省下了大量重新对齐需求的时间算是我从这套速查表里获得的最高性价比收益。