企业官网建设流程全解析

说实话，我第一次用 Claude Code，是老老实实打开一个独立终端窗口跑的。敲命令没问题，可一旦遇到“编辑器里正看着这个文件，想让 AI 顺手改一下”的场景，整个人就得在两个窗口之间来回切。切几次还好，切多了你会发现上下文也断了、引用文件也算了，干活效率还不如不接 AI。直到某天我把 Claude Code 搬进了 VS Code 的集成终端，才意识到前面白折腾了那么久。

这篇文章就聊清楚一件事：怎么在 VS Code 终端里把 Claude Code 用得顺手，甚至“调教”出符合自己习惯的工作流。适合已经在用或准备入坑命令行列 AI 编程工具的同学，尤其是受够了多窗口切换、想把手头项目真正交给 AI 动手改的人。我会把原理、步骤、配置方法和踩过的坑一次性讲完，尽量做到你看完就能直接上手。

1. 为什么把 Claude Code 搬进 VS Code 终端，而不是单开一个窗口跑

先说个很现实的问题：Claude Code 本质上是一个跑在终端里的 AI 结对编程助手，它任何时候都需要和你的代码库、编辑器、版本控制工具协同工作。独立终端最大的问题不是不能跑，而是“割裂感”太重。

1.1 之前的工作流，别扭在哪

独立终端里跑 Claude Code，你会遇到三类最常见的别扭：

• 引文件要手敲路径。想让 AI 看src/components/UserCard.tsx，你得把整条路径打出来，或者拼凑粘贴，多一步都显得蠢。
• 看 diff 要切窗口。它改完代码，你要去编辑器里看改动，发现问题再回终端补充描述，一来一回，本来连贯的思路就被切碎了。
• 报错地址不直观。终端里抛出的报错有文件名和行号，但在独立终端里你没法直接点过去，得自己按路径再找一遍。

这些痛点单独看都不致命，但它们共同造成了一个后果：你的注意力始终在“搬运信息”，而不是“研究问题”。我在连续用了一周之后最大的感受是，AI 的上下文再强，也扛不住我反复把文件路径、代码片段、报错信息换个窗口重新喂一遍。

1.2 集成终端里用，核心收益是什么

把 Claude Code 放进 VS Code 集成终端，收益集中在这三点：

