企业官网建设流程全解析

我先说一个真实的场景。前几天有个同事跟我吐槽，说 Claude Code 越用越“笨”，同一个需求前面还能一次改对，到后面就开始反复横跳，甚至漏掉关键文件。我过去瞄了一眼他的终端，问他：“你用过/compact吗？”他愣了一下：“这是什么？我用 Claude Code 从来只打字。”这一下把我点醒了：很多人嘴上在用 Claude Code，实际上还停留在把它当成“长得像命令行的聊天框”的阶段。

Claude Code 真正值钱的地方，其实是从输入框里敲/之后展开的那一整套命令体系。这套斜杠命令相当于给 AI 预设了动作：压缩上下文、初始化项目规则、代码审查、切换模型、导出对话……每一条都在解决一个你靠“自由对话”很难稳定完成的问题。这篇文章我就按使用场景，把 12 个最容易被忽略、但实际帮我省了大量时间、金钱和头发的命令拆开讲透。适合刚上手想少走弯路的新手，也适合已经用了一段时间但还停留在“打字对话”阶段的老手。

1. 为什么我劝你别再把 Claude Code 当聊天框用

1.1 聊天框式用法的三个隐形代价

我见过太多人把 Claude Code 当 ChatGPT 的终端版在用：敲一句需求，等它输出一段代码，再敲一句，再等。这种用法不是不行，但它会让整个工具的效率上限被锁死，而且会悄悄付出三个代价。

第一个代价是上下文膨胀。Claude Code 的每次对话都要把当前会话的历史记录一并发给模型。你前面讨论过的技术选型、它写过的代码、你纠正过的问题，全都会累积在上下文里。聊到三四十轮之后，模型开始“忘事儿”其实是正常现象——它没有忘，是它的工作记忆里塞了太多杂物，导致注意力被稀释，输出质量自然崩。第二个代价是token 开销水涨船高。历史越长，单轮请求的 token 成本就越高。你以为自己在正常聊天，其实每一轮都在为前面的废话重复买单。第三个代价是行为不可控：自由对话没有固定格式，同一个需求换个问法，输出风格和质量天差地别。而斜杠命令是确定性动作，执行逻辑固定，输出结构也固定，这是自由对话给不了的东西。

1.2 斜杠命令是 Claude Code 的“快捷键层”

你会用图形界面软件，一定知道“快捷键”的存在。菜单栏里的功能全部能用快捷键触发，但没人会一个个去背。Claude Code 也一样，对话只是它的最小交互单位，斜杠命令才是为高频动作准备的快捷键层。

在 Claude Code 输入框里敲一个/，它会把当前版本支持的所有命令列出来。你可以把每个命令理解为一段预设好的“工作流”：你不需要描述“请把我们的对话总结一下然后重新开始”，你只需要敲/compact；你不需要说“请以代码审查者的身份审阅一下当前工作区的改动”，你只需要敲/review。命令把意图固定下来，模型的发挥空间被框在一个合理的范围内，质量和可预期性都大幅提升。

1.3 先收下这张速查表

下面这张表是我日常使用频率最高的 12 条命令。先记住“什么场景找什么命令”，后文再逐个展开原理和细节。

你不需要一次性记全。但接下来的每一节，我都建议你对照着用到自己日常里，才能真正形成肌肉记忆。

2. 上下文管理：token 花得值不值，就看这几条命令

2.1 /compact：上下文快爆炸时的“压缩饼干”

/compact可能是这 12 条命令里价值最高的一条，也是最容易被忽略的一条，因为它的作用原理反直觉：你以为对话越长 AI 越聪明，实际上恰恰相反，对话越长 AI 越容易被垃圾历史拖垮。

执行/compact的时候，Claude Code 会读取当前整段会话，提炼出一份摘要，然后清空原有历史，用这份摘要作为新的对话起点。它相当于把一本写满涂鸦的草稿本换成一页干净的重点笔记。你不需要担心之前写进代码文件里的修改会丢，磁盘上的改动是落盘的，不依赖会话记忆。丢掉的只是对话中原有的“过程性信息”，比如你说过的模糊描述、它给过但又被推翻的中间方案。

