企业官网建设流程全解析

说句得罪人的话：Claude Code都火到 2026 年了，我见很多人的插件列表还停在“装了个寂寞”的阶段。有人一口气装了二十几个扩展，真正天天用的不超过三个，剩下全是心理安慰。为什么这样？因为不少人是拿 VS Code 那套“装完即生产力”的思路来套 Claude Code，但这套逻辑在 Claude Code 身上基本不成立——它的扩展形态是 Skills、MCP、Hooks、Commands 这些完全不同的东西，选错了、装多了，不但不省事，反而拖慢启动、干扰上下文、白白烧 Token。这篇文章就把我在真实项目里反复试过、留下来长期在用的 9 款整理出来，顺便把安装配置过程中的坑也讲清楚，让你看完就知道该装什么、不该装什么。

1. 先搞明白：Claude Code 的“插件”和 VS Code 根本不是一回事

1.1 Claude Code 扩展体系的四大件

很多人第一次接触 Claude Code，会下意识去找“插件市场”，然后发现官方并没有一个像 VS Code 那样点一下就能装的图形商店。Claude Code 的扩展能力，实际由四套机制加上一批周边管理工具共同组成，理解错这个底层结构，后面装什么都容易白装。

第一套是 Skills，也就是技能。它的形态是把一段复杂任务的执行流程写成SKILL.md，放在项目目录.claude/skills/或者用户目录~/.claude/skills/下面。Claude 在对话中会根据任务描述自动匹配并加载这些技能，或者你也可以用@技能名手动强制触发。它解决的是“知道怎么做，但每次都要重新啰嗦一遍”的问题，本质上是把团队的最佳实践沉淀成可复用的操作手册。

第二套是 MCP，Model Context Protocol。这是 Anthropic 主导的开放协议，相当于给 Claude 接上外部工具的 USB 口。通过 MCP server，Claude 可以读文件系统、操作浏览器、访问数据库、调 GitHub API。相比 Skills，MCP 更偏“执行能力”，而 Skills 更偏“做事流程”。

第三套是 Hooks，钩子。它允许你在 Claude Code 生命周期中的特定节点插入自定义脚本，比如在调用工具前（PreToolUse）、工具调用后（PostToolUse）、会话停止时（Stop）执行检查。翻译成人话就是：你可以让 Claude 在准备执行某个危险命令之前，先跑一遍你的校验脚本。

第四套是 Slash Commands，斜杠命令。这些自定义命令放在.claude/commands/目录下，是帮你把高频操作压缩成一个斜杠词，比如/review、/commit、/release。它和 Skills 的区别在于，Commands 通常只做简单直接的“触发动作”，Skills 则是一套带多步骤判定逻辑的完整流程。

再加上 CC Switch 这类周边管理工具，就构成了一个完整的 Claude Code“插件宇宙”。所以别再拿 VS Code 的经验来套它了，搞清楚这四件套的分工，再谈安装什么才有意义。

1.2 为什么 2026 年插件生态成了 Claude Code 真正的分水岭

这两年基座模型的能力已经卷到一个挺高的水位，单纯比“谁写代码更聪明”，头部模型之间的差距在缩小。真正把使用体验拉开差距的，是工程化的东西：谁能把模型的输出接入到团队现有的代码审查流程里？谁能让它自动遵守项目里的安全规范？谁能让一个大型重构任务被拆分成多个并行子任务而不是单线程死磕？

这些都是模型本身做不到的，要靠外围的扩展体系来完成。所以你会看到，同样用 Claude Code，有人用得跟个高级聊天框一样，而有人已经让它在 CI 流程里自动跑测试、自动生成变更说明、自动提交 PR。区别不在模型，在扩展生态的搭建水平。2026 年，插件和工具链的配置能力，才是 Claude Code 使用者的真正分水岭。

2. 我筛选 Claude Code 扩展的三个标准：不省时间就是负资产

2.1 三个问题

市面上打着“增强 Claude Code”旗号的工具越来越多，GitHub 上随便一搜都是几百个项目。怎么筛？我有一套自己的标准，就三个问题，回答不上来的一律不装。

