企业官网建设流程全解析

最近半年，我的日常开发基本都泡在 Claude Code 里。最开始就是"裸用"——打开终端，输入 claude，直接提问，让它帮我改代码。说实话，那个阶段它更像一个"会聊天的代码搜索引擎"：改完这个文件，下个会话又忘了我的项目背景、代码规范、技术栈偏好，我得把同样的话重新说一遍。真正让我从"裸用"走到"工程化"的，是两个东西：Skills 和 MCP。Skills 把团队规范、项目上下文、常用套路沉淀成可复用的能力包；MCP 则把 Claude Code 从终端里解放出来，让它能碰真实的数据源和外部工具。这篇就把我这半年的折腾过程、踩过的坑、留下的配置原原本本写出来，给同样在"裸用"和"工程化"之间犹豫的人一个参考。

1. 先认清痛点：裸用 Claude Code 到底卡在哪里

1.1 无 Skills 时的重复劳动：每个新会话都在"重新做人"

裸用 Claude Code 最典型的场景是这样的：你开一个新任务，让它"把这个接口改成 GraphQL 风格"，它确实会改，但改出来的代码大概率不符合你项目的既有约定。你的项目用 pnpm 还是 npm？组件写的是 Options API 还是 Composition API？接口返回结构要不要统一包一层{ code, data, msg }？这些信息它都不知道。

更麻烦的是，你每开一个会话就得重新交代一遍。我试过把这些写进 CLAUDE.md 项目说明文件，能解决一部分问题，但它只是一个静态的说明书，Claude Code 并不会在遇到具体任务时自动想起"这种情况应该套用某某规范"。换句话说，裸用时代，上下文传递靠人肉重复，能力复用基本为零。这也是我后来对 Skills 产生兴趣的直接原因——它不只是"多一个 prompt 模板"，而是让模型在恰当的时候主动加载恰当的能力。

1.2 没有 MCP 时，代码库之外的数据全是盲区

第二个痛点比第一个更隐蔽。Claude Code 默认只能读你给它的文件路径、执行终端命令、操作工作区。可现实中的开发工作流，很大一部分价值在代码库之外：UI 设计稿在 Figma 里，需求文档在 Dify 的工作流里，PCB 工程在 Altium Designer 里，PLC 程序在 TIA Portal 里，逆向样本在 IDA 和 x32dbg 里。裸用的时候，我不得不手动把设计稿说明复制粘贴给 Claude，手动从调试器里拷贝反汇编片段，再让它分析。一顿操作下来，AI 的"眼睛"和"手"全是断的。

我印象很深的一次，是要它根据蓝湖的设计稿还原一个页面。我先把几张截图和标注文字贴给它，它理解得七零八落，还原出来的间距、字号全不对。后来接了蓝湖 MCP，Claude Code 能直接读取图层树和样式标注，那次还原质量完全不是一个量级。所以说，工作流要是没有 MCP，AI 开发助手的上限只是"能改代码"，而不是"能干活"。

1.3 裸用到工程化：我需要的是能力分层

折腾了几个月，我的体会是，工程化的本质不是装更多插件，而是把工作流拆成三层：

• 能力层（Skills）：告诉 Claude Code"你擅长什么、遇到什么场景该用什么套路"。这是对模型行为方式的塑造。
• 连接层（MCP）：让 Claude Code 能访问外部系统和数据的通道。一个 MCP Server 就是一个外部能力的适配器。
• 调度层（模型与配置管理）：用 CC Switch 之类的工具控制它到底跑在哪个模型上、花多少钱、有没有权限执行高风险命令。

这三层不复杂，但每一层都有不少细节。下面按我的实操顺序逐一展开，先 Skills，再 MCP，最后是模型和运行环境，并附上我真实踩过的坑。

2. Skills：把"提示词"升级成"能力包"，我踩对的第一步

2.1 Skills 和普通 Prompt 到底差在哪

先说结论：Skills 是"结构化的、按需加载的、带工具的 Prompt 包"，而普通 Prompt 是一段一次性文本。