什么时候该主动压？我的判断标准很简单：当你发现 Claude Code 开始不记得你自己说过的话，或者一个改了好几次的问题又开始往老路子上走，二话不说先/compact。还有更前置的判断法：打开/status看上下文占用，超过 70% 就主动压一次，不要等它彻底卡死。另外有一个容易被忽略的配置项叫autoCompactEnabled，可以在设置文件里打开：

{ "autoCompactEnabled": true }

打开了自动压缩之后，Claude Code 会在接近上下文上限时尝试自己做压缩。但你千万别把自动压缩当成免死金牌，它的触发时机偏保守，等它动手时，前面已经浪费了好几轮高成本的请求了。我的习惯是：长会话里把主动/compact当作常规操作，每完成一个子任务就评估一次是否该压。

2.2 /init：让 AI 长期记住项目规则

如果说/compact管的是“短期记忆”，那/init管的就是“长期记忆”。在全新的项目目录里执行/init，Claude Code 会扫描项目结构、分析技术栈和代码组织方式，然后在项目根目录生成一份CLAUDE.md。这份文件就是它的“项目入职手册”，之后每次会话启动和对话过程中，它都会参考这份说明来回答问题。

很多人的误区是“跑过一次就完事”。实际做法应该是：只要项目结构有大变化、技术栈有调整、团队规范有更新，就再跑一次/init让它刷新记忆。你甚至可以直接手动维护这份文件，把它当成给 AI 写的大纲。下面是一个精简示例：

# 项目说明 - 技术栈：TypeScript + React + Vite - 包管理：pnpm - 组件开发规范：函数组件 + Hooks，禁止类组件 - 样式方案：Tailwind CSS，不要引入 CSS Modules - 接口请求：统一走 src/api/client.ts，禁止散落 fetch - 输出要求：新增业务组件必须包含 loading 和 error 状态

写规则时我踩过一个很实在的坑：前后条款自相矛盾。我有一次在前面写了“优先函数组件”，后面又写了“新页面必须用类组件”，结果 AI 行为变得随机飘忽，同一个需求这次给函数式方案，下次给类式方案。CLAUDE.md 的条款必须互斥且明确，否则它就会给模型埋下混乱的种子。新版 Claude Code 的/init还会生成.claude/skills之类的目录结构，这是它向“项目级 Agent 配置”演进的方向。团队项目里把这套文件纳入版本管理，每个人打开项目都能自动继承同一套 AI 行为规则，这比口头约定靠谱得多。

2.3 /add-dir：精确指定 AI 的“阅读范围”

很多仓库动辄几十上百个目录，里面还有 node_modules、dist、build 这种一眼就不可能被关心的文件夹。如果你在对话里直接说“看一下 src/modules/order 目录”，模型可能要自己猜该读哪些文件，猜错就白折腾。/add-dir的价值在于，它把指定目录显式注册进上下文，告诉模型“这就是你这次工作的工作区，相关文件从这里找”。

这个命令对“省 token”的意义是实打实的。它不用把整个项目塞进上下文，只把目标目录的入口和结构信息挂载进来，后续按需读取具体文件。大型项目里效果尤其明显：同样做一次订单模块的改动，全量投喂可能几十分钟上下文就满了，用/add-dir只挂src/modules/order，能干到任务结束上下文还有富余。

实际操作里我会配合/init一起用：/init保证它懂项目全局规则，/add-dir保证它聚焦在局部模块。它俩一个是“宏观视野”，一个是“局部聚焦”，组合起来正是省 token 又不丢精度的最佳姿势。

2.4 /clear：该换脑子时就换脑子

