企业官网建设流程全解析

用过 Claude Code 的人大概都有这种感觉：前几次用还觉得新奇，用上一周之后，它就从“聊天机器人”变成了真正的工作搭档。但这个搭档好不好使，很大程度上取决于你怎么对它下指令。

这 100 条常用指令并不是某个官方文档里的编号清单，而是我每天实际使用 Claude Code 时积累下来的命令、参数和话术组合。从安装、认证、上下文管理，到权限控制、CLAUDE.md 规范、自动化钩子，再到 Git 协作和排错，基本覆盖了日常开发会碰到的所有场景。如果你刚开始接触 Claude Code，或者已经用了一段时间但总觉得“差点意思”，这篇内容应该能帮你省下不少摸索时间。

1. 安装与首次启动：看似简单但最容易翻车的地方

1.1 我推荐的安装方式，以及为什么不用纠结版本

Claude Code 的安装，官方现在提供了两种主路径：一种是直接通过 npm 全局安装，一种是使用桌面端安装包。我的建议是：如果你平时已经在用 Node.js 开发，直接走 npm 最省事；如果你完全不想碰终端命令行的环境折腾，那原生安装包更适合你。

npm install -g @anthropic-ai/claude-code

装完之后，在终端里跑一下claude --version，看到版本号就说明装好了。这里有个容易忽略的细节：安装之后不要急着进项目，先在任意目录跑一次claude，让它完成初始化配置，再进到你的真实项目目录使用。否则某些环境下会出现配置目录没生成、登录态不生效的怪问题。

Ubuntu 用户如果遇到安装后claude: command not found，大概率是 npm 全局 bin 目录没加到 PATH 里。检查npm prefix -g的输出，把对应的 bin 目录加到~/.bashrc或~/.zshrc里就行。

1.2 登录、授权和第一轮体验

启动后第一步是登录。Claude Code 的登录流程会引导你打开浏览器完成授权，然后把 token 存在本地。这部分正常情况下很顺利，但有三类问题我见过不止一次：

• 组织账号和普通账号的权限范围不同，会出现“个人账号能跑、公司账号被拦”的情况；
• 终端代理环境配置混乱，导致登录后回调失败；
• 首次进入项目目录时，它会提示需要读取文件、执行命令等权限，很多人直接一路回车选了默认，后面用起来才发现权限不够。

我的建议是，第一次授权时别嫌麻烦，看清楚每个权限提示。文件读取、命令执行、网络访问这几类权限是日常编码中最常用的，该给就给。但如果是在不信任的第三方代码库里，注意别轻易给 bash 权限，防止它执行一些你还没看懂的脚本。安全第一，不是一句空话。

1.3 在 VSCode 里配置 Claude Code

如果你主要在 VSCode 里工作，我建议不要只是把它当外部终端工具来回切换，而是直接让 Claude Code 以集成终端的方式跑在编辑器内部。步骤很简单：VSCode 里打开终端面板，确认默认 shell 是 bash/zsh，然后直接运行claude。

我习惯把集成终端拆成上下两个面板，上面跑 Claude Code，下面跑普通 shell，遇到它需要我手动确认的命令时，直接切过去操作。这个方案比装第三方扩展更稳定，因为 Claude Code 官方主推的还是 CLI 形态，VSCode 扩展能做到的，终端基本都能做到，反而少了一层兼容性问题。

2. 日常最常用的核心指令：上下文与对话管理

2.1 /init、/clear、/compact：把上下文控制权握在自己手里

Claude Code 和普通网页聊天最大的区别是，它工作在一个长期存在的会话里，上下文会不断累积。对话越长，token 消耗越高，响应速度也会下降。所以上下文管理能力，直接决定你能不能用得顺手。

• /init：在当前项目生成或更新 CLAUDE.md。这应该是你进入任何项目做的第一件事，它会扫描项目结构、README、代码组织方式，生成一份项目说明文件。后续每次对话，Claude Code 都会自动加载这份文件，相当于给模型补上了“项目上下文”。
• /clear：清空当前会话历史。当你感觉上下文已经混乱，或者要换一个完全不相关的任务时，直接清空，别犹豫。
• /compact：压缩当前对话历史。它是/clear的温和版，保留核心意图和已完成事项的摘要，把冗长的中间过程丢进回收站。适合一个大功能还没做完，但上下文快撑不住的时候用。

我自己有个习惯：每完成一个阶段任务，就手动敲一次/compact，而不是等它提示我。这能保证每个阶段开始时，模型面对的都是精简后的上下文，效果明显比硬撑到底好得多。