第一个问题：它解决的是真实痛点，还是为了让你显得专业？比如你每天压根不碰浏览器自动化，那装个 Playwright MCP 除了增加启动时间和上下文混乱，没有任何好处。真正值得装的工具，一定对应着你周工作中反复出现的动作：切换模型供应商、跑测试、生成提交信息、检查敏感信息泄露。

第二个问题：学习成本在不在可接受范围内？一个扩展如果配置要改五个文件、还要自己编译、还要维护环境变量，那除非它能帮你省下每天一小时以上，否则不值得。我见过不少人的插件装完就没打开过研究文档，最后变成纯占地盘。

第三个问题：维护风险是多高？Claude Code 版本迭代非常快，第三方扩展很容易跟不上。我的原则是：能用官方机制解决的，优先用官方机制（Skills、Hooks、Commands 都是官方能力，不依赖第三方项目存活）；必须用第三方的，选 star 数量够高、更新频次够稳定的。

2.2 我劝你别装的那些“伪生产力”扩展

有几类东西我看着就头大，真诚劝你别装。第一类是“大而全工具箱”，宣称一个扩展搞定文件、数据库、浏览器、邮件、日历，实际每个功能都是半吊子，启动一次还要拉一堆依赖，拖慢整个会话响应。第二类是纯界面美化工具，给终端加花里胡哨的仪表盘、状态栏、图表，好看是好看，但 Claude Code 的核心价值是代码上下文流转，不是给你刷视觉存在感。第三类是已经停止维护的老牌插件，你装上它可能只是为了某一个小功能，但它依赖的老接口在新版本里早改了，反而成了报错源。

判断一个扩展是不是“伪生产力”，我有个简单方法：你用两周，记录它真正派上用场的次数。如果两周内使用次数少于五次，那它就是在你的终端里白吃资源，该卸就卸，别心疼。

3. 从安装到长期使用：这 9 款为什么留在了我的终端里

3.1 CC Switch：供应商管理，省心第一名

CC Switch 是一个开源桌面工具，它的核心功能是管理和切换 Claude Code 的 API 供应商配置。我在真实项目里用它的场景很典型：手头同时有官方直连、AWS Bedrock、Google Vertex 几个渠道，不同项目对数据落地的要求不一样，有时候还要切到公司自建的兼容网关。没有 CC Switch 之前，每次切换都要手动改~/.claude/settings.json里的环境变量，还容易改错把后续请求全卡住。

它的使用逻辑很简单，图形界面上维护几套供应商配置，点一下就切换，底层会自动帮你改好配置文件。实际用下来的感受是：这东西帮我省下的不仅是时间，还有“手改配置改出事故”的风险。有一点要提示，切换完之后，最好重新开一个 Claude Code 会话，因为已经启动的会话可能还占着旧的环境变量，这是很多“切完报错”的根源。

3.2 Ollama 本地模型桥接：脱敏场景的 Plan B

Ollama 本身不是 Claude Code 插件，但把它和 Claude Code 组合起来，是我在 2026 年很依赖的一套配置。做法是本地跑一个 Ollama 服务，再通过一层兼容转换（社区里常用 LiteLLM 之类的方式）把它暴露成 Claude Code 能识别的接口，然后在 CC Switch 里加一个指向http://localhost的本地供应商。

先泼盆冷水：本地小模型在代码推理能力上跟 Claude 4/5 这代模型完全不是一个量级，别指望它能替你做架构设计或者复杂重构。它的正确使用场景是：处理敏感代码片段时不想外发、网络不稳定时的应急通道、给 Claude 生成的内容做初步整理和格式化。我个人的用法是，把项目里一些不能出内网的文件，先用本地模型做脱敏摘要，再把干净的版本交给 Claude Code 做深度分析。

3.3 Skills 技能库：把 SOP 焊进 Claude 的工作流

Skills 是我现在最看重的官方扩展机制。以前让 Claude 按团队规范做事，每次都要在 prompt 里重复一大堆约束，后来发现根本管不住，换个人开个新会话就忘了。有了 Skills，我直接把这些规范写成一个SKILL.md，让 Claude 在会话中自动加载。

