企业官网建设流程全解析

这两年我见过太多人给 Claude Code 装插件，装完发现要么吃灰，要么把终端搞得又慢又乱。我自己也是踩过坑才明白，Claude Code 的插件生态其实是分层的，有 MCP 服务、官方 Skill、Hooks 生命周期脚本，还有各种 IDE 扩展和命令行工具。真正影响日常效率的，不是数量，而是组合方式。

这篇文章我会写透 2026 年我留在生产环境里的 9 款 Claude Code 扩展，每一款都按"解决什么问题、怎么安装、怎么配置、什么场景该用/不该用"来讲。既给新手一套可以直接复制粘贴的配置，也给老手一些我踩坑后整理出来的判断标准。默认你已经装好 Claude Code 并且能正常跑基础功能，看完这篇，你应该能照着自己搭出一套不臃肿、稳定、能扛住真实项目节奏的 Claude Code 环境。

1. 先别急着装：搞懂 Claude Code 的四种扩展机制

1.1 MCP、Skill、Hooks 与 IDE 扩展，到底谁是谁

很多人把"插件"当成一个筐，什么都能往里装。实际上 Claude Code 的扩展机制至少有四层，搞混了就容易装错东西。

• MCP（Model Context Protocol）服务器：给 Claude 新增工具能力。比如读数据库、查文档、操作浏览器、调 GitHub API。MCP 服务器按需被调用，Claude 先决定要不要调用某个 tool，再由本地或远程进程执行并返回结果。
• Claude Skills：官方推出的技能机制。Skill 不新增工具，而是把"完成某类任务的方法论"固化下来。比如"发布检查""提交信息规范""组件开发流程"。遇到匹配的请求时，Claude 会读取技能说明，按里面写好的步骤执行。
• Hooks：生命周期事件挂钩。Claude Code 在会话启动、用户提交提示词、工具调用前/后、对话结束等事件发生时，会执行你配置的脚本。适合做门禁、拦截、通知、日志。
• IDE 扩展与桌面端：官方提供的 VS Code 扩展、桌面版客户端，本质是给 Claude Code 换个交互界面，共享同一份会话和配置目录。

这四层的价值完全不同。想要"阻止 Claude 读太大文件"应该用 Hooks，想要"让 Claude 每次发版前都跑一遍规范检查"应该用 Skill，想要"操作数据库或浏览器"才需要上 MCP。我在很多项目里见过的最常见误区，是团队为了一个很小的需求装了一整套 MCP，结果把上下文窗口塞满了无关工具，Claude 反而变笨。

下面这张表可以帮你快速分辨：

1.2 我筛选生产力插件的四个标准

装插件之前，先过一遍我自己的筛选标准，能过滤掉 80% 的花架子。

第一，按需加载才合格。扩展只应该在 Claude 需要时被调用，而不是启动时就把一堆上下文塞进窗口。凡是"常驻注入大段上下文"的插件我基本都会卸掉，因为它在持续稀释注意力、抬高 token 成本。第二，解决的是真痛点。装之前问自己：我是不是刚在最近一周内被这个问题卡住过？如果答案是"我收藏了好几个这种插件"而不是"我确实每次都被它困扰"，那就不装。第三，维护活跃、接口稳定。Claude Code 更新很快，半年不更新的扩展大概率出兼容问题。装之前看一下 star、最后 commit 时间、issue 响应速度。第四，权限和网络行为透明。一个插件要访问什么、数据去了哪里必须清楚。团队项目里我只会用可审计的开源扩展，绝不让不明插件持有环境变量里的 Key。

这四个标准看起来简单，但真的能执行下去的人不多。尤其是团队项目里，任何人都可以往公共配置里加一个 MCP，最后变成"每个人的电脑上都有五六个不知道是干什么用的工具"。接下来这 9 款，全部通过了这套标准。

2. 配置与省 token：先让 Claude Code 用得顺手又不烧钱

2.1 cc-switch：多环境、多 Key、本地模型一键切换

