1. 为什么我花了一周时间整理这100条指令用 Claude Code 的人越来越多但大部分人的使用深度其实停留在“打开终端、敲一句帮我写个函数、复制结果、关掉”这个循环里。我刚开始也这样直到有次看一个同事操作同一个重构任务我敲了七八轮对话才搞定他三条指令结束战斗还顺手把测试和提交信息都生成了。那一刻我才意识到Claude Code 的真正效率差距不在模型本身而在你对指令系统的熟悉程度。Claude Code 是 Anthropic 推出的命令行 AI 编程工具它直接跑在你的终端里能读写项目文件、执行 shell 命令、跑测试、管理 git本质上是一个“住在你项目目录里的结对程序员”。它和网页版对话最大的区别是它有上下文、有工具、有权限能真正动手改你的代码。而驱动这一切的就是指令——包括斜杠指令slash commands、CLI 启动参数、以及对话中的自然语言指令模式。这份整理适合三类人刚装好 Claude Code 还没摸清门路的新手、用了一阵但总觉得效率没拉满的中级用户、以及想把这套工具引入团队工作流的 Tech Lead。我会把 100 条常用指令按场景拆开讲每条都说清楚什么时候用、为什么这么用、有什么坑。不是干巴巴的清单而是我自己踩过一遍之后的实战笔记。提示指令数量会随版本迭代变化我整理的是当前稳定版本下最常用、最值得记住的那批。核心逻辑比具体条目更重要。2. 指令体系的整体设计与分类逻辑2.1 三类指令的本质区别很多人把 Claude Code 的指令混为一谈其实它分三个层次用途完全不同。第一类是斜杠指令在对话输入框里以/开头比如/help、/clear、/init。这类指令由客户端本地解析不消耗模型 token作用是控制会话状态、切换模式、触发特定工作流。你可以理解为“操作系统的快捷键”。第二类是CLI 启动参数在终端敲claude命令时带的 flag比如claude -p xxx、claude --resume。这类决定会话怎么启动、用什么权限、加载哪个配置。它是“进门之前的设置”。第三类是自然语言指令模式就是你直接跟它说的话但有一些固定句式能触发特定行为比如“先看再改”“只输出 diff 不要写入”“用 TDD 方式实现”。这类最灵活也最考验使用者的表达功力。2.2 为什么指令设计成这个样子Claude Code 的指令体系背后有个清晰的设计哲学把确定性操作和概率性操作分开。斜杠指令和 CLI 参数是确定性的敲了必然执行某个动作自然语言是概率性的模型理解成什么样有波动。这个分离很关键——状态管理、权限控制、会话切换这些不能出错的事情交给确定性指令代码理解、方案设计、重构这些需要判断的事情交给自然语言。理解了这一点你就知道为什么不该用自然语言去干/clear的活比如跟它说“忘掉之前的对话”效果远不如直接/clear也不该指望斜杠指令帮你做架构决策。2.3 我建议的记忆优先级100 条不可能全背下来。我的建议是按这个优先级记必记每天用/help、/clear、/init、/compact、/review、/model加上claude -c、claude -p、claude --resume。这不到 10 条覆盖 80% 日常场景。常用每周用权限相关、git 相关、上下文管理相关大概 20 条。备用知道存在即可剩下的按需查/help或本文档。下面进入正题我按场景把指令拆开讲。3. 会话与上下文管理指令详解3.1 会话生命周期指令会话管理是最基础也最容易被忽视的一块。很多人一个会话开一整天上下文塞满了各种无关内容模型越来越迟钝还以为是模型变笨了。/clear是清空当前会话上下文但不退出程序。什么时候用当你切换到一个完全无关的任务时。比如你刚调完一个 Python bug现在要写前端组件直接/clear比在旧上下文里继续干净得多。我实测下来不清上下文直接切任务模型经常把两边的变量名、框架习惯混在一起产出质量明显下降。/compact是压缩上下文把之前的对话总结成摘要保留释放 token 空间但保留关键信息。这个指令在长任务里特别有用——比如你做一个大重构已经聊了 50 轮上下文快满了但又不想丢掉前面的决策记录/compact就是干这个的。它和/clear的区别是/clear是失忆/compact是记笔记。/resume在会话内使用可以恢复之前的会话而 CLI 层的claude --resume或claude -c是启动时直接续上最近一次会话。-c是--continue的简写我几乎每次重开终端都用它省得重新交代项目背景。/exit或CtrlC两次退出。这里有个小坑直接关终端窗口有时会留下锁文件下次启动报错养成用/exit的习惯更稳。3.2 上下文注入指令/init是初始化项目记忆文件会在项目根目录生成CLAUDE.md。这个文件是 Claude Code 的“项目说明书”每次会话启动会自动读取。我强烈建议每个项目都跑一次/init然后手动编辑CLAUDE.md把项目结构、技术栈、代码规范、常用命令写进去。这一步做得好后面每次对话都省去大量解释成本。/memory用来查看和编辑当前加载的记忆内容。有时候你改了CLAUDE.md但不确定有没有生效/memory一看便知。#开头的输入是快速记忆指令比如# 这个项目用 pnpm 不用 npm它会直接追加到记忆文件里。这个我经常用遇到模型反复犯同一个错就#记一笔下次就不会再犯。/add-dir可以把项目外的目录加入工作区。比如你的项目依赖一个本地共享库在另一个目录用这个指令加进来模型就能同时读写两边。3.3 上下文管理的实操心得我踩过最大的坑是在同一个会话里既做代码审查又做功能开发。审查时模型处于“挑刺”模式开发时需要“建设”模式两种心态混在一起产出很别扭。后来我养成习惯审查用/review单独开开发另起会话。另一个心得是关于CLAUDE.md的写法。不要写成 README 那种给人看的文档要写成给模型看的“操作手册”。比如“运行测试用pnpm test:unit不要用npm test”“组件文件放在src/components/每个组件一个目录”这种具体到命令和路径的指令比“本项目采用模块化架构”有用一百倍。4. 代码操作与文件读写指令4.1 读取与理解代码Claude Code 默认会按需读取文件但你可以用指令引导它读得更准。直接说“读一下src/auth/目录下所有文件总结认证流程”比“帮我看看认证怎么实现的”高效得多。前者给了明确范围后者让模型自己猜。符号是文件引用指令输入会触发文件路径补全选中后该文件内容会直接注入上下文。这个在精准提问时特别好用比如src/utils/date.ts 这个文件的 formatDate 函数有没有时区问题。对于大项目我建议先用“给我画一下这个模块的调用关系”这类指令让模型建立全局观再深入具体文件。直接扎进细节容易迷路。4.2 修改与写入代码默认情况下Claude Code 修改文件前会展示 diff 并请求确认。这个确认机制很重要别嫌烦。我见过有人为了图快开了全自动权限结果模型把一个配置文件改错了排查半天。/permissions可以查看和修改权限设置。权限分几档只读、可编辑需确认、可编辑免确认、完全访问。我的建议是日常用“可编辑需确认”只有在跑批量机械修改比如全项目重命名变量时才临时开免确认。写入时的关键指令模式是“先看再改”。明确说“先读这三个文件理解现有实现然后只修改handleSubmit函数其他不动”。这样能避免模型顺手“优化”了你不想动的地方。我吃过亏——让它改个按钮文案它把整个组件的状态管理重构了diff 几百行review 起来想哭。/diff查看当前所有未提交的改动相当于内置了一个 git diff。改完一批文件后先/diff扫一眼确认没有意外改动再提交。4.3 代码审查与质量指令/review是触发代码审查工作流它会检查当前改动从正确性、安全性、性能、可读性几个维度给意见。我通常在提交前跑一次当免费的 pre-review。/security-review更聚焦安全检查注入、越权、敏感信息泄露这类问题。涉及用户输入、数据库操作、认证逻辑的改动我必跑这个。审查类指令有个使用技巧明确审查范围。/review默认看所有未提交改动如果改动很多最好说“只审查src/api/下的改动”否则模型注意力分散意见质量下降。4.4 文件操作的避坑经验第一个坑不要让模型操作它没读过的文件。有次我让它“把 config 里的超时改成 30 秒”它没读文件就凭猜测改了改错了字段。正确做法是先config引用或者明确说“先读 config 文件再改”。第二个坑批量操作前先备份或确保在 git 干净状态下。模型批量改文件时偶尔会漏掉某个文件或改错有 git 兜底随时能回滚。我现在的习惯是任何超过 3 个文件的批量修改前先git status确认干净。第三个坑注意模型的“过度热情”。你让它修一个 bug它可能顺手把相关的“潜在问题”也改了。如果只想最小改动明确说“只修这个 bug不要做其他改动”。5. CLI 启动参数与工作流指令5.1 启动参数速查CLI 参数是很多人忽略的一块但它能大幅改变使用体验。下面这张表是我最常用的启动参数参数作用我的使用场景claude启动交互式会话日常开发claude -c继续最近一次会话重开终端后接着干claude -p xxx单次执行后退出脚本化、CI 场景claude --resume选择历史会话恢复找回昨天的上下文claude --model xxx指定模型切换不同能力档位claude --add-dir xxx添加工作目录多目录项目claude -p这个模式值得单独说。它是“打印模式”执行完直接输出结果就退出不进入交互。这个在写脚本时无敌好用比如claude -p 检查 src 下所有 ts 文件的类型错误并输出列表可以直接嵌到 shell 脚本或 CI 流程里。5.2 权限与安全参数--dangerously-skip-permissions是跳过所有权限确认慎用。我只在完全隔离的容器环境或一次性任务里用。本地开发环境绝对不要开风险太大。--allowedTools和--disallowedTools可以精细控制模型能用哪些工具。比如你只想让它读代码不想让它执行命令可以禁用 Bash 工具。这个在给团队做标准化配置时很有用。/permissions在会话内调整权限比启动参数更灵活。我通常启动时用默认权限遇到需要批量操作时临时/permissions提权干完再降回来。5.3 工作流自动化指令/agents可以创建和管理子代理每个子代理有独立的上下文和工具权限。这个高级功能适合复杂任务拆分比如一个代理专门写测试一个专门做重构。我目前用得不多但在大型重构里试过效果不错。/hooks配置钩子在特定事件如文件保存、工具调用前后触发自定义脚本。比如你可以配一个钩子每次模型改完文件自动跑 lint。这个需要一些配置功底但配好之后很省心。/mcp管理 MCP 服务器连接。MCP 是外部工具集成协议能让 Claude Code 连上数据库、API、第三方服务。我接了一个内部文档系统的 MCP查接口文档不用切窗口了。5.4 工作流指令的实战组合分享一个我常用的组合早上开工claude -c续上昨天的会话先/memory确认项目记忆加载正常然后/diff看昨天有没有遗留未提交改动接着/review快速过一遍确认没问题就继续开发。这一套下来不到一分钟但能避免很多“昨天改到一半忘了”的尴尬。另一个组合是处理 issueclaude -p 读一下 issue.md分析需要改哪些文件输出方案先做分析确认方案后再进交互模式实施。分析和实施分开思路更清晰。6. 常见问题排查与避坑实录6.1 会话与上下文类问题问题一模型突然“失忆”不记得前面说过的约定。排查思路先/memory看记忆文件是否正常加载再检查是不是上下文超限触发了自动压缩。如果是压缩导致的关键约定可能被摘要掉了。解决办法是把重要约定写进CLAUDE.md而不是只靠对话记忆。问题二/compact之后模型行为变了。这是正常的压缩会丢失细节。我的经验是压缩前先把关键决策用#记进记忆文件压缩后这些还在。另外压缩后可以补一句“继续之前的任务当前进度是 xxx”帮模型重新对齐。问题三会话启动报锁文件错误。通常是上次非正常退出留下的。找到项目下的锁文件删掉即可或者用/exit正常退出养成习惯。6.2 权限与操作类问题问题四模型反复请求权限很烦。用/permissions把常用操作比如读文件、跑测试设为免确认危险操作比如删文件、执行任意命令保持确认。分级管理比一刀切好。问题五模型改了不该改的文件。第一确保在 git 干净状态下操作随时能回滚。第二明确指令范围“只改 A 文件”。第三改完/diff检查。这三步做好基本不会出大问题。问题六批量操作中途失败。模型批量改文件时如果中途出错可能改了一半。这时候git diff看改了哪些git checkout回滚然后缩小批量范围重试。别在失败状态下继续让模型“修复”容易越修越乱。6.3 输出质量类问题问题七模型给的方案太泛不落地。这是提问方式的问题。把“帮我优化这个函数”换成“这个函数在数据量 10 万时会慢分析瓶颈并给出具体优化代码”输出质量立刻不一样。给约束、给场景、给期望输出格式是提升质量的三板斧。问题八模型理解错了需求。先别急着纠正让它复述一遍它的理解。“你刚才理解的需求是什么复述一下”往往能发现是哪里歧义了。然后重新表述比在错误理解上打补丁高效。问题九代码能跑但风格不符项目规范。根因是CLAUDE.md没写清楚规范。把项目的 lint 规则、命名习惯、目录约定写进去模型会遵守。我还会在CLAUDE.md里放一两个“范例文件”路径让模型参考风格。6.4 常见问题速查表现象可能原因解决指令模型失忆上下文压缩或记忆未加载/memory检查重要约定写进 CLAUDE.md反复要权限权限设置过严/permissions分级调整改了不该改的指令范围不明确明确文件范围改后/diff方案不落地提问太泛加约束、场景、输出格式风格不符规范未写入记忆编辑 CLAUDE.md 补充规范会话启动报错锁文件残留删除锁文件用/exit退出6.5 我踩过的最深的三个坑第一个坑是在脏工作区让模型改代码。有次我手头有一堆未提交改动又让模型改另一个文件结果它把两者混在一起diff 乱成一团回滚都不敢回。从那以后改代码前必git status。第二个坑是过度依赖自动权限。图省事开了免确认模型把一个.env文件的内容读出来写进了日志。虽然本地环境没造成实际损失但吓出一身冷汗。权限这东西宁可多确认一次。第三个坑是把 Claude Code 当搜索引擎用。问它“React 的 useEffect 怎么用”它给的和网页搜索差不多还占上下文。这类通用知识问题不该问它它的价值在于结合你的项目上下文给具体方案。问“我这个组件里的 useEffect 依赖数组有没有问题”才有意义。7. 把指令用成肌肉记忆的进阶思路7.1 建立个人指令清单100 条不用全记但要建立自己的“高频 20 条”。我的做法是在CLAUDE.md里放一个“常用指令速查”段落把自己最常用的指令和用法写进去。这样既提醒自己也让模型知道我的工作习惯。更进一步可以把常用工作流写成 shell 别名或脚本。比如我有个cr别名展开是claude -p review 当前 git diff按严重程度列出问题敲两个字母就完成一次快速审查。7.2 团队协作中的指令标准化如果你要把 Claude Code 引入团队CLAUDE.md就是标准化的抓手。把团队规范、常用命令、目录约定、审查清单都写进去新人 clone 下来就能用统一的方式和 AI 协作。我们团队还维护了一个共享的“指令片段库”把高频指令和提示词模板沉淀下来避免每个人重复造轮子。7.3 指令之外的思考工具再强也只是放大器。Claude Code 放大的是你原本的工程能力——你架构清晰它帮你更快落地你思路混乱它帮你更快地产生混乱。我见过有人指望它“自动写好整个项目”结果得到一堆能跑但没法维护的代码。指令是术工程判断是道别本末倒置。最后分享一个我最近养成的习惯每周花十分钟回顾这周用 Claude Code 的过程把新发现的顺手指令记下来把踩过的坑写进CLAUDE.md。这个复盘习惯坚持两个月后我的指令使用效率大概翻了一倍。工具在迭代用法也在迭代持续记录比一次性背清单有用得多。