举个我实际在用的例子，团队做 Python 服务端开发，要求所有新增依赖必须写入pyproject.toml、数据库迁移必须有向下兼容方案、所有对外接口必须带类型注解。这些事情写成 Skill 之后，Claude 在改动相关文件时就会自动遵循这套流程。这个能力用久了会特别上瘾，因为你相当于把团队里最有经验的人的工作习惯复制到了每个会话里。

SKILL.md的结构并不复杂，前面是 frontmatter，写技能名称和触发描述，后面是正文步骤。下面是我一个简化示例的格式：

--- name: python-service-规范 description: 当需要修改 Python 服务的接口、依赖或数据库迁移时使用 --- 1. 先阅读项目根目录的 CLAUDE.md，确认当前技术栈。 2. 新增依赖时必须同步修改 pyproject.toml，并在变更说明里注明原因。 3. 数据库迁移必须提供 rollback 方案，禁止只写 forward。 4. 对外接口必须携带完整类型注解，并在函数 docstring 中标注异常类型。

3.4 MCP 工具集：让 Claude 的“手”伸到浏览器和数据库

MCP 服务器是真正把 Claude Code 从“只会在编辑器里改代码”升级到“能操作真实系统”的关键。我常用的 MCP server 主要是这三个：文件系统 MCP，用来跨项目批量处理文件；浏览器自动化 MCP（比如 Playwright MCP），用来跑前端回归和抓取页面结构；GitHub MCP，用来直接操作 issue、PR、代码搜索。

用得最多的场景是浏览器自动化。以前让我写前端回归测试，得先自己开浏览器、手动点一遍、再写断言。现在我会让 Claude Code 通过 Playwright MCP 自己起浏览器、根据页面文本和元素定位做交互、把失败路径截图回来分析。这已经不是“帮忙写代码”的范畴，而是直接替你把测试跑完了。

这里有一个重要原则：权限最小化。MCP 给 Claude 的权限越大，风险越大。我只会给对应项目的会话挂对应的 MCP server，比如纯后端项目绝不挂浏览器工具，避免模型在上下文混乱时执行了不该执行的操作。

3.5 Hooks 门禁脚本：在犯错之前踩刹车

Hooks 给我的感觉是在 Claude Code 外面加了一道闸门。我最常用的是 PreToolUse 和 Stop 两个节点。PreToolUse 可以在 Claude 准备执行某类危险命令前触发检查，比如拦截git push之前未通过 lint 的情况、拦截在配置文件中写入敏感信息的情况、拦截把大文件提交进仓库的情况。

Stop 钩子则是我用来做“完成自检”的：每当 Claude 结束一轮处理，我会让它自动跑一遍关键命令（测试或构建），如果有失败结果就重新回到任务循环里继续修，而不是假装没事。严格来说这套机制组合了 Hooks 和命令脚本，但它带给我的安全感非常大，相当于给 AI 的行为装了一个自动纠错回路。

下面是一个 hooks 配置的示意结构，实际字段以对应版本的官方文档为准：

{ "hooks": { "PreToolUse": [ { "matcher": "Bash(git push*)", "hooks": [ { "type": "command", "command": "sh scripts/check-before-push.sh" } ] } ] } }

3.6 CLAUDE.md 模板与继承体系：给每个项目装“开机记忆”

CLAUDE.md 不是传统意义上的插件，但它是我认为最值得“配置化”的一项工程。Claude Code 每次启动会自动读取项目根目录的CLAUDE.md和用户目录的~/.claude/CLAUDE.md，把里面的内容作为项目背景。很多人随便写两行就完事，我却把它做成了一个结构化模板，让新项目克隆下来改改参数就能用。

我的项目级模板里固定包含几块内容：技术栈与目录结构说明、常用命令（测试、构建、lint、迁移）、代码规范与禁止事项、常见架构决策背景。这样一来，每个接手项目的 Claude 会话都自带上下文，不用每次从头解释“我们这个项目是什么结构”。团队使用时的效果尤其明显——新同事拉下一个项目，Claude 已经了解项目背景，上手速度明显比过去快。

3.7 Subagents 并行任务编排：让一场大重构变成多条流水线

一个 Claude Code 会话处理复杂大任务时，经常会陷入上下文过长导致的效率下降。我的解决办法是引入 Subagents 并行编排的思路：不指望单个会话一路推进到底，而是把大任务拆成多个边界清晰的子任务，用多个会话并行推进，最后再做整合。