我同时维护公司项目和个人项目。公司的 Claude Code 配置要指向团队账号，个人项目用我自己的 Key，本地实验时又想切到本地模型跑一跑。最早我靠手动改配置文件，每次切换都要小心翼翼，改错一个字段整个会话就废了。cc-switch 就是为这种场景设计的。

它本质上是一个命令行配置切换工具，把 Claude Code 的不同配置存成 profile，一键切换。你可以把生产环境、测试环境、个人环境分别存成 profile，每个 profile 里记录对应的 API Key、模型设置、视觉能力开关等。团队里还能共享一份配置文件模板，新同学克隆下来直接用。

安装很简单，Node 18 以上的环境执行：

npm install -g cc-switch

常用操作大概是这样的思路，具体命令以你装到的版本为准：

cc-switch profile add company --api-key sk-ant-xxxx --vision true cc-switch profile add personal --api-key sk-ant-yyyy cc-switch use company cc-switch list

为什么我把它排在第一位？因为绝大多数配置问题都不是 Claude Code 本身的问题，而是"环境串了"。公司 Key 打了个人项目的请求，测试流量误伤生产账号，或者临时改乱了 settings.json 忘了还原。我用了 cc-switch 之后，切项目之前先cc-switch use <profile>，已经大半年没有因为配置问题浪费过时间。

这里有一个非常实用的心得：不要图省事把 Key 写在 shell 历史里。用环境变量或系统 keyring 保存，而且要检查 profile 文件的权限。我还见过有人把包含 Key 的配置文件直接提交到 git 仓库，这个在团队项目里属于事故级错误，一定要把配置文件加进.gitignore。

2.2 .claudeignore + Hooks：被低估的省 token 组合拳

很多人只关注"让 Claude 能做什么"，忽略了"别让 Claude 看不需要的东西"。默认情况下，Claude Code 会用文件系统工具浏览项目，你如果不拦着，它会去读node_modules、dist、package-lock.json、日志文件。这些内容既烧 token 又干扰判断。

.claudeignore的语法和.gitignore几乎一样，放在项目根目录：

node_modules/ dist/ build/ coverage/ *.lock .tmp/ *.log

这样 Claude 在做全局搜索和文件读取时，会跳过这些目录。它会知道这些目录存在，但不会把内容塞进上下文。如果你某次对话确实需要读某个被忽略的文件，直接把它拖进终端，或者用@文件路径显式指定，可以临时绕过 ignore 规则。

Hooks 则是更细粒度的"门禁"。我在settings.json里配了两个 Hook，一个用来拦截超大文件，一个用来在任务结束时发桌面通知：

{ "hooks": { "PreToolUse": [ { "matcher": "Read|Grep", "hooks": [ { "type": "command", "command": "node .claude/hooks/guard-read.js" } ] } ], "Stop": [ { "hooks": [ { "type": "command", "command": "osascript -e 'display notification \"Claude Code 任务完成\" with title \"Claude Code\"'" } ] } ] } }

guard-read.js的逻辑很简单，就是检查 Claude 要读的文件大小，超过 200KB 直接阻止，并提示它改用 grep 或查看片段：

const fs = require('fs'); let input = ''; process.stdin.on('data', d => input += d); process.stdin.on('end', () => { const hookInput = JSON.parse(input); const filePath = hookInput.tool_input.file_path; if (!filePath) { process.exit(0); } const MAX = 200 * 1024; try { const stat = fs.statSync(filePath); if (stat.size > MAX) { process.stdout.write(JSON.stringify({ decision: 'block', reason: `文件过大(${(stat.size / 1024).toFixed(0)}KB)，已阻止读取，请先用 grep 或查看文件片段` })); } } catch (e) {} });

这一套组合拳的效果立竿见影。我之前在一个前端项目里，package-lock.json有五百多 KB，Claude 偶尔会去读它，一次性就吃掉十几万 token。加了.claudeignore和 Hook 之后，/context里的占用明显降下来，Claude 也不会再纠结于构建产物里的无关信息。省 token 不只是省钱，更是让 Claude 把注意力放在真正需要改的代码上。

