企业官网建设流程全解析

我用 Claude Code 写了大半年项目，最想吐槽的一点是：网上所谓的命令大全，大多是把帮助文档里的英文说明翻译一遍，翻完你依然不知道什么场景该敲哪条，更别提那些“全网最全”的说法，往往只是把几十个命令往那儿一堆，看着热闹，实际用起来一头雾水。这篇我换个讲法：先用一套逻辑帮你看懂命令设计的底层思路，再把我自己整理过的 93 个命令入口分成四张表全列出来，最后用几个我每天都在用的组合演示一遍。新手可以从第 2 节开始直接抄作业，老手可以直接跳到第 3 节看组合用法，保证每一段都对得起“实操”两个字。

1. 命令设计逻辑：搞懂这套思路，93 个命令至少能少背一半

1.1 斜杠命令的本质：给对话预设“工作模式”

很多第一次用 Claude Code 的人会觉得，斜杠命令就是快捷键，省得打几个字而已。但实际不是这样。斜杠命令更像是给这个对话预设了一个工作模式：你敲下/review，它知道接下来要把代码审查的标准提上来；你敲下/init，它知道要开始分析项目结构并生成规范文件；你敲下/compact，它知道你嫌弃上下文太长了，要执行一次压缩。

我习惯把它类比成你跟一个资深工程师之间的沟通方式。你要是直接说“帮我看看代码”，他可能先问你十个问题；但你要是递过去一张写好的检查清单，他直接照着清单逐项过就行。斜杠命令就是那张清单，它绕开了“猜测你意图”这一步，让模型把精力花在执行上，而不是理解上。

另一个容易被忽略的点是，斜杠命令的定义本身就是 Markdown 文件，你可以自己往里边塞说明、示例、检查步骤。这等于你能定制一个新的“工作模式”给 Claude Claude Code 用。第 4 节我会专门讲这块怎么写，这里先记住一个核心结论：命令不是“少打字”的偷懒工具，而是“明确意图”的控制手段。

1.2 符号前缀：@、!、#背后的杠杆效应

斜杠命令之外，Claude Code 的输入框里还支持几类符号前缀，很多人用了很久也不知道它们能干嘛。

@符号用来引用文件或目录。我实测下来，这是上下文管理最重要的入口。你在对话里写“看看@src/utils/format.ts的导出逻辑”，它会把那个文件的内容读进上下文并围绕它回答。如果你引用的是一个目录，它一般会先看目录结构再按需读取内部文件。这里有个细节：直接用@引用单个大文件没问题，但一次引用整个目录，尤其是上百个文件的目录，可能会把大量无关内容塞进上下文，反而干扰判断。

!符号用来执行终端命令，比如!git status、!npm test。它会真实地在当前工作区跑一次命令，再把输出回传给你。这招在排查问题时极好用，尤其是“看看服务现在挂没挂”“跑一下这个测试什么结果”这类需求，不需要切出对话窗口，就能拿到环境里的真实反馈。

#的用法在不同项目里略有差异。官方层面，#常被用来引用会话里的某条消息，或者配合协作脚本做任务标记；我自己的项目里也会把它当成 todo 标签用，例如让 Claude 把待办事项都标注成#TODO开头，方便我统一搜索。符号前缀之所以威力大，是因为它们把“文件系统”和“终端命令”直接拉进了对话，你不再需要把内容复制粘贴给模型，而是把入口交给它。

1.3 快捷键：让双手留在键盘上

终端环境本身有一批通用快捷键，它们不是 Claude Code 独有，却是日常使用中绕不开的。我列出了个人使用频率最高的几个组合，说一个最容易踩的坑：很多人发现对话卡住了就连续按Ctrl+C，结果把整个进程都干掉了，而不是中断当前输出。正确姿势是先按一次Esc或Ctrl+C看是否是中断当前生成，如果发现退出了交互界面，再考虑是不是按键按过头了。

另外，↑方向键翻历史这个习惯一定要养成。Claude Code 的会话上下文很长，有时候你前面那句指令写得非常好，直接翻上去微调比重新打一遍更高效。Ctrl+L清屏也很实用，输出太长的时候清一下，可以让注意力回到当前的提示符上。

2. 命令全景拆解：四张大表凑齐 93 个命令入口

我按自己的使用习惯，把 93 个命令入口分成了四类：官方斜杠命令 25 个、符号前缀与快捷键 18 个、内置工具调用 12 个、推荐自定义命令 38 个。这个分类不是官方文档结构，是纯粹的实战角度，方便你在不同场景下快速检索。

2.1 官方斜杠命令：25 个

这 25 个是所有命令的地基。我的建议是优先吃透/add、/drop、/context、/compact这四个，因为它们直接决定了你“喂给模型什么信息”。信息喂对了，后面哪怕只用对话自然语言，输出质量都能上一个台阶。