举个例子，一次涉及 40 个文件的跨模块重构，我会先梳理出依赖关系，然后把不互相依赖的几个模块，分给不同的会话并行改。每个会话只加载自己负责模块的上下文，思路清晰很多，改完再统一做集成测试。实际操作中，我会用多个终端窗口或者一个外部脚本同时拉起多个 Claude Code 实例，每个实例指定不同的任务描述和上下文目录。

这个模式的收益不只是“快”，更重要的是每个子任务的质量都更稳。因为上下文变短了，模型跑偏的概率也低了很多。要提醒的是，并行任务的前提是模块边界要真正解耦，否则两个会话同时改同一个文件，合并冲突会教你做人。

3.8 自定义 Slash Commands：把高频操作压缩成一句话

自定义 Slash Commands 是我每天用得最频繁的扩展。它把那些需要重复输入一长串 prompt 的操作，变成了一个斜杠词。我常用的有/review（启动代码审查流程）、/commit（生成规范提交信息）、/release（生成版本变更说明）。

比如/commit，我在.claude/commands/commit.md里写好指令：先执行git diff和git status查看改动，再按团队规范生成一个符合 Conventional Commits 格式的提交信息，最后附上改动摘要。这样每次提交就不用手动复制 diff 再写几百字说明了。

Commands 与 Skills 最大的区别是，Command 就是你主动按下的快捷键，而 Skill 是 Claude 在合适时机自动调用的技能。两者并不冲突，我的使用习惯是：高频的、动作明确的场景用 Command，复杂的、需要自动判断的流程用 Skill。

3.9 /test 自动化回归组合：写完代码立刻自测

最后这一款，是我从“让 Claude 写代码”进化到“让 Claude 对代码负责”的关键一步。Claude Code 内置的/test命令可以自动探测项目的测试命令并执行，但光有这个还不够，我把它和前面说的 Hooks 结合起来：每次 Claude 完成任务停下来之前，自动触发一轮测试，测试失败就自动回到任务循环里继续修。

这套组合拳让“写完就测”从口号变成了默认行为。实际操作中，我会要求 Claude 在最后一条回复里附上测试运行结果，如果没有附，就视为任务未完成。可能有人觉得这样严格了点，但用了几个月之后，我合入主干的代码质量明显上去了，因为大部分低级错误在提交之前就被拦下来了。

4. 那些年我踩过的坑：五个翻车现场与完整排查链路

4.1 CC Switch 切换后忽然无法认证

有一次我在 CC Switch 里从官方直连切到 Bedrock，再切回来，结果 Claude Code 直接报认证失败。当时我第一反应是 API Key 坏了，去官网复制了好几次，折腾半小时都没解决。

后来才意识到问题在配置文件：CC Switch 在切换时会重写~/.claude/settings.json，如果某个供应商的 API Key 字段是空的，或者环境变量里残留了旧配置，就会覆盖掉原本正常的值。排查链路应该是：先看claude doctor或直接打开settings.json确认当前生效的 Key 和 Base URL，再检查 shell 环境变量里有没有ANTHROPIC_API_KEY之类的定义，因为环境变量的优先级通常会覆盖配置文件，最后再考虑是不是 Key 本身失效。从那以后，我每次切换完都会顺手打开配置文件确认一遍环境变量，再新开会话，基本没有再犯。

4.2 Ollama 接入后响应慢得离谱

我最初把 Ollama 桥接到 Claude Code 时，本地模型跑一个简单任务都要等十几秒，而且输出质量惨不忍睹，一度怀疑是配置错了。排查下来发现是两层问题叠加：一是本地模型选得太小，7B 量化版本来就不具备复杂推理能力，本来就不该让它承担这类任务；二是那台开发机的内存不够，模型常驻内存加上系统其他进程挤在一起，交换内存吃了大亏。

排查思路是：先在 Ollama 的日志里看模型推理耗时占比，再在系统监控里看内存占用。如果是内存吃紧，把模型重启、关掉不必要的容器就好很多。如果是要更高质量的输出，那就不是调参能解决的，得换更大的模型或者干脆回到云端模型。别跟本地模型死磕，它就是个 Plan B，不是主力。

