企业官网建设流程全解析

最近一个月，我在各种场合反复收到同一个问题：安装会了，CLAUDE.md 也会写了，MCP 也配上了，但真让自己手里的项目完整跑一遍，总觉得发虚。这问题问得很准。前面系列文章陆续把安装、配置、记忆文件、工具扩展、子代理这些环节一个个拆开讲过，但它们更像是一堆零件——拆开了都认识，拼起来才知道哪儿该咬合、哪儿该留缝。这也是我把第 12 篇主题定为“整体串起来”的原因。这篇不做新功能介绍，只做一件事：把从环境准备到日常交付的完整链路重新走一遍，把那些分散的知识点串成一条可以照着执行的路。适合两类人：一类是刚装好还没真正跑起来的新手，另一类是已经用了但总觉得工作流卡顿、想整理一遍的老手。

1. 一条主线：从需求到交付，Claude Code 的工作台视角

1.1 三种使用层次，决定你把它当什么工具

在开始串联之前，得先拉出我脑中对这个工具的基本定位：Claude Code 不是一个加强版聊天框，它是一个有工作台属性的编码智能体。同样一个工具，不同人用出来的效果天差地别，根源往往不在模型能力，而在使用层次。

我习惯把使用方式分成三层：

• 提问型：把终端当成搜索引擎，问“这个 API 怎么传参”“这个报错什么意思”，拿到答案就关掉。
• 任务型：给一个明确任务，比如“把登录接口加上参数校验”，它改完代码，人来看结果。
• 托管型：从一句自然语言需求开始，它自己规划步骤、自己读写文件、自己跑命令验证，最后交出一个可直接评审的结果。

这个层次划分不是用来搞笑的，它直接决定了你需要在配置上投入多少精力。如果你只是提问型用户，CLAUDE.md 写不写、MCP 配不配、上下文怎么压缩，这些优化做不做都无所谓，反正每次会话都很短。但如果你想进入托管型工作流，前面文章里讲的记忆文件、工具权限、子代理、成本控制，全都不是可选项，而是基础设施。后面所有串联动作，其实都是在为托管型工作流服务。

1.2 主链路解构：每个环节都对应一个“零件”

我梳理 Claude Code 日常使用时，心里装着的是一条固定链路：会话启动 → 加载项目记忆 → 理解需求 → 拆解步骤 → 调用工具执行 → 校验结果 → 人工审查 → 收尾交付。这条链路一旦跑顺，它就像一个稳定的流水线，而不是一堆随时需要救火的单点功能。

这个顺序不是我拍脑袋定的，而是有先后依赖的。比如“加载项目记忆”必须排在“理解需求”前面：如果一个 AI 连项目用什么包管理器、代码放在哪个目录、有没有既定规范都不知道，你让它去改代码，它只能靠猜，而猜的结果就是给你写出一堆“看起来能跑但完全不符合项目风格”的代码。以前有很多读者来问“为什么我的 Claude Code 总是不听话”，排查到最后，八成是记忆文件没建，或者建了但没维护。

1.3 走一遍最小闭环：给博客加一个字数统计命令

链路光说理论不直观，我拿一个最小例子完整走一遍。假设你有一个 Hexo 或 VitePress 博客项目，需求只有一句话：“我想加一条命令，统计所有文章的单词数。”

用 Claude Code 从头走一次，整个流程是这样：

第一，在项目根目录启动会话。它启动后会先扫一遍当前目录，看到 package.json、README、docs 目录，大概判断出这是个静态博客项目。第二，它读 package.json，发现项目用 npm 管理脚本，scripts 下还没有 word-count 相关命令。第三，它发现这个仓库没有 CLAUDE.md，于是主动问你“要不要初始化项目记忆文件”。你同意之后，它生成一份初始的 CLAUDE.md，里面记录项目类型、目录结构、常用命令。第四，你再说一次需求，它这次不会再问“你的文章放在哪”，因为记忆文件里已经有答案。它开始拆解步骤：写一个 Node 脚本遍历 docs 目录、统计每个 Markdown 文件的词数、在 package.json 里注册命令。第五，它创建 scripts/count-words.mjs，然后请求在终端里执行 node scripts/count-words.mjs，验证输出结果。第六，你审查 diff，觉得输出格式不够好看，让它把结果按文章标题排序，它改完再跑一次，通过。第七，收工。