2.2 符号前缀与快捷键：18 个

这里特别说明一下，@和!是 Claude Code 交互层面的符号，其余的都是终端通用快捷键。很多人会把“快捷键”这部分也算进命令数量里，我觉得合理——毕竟指望命令行工具提效，双手离不开键盘。

2.3 内置工具调用：12 个

这 12 个工具并不是让你像敲命令一样手动触发，而是说明 Claude Code 在对话过程中“可以调用的能力边界”。我为什么把它们列进命令表？因为当你用自然语言提问时，它极可能就是在背后调用这些工具。理解了这一点，你发出的指令就会更精准：你想让它在几十个文件里找某段逻辑，直接说“用 Grep 搜一下关键字”，而不是含糊地说“帮我找找那个东西”。

2.4 推荐自定义命令：38 个

这 38 个命令并非开箱即用，需要你自己在.claude/commands/目录下创建对应的 Markdown 文件，它们才会出现在斜杠命令列表里。我给了推荐命名和用途，你可以直接照着建。第 4 节我会演示一个完整的自定义命令写法，这里先有个概念：自定义命令就是把“你经常重复说的一大段话”压缩成一个斜杠指令，属于收益最高、门槛最低的效率提升手段。

3. 高频命令实测：能立刻提效的五个组合

3.1 组合一：/init + CLAUDE.md，把项目基因写进去

新接手一个项目，我做的第一件事永远是/init。它会在项目根目录生成或更新一份CLAUDE.md，里面记录着项目结构、技术栈、构建命令、代码规范。很多人把它当成一份给 Claude 看的说明书，这理解不够。我更愿意把它理解为“项目基因”——每次新开会话，Claude Code 都会自动读取这份文件，相当于让每个新会话都带着同一个记忆底座。

我实际测试过两个对照场景。同一个项目，在没有CLAUDE.md的情况下，让 Claude 写一个新的 API 接口，它会给出一版中规中矩的代码，但目录结构、命名风格跟现有代码总有出入。等我用/init生成了规范文件，又手动补充了“本项目使用函数式组件，禁止类组件”“状态管理统一走某个库”这两条后，第二次让它在同一项目里写同样的接口，生成的代码几乎可以直接合入。差异就是这么明显，所以我每次进入项目的第一条命令永远是/init。

这里有个注意事项：/init生成的文件不要迷信，它只能基于目录结构和已有代码推断，不一定能覆盖你团队真正约定俗成的规则。正确做法是生成之后手动改一遍，把最能代表这个项目风格的 10 到 20 条规则写进去，越多越杂反而让模型抓不住重点。

3.2 组合二：@路径 + /add，精准投喂上下文

Claude Code 的上下文窗口是有限的，这决定了你不能把半个项目都塞给它。我最常用的操作顺序是：先@src引目录让它看结构，定位到相关文件后，马上用/add把具体文件加进上下文，再用/drop把无关内容踢出去。

这套组合的核心是“够用即可”。比如我要改一个支付回调接口，通常上下文里只需要：路由文件、对应的控制器、相关的模型定义、以及接口文档片段。至于不相关的工具函数、配置文件，别加。我踩过的坑是：为了图省事，把整个src目录通过@丢进去，结果 Claude 输出的代码看着结构挺完整，但把几个无关模块的旧函数误当成依赖，生成了根本不该存在的引用。那不是模型蠢，是我喂错了信息。

所以我现在对项目里的新人只有一个要求：让 Claude 帮你之前，先自己回答三个问题——它需要读哪个文件？要跑哪些命令？要遵循什么约束？把这三点想清楚，再动手@、/add、!，效果会比笼统一句“帮我看下这个功能”好十倍。

3.3 组合三：/compact，压缩上下文的正确时机

/compact是我用得最勤的命令之一，但这并不代表我应该无脑用它。它的作用是压缩会话历史，把已经聊过的内容做一次提炼，留下关键结论，释放上下文空间。但我实测发现，压缩是有信息损耗的——对话里的某些细节、某个字段名、某个具体的报错堆栈，压缩后可能只剩下模糊的概括，后续执行就容易变形。

我的经验是：不要等项目聊到上下文快爆了才想起/compact。更好的时机是你意识到“接下来要换一个明显不同的任务”的时候。比如前半小时一直在讨论需求，现在要动手写代码了，此时上下文里塞满了需求讨论的来回对话，直接压缩一次，把需求结论保留住，进入实现阶段。压缩完之后，我通常会接着追问一句“刚才讨论得到的结论是什么”，确认它没有把关键信息丢掉。如果发现有遗漏，马上手动补一条到/memory或 CLAUDE.md 里。