2.3 Ollama MCP：把本地模型接进 Claude Code 当备胎

Ollama 是本地跑大模型最方便的工具之一，本身和 Claude Code 没有直接关系。但通过 MCP 服务器，你可以让 Claude Code 调用本地模型完成一些特定任务。我把它当成"备胎"，专门处理那些不适合发给外部 API 的文本。

最典型的一个场景：你写了一个脚本，想先把一段内部日志做粗略分类，再决定后续处理方式。或者出于公司合规要求，某段代码文本不适合发送到外部服务。这时可以让 Claude Code 调用本地模型完成预处理——日志摘要、批量翻译、命名规范检查、简单格式整理，都是本地模型能稳定完成的任务。

先拉模型，再加 MCP：

ollama pull qwen2.5:7b claude mcp add ollama \ -- npx -y mcp-ollama \ --model qwen2.5:7b \ --baseUrl http://localhost:11434

然后在对话里直接说类似这样的话："用 ollama 工具把下面 20 条 Nginx 错误日志按 4 类归档，只输出统计结果。"Claude 会按需调用本地模型，拿到结果再继续处理。

为什么不建议把复杂任务也丢给本地模型？因为本地模型在复杂代码生成、深度推理上的能力上限和云端还有明显差距，推理速度也慢。我试过让它做完整的模块设计，效果远不如 Claude 官方模型。但在"清洗、摘要、格式化"这类天花板不高的任务上，本地模型完全够用，而且数据不出机器。这里要提醒一点：7B 量化模型大概需要 4 到 6GB 内存，如果你的机器内存紧张，建议换更小的 3B 模型，或者干脆别开。

3. 能力扩展：让 Claude 真的"能跑起来"

3.1 Context7 MCP：按需抓取最新文档，治疗 API 幻觉

Claude 的训练数据有截止日期，这是所有大模型的通病。你让它写某个库的新版本 API，它很可能自信地写出一个"看起来对、实际上不存在"的用法。Context7 解决的就是这个问题——它按需从官方文档源抓取最新信息给 Claude 参考，而不是让 Claude 凭记忆瞎编。

安装命令：

claude mcp add context7 -- npx -y @upstash/context7-mcp

使用方式很自然，比如我会这么问：

"用 context7 查一下 React 19 里 useDeferredValue 的最新用法，我想在搜索排序里用它做防抖。"

Claude 会调用 context7 的查询工具，检索对应库的官方文档，把相关片段带回上下文，然后基于这些片段写代码。我在升级公司项目依赖时最依赖它，React 19、Vite 6、Next.js 15 这些大版本更新，光靠记忆根本不靠谱。

为什么说它比"把所有文档写进 prompt"更聪明？因为按需加载。你不需要在每次会话里都塞几百页文档，Claude 只会在需要时去查，而且一次只查一个库，token 成本很低。这里有一个使用心得：不要让 Claude 一次查询太多库，否则返回的文档片段会非常大，反而拖慢节奏。一次对话里，最多让 Claude 逐库查，查完一个写一段。

3.2 Playwright MCP：让 Claude 自己开浏览器验证

前端开发最烦的事情就是"看起来能跑，实际白屏"。代码逻辑没问题、构建也没报错，但页面就是渲染不出来。以前我只能自己手动开浏览器一遍遍点，现在我把这一步交给了 Playwright MCP。

Playwright MCP 的核心价值是：让 Claude 能打开真实浏览器，执行点击、输入、跳转、截图等操作，然后把页面状态、控制台报错、DOM 结构带回来分析。安装：

claude mcp add playwright -- npx -y @playwright/mcp@latest

我会这么用：让 Claude 写好前端组件后，启动本地开发服务器，再用浏览器去验证。Prompt 大概长这样：

"启动本地开发服务器后，打开 http://localhost:5173，点击右上角登录按钮，输入测试账号，如果出现 console 报错，把报错和页面截图保存到 /tmp/login-check.png。"