这段流程里的每一步单独拎出来都不稀奇，但组合在一起就有意思了：记忆文件负责“少解释”，工具调用负责“能动手”，终端执行负责“自验证”，人工审查负责“质量关”。整个过程中，人没有写过一行代码，但每一行代码都经过人的确认。这就是“整体串起来”和“一个个功能分开用”的本质区别——分开用的时候，它是问答工具；串起来的时候，它是一个能交付结果的协作者。

2. 环境端到端打通：安装、认证、模型路由的常见卡点

2.1 三个安装入口，Windows 与 Linux 的踩坑记录

先说安装。Claude Code 现在有 CLI、VS Code 插件、桌面版三个入口，三者共享账号体系，配置也基本互通。CLI 是根本，推荐所有用户先装它：

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

Linux 和 macOS 上这条命令基本一次过，真正麻烦的是 Windows。我踩过两个坑，都是新手高频问题。

第一个是 PowerShell 执行策略报错。npm 全局装完之后，输入claude提示“无法加载文件，因为在此系统上禁止运行脚本”。这不是 Claude Code 的问题，是 Windows 默认执行策略限制了脚本运行。解决办法是给当前用户放开权限：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned的意思是：本地写的脚本可以跑，从网络下载的脚本必须有签名。这是 Windows 下的安全折中方案，不建议直接设成Unrestricted。

第二个是中文乱码。Claude Code 在 Windows 终端里输出中文时偶尔会出现乱码，尤其是用默认的 conhost 终端时。常见解法是切换到 Windows Terminal，并把终端的编码设成 UTF-8，或者在老终端里先执行chcp 65001再启动。这个问题的根源是旧终端默认代码页不是 UTF-8，Claude Code 的输出按 UTF-8 编码后，终端按 GBK 解码，自然就花了。

2.2 登录返回 403 的排查链路

“登录返回 403”是新手期出现频率最高的异常之一。我第一次遇到时也愣了一下，因为我确认账号密码没问题。后来排查多了，发现 90% 的 403 和密码无关，而是本地认证状态出了问题。

常见的三个诱因：一是浏览器端登录态过期了，但 CLI 本地缓存里还存着旧凭据；二是多账号切换时，旧凭证文件没清干净；三是系统时间偏差，导致 token 校验失败（这个最隐蔽，但最容易排查）。

我推荐的排查顺序：

1. 先跑claude doctor，能显示当前认证状态和配置文件路径。
2. 退出当前登录：claude会话里执行/logout，或者直接删掉本地凭据缓存目录（位置可以用 doctor 查到）。
3. 校准系统时间，确认时区和网络时间同步。
4. 重新执行claude，走一遍浏览器授权流程。

这里有个关键提醒：如果授权页转圈卡住，不要疯狂刷新页面。你每刷新一次，就可能产生一次新的回调请求，反而容易造成状态错乱。正确做法是：等 30 秒，如果还没有跳转，就关掉整个流程，清凭据，重来一次。

2.3 模型路由：官方、本地 Ollama、DeepSeek 怎么选

默认情况下 Claude Code 连的是 Anthropic 官方模型。但很多人不知道，它的模型接口做成了可替换的抽象层，也就是说，你可以不换工具链，只换底层模型。这也是“模型路由”这个概念能成立的原因。

三种底座的选择逻辑：

• 官方 Claude 模型：综合能力最强，尤其在复杂多步任务、长上下文理解、工具调用稳定性上表现最好。代价是费用高，适合正式项目开发。
• 本地 Ollama：完全离线、隐私可控、不花 API 费用，但能力上限取决于你的显卡和选用的模型。适合处理简单任务、敏感数据、实验性验证。
• DeepSeek 等第三方 API：成本和质量取中间值，通过兼容接口接入后，日常开发完全够用，偶尔需要人工修正一些细节。

配置方式是在项目.claude/settings.json里加环境变量：

{ "env": { "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic", "ANTHROPIC_AUTH_TOKEN": "你的 API Key" } }

