如果把 Claude Code、Skills、MCP 这三样东西拆开看每一样单独拿出来都不算复杂可一旦把它们组合进同一条开发工作流我的日常开发方式确实被改写了。最早我是裸用Claude Code 的——在终端里开个对话让它改点代码、写个函数用起来跟高端聊天窗口差不多新鲜感过了就开始失望。真正让我改变的是两件事给 Claude Code 配上了 Skills又把 MCP 服务接进了项目。前者像给模型一份作业指导书后者像给模型装上手和眼睛。这篇文章就把我从裸用到工程化的完整过程讲透包括这三者分别解决什么问题、怎么安装怎么配置、怎么写自己的 Skill、怎么按项目选 MCP以及过程中踩过的那些坑。1. 裸用 Claude Code 的三条翻车链路以及我现在怎么回头看1.1 裸用到底意味着什么我先把裸用这个词定义清楚免得后面大家对不齐。所谓裸用就是只把 Claude Code 当作一个终端里的对话助手你问一句它答一句偶尔让它改个文件、跑个命令。除此之外不配任何 Skills不接任何 MCP 服务也没有项目级的规则文件。听起来好像也够用我最初就是这么想的一个能看懂代码、能写代码的对话窗口已经比绝大多数工具强了。但问题恰恰出在没有上下文约束上。一个刚装好的 Claude Code面对你的仓库时它并不知道这个项目用什么框架、依赖了哪些包、版本策略是什么团队的代码风格、目录规范、命名约定是什么改动之后要不要跑测试、跑 lint、更新文档哪些目录能碰、哪些文件不能碰。于是它只能靠你的对话去猜猜错了就瞎改改完了你还要人肉收拾。这就是裸用的本质——你给了一个很聪明的模型却没有给它任何工作环境说明。1.2 三条最有代表性的翻车链路我这三个月里的翻车总结下来可以压缩成三条链路。第一条改代码不跑验证。我让 Claude Code 重构一个模块它很痛快地改完了然后告诉我改好了。本地编译、单测、lint 全没做。我人在开会等合并完 CI 一片红同事过来问我怎么回事。后来我才意识到它不是不想跑是它压根不知道自己应该跑——我不会每次都想起来说改完记得跑测试。第二条文件落地完全无视目录约定。项目里明明有src/utils和src/components它会把工具函数塞到组件目录下面还自己新建了一层嵌套。原因是它只看到了文件系统快照没看到团队约定对应该把代码放哪里这件事几乎没有任何判断依据。第三条长对话失忆。聊到第 40 轮它开始忘记前面定的技术方案。你以为它记住了实际上上下文已经被大量代码片段挤爆了早期的关键决策早就被截断。于是它后面给的方案经常推翻自己前面说的话。这三条链路的根因是同一个模型有通用能力但没有专用上下文。裸用相当于把一个大模型直接空降到你的仓库里既不告诉它纪律在哪里也不给它任何干活用的手。它当然会自由发挥。1.3 我最终想明白了模型不缺能力缺的是作业指导书和手后来我翻了很多资料包括官方对 Agent Skills 的说明才慢慢把这件事想清楚模型本身不缺推理和编码能力缺的是两样东西——行为约束和工具接口。行为约束就是 Skills 要做的事。Agent Skills 这套机制在 2025 年推出后解决的是让模型在特定任务里按标准流程执行的问题。它不是简单地把一大段提示词塞进上下文而是让模型在遇到某个触发场景时主动去读一份作业指导书按里面的步骤干活。工具接口就是 MCP 要做的事。MCPModel Context Protocol把模型和外部工具通过一个标准协议接起来让 Claude Code 能操作文件、浏览器、数据库、调试器、甚至工业软件。没有 MCP 的时候模型只有一张嘴接上 MCP它才有了手和眼。顺带说一句Claude Code 本身允许模型在受控范围内执行终端命令——前提是你在设置里开了对应权限这一点很多人不知道。但裸用状态下命令执行往往是随机尝试配合 Skills 的流程约束之后它才会变成按步骤执行命令才开始有了明确目的。这两样东西是互补的Skills 管怎么做MCP 管能做什么。不理解这一点后面配置再多工具都是堆砌。2. Skills给模型配一份看得懂的作业指导书2.1 先纠正一个误解Skills 不是把提示词变长很多人第一次接触 Skills会以为它就是把 system prompt 写得更长、更详细。这个理解有偏差。Skills 在 Claude Code 里是一种结构化的目录核心是SKILL.md文件里面用 YAML frontmatter 声明 name 和 description正文写具体执行步骤旁边还可以挂scripts目录放可执行脚本挂resources目录放模板和示例。关键设计在于触发-加载机制。Claude Code 在跑任务时会根据任务描述去匹配 Skills 的 description匹配到了才去读对应的 SKILL.md。也就是说Skills 不是每轮对话都在上下文里的常驻大段文本而是按需加载的知识包。这样既省上下文窗口又对路——你让它写代码的时候它不会把写文档的 Skill 先读一遍。对比一下把一大段提示词贴进 system prompt 的做法区别很明显提示词是塞给它的Skill 是它自己根据需要去读的后者不需要每轮都占用宝贵的上下文空间维护起来也是独立文件不用动整个项目的提示词配置。2.2 官方生态和社区资源从 superpower skills 到 codex skills我现在搭的这套 Skill 体系一半来自社区一半自己写的。先说你能直接拿来用的。GitHub 上搜 awesome claude skills能找到不少聚合仓库官方文档也维护着一份 Skills 指南讲怎么写、怎么挂载、怎么在项目里发现可用技能对应的命令类似find skills各家客户端叫法略有差异思路一致。社区里流传比较广的是 Superpower Skills 系列它把编码、调试、需求拆解、文档撰写这类高频场景拆成了一组细分的 Skill 包每个包都带独立目录和说明装完就能感觉到 Claude Code 的处事风格明显变得更稳。这里要提一个趋势Skills 正在跨工具扩散。OpenAI 的 Codex 也有了自己的 skills 体系GitHub 上有很多 skills 模板可以直接迁移——因为核心结构都差不多SKILL.md scripts resources 这套骨架已经成了事实标准。所以我现在写一个 Skill会刻意写成可迁移的只依赖通用目录结构不写死 Claude Code 专属配置。这样哪天 Codex 也接进来了同一份 skill 基本不用改。至于 skills 下载平台除了 GitHub 搜索和 awesome 聚合仓库不少开源社区站点也做了可视化浏览甚至有一些客户端像 Reasonix提供了更友好的 skills 安装入口逻辑都类似找到仓库、装进本地的 skills 目录、在配置里启用。2.3 实测前端项目配上 Skills 之后代码质量的变化我拿自己一个 React 项目做了对照。没配 Skills 之前让 Claude Code 加一个错误边界组件它会直接开写完全不看项目里有没有现成的错误上报组件、有没有封装的 ErrorBoundary 基类。配了一套前端开发 Skill包含需求确认、组件设计、编码自测三个步骤之后同样的任务它的动作变成了先读 package.json 确认 React 版本再扫描 components 目录看有没有可复用的基类然后才动手写写完自动跑 lint 和 build。说实话第一次看这个流程完整跑下来我还是有点惊讶的。整个过程我没有输入一句额外指令它自己就按 Skill 里的流程把上下文搜集齐了。这才是 Skills 的价值——它不是让模型变聪明是让模型在特定场景里的职业习惯变好。同类的还有一堆现成好用的code review 类的 Skill、写 commit message 的 Skill、写论文的 Skill社区里叫 codex 写论文的 skills本质上 Claude Code 也能用、需求拆分的 Skill 等等。装 Skills 之前最好想清楚一件事高频场景优先配。低频场景配了反而是负担因为技能列表一长模型反而可能在关键时刻选错包。3. MCP打开模型能力边界的那扇门3.1 用 USB-C 的类比理解 MCP 协议MCP 全称 Model Context Protocol是一条公开协议。我平时跟同事解释它喜欢用 USB-C 做类比以前每家手机厂商都有自己的充电口你要带一堆线USB-C 统一之后一根线通吃所有设备。MCP 做的就是类似的事——它把模型要调用外部工具这件事标准化了。在这个协议里有三个角色MCP Server 负责把某个能力包装成标准接口比如文件系统 Server、浏览器 ServerMCP Client 是发起请求的一方Claude Code 就是这个角色协议本身则通过一条基于 JSON-RPC 的通道完成工具发现、调用和资源读取。因为有了这套协议Claude Code 不需要为每个外部工具写专属集成代码。谁想接什么能力就自己写一个 MCP Server模型侧能自动发现。这也是为什么过去一年里 MCP 生态能爆发——各种垂直软件都开始自己做 MCP 服务而不是等 AI 厂商来适配。3.2 我常用/实测过的 MCP Server 清单下面的列表是我真实在项目里接入、并且觉得值得写出来的MCP Server解决什么问题我的使用场景Filesystem文件与目录操作让 Claude Code 直接读写项目文件、批量替换Playwright浏览器自动化端到端测试、爬页面、复现前端 bugGitHub仓库与 PR 操作自动提 PR、查 issue、读 CI 状态Figma设计稿上下文前端开发时让模型看懂设计稿的图层和样式IDA / x32dbg 插件二进制与调试逆向分析时让模型读取反汇编、下断点Unreal 5.8 MCP虚幻引擎工程操作游戏开发中读写关卡、蓝图、资源Altium Designer MCPPCB / 原理图硬件设计里让模型操作 EDA 工程Dify 浏览器 MCP自动化网页操作低代码流程里驱动浏览器动作这里得提醒一句MCP Server 的质量差异非常大。官方维护的几个比较稳社区第三方 Server 我一般先看 README、看 Star 数、看最近有没有更新再决定要不要装进项目。毕竟 MCP Server 拿到的权限通常是真权限瞎装等于把仓库钥匙交出去。授权问题在上手时最容易卡住。以 Figma 为例你需要先在 Figma 开发者平台生成一个 Personal Access Token然后在 MCP Server 的配置里把它作为环境变量填进去模型才能替你读设计稿。蓝湖 MCP 也是类似的思路——先拿 token再配环境变量。这一步卡住的大多是 token 权限范围没选对不是协议的问题。3.3 一个值得单独拿出来说的需求把模型输出流式写到文件很多人以为 MCP 是给重活用的其实一些看似不起眼的小需求MCP 也解决得很香。比如把模型输出的内容流式写到文件。以前我让 Claude Code 生成一份长文档它经常在终端里磨磨蹭蹭输出我又要手动复制粘到 Markdown 文件里长文档复制还容易断行。后来我发现可以直接挂一个输出类型的 MCP Server让它把内容按增量流式写入指定文件生成逻辑和落盘逻辑分离。这个需求听起来小但在做批量内容生成、代码仓库文档化这类任务时体验差异非常大。我也见过有人在 Cherry Studio 这类客户端里做同样的流式输出落盘原理大同小异——都是借助 MCP 通道把模型输出转成文件操作。核心就一句话只要模型和文件系统之间有了标准的工具通道很多复制粘贴搬运工的工作就可以取消了。4. 把环境搭对安装、配置与多模型切换的完整实操4.1 安装和 VSCode 集成的正确姿势Claude Code 的安装其实不难。我用的方案是 npm 全局安装npm install -g anthropic-ai/claude-code装完在终端里执行claude就能进入交互界面。升级也简单Claude Code 支持在线升级命令行里跑一次claude update就能同步到最新版本。另外官方也提供了一键安装脚本适合不想碰 npm 的情况不过我个人还是习惯 npm因为后续版本回退更直观。在 VSCode 里配合使用是另一个高频选择。安装好 Claude Code 之后可以直接把它当成一个终端面板拉起来也可以安装官方/社区提供的扩展在编辑器里跑命令。我自己的偏好是VSCode 只负责代码编辑和查看 diffClaude Code 跑在独立终端两边通过文件系统同步。这样分工清晰Claude Code 改完文件我立刻能在编辑器里看到变化又不至于被它的每一步操作打断。有一件事我踩过坑在 Ubuntu 等 Linux 环境上如果 Node.js 版本太老npm 全局安装容易失败或者跑起来报错。建议先把 Node 升到 18 以上再装省得后面排错。4.2 用 CC Switch 管理多套模型配置DeepSeek/Qwen/GLM这里先纠正一个容易混的概念。Claude Code 官方默认接的是 Anthropic 的模型但它的接口地址是可以覆盖的。很多第三方服务提供了兼容的 API 端点于是社区里出现了像 CC Switch 这样的配置管理工具用来在多个模型供应商之间快速切换而不需要手动改环境变量。我用 CC Switch 接过的模型包括 DeepSeek 的 V4、阿里的 Qwen、智谱的 GLM。切换之后Claude Code 的使用体验几乎不变但成本和可用性有了更多选择。尤其是当官方入口在高负载时段不稳定时切到第三方端点能救急。实际配置上CC Switch 本质上是把你的供应商列表保存成配置切换时自动重写相关的环境变量或配置文件。它只是一个标准的配置管理器。我更建议你在项目团队里使用时把不同供应商的配置统一写进一份说明文档谁要用哪家跑一下切换命令就行别各自乱配。4.3 本地模型接入LM Studio 当 Claude Code 的推理后端还有一个很实用的玩法让 Claude Code 调用本地模型。我用的是 LM Studio加上一个适配层的方案。这里有个技术细节要说明Claude Code 期望的是 Anthropic 格式的请求而 LM Studio 这类本地推理工具通常提供的是 OpenAI 兼容接口。要让两端对上需要中间加一层转换把 Anthropic 格式翻译成 OpenAI 格式。CC Switch 或者 claude-code-router 这类工具都在做这件事。大概的操作路径是在 LM Studio 里加载一个模型并启动本地服务默认端口通常是 1234在适配工具里把模型供应商指向http://localhost:1234/v1切到本地模型作为当前供应商然后在 Claude Code 里正常发指令。本地模型的好处是数据不出机器适合处理敏感代码缺点是能力和速度都弱于官方模型我一般只拿它做轻量任务和离线演示。要是你的主力场景是大量重构和代码生成本地模型暂时还顶不上。5. 手写一个自己的 Skill从 SKILL.md 到 scripts5.1 一个 Skill 文件夹里到底该放什么写自己 Skill 的念头大部分人都是在配了别人写的但总感觉不对味之后冒出来的。别急先从目录结构开始。一个标准 Skill 目录长这样code-review-skill/ ├── SKILL.md ├── scripts/ │ ├── collect_changes.py │ └── run_review.py └── resources/ └── review-checklist.mdSKILL.md是入口模型靠它判断触发场景和执行流程scripts/放实际操作脚本模型可以调用它们去收集信息、执行分析resources/放辅助资料比如检查清单、示例模板模型在需要时可以读取。这套结构不是官方强制的但现在已经成了事实标准跨工具迁移都方便。我见过不少人图省事把所有东西都塞进SKILL.md不要脚本也不要资源文件。短期能用长期维护会很难受——模型上下文里塞不下那么长的文字真要执行复杂逻辑时又没有脚本可以调。5.2 写 SKILL.md 的顺序先定义触发条件再设计工作流写 Skill 最容易犯的错误是一上来就写执行步骤。我建议反过来先把触发条件写清楚。触发条件写在 frontmatter 的description里。这句话非常重要因为模型是靠它来判断当前任务要不要加载这个 Skill。写得太泛模型什么都想用反而干扰写得太窄模型又压根发现不了它。比如我写代码审查 Skilldescription 会写成当用户要求进行代码审查、提交信息检查、代码质量评估、或 review PR 时使用……第一时间把所有会触发这个场景的用户表达法列进去。触发条件定好后再设计工作流。我的习惯是分成 35 个阶段每个阶段明确三件事输入是什么、采取什么动作、产出什么校验物。拿代码审查 Skill 举例SKILL.md 的正文骨架大概是--- name: code-review description: 当用户要求进行代码审查、提交信息检查、代码质量评估、或 review PR 时使用本技能。 --- # Code Review ## 步骤 1收集变更 运行 scripts/collect_changes.py 获取 git diff列出涉及文件。 ## 步骤 2定位风险 按依赖变更、逻辑分支、异常处理三个维度扫描变更内容。 ## 步骤 3输出报告 把问题按严重级别分类每条给出修改建议存为 review-report.md。把这个结构写进 SKILL.md 后实测下来 Claude Code 在审查时的动作明显更有条理。5.3 用 Agent 自己来折磨你的 Skill写好 Skill 之后我强烈建议做一轮自我折磨测试。方法很简单准备 510 个不同形态的任务输入给已经配置好的 Claude Code观察它有没有正确加载这个 Skill、加载后有没有按 SKILL.md 的流程执行、中途有没有卡住或者跑偏。这里分享一个我复盘出来的经验Skill 的 description 需要根据测试结果反复调措辞。我第一次写的代码审查 Skill用帮我看看最近的改动有没有问题去触发结果模型没有加载它直接当普通问答处理了。后来我把 description 改得更直接、更贴近用户原话再测就能稳定触发了。社区里管这一类测试叫 agent skills testingGitHub 上也有对应的测试工具和框架。我自己的做法更朴素做一个固定的评测任务集每次改了 Skill 就跑一遍对比。这套回归思路对维护多个 Skill 特别有用因为改了一个 Skill很可能会影响其它 Skill 的触发率。有一类社区习惯把 Skill 写得特别自然语言化让流程尽可能像人类的工作习惯这一类常被叫做 nature skills——我自己的体会是自然语言化的 Skill 更容易被模型理解但后期调试也会更费嘴皮子得平衡。6. 项目级选型与工程化落地按领域选 MCP按团队沉淀 Skills6.1 不同领域怎么搭 MCP Skills到最后一步你会发现最核心的问题不是哪个工具好而是我的项目该上什么。我整理了一个按领域划分的对应表都是我实际接触过或看到真实案例的领域推荐 MCP / 插件Skill 侧重点典型场景Web 前端Figma MCP、Playwright、Filesystem需求拆分、组件设计、自测设计稿转页面、自动化回归游戏开发Unreal 5.8 MCP关卡设计、蓝图调试、资源管理UE 工程内批量操作硬件 / EDAAltium Designer MCPPCB 规范检查、元件库管理原理图/PCB 的脚本化操作逆向 / 调试IDA MCP、x32dbg MCP 插件反汇编分析、断点调试恶意样本分析、崩溃现场排查工业自动化西门子 TIA Portal 的 MCP 服务社区方案PLC 程序审查、导出交付物工控工程文件自动化处理企业业务系统项目自带 MCP 合并方案如 ruoyi-vue-pro 社区添加的 MCP 功能需求文档、权限说明让 Agent 理解内部系统结构这张表的核心逻辑是先看这个领域的高频操作是什么再去找能把该操作标准化的 MCP ServerSkills 则负责把该领域的工作流程写成模型能照做的步骤。两者配合才叫工程化只堆工具不配流程还不如裸用。6.2 不是所有场景都适合上 MCP我必须泼一盆冷水MCP 不是越多越好。原因有三权限风险。每个 MCP Server 都意味着额外的权限通道。接了一个第三方 Server等于让模型多了一处可以操作真实环境的入口。没有经过审核的 Server千万不要往正式项目里塞。维护成本。Server 要装、要配置、要升级有些还依赖特定版本的外部软件。接了 10 个 Server光维护就够喝一壶。延迟和不确定性。调用外部工具意味着要等待、要处理失败会让整个任务链路变得脆弱。我给自己的底线是一个工作流闭环里确实缺哪一环才补哪一类的 MCP Server。宁可少接不要瞎接。如果你在 Codex 里遇到找不到 MCP这类问题先查配置路径和权限别急着换工具——大多数时候是路径或环境变量的问题不是协议的问题。6.3 从个人经验到团队资产让新成员一键上手工程化的最后一步是把个人经验沉淀成团队可用资产。我给团队做这件事的三个动作可以参考。第一在项目里维护统一目录.claude/skills把团队的代码规范、审查流程、文档模板全翻译成 Skill 文件。这东西跟 README 一样是项目的资产跟着仓库走。第二把 MCP Server 的清单和配置说明写成一份mcp-setup.md标注哪些是官方维护的、哪些是社区方案、各自需要什么权限。新成员照着文档跑一遍半小时内就能把环境拉齐。第三把踩坑记录回填到 Skill 里。比如我们发现改完代码必须跑一遍 lint test是团队铁律就把这步写进所有编码类 Skill 的末尾。等于是把组织经验固化进了 Skill 本身。我个人在做了这套工程化改造之后最直观的感受是Claude Code 从一个我不断纠偏的工具变成了一个大多数时候不需要我盯着的协作者。Skills 让它懂规矩MCP 让它有手有脚而工程化的过程不过是把这两样东西变成项目基础设施的一部分。如果你现在还在裸用我建议从最小的闭环开始先找一个最高频的场景写一个 Skill再挂一个最需要的 MCP Server跑通一个完整任务。等这个闭环稳定了再谈扩展。工程化不是一步到位的是长出来的。