企业官网建设流程全解析

1. 为什么我花了一周时间整理这100条指令

用 Claude Code 的人越来越多，但大部分人的使用深度其实停留在“打开终端、敲一句帮我写个函数、复制结果、关掉”这个循环里。我刚开始也这样，直到有次看一个同事操作，同一个重构任务，我敲了七八轮对话才搞定，他三条指令结束战斗，还顺手把测试和提交信息都生成了。那一刻我才意识到，Claude Code 的真正效率差距不在模型本身，而在你对指令系统的熟悉程度。

Claude Code 是 Anthropic 推出的命令行 AI 编程工具，它直接跑在你的终端里，能读写项目文件、执行 shell 命令、跑测试、管理 git，本质上是一个“住在你项目目录里的结对程序员”。它和网页版对话最大的区别是：它有上下文、有工具、有权限，能真正动手改你的代码。而驱动这一切的，就是指令——包括斜杠指令（slash commands）、CLI 启动参数、以及对话中的自然语言指令模式。

这份整理适合三类人：刚装好 Claude Code 还没摸清门路的新手、用了一阵但总觉得效率没拉满的中级用户、以及想把这套工具引入团队工作流的 Tech Lead。我会把 100 条常用指令按场景拆开讲，每条都说清楚什么时候用、为什么这么用、有什么坑。不是干巴巴的清单，而是我自己踩过一遍之后的实战笔记。

提示：指令数量会随版本迭代变化，我整理的是当前稳定版本下最常用、最值得记住的那批。核心逻辑比具体条目更重要。

2. 指令体系的整体设计与分类逻辑

2.1 三类指令的本质区别

很多人把 Claude Code 的指令混为一谈，其实它分三个层次，用途完全不同。

第一类是斜杠指令，在对话输入框里以/开头，比如/help、/clear、/init。这类指令由客户端本地解析，不消耗模型 token，作用是控制会话状态、切换模式、触发特定工作流。你可以理解为“操作系统的快捷键”。

第二类是CLI 启动参数，在终端敲claude命令时带的 flag，比如claude -p "xxx"、claude --resume。这类决定会话怎么启动、用什么权限、加载哪个配置。它是“进门之前的设置”。

第三类是自然语言指令模式，就是你直接跟它说的话，但有一些固定句式能触发特定行为，比如“先看再改”“只输出 diff 不要写入”“用 TDD 方式实现”。这类最灵活，也最考验使用者的表达功力。

2.2 为什么指令设计成这个样子

Claude Code 的指令体系背后有个清晰的设计哲学：把确定性操作和概率性操作分开。斜杠指令和 CLI 参数是确定性的，敲了必然执行某个动作；自然语言是概率性的，模型理解成什么样有波动。这个分离很关键——状态管理、权限控制、会话切换这些不能出错的事情，交给确定性指令；代码理解、方案设计、重构这些需要判断的事情，交给自然语言。

理解了这一点，你就知道为什么不该用自然语言去干/clear的活（比如跟它说“忘掉之前的对话”，效果远不如直接/clear），也不该指望斜杠指令帮你做架构决策。

2.3 我建议的记忆优先级

100 条不可能全背下来。我的建议是按这个优先级记：

• 必记（每天用）：/help、/clear、/init、/compact、/review、/model，加上claude -c、claude -p、claude --resume。这不到 10 条覆盖 80% 日常场景。
• 常用（每周用）：权限相关、git 相关、上下文管理相关，大概 20 条。
• 备用（知道存在即可）：剩下的按需查/help或本文档。

下面进入正题，我按场景把指令拆开讲。

3. 会话与上下文管理指令详解

3.1 会话生命周期指令

会话管理是最基础也最容易被忽视的一块。很多人一个会话开一整天，上下文塞满了各种无关内容，模型越来越迟钝，还以为是模型变笨了。

/clear是清空当前会话上下文，但不退出程序。什么时候用？当你切换到一个完全无关的任务时。比如你刚调完一个 Python bug，现在要写前端组件，直接/clear比在旧上下文里继续干净得多。我实测下来，不清上下文直接切任务，模型经常把两边的变量名、框架习惯混在一起，产出质量明显下降。