1. 工作区上下文天然存在。集成终端的当前目录就是你的项目根目录，启动会话时不需要额外切换目录，所有相对路径都直接用。
2. 编辑器联动零成本。Ctrl+` 呼出终端，Split 一个面板，AI 在左边跑，你在右边看改动，同一个窗口内就能完成“让它改、我看 diff、我反馈”的闭环。
3. 和 VS Code 生态无缝衔接。报错信息里的文件路径，很多在集成终端里可以直接点跳；关闭窗口时保留会话，下次打开还能续上。

它不是“换了个地方跑同样命令”这么简单，而是把 AI 工具真正嵌进了你的日常开发循环。写代码、看改动、跑测试、回滚，全部在一个界面里完成，这是独立终端给不了的体验。

2. 装好、跑通、登录：跳过环境坑是最省时间的一步

所有工具的第一步都是安装。Claude Code 的安装并不复杂，但恰恰是这种“不复杂”的步骤，很多人会因为疏漏卡住很久。

2.1 前置依赖与安装命令

Claude Code 需要一个较新的 Node.js 运行时。安装完不要直接跑安装命令，先确认一下版本：

node -v npm -v

如果node命令都没找到，说明 Node.js 不在你的 PATH 里，需要先解决环境变量问题，再去安装。接下来全局安装：

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

提示：如果你平时习惯用pnpm或yarn，也都能装。比如pnpm add -g @anthropic-ai/claude-code，效果一样。

安装完测试一下：

claude --version

如果能输出版本号，说明装成功了。反之，如果提示command not found，大概率有两种原因：一是 npm 全局路径没有被加到系统 PATH 里，二是你的 shell 配置还没重载。此时不要急着重装，先看看npm prefix -g的输出，再把那个路径加进.zshrc或.bashrc。

2.2 登录与权限初始化

第一次运行claude，会进入登录流程。按提示打开浏览器授权即可，这个动作本质上是让本地 CLI 拿到一个会话凭证，后续的请求都会带上它。

登录成功之后，我建议你花 30 秒看一眼权限配置。Claude Code 默认会询问是否能执行 shell 命令，这个交互有点频繁，但初期不建议直接全部跳过确认。你需要在体验中慢慢感受哪些命令是安全的、哪些操作需要你牢牢把关，后面我会专门讲怎么用白名单减掉打扰。

2.3 顺手把终端配置成顺手的形态

很多人忽略这一步，但我认为它对使用体验的影响很大：

• 在 VS Code 设置里把terminal.integrated.defaultProfile设成你常用的 shell（比如 zsh、bash）。
• 给集成终端开一个独立的颜色主题或边框色，这样你能一眼分辨哪个面板在跑 AI。
• 把终端字体调大一点。Claude Code 的输出密度很高，字小了看一会儿就头晕。

这几个调整都不难，但属于“早调早享受”的长期投资。

3. CLAUDE.md 才是“调教”的关键：让模型记住你的工程习惯

很多人用这类 AI 工具，停留在“每次临时描述需求”的阶段。这当然能用，但效果很不稳定，因为模型的记忆是短时的。真正让它持续配合你习惯的机制，是项目级记忆文件CLAUDE.md。

3.1 项目记忆文件怎么写

在项目根目录创建CLAUDE.md，Claude Code 启动时会自动加载它，把它作为项目背景混入上下文。这意味着你不需要每次对话复述技术栈、目录结构、代码风格这些基本信息。

我项目里的CLAUDE.md模板大概是这样的：

# 项目记忆 ## 技术栈 - 前端：Vue3 + TypeScript + Vite - 后端：Node.js + Express - 数据库：PostgreSQL，通过 Prisma 访问 ## 代码约定 - 提交信息用 conventional commits 格式 - 组件统一使用 `<script setup lang="ts">` - 单个函数超过 80 行时拆分成多个小函数 - 样式优先使用项目内的 design token，不写死颜色值 ## 常用命令 - 开发启动：npm run dev - 运行测试：npm run test:unit - 数据库迁移：npm run db:migrate

这三个部分非常实用。“技术栈”让 AI 不用猜你用什么框架；“代码约定”直接影响它生成的代码风格；“常用命令”能减少它让你手动执行某些频繁命令的次数。我实测下来，有了这几段之后，AI 生成的代码在风格上贴合度提升非常明显。

3.2 全局记忆与项目记忆的分工

除了项目根目录的CLAUDE.md，你还可以设置用户级别的全局记忆文件（通常在~/.claude/CLAUDE.md）。两者分工要明确：

• 全局记忆：放个人偏好、通用代码风格、常用工具链习惯。比如“提交信息一律用中文”“优先使用 pnpm”“函数注释写清楚参数含义”。
• 项目记忆：放当前仓库特有的信息。比如这个项目的部署方式、目录划分、数据库模型、第三方服务配置。

这种分层设计的本质，是把通用能力和具体业务拆开。全局记忆负责让每个项目都“懂你”，项目记忆负责让当前项目“懂自己”，两者叠加，效果远好于把所有东西塞进一个文件。

3.3 注意别把隐私和密钥写进去

这是个很容易踩的坑。CLAUDE.md会被 AI 作为上下文读取，也会在团队协作时被别人看到。API Key、数据库连接串、敏感的内部服务地址，绝对不能写进去。

如果某个项目确实需要让 AI 记住一些配置信息，建议用环境变量的方式注入，在需要时手动引用，而不是写进记忆文件。

4. 在编辑区旁边指挥它：上下文引用与即时改码

安装和记忆文件都配好之后，终于到真正的核心体验：一边看代码，一边指挥它干活。

4.1 把当前文件和选中代码喂给它

Claude Code 支持在对话中直接引用文件路径。在集成终端里，最顺手的操作是：

claude "重构 src/api/user.ts 里的错误处理逻辑"

这样启动会话时，AI 已经知道项目背景和目标任务。如果你已经在会话中，想临时让它看某个文件，可以这样写：

@src/api/user.ts 这段代码里的 fetch 错误处理有什么问题？

@文件名就是一种“把文件拉进上下文”的快捷方式，比复制粘贴整段代码高效得多。还有一种更符合直觉的做法：在编辑器里选中代码，然后切到终端输入@，VS Code 的快捷键或剪贴板辅助可以帮你在终端里快速取到当前选中内容。具体操作路径可能因版本不同略有差异，但核心思路是一致的——把“当前正在看的东西”直接作为上下文传给 AI，而不是靠人肉搬运。

4.2 让它自己动手改文件，边界怎么控制

Claude Code 不只是聊天工具，它可以在获得权限后直接改文件。这个能力很强，但边界感一定要建立起来。

我的建议是，让 AI 动手改文件之前，先让它说清楚“打算怎么改”。你可以要求它给出改动方案，确认之后再让它执行。这样做的原因是，代码重构往往存在多种可行解，它选的那一条未必符合你的预期。先对齐方案，再动手执行，能省掉很多无意义的来回。

改完之后，一定要看一眼 diff。在 VS Code 集成终端里，这个动作很快：切到源代码管理面板，或者直接输入git diff查看改动。如果发现 AI 改偏了，直接用git checkout -- <文件>回滚，重新让它改。这个工作流的核心是：AI 动笔，你把关。

4.3 用会话管理控制多任务上下文

Claude Code 的会话是独立上下文。我的习惯是给不同任务开不同会话：

# 处理登录模块的重构 claude "重构登录模块" # 给前端写单元测试 claude "为 utils/date.ts 补充单元测试"

这样做的好处是，不同任务不会互相污染上下文。比如你聊了半天测试用例，再去让它改登录模块，它可能还会惦记着刚才测试的事，开始输出一些多余内容。独立会话能避免这种“上下文串味”。

5. 边用边调的进阶姿势：自定义命令与权限白名单

当你把基础流程跑顺之后，就该进入“调教”阶段了。这一步决定你是在“用工具”，还是真正“指哪打哪”。

5.1 自定义斜杠命令的场景

Claude Code 支持自定义斜杠命令，本质上是把一段高频复用的提示词抽出来。在.claude/commands/目录下新建一个 Markdown 文件，比如.claude/commands/review.md：

--- description: 对当前分支的改动进行代码评审 --- 请先运行 git status 查看当前分支改动文件列表，然后逐个文件查看 diff，按以下格式输出评审结果： - 严重问题：可能导致线上故障或明显逻辑错误 - 建议优化：代码可读性、性能、潜在边界问题 - 疑问澄清：无法确定意图、需要人工确认的地方 最后按严重程度排序，给出优先处理顺序。

之后在对话里输入斜杠命令就能触发预设工作流，不需要每次手打一大段说明。类似的场景还能自定义：提交信息生成、创建新组件、数据库迁移脚本生成、某类接口文档更新、甚至是“帮我分析这个报错并给出排查步骤”。

自定义命令之所以好用，是因为它把“你反复说的话”变成了“工具自带的能力”。长期使用后，你会沉淀出一套完全贴合自己项目的命令集，换任何项目都能快速迁移这些工作流。

5.2 权限配置的本质是信任边界

Claude Code 在执行命令时需要权限，默认情况下它会频繁弹出确认。初期你会觉得安全，用熟了就会觉得烦。解决方法是配置权限白名单，把高频率、低风险的操作放进去。

claude config set -g allowedTools "Bash(git:*)"

上面这条命令允许 AI 运行所有git开头的操作。这样像git status、git diff、git add这类日常命令就不再逐条询问了。当然，是否把“写”操作也加入白名单，需要你自己评估风险。我的原则是：只给“读和查”放权，保留“删和写”的确认。

权限配置的本质是信任边界管理。你信任得越多，交互越流畅，但风险也越高。建议从最小权限开始，逐步放权，不要第一次配置就全部放开。

5.3 多终端并行，互不干扰

VS Code 的集成终端支持分屏。我会开两个终端面板：一个跑 Claude Code，用来生成和修改代码；另一个跑测试、构建、git 操作。这样 AI 在跑长任务的时候，我还能在另一个面板里手动检查其他事，真正做到并行工作。

如果同时有多个任务，还可以给每个任务开一个独立终端标签页，各自对应一个 Claude Code 会话。配合 VS Code 的终端命名功能，一眼就能分清哪个面板在跑哪个任务。

6. 我踩过的坑：权限弹窗、路径空格、长输出截断

用了一段时间之后，遇到的坑也不少。这些问题单看都小，但不处理就会反复磨你的耐心。

6.1 安装后claude命令找不到

最常见的坑之一。很多人的 Node.js 是通过官网 pkg 包装的，npm 全局安装路径通常指向/usr/local/bin，这没问题。但如果你用了某些版本管理工具，全局 bin 目录可能没被放进系统 PATH。解决方法：

npm prefix -g

把输出的路径添加到 shell 配置文件里再重开终端。如果还是找不到，检查一下 Node.js 本身的版本是否满足要求，别在旧版本上浪费时间。

6.2 路径带空格或中文目录的坑

在 Windows 上，项目路径里如果带了空格或中文，某些内部命令拼接时容易出问题。这不是 Claude Code 独有的毛病，是大量 CLI 工具的通病。

我的规避方法是：尽量把代码工程放在纯英文无空格的路径下；早在创建项目时就避免“我的项目 v2”这类目录名。实在避不开，在执行相关命令时，给整个路径加双引号包裹。

6.3 终端输出截断与乱码

长任务输出很多，终端会滚动得飞快，而且某些情况下会把上下文搞得很长。Claude Code 有专门的处理方式，你可以引导它控制输出长度，或者要求每轮回复只给摘要、细节放代码文件里。

乱码问题在 Windows 上更常见，通常是编码不匹配。把终端编码调到 UTF-8，或在 shell 里执行：

chcp 65001

能解决绝大多数中文输出乱码问题。别小看这个，它能让你的阅读体验提升一个量级。

6.4 误操作之后的补救流程

最后说说误操作。AI 在获得权限后执行了某条命令，结果你发现它改错了文件。这时候最重要的不是骂工具，而是迅速回滚。

git add -A && git stash

或者精确一点，只放弃某一个文件的改动：

git checkout -- src/components/UserCard.tsx

平时养成小步提交的习惯，每个功能点改完先提交一次，后面 AI 改崩了，你随时有退还到安全位置的余地。我在实际使用中发现，好用的不是那些“一步不改”的谨慎策略，而是“敢让 AI 改，但随时能退回去”的完整兜底机制。

最后再分享一个小技巧

如果你和我一样，经常在几个项目之间来回切，强烈建议把不同项目的 Claude Code 会话命名区分开，同时在每个项目里都维护一份自己的CLAUDE.md。这样不管切到哪个工程，AI 都能立刻进入状态，而不是每次都要你重新介绍背景。

我自己的体会是，工具再强也只是工具，真正决定体验上限的，是你有没有建立起一套稳定的使用规则。等规则成型，Claude Code 在 VS Code 终端里的体验，会比最开始的“开一个黑窗口问两句话”高效太多。