Claude 会一步步操作，把每一步的结果传回来。如果页面报错，它能看到具体错误信息，接着修，改完再验证一遍。这个过程把"写代码—验证—返工"的循环压缩在了同一个会话里，非常省心。

但我必须提醒几个坑。第一，不要在已经登录你真实账号的浏览器配置里跑，用--user-data-dir指定一个独立 profile，避免它误操作你的私人会话。第二，每张截图、每一步 DOM 结果都吃 token，控制操作步数，把多个验证动作尽量合并成一次任务。第三，Playwright MCP 适合做"最小可执行验证"，不等于正式 E2E 测试，别拿它替代测试框架。

3.3 Sequential Thinking MCP：复杂任务的推理外挂

Claude Code 在简单任务上反应很快，但遇到大型重构、系统设计这类问题时，容易犯"第一次给答案"的毛病——直接输出一个看似全面、实则浅层的方案。Sequential Thinking MCP 就是对抗这个问题的工具。

它提供的是一个结构化思考工具，让 Claude 把推理过程一步步写出来，每步都可以检查、修正、回溯。安装：

claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

用法是在复杂任务的 prompt 里显式要求，比如：

"用 sequential thinking 分析这个支付模块为什么在并发 100 时会偶发重复入账，先列出假设，再逐条验证。"

Claude 会按顺序输出思考步骤：先明确已知线索，再列出可能的故障点，然后逐个验证，最后给出结论和方案。这样你看到的就不是一个"成品答案"，而是一条可以 review 的推理链。

我试过在一次模块拆解任务里，让 Claude 先用 sequential thinking 做推理，再让我审查每一步的假设，最后才让它写代码。结果是它找到的边界条件比直接生成方案多得多，后续返工明显减少。但注意，简单任务千万别用。让 Claude 思考"如何写一个 console.log"还走八步推理，纯属浪费时间和 token。这个工具应该只在任务复杂度值得的时候手动开启。

4. 协作与工作流：把个人工具升级成团队基础设施

4.1 Claude Skills：把团队的手艺固化下来

一个团队最有价值的资产，是"怎么干活"的知识。比如前端组件开发的命名规范、发布前的检查清单、commit message 的格式要求。这些东西以前写在 wiki 里，没人看。现在可以写进 Claude Code Skills，遇到对应场景时被自动加载。

Skill 的目录结构很固定：.claude/skills/<skill-name>/SKILL.md。文件开头是 frontmatter，接着是具体步骤。我这里用一个真实的团队技能做例子：

--- name: component-dev description: 开发一个新的 React 组件，包含类型定义、单元测试和 Storybook 文档。当用户要求新增组件时使用。 --- 1. 在 src/components 下创建组件文件，遵循团队命名规范。 2. 为组件编写单元测试，覆盖默认状态和边界状态。 3. 运行 `npm run test:component -- <ComponentName>` 确保测试通过。 4. 在 stories 目录添加 Storybook 示例。 5. 检查 TypeScript 类型声明无 any。

Claude 收到"帮我新增一个 DataTable 组件"这类请求时，会自动匹配 description，加载技能内容，然后按步骤执行。它不需要用户每次都手动声明"请走我们的规范流程"，这正是 Skill 和普通 prompt 最大的区别。

写 Skill 有两个要点。第一，description 要写清楚"什么任务会用到该技能"，含糊的描述会导致 Claude 在无关场景下也去读技能文件。第二，复杂判断不要全写在自然语言里，最好写成脚本让 Skill 引用。比如"检查是否包含敏感信息"这种逻辑，用 grep 脚本做比让 Claude 逐条看靠谱得多。技能目录要放进 git 管理，并且要定期 review。我在公司里就是每季度过一次技能清单，把过时的、团队已经不再遵守的规则删掉。

4.2 GitHub MCP Server：PR 审查与 Issue 处理不掉线

在日常开发里，我切换最频繁的两个工具是编辑器（Claude Code）和 GitHub 网页。一会要看 issue，一会要开 PR，一会又要看 CI 结果，来回切换非常打断心流。GitHub 官方 MCP Server 把这个流程收进了 Claude Code。