Skill 在 Claude Code 里的落盘形态是一个目录，通常是.claude/skills/<skill-name>/SKILL.md，外加一些配套资源。SKILL.md 自带 YAML frontmatter，里面至少要写name和description，关键是description：模型就是靠它来决定"当前任务要不要激活这个 Skill"。这跟 CLAUDE.md 那种"启动时全量加载"的方式完全不同——Skills 是按需加载，任务不相关时它根本不占用上下文窗口。

我最早看到这个概念时的想法是："这不就是写几个 Markdown 模板吗？"真正用了才发现差别。举手之劳式的 Prompt 只会在当前会话生效，而一个 Skill 可以被任何会话按需激活，还能带上自己的辅助文件、脚本和工具白名单。这就像一个员工手册：不是每天把整本手册背一遍，而是遇到某个流程时，翻到对应章节照着做。

2.2 官方市场与 find skills：别上来就装一堆

Skills 机制出来之后，网上的"skills 推荐"铺天盖地，GitHub 上有不少聚合仓库，热词里的find skills、skills 下载平台有哪些、github skills指的就是这类渠道。你可以在网上搜到社区整理好的技能集，比如主打通用能力的superpower skills，还有各种针对前端、论文写作、逆向分析方向的 skills 合集。

我的建议是：先忍住，别当松鼠党。我第一周装了二十多个技能，结果真正用到的不到五个，反而因为部分技能 description 相互重叠，模型在激活时经常选错。比如同时装了"vue 组件开发规范"和"前端最佳实践"，遇到一个 Vue 任务时它可能两个都激活，上下文被无谓占用。

正确的姿势是：先列一张"我平时反复让 AI 做的事"清单，比如我列出来的是——Vue 组件开发、代码 review、接口文档生成、git 提交信息规范。然后针对这几件事去找对应的 skills，找不到满意的就自己写。这就是从"找技能"到"造技能"的转变。

2.3 我自己留下的三组 Skills：superpower skills 之外的实用组合

坦白说，superpower skills里我最常用的是它的规划类技能。它把一个大任务拆成人话版步骤，让 Claude 先做计划再动手，对复杂改动特别有效。但它的包体很大，不是每个技能都适合我的工作流。我自己目前留了这么几组：

• 技术栈规则类：把项目的前端规范、接口约定、目录结构约定写成一个 skill。这一组直接解决我开头说的"重新做人"问题。凡是涉及本项目代码的改动，模型会自动加载它。
• 任务模板类：比如"生成接口文档""写单元测试""做代码 review"。这类 skill 的价值是输出格式稳定，不会这次 Markdown 表格、下次又给我散文。
• 工具链技能：把常用的命令组合封装成技能。比如"启动本地开发环境并做健康检查"，让 Claude 按固定流程执行。

重点说一下技术栈规则类的写法，它最有代表性。

2.4 自建 Skills 的标准姿势：目录、frontmatter、正文结构

我建议每个团队至少都建一个自己的frontend-vue-rules之类的基础技能，目录结构长这样：

.claude/ └── skills/ └── frontend-vue-rules/ ├── SKILL.md └── templates/ └── component-template.txt

SKILL.md 我一般这样写：

--- name: frontend-vue-rules description: 在修改或者新建 Vue 3 组件时触发，统一使用项目现有的组件规范、目录结构和样式方案。 allowed-tools: Read, Edit, Write, Bash --- ## 何时使用 当任务涉及 src/views 下页面组件、src/components 下公共组件的创建或修改时。 ## 核心规范 - 统一使用 <script setup> 语法，禁止 Options API - 样式使用 scoped 且变量从 design-tokens.css 中取 - 组件目录下必须附带 index.ts 统一导出 - 接口调用统一走 src/api 下的封装，禁止在组件内直接写 fetch ## 标准流程 1. 先读取目标文件并确认所属模块 2. 对照 templates/component-template.txt 创建或重构组件 3. 检查是否引用了 design-tokens 中的变量 4. 完成后给出改动清单

这里最关键的其实是description。写得越具体，触发越准。我见过很多人把 description 写成"用于前端开发"，这种等于没写，模型看到什么任务都像沾边。要写成"当任务涉及……时使用"的句式，把触发条件收敛得越窄越好。