2.2 /model、/memory、/help：三个容易被忽略的基础指令

很多人不知道/model可以在对话中途切换模型。Claude Code 底层可能对接多个模型配置，用/model可以实时切换轻量模型和强推理模型。简单任务用轻量模型，省 token 也快；复杂重构换回强模型，准确率更高。

/memory是管理长期记忆的入口。它对应的是用户级记忆文件，和项目的 CLAUDE.md 作用不同，这里记的是你个人的偏好。比如“代码风格需要遵循项目的 ESLint 配置”“提交信息一律用 Conventional Commits 规范”“不要自动删除未跟踪文件”这类跨项目的个人要求。记忆不是越多越好，只放那些“无论做什么项目都成立”的规则。

/help不用多说，忘了指令就敲它。我反而是建议刚上手的人先把/help的输出看一遍，里面能看到所有内置斜杠命令和示例，比看文档高效得多。

2.3 会话恢复：--continue 与 --resume 的差别

Claude Code 支持两种方式回到之前的会话。

• claude --continue：直接接续最近一次会话。
• claude --resume：弹出一个会话列表，让你选择恢复哪一次历史会话。

实际使用中我基本固定用--continue，因为大部分场景都是“昨天干到一半的活，今天接着干”。只有同时维护多个功能分支、需要切回不同上下文时，才用--resume去挑会话。

另外一个很实用的组合是：在 VSCode 里给命令起别名，比如把claude --continue绑成一个快捷键。这样早上打开编辑器，一键就能回到昨天的工作现场，效率体感提升非常明显。

2.4 几个平时想起才用、但关键时刻很救命的指令

还有几个指令不是天天用，但一旦遇到问题就是救命稻草：

• /cost：查看当前会话的 token 消耗情况。我一般每跑完一个大任务都会看一眼，防止费用失控。
• /status：查看当前会话状态，包括会话 ID、当前模型、API 状态等。
• /terminal-setup：当你发现终端渲染、快捷键或者颜色输出有异常时，用它重新初始化终端环境。

3. 让 Claude Code 真正“读懂”代码：文件权限、引用与搜索

3.1 用路径引用和 @file 精确控制上下文

很多人的使用习惯是直接把一大段代码贴进对话里，问“这段代码有什么问题”。这当然可以用，但 Claude Code 这些 CLI Agent 工具真正的优势在于：它可以直接读取项目文件。

你可以直接在消息里写@src/utils/format.ts 帮我看下这个文件里的函数有什么问题，它会自动定位并读取文件内容。也可以用@src/utils引用整个目录，让它自己决定读哪些文件。

路径引用的核心价值在于：你不需要自己复制代码，它读到的就是磁盘上的最新版本，不存在“贴错了旧代码”的问题。开始一个新任务时，我通常只会给它一个入口文件路径和一个目标描述，然后让它顺着引用的关系自己去探查。这比事无巨细地给它喂代码要高效得多。

3.2 grep、glob 与 Where 类问题的提问姿势

处理大型代码库时，“找代码”是最高频的需求。我总结了几种提问姿势，效果差别很大：

• “找到所有调用getUserInfo的地方” —— 这种一定要强调“列出调用点”，不然它会给你一段示例代码，而不是全部位置。
• “在src/services下搜索包含TODO的文件” —— 明确限定目录和关键词，命中率更高。
• “哪个文件定义了这个类型” —— 配合路径引用使用，让它先定位再解释。

它的搜索能力底层依赖 grep 和 glob 工具。遇到搜索不到的情况，先检查一下项目里有没有.gitignore或者.claudeignore把它挡掉了。有些目录（比如构建输出目录、大体积的 node_modules）被默认排除是正常的，但如果你明确知道某个文件存在却搜不到，十有八九就是忽略规则的问题。

3.3 权限控制：从只读到执行命令

Claude Code 的权限系统，是你和 Agent 之间的安全边界。理解这套权限模型，比记住任何指令都重要。

权限分为几类：读文件、写文件、执行 bash 命令、网络请求等。这些权限可以设置为“自动允许”“询问后允许”“拒绝”。

我的建议配置是：

这种配置下，日常开发效率和安全性能兼顾。尤其是 git 操作，很多人一开始图省事直接给自动权限，结果它把提交信息写错了、分支切错了，回滚起来反而更麻烦。

4. 用 CLAUDE.md 与自定义规则，把项目规范“刻进”模型

4.1 CLAUDE.md 到底该怎么写

CLAUDE.md 是 Claude Code 的项目记忆文件。它会在每次对话时被自动加载，相当于给模型一份“项目说明书”。很多人只是跑一次/init让它自动生成，之后就再也不管了，这其实是浪费了它最重要的功能。

