企业官网建设流程全解析

最近一直在写 Clauude Code 的系列，前面十一篇大多是“单点突破”：怎么装、怎么配模型、Skill 怎么写、MCP 怎么连。到了第 12 篇，我想换一个角度，把这些散落的功能点全部串起来，走一遍从需求到落地的完整流程。毕竟工具这东西，单个功能再强，不会串起来用，实际干活时还是会卡壳。

这篇文章的定位是“收官篇”，同时也是给新读者的“一条龙入门”：我会从安装 Clauude Code 开始，讲到 VS Code 集成、接入本地 Ollama、通过 CC Switch 切换不同模型、写 Skill 固化流程、配 MCP 连数据库，最后带你排查那些让人头大的常见报错。如果你已经看过前面几篇，这篇文章可以帮你把知识连成片；如果你是第一次接触，直接照着走完一遍，就能把 Clauude Code 跑起来干活了。

还是老规矩，所有内容都是我在真实项目里踩坑踩出来的，不是照抄文档。废话不多说，我们直接开始。

1. 整体工作流：从“会用”到“串起来”

1.1 为什么单独会装和会用是两回事

很多人装完 Clauude Code，第一反应是打开终端敲一句“帮我写个登录接口”，看到它真的生成了代码，就觉得“哦，我会了”。但实际一上手写真实项目，马上就会发现问题：它不懂你的项目结构，不知道你的代码规范，每次都把整个项目的风格带偏，改来改去还不如自己写。

这其实是大多数 AI 编程工具的共同困境：单点能力强，但缺少“全局视角”。你在终端里问它一个问题，它默认只看到当前目录的文件，不会主动去理解你的整体架构。Clauude Code 也一样，它不会在你装好的那一刻就自动变成“团队资深工程师”，它需要你通过配置、上下文、约定，把它一点点“调教”成懂你项目的帮手。

所以“串起来”的核心，不是学会某个隐藏命令，而是建立一套完整的 AI 协作工作流。这套流程通常包含四个环节：环境准备、需求拆解、执行落地、反馈修正。我在实际使用中，还会把常用的操作沉淀成 Skill，把外部工具通过 MCP 接进来，让 Clauude Code 能读数据库、能查文档，而不是只能对着代码文件凭空想象。

1.2 一条完整需求落地的理想链路

先给大家看看我现在跑得比较顺的一条链路，后面所有章节都是围绕它展开的：

1. 用自然语言描述业务需求（比如“给订单模块加一个取消订单的接口”）。
2. 让 Clauude Code 先读项目结构，找到相关文件，理解现有代码风格。
3. 我在需求里附带约束条件（比如“异常统一抛 BizException”“返回 Result 包装类”），它按约定生成代码。
4. 写完代码后，让它用项目已有的测试框架补测试用例。
5. 如果有数据库操作，通过 MCP 让它直接查表结构，验证字段是否正确。
6. 最后让它跑一遍 lint 和测试，把报错信息丢回去，循环修复。

这套流程看起来不复杂，但每一步都有对应的配置和工具支撑。比如第 2 步需要你引导它读文件，第 3 步需要你把项目约束写清楚，第 5 步就依赖 MCP 的正确配置。把每一环都串起来之后，Clauude Code 才真正像一个“干活的”，而不是“聊天的”。

2. 环境搭建：从头装好 Claude Code

2.1 安装方式与版本选择

先说安装。Clauude Code 目前的主流使用方式是命令行工具，它给你提供了一套交互式的 CLI，可以独立在终端里用，也可以通过 VS Code 插件获得图形界面。安装方式本身并不复杂，主要取决于你本机的环境。

如果你用的是 macOS 或者 Linux，最常见的安装命令是：

npm install -g claude-code

Windows 用户需要注意一点：尽量用 PowerShell 或者 WSL 来执行安装操作。很多人习惯打开 CMD 敲命令，但 Clauude Code 的官方安装脚本和交互式终端在 PowerShell 下的兼容性明显更好，如果用的 Windows Terminal 搭配 PowerShell 7，基本不会遇到奇奇怪怪的问题。

先检查一下 Node.js 版本，Clauude Code 对 Node 版本有最低要求，建议至少 18 以上：

node -v npm -v

