1. 为什么“指令清单”比“功能清单”更值得收藏用 Claude Code 的人大概都有过这种体验装好之后打开终端敲下claude然后……愣住。知道它能读代码、能改文件、能跑命令但真到用的时候脑子里只有一句“帮我看看这个项目”。这就像手里攥着一把瑞士军刀却只会用它开啤酒。我最初接触 Claude Code 的时候也是这个状态。前两周基本就是把它当个“能聊天的 grep”在用直到有一次看同事操作——他几乎不敲自然语言全程用斜杠指令和快捷键在会话、文件、模型之间来回切换效率差了大概三倍。那次之后我才意识到Claude Code 的真正门槛不在“会不会用”而在“知不知道有哪些指令”。这篇内容就是把我自己日常高频使用的指令、以及从社区里收集到的常用指令按使用场景整理成一份可查、可抄、可复现的清单。它适合三类人刚装好 Claude Code 还没摸清门路的新手、用了一段时间但总觉得效率上不去的中级用户、以及想把这套工具纳入团队工作流的技术负责人。全文不涉及任何需要特殊网络环境的内容所有指令都在标准终端环境下验证过。需要先说明一点Claude Code 的指令体系分三层——CLI 启动参数、会话内斜杠指令、键盘快捷键。很多人只熟悉中间那层其实另外两层在特定场景下更省事。下面按这个结构展开每一条都尽量说清楚“什么时候用”和“为什么这么设计”。2. 启动阶段的 CLI 参数决定你这一天怎么干活2.1 最容易被忽略的-p与--print模式大部分人启动 Claude Code 就是一句claude进交互式会话。但如果你只是想让它在 CI 里跑一次代码审查、或者把一段输出直接管道给别的工具交互式会话反而是累赘。claude -p 解释这个函数的作用这种用法叫print 模式它执行完就退出输出直接打到 stdout。我把它用在两个地方一是写 git hook提交前自动让 Claude 检查一遍 diff二是配合xargs批量处理文件。# 批量给每个 Python 文件生成 docstring 建议 find . -name *.py | xargs -I {} claude -p 为 {} 中的函数生成 docstring 建议只输出建议内容这里有个坑print 模式默认不会自动确认文件修改它只输出文本。如果你希望它真的改文件得配合--allowedTools参数显式授权。我一开始不知道这点跑了半天发现它只是在“建议”文件纹丝不动。2.2--model与模型切换的取舍逻辑Claude Code 支持在启动时指定模型。日常写业务代码我用默认模型就够了但遇到两类任务我会切一是需要长上下文推理的架构重构二是需要快速响应的简单补全。claude --model claude-sonnet-4-5 重构这个模块的分层结构选型的逻辑很简单推理密度高的任务用强模型吞吐量大的任务用快模型。我做过一个粗略统计同一个重构任务强模型一次通过率大概 70%快模型 40% 但速度快一倍。如果你的任务是“改 50 个文件的 import 顺序”这种机械活快模型明显更划算。2.3 工作目录与--add-dir的边界默认情况下 Claude Code 只能访问你启动它的那个目录。但真实项目经常是 monorepo前端在apps/web后端在services/api共享库在packages/shared。这时候--add-dir就派上用场了。claude --add-dir ../shared --add-dir ../api注意每加一个目录Claude 的上下文窗口就多一份占用。我建议只加当前任务真正需要的目录不要图省事把整个仓库都挂上否则它会在无关文件里“迷路”。2.4 权限相关的启动参数Claude Code 默认对文件写入、命令执行是保守的每次都要你确认。这在探索阶段是好事但如果你已经信任某个任务范围反复确认会很烦。--allowedTools可以预先授权特定工具。比如你明确知道这次任务只需要读文件和跑测试claude --allowedTools Read,Grep,Glob,Bash(npm test:*)这里的Bash(npm test:*)是模式匹配只允许执行以npm test开头的命令。这种细粒度授权比直接开--dangerously-skip-permissions安全得多。我个人的原则是永远不用全权限跳过宁可多写几行授权规则。3. 会话内的斜杠指令日常使用的主战场3.1/help之外你真正该记住的几个/help谁都会敲但它列出的指令太多反而记不住。我筛出日常真正高频的几条指令实际用途我的使用频率/clear清空当前会话上下文每天十几次/compact压缩上下文保留摘要长会话必用/cost查看本次会话的 token 消耗每天几次/model会话内切换模型按任务切换/review对当前改动做代码审查提交前必用/init生成项目级 CLAUDE.md新项目首次/clear和/compact的区别值得说清楚。/clear是彻底重置之前聊的全忘掉/compact是把历史对话压缩成摘要保留关键信息但释放 token 空间。我的习惯是换任务就/clear同一任务聊太久就/compact。有一次我做一个大重构会话开了两个小时没 compact结果响应越来越慢/cost一看已经烧了不少compact 之后立刻顺畅了。3.2/init生成的 CLAUDE.md 到底该写什么/init会扫描你的项目生成一个CLAUDE.md文件。这个文件是 Claude Code 的“项目记忆”每次启动都会读。很多人 init 完就不管了其实这个文件的质量直接决定 Claude 对你项目的理解程度。我自己的CLAUDE.md一般包含四块# 项目约定 - 包管理器用 pnpm不要用 npm - 测试框架是 vitest跑测试用 pnpm test - 提交信息遵循 conventional commits # 目录结构 - src/components 放通用组件 - src/features 放业务模块 - 不要修改 src/generated 下的文件 # 常用命令 - 类型检查pnpm typecheck - 格式化pnpm format # 禁忌 - 不要引入新的依赖除非我明确要求 - 不要改 .env 文件最后那条“禁忌”特别重要。Claude 有时候会“热心”地帮你装个库、改个配置写清楚边界能省很多事。3.3/review与代码审查的实战细节/review是我用得最多的指令之一。它会读取当前的 git diff然后给出审查意见。但直接敲/review效果一般因为它不知道你关心什么。更好的用法是带上下文/review 重点关注错误处理和边界条件忽略代码风格我实测下来加上关注点之后审查意见的命中率明显提升。另外一个小技巧先git add你想审查的文件再/review这样它只看暂存区的改动不会被无关的临时文件干扰。3.4 自定义斜杠指令把重复劳动固化下来Claude Code 支持在.claude/commands/目录下放 markdown 文件每个文件就是一个自定义指令。这是我认为最被低估的功能。比如我经常需要“给当前文件写单元测试”就建了个.claude/commands/test.md为当前打开的文件生成单元测试。 要求 1. 使用 vitest 2. 覆盖正常路径和至少两个边界情况 3. mock 掉所有外部依赖 4. 测试文件放在同目录的 __tests__ 下之后在会话里敲/test就能触发。团队里每个人都可以贡献自己的指令慢慢就攒出一套“团队指令库”。这比每次手打一长串 prompt 高效太多。4. 键盘快捷键与交互技巧省下的都是时间4.1 多行输入与编辑的隐藏操作Claude Code 的输入框支持多行。默认回车是发送但如果你要写一段长 prompt可以用\加回车换行或者直接ShiftEnter取决于终端配置。更实用的是历史指令召回按上箭头可以翻之前输入过的内容。我经常用这个来微调上一次的 prompt而不是重新打一遍。还有一个很多人不知道的在 Claude 输出过程中按Esc可以中断生成。当你发现它理解偏了别等它输出完直接打断重新说省 token 也省时间。4.2 文件引用的语法在 prompt 里提到文件时用开头会自动触发路径补全src/utils/date.ts 这个文件里的时区处理有问题帮我看看这比手打完整路径快而且能确保路径正确。我习惯在描述问题时总是带上文件路径这样 Claude 不用去猜你说的是哪个文件。4.3 图片与截图的使用Claude Code 支持直接粘贴图片。做前端的时候我经常把设计稿截图粘进去然后说“按这个实现”。或者遇到报错直接截错误信息的图比手打错误信息准确。粘贴的方式是CtrlVmacOS 上是CmdV终端会自动把剪贴板里的图片转成引用。这个功能在排查 UI 问题时特别好用。5. 把指令串成工作流几个真实场景的完整操作5.1 场景一接手一个陌生项目刚 clone 一个项目怎么快速摸清结构我的流程是claude启动先/init生成 CLAUDE.md让它读 README 和 package.json问“这个项目的技术栈和启动方式是什么”用引用入口文件问“请求从入口到数据库的完整链路”/clear清空然后针对具体模块深入这套流程下来大概十分钟能对一个中等规模项目有个整体认知。关键是先建立全局再深入局部不要一上来就扎进某个文件。5.2 场景二修一个 bug 的完整指令序列假设线上报了个 bug我的操作序列是报错相关的文件 这个函数在并发调用时会返回错误结果帮我定位原因 分析后 /review 针对刚才的修改检查是否有遗漏的边界情况 确认后 帮我写一个能复现这个 bug 的测试用例 测试通过后 /compact注意最后那个/compact——修 bug 的过程往往对话很长compact 一下为下一个任务腾空间。5.3 场景三批量重构的指令组合重构 20 个文件的 API 调用方式这种活最考验指令组合# 先用 print 模式批量分析 claude -p 列出 src/api 下所有直接使用 fetch 的文件 files.txt # 再逐个处理 cat files.txt | xargs -I {} claude -p 把 {} 中的 fetch 调用改成使用封装的 request 函数批量操作一定要先分析、后执行而且执行前用 git 提交一次方便回滚。我有一次没提交就批量改结果改错了想回退只能一个个手动改回来。6. 那些没人告诉你但迟早会踩的坑6.1 上下文窗口不是越大越好很多人以为把整个项目都塞给 Claude 效果最好其实相反。上下文里无关信息越多它越容易“分心”。我做过对比同一个任务只给相关文件 vs 给整个 src 目录前者的准确率明显更高。所以--add-dir要克制引用要精准长会话要/compact。上下文是稀缺资源要像管理内存一样管理它。6.2 指令的“幂等性”问题有些指令重复执行会出问题。比如你让 Claude “在文件末尾追加一行配置”如果它执行了两次就会追加两行。涉及写操作的指令执行前最好确认一下当前状态。我的习惯是写操作前先让它读一遍目标文件确认它知道当前内容是什么再让它改。6.3 模型对“否定指令”的理解偏差“不要修改 X 文件”这种否定指令Claude 有时候会理解成“要关注 X 文件”。更可靠的写法是正面描述“只修改 Y 文件其他文件保持原样”。这个坑我在早期踩过好几次明明说了不要动配置它还是动了。后来改成正面表述问题就少了。6.4 终端环境的兼容性Claude Code 在不同终端下的表现有差异。iTerm2、Windows Terminal、VS Code 内置终端我都试过快捷键和图片粘贴的支持程度不一样。如果你发现某个快捷键不生效先确认是不是终端拦截了。VS Code 里用的话建议装官方扩展集成度比在终端里跑高不少尤其是 diff 查看体验。7. 指令清单的维护方式让它跟着你一起成长最后说个方法论层面的东西。这 100 条指令不是让你背下来的而是让你建立自己的指令库。我的做法是维护一个~/.claude/commands/目录把高频操作都做成自定义指令。每当我发现自己第三次手打同一段 prompt就把它固化下来。半年下来攒了三十多条覆盖了代码审查、测试生成、文档撰写、重构等场景。同时我会定期回顾/cost的输出看看哪些指令消耗大但收益低该优化的优化该删的删。指令库和代码一样需要持续重构。工具的价值不在于功能多少而在于你能否在正确的时机用上正确的指令。这份清单是个起点真正的效率提升来自你把它内化成肌肉记忆然后根据自己的工作流不断增补。我现在已经很少刻意想“该用哪个指令”了手比脑子快——这大概就是用熟了的标志。