1. 从“裸用”到工程化的转变起点先说个直观的感受。刚接触 Claude Code 的时候我基本是把它当成一个“高级版终端助手”在用写代码遇到问题就丢给它让它改 bug、写测试、补注释。用了一阵子后效率确实有提升但总觉得差点意思——每次开新项目都要把同样的背景说明、同样的代码规范、同样的工具链配置重新解释一遍Claude 就像个记忆力极差的实习生换个会话就把什么都忘了。后来我做了两件事整个工作流彻底变了个样一是给 Claude Code 装上了Skills二是接入了MCP服务。这两个东西合在一起才真正让我感觉不是在“用”一个 AI而是在“搭建”一套属于自己的 AI 开发流水线。如果你也正在经历从“裸用”到“工程化”的这个阶段这篇文章应该能给你一些参考。我会把 Skills 和 MCP 的原理、选购思路、落地方案、踩坑记录都拆开讲一遍尽量少说虚的多给能直接照做的内容。2. Skills 到底是什么为什么它比“提示词模板”高一个维度2.1 从“每次重复解释”到“一次性定义能力”很多人第一次听说 Skills 的时候会下意识觉得“这不就是预设提示词吗”我在最开始也是这么理解的直到我用过之后才知道区别在哪。预设提示词本质上是“对话前的一次性上下文注入”。它的作用范围仅限于当前会话换个会话就要重新粘贴。而Skills 是“可复用的能力模块”它定义的是“Claude 在特定场景下应该怎么做”的一套行为规范包括任务拆解方式、工具调用规则、输出格式约定、质量检查清单等等。用一次之后这个能力就被“安装”到了 Claude 的运行环境中之后无论开多少个新会话它都记得自己具备这项能力。我举个例子。我平时用 Claude 写前端组件以前每次都要说“请按照我的项目规范使用 TypeScript样式用 CSS Modules组件要支持无障碍访问”。这些话加起来快两百字每次新会话都要复制一遍。后来我把它写成一个frontend-component-developer的 Skill里面不仅包含了这些约束还把组件的验收标准、常见的代码组织方式、首选依赖都定义好了。现在只要在对话里说“用 frontend-component-developer 这个技能帮我写一个下拉组件”它就能自动进入“角色状态”输出的代码直接就能跑通项目里的 lint 规则。2.2 和 MCP 的关系一个是“行为准则”一个是“手脚延伸”再强调一下 Skills 和 MCP 的区别因为很多人会把这两个概念搞混。**MCPModel Context Protocol**解决的是“AI 能触达什么”的问题。它的本质是一个开放协议让 Claude 能通过标准化的接口去读取本地文件、查询数据库、调用外部 API、操作浏览器甚至控制设计软件。如果说 Claude 是个大脑MCP 就是给它接入四肢的通讯协议——没有它大脑再聪明也够不到外部世界的工具。Skills解决的则是“AI 该如何思考和组织行为”的问题。它定义的是工作流程、思维框架和行为约束。有了 SkillsClaude 就像是接受过专业训练的员工——它知道遇到任务该怎么拆解、按什么顺序执行、产出物应该长什么样、怎么样算达标。打个比方MCP 是给 Claude 装上了“手和眼睛”Skill 则是给这个“手和眼睛”配了一本 SOP 手册。没有 MCPClaude 的能力边界受限没有 SkillsClaude 即使能接触到工具也不知道怎么用得高效、用得规范。这两者的搭配才是工程化的关键。我当时就是先装了 Skills让 Claude 知道“写前端组件应该遵循什么标准”又装了对应的 MCP 服务让它能直接读取项目里的设计稿文件、组件库文档、接口定义。这样它不仅能按规范思考还能直接拿真实数据工作产出的准确率直接上了一个台阶。2.3 Skills 市场里值得关注的几个方向目前社区里已经有不少现成的 Skills 可以下载使用我逛了一圈之后发现真正有价值的其实集中在这么几类里面代码审查类这类 Skill 定义了代码审查的检查点比如安全性、性能、可维护性、测试覆盖度等维度能让 Claude 在提交代码前自动跑一遍预审省去很多低级问题。架构设计类针对特定项目框架比如 React、Vue、Spring Boot生成项目骨架、目录结构建议和模块划分方案适合项目启动阶段用。文档生成类把散乱的注释、 API 定义、变更记录自动整理成结构化的项目文档对维护老项目特别实用。测试生成类根据业务逻辑自动生成单元测试和集成测试用例还能根据覆盖率报告补齐缺口。我的建议是刚开始不用贪多挑一两个跟日常开发最相关的就够了。Skills 这东西不是装得越多越好装多了反而会让 Claude 在“该用哪个技能”这件事上产生混乱。我自己的经验是先装一个代码审查类的再装一个跟项目框架强相关的开发类用顺了之后再逐步扩展。3. MCP 的实战接入从环境配置到场景落地3.1 配置的前置条件先理清你的运行环境在聊具体方案之前先把前置条件交代清楚。这里有一个很多新手会忽略的问题Claude Code 的环境兼容性。装不同版本的 Claude CodeMCP 的配置方式会有差异有些功能只在特定版本上开放旧版本可能根本识别不到你配置的 MCP 服务。我个人的实际经验是先确认 Claude Code 版本再动 MCP 的配置。如果你在自己的环境里运行claude --version发现版本比较旧建议先升级到最新版。新版对 MCP 的支持更完整包括 SSE 传输、流式输出这些能力都有改进。另外如果你的 Claude Code 用的是第三方 API比如通过 CC Switch 这类工具接入其他模型服务商有些 MCP 功能可能不受支持。这跟 MCP 协议的实现程度有关系不同的模型服务商对工具调用的支持力度不同。我试过在本地模型比如通过 LM Studio 跑开源模型上挂 MCP结果是模型能收到工具定义但实际调用经常超时或返回格式错误。后来我干脆把“需要通过 MCP 来操作”的任务都保留在云端 Claude Code 环境里执行把本地区域留给纯代码生成和审查这类任务。3.2 三种主流 MCP 配置方案的对比MCP 服务接入的方式很多我这个项目里实际尝试过三种各有优劣直接说结论接入方式适用场景优点缺点stdio 模式本地工具链集成如文件系统、数据库连接配置简单直接在claude mcp add里指定启动命令即可只适用于同一台机器上的进程间通信不支持远程调用SSE/HTTP 模式远程服务、跨设备调用一台机器启动服务其他设备都能共享需要额外维护服务进程需要考虑鉴权和安全性WebView 内嵌模式需要在图形界面上展示结果的场景体验好能看到可视化的内容配置最复杂对版本要求也更高我实际的建议是如果你只是在自己开发的这台电脑上用优先选 stdio 模式。它的稳定性和易用性最好出现问题的概率最低。当你有跨设备需求、或者想让团队共享一套 MCP 服务的时候再升级到 SSE 模式。3.3 完整示例把本地文件系统接入 Claude Code我用一个最简单的例子来演示配置过程目标是让 Claude 能直接读取指定目录下的文件内容。配置命令如下claude mcp add filesystem -- stdio npx -y modelcontextprotocol/server-filesystem /Users/yourname/projects如果你不想用命令行配置也可以直接改配置文件。Claude Code 的配置文件位置通常在~/.claude.json打开之后找到mcpServers字段手动添加即可。加入之后在 Claude Code 里跑一下/mcp命令就能看到当前已加载的 MCP 服务状态。如果显示为 connected说明接入了成功。之后你让 Claude 读某个文件它就会直接调用这个 filesystem 工具去操作而不再依赖对话上下文里的“历史记忆”。3.4 接入 IDE 类 MCP 的场景扩展我后来又把 MCP 接入了几个开发场景效果都挺明显的挑两个有代表性的讲一下。一个是接入Figma MCP。前端开发最头痛的事情就是“设计稿和代码不对齐”。我以前是人工对着设计稿量尺寸、取色值费时费力还容易出错。接入 Figma 的 MCP 服务之后Claude 可以直接读取设计稿中的组件信息、样式参数和布局结构生成出来的代码基本不用做大的调整。另一个是接入蓝湖 MCP。蓝湖是很多团队做设计交付的常用工具接入之后 Claude 可以直接获取蓝湖上的标注信息、切图资源和交互备注。这一步省掉了我大量来回切换工具的时间消耗。其实很多流行的设计协作工具都已经支持 MCP 或者有相应的社区实现关键在于你要去“找”。找 MCP 服务有一个固定的思路搜索 “工具名 MCP”大概率能找到官方或社区封装的实现比如Altium Designer AI 接口 MCP、IDA MCP、x32dbg MCP这些都是社区里已有的现成方案。4. 工程化落地的关键拼图把 Skills 和 MCP 串成完整流水线4.1 先搭“骨架”用 Skill 定义流程用 MCP 提供数据工程化改造这件事最难的不是搞懂单个工具怎么用而是怎么把零散的“能力碎片”组合成一条真正能跑的流水线。我自己摸索下来核心其实是四个字先定标准再接数据。标准指的是“流程规范”需要用 Skills 来定义。比如我有一个 “新功能开发” 的 Skill它的流程定义是分析需求描述拆解出功能点清单定位现有代码中受影响的所有模块读取涉及模块的代码结构与核心逻辑设计实现方案列出改动文件清单按依赖顺序依次实现每完成一个模块就自测输出变更摘要和受影响范围说明书在定义这套流程之前Claude 写代码基本上是“点对点”你说什么它写什么没有任何任务理解、影响面分析的动作。有了这套 Skill 之后它就变成了一个“正规军”接到任务先做分析绕着代码库做完整调研然后才动手写代码。虽然单次任务的速度慢了一点点但产出物质量、代码一致性和后期返工率都明显变好。标准定好之后剩下就是“数据供给”。这就是 MCP 的主场我把项目的接口文档通过一个自定义 MCP 服务暴露、设计稿信息通过 Figma MCP、数据库 Schema通过一个数据库 MCP都接入进去Claude 在按 Skill 流程执行任务的过程中不需要我手动粘贴任何上下文需要什么直接调用工具获取。4.2 单条流水线的执行细节我拿一个实际经历过的任务来完整复盘给一个后台管理系统新增“角色权限配置”页面。如果没有 Skills 和 MCP我过去的做法是在对话里把需求告诉 Claude → 把相关的代码文件内容粘贴进去 → 让它改 → 改完再去翻查组件库的规范逐个核对 → 发现问题再回头改。有了 Skills 和 MCP 之后流程变成了我在对话里只输入需求“用 frontend-admin-developer 这个 Skill 给角色权限页面的 UI 增加模块。”Claude 自动读取了这个 Skill 里的工作流程先分析了需求列出了“权限配置页需要支持的交互逻辑”“当前管理系统的前端架构约束”“组件库中可复用的基础组件”这三个待确认的信息。随后它通过 MCP 调用项目文件系统自动识别出权限页面相关的目录和文件又通过数据库 MCP 查看了后台的权限表结构和已有的接口定义。在确认信息完整后它按照 Skill 里定义的组件编写规范生成了完整实现代码并同步输出了对这一改动影响的文件清单和潜在风险点。整个过程中我只说了第一句话和最后一句“确认可以提交”。中间大量繁琐的“上下文搬运”工作全部由这套机制自动完成了。4.3 可复用的工程化实践清单如果你也想把自己的 AI 开发工作流从“裸用”往“工程化”方向推我总结的这几条建议是可以直接照搬的从项目骨架开始沉淀 Skill。每个项目团队都有自己的代码规范、目录组织方式和提交规范把这些沉淀成一个 Skill让 Claude 在项目里默认遵守。按“开发流程”而不是“单一动作”来设计 Skill。比如不要只写一个“生成接口调用代码”的 Skill而要写一个“新增一个数据请求闭环”的完整流程。MCP 优先接入“直接影响产出准确性”的数据源。比如你们项目的真实接口定义、数据库 Schema、设计稿图标信息这些数据是 AI 生成代码的“参照物”有和没有差别巨大。建立工具的“默认组合”而不是“大杂烩”。给不同的任务类型搭配固定的 MCP Skill 组合比如“前端开发 代码规范 Skill 项目文件系统 MCP 设计稿 MCP”不要每次都临时翻找工具。5. 实操过程中的高频问题与排查实录5.1 Skill 装了但 Claude 不调用怎么办这是我被问过最多的问题。Skill 装了也确认出现在列表里但让它执行任务的时候Claude 就是不按照 Skill 定义的行为来。这个问题我排查了几次之后发现根源多半出在Skill 的触发表述上。Claude 不是每次都会主动去检索所有已安装的 Skills它需要明确的信号才会“进入技能状态”。解决方案其实很直接对话中直接用“使用 XX 技能”“按照 XX 技能的定义来做”这类引导句式。更稳妥的做法是在你的 Skill 内容里定义一个“触发条件”字段或者“核心适用场景”说明让 Claude 能通过上下文的匹配更大概率地命中正确的 Skill。5.2 MCP 配置了但显示连接失败这类问题我踩过不少次常见的就三种原因启动命令写错了。stdio 模式下的启动命令如果带了不能被正确解析的参数服务就会起不来。依赖缺失。有些 MCP 服务依赖 node 的特定版本或者需要额外的环境变量少了就加载失败。网络受限。远程 SSE 模式的 MCP 服务如果目标是国内不可直连的地址连接大概率会直接失败。我的排查习惯是三步走先看claude mcp list确认配置信息再用/mcp查看运行状态最后手动在终端里运行一遍当时的启动命令看有没有报错信息输出。这个操作能解决掉 90% 的问题。5.3 工具调用看起来“生效了”但输出不可用还有一种微妙的情况MCP 工具确实被调用了返回的数据也拿到了但 Claude 最后的输出结果不可用。我之前接数据库 MCP 的时候就遇到过它把整个表结构读出来之后生成的代码里居然用了不存在的字段。后来分析发现问题出在Skill 里面对“如何处理数据源”的约束不够。也就是说Claude 拿到了数据但不知道该怎么用这些数据于是它按照自己“默认的理解”来写代码而不是按照你项目的真实情况。解决办法也很简单在 Skill 的编写规范里补充一条“在进行代码生成前先核对数据源字段定义所有输出的字段必须来自真实存在的数据定义”这样的约束条件。你的 Skill 让 Claude 与真实数据的绑定越紧密输出的可用性就越高。5.4 团队协作时的“环境一致性问题”如果你不是一个人在折腾而是要把这套工作流复制给整个团队那么大概率会遇到环境不一致的问题。我这边实际处理过的情况是同事的电脑上装了旧版本的 Claude Code导致同一个 Skill 在他的环境里表现不一致还有人完全没配置 MCP同一个任务在他们的环境里就是纯靠对话硬猜。我的建议是做一个团队内部的环境初始化文档里面明确写出三个东西一体化的配置步骤从 Claude Code 版本、到 Skills 安装、到 MCP 服务启动命令、一个最小可用的验证用例、以及每个人各自需要修改的个性化参数比如项目路径、数据库连接配置。这样新同事加入的时候照着文档走一遍五分钟内就能把整套“工程化”能力跑起来。6. 关于 Skill 开发的一点个人心得用了一段时间现成的 Skills 之后我开始尝试自己开发一些定制 Skill。这块目前社区里讨论得很多但大部分内容都集中在“怎么写一个能跑的 Skill”这个层面。我个人觉得比“怎么写”更重要的是“怎么设计”。一个真正好用的 Skill需要做到三件事有明确的职责边界、有可执行的行为步骤、有可量化的输出标准。不要贪大求全一个 Skill 里面塞太多内容反而让 Claude 在执行时失去焦点。我自己的经验是一个 Skill 最好只解决一个类型的问题比如“代码审查”“生成接口联调用例”“输出变更影响分析”各做一个独立的 Skill使用起来最顺手。也不建议过于追求“通用”。有些人的理想是写一个能应对所有场景的“超级 Skill”结果做出来之后发现质量和直接让 Claude 自由发挥差不多。真正有价值的往往是那些和你实际项目绑定得很紧、沉淀了大量项目特定经验的 Skill。7. 一点关于工作流的总结性感悟最后说点心里话。做了这套工程化改造之后我最大的感受并不是“AI 写代码的速度变快了”而是“我对 AI 产出的信任度变高了”。裸用时代的最大痛点其实不是效率而是不确定性。你永远不知道它这一轮会输出什么质量的代码也不知道它会不会遗漏某个关键的上下文。这种不确定性导致你每次都要完整审查它的输出审查成本一高AI 的价值就被稀释了。Skills MCP 这套组合解决的核心问题恰恰是把不确定性一点点压下去。Skill 让 Claude 的行为有据可依MCP 让它的判断有真实数据支撑。当它的产出稳定可预期了你才敢把更多关键任务交给它去执行。如果你现在也处在“裸用”状态我建议你从一个小切口开始先把你的核心代码规范写成一个 Skill再给 Claude 接入一个你最常用的本地文件系统 MCP然后用一周时间观察它的产出变化。多数情况下一周之后你就不会想退回去了。