/clear看起来太基础了，基础到所有人都知道，但恰恰因为它太简单，很多人反而不把它当“高效命令”看。我观察到的情况是：很多同事一个会话从早上聊到晚上，需求一个接一个地塞进去，AI 上一个任务的状态还没完全退出来就开始处理下一个任务，两边互相污染。

我的原则是“一个会话只干一件事”。上一个任务已经收尾，下一个任务哪怕只是换个页面改样式，也要先/clear。这个命令的作用是清空上下文，给模型一个干净的工作记忆，效果等同于让它“先忘掉上一件事”。别小看这一步，很多你以为的“AI 变笨了”，其实都是两个任务叠加导致的串味。

那/clear和/compact的区别到底是什么？我做了个小决策表，直接照抄就行：

有一个细节要特别注意：/clear之前，如果会话里有一些重要的中间结论，比如某个排查过程的关键根因、某个临时决定的方案取舍，先让它把这些结论写进文件或直接用章节里要讲的/export存下来。清空操作不可逆，别指望回头还能捞出历史记忆。

3. 代码工作流提效：从“问一句答一句”到“批量干活”

3.1 /review：让 Claude 自己审自己的活

我身边大部分人的“代码审查”姿势是这样的：手动把文件复制进对话里，然后写一句“帮我看看有没有问题”。且不说文件一长发出去就超长，单说这种没有边界的提问，模型根本不知道你要它审什么——是审逻辑？审风格？还是审性能？所以输出往往泛泛而谈，没有太多实际参考价值。

/review把这件事流程化了。它默认基于当前工作区的 git 改动来定位审查范围，执行后输出结构化的审查结论，通常包含问题列表、风险等级和修改建议。不用你贴文件，不用你描述范围，只要改动在工作区里，它自己就能找到。

新版本 CLI 里这个命令叫/review，老版本可能还叫/code-review。如果你的 claude 命令版本比较旧，敲/review没反应，先跑一下/update再试试。实操里我习惯把它和git diff串在一起，这是我提 PR 前的固定动作：

> git diff > /review

先让改动进入模型视线，再触发审查流程，这样它既能结合 diff 又有一套固定审查逻辑，比单纯丢文件可靠得多。另外注意一点：审查前最好只保留和本次改动相关的文件，别把一堆临时输出文件、配置备份文件也放在工作区里，否则它会花大量 token 在无关改动上，重点问题反而被稀释。

3.2 /model：按任务难度灵活调度模型

Claude Code 底层可以调用不同规格的模型，指令就是/model。默认配置通常用均衡型模型，适合绝大多数开发场景。但你如果所有任务都跑默认模型，等于把“重火力”和“轻任务”全部混在一起：写一个 5 行的工具函数和设计一个跨模块的架构方案，消耗的成本和资源却是一样的。

我现在的调度策略大致是这样的：

• 架构设计、跨模块重构、疑难调试：切换到最强模型 Opus。这类任务需要强推理能力，多花点成本是值得的，因为它能省下后续反复返工的时间。
• 日常编码、按需求实现功能、修改现有逻辑：跑默认均衡模型 Sonnet。覆盖绝大多数场景，能力够用，成本和速度都适中。
• 批量改名、格式转换、补注释、写测试骨架：直接降级到 Haiku。这些任务模式明确、难度低，快是最重要的，没必要让大模型来干。

一个常见的疑问是：切换模型会不会丢上下文？实测下来不会。会话历史会被保留，你可以中途任意切换，模型只是换了，对话仍然连贯。于是就有了一个很省钱的组合打法：开场先用最强模型把设计思路理清楚，然后切成均衡模型让它写实现，到了明显机械化的收尾阶段再降级到轻量模型批量处理。同样一个需求，token 费用可以差出好几倍。

3.3 /vim：给键位肌肉记忆留一条活路

如果你是 Vim 用户，这条命令属于“用过就回不去”的类型。Claude Code 默认的输入框是普通编辑模式，但敲一下/vim之后，整个输入框就切换成 Vim 键位：i进入插入模式，Esc回到普通模式，dd删一行，u撤销，/搜索历史。凡是你脑子里存的 Vim 肌肉记忆，全都能用上。