/compact是压缩上下文，把之前的对话总结成摘要保留，释放 token 空间但保留关键信息。这个指令在长任务里特别有用——比如你做一个大重构，已经聊了 50 轮，上下文快满了，但又不想丢掉前面的决策记录，/compact就是干这个的。它和/clear的区别是：/clear是失忆，/compact是记笔记。

/resume在会话内使用可以恢复之前的会话，而 CLI 层的claude --resume或claude -c是启动时直接续上最近一次会话。-c是--continue的简写，我几乎每次重开终端都用它，省得重新交代项目背景。

/exit或Ctrl+C两次退出。这里有个小坑：直接关终端窗口有时会留下锁文件，下次启动报错，养成用/exit的习惯更稳。

3.2 上下文注入指令

/init是初始化项目记忆文件，会在项目根目录生成CLAUDE.md。这个文件是 Claude Code 的“项目说明书”，每次会话启动会自动读取。我强烈建议每个项目都跑一次/init，然后手动编辑CLAUDE.md，把项目结构、技术栈、代码规范、常用命令写进去。这一步做得好，后面每次对话都省去大量解释成本。

/memory用来查看和编辑当前加载的记忆内容。有时候你改了CLAUDE.md但不确定有没有生效，/memory一看便知。

#开头的输入是快速记忆指令，比如# 这个项目用 pnpm 不用 npm，它会直接追加到记忆文件里。这个我经常用，遇到模型反复犯同一个错，就#记一笔，下次就不会再犯。

/add-dir可以把项目外的目录加入工作区。比如你的项目依赖一个本地共享库，在另一个目录，用这个指令加进来，模型就能同时读写两边。

3.3 上下文管理的实操心得

我踩过最大的坑是：在同一个会话里既做代码审查又做功能开发。审查时模型处于“挑刺”模式，开发时需要“建设”模式，两种心态混在一起，产出很别扭。后来我养成习惯，审查用/review单独开，开发另起会话。

另一个心得是关于CLAUDE.md的写法。不要写成 README 那种给人看的文档，要写成给模型看的“操作手册”。比如“运行测试用pnpm test:unit，不要用npm test”“组件文件放在src/components/，每个组件一个目录”这种具体到命令和路径的指令，比“本项目采用模块化架构”有用一百倍。

4. 代码操作与文件读写指令

4.1 读取与理解代码

Claude Code 默认会按需读取文件，但你可以用指令引导它读得更准。直接说“读一下src/auth/目录下所有文件，总结认证流程”比“帮我看看认证怎么实现的”高效得多。前者给了明确范围，后者让模型自己猜。

@符号是文件引用指令，输入@会触发文件路径补全，选中后该文件内容会直接注入上下文。这个在精准提问时特别好用，比如@src/utils/date.ts 这个文件的 formatDate 函数有没有时区问题。

对于大项目，我建议先用“给我画一下这个模块的调用关系”这类指令让模型建立全局观，再深入具体文件。直接扎进细节容易迷路。

4.2 修改与写入代码

默认情况下，Claude Code 修改文件前会展示 diff 并请求确认。这个确认机制很重要，别嫌烦。我见过有人为了图快开了全自动权限，结果模型把一个配置文件改错了，排查半天。

/permissions可以查看和修改权限设置。权限分几档：只读、可编辑需确认、可编辑免确认、完全访问。我的建议是日常用“可编辑需确认”，只有在跑批量机械修改（比如全项目重命名变量）时才临时开免确认。

写入时的关键指令模式是“先看再改”。明确说“先读这三个文件，理解现有实现，然后只修改handleSubmit函数，其他不动”。这样能避免模型顺手“优化”了你不想动的地方。我吃过亏——让它改个按钮文案，它把整个组件的状态管理重构了，diff 几百行，review 起来想哭。

/diff查看当前所有未提交的改动，相当于内置了一个 git diff。改完一批文件后先/diff扫一眼，确认没有意外改动再提交。

4.3 代码审查与质量指令

/review是触发代码审查工作流，它会检查当前改动，从正确性、安全性、性能、可读性几个维度给意见。我通常在提交前跑一次，当免费的 pre-review。

