Claude Code用了一年，我最终只留下这6个命令

保哥用了一年Claude Code，能装的命令几乎都装过，最后每天真正离不开的只剩6个。这篇不是命令手册，是做完减法之后的复盘：哪几个命令对应着你现在就有、却还没意识到的问题，以及一个SEO和独立站从业者，该怎么把它们用在批量改meta、写GSC脚本、上线前查漏这些真实活计上。顺带把一个被无数教程讲拧的地方掰正——这6样里，真正的“命令”和其实是“配置”的，根本不是一回事。

一年前我也干过同一件事：听说哪个命令好用就装，看到哪个功能眼熟就试，收藏夹里塞满了别人整理的“Claude Code命令大全”。一年下来，桌面上那张速查表早就吃灰了。真正每天敲、敲到形成肌肉记忆的，数来数去就6个。

其余的不是没价值。是那种“知道有这么个东西，真要用的时候再翻文档”的价值。这跟挑工具是一个道理：抽屉里囤二十把螺丝刀的人，干活时手边永远是那三把。所以我想换个讲法——不按功能罗列，而是反过来，从你手头正在发生的问题倒推：你现在就卡在这儿了，只是还没把它叫出名字。

为什么大多数Claude Code命令你其实都用不上？

这里有个反直觉的规律：一个命令你越早用上，它对你的价值越高；越是拖到很晚才第一次用，往往说明它对应的问题，你之前压根没意识到自己有。

举个最常见的：你从来不看上下文占用，直到某天会话越拖越慢、回答越来越离题，才反应过来“原来上下文是能管理的”。那一刻你才去搜怎么看上下文——但你慢了，这个本该第一周就用上的习惯，被你拖到了第三个月。

市面上那些“30个命令全解析”的文章，逻辑是穷举：把所有能敲的都列给你，你自己挑。问题是，穷举不解决“先用哪个”。新手看完更慌，老手看完发现80% 用不上。这篇反着来——只讲6个，是因为它们对应的6个问题，你现在就有，区别只在你认没认出来。这跟站内那篇Claude Code高效开发20技巧速查指南正好配成一对：那篇铺广度，求全；这篇做减法，求准。先把这6个用熟，再回头翻那张大表，你会知道自己缺的到底是哪一格。

先分清楚：哪些是斜杠命令，哪些只是配置？

动手之前先纠一个几乎所有教程都讲拧的地方，不纠正，后面会一直别扭。很多文章把这6样统称“6个命令”，但它们根本不是同一种东西，混在一起讲，你会以为全都能在对话框里敲一行就生效——结果有两样你敲了半天没反应。

准确地拆，是这样：

• 会话里直接敲的斜杠命令：/compact、/clear、/context、/effort、/security-review，外加一个打开权限界面的 /permissions。这些是即时生效的指令，敲完回车就动。
• 写在settings.json里的配置：permissions 的那套放行/询问/拒绝规则，以及 sandbox 沙箱。这些不是你“敲”出来的，是你把规则写进配置文件、让它常驻生效的。/permissions 这个命令只是帮你可视化地查看和增删这些规则，规则本身住在文件里。

这个区分不是抠字眼。它直接决定你怎么管理它们：斜杠命令是“当下这一下”，随用随敲，不留痕；配置是“长期那一套”，写一次、进版本库、整个团队共享。做SEO自动化尤其要拎清——你给客户站写的批量脚本权限边界，属于配置，应该check进Git让协作的人都受同一套约束；而某次会话要不要压缩、这次任务给多少算力，属于命令，是临场决定。把“当下”的东西当“长期”来配，或者反过来，都会让你别扭。

还有个更要命的细节：这些权限规则是由Claude Code这个程序强制执行的，不是由模型本身判断的。你在CLAUDE.md里写多少“不准碰 .env”，那只是影响模型“想不想”碰；真正决定它“能不能”碰的，是settings.json里的deny规则。这两层差着一个数量级的可靠性——靠提示词约束等于贴张纸条，靠配置约束才是上了锁。下面6节，我会标清楚每一样到底是命令还是配置。

/compact凭什么比/clear更该成为你的条件反射？

我一年前的坏习惯是：会话一乱就 /clear。

这是个特别隐蔽的坏习惯，因为它当下感觉很爽——一键清空，世界清净。但你清掉的是什么？是之前辛辛苦苦建立起来的全部上下文：你跟它约定好的技术栈、你们反复商量才定下来的方案、它已经啃明白的那套代码结构。你以为在“重置”，其实是在“认输重开”。