很多人会忽略这条命令，原因是它默认不开，而且大多数人压根没想到会有人需要在终端输入框里用 Vim 键位。但对 Vim 党来说，编辑一段长 prompt 的效率提升是非常明显的。你要是纯粹 VS Code 流用户，这条可以跳过，但这不妨碍它成为不少人的“隐藏快捷键”。

3.4 /status：在出问题之前先看一眼仪表盘

/status是我每天敲得最多的诊断命令。它展示的是当前会话的健康度：上下文占用比例、任务执行状态、相关耗时信息。你可以在会话一开始就敲一次，建立基线；也可以在任务过程中随时敲，判断要不要主动/compact。

我有一次印象特别深：Claude Code 突然不按指令走了，让它改 A 文件它偏去翻 B 文件，指令好像完全失效。我第一反应不是骂模型“傻了”，而是/status看了一眼，上下文占用已经逼近极限。这就是问题根因——它脑子塞得太满，接收新指令的余量已经所剩无几。接着一个/compact，问题立刻恢复。这种“行为异常其实是上下文过载”的规律，不跑/status很难第一时间定位。养成习惯：每完成一个任务块，敲一下/status，心里对会话余量始终有数，比等到崩了再排查省事得多。

4. 环境诊断与团队协作：出问题别急着重装

4.1 /doctor：先体检再排查

很多人一遇到 Claude Code 行为诡异，第一反应是“重装”或者“清缓存”。其实多数环境问题都可以用/doctor在几秒内定位。这个命令会对当前环境做一轮自检，覆盖版本信息、登录状态、配置完整性、API 连通性等关键项。执行完会输出一份检查结果，告诉你哪一块有问题。

我自己的经历是：有一段时间调用总是静默失败，提示权限相关的问题，但又没有明确报错来自哪一层。我当时以为是代码逻辑问题，翻了一下午没结果。最后跑了一次/doctor才显示当前登录身份异常，重新登录后立刻恢复。这种问题，不跑/doctor根本不可能靠“猜”定位出来。从那以后我给自己立了个规矩：凡是出现诡异现象，先跑/doctor再做任何代码改动。这不是能力问题，是排错顺序问题。

4.2 /config：用面板而不是手改文件

配置 Claude Code 常见的方式是去改settings.json，但如果你不熟悉它的配置结构，手改文件容易把 JSON 写错，而且改完还要重启才会生效。更友好的做法是直接在会话里执行/config，它会打开一个配置面板，权限模式、模型偏好、自动压缩、交互细节这些参数都可以可视化调整。

配置本身是分层的，理解这个分层能帮你少踩很多坑：

• 用户级配置：~/.claude/settings.json，对你机器上的所有项目生效。
• 项目级配置：.claude/settings.json，只对当前项目生效，适合团队统一行为规范。

项目级配置会覆盖用户级配置。这也是一个常见坑：你在个人全局配置里改了某个权限策略，但项目里如果存在一份项目级配置，很可能把你全局的配置顶掉。所以遇到“怎么改都不生效”的情况，先检查项目目录下有没有一份团队级的settings.json。

4.3 /resume：换机器、断终端都能无缝接上

用 Claude Code 干活，最怕的就是干到一半终端断了，尤其是我这种经常远程连服务器的人。好在它的会话记录是持久化的，不需要你手动保存什么。命令行直接恢复：

claude --continue

这是恢复最近一次会话。如果你想选择性恢复历史会话：

claude --resume

它会列出历史会话列表，挑一个进去接着聊。更顺手的是，--continue后面可以直接跟新指令：

claude --continue "接着改刚才的接口，这次把参数校验补上"