另外还要注意allowed-tools这个字段。它限制了这个技能激活时模型可以用哪些工具。我一开始把权限放得很宽，结果一个"生成接口文档"的技能也会去执行 bash，这完全没有必要。把工具限制住，等于给技能圈定了行为边界，既省 token 又安全。

提示：Skills 写好之后要测试，可以用/skills命令查看已加载的技能，再给模型丢一个明确的触发任务，看它到底激活了哪个技能。调试技能时最常用的手段就是看模型 response 里有没有引用 SKILL.md 的内容，如果完全没引用，多半是 description 没写对。

3. MCP：真正让 Claude Code 长出"手和眼睛"的协议

3.1 MCP 是什么，我一句话讲清楚

MCP（Model Context Protocol，模型上下文协议）是一个标准化协议，它定义了大模型应用（客户端）和外部数据/工具（服务端）之间怎么通信。我一般用"AI 世界的 USB-C"来类比：以前每个 AI 要接一个工具就得专门写一套私有接口，有了 MCP 之后，只要工具那边提供一个符合协议的 Server，Claude Code 这边就能即插即用。

从实现上看，一个 MCP Server 通常会通过 stdio（本地子进程）或 HTTP（远程服务）和 Claude Code 通信。它对外暴露三类能力：tools（可执行的操作）、resources（可读取的数据）、prompts（可复用的提示模板）。我们日常用得最多的是 tools，比如"查询资产信息""读取 PCB 工程数据""在调试器里下断点"。Claude Code 每调用一次 tool，本质上是向 Server 发了一个 JSON-RPC 请求，然后把返回结果收进上下文继续推理。

3.2 配置 MCP 的两种姿势和一条铁律

配置 MCP 我常用的有两种方式。

方式一：命令行直接添加，适合一次性、个人级的配置：

claude mcp add unreal -- npx -y @some/unreal-mcp claude mcp list

方式二：项目级.mcp.json，适合跟着代码仓库走、团队共享的配置：

{ "mcpServers": { "figma": { "command": "npx", "args": ["-y", "figma-mcp-server"], "env": { "FIGMA_API_KEY": "your-token" } } } }

我用下来的一条铁律是：能走项目级配置就走项目级，而且必须放到代码仓库里统一管理。这样同事拉下来项目就能直接用同一套 MCP 环境，不用各自在命令行里敲一遍。但注意，.mcp.json里如果写死了 API Key，千万别提交到公开仓库，密钥用环境变量引用。

3.3 我实测过的领域 MCP：Unreal、Altium、IDA、TIA、设计协同

MCP 的价值有时候不亲身体会很难讲透，我列一下自己实际配过的几个领域，你可以对照自己的行业看看有没有对应的兴奋点。

以 Unreal 5.8 MCP 为例，接入步骤大概是：先把 MCP 插件装进引擎插件目录，在编辑器里启用并开启对应端口，然后在 Claude Code 里注册 MCP Server，把端点和认证信息配好。接着你就能让 Claude 列出关卡里的 Actor、查询某个资产的引用关系，甚至指导你搭建蓝图。实际用的过程中我最大的体会是：这类 MCP 的价值不在于它多聪明，而在于它把 AI 和环境之间的"翻译工作"省了——不需要我手动复制资产路径、手动导出清单。

Altium Designer 那边我试用过类似的接口 MCP，它在读原理图层次结构和批量修改位号这类机械工作上表现稳定，但对复杂信号完整性的判断还是做不了，你也别指望它替代 SI 仿真工具。

3.4 MCP 的安全边界：不是所有工具都该放开

MCP 给了 Claude Code"手和眼睛"，但给多少权限，必须由你决定。这是我在接入几个高危类型 MCP 之后最想强调的。

claude mcp add的时候留意一下它到底是只读类的 tools 还是带写操作的 tools。以 IDA MCP 和 x32dbg MCP 为例，这类调试工具天然就有"修改进程状态"的能力，配置在本地个人环境没问题，但如果跑在共享的 CI 机器上，得靠 MCP Server 自身的配置先把写操作禁用掉。

我给自己定的几条安全边界，供参考：