ANTHROPIC_BASE_URL的作用是把请求地址指到第三方服务上，ANTHROPIC_AUTH_TOKEN换成对应的 Key。换完之后不需要改任何调用代码，MCP、Skills、子代理照常工作。这也是我推荐“底座可换、工具链不变”这套思路的原因——你换的是发动机，驾驶舱不用重新学。

2.4 cc-switch：多套配置一键切换

当你有两套以上模型配置时，手动改环境变量就变成了一场灾难。我今天用官方，明天想切本地，总不能每次改完再重启一遍。cc-switch 解决的就是这个痛点。它本质上是个配置管理工具，把不同模型的 API 地址、Token、模型名称、环境变量打包成 profile，切换时一键生效。

我在本机维护了两套 profile：一套指向官方模型，处理正式开发；一套指向本地 Ollama，处理隐私分析和草稿代码。切换过程就是启动 cc-switch、选 profile、重启 Claude Code，整个过程不到十秒。有一点需要提醒：cc-switch 是社区工具，不是官方出品的，升级 Claude Code 后如果出现配置不生效，优先检查工具本身的版本兼容性，而不是立刻怀疑配置写错了。

3. 项目工作流串联：让 Claude Code 像一个真正的结对程序员

3.1 把 CLAUDE.md 写成团队的交接文档

CLAUDE.md 是整个工作流里最重要的一个文件，没有之一。它会在每次会话启动时被加载，相当于给 AI 的一份项目交接文档。它写得好不好，直接决定 AI 后续所有动作的质量。

我见过两类极端：一类是完全不写，AI 每次都在猜项目背景；另一类是写了三千字，把 AI 的上下文窗口塞得满满当当，结果它抓不住重点。正确的做法是克制地写，只记录高频事实。这是我的最小模板：

# 项目简介 一句话说明这个项目是什么。 # 常用命令 - 开发启动：npm run dev - 构建：npm run build - 测试：npm run test - Lint：npm run lint # 目录结构 src/ 源码 scripts/ 工具脚本 docs/ 文档 # 代码约定 - 组件命名用 PascalCase - 提交信息用 conventional commits - 禁止在业务代码里写 console.log # 已知问题 - 旧版构建脚本有缓存 bug，改完代码先清缓存再验证

这个模板不超过 60 行，但已经覆盖了 AI 每天最高频需要知道的信息。建议先用/init让它自动生成一份初稿，再人工修剪。自己从零写容易漏，让它先写你再改，效率高得多。

3.2 MCP 与 Skills 的配合方式

MCP 和 Skills 这两个功能经常被混在一起说，但它们的定位完全不同。MCP 是连接器，负责让 Claude Code 获得访问外部数据和系统的能力；Skills 是操作姿势，负责把重复性的动作固化成固定流程。

举一个具体场景：假设你要查数据库里重复的手机号。

没有 MCP 的时候，你得自己打开数据库客户端，写 SQL，把结果导出，再贴给 AI 分析。有了 MCP，你只需要说“查一下 user 表里手机号重复的记录”，它会自动连接数据库、列出表结构、写 SQL、执行查询，然后分析结果。MCP 的价值在于：它让 AI 不再“眼瞎”，能直接看到数据本身。这一点非常关键，因为很多任务的最大阻力不是写代码，而是“获取数据”。

Skill 则适合固化“应该怎么做”。比如“提交前自检”这个动作，可以封装成一个 skill：让它跑 lint、跑测试、检查 diff 里有没有调试日志、确认提交信息符合规范。每次提交前手动执行一次，它就按固定顺序跑完整套检查，不会漏项。简单来说，MCP 解决“能做什么”，Skill 解决“把事情做对”。

3.3 子代理并行改造的拆法

当任务大到一定程度，单线程的对话模式会变得很慢，这时候就该用子代理做并行处理。这个功能在重构多文件项目时特别好用，用好了效率翻倍，用不好则会制造冲突。

我踩过一个很典型的坑。有一次想把一个旧项目里的工具函数从utils.js拆到多个模块，我让两个子代理分别处理 A 模块和 B 模块，结果两个代理都去改了入口index.js，一个改了导出，一个加了引用，最后生成的文件直接合并冲突。

从那以后我总结出一条拆任务原则：不能只按“文件”分，还要按“依赖关系”分。正确做法是先让主代理完成共享文件的改造（比如入口文件的导出逻辑），再让子代理并行处理叶子文件（比如每个工具函数模块），最后再由主代理统一收口。拆任务时先花两分钟画出依赖关系，比事后处理冲突省一小时。