我前阵子远程跑代码，就在终端里跟 Claude Code 聊到关键步骤，结果网络一断整个人懵了。重连之后抱着试试的心态敲了claude --continue，它真的把上次的上下文接了回来，连之前讨论到一半的方案都能继续。这个命令救过我好几次。不过有一点要注意：resume恢复的是会话记忆，不保证代码分支和工作区状态也跟着恢复。如果你恢复会话之前还没提交代码，先确认当前分支对不对，别在错误版本上继续往下写。

4.4 /export：把会话变成团队知识资产

Claude Code 的会话记录如果不主动保留，关掉终端就等于没了。但很多时候，你花了两三个小时排查一个棘手问题，这个排查链路本身有极高的分享价值。/export干的就是这件事：把当前会话整理成 Markdown 导出。

执行/export之后，Claude Code 会将会话内容按结构导出为可读的 Markdown 文件，你可以选择保存路径。这个导出文件里包含你每一步的指令、它每一步的输出，相当于一份完整的排障回放。我通常的用法是：

• 周末复盘时导出整周的关键会话，提炼成自己的问题案例库；
• 排查完一个难搞的问题后导出，贴到内部知识库，配合简单的二次总结，供团队其他人直接参考；
• 需要给同事同步一个复杂上下文时，不靠口述，直接丢一份导出文件过去。

导出后的文件信息密度很高，如果只是给同事参考，建议在导出基础上再写两三句总结，而不是原样扔过去。它最合适的定位是“素材底稿”，不是“成品文档”。

5. 把命令串起来：我日常最顺手的几个组合用法

5.1 新任务的标准开局

我接手一个新项目或一个新需求时，第一组命令永远是：

> /init > /clear # 然后开始描述任务

/init先确保项目规则文件存在且最新，让 AI 拿到“入职手册”；紧接着/clear把生成和扫描规则过程产生的冗余对话清掉，确保正式任务的上下文从干净状态开始。顺序不能反，先init再clear，如果先清空再 init，扫描过程又会产生新的杂质。已经有 CLAUDE.md 的存量项目，直接检查文件是否过期，过期就重新跑一次/init。

5.2 合代码前的“三道闸”

每次准备提交代码或提 PR 之前，我基本固定走一遍这个流程：

> /status > git diff > /review > /export

/status检查上下文余量，如果快满了先压一次；git diff把改动喂给模型；/review触发结构化审查；审查结论满意之后，/export把审查记录存成文件，修改建议逐条对照修改。这四步走下来，改完直接提 PR，心里踏实很多。审查记录留着也是好东西，后续如果要跟人解释“为什么这里这样改”，直接翻导出文件就行。

5.3 长会话的“保命三部曲”

遇到一个大需求必须在一个会话里连续干好几个小时的时候，我的节奏是这么控制的：

• 主动/compact，不要等自动压缩兜底，每完成一个模块就判断一次上下文是否该压；
• 用/resume拆会话，大任务按里程碑拆成多段，每完成一段就/export存档然后/clear，下一次用claude --continue接着推进；
• 全程靠/status巡检，每次准备切换子任务前先看一眼健康度。

这样做的收益很直观：每次会话的上下文范围可控，模型不会因为塞了太多历史而“精神涣散”，成本也被压在一个可预期的范围里。你以为多开几个会话会麻烦，实际上反而比“一个会话硬撑到底”更稳、更省钱。

5.4 关于这 12 条命令，最后几句大实话

不要试图一次全背下来。命令这东西，背下来没用，用熟了才是你的。我最建议你先从三条开始：/compact、/init、/status。这三条解决的是“上下文失控”这个最普遍也最致命的问题，几乎每个深度用户都会遇到。等你把这三条练成肌肉记忆，再慢慢把/model、/review、/resume加进日常流程。

我自己用下来的体会是：Claude Code 的真正分水岭，不是你用的模型多强、配置多花哨，而是你有没有建立一套稳定的“命令使用节奏”。聊天框式的用法上限很低，斜杠命令才是把这个工具从“能聊”推向“能用、好用、省着用”的关键一层。希望这篇整理能让你少走一些我走过的弯路。