另一个实用技巧是：在/compact之前，把必须留存的要点用一句话写进当前对话里，比如“记住，生产环境的数据库地址配置要放在环境变量里”，这样压缩工具在提炼时就会优先保留这类显式说明，而不是靠它自己去猜哪些信息重要。

3.4 组合四：!命令与 Shell 直接互通

!前缀会让我在对话里直接指挥终端做事，这个能力用好了，效率提升非常明显。比如我怀疑某个测试挂了，直接在对话里输入!npm test -- --listTests，它会返回当前测试文件清单，比我手动切终端跑命令快得多。再比如查 Git 历史，!git log --oneline -10一步到位，让 Claude 基于真实提交记录分析问题，而不是靠它凭感觉猜。

但这里有一个我必须强调的安全问题：!命令是真实执行在系统里的，它不是模拟也不是演示。刚开始使用者最容易犯的错就是对它太信任，比如让 Claude 执行一个看似无害的清理命令，结果它真的把临时目录里的文件删了。所以我的原则是：凡是涉及删除、覆盖、移动文件的命令，先让它输出命令内容，我看一眼确认没问题之后再手动执行，而不是直接让模型代劳。

3.5 组合五：/model，按任务难度切换模型

很多人不知道 Claude Code 支持在对话中切换模型，/model一敲，就能在不同的模型之间切换。我自己的策略是“大模型想方案，小模型跑执行”。需求分析、架构设计、审视复杂代码逻辑这类高难度的活儿，用最强模型；写格式化的代码、生成文档、补注释、整理测试数据这类重复性任务，换到轻量模型就够用。

这么做的直接好处是省时间和省额度。我曾经在一个大量生成数据脚本的任务里全程开着强模型，结果同一个任务换成轻量模型后，速度和成本都有明显改善，输出质量对比下来几乎没差别。你要是不确定该用哪个模型，可以先从中等模型开始跑，感觉它理解需求吃力、频繁出错，再切到强模型；如果一切顺利，就别往上升级。

4. 自定义命令实战：把重复劳动固化成 /xxx

4.1 自定义命令的基本写法

自定义命令的机制其实非常简单：每个命令对应一个 Markdown 文件，文件名就是命令名，文件内容就是你想让 Claude 执行的那套指令。全局命令放在~/.claude/commands/目录，项目级命令放在项目根目录的.claude/commands/目录。我个人遵循的原则是：通用型命令放全局，比如/commit、/summary；和具体项目绑定强的命令放项目级，比如某套特殊格式的接口生成命令。

文件内容支持用双大括号做参数占位，比如你想让命令接受一个输入参数，在 markdown 里写{{参数名}}，实际使用斜杠命令时，它就会提示你输入对应内容。这让自定义命令不只是固定口号，还能变成可复用的工具。

4.2 一个可用的 /review 命令示例

我拿团队里用得很顺的一个代码审查命令举例。它的定位不是“让 Claude 全量重写代码”，而是“按团队的检查清单逐项过一遍”。

在.claude/commands/review.md里，我写了这样几段内容：

你是本项目的代码审查助手。请对 {{目标范围}} 的改动执行以下检查： 1. 是否遵循项目 CLAUDE.md 中约定的目录结构与命名规范 2. 是否存在明显逻辑错误、空指针风险或未处理的异常边界 3. 是否有不必要的大文件改动、死代码或重复实现 4. 是否缺少必要的测试覆盖 输出格式： - 每个问题按「严重 / 一般 / 建议」分级 - 每行说明具体文件与行号范围 - 最后给出优先级排序的修复建议，不要直接改代码

实际使用的时候，我输入/review src/utils/payment.ts，它就会带上这个文件路径，按上面这套标准逐项审查。以前我要手敲一大段审查要求，现在一个斜杠命令就搞定了，而且每次的审查标准保持一致——这一点对团队协作特别重要，规则统一才能减少口头传达的偏差。

4.3 团队规范与 CLAUDE.md 的配合

自定义命令做到一定规模之后，容易出现和项目规范脱节的问题。我的解决办法是把项目级规则全部沉淀在CLAUDE.md里，然后自定义命令里统一留一句“请先阅读 CLAUDE.md 中的项目规范”。这样即使命令模板更新不及时，只要规范文件是最新的，Claude 的行为也会跟着最新规则走。

举个例子，某次我们团队调整了接口返回格式，从下划线命名改成小驼峰。我没有去改每个命令文件里的描述，只是在CLAUDE.md里补了一行“所有接口返回字段必须使用小驼峰命名”。之后凡是走了任意自定义命令的代码生成，都会遵守这条新规则。这就是“规则文件 + 命令模板”的搭配价值：命令负责流程，规范负责内容，互不干扰又互相支撑。

5. 常见问题与避坑实录