/compact 干的是另一件事：把当前会话压缩成一份更干净的摘要，然后接着往下走。主线任务还在，关键约束还在，那些已经过时的试错、被否掉的方案、车轱辘话——被压没了。说人话就是，/compact 是会话瘦身，/clear 是会话自杀。官方给的经验阈值也很实在：上下文用量超过80% 左右就该 /compact，只有真要彻底换个任务，才用 /clear。

而且 /compact 还能带指令。你可以敲 /compact 专注于关键词分组那部分逻辑，让它压缩时刻意保住你最在乎的那条线——这一手后面会救你的命，下文踩坑环节专门讲它怎么反过来咬人。

放到SEO的活上，这个区别特别值钱。我常碰到这种场景：在一个会话里跟它磨一套批量改title标签的规则，先试了“主关键词前置 + 品牌后缀”，发现某些长尾页太挤；又试了“按模板分组、各走各的句式”，最后定下来用栏目维度分桶处理。这个结论得留住，但前面那些“方案A太挤、方案B又散”的过程，完全可以压掉。

这时候 /compact，下一轮上下文干干净净，它还记得你们定的分桶规则，可以直接接着生成。要是手贱 /clear，对不起，分桶逻辑、踩过的坑、你举过的例子，全没了，你得从头再讲一遍——而它很可能又把你之前否掉的方案A重新提一遍，因为它根本不记得那条路走不通。

我现在的节奏很简单：对话超过20来轮，或者感觉它开始“忘事”、把早就约好的规则又问一遍，先 /compact 而不是 /clear；只有整个任务真的收工了，才 /clear 翻篇。一个是换气，一个是退场，别搞反。

/context这块“上下文油表”，到底该怎么读？

很多人会话一变慢，第一反应是换个网络节点，或者归咎于“今天AI状态不好”。其实大多数时候，原因朴素得很：上下文太重了。

/context 就是用来看这件事的。它把你当前的上下文占用可视化成一张彩色的格子图，本质上是你这趟会话的“油表”——格子快填满了，回答就会变慢、质量会往下掉。这东西的价值在于，它把一个你只能“感觉”的玄学问题，变成了一个你能“看见”的具体数字。

我的用法没什么花活：感觉不对劲，先敲 /context 看一眼油表，再决定是 /compact 瘦身、/clear 翻篇，还是其实还早、继续聊。先看状态，再下决策，而不是凭手感乱救。

做独立站SEO的人对“上下文膨胀”应该不陌生，只是没往这上面想。一次完整的站点诊断，往往要把robots.txt、sitemap、几个模板文件、一堆schema标记、内链结构，连同好几轮来回讨论，全堆进同一个会话。这种场景上下文涨得飞快——你以为它在帮你通盘分析，其实它早就开始顾头不顾尾了。养成“每隔一阵看一眼 /context”的习惯，比“等明显卡了再手忙脚乱地救”省事太多。这也是为什么站内那篇用Vibe Coding做SEO工具的8步避坑指南会把上下文窗口称作“成败的命门”——你能不能把一个工具顺顺当当地造完，很大程度上取决于你有没有在上下文爆掉之前管住它。

/effort是真命令：执行题和判断题，档位凭什么一样？

先替这个命令正个名。我查证过，/effort 是Claude Code里货真价实的内置斜杠命令，敲 /effort low、/effort high、/effort max 就能改变接下来整段会话的思考强度。网上那些 ultrathink、think harder 之类的“咒语”，只是非正式的提示词替代——它们也确实有用（think 大约调4000 token思考预算，think harder／ultrathink 能拉到约31999 token），但官方那条正路，是 /effort。把它跟那些民间咒语混为一谈的文章，多半没真查过。

很多人的习惯是effort默认拉满，逻辑是“反正想得越深越不亏”。这个逻辑有漏洞。

关键在于分清你交给它的是执行题还是判断题。

改一个已经定位清楚的bug，把某段函数从回调改成async/await，给一批商品页补alt文本——这些是执行题。目标明确，照做就行。这时候高effort只会把一个本来3分钟的活拖成15分钟，质量并没有肉眼可见的提升，纯粹是让你多等、多烧token。

而判断“这套权限校验该放在网关层还是服务层”、“一个站到底用子目录还是子域名做多语言”、“canonical该指向带参数的还是干净版URL”——这些是判断题，需要分析、权衡、比较方案。这时候effort给低了，它回你的是“第一反应”，不是“认真推演”，你拿到的建议会浅得让你后悔。

