最近半年我的日常开发基本都泡在 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 的眼睛和手全是断的。我印象很深的一次是要它根据蓝湖的设计稿还原一个页面。我先把几张截图和标注文字贴给它它理解得七零八落还原出来的间距、字号全不对。后来接了蓝湖 MCPClaude Code 能直接读取图层树和样式标注那次还原质量完全不是一个量级。所以说工作流要是没有 MCPAI 开发助手的上限只是能改代码而不是能干活。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 我自己留下的三组 Skillssuperpower 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.txtSKILL.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 是什么我一句话讲清楚MCPModel Context Protocol模型上下文协议是一个标准化协议它定义了大模型应用客户端和外部数据/工具服务端之间怎么通信。我一般用AI 世界的 USB-C来类比以前每个 AI 要接一个工具就得专门写一套私有接口有了 MCP 之后只要工具那边提供一个符合协议的 ServerClaude 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 我实测过的领域 MCPUnreal、Altium、IDA、TIA、设计协同MCP 的价值有时候不亲身体会很难讲透我列一下自己实际配过的几个领域你可以对照自己的行业看看有没有对应的兴奋点。场景MCP 服务接入后能做什么我的使用感受游戏开发Unreal 5.8 MCP查询资产、读取蓝图、操作关卡、辅助 C 代码生成编辑器里可视化操作 AI 生成逻辑是真省事但必须保证 MCP 插件端口没被防火墙拦硬件/EDAAltium Designer AI 接口 MCP读原理图、PCB 工程结构让 AI 辅助检查器件连接和布线约束适合做批量命名和规范检查但输入大批量数据时要小心 token 爆炸建议先只读当前页逆向分析IDA MCP、x32dbg MCP 插件把反汇编结果、调试器状态喂给 AI 辅助分析对分析混淆代码特别有用但这类场景风险高一定要隔离环境运行工业自动化TIA MCP与西门子 TIA Portal 工程交互辅助生成和理解 PLC 程序交付包这种形式对工艺工程师挺友好但建议先在小工程验证再接产线设计协同Figma MCP、蓝湖 MCP读取图层树、标注、样式变量前端还原设计稿的利器解决了我开头说的截图粘贴看不懂的问题工作流自动化Dify 浏览器 MCP让 AI 操作浏览器配合 Dify 的可视化编排做数据采集、表单填写适合做重复性网页操作但别让它接触支付、登录后的敏感页面以 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_URLhttps://your-gateway.example.com/anthropic export ANTHROPIC_AUTH_TOKENsk-your-key export ANTHROPIC_MODELdeepseek-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_URLhttp://localhost:1234 export ANTHROPIC_AUTH_TOKENnot-needed export ANTHROPIC_MODELqwen2.5-coder-32b跑起来之后Claude Code 能正常对话但我要给个真实评价本地模型的 tool calling 稳定性明显弱于云端旗舰模型。具体表现是让它调用 MCP 工具时偶尔会把参数类型写错或者在一次循环里反复调用同一个工具拿不到结果还不退出。后来我的解决方案是本地模型只用来做代码解释、文档生成、简单的文件修改凡是涉及多步骤 MCP 调用和复杂重构的任务一律切回云端强模型。这不算妥协而是让合适的模型干合适的活。4.4 模型切换后的真实差异与成本控制把几种接入方式放一起对比感受会更直观接入方式tool calling 稳定性延迟成本我用来干什么Claude 官方订阅最稳几乎不翻车中订阅内核心开发、复杂 agent 任务DeepSeek / Qwen / GLM 云端 API中上复杂工具链偶尔出错中低较低按量计费批量重构、文档、日常问答LMStudio 本地模型中下依赖模型尺寸看机器电费隐私敏感代码的辅助解释成本控制这块我的经验是两条一是给 Claude Code 设好模型别名和上下文上限避免它无脑堆长上下文二是善用/compact压缩历史长会话跑久了上下文里全是旧的工具返回结果既费 token 又影响模型注意力。工程化工作流里上下文管理本身就是一项核心技能不会压缩上下文的人跑复杂任务一定又慢又贵。5. Ubuntu VSCode把工程化工作流钉在常用环境里5.1 Ubuntu 下安装与升级的细节我日常主力环境是 UbuntuClaude 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 找不到/不生效的问题我的排查链路是确认注册范围claude mcp list看 Server 是 user 级还是 project 级。工具用的是哪个目录检查对应的.mcp.json是否在正确位置。确认传输方式本地 stdio 型的 Server 依赖command和argsHTTP 型的需要url和正确的认证头。两者配置结构完全不同最容易混。手动启动 Server 看报错把.mcp.json里的 command 手动在终端跑一遍八成能找到问题——比如 npx 包名拼错、依赖没装、端口被占。看 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 上的时间会在未来每一个新项目里持续回报你。