3.4 人机协同的检查点设置

Claude Code 默认不是“无人驾驶”，虽然提供了跳过确认的选项，但我强烈不建议在正式项目上开启。你要把它当成一个能力强但需要方向感的下属，而不是一台不需要监督的机器。

我在实际使用中维护这三条纪律：

• 文件读写和终端执行保持逐次确认，不设置全局允许。
• 不允许它自动操作 git push、发布、删除分支这类有外部副作用的动作。
• 连续改动超过 10 个文件或 300 行时，停下来完整审查一次 diff。

这个节奏看似增加了手动操作，实际上是在控制风险桶的大小。AI 写代码的容错率远高于人类，但它一旦方向错了，连续错误会迅速累积。人工在各个关键节点做一次方向纠偏，比相信它全自动跑完更安全，也更省 token。

4. Token 消耗控制：从“能跑”到“省着跑”

4.1 Token 到底耗在哪

很多人对 token 消耗有误解，以为“我没让它写多少代码，怎么就用掉这么多”。但 Claude Code 的费用大头从来不是输出，而是输入。你让它分析一个仓库，它要读取文件内容；你让它调试报错，它要把完整日志读进上下文；你每提一个问题，之前所有对话历史都要重新计算一遍。输出可能只有几百行代码，但输入累积起来轻松超过几万 token。

我观察过一个典型案例：一次简单的功能开发，表面上只写了 100 行代码，实际上消耗了 120k token。拆开看，一半是闲聊式的对话历史，四分之一是工具返回的长文本，真正有用的输出只占很小一部分。理解了这一点，省钱的核心思路就清晰了：压缩输入，而不是压缩输出。

4.2 几个实测有效的手段

以下手段我都亲测过，不涉及任何魔法，纯粹是工程习惯的调整：

1. 瘦身 CLAUDE.md：只保留高频事实，删掉解释性废话。500 行记忆文件每次会话都吃进上下文，累积成本非常可观。
2. 限制工具读取范围：能用Read指定文件路径时，就不要让它自己搜索整个仓库。搜索范围越大，读进去的无用内容越多。
3. 长对话及时/compact：当对话进行到二三十轮以上，上下文已经很臃肿，/compact可以把历史总结成精华，重新开始，但保留关键信息。
4. 一件事一个会话：做完一个功能就结束会话，下次启动新会话。这样避免历史垃圾持续污染后续请求。
5. 大数据工具结果截断：数据库查询结果、测试日志这些内容，能只看摘要就不看全量，要求 AI“只返回前 20 行”就够了。
6. 简单任务切到本地或第三方模型：不需要顶级模型的任务，换底座能省一大笔费用。

这六条组合使用下来，我个人的单次开发成本大约能压缩到原来的三分之一左右。其中最立竿见影的是第 4 条，几乎零成本，效果最明显。

4.3 限流提示的误解与应对

很多人在使用过程中会看到类似 “your limits are temporarily boosted. your weekly Claude Code limit is 50% higher” 的提示，第一反应是“我是不是被降级了”，其实不是。这个提示恰恰相反：它是在告诉你，本周用量上限被临时提升了 50%。

但这件事还有另一面。你会看到这个提示，说明你在这个周期内已经用到了接近原上限的规模。换句话说，提示本身在暗示你：是不是该控制使用粒度了。如果频繁看到这类提示，正确做法不是等额度恢复，而是停下来检查近期的会话记录，看哪些对话是可以被拆掉、压缩或者换到本地模型处理的。限流从来不是靠手速解决的，是靠单次请求的价值密度解决的。

4.4 三种模型底座的成本实测对比

三种底座的体验差异，我用一张表列出来，基于我自己的实际使用感受：

我现在的组合策略是：复杂逻辑、跨模块重构用官方模型；日常增删改查、数据分析用第三方 API；涉及密钥、未发布业务逻辑的实验用本地模型。同一个项目里按任务切换，既保质量又控成本，运行成本大约能比全程官方模型降低一半以上。

5. 多端协同与团队落地：三种入口各有各的活，选型别纠结

5.1 CLI、VS Code 插件、桌面版的分工