• 生产环境、有真实用户数据的系统，坚决不接 MCP。就算接也要先确认 Server 端有完整的只读模式。
• 每个 MCP Server 只给最小权限。比如 Figma MCP 只读图层树，就不该让它拥有"写回设计稿"的能力。
• 定期用claude mcp list审计。我每两周看一次，把不再使用的 Server 移除。MCP 接得越多，维护成本和被攻击面就越大，这不是玩笑。

安全原则只有一个：让 AI 看得见它该看的，碰不到它不该碰的。

4. 模型接入与管理：用 CC Switch 把 Claude Code 变成"多模型终端"

4.1 为什么我要折腾第三方模型与本地模型

官方 Claude 订阅确实稳定，但我遇到过一个很现实的问题：组织账号提示your organization has disabled claude subscription access for Claude Code。直白说，公司策略把路堵了，我又需要在工作流里继续用 Claude Code。当时就两条路：一是用自己的个人订阅账号重新授权，二是给 Claude Code 接入第三方模型通道。

顺着第二条路折腾下来，我发现"换模型"这件事远比想象中有价值。Claude Code 的 agent 循环本质上是"推理-调用工具-观察结果-再推理"，它对模型的要求不仅是代码能力强，还要求模型有稳定的 tool calling 能力。而市面上不少模型在纯对话任务上很能打，一进 agent 循环就露馅——工具参数瞎填、上下文记不住。所以，接入哪个模型，直接决定你的工程化工作流是"加速器"还是"翻车现场"。

4.2 CC Switch 的配置路径与原理

CC Switch 是一个社区工具，核心功能就是管理 Claude Code 的多套 API 配置，实现一键切换。它的原理很简单：Claude Code 本身通过几个环境变量来识别 API 地址和身份认证，比如ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL。CC Switch 的工作就是维护不同的环境变量组合，切换时帮你把对应配置写进去。

我用它接第三方模型的典型路径是：

# 以聚合平台提供的 Anthropic 兼容通道为例 export ANTHROPIC_BASE_URL=https://your-gateway.example.com/anthropic export ANTHROPIC_AUTH_TOKEN=sk-your-key export ANTHROPIC_MODEL=deepseek-chat

我用 CC Switch 分别配置了 DeepSeek、通义千问（Qwen）、智谱（GLM）几个预设，还有一个指向本地的 LMStudio。切换时选一下预设，重启终端里的 Claude Code 会话就生效了，整个过程一分钟以内。

有一点必须提醒：不是所有平台都原生提供 Anthropic 兼容端点。如果你用的是裸的 OpenAI 格式 API，通常需要走一个转换网关，把chat/completions转换成 Claude Code 能认的格式。这属于另一套折腾了，建议从"已经做了 Anthropic 兼容层"的聚合服务下手，省很多事。

4.3 LMStudio 本地模型接入实录

本地模型这件事，最初是冲着隐私去的。有些公司的代码确实不能出内网，但又想用 AI 辅助，那就只有本地模型一条路。我用 LMStudio 加载了 Qwen 和 GLM 系的大规模参数模型，然后在 LMStudio 里开启本地服务器模式，默认地址http://localhost:1234。

之后在 CC Switch 里加一个预设：

export ANTHROPIC_BASE_URL=http://localhost:1234 export ANTHROPIC_AUTH_TOKEN=not-needed export ANTHROPIC_MODEL=qwen2.5-coder-32b

跑起来之后，Claude Code 能正常对话，但我要给个真实评价：本地模型的 tool calling 稳定性明显弱于云端旗舰模型。具体表现是，让它调用 MCP 工具时，偶尔会把参数类型写错，或者在一次循环里反复调用同一个工具拿不到结果还不退出。后来我的解决方案是：本地模型只用来做代码解释、文档生成、简单的文件修改，凡是涉及多步骤 MCP 调用和复杂重构的任务，一律切回云端强模型。这不算妥协，而是"让合适的模型干合适的活"。

4.4 模型切换后的真实差异与成本控制

把几种接入方式放一起对比，感受会更直观：

成本控制这块，我的经验是两条：一是给 Claude Code 设好模型别名和上下文上限，避免它无脑堆长上下文；二是善用/compact压缩历史，长会话跑久了，上下文里全是旧的工具返回结果，既费 token 又影响模型注意力。工程化工作流里，上下文管理本身就是一项核心技能，不会压缩上下文的人，跑复杂任务一定又慢又贵。