/security-review更聚焦安全，检查注入、越权、敏感信息泄露这类问题。涉及用户输入、数据库操作、认证逻辑的改动，我必跑这个。

审查类指令有个使用技巧：明确审查范围。/review默认看所有未提交改动，如果改动很多，最好说“只审查src/api/下的改动”，否则模型注意力分散，意见质量下降。

4.4 文件操作的避坑经验

第一个坑：不要让模型操作它没读过的文件。有次我让它“把 config 里的超时改成 30 秒”，它没读文件就凭猜测改了，改错了字段。正确做法是先@config引用，或者明确说“先读 config 文件再改”。

第二个坑：批量操作前先备份或确保在 git 干净状态下。模型批量改文件时偶尔会漏掉某个文件或改错，有 git 兜底随时能回滚。我现在的习惯是，任何超过 3 个文件的批量修改前，先git status确认干净。

第三个坑：注意模型的“过度热情”。你让它修一个 bug，它可能顺手把相关的“潜在问题”也改了。如果只想最小改动，明确说“只修这个 bug，不要做其他改动”。

5. CLI 启动参数与工作流指令

5.1 启动参数速查

CLI 参数是很多人忽略的一块，但它能大幅改变使用体验。下面这张表是我最常用的启动参数：

claude -p这个模式值得单独说。它是“打印模式”，执行完直接输出结果就退出，不进入交互。这个在写脚本时无敌好用，比如claude -p "检查 src 下所有 ts 文件的类型错误并输出列表"，可以直接嵌到 shell 脚本或 CI 流程里。

5.2 权限与安全参数

--dangerously-skip-permissions是跳过所有权限确认，慎用。我只在完全隔离的容器环境或一次性任务里用。本地开发环境绝对不要开，风险太大。

--allowedTools和--disallowedTools可以精细控制模型能用哪些工具。比如你只想让它读代码不想让它执行命令，可以禁用 Bash 工具。这个在给团队做标准化配置时很有用。

/permissions在会话内调整权限，比启动参数更灵活。我通常启动时用默认权限，遇到需要批量操作时临时/permissions提权，干完再降回来。

5.3 工作流自动化指令

/agents可以创建和管理子代理，每个子代理有独立的上下文和工具权限。这个高级功能适合复杂任务拆分，比如一个代理专门写测试，一个专门做重构。我目前用得不多，但在大型重构里试过，效果不错。

/hooks配置钩子，在特定事件（如文件保存、工具调用前后）触发自定义脚本。比如你可以配一个钩子，每次模型改完文件自动跑 lint。这个需要一些配置功底，但配好之后很省心。

/mcp管理 MCP 服务器连接。MCP 是外部工具集成协议，能让 Claude Code 连上数据库、API、第三方服务。我接了一个内部文档系统的 MCP，查接口文档不用切窗口了。

5.4 工作流指令的实战组合

分享一个我常用的组合：早上开工，claude -c续上昨天的会话，先/memory确认项目记忆加载正常，然后/diff看昨天有没有遗留未提交改动，接着/review快速过一遍，确认没问题就继续开发。这一套下来不到一分钟，但能避免很多“昨天改到一半忘了”的尴尬。

另一个组合是处理 issue：claude -p "读一下 issue.md，分析需要改哪些文件，输出方案"先做分析，确认方案后再进交互模式实施。分析和实施分开，思路更清晰。

6. 常见问题排查与避坑实录

6.1 会话与上下文类问题

问题一：模型突然“失忆”，不记得前面说过的约定。

排查思路：先/memory看记忆文件是否正常加载，再检查是不是上下文超限触发了自动压缩。如果是压缩导致的，关键约定可能被摘要掉了。解决办法是把重要约定写进CLAUDE.md，而不是只靠对话记忆。

问题二：/compact之后模型行为变了。

这是正常的，压缩会丢失细节。我的经验是，压缩前先把关键决策用#记进记忆文件，压缩后这些还在。另外压缩后可以补一句“继续之前的任务，当前进度是 xxx”，帮模型重新对齐。