安装方式最常见的是用 Docker 跑官方镜像：

claude mcp add github \ --env GITHUB_PERSONAL_ACCESS_TOKEN=ghp_xxx \ -- docker run -i --rm \ -e GITHUB_PERSONAL_ACCESS_TOKEN \ ghcr.io/github/github-mcp-server \ --tools repo,issue,pull_request,actions

配好之后，你可以在对话里直接让它做这些事："把当前分支和 main 的 diff 总结成 PR 描述，打开一个 PR""看看 issue #88 的讨论，给出一个修复方案""检查我最近的 commit 有没有误提交的敏感信息"。

我最常用的场景是"先 review 再提交"。写完代码后，让 Claude 把当前分支的 diff 全部看一遍，找出潜在问题，修完再开 PR。这一步让 PR 质量提升非常明显，很多低级错误在进入 code review 之前就被拦下了。

这里的安全提醒是重中之重：GitHub token 一定要最小权限。不要用拥有所有仓库权限的个人 token，而是用 fine-grained token，只授权当前项目需要的仓库和操作范围。同时别把 token 写进共享配置或 skill 文件，通过环境变量注入。Claude Code 开源且可审计，但团队里其他人装的第三方插件不一定靠谱，这个问题在 4.3 之后我还会再强调。

4.3 VS Code 官方扩展：保留终端灵活，享受 IDE 视图

有人觉得 Claude Code 既然是终端工具，就必须全程在终端里用。其实不是。官方 VS Code 扩展的价值在于，你可以在需要的时候切到图形界面，而会话、配置、上下文都是和 CLI 共享的。

我在实际工作中是双轨制：日常写 prompt 用终端，因为快、轻、脚本友好；但遇到大 diff 审查、多文件重构、需要边看代码边聊的场景，我会切到 VS Code 扩展。它的 diff 视图比终端里的纯文本输出舒服太多，选中一段代码直接加进 Claude 上下文的操作也比手动复制粘贴干净利落。

安装就是去 VS Code 插件市场搜 Claude Code，装完登录同一个账号即可。它会自动读取你现有的~/.claude配置和项目级settings.json，不用二次配置。我在 monorepo 里用的时候，会先在项目根目录启动，避免它去扫整个仓库的所有子包，不然同步会有明显的卡顿。如果你发现扩展响应变慢，首先检查的就是是不是加载了太多不需要的 MCP 服务器。

5. 组合配置：把九款插件装成一套生产环境方案

5.1 一份可以直接抄的配置骨架

讲了九个单独的扩展，但真正高效的是它们的组合。这里我给出一个可以当模板用的项目结构：

my-project/ ├── .claude/ │ ├── settings.json │ ├── skills/ │ │ └── component-dev/ │ │ └── SKILL.md │ └── hooks/ │ └── guard-read.js ├── .claudeignore └── package.json

.claudeignore里写排除项，settings.json里配 Hooks，skills目录放团队技能，MCP 服务器按项目需要单独添加。我建议做一张速查表贴在团队文档里：

这套骨架的好处是：基础设施固定，按需扩展工具。也就是说，.claudeignore、Hooks、Skills 是任何项目都该有的"默认配置"；而 MCP 服务器属于"按需加载"的部分，不是每台机器都要全装。

5.2 真实场景复现：一个功能从开发到 PR 全流程

拿我最近一次给公司内部组件库新增 DataTable 组件的过程来演示这套组合拳。

第一步，cc-switch use company，确认当前环境是公司配置，避免混用 Key。第二步，在项目根目录启动 Claude Code，输入："使用 component-dev 技能开发一个 DataTable 组件，支持排序和分页。"Claude 自动读取技能文件，按团队规范创建组件、类型、测试和 Storybook 文档。