4.3 Skills 加载不出来

Skills 不像 VS Code 插件那样装完有明确反馈。我踩过几个只报错不提示的坑，最常见的是目录路径放错了。Claude Code 对项目级 Skills 的识别路径是项目下的.claude/skills/技能名/SKILL.md，如果我直接放成.claude/skills/SKILL.md，或者技能名目录带上中文和空格，都会导致加载失败。另一个常见问题是SKILL.md里 frontmatter 格式不对，缺少name或description字段也会被静默忽略。

排查这类问题，我建议直接用/plugin或官方文档里的调试方式，把当前会话能识别到的技能列表打出来看。如果列表里没有，优先查路径和 frontmatter 格式，别急着怀疑模型本身。

4.4 MCP server 连不上

MCP 的报错通常比较隐晦，常见的是“connection failed”然后没有下文。我排查下来发现，大概率是 server 类型注册错了。MCP 有 stdio 和 HTTP/SSE 两种通信模式，如果你注册时写成 HTTP，但那个 server 只支持本地 stdio，就会连不上。还有一类问题是超时设置太短，尤其是浏览器自动化和大型代码索引这类耗时长连接，启动超时设成默认值很容易导致运行到一半连接被掐断。

排查链路是：先用 standalone 模式手动启动一遍 MCP server，确认它自己能正常工作，再检查 Claude Code 配置里的传输类型、启动命令和超时参数。把大日志分段处理，是定位问题最快的办法。

4.5 Windows PowerShell 下 Hooks 脚本失效

换到 Windows 开发机的时候，我的 Hooks 脚本全部失灵，日志里也没有明确报错。排查了半天，发现问题是脚本首行写的#!/bin/bash，但 Windows 下默认 shell 是 PowerShell，根本不会按 bash 语法去执行，而且命令路径里反斜杠和引号转义规则也完全不同。

打印排查方案只有一句话：不要让 Hooks 依赖特定 shell。我后来把所有 Hooks 脚本改成用 Node.js 或 Python 写，只通过命令行参数传递上下文，再显式指定执行器，比如python scripts/check.py。这样跨平台就稳定多了，Windows 和 macOS 都不再出幺蛾子。

5. 我 2026 年正在跑的一套组合配置：照抄不亏

5.1 最小可行配置清单

如果你想快速搭一套靠谱的 Claude Code 环境，不用照搬我全部的东西，可以先从这套最小配置开始：

先跑通这六项，再根据实际需求决定要不要上 MCP 和 Subagents 编排。别一次性全装，你会被配置轰炸搞得失去耐心。

5.2 不同项目类型的最佳组合

不同项目类型，扩展组合的偏重差距很大。我个人项目或原型阶段，我几乎只用 CC Switch + CLAUDE.md + 两三个 Command，追求的是快速迭代。团队协作的中大型项目，Skills 和 Hooks 就成了主力，规范约束和质量门禁都靠它们，CLAUDE.md 要写得非常详尽。如果项目涉及前端页面反复调整、需要真实浏览器验证效果，那就必须挂浏览器 MCP，让 Claude 自己去看渲染结果。

5.3 省 Token 与成本控制心得

最后分享几条我用 Claude Code 省 Token 的真实经验。第一，别让无关的扩展塞满上下文——每个 MCP 工具在会话开始时都会注入工具描述，装得越多，浪费的 Token 越多；第二，项目记忆要精炼，CLAUDE.md只写真正影响编码的内容，不要写几百行废话；第三，能切到 Bedrock 或 Vertex 等渠道的场景，配合 CC Switch 按需选择，成本差异还是挺明显的；第四，用 Subagents 并行处理大任务时，每个子会话的上下文边界越清晰，总 Token 消耗越低，因为不会反复在同一个会话里累积大量历史。

我在实际项目里长期用下来，最核心的体验就是：Claude Code 真正的生产力不在“多装”，而在“装对”。把官方机制用好，再挑几个真正贴合自己工作流的外围工具，价值和体验比堆二十个插件高出好几个量级。与其把时间花在纠结装哪个，不如先把你自己的工作习惯梳理清楚，再让扩展来服务它。