Claude Code 的三种入口形态，不是简单的功能重复，而是各有侧重。我现在每天三个都在用，它们在我工作流中的分工是这样：

CLI 是速度型。它启动最快，适合跑一次性脚本、批量处理文件、在服务器上远程操作。我在 SSH 到开发机时用的就是 CLI，完全不需要图形界面。

VS Code 插件是审查型。它和编辑器深度集成，左边是对话面板，右边是代码 diff，适合日常开发场景。写代码、看改动、回滚，都在同一个窗口里完成，上下文切换成本最低。

桌面版是配置型。它把 MCP 管理、模型配置、对话管理做成了可视化界面，适合新手熟悉功能，也适合做环境初始化。我一般用桌面版完成配置，然后用 CLI 和 VS Code 插件进行日常开发。

三者共享账号和配置，不存在“我在 CLI 里配置的东西插件看不到”这种问题，切换起来没有额外负担。

5.2 桌面端登录卡住的排查步骤

桌面版最常见的异常是“卡在登录账号界面”，点了登录，浏览器里授权也完成了，但桌面版就是没有任何反应。这个问题我在自己机器上遇到过两次，根源基本都是本地登录状态冲突。

原因是这样的：Claude Code 的 CLI 和桌面版共享一套认证体系，但桌面版自己还会维护一份本地登录状态。如果你之前用 CLI 登录过，桌面版的本地状态又因为异常变成了半成品，它启动时就会一直等着那份半成品状态完成登录，于是卡死。

解决步骤按顺序做：

1. 完全退出桌面版，包括系统托盘里的进程。
2. 打开本机的用户配置目录，删除与 Claude Code 登录状态相关的缓存文件（不确定位置就先备份整个目录再删）。
3. 重新启动桌面版，走一遍登录流程。

有一点很重要：清缓存之前先备份，因为你同时可能会把 MCP 配置一起删掉。我第二次遇到这个问题时学乖了，只删认证相关文件，保留配置目录。这个细节能帮你省下重新配置所有 MCP 的时间。

5.3 把配置纳入版本库，让团队五分钟上手

如果你要给团队推广 Claude Code，最有效的一件事不是写长篇文档，而是把配置放进 git 仓库。一个项目 clone 下来，新人第一分钟就能让 Claude Code 按团队约定工作，这才是真正的零成本上手。

我推荐的最小仓库结构：

.claude/ settings.json skills/ CLAUDE.md

.claude/settings.json放项目级环境变量、权限配置；skills/放团队共享的 Skill 定义；CLAUDE.md放项目规范和约定。团队模板和个人模板有一个重要区别：团队版要写“规范”，不要写“情绪”。比如“禁止在业务代码里写 console.log”，这是规范；比如“这个项目的历史包袱很重，改的时候要小心”，这种模糊描述只会让 AI 无所适从。

5.4 Codex 与 Claude Code 选型：先看链路再看单点

搜索热词里频繁出现“选 codex 还是 claude code”的争论。站在实际使用者的角度，我觉得这类对比容易让人陷入单点跑分的误区。

我的观点很直接：工具选型不应该只看“谁更强”，而应该看“哪条链路更容易在你手里跑通”。如果你的项目里 MCP 生态已经积累了很多外部数据源，那 Claude Code 更顺手；如果你只需要一个开箱即用的助手，另一款可能更省心。我自己是两套并存：Claude Code 作为主工作流，另一款在部分场景做对比验证。真正决定生产力的，是你能不能用一条完整的链路把它串起来，而不是单点功能的纸面对比。

写到最后想多说一句。前 11 篇写下来，我花了很多时间研究单个功能——这个命令怎么用、那个配置怎么写，像是集邮。但真正让效率有质的提升，是这次“整体串起来”之后的事：从安装到交付，中间每个环节都清楚下一步该做什么，整个过程不再需要反复查资料。如果你也想达到这个状态，我的建议很简单：别想着一次配到完美，就挑这个周末的一个小需求，强制自己用 Claude Code 从头到尾走完一遍——装好、登录、建记忆文件、让它改一个真实的功能、审完 diff、提交。第一遍一定会有卡顿，甚至想放弃，但跑完这一圈，你对它的掌控感会完全不同。这比连续看十篇文章都管用。