我现在的做法是手写维护一个 CLAUDE.md，结构大致如下：

# 项目概述 这是一个基于 NestJS 的支付网关服务，主要处理订单、退款、对账等核心链路。 # 常用命令 - 启动开发服务: npm run dev - 运行测试: npm test - 构建: npm run build # 代码规范 - 目录结构遵循 modules / services / controllers 分层 - 数据库操作必须走 Repository，不允许在 Controller 中直接写 SQL - 新增接口必须补充 Swagger 注解 # 注意事项 - 生产环境配置读取自环境变量，禁止硬编码密钥 - 对账相关代码改动必须同时更新 docs/reconciliation.md - 禁用全局异常吞掉，必须显式抛出业务异常

写的时候记住一个原则：只写项目特有、且不写就会出错的信息。通用编程规范不要写进 CLAUDE.md，“使用驼峰命名”这种写在项目文件里毫无意义，因为模型本来就知道。真正重要的是那些只有你们团队知道的约束，比如“这个服务只能通过消息队列消费，不能直接对外暴露 HTTP 接口”。

4.2 项目级 CLAUDE.md 和用户级记忆的分工

Claude Code 的记忆分两层：用户级（~/.claude/CLAUDE.md）和项目级（项目根目录的CLAUDE.md）。

用户级放的是跨项目的个人偏好，比如“我的默认 shell 是 zsh”“格式化用 Prettier”“提交信息用中文还是英文”“不要用 var”。项目级放的就是上面提到的项目特有信息。

这两层不能混用。我之前犯过的错是把个人偏好写进项目级 CLAUDE.md，结果团队其他人 clone 项目后，也加载到了我的个人习惯，导致他生成的代码风格跟我一致，但跟项目实际规范对不上。记忆的层级设计，本质上是为了区分“人的长期画像”和“事的短期上下文”。

4.3 再进一步：用 hooks 把“硬约束”自动化

光靠 CLAUDE.md 写规范，模型未必每次都能遵守，毕竟它的注意力会被长对话稀释。真正可靠的方案是把校验逻辑交给自动化工具。

Claude Code 支持 hooks 机制，也就是在特定事件触发时执行自定义脚本。我主要用两种：

• PreToolUse：在模型调用某个工具前触发。比如禁止它运行rm -rf，可以在 hook 里直接拦截并报错。
• Stop：在一次回答结束时触发。比如检查生成的代码是否通过了 ESLint，没通过就自动标记出问题。

这相当于给 Agent 加了一层护栏。CLAUDE.md 负责“告诉它怎么做”，hooks 负责“在它做错时拦住它”。日常配置里，我是这样写的（简化版）：

{ "hooks": { "PreToolUse": [ { "matcher": "Bash(mkdir|touch|curl*)", "hooks": [ { "type": "command", "command": "node .claude/hooks/check-dangerous-cmd.mjs", "timeout": 10 } ] } ] } }

写 hooks 不需要很复杂，先覆盖风险最高的几个命令（删除、强制推送、批量修改权限），再逐步增加代码质量检查，就够了。

5. 搭建可持续的项目工作流，而不只是一次性对话

5.1 Todo List 驱动：从“帮我改个东西”到“帮我完成一个功能”

大多数人用 Claude Code 的方式是“拿到需求，描述一遍，让它干活”。这种模式处理小任务没问题，但一旦任务复杂，模型很容易顾此失彼——改好了一个文件，忘了另一个。

我现在的方式是拆分任务 + 维护 Todo。具体操作是，在开始一个功能前，先要求它输出一份任务分解清单，然后按清单逐项执行。对话里可以这样要求：

先不要写代码。分析这个需求，列出所有需要修改的文件、每个文件要改的核心点、风险点和验证方式，整理成 Todo 列表。确认后再开工。

任务执行中，它每完成一项，就会在 Todo 列表里打勾。这样有两个好处：一是执行顺序更清晰，二是中途上下文被打断时，你只需要看一眼 Todo 就能知道进度到哪了。

遇到大重构时，我会把这个 Todo 列表直接写进一个临时文件（比如docs/todo.md），让它在每次关键节点前后都去读取一遍，避免因为上下文折叠丢了进度。

5.2 大仓库场景下的心智负担控制

项目一大，模型很容易迷失在代码海洋里。你问它一个问题，它可能检索出十几个相关文件，然后自己也被绕晕了。

控制心智负担的方式是分区思考。一条实用的指令模式是：