版本这块，我的建议是不要盲目追新。Clauude Code 的更新频率很高，新版本通常带来新功能，但也可能引入一些回归问题。如果你主要用它在现有项目上干活，稳定压倒一切。我的习惯是用 npx 指定版本或者通过 npm 固定版本号，而不是每次都要最新。

另外，Clauude Code 还有桌面版（Desktop）的形态，适合不习惯命令行的人。桌面版本质上是把 CLI 包了一层图形外壳，核心能力是一样的。我的建议是：如果你要深度参与代码库的读写，CLI 的效率更高；如果你只是偶尔问几个问题、看看代码解释，桌面版更方便。

2.2 VS Code 集成与 Ollama 本地模型接入

装好 CLI 之后，大多数人会立刻打开 VS Code，搜索“Claude Code”插件。VS Code 里的 Clauude Code 插件本质上是把终端里的对话搬到了侧边栏，同时会自动读取当前打开的工作区作为上下文，这点比纯命令行方便很多，不用手动 cd 目录了。

不过这里有一个关键点：如果你用的是海外大模型的 API，就直接用官方认证方式登录即可；如果你想接入本地模型，比如 Ollama 拉下来的 Qwen、Llama 或者 DeepSeek 的本地版本，那就需要用环境变量或者配置文件把模型的 API 地址指到本地服务。

我在本地经常用这一套组合：Clauude Code + cc switch + Ollama。cc switch 是一个第三方的模型配置切换工具，它可以让你在不同模型服务之间快速切换，不用每次改环境变量。配合 Ollama 启动本地模型之后，只要保证 Ollama 的 API 地址（默认是 http://localhost:11434）和模型名称正确，Clauude Code 就能以“本地模型”的方式工作。

一个典型的本地模型接入配置片段长这样：

export ANTHROPIC_BASE_URL="http://localhost:11434" export ANTHROPIC_MODEL="qwen2.5-coder:7b"

但要注意，不是所有模型都能直接兼容 Clauude Code 的 API 格式，实测下来，支持 Anthropic API 格式的模型接入才顺畅。如果你的模型不在支持列表里，可能要在 Ollama 侧做一层接口转换，或者改用兼容层工具来适配。

2.3 配置保存与多模型切换

配置串起来之后，下一步就是“多模型切换”的问题。我日常会在“云端 Claude 模型”和“本地小模型”之间反复横跳：

• 处理复杂架构设计、大规模重构、写单元测试时，用云端模型，质量高但费 token。
• 处理格式化、变量重命名、简单脚本生成时，用本地小模型，免费且响应快。

每次手动改环境变量显然不现实，这时候 cc switch 就派上用场了。你可以在它的配置里预置多套环境，每个环境对应不同的 API 地址和模型名。切换的时候，一条命令就把当前终端环境切到目标模型，Clauude Code 不需要重启，直接按新的配置发请求。

有个小坑要提醒一下：cc switch 本质上是修改当前 shell 的导出变量，如果你在 VS Code 的集成终端里用，而 VS Code 的插件进程不是从这个 shell 启动的，那插件侧可能仍然读不到最新的环境变量。解决办法是切换完模型后，重开一个 VS Code 窗口，或者在插件设置里手动指明模型服务地址。

3. 核心玩法：Skills、MCP 与上下文管理

3.1 Skills：把常用操作固化下来

说到 Clauude Code 系列里最值得投资时间的功能，我首推 Skills。你可以把它理解成给 Clauude Code 定义的“专用技能包”：每次你提供一个指令或开关，它会按照你预设的流程去执行多步操作，而不是单纯地“问一句答一句”。

举个实际场景。我经常要新增一个后端接口，步骤永远是：创建 Controller、创建 Service、创建 ServiceImpl、创建 Mapper、写一个基础单元测试。以前我每次都要口头把这五个步骤重复一遍，后来我写了一个名为add-api的 Skill，把这一段流程固定成了模板：

1. 读取项目现有的 Controller 命名规范。
2. 生成带注释的 Controller 代码。
3. 生成对应的 Service 接口和实现类。
4. 生成 Mapper 接口，并扫描对应的 XML 文件路径。
5. 生成一个冒烟测试，确保接口能跑通。

这样只需要对 Clauude Code 说一句“add-api 订单 取消订单”，它就会自动执行整个流程。这里用到了 Clauude Code 的官方 Skills 文档里提到的规则文件机制，把流程说明、文件模板、校验规则放在一个目录里。写一次，长期复用。