我现在的规矩很简单：任务目标明确，effort收低，追求快和准；任务需要推演、权衡、对比方案，effort往上拨。落到出海SEO的活上——做技术选型（Schema用Product还是Offer、归因到底信哪个模型）、刨一个诡异排名波动的根因、设计一套内链权重的分配逻辑，这些是判断题，值得高effort慢慢想；而批量替换时区显示、补一个表单校验、把某段重复代码抽成函数，这些是执行题，低effort足够，给高了纯属浪费。

这套“按任务给算力”的思路，跟我在Opus 4.8基准刷新后该把哪些SEO活交给Agent自己跑里聊的委托清单是一脉相承的：会不会用AI，差距不在你敢不敢全交给它，而在你能不能分清哪些活该多想、哪些活该快办。

permissions：怎么一次配好“别老打断我”和“别碰那些东西”？

先说清楚，permissions 是配置不是命令——它住在settings.json里，你用 /permissions 这个命令去查看和增删它，但规则本身是写进文件、长期生效的。

权限确认是Claude Code最劝退新手的地方：看个文件确认一次，跑个命令确认一次，改段内容再确认一次。但解药不是“把所有确认全关掉”——那等于把锁砸了图省事——而是把操作分成三层：allow（放行）、ask（询问）、deny（拒绝）。

搞懂这三个词，permissions就不玄了。

allow 放低风险高频操作。跑测试、跑lint、git status、git diff——这些你每天确认十几遍，却从来不出事，直接放行：

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff *)"
    ]
  }
}

ask 留给有风险但不是不能做的操作：装依赖、跑构建脚本、改项目文件——让它做可以，但你想先扫一眼再放行。