5. Ubuntu + VSCode：把工程化工作流钉在常用环境里

5.1 Ubuntu 下安装与升级的细节

我日常主力环境是 Ubuntu，Claude Code 装起来本身不复杂：装好 Node.js 18 以上版本，然后npm install -g @anthropic-ai/claude-code。这里有两个容易踩的细节：

• 用 nvm 管理 Node 版本的人，注意全局安装的 CLI 可能在切换 Node 版本后"消失"，报command not found: claude。我后来统一用系统级 Node LTS 跑 Claude Code，避免这种诡异问题。
• 在线升级最新版本：Claude Code 更新很勤，官方支持claude update自动升级。不过升级之后偶尔会遇到配置兼容问题，所以我每次升级完都会先跑一遍claude --version和claude mcp list，确认核心配置还在。升级前备份.claude目录是我后来养成的习惯，成本极低，收益极高。

5.2 VSCode 集成：从命令行到 IDE 面板

命令行用顺手之后，我一度觉得 VSCode 集成是多余的。直到有一次在三个项目之间来回切换，才发现 VSCode 侧边栏面板的方式能更直观地管理会话和 diff。

安装 Claude Code for VS Code 扩展之后，它会自动识别已经登录好的 CLI，我在编辑器里直接打开面板就能对话。实际体验中，VSCode 集成最大的优势不是聊天，而是代码改动可视化了——AI 改了什么、改了哪几行，编辑器里直接以 diff 形式呈现，我可以一段一段接受或拒绝。这个体验比纯终端里的输出强太多。

配置上要留意的就一点：扩展和命令行共用同一个认证和配置目录，登录状态也是互通的。如果你在公司网络环境下登录异常，先在终端里执行登录相关的授权命令，确认没问题再打开扩展面板，不然扩展会一直转圈。

5.3 让 Claude Code 直接执行终端命令的权限设计

Claude Code 最爽也最危险的能力，就是能直接执行终端命令。默认情况下，它会先请求你的确认（Bash(your command)出现在权限请求列表里），你可以选择 Allow Once / Allow Always / Deny。常用的命令如git status、npm run build你可能会选 Always，但我的建议是用配置文件做更颗粒度的管理。

在.claude/settings.json里可以这样设置：

{ "permissions": { "allow": [ "Bash(npm run build)", "Bash(git status)", "Bash(git diff)", "Read(src)", "Edit(src)" ], "deny": [ "Bash(rm -rf *)", "Bash(sudo *)" ] } }

这样设计之后，Claude Code 在该项目里能执行的就限定在这些命令内，不再每次弹窗询问。我特意把sudo和rm -rf全局拉黑，因为这类命令一旦让模型在错误上下文里执行，后果不可逆。记住：权限配置的目的是让 AI 在三秒内能做的事不出错，而不是把保险丝全拔了。

6. 连踩六个坑之后，我总结的排查链路与避坑清单

6.1 codex 找不到 MCP：从配置路径到日志的全链路排查

先说一个我印象最深的坑：某次 Codex 类工具（包括一些基于 Claude Code agent 循环的脚本）怎么都找不到刚配好的 MCP Server，但claude mcp list里明明能看到。折腾半天之后发现，claude mcp list读的是全局配置，而项目里的工具启动时读的是.mcp.json，两边没对上。

遇到"MCP 找不到/不生效"的问题，我的排查链路是：

1. 确认注册范围：claude mcp list看 Server 是 user 级还是 project 级。工具用的是哪个目录，检查对应的.mcp.json是否在正确位置。
2. 确认传输方式：本地 stdio 型的 Server 依赖command和args，HTTP 型的需要url和正确的认证头。两者配置结构完全不同，最容易混。
3. 手动启动 Server 看报错：把.mcp.json里的 command 手动在终端跑一遍，八成能找到问题——比如 npx 包名拼错、依赖没装、端口被占。
4. 看 stdout 是否被污染：有些 Server 会把日志直接打到 stdout，这会导致 MCP 协议解析失败——JSON-RPC 消息里掺了无关文本，客户端直接挂。这也是我最容易忽略的坑。

