别小看“会敲命令”和“会用命令”之间的差距。我大概是从 Claude Code 刚开放命令行预览时就开始折腾它了前前后后在各种项目里跑了几百个会话。结论很直接Claude Code 的能力上限很高但大多数人的使用效率卡在对命令边界不清楚这件事上——不知道什么时候该用/clear什么时候该用/compact更不知道-p模式和交互模式到底该什么时候切换。这篇内容不是官方文档的复读而是把我实际跑项目时挑出来的 14 个命令按“启动、会话、上下文、审查、成本、权限”几个纬度拆开讲。每个命令我都尽量说清楚三件事它是干什么的、什么场景下用最顺手、什么场景下别硬用。文章末尾还会用一个真实需求走一遍完整工作流以及我踩过的几个坑。无论你是刚装好 Claude Code 的新手还是已经用了几个月的重度用户这份边界清单应该都能帮你省掉不少试错时间。1. 14个命令速查表先抄作业再看边界1.1 为什么命令边界比命令本身更值钱Claude Code 的命令并不复杂复杂的是它运行的上下文环境。它是一个跑在终端里的编码代理这意味着它既能读文件、改文件、执行命令也能跨多个会话保留项目记忆。这个能力一旦用偏最常见的问题是上下文越攒越厚回答越来越“温”最后整个会话变得又慢又贵。我见过不少用户一个会话从早上一路开到下午中间既不/clear也不/compact累计塞进去几万行代码内容结果模型开始反复忘记前面的需求只能靠人工一遍遍提醒。这不是模型变笨了而是上下文窗口被无关内容挤占了。理解了这层你就会明白命令本身只是工具边界才是效率的核心。知道了哪些命令擅长清理上下文、哪些命令负责恢复会话、哪些命令能在不发散的前提下做代码审查你才能真正把 Claude Code 从“一个问答工具”升级成“一套可重复执行的工作流”。1.2 14个命令一句话总览下面这张表是我自己整理出来的“常用命令速查表”。建议先照着用一遍再去看后面的边界解析不然容易看了一堆盘根错节的细节却记不住最开始该敲哪个命令。命令作用典型用法一句话边界claude进入交互式会话直接在终端输入claude适合边聊边改不适合无人值守claude -p 任务一次性非交互执行claude -p 看看 tests/ 下的失败用例适合脚本与流水线不适合多轮追问claude --continue继续最近一次会话claude --continue适合刚关闭终端马上接着干claude --resume id恢复指定会话claude --resume abc123适合多任务并行、跨天续跑claude --model 型号指定模型启动claude --model claude-sonnet-4-5需求简单别用大模型烧钱且慢claude --output-format json输出结构化 JSON搭配-p使用适合程序解析不适合人肉阅读claude --allowedTools ...控制可用工具claude --allowedTools Read,Edit,Bash(git*)别图省事开全量权限/init初始化项目上下文在项目中执行/init只在项目根目录用别频繁重复跑/clear清空当前会话上下文感觉回答开始发散时用会丢失前面对话需要重新交代背景/compact压缩上下文长任务进行到一半、上下文告急时用压缩有损关键细节可能被省略/context查看上下文占用定期确认 token 使用量只是一个查看命令不能直接修改/cost查看会话费用收工前跑一下只算估算值别当账单精确数据/review对最近改动做代码审查完成一阶段改动后使用审查建议要人工复核别无脑采纳/mcp管理 MCP 服务器/mcp查看或添加服务别一次挂太多 MCP上下文压力大2. 命令边界拆解什么场景下用什么场景下别用2.1 启动类命令交互、一次性和会话恢复的正确姿势claude交互模式应该是最常启动的方式。你进入项目目录敲一下claude就进了一个可直接对话的命令行环境。它可以配合 Bash 工具直接读目录、跑测试、修改代码。我的习惯是先让它“看看项目结构”再决定接下来的任务切分。这个模式的好处是反馈即时坏处是太容易聊着聊着就跑偏。跑偏不是模型的错是命令的使用边界没控制住交互模式适合探索、重构、理解代码但不适合把它当成一个“永远在线”的挂机工具。claude -p 任务是非交互模式执行完就退出输出可以直接被脚本捕获。这个命令是我做自动化时最依赖的入口。比如我可以写一个 shell 脚本循环跑一批小任务每个任务独立会话互不干扰。边界也很明确-p模式没有连续上下文每个问题都是“一次性消费”。如果你的任务需要多轮确认比如“先找出接口定义再改实现最后补测试”那你最好进交互模式或者把多步要求写成一段足够清晰的长指令一次性交给-p执行。claude --continue和claude --resume这两兄弟很容易混。--continue是自动接上最近一次会话适合你刚关掉终端、又想立刻回到刚才的战场--resume则是按 session id 精确恢复某个历史会话适合同时在几个项目分支之间切换。我实际用的时候有个心得多任务并行时建议给每个任务单独开一个会话并且像记 commit message 一样把会话 id 记在笔记里。否则第二天你想恢复几天前的讨论光靠--continue是找不到的。2.2 上下文管理命令别让上下文成为你的隐形瓶颈上下文是 Claude Code 最值钱也最容易被浪费的资源。很多人在项目干到一半时觉得 Claude Code“变笨了”大概率不是能力问题而是上下文窗口被塞满了无关内容。/context是第一个应该学会的查看命令。它能让你看到当前会话上下文占用情况。我通常的做法是每完成一个小阶段就敲一次/context如果占用已经超过 70%我就会开始考虑是/compact还是/clear。/compact是长任务中途的“压缩包”。它的原理是把之前的对话历史做一次摘要把核心信息浓缩后继续对话。好处是能把数百 KB 的上下文压到很小的体积坏处是压缩过程有信息损失。比如你之前讨论了很多次才定下来的某个设计取舍压缩后可能只剩一句“这里使用方案 A”至于为什么不用方案 B 的推理过程可能就被丢掉了。所以我的使用边界是只有在任务处于后半段、核心结论明确、剩余工作主要是执行时才放心用/compact。/clear则是直接清空会话上下文比/compact更狠但也更干净。当你发现上下文已经被大量无效讨论污染或者上一个任务已经结束、你准备开启一个完全不同方向的任务时直接/clear是最高效的选择。边界鲜明一旦清空之前的对话细节就全部消失了。如果后面还需要用到先前结论请先确保关键内容已经落地到文件或 CLAUDE.md 里再执行/clear。/init在这个分类里有点特殊。它不是清上下文而是生成项目的全局记忆。在项目根目录执行后Claude Code 会扫描项目结构、读取关键文件生成一份CLAUDE.md放在项目里后续会话都会自动参考这份文件。我的建议是新项目第一次上手时进入交互模式后第一件事就是执行/init让它把项目的技术栈、目录约定、常用命令固化下来。但要克制的是别隔几分钟就重跑一次/init。频繁初始化会让 CLAUDE.md 越长越臃肿最终反而稀释掉关键信息。2.3 成本与状态命令花钱要看得见改代码要带着审/cost是一个很容易被忽视但实际很实用的命令。它会显示当前会话的估算费用。在预算敏感的项目里我基本是每个小时敲一次盯着花销有没有失控。这个命令的边界在于它的“估算”属性它根据 token 用量和模型单价算出一个近似值不代表最终账单。但用来做成本趋势判断已经够了。如果你发现一个简单任务花了超出预期的钱通常不是费用计算有问题而是你的会话上下文里堆了太多无用内容或者你在用大模型做本该用小模型完成的事。/status能快速展示当前会话的一些关键状态信息比如项目目录、模型、MCP 服务数量、会话 id 等。这个命令在排查问题时特别有用。比如你怀疑某个改动没生效先跑一下/status确认当前工作目录是不是你以为是的那一个。这个步骤虽然不起眼但能避免很多“改错了文件”的乌龙。/review是我个人觉得 Claude Code 被低估的功能之一。在一个阶段的开发工作完成后敲一下/review它会基于当前会话上下文检查自上次提交以来的代码改动列出潜在问题、风格冲突和安全风险。边界也很明显它是“辅助审查”不是“替代审查”。我遇到过它提出修改建议合理但上下文不完整的情况也遇到过它把同时改动的好几个无关文件强行扯上关联的情况。所以正确的用法是把/review的结果当成第一遍检查然后人工快速确认后再进 commit。2.4 模型选择与权限命令越界一次就要花一个晚上后悔claude --model可以指定启动时使用的模型。不同模型在速度、成本、复杂任务处理能力上差距非常大。我的选择逻辑很简单常规重构、写测试、生成模板用轻量级模型涉及复杂架构设计、多文件联动改动用重量级模型。实际项目的收益并不总是“越大越强”有时候一个简单任务用大型模型反而会因为过度思考而执行更多无用步骤既慢又贵。--allowedTools是控制 Claude Code 能使用哪些工具的开关。这个命令的边界极其重要。你可以在启动时传入一组白名单比如只允许读取文件、编辑文件、执行 git 命令不允许它任意运行网络请求或安装依赖。我见过有人为了省事直接给全量权限把系统交给 Claude Code结果它顺手跑了包管理器的自动更新把本地环境搞乱了。这个坑一旦踩上恢复环境的时间远超省下的那点确认操作时间。还有一个容易手滑的参数是--dangerously-skip-permissions看名字就知道不建议日常使用。它会让 Claude Code 跳过工具使用确认自动执行所有命令。这个参数只适合在完全隔离、可随时重建的沙箱环境里使用或者你有绝对的把握当前任务不需要任何交互确认。别在高价值的生产环境目录里开这个开关风险完全不对等。3. 串成工作流从需求到提交的完整链路3.1 从需求到落地一次真实的“表格导出 CSV”任务光说命令太零散我拿一个真实任务把 14 个命令串起来。假设我现在维护一个内部后台系统需求是给现有的数据表格加一个“导出 CSV”按钮。第一步我会在项目根目录敲claude进入交互模式。如果这个项目是从没跑过的新项目我会先执行/init让它生成 CLAUDE.md把项目的目录规范、测试命令、构建方式固化下来。这一步能减少后面每个小任务的沟通成本。第二步我会用一段自然的任务描述向它提出需求包括表格组件的文件路径、现有的接口字段定义、以及导出格式要求。此时我会盯着/context的输出确认这次任务占用的上下文规模。如果项目很大直接打开太多文件我会让它先聚焦到表格组件和接口定义不要一股脑读整个仓库。第三步当模型给出实现方案并开始改代码时我会保持交互模式观察它用 Bash 工具跑测试。如果测试挂了会看到它自动分析错误信息、重新修改代码的循环这个阶段最好别打扰。等到一轮改动基本完成我会跑一下/review让它把最近改动过一遍挑出潜在问题。最后一个阶段我会用git add和一般 git 流程完成提交然后敲/clear清空当前上下文再进入下一个并行任务。这套流程下来命令边界非常清晰/init只出现一次/context周期性出现/review只在小阶段结束时出现/clear只在上下文彻底“用完即弃”时出现。3.2 中长任务的分段与恢复策略如果任务很长比如要跨好几天完成一个模块的重构我不会让一个会话无限期地存在下去。原因很朴素上下文会增长成本会上涨而且模型对多天前讨论细节的记忆会随着compact次数的增加而失真。我的做法是把大任务拆成几个清晰的里程碑。每个里程碑对应一次会话。比如“第一步迁移接口定义”、“第二步改写调用方”、“第三步清理旧代码”这样拆。每次会话结束前我会要求它把当前进度和下一步计划写进项目的 NOTES 文件或直接更新 CLAUDE.md然后把session id记录到终端外的笔记里。需要恢复会话时用claude --resume session id就能回到当时的现场所有历史上下文还在。这种做法的边界在于你必须在关键节点主动留存足够多的“外部记忆”因为--resume只能恢复模型侧的记忆恢复不了你大脑里临时冒出的想法。把想法及时写在代码注释和项目文档里是比任何命令都更可靠的工作流保障。3.3 用 JSON 输出和单次执行搭自动化流水线除了交互式使用Claude Code 也可以当成一个可编程的“代码执行后端”。把-p和--output-format json组合起来就能把一次性任务接入自己的脚本或 CI 流程。比如我可以写一个简单的 shell 脚本遍历仓库里的多个模块对每个模块执行claude -p 分析这个目录指出测试覆盖率最低的文件 --output-format json然后把输出的 JSON 解析出来再决定下一步动作。这个组合适合批量代码审查、批量生成文档、批量重构模板。这里的边界是-p模式没有交互上下文任务描述必须自包含。如果你想让它基于前一个任务的结果做下一步必须手动把结果拼进第二个-p的指令里或者在同一个-p指令里完整叙述“先分析什么、再根据结果做什么”。另外JSON 输出在带格式日志时的可读性很差如果只是给人看务必不要开 JSON 模式。这个模式是给程序用的不是给人强行读的。4. 常见问题与排查技巧实录4.1 几个高频率翻车现场第一个高频问题是“会话中途 Claude Code 开始反复问你无聊的确认问题”。这里往往不是模型变傻了而是权限配置太窄或者太宽。如果权限太窄它每执行一次命令都要向你确认体验很割裂。我会在启动时用--allowedTools把当前任务确定需要的权限一次性给足比如Read,Edit,Bash(git*)既减少中间确认次数又不至于放开整个系统。第二个高频问题是“上下文越跑越乱模型开始答非所问”。我之前说过这不是玄学是上下文溢出。排查步骤很简单先敲/context看占用如果已经极高敲/compact压一次如果仍然感觉混乱再敲/clear重开。不要一上来就clear有些讨论结论还依赖历史上下文直接清空会导致你不得不再花十分钟重新交代背景。第三个高频问题是“文件被改错了但不知道改了什么”。这是开全量权限或跳过确认的典型副作用。我建议每次让 Claude Code 动手改代码前在指令里明确强调“列出你准备改的文件列表等确认后再执行”。当然更安全和高效的是用 git 管理所有变更每完成一个小阶段就 diff 检查一次有问题立刻git checkout回去把损失限制在分钟级别。4.2 什么时候该 reset什么时候该 compact这个问题被问得太多了我直接给一个判据。如果你的任务目标和上下文里的既有信息高度一致比如“继续实现之前讨论过的功能”上下文占用又高就用/compact压缩后最关键的设计决策如果仍然保留在 CLAUDE.md 或代码注释里那么即使压缩有损失也不会让任务垮掉。如果你的任务方向已经变了比如之前一直在做后端接口现在突然要看前端样式问题这时候上下文里的历史内容绝大部分都是噪音直接/clear比/compact更合适。换个说法/compact适合“同一段故事的中场休息”/clear适合“换一段新剧本的开场”。4.3 成本失控前的三个信号根据我的观察成本失控前通常会出现三个信号。第一个信号是/context占用率持续在 80% 以上说明你一直在给会话堆料而堆料最终都会折算成 token 费用。第二个信号是模型频繁重复运行类似的命令比如反复跑同一组测试却要分很多次看结果说明任务不够聚焦可以考虑把任务描述改得更精准。第三个信号是/cost的估算值在短时间内快速翻倍。如果遇到这种情况我会直接clear重开而不是继续在一个被污染的会话里纠缠。另外一个容易被忽略的成本细节是模型选择。默认模型可能对简单任务来说“用力过猛”。实际做日志分析、批量脚本生成、格式转换这类线性任务时我会用轻量模型跑复杂度高的架构分析才换大模型。这个习惯长期下来能省不少预算。5. 给不同基础的人几条使用建议5.1 新手开始时的最小路径如果你刚装好 Claude Code不知道怎么配工作流我建议你先不要碰任何高级参数。最简单的路径是进项目目录敲claude先跑/init然后像和一个新同事说话一样描述你想做的事。第一个星期的目标不是“用最少的 token 完成任务”而是“建立对命令边界的感觉”。你可以在每次任务结束后看一下/context和/cost慢慢形成“什么场景消耗大、什么场景消耗小”的判断然后再开始用-p、--resume、--allowedTools这些更精细的控制手段。5.2 老手可以再往深挖的三个组合用法已经有了一定使用经验的话我推荐再试三个进阶组合。第一个是“双会话并行法”一个会话专门做代码调研和方案设计另一个会话专门做具体实现。这样设计会话不会被实现过程的琐碎上下文污染方案讨论也更干净。第二个是“CLAUDE.md 驱动法”把项目规范、常用命令、开发陷阱都写进 CLAUDE.md然后每次新会话都依赖/init生成的基础记忆让模型从第一步就站在“懂这个项目”的位置上。第三个是“自动化集成法”把-p模式封装进自己的脚本工具集比如一键生成新组件的模板代码、一键做提交前审查把它当成一个可编程的代码助手而不仅仅是一个交互式聊天窗口。这几个组合的共同点都是围绕命令边界去设计工作流上下文该怎么隔离、权限该怎么收敛、成本该怎么观察。边界清晰了Claude Code 才能从“有趣的玩具”变成“可靠的生产力工具”。我自己用下来最大的感受是Claude Code 这类终端代理工具的学习曲线并不在命令本身而在如何克制使用它的冲动。不是所有任务都需要开新会话也不是所有问题都适合丢给它。把合适的命令用在合适的阶段比记住再多快捷键都管用。希望这份 14 个命令的边界清单能让你下一次跑项目时少走几段弯路。