deny 是绝对不能碰的，直接拒。做出海项目，下面这几条建议你闭着眼睛先写进去：

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(./config/*)",
      "Bash(git push *)",
      "Bash(rm -rf *)"
    ]
  }
}

这里有几个大多数教程不告诉你的工程细节，恰恰是它们最值钱的地方。

第一，deny的优先级最高（这一点Claude Code官方权限文档写得很明确）。规则是按deny → ask → allow的顺序逐条匹配的，谁先命中谁说了算。所以哪怕某个操作在别处被allow了，只要它撞上一条deny，照样被拦。这意味着你的 .env、GA4和GSC的API密钥目录、生产发布脚本，应该优先写进deny，而不是赌“到时候看弹窗再判断”——人是会手滑闭眼点“同意”的，规则不会。

第二，光写工具名和写具体范围，拦截方式不一样。一条光秃秃的 Bash 会把整个Bash工具从模型的视野里彻底拿掉，它根本看不见这个工具；而 Bash(rm -rf *) 这种带范围的，是把工具留着、只在它真去敲匹配的命令时才掐掉。前者是“这扇门焊死”，后者是“门开着，但这几步不许迈”。

第三，通配符里那个空格是有讲究的。Bash(ls *) 能匹配 ls -la，但匹配不到 lsof；而 Bash(ls*)（没空格）两个都匹配。这个细节坑过不少人——你以为只放行了 ls，结果连 lsof 一起放了出去。写规则时这一个空格，决定了你的边界是严丝合缝还是漏风。

对SEO自动化来说，这套权限配置就是你的安全带。保哥给客户站写批量脚本时，allow里放的是各种只读的审计命令（抓取状态码、校验sitemap、跑本地的内链体检脚本），deny里死死按住的是任何能读到密钥、能推到线上、能 rm -rf 的操作。这跟我在用Claude Code做GSC自定义SEO报表里反复强调的“API凭据要放在AI看不到的地方”是同一件事的两面——那篇讲的是把密钥挪出视线，这里讲的是用deny规则给视线之外再上一道锁。配一次，之后每天省下来的打断次数，是实打实能感觉到的。

sandbox：怎么让它连续干活，又只能在边界内折腾？

这一样我是用了挺久之后才真正用上的，因为它对应的问题，得你想“放手让它自己跑一整套流程”时才会冒出来。它也是配置，不是命令——开关写在settings.json里。

场景是这样的：你想让它自己跑测试、自己验证改动、自己走一遍完整的检查流程，但又不放心它在这过程里碰到不该碰的东西。sandbox 干的事，就是给它划一道操作系统层面的执行边界，让它在圈里随便跑，圈外的文件和网络它够不着。

没有沙箱，让它连续执行命令，每一步都来问你一遍，节奏被切得稀碎；开了沙箱，那些落在项目目录里的读取、执行、验证，可以一口气连着做，不用每步点头。这里有个默认就开着的关键设定：autoAllowBashIfSandboxed 默认是 true，意思是命令一旦在沙箱里跑，哪怕你的权限规则写了“每条Bash都要问”，它也不再逐条弹窗——因为沙箱这道墙，已经替代了那个“你确定吗”的确认。等于你用一道结实的物理边界，换掉了无数次烦人的点击。

这一手对做出海产品特别顺手。比如你让它帮你验证一套订阅逻辑，它得跑测试、翻日志、查数据库状态——这一连串动作要是每步都来问你，你的注意力全被打断了。开了沙箱，它能在项目范围内一路跑到底，把结果摊给你看。

有一点得提醒：沙箱再省事也不是万能的。它的边界是“项目目录”，所以那些目标是根目录或你家目录的危险操作（比如 rm -rf /），即便在沙箱里也照样会触发确认——这是给模型犯傻留的最后一道保险，别指望它会被沙箱“惯”过去。另外，有些命令本就需要访问项目外的路径（全局工具、Docker之类），这时候得额外配置才能让它们进沙箱跑，不是开了就万事大吉。

/security-review：为什么这是独立站上线前必跑的一关？

这个命令几乎没人在文章里强调，但做出海产品的人必须知道它。它是Claude Code内置的斜杠命令（用法见Anthropic官方说明），敲 /security-review，它就分析你当前这批待提交的改动，专挑安全风险点：权限控制有没有漏、外部输入有没有校验、敏感信息有没有暴露、文件处理有没有越界。官方还配了一个能挂在GitHub上的同款Action，PR一提就自动扫、自动在代码行上留评论。

为什么出海产品格外需要它？因为做北美、欧洲市场，有两类安全问题，国内开发者特别容易忽视。

第一类是 IDOR，越权访问漏洞。查数据库时写了 WHERE id = {userId}，却忘了加一句 AND owner_id = currentUser.id——结果任何一个登录用户，只要把URL里的id换个数字，就能翻到别人的订单、别人的资料。这是出海独立站最常见的安全漏洞之一，偏偏Anthropic那个官方安全审查工具的检测清单里，IDOR是被明确点名的一项。

第二类是 GDPR合规。错误日志里有没有顺手打出用户的邮箱、IP、个人信息？欧盟用户的数据合规是真实的法律义务，不是“有空再说”的可选项。而“敏感数据被记进日志”同样在那份官方检测清单里——这不是我危言耸听，是工具方自己列出来的高频风险。

我的做法是：每次做完涉及用户数据、权限、支付、文件处理的功能，跑一遍 /security-review。不是所有改动都要跑，但这几类场景，省不得。它不保证每次都能揪出问题，但它帮你多过了一道“安全视角”的筛子，免得你眼睛只盯着“功能跑没跑通”，把“有没有漏洞”整个忘了。对独立站尤其关键——功能出bug顶多用户骂两句，越权和数据泄露出事，是要吃罚单、上新闻的。

这6个，其实对应你现在就有的6个问题

绕回开头那句话。记命令不是目的，知道“什么时候用哪个、为什么用”才是。把这6样翻译成6个问题，你会发现它们早就埋在你的日常里了：

• 会话越拖越重、它开始忘事——你需要的是 /compact，不是 /clear。
• 不知道会话现在什么状态、该不该救——你需要 /context 先看油表。
• 模型档位没按任务调，执行题等到花儿谢、判断题又敷衍——你需要 /effort 分清快办还是慢想。
• 权限确认烦到想全关，又怕它碰了不该碰的——你需要把 permissions 的allow／ask／deny配明白。
• 想让它连续干活，又怕它越界——你需要 sandbox 划好边界。
• 上线前没人替你看安全这一眼——你需要 /security-review 补上这道视角。

这6个问题你现在就有，区别只在认没认出来。认出来了，对应的命令自然就用上了；认不出来，再长的命令清单也只是收藏夹里又一条吃灰的链接。

两个亲历的坑：compact吞了废案，security-review跑太晚

坑一：把 /compact 当成“清空再重开”，方向错了。

保哥刚用 /compact 时，以为它跟 /clear 差不多，只是“温和点的重置”。用下去才发现不对——它给我的那份摘要里，把一个其实已经被我否掉的方案也保了进来，结果后面好几轮，它一直顺着那个废案的思路给我出主意，越走越偏。

排查了好一阵才想明白：/compact 压缩的是“它认为重要的内容”，不一定是“你认为该留的内容”。它没读心术，你否方案时那句“算了这条不行”，在它眼里可能只是对话里普通的一句，权重还没你举的例子高。

解法有两个，配合着用最稳。其一，/compact 完别急着往下冲，花一分钟让它复述一遍摘要里留了哪些关键约定，扫一眼有没有歧义、有没有把死方案当活的，确认了再继续。其二，更主动一点，压缩的时候就带上指令，直接敲“这个方案已经废了，压缩时不要保留”，或者用前面说的 /compact 专注于xxx 把你真正在乎的那条线点出来。让它知道你要什么，比事后纠它便宜得多。

坑二：/security-review 只在上线前跑一次，发现问题太晚。

保哥最早把 /security-review 当成“上线前的最后一道检查”，跑完没事，push，收工。

有一次它真扫出来一个IDOR：用户改一改URL里的id，就能看到别人的订阅数据。问题出在一个三周前写的接口路由里。改起来其实不麻烦，几行的事。但如果当时写完就跑一遍，3分钟能搞定的事，硬是拖成了三周后回头翻代码、重新理逻辑、改完再回归测试——成本翻了不知道多少倍。漏洞这东西的修复成本，是随时间指数级往上涨的，写的当下最便宜，上线前次之，出事之后那就不是钱的事了。

解法很直白：别等上线前才跑。凡是碰了用户数据、权限、支付的功能，写完当场就跑一遍，这个阶段发现问题，成本最低。把它从“临门一脚的体检”改成“随手洗手”的习惯，这一个改动的回报，比你多记十个命令都大。

一张表：什么SEO场景该用哪个？

把上面的话收成一张可以贴在显示器边上的对照表，按你手头的活直接查：

表里最后一列我特意留着——分清命令和配置，不是学究气，是它决定了你把这套东西安在哪：命令是随手敲、当下用；配置是写进文件、进版本库、整个团队共享。把这层想明白，你才算真把Claude Code当工具使，而不是当一堆需要背的咒语。

常见问题解答

/compact 和 /clear 到底什么时候用哪个？

判断标准是“主线任务还要不要”。任务没结束、只是上下文重了或它开始忘事，用 /compact 瘦身，把过时的试错压掉、关键约定留下；任务彻底翻篇、要换个完全无关的活，才用 /clear。官方经验是上下文用量超过80% 左右先 /compact。一句话：换气用compact，退场用clear。

/effort 真的是命令吗？跟ultrathink那些有什么区别？

是真命令。/effort low|high|max 是官方提供的、用来控制接下来整段会话思考强度的正式方式。ultrathink、think harder 这类是非正式的提示词触发，也能调高思考预算，但属于民间打法。两者都只在Claude Code这个命令行工具里生效，你在网页版输入框敲 ultrathink 是没反应的。要稳定控制档位，用 /effort。

permissions和sandbox都是管安全的，配了一个还要另一个吗？

建议两个都上，它们是互补的两层。permissions控制的是Claude能用哪些工具、能碰哪些文件和域名，作用于所有工具；sandbox是操作系统层面的强制隔离，只管Bash命令及其子进程的文件和网络访问。permissions的deny让它“连试都不去试”，sandbox则保证“哪怕提示词被注入绕过了模型的判断，命令也出不了边界”。一个防意图，一个防越界，叠起来才是纵深防御。

把 .env写进deny，密钥就绝对安全了吗？

能挡住Claude Code自己的文件工具（包括它在Bash里用 cat、head 这类读文件的命令），但挡不住“间接读取”——比如它跑一个自己打开文件的Python或Node脚本，deny规则就管不到了。要做操作系统层面、把所有进程都拦住的强隔离，得开sandbox。所以稳妥的做法是deny加sandbox一起上，再叠上“密钥根本不进项目目录”的工程习惯。

SEO从业者不太懂代码，这套东西用得上吗？

用得上，而且越不懂代码越该用对档位和边界。你不需要会写复杂程序，但你会让它帮你跑批量改meta、生成GSC报表脚本、校验sitemap——这些活同样会碰到上下文膨胀、权限打断、密钥泄露的问题。把 /compact、/context、permissions 这几样用顺，等于给自己请了个不会手滑、不会越界的助手，这比你硬啃语法划算得多。

权威参考资料