3.2 MCP：让 Clauude Code 连接外部工具

Skills 处理的是“内部流程”，MCP（Model Context Protocol）处理的则是“外部连接”。通过 MCP，Clauude Code 可以读取本地文件、操作数据库、读写外部 API，相当于给它装上了“手脚”。

我自己用得最多的是数据库读取。以前写代码的时候，遇到字段名不确定，得自己去数据库客户端查表结构，来回切换非常费时间。现在我在 Clauude Code 的配置里加了一个 MySQL MCP Server，它就可以直接执行只读 SQL，把表结构、索引、样例数据拿到上下文里来。比如我问它“订单表里表示状态的是哪个字段”，它会自动去查 information_schema，然后告诉我答案，完全不用我手工切窗口。

MCP 的配置通常在.mcp.json或者全局配置里设置。一个最小的 MCP server 配置长这样：

{ "mcpServers": { "mysql-reader": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-mysql"], "env": { "MYSQL_HOST": "127.0.0.1", "MYSQL_PORT": "3306", "MYSQL_USER": "root", "MYSQL_PASS": "yourpass", "MYSQL_DB": "yourdb" } } } }

注意，MCP 的连接串会暴露数据库地址和账号信息，生产环境的库不要乱接，建议只读账号加内网地址。这个安全意识要有。

3.3 对话历史保存与上下文相关性

很多人问 Clauude Code 怎么保存对话历史。它默认是会保存的，通常存放在用户主目录下的一个 jsonl 文件中，每次会话都会追加记录。如果你在 VS Code 插件里操作，侧边栏一般会有历史会话入口。

但“保存”和“有用”是两回事。实际用下来，Clauude Code 对上下文的处理比普通聊天工具更智能，它会自动裁剪过长的旧消息，保留与当前任务最相关的部分。不过这个自动裁剪有时候也会不太聪明，比如我做大规模重构时，前面定义的关键约束可能被它忘掉。

我的实践经验是：重要约束不要只放在对话里，也要写进项目里的CLAUDE.md文件。Clauude Code 在启动时会自动读取这个文件作为长期上下文，这比“反复在对话里重申”可靠得多。把项目规范、技术栈、目录结构、常见陷阱写进去，每次会话都能保持一致的行为风格，省 token 也省心。

4. 模型选型：Claude Code、Codex 与省钱技巧

4.1 Claude Code 与 Codex 的核心差异

只要你在社区里逛一圈，肯定能看到大家在争论“选 codex 还是 claude code？”这类话题。作为一个两边都深度用过的人，我的体感是：它们各有侧重，不能简单地说谁比谁强。

Codex 更像是“面向工程的 Copilot 模式”，它擅长在已有代码库中做修补和快速生成代码片段。Clauude Code 则更强调“任务级代理”，你可以给它一个比较大的目标，比如“重构整个模块”，它能拆解步骤并逐步完成。换句话说，Clauude Code 偏“项目经理+程序员”，Codex 偏“结对程序员”。

此外，两者对消费模式和上下文管理差异也很大。Clauude Code 更依赖长上下文的窗口，适合做跨文件的分析与修改；而 Codex 的交互更偏向短对话、快反馈。如果你希望一个工具能“理解整体再动手”，Clauude Code 更顺手；如果你只是要补几个函数、修几个 bug，Codex 可能更轻量。

4.2 省 Token 的实操技巧

很多人关心 Clauude Code 如何用省 token，因为费用确实是个现实问题。我在长期使用中摸索出几个有效的方法：

• 不要让它在对话里频繁输出无关解释。在配置里开启“简洁模式”或直接要求“只输出代码和必要说明”，能省不少 token。
• 利用CLAUDE.md把项目背景固化，减少每次对话重复交代上下文的开销。
• 优先在本地用小模型处理简单任务，把云端大模型留给复杂问题。
• 大段无关文件不要全丢给上下文，用 Clauude Code 的“文件选择”或“目录排除”功能，只让它读必要的文件。

还有一个容易被忽略的技巧：当你要让 Clauude Code 修改多个文件时，尽量在一个任务里说清楚，而不是分多条消息逐步补充。因为每补充一次，它都要重新读一遍当前相关的文件列表，token 消耗自然就上去了。

4.3 接入 DeepSeek 与第三方模型

除了官方模型，现在很多人也在尝试把 Clauude Code 接到 DeepSeek 等第三方模型上。接入方式其实和 Ollama 类似，都是通过修改ANTHROPIC_BASE_URL指向目标服务的兼容接口。

不过要注意，不同第三方模型对工具调用（function calling）的支持程度参差不齐。Clauude Code 的很多高级能力，比如自动读写文件、执行命令，都依赖模型的工具调用能力。如果接入的模型不擅长这个，Clauude Code 就会频繁地“问你要权限”或者干脆不会操作文件。所以我的建议是：第三方模型适合做辅助验证、代码解释、简单生成，关键的重构任务还是交给对工具调用支持更好的模型。

5. 常见问题与排查技巧实录

5.1 安装与登录类问题

Clauude Code 在 Windows 上最典型的报错，就是 PowerShell 安装时报错。常见的原因有两个：一是执行策略限制了 npm 全局脚本的运行；二是环境变量Path没有包含 npm 的全局目录。解决办法是先在 PowerShell 里放开当前用户的执行策略：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

然后确认 npm 全局路径是否在环境变量里。如果报错信息里有EACCES之类的权限提示，大概率是 Node.js 安装权限的问题，建议用nvm这类版本管理器装 Node，避免直接装在系统目录下。

另一个频发的问题是登录返回 403。这个一般不是密码错误，而是网络出口 IP 触发了风控，或者是使用了一些不常见的代理节点。优先检查当前网络出口是否稳定，其次确认系统时间是否正确——时间偏移严重时，OAuth 签名校验过不了，也会报 403。

5.2 配置与兼容类问题

接入 Ollama 时，很多人会遇到“模型不认识”的报错。比如，消息里写着glm-5.2 is not a model this version of Claude Code recognizes.这种提示。这个报错的意思是当前 Clauude Code 版本的内置模型列表里没有这个名字，并不代表模型本身有问题。解决办法是检查环境变量里是不是写错了模型标识，或者当前版本是否支持自定义模型名。

如果报错出现在 VS Code 插件里，而终端里能正常工作，问题通常出在插件读不到当前 shell 的环境变量。我在前面提到过，这时候请重开窗口，或者手动在插件设置里指定模型服务地址。

还有一个常见的乱码问题。Windows 环境下，Clauude Code 输出中文偶尔会乱码，多半是代码页不对。可以在 PowerShell 里临时切到 UTF-8：

chcp 65001

或者在启动 Clauude Code 前设置PYTHONIOENCODING（如果你在配合 Python 脚本使用的话）。这个坑虽小，但出现时非常影响心情。

5.3 使用中的独门避坑经验

最后分享几条从实际项目中攒下来的经验。

第一，Clauude Code 不是搜索引擎。它会非常自信地生成答案，哪怕这个答案是错的。凡是它给出的 API 用法、依赖版本、配置项，都要以官方文档为准。我上过当，有一次它让我安装一个并不存在的 npm 包名字，浪费了半个小时。

第二，注意上下文污染的连锁反应。如果你让它读了一个与任务无关的大文件，它可能会被无关信息“带偏”。在实践中，我会先用精简命令让它列出项目文件树，确认范围后再让它读取具体文件。

第三，用好/compact这类命令。长对话之后，Clauude Code 的上下文会慢慢变得混乱，此时不要继续硬聊，主动压缩上下文，把已经确定的信息重新整理给它，效果往往比强行延续对话好得多。

第四，weekly limit 的问题。如果你收到了“your limits are temporarily boosted”之类的提示，说明当前账号的周配额被临时调整了。这种情况通常是因为短时间内并发任务太多，或者单日 token 消耗过大。我的经验是：把大任务拆散，分到多天执行，有效缓解配额压力；自建本地模型作为补充，能把日常琐事承担过去。

总的来说，把 Clauude Code 真正“串起来”用，关键不在于记住多少命令，而在于形成一套适合自己项目的协作习惯：用配置固化上下文，用 Skills 固化流程，用 MCP 打通外部数据，用本地模型降低成本，最后用一套可控的排查流程兜底。我在实践中最深的体感是，工具链越完整，它越像并肩干活的同事；而这一切的前提，是把基础环境和配置打扎实。希望这篇文章能帮你少走一点弯路，直接进入“整体串起来”的状态。