第三步，我追加一句："用 context7 查一下 React 19 里 useDeferredValue 的最新用法，看排序搜索能不能直接用它优化。"Claude 查完文档后对组件做了优化，把大列表排序的卡顿问题处理掉了。第四步，我说："用 playwright 打开本地 http://localhost:5173，访问 /components/data-table 页面，点击列头排序，截图看效果。"它自己启动浏览器，模拟点击，截图反馈。如果白屏或报错，直接把 console 信息拿回来修。

第五步，所有验证通过后，我说："用 github 工具把这个改动提交到新分支，创建 PR，总结改动，贴到 PR 描述。"整个过程里，guard-read.js一直在拦截大文件，.claudeignore保证了它不会读node_modules，任务结束时的 Stop Hook 会自动发桌面通知。一个完整功能从开发到 PR，全程没有离开过 Claude Code，也没有手动做过一次上下文清理。

这套流程跑顺之后，我的切身体会是：插件的价值不在于某一个工具多酷，而在于它们组合起来之后，减少了每一次上下文切换带来的心智损耗。

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

6.1 装了扩展却不生效

我遇到最多的反馈是"明明加了 MCP，Claude 就是不用"。排查顺序很重要。先跑claude mcp list确认服务器还在不在，再看claude mcp get <name>看具体状态，最后用claude mcp inspect <name>查看最近的调用日志。

最常见的三个原因：第一，npx 首次下载 MCP 包失败，Node 版本太低或网络问题导致拉不回来，优先把 Node 升到 20 以上再试；第二，添加完 MCP 之后没有重启 Claude Code 会话，新服务器是在会话启动时加载的；第三，Skill 没生效，多半是目录结构写错了。Skill 必须放在.claude/skills/<技能名>/SKILL.md，frontmatter 里的 name 和 description 不能少。Hook 没生效则要检查 matcher 语法和你脚本的输出格式，Hook 的 JSON 输出必须包含decision字段才会被 Claude Code 识别。

6.2 token 突然暴增怎么办

如果你发现一次普通对话的 token 消耗高得离谱，先打开/context看一下当前上下文里到底塞了什么。然后翻会话记录，确认是哪些工具调用消耗了大头。

高概率是三个来源：第一，package-lock.json、构建产物这类大文件被 Claude 读进上下文，解决方案是补全.claudeignore；第二，Playwright MCP 截图和 DOM 结果太频繁，控制浏览器操作步数，减少截图次数；第三，Context7 一次查了多个库，返回的文档片段严重超量，改为一次只查一个库。

另外，不要同时启用多个功能重叠的 MCP。比如你既装了文件系统 MCP 又装了 GitHub MCP，Claude 在读取仓库文件时可能不知道该调哪个，有时候会连续触发多个工具调用，token 翻倍。我的原则是：一个能力只留一个工具。

6.3 安全与权限，怎么强调都不过分

第三方 MCP 本身就是一个可以访问你项目文件的进程，它甚至可能把内容发到它自己的远程服务。所以装之前我要求自己能看懂源码、能审计、社区活跃。任何来源不明的"增强插件"，不管宣传多夸张，一概不装。

API Key 和 GitHub Token 绝不能写进settings.json或任何会进 git 的文件。统一用环境变量，或者在 cc-switch 这类工具里单独管理。GitHub token 用 fine-grained token，只给需要的仓库授权。公司合规要求高的时候，涉及敏感数据的文本处理切到 Ollama 本地模型，让数据留在机器内。

我还养成了一个习惯：每周跑一次claude mcp list，看有没有我不认识的服务器被加了进来。团队协作时，别人可能在公共配置里加了一个工具，如果你没留意，就可能带着一个陌生的网络权限跑一整周。Claude Code 提供了很清晰的审计接口，善用它。

最后分享一个我自己的使用习惯：每季度做一次插件清理。把claude mcp list拉出来，凡是三个月没用过的扩展直接删，再看一遍 hooks 和 skills 目录，把过时的说明更新掉。Claude Code 的迭代速度很快，环境里的工具越少越好维护，真正留下的应该是你每天都会用到的那几个。希望这份清单能帮你把省下来的时间，花在真正要解决的问题上。