先只分析src/modules/order这个模块内的代码，不要扩大到其他模块。我会告诉你什么时候可以跳出这个范围。

这样做本质上是给它划定思考边界。Claude Code 的很多“不听话”问题，不是模型笨，而是问题没有给它足够的约束。

另外，对于超大仓库，我建议在.claudeignore里明确排除掉与当前任务无关的大目录（比如legacy/、docs/、assets/）。这样能减少无效搜索，也减少 token 浪费。

5.3 与 Git 无缝协作：从写提交信息到自动处理合并冲突

每天和 Claude Code 配合 git 操作的频率非常高。我常用的指令链是：

1. 功能改完后，让它跑一遍测试，确认通过；
2. 让它git diff --stat看一下改动的文件范围；
3. 让它基于改动内容生成提交信息，并按 Conventional Commits 规范格式化；
4. 我审阅信息没问题后，由我手动执行git commit。

这里的关键点是：提交动作必须由人工触发，我从不给自动提交的权限。原因很简单，提交信息写得好不好只是小事，但它如果顺手把不该提交的文件（比如.env、日志文件）也提交了，处理起来就麻烦多了。

合并冲突也是高频场景。直接粘贴冲突内容让它解除是不推荐的，更好的方式是让它读取冲突文件，结合上下文理解两边各自的意图，再提出解决建议。当然，这块我依然只让它生成修改方案，实际执行是由我来决定。

6. 实战排错：那些文档里没写、我自己踩过的坑

6.1 上下文爆掉的信号，别硬撑

Claude Code 上下文接近上限时，通常有几种征兆：回答速度明显变慢、一开始的代码规范突然“忘记”了、重复修改同一个问题、回答开始泛泛而谈。这些信号出现时，最优处理就是立刻/compact，而不是继续往对话里追加“不对，再改一下”。

我有一次改一个后端接口，从下午改到晚上，对话历史估计被拉得特别长。后来它连最基本的路由结构都答不对了，我还在执着地继续问，白白浪费了大把时间和 token。最后/clear之后重来，五分钟就改好了。

6.2 权限逐条批准时，如何避免重复劳动

如果权限设成了“询问后允许”，一次大任务可能会弹十几个确认提示。第一次用的时候很容易烦，但直接全部改成自动允许又有风险。

我的折中方案是：先在项目根目录打开 Claude Code，执行一条“只读任务”（比如让它先分析代码结构），把项目相关的文件读取权限一次性授予。然后再开始核心任务，写文件权限保持询问模式。这样既保证了它能自由读取代码，又限制了它乱改文件。

另外，Claude Code 的权限选择里有一个“本次会话允许”和“永久允许”的区别，我建议默认只选“本次会话”。尤其是在临时看别人的仓库时，永久授权容易留下隐患。

6.3 “我以为它改了文件，其实没有”的教训

这个坑我踩过好几次，必须单独拿出来说。有时候 Claude Code 在回答里给你展示一段修改后的代码，你看了没问题，但它实际上并没有写进文件——它只是“演示”了一下。

解决方式：让它改完某个文件后，立刻让你看到 diff 确认。实用的指令是：

改完后，用git diff列出本次所有修改内容，确认修改已经落盘。

现在我会要求在每次改动后都执行一次git diff或git status，从结果反推它是否真的操作了文件。没有这个确认机制，后面基于错误前提继续开发，才是最大的时间黑洞。

6.4 安装卸载过程中遇到的几个“玄学”问题

不少人在安装或者卸载 Claude Code 时会遇到各种奇怪问题。常见的比如升级后提示版本不对、卸载了但claude命令还能用、全局缓存导致配置总是恢复默认。

这些问题的根源，大多是旧版本残留文件没有清干净。我的建议是走标准卸载流程，然后手动检查下面几个位置：

• npm 全局安装的残留包；
• 用户目录下的~/.claude配置和缓存目录；
• 系统 PATH 里残留的软链接。

卸载再安装后，如果发现配置还是旧状态，果断备份后清掉~/.claude里的配置目录再来一次。虽然听起来有点“重”，但比排查半小时玄学问题省时间。

最后分享一个我自己的使用心得。Claude Code 上手其实并不难，真正拉开效率差距的，是你能不能把它从“问一句答一句”的工具，变成“知道项目背景、遵守团队规范、自动执行常规任务”的工作搭子。100 条指令也好，几十个参数也好，都是为了这个目的服务的。从今天开始，试着给你的项目补一份正经的 CLAUDE.md，把常见任务拆成 Todo 清单，再给危险命令加上 hook 拦截——这三件事做完，你的体验会立刻不一样。