6.2 organization has disabled claude subscription access 的三种成因

报错原文是your organization has disabled claude subscription access for Claude Code，我第一次遇到是在把订阅账号切到组织工作区之后。后来排查下来，这个报错通常有几种成因：

• 账号问题：当前登录的是组织托管账号，而组织策略禁止成员把 Claude Code 用于个人工作。对策是退到个人订阅账号。
• 订阅层级问题：你用的是不含 Claude Code 权益的订阅套餐。需要检查订阅层级和配额。
• 认证状态过期：本地的 OAuth 凭证失效，工具仍然以为你有订阅但实际授权已过期。对策是重新执行登录流程，确认claude auth status再继续。

如果不是非用官方订阅不可，另一个解法就是回到章节 4 的路线，用 CC Switch 切到第三方 API 或本地模型，直接从根上绕开订阅配额限制。这也是不少团队的实际选择。

6.3 Skills 不生效与升级后丢失

Skills 写了一堆却不生效，我遇到过的原因就三类：目录名不对、description 写错、功能没开启。目录名和 frontmatter 里的name必须一致，且外层目录和 SKILL.md 文件名不能乱改。description 写得像"用于前端开发"这种，等于每个前端任务都可能触发，又等于永久不触发。另外，某些中间版本里 Skills 需要手动开启，记得在/config里翻一下。

升级后技能丢失的问题我也碰到过。原因是 Claude Code 升级时重置了部分配置目录，而我当时把自定义 skills 放在了被重置路径下。后来我把.claude/skills放进 Git 仓库管理，每次升级前一条命令备份，升级完恢复，再没丢过。任何工程化配置，一旦值得手工维护，就应该进版本库。

6.4 涉及长输出的几个坑：流式写文件与上下文压缩

最后一个坑比较隐蔽，但遇到的人不少：让 Claude Code 生成一个大文件（比如三千行代码、一整份需求文档）时，它经常写着写着就停了，或者输出被截断。这是因为上下文窗口和大模型单次输出长度都有限制。

我的解法是让 MCP 工具直接把内容流式写入文件，而不是让模型一次性把完整内容"说"出来。以 CherryStudio 配合 MCP 写文件这类场景为例，核心思路就是分块写入：模型一边生成，MCP 一边把已经生成的部分追加到文件里，最后再让模型收尾和校验。这样即使生成到一半模型输出被截断，文件里也已经有了大部分内容，重跑成本低很多。

至于长会话，我前面提过/compact压缩工具，别客气，该用就用。另外，大任务拆小批次跑，每批只让模型处理一个完整子模块，也是一种很实用的上下文管理策略。压缩与分块，是长输出场景的两条命。

7. 这套工作流现在的样子，以及我最想给你的三个建议

写到这里，我的日常已经稳定在这套结构里：Skills 管能力，MCP 管连接，CC Switch 调度模型，Ubuntu + VSCode 提供环境。工具本身一直在变，但底层的思考方式基本定型了——不是让 AI 替你干一件事，而是把一件事拆成 AI 能稳定复用的最小单元。

围绕这套工作流，我给同样想从"裸用"走向"工程化"的你三个实在建议：

• Skills 从自己写开始。别急着囤社区技能包，先梳理自己项目里重复劳动最多的三件事，把这三种事写成 skill，你会最快感受到"同一件事下次不用再交代一遍"的爽感。
• MCP 每接一个都要问边界。接之前问自己：这个 Server 是只读还是可写？数据会流向哪里？项目里其他人会不会受影响？MCP 是工程化的加速器，也是安全边界的放大器。
• 模型管理不是玩具，是成本中心。官方模型、第三方 API、本地模型，各有各的用途，不要因为哪个便宜就全线切换。稳定的核心开发路径用强模型，批量机械任务用性价比模型，隐私数据用本地模型，这是我目前验证过最省心的组合。

最后再补一句个人体会：工具迭代的速度永远比你学得快，但"能力分层 + 按需复用 + 边界约束"这套思路不会过时。你现在花在 Skills 和 MCP 上的时间，会在未来每一个新项目里持续回报你。