问题三：会话启动报锁文件错误。

通常是上次非正常退出留下的。找到项目下的锁文件删掉即可，或者用/exit正常退出养成习惯。

6.2 权限与操作类问题

问题四：模型反复请求权限，很烦。

用/permissions把常用操作（比如读文件、跑测试）设为免确认，危险操作（比如删文件、执行任意命令）保持确认。分级管理比一刀切好。

问题五：模型改了不该改的文件。

第一，确保在 git 干净状态下操作，随时能回滚。第二，明确指令范围，“只改 A 文件”。第三，改完/diff检查。这三步做好基本不会出大问题。

问题六：批量操作中途失败。

模型批量改文件时如果中途出错，可能改了一半。这时候git diff看改了哪些，git checkout回滚，然后缩小批量范围重试。别在失败状态下继续让模型“修复”，容易越修越乱。

6.3 输出质量类问题

问题七：模型给的方案太泛，不落地。

这是提问方式的问题。把“帮我优化这个函数”换成“这个函数在数据量 10 万时会慢，分析瓶颈并给出具体优化代码”，输出质量立刻不一样。给约束、给场景、给期望输出格式，是提升质量的三板斧。

问题八：模型理解错了需求。

先别急着纠正，让它复述一遍它的理解。“你刚才理解的需求是什么？复述一下”，往往能发现是哪里歧义了。然后重新表述，比在错误理解上打补丁高效。

问题九：代码能跑但风格不符项目规范。

根因是CLAUDE.md没写清楚规范。把项目的 lint 规则、命名习惯、目录约定写进去，模型会遵守。我还会在CLAUDE.md里放一两个“范例文件”路径，让模型参考风格。

6.4 常见问题速查表

6.5 我踩过的最深的三个坑

第一个坑是在脏工作区让模型改代码。有次我手头有一堆未提交改动，又让模型改另一个文件，结果它把两者混在一起，diff 乱成一团，回滚都不敢回。从那以后，改代码前必git status。

第二个坑是过度依赖自动权限。图省事开了免确认，模型把一个.env文件的内容读出来写进了日志。虽然本地环境没造成实际损失，但吓出一身冷汗。权限这东西，宁可多确认一次。

第三个坑是把 Claude Code 当搜索引擎用。问它“React 的 useEffect 怎么用”，它给的和网页搜索差不多，还占上下文。这类通用知识问题不该问它，它的价值在于结合你的项目上下文给具体方案。问“我这个组件里的 useEffect 依赖数组有没有问题”才有意义。

7. 把指令用成肌肉记忆的进阶思路

7.1 建立个人指令清单

100 条不用全记，但要建立自己的“高频 20 条”。我的做法是在CLAUDE.md里放一个“常用指令速查”段落，把自己最常用的指令和用法写进去。这样既提醒自己，也让模型知道我的工作习惯。

更进一步，可以把常用工作流写成 shell 别名或脚本。比如我有个cr别名，展开是claude -p "review 当前 git diff，按严重程度列出问题"，敲两个字母就完成一次快速审查。

7.2 团队协作中的指令标准化

如果你要把 Claude Code 引入团队，CLAUDE.md就是标准化的抓手。把团队规范、常用命令、目录约定、审查清单都写进去，新人 clone 下来就能用统一的方式和 AI 协作。我们团队还维护了一个共享的“指令片段库”，把高频指令和提示词模板沉淀下来，避免每个人重复造轮子。

7.3 指令之外的思考

工具再强，也只是放大器。Claude Code 放大的是你原本的工程能力——你架构清晰，它帮你更快落地；你思路混乱，它帮你更快地产生混乱。我见过有人指望它“自动写好整个项目”，结果得到一堆能跑但没法维护的代码。指令是术，工程判断是道，别本末倒置。

最后分享一个我最近养成的习惯：每周花十分钟回顾这周用 Claude Code 的过程，把新发现的顺手指令记下来，把踩过的坑写进CLAUDE.md。这个复盘习惯坚持两个月后，我的指令使用效率大概翻了一倍。工具在迭代，用法也在迭代，持续记录比一次性背清单有用得多。