5.1 命令没反应？先查这四个地方

我自己遇到命令不生效的情况，绝大多数不是产品出 bug，而是小细节没到位。

第一是检查斜杠前缀是否输入正确。有时候中文输入法会混进一个全角字符，斜杠看起来像/，实际不是，命令自然没反应。第二是自定义命令没出现在列表里，先看文件扩展名是不是.md，以及是否放在正确的目录。我之前把命令文件起名带空格，结果怎么都不出现，去掉空格就好了。第三是新写的自定义命令往往需要重开会话或者重新加载才会被识别，某些情况下要执行/help刷新一下。第四是如果你改动过权限配置，注意是不是被权限拦截了——命令本身没问题，但被当前权限策略挡掉了。

顺序排查法比较稳：先确认输入有没有隐形字符，再确认文件路径和扩展名，再确认是否要重启会话，最后看一眼权限日志。

5.2 上下文越用越笨，多半是没管上下文

很多人的使用体验曲线是“一开始挺聪明，聊到后面越来越笨，甚至前后矛盾”。这几乎都是上下文管理不到位导致的。对话越长，原始信息被淹没在历史里的概率就越大，模型会越来越依赖最近几轮的内容，忘了你最早提到的约束。

我的处理流程是这样：感觉回答质量下滑，先/context看当前占用率。如果占用率很高，立刻执行/compact，并在压缩后追问一句确认关键结论是否保留。如果压缩后还是不行，就考虑开新会话，把核心需求、约束、相关文件重新/add进去。但不要一卡顿就/clear，有些上下文是有价值的，粗暴清空会丢掉重要信息。保存关键决策靠/memory或写进CLAUDE.md，这才是长期有效的办法。

5.3 权限弹窗过敏：怎么调出一个顺手的权限策略

Claude Code 能调用的工具越多，权限弹窗出现的频率就越高。有时候你只是想让它读几个文件，结果弹窗连续出现好几次，体验极其割裂。反过来，你要是把所有权限全部放开，又担心它执行了危险命令。

我最后调出来的策略是：阅读类工具（Read、Grep、LS、Glob）大量放行，写入类工具保持确认，危险类操作（删除、移动、执行脚本）每次询问。这个策略既保证了效率，又守住了底线。具体在/permissions里设置默认模式为询问模式，再把高频的只读命令加进白名单。调完以后，日常开发顺畅度会明显提升，而且你心里有数，真正需要人确认的动作它不会越过你。

5.4 加错文件导致幻觉，怎么避免

前面提到过，把不相关文件加进上下文会干扰模型判断，具体表现形式就是它“自信地”生成一些基于错误根据的代码，看起来合理，实际是幻觉。要避免这个问题，最笨也最有效的方法是：每次让 Claude 动手改代码之前，先让它列出它认为相关的文件和改动范围，你确认无误后再让它改。

我在实践中还养成了一个习惯：遇到生成结果奇怪的情况，第一反应不是质疑模型能力，而是先执行/context看看上下文里到底有哪些文件。十次里有七八次能发现，某个改动请求时不小心把旧的备份文件也带进去了，导致模型在旧逻辑上做推理。用/drop把无关文件移出去，重新提问，问题通常当场消失。

5.5 自定义命令载入失败：缓存与路径的坑

自定义命令写好了却不生效，另一个常见原因是路径歧义。全局命令和项目命令如果同名，项目级优先级更高，但可能有缓存残留导致新改动不生效。我的排查顺序是：确认当前工作目录在项目根目录下，确认命令文件放在.claude/commands而不是随便建了个同名文件夹，然后重开会话再试。

还有一个细节容易被忽略：命令文件的文件名会直接决定命令触发词，最好不要用中文和特殊字符，否则在某些终端环境里补全和识别会有问题。保持英文小写加短横线，是最稳妥的命名方式。

结尾：我整理这张表之后的真实心得

把 93 个命令入口整理完的那一刻，团队有人问我：真的有人能用得上 90 多个命令吗？我的回答是，日常开发里八成时间可能就靠那十个主力命令，但知道全貌的价值在于，当你遇到一个从来没见过的工程问题时，你会想起“好像有个东西能干这个活”，而不是又回到手工复制粘贴和反复聊天试探的笨办法。

我个人实际用下来的体会是：不要试图一上来就背完整张表。先把/init、@、!、/add、/drop、/compact、/model这七个玩到形成肌肉记忆，再按你自己项目的痛点，逐个添加自定义命令。随着使用时间推移，你会慢慢形成一套属于自己团队的命令体系，那个价值远比我给的清单大得多。最后再分享一个小建议：每新增一条自定义命令，顺手在CLAUDE.md里记一句它的用途，三个月后你会发现，这份文件才是你这个项目最值钱的数据资产。