1. 从“裸用”到工程化我的 AI 开发工作流重构之路1.1 为什么“裸用”大模型写代码迟早会崩我最开始用 Claude Code 的时候跟大多数人一样就是打开终端敲一句“帮我写个用户登录接口”然后等它吐代码。刚开始确实爽几秒钟出结果复制粘贴就能跑。但用了不到两周问题就全冒出来了。第一个坑是上下文漂移。同一个项目里我先让它写了一个UserService过两天再让它写OrderService它完全不记得UserService里定义了哪些方法、用了什么命名规范、返回体是什么结构。结果就是两个 Service 各写各的一个用ResultT包装一个直接返回实体类前端对接的时候直接懵了。第二个坑是重复劳动。每次新开一个会话我都要重新告诉它“这个项目用 Spring Boot 3.2JDK 17MyBatis-Plus统一返回ResultT异常用BusinessException日志用Slf4j……” 说一遍两遍还行说二十遍的时候我真的想把键盘砸了。第三个坑是不可复现。有一次它帮我写了一个特别巧妙的 SQL 优化方案我当时没存下来后来想复用的时候怎么都想不起具体怎么写的。会话一关经验就归零。这三个坑归结起来就是一句话我把大模型当成了一个“随叫随到的代码生成器”而不是一个“需要配置和管理的工程系统”。裸用大模型就像不带任何工具去修车——能拧几个螺丝但遇到发动机大修就彻底歇菜。1.2 Skills 和 MCP 到底解决了什么问题后来我开始认真研究 Claude Code 的 Skills 和 MCP才发现这两个东西本质上是在解决两个不同维度的问题。Skills 解决的是“知识复用”问题。你可以把 Skills 理解成给 AI 写的“操作手册”或者“岗位说明书”。比如你定义一个spring-boot-conventions的 Skill里面写清楚这个项目的包结构规范、命名规范、异常处理规范、日志规范。之后每次让 Claude Code 写代码它都会自动加载这个 Skill按照你定义的规范来写。不用再重复交代不用再纠正它的风格。MCP 解决的是“能力扩展”问题。MCP 全称是 Model Context Protocol你可以把它类比成“AI 世界的 USB 接口”。USB 接口让电脑可以连接鼠标、键盘、打印机等各种外设MCP 让 Claude Code 可以连接数据库、浏览器、Figma、蓝湖、Jira 等各种外部工具。没有 MCP 的时候Claude Code 只能读写本地文件、执行终端命令有了 MCP它可以查数据库表结构、读 Figma 设计稿、拉 Jira 任务详情、操作浏览器做端到端测试。这两个东西配合起来才真正把 Claude Code 从“代码生成器”升级成了“开发工作流引擎”。Skills 负责“知道怎么做”MCP 负责“能做什么”两者结合才能实现从需求到代码到验证的完整闭环。1.3 这套工作流适合谁不适合谁先说适合谁。如果你满足以下任意一条这套工作流值得你花时间搭建你维护的是一个长期项目不是一次性脚本。项目周期越长Skills 和 MCP 的复利效应越明显。你的团队有明确的编码规范但每次 Code Review 都要花大量时间纠正风格问题。你需要频繁在多个工具之间切换比如从 Figma 看设计稿到数据库查字段再到 IDE 写代码最后到浏览器验证。你希望 AI 生成的代码可以直接合并而不是每次都要手动改半天。再说暂时不适合谁。如果你只是偶尔写个爬虫脚本、做个数据分析项目生命周期不超过一周那搭建 Skills 和 MCP 的投入产出比确实不高。这种情况下裸用大模型反而更高效。但如果你是一个前端或后端工程师每天的工作就是在一个成熟项目里加功能、改 Bug、做重构那这套工作流迟早会帮你省下大量时间。我自己的实测数据是搭建 Skills 和 MCP 花了大概两个周末之后每周至少省下 5 到 8 小时的重复沟通和手动修正时间。一个月就回本了。2. Skills 体系设计把项目规范写成 AI 能读懂的“操作手册”2.1 Skill 的文件结构和加载机制Claude Code 的 Skill 本质上就是一个 Markdown 文件放在项目的.claude/skills/目录下。每个 Skill 是一个独立的文件夹文件夹名就是 Skill 的名字里面必须有一个SKILL.md文件作为入口。一个典型的 Skill 目录结构是这样的.claude/ skills/ spring-boot-conventions/ SKILL.md examples/ controller-example.md service-example.md references/ exception-codes.md vue3-frontend-conventions/ SKILL.md examples/ component-example.mdSKILL.md的格式也有讲究。它需要包含 YAML 格式的 frontmatter用来告诉 Claude Code 这个 Skill 叫什么、什么时候该加载它。下面是一个我实际在用的例子--- name: spring-boot-conventions description: 当编写或修改 Spring Boot 后端代码时使用此 Skill包含包结构、命名规范、异常处理、日志规范等约定 --- # Spring Boot 项目编码规范 ## 包结构 - Controller 放在 controller 包下 - Service 接口放在 service 包下实现类放在 service.impl 包下 - Mapper 放在 mapper 包下 - 实体类放在 domain.entity 包下 - DTO 放在 domain.dto 包下 - VO 放在 domain.vo 包下 ## 命名规范 - Controller 类名以 Controller 结尾 - Service 接口以 Service 结尾实现类以 ServiceImpl 结尾 - 方法名使用动词开头如 createUser、updateOrderStatus ## 统一返回体 所有 Controller 方法必须返回 ResultT定义如下 ...这里有个关键点description 字段决定了 Skill 什么时候被自动加载。Claude Code 会根据你当前的任务内容匹配 Skill 的 description决定是否加载。所以 description 要写得既准确又宽泛太窄了匹配不上太宽了会误加载。2.2 如何写出高质量的 Skill三个核心原则我踩过不少坑之后总结出写 Skill 的三个核心原则。原则一写“约束”而不是“教程”。很多人写 Skill 的时候喜欢把整个 Spring Boot 教程搬进去从什么是 IoC 讲到 AOP 原理。这是完全错误的。Claude Code 本身已经懂这些基础知识你不需要教它。你需要告诉它的是在这个项目里我们是怎么做的。比如“我们不用Autowired字段注入统一用构造器注入”这才是它不知道的信息。原则二用示例代替描述。与其写“Service 层要处理业务异常并记录日志”不如直接给一个完整的 Service 方法示例让它照着写。我自己的经验是一个 20 行的代码示例比 200 字的文字描述效果好得多。Claude Code 对代码模式的模仿能力极强你给它看什么它就学什么。原则三分层组织按需加载。不要把所有的规范都塞进一个 Skill。我现在的做法是基础规范命名、包结构、返回体放在一个base-conventionsSkill 里数据库操作规范放在database-conventions里前端规范放在frontend-conventions里。这样 Claude Code 在写 Controller 的时候只会加载base-conventions不会把前端规范也拉进来节省上下文窗口。2.3 我实际在用的 Skill 清单和配置下面是我目前项目里在用的 Skill 清单以及每个 Skill 的核心内容概要Skill 名称触发场景核心内容base-conventions编写任何后端代码包结构、命名规范、统一返回体、异常处理database-conventions涉及数据库操作MyBatis-Plus 用法、分页规范、SQL 编写规范api-design设计新接口RESTful 规范、URL 命名、参数校验、Swagger 注解frontend-conventions编写 Vue 代码组件命名、Composition API 用法、状态管理规范test-conventions编写测试代码JUnit 5 用法、Mockito 规范、测试命名每个 Skill 的SKILL.md我都控制在 200 行以内超过 200 行就会拆分成多个 Skill。原因是 Claude Code 的上下文窗口是有限的Skill 太长会挤占其他内容的加载空间。这里分享一个实操心得Skill 写完之后一定要测试。测试方法是新开一个会话让它写一个简单的功能看它是否自动加载了正确的 Skill生成的代码是否符合规范。如果不符合就回去改 Skill 的 description 或者内容。我前三个 Skill 改了至少五遍才稳定下来。3. MCP 接入实战让 Claude Code 真正“连上”你的工具链3.1 MCP 的本质AI 世界的 USB 协议MCP 这个词最近很火但很多人搞不清楚它到底是什么。我用一个类比来解释MCP 就是 AI 世界的 USB 协议。在 USB 出现之前电脑连接鼠标用 PS/2 接口连接打印机用并口连接显示器用 VGA 接口每种设备一个专用接口互不兼容。USB 出现之后所有设备统一用 USB 接口电脑只需要提供 USB 端口设备只需要实现 USB 协议就能互相通信。MCP 做的事情一模一样。在 MCP 出现之前Claude Code 要连数据库需要专门写一套数据库连接逻辑要连 Figma需要专门写一套 Figma API 调用逻辑要连浏览器需要专门写一套浏览器控制逻辑。每个工具都要单独适配工作量巨大。MCP 出现之后所有工具只需要实现 MCP 协议Claude Code 只需要支持 MCP 协议就能连接所有工具。这就是为什么最近 MCP 生态爆发式增长——大家都按同一个标准来接入成本大幅降低。3.2 我接入的 MCP 服务清单和配置方法目前我项目里接入了四个 MCP 服务每个都解决了具体的痛点第一个是数据库 MCP。这个 MCP 让 Claude Code 可以直接查询数据库表结构、查看字段类型、甚至执行只读 SQL。以前我要写一个实体类得先打开数据库客户端查表结构复制字段名再回到 IDE 写代码。现在直接跟 Claude Code 说“根据t_user表生成实体类”它自己就去查表结构了。配置方法是在项目根目录的.mcp.json文件里添加{ mcpServers: { database: { command: npx, args: [-y, modelcontextprotocol/server-mysql], env: { MYSQL_HOST: localhost, MYSQL_PORT: 3306, MYSQL_USER: readonly, MYSQL_PASSWORD: your_password, MYSQL_DATABASE: your_database } } } }这里有个安全注意事项数据库 MCP 一定要用只读账号。我专门建了一个readonly用户只给 SELECT 权限。这样即使 Claude Code 误操作也不会把数据改坏。第二个是浏览器 MCP。这个 MCP 让 Claude Code 可以控制浏览器做端到端测试。比如我写完一个登录功能直接跟它说“打开浏览器访问登录页输入测试账号验证登录成功”它就会自动操作浏览器完成测试。浏览器 MCP 目前有两个主流选择Browser Use MCP 和 Playwright MCP。我两个都试过最后选了 Playwright MCP。原因是 Playwright MCP 更稳定对复杂页面的支持更好而且可以直接复用 Playwright 的测试脚本。Browser Use MCP 的优势是更轻量适合简单的页面操作。第三个是 Figma MCP。这个 MCP 让 Claude Code 可以读取 Figma 设计稿自动生成对应的前端代码。以前前端开发最痛苦的就是对着设计稿一个像素一个像素地调现在直接把 Figma 链接丢给 Claude Code它就能生成 80% 相似度的代码我再手动微调一下就行。第四个是蓝湖 MCP。蓝湖是国内团队常用的设计协作工具它的 MCP 和 Figma MCP 功能类似但更贴合国内团队的使用习惯。如果你的团队用蓝湖直接接蓝湖 MCP 就行。3.3 MCP 配置的常见坑和排查方法MCP 配置看起来简单但实际接入的时候坑特别多。我整理了几个最常见的坑一MCP 服务启动失败但没有任何报错。这种情况通常是command或args写错了。排查方法是手动在终端执行一遍command和args看能不能正常启动。比如上面数据库 MCP 的配置你就手动执行npx -y modelcontextprotocol/server-mysql看有没有报错。坑二MCP 服务启动了但 Claude Code 找不到。这种情况通常是配置文件路径不对。Claude Code 默认读取项目根目录的.mcp.json如果你放在其他位置它就读不到。另外有些版本的 Claude Code 需要重启才能加载新的 MCP 配置改完配置记得重启一下。坑三MCP 服务能连上但调用时报权限错误。这种情况通常是环境变量没配好。比如数据库 MCP 的MYSQL_USER和MYSQL_PASSWORD如果写错了服务能启动但查询的时候会报权限错误。排查方法是检查.mcp.json里的env字段确保所有必要的环境变量都配了。坑四多个 MCP 服务冲突。如果你同时接入了多个功能相似的 MCP比如同时接了 Figma MCP 和蓝湖 MCPClaude Code 可能会不知道该用哪个。我的做法是只保留一个需要切换的时候手动改配置。4. Skills 和 MCP 协同构建完整的 AI 开发工作流4.1 一个完整功能的开发流程实录下面我以一个真实的功能开发为例展示 Skills 和 MCP 如何协同工作。需求是给用户模块增加一个“修改密码”功能。第一步需求理解。我直接跟 Claude Code 说“给用户模块增加修改密码功能需要旧密码验证、新密码强度校验、修改成功后发送通知。”第二步自动加载 Skill。Claude Code 检测到这是后端功能开发自动加载了base-conventions和api-design两个 Skill。它知道这个项目的 Controller 要返回ResultTService 要分接口和实现类异常要用BusinessException。第三步通过 MCP 查数据库。Claude Code 通过数据库 MCP 查询了t_user表结构发现已经有password字段但缺少password_updated_at字段。它主动提醒我“检测到缺少password_updated_at字段是否需要生成对应的 DDL 语句”第四步生成代码。它生成了完整的代码Controller 层的changePassword接口、Service 层的changePassword方法、DTO 层的ChangePasswordRequest、以及对应的单元测试。所有代码都符合项目规范命名、包结构、返回体全部正确。第五步通过 MCP 验证。它通过浏览器 MCP 启动了前端页面模拟用户操作验证修改密码流程是否正常。发现新密码强度校验的前端提示文案和后端不一致主动修正了。第六步生成变更总结。最后它输出了一份变更总结包括修改了哪些文件、新增了哪些文件、需要执行什么 DDL、有什么注意事项。整个流程下来我只需要在第一步描述需求后面全是自动完成的。以前这个功能我至少要写半天现在 20 分钟搞定。4.2 工作流中的关键决策点这套工作流能跑通有几个关键决策点值得展开说。决策点一Skill 的粒度怎么定。太粗了一个 Skill 管所有事Claude Code 加载的时候会带入大量无关信息浪费上下文太细了一个 Skill 只管一个方法维护成本太高。我的经验是按“关注点”划分。命名规范是一个关注点数据库操作是一个关注点API 设计是一个关注点。每个关注点一个 Skill粒度刚刚好。决策点二MCP 的权限怎么控。MCP 给了 Claude Code 很大的能力但能力越大风险越大。我的原则是只给必要的权限不给多余的权限。数据库 MCP 只给只读权限浏览器 MCP 只给测试环境的访问权限Figma MCP 只给读取权限。这样即使出问题影响也可控。决策点三什么时候用 Skill什么时候用 MCP。简单判断标准是如果这件事是“知道怎么做”用 Skill如果这件事是“需要访问外部资源”用 MCP。比如“怎么写 Controller”是 Skill“查数据库表结构”是 MCP。两者配合才能覆盖完整的开发流程。4.3 实测效率对比裸用 vs 工程化我记录了自己一个月内两种模式下的效率数据对比如下对比项裸用大模型Skills MCP 工程化单功能平均开发时间3.5 小时1.2 小时代码规范符合率约 60%约 95%需要手动修正的次数平均 8 次/功能平均 1.5 次/功能跨会话上下文丢失率100%接近 0%端到端测试覆盖率基本没有约 70%这个数据是我自己手动记录的样本量不大但趋势很明显。最让我意外的是“代码规范符合率”这一项。裸用的时候我至少要花 30% 的时间在改命名、改返回体、改异常处理上。用了 Skill 之后这部分时间几乎降为零。5. 常见问题与排查技巧实录5.1 Skill 不生效的排查思路Skill 不生效是最常见的问题表现是 Claude Code 生成的代码不符合 Skill 里定义的规范。排查思路如下第一步检查 Skill 是否被加载。在 Claude Code 里输入/skills命令可以看到当前加载了哪些 Skill。如果列表里没有你的 Skill说明没加载成功。第二步检查 description 是否匹配。如果 Skill 在列表里但没被使用说明 description 和当前任务不匹配。比如你的 description 写的是“编写 Java 代码时使用”但当前任务是写 SQL那就匹配不上。解决方法是把 description 写得更宽泛或者拆成多个 Skill。第三步检查 Skill 内容是否有冲突。如果加载了多个 Skill内容有冲突Claude Code 可能会无所适从。比如一个 Skill 说“用Autowired注入”另一个说“用构造器注入”它就会随机选一个。解决方法是确保 Skill 之间没有矛盾。第四步检查 Skill 文件格式。SKILL.md的 frontmatter 必须是合法的 YAMLname和description字段必须存在。我遇到过因为 YAML 缩进错误导致 Skill 加载失败的情况排查了半天才发现。5.2 MCP 连接失败的速查表MCP 连接失败的原因很多我整理了一个速查表按现象分类现象可能原因解决方法MCP 服务启动失败command 或 args 错误手动执行命令验证Claude Code 找不到 MCP配置文件路径错误确认.mcp.json在项目根目录调用时报权限错误环境变量配置错误检查env字段调用超时网络问题或服务未启动检查服务状态和网络多个 MCP 冲突功能重叠只保留一个或手动切换配置改了不生效需要重启重启 Claude Code5.3 我踩过的三个大坑和解决方案大坑一Skill 写得太长导致上下文溢出。我一开始把整个项目的编码规范都写进一个 Skill结果 800 多行。Claude Code 加载之后上下文窗口被占了一大半导致它记不住其他重要信息。解决方案是拆分成多个小 Skill每个控制在 200 行以内。大坑二MCP 用了生产环境数据库。有一次我图省事数据库 MCP 直接连了生产库。结果 Claude Code 查询的时候执行了一条全表扫描把生产库拖慢了。虽然没造成数据损坏但被运维警告了一次。解决方案是永远用只读账号永远连测试库。大坑三Skill 和 MCP 的职责边界不清。我一开始把“查数据库表结构”也写进了 Skill结果 Claude Code 按照 Skill 里的描述去查但因为没有 MCP 权限查不到。解决方案是明确边界Skill 只写“知道怎么做”MCP 只写“能访问什么”两者不重叠。5.4 进阶技巧让 Skill 和 MCP 互相配合最后分享一个进阶技巧让 Skill 引用 MCP 的能力。比如在database-conventionsSkill 里可以写这样一段## 生成实体类的流程 1. 通过数据库 MCP 查询目标表的结构 2. 根据表结构生成实体类字段名使用驼峰命名 3. 主键使用 TableId 注解类型为 Long 4. 公共字段create_time、update_time使用 TableField(fill FieldFill.INSERT) 注解这样 Claude Code 在生成实体类的时候就会自动去调用数据库 MCP 查表结构然后按照 Skill 里的规范生成代码。Skill 负责“怎么做”MCP 负责“查什么”两者配合得天衣无缝。这个技巧的关键是在 Skill 里明确写出“通过 XX MCP 做 XX 事”。Claude Code 看到这样的描述就会主动去调用对应的 MCP。我实测下来这个配合方式比单独用 Skill 或单独用 MCP 效果好得多。6. 从工具到习惯我的日常 AI 开发工作流6.1 每天开工前的准备工作我现在每天开工前会做三件事花不了五分钟但能让一整天的效率提升一个档次。第一件事是检查 Skill 和 MCP 的加载状态。输入/skills看 Skill 列表输入/mcp看 MCP 连接状态。如果有异常第一时间排查不要等到写代码写到一半才发现。第二件事是同步最新的项目规范。如果昨天 Code Review 的时候发现了新的规范问题比如“以后 DTO 命名统一用XxxRequest和XxxResponse”我会第一时间更新到对应的 Skill 里。这样今天写的代码就不会再犯同样的错误。第三件事是清理过期的上下文。Claude Code 的会话上下文是有限的如果昨天开了一个很长的会话今天继续用的时候可能会因为上下文太满而变慢。我的做法是每天开一个新会话把必要的背景信息通过 Skill 和 MCP 自动加载而不是靠会话历史。6.2 开发过程中的协作节奏开发过程中我摸索出了一套和 Claude Code 协作的节奏。需求描述阶段我会尽量把需求说清楚包括业务背景、输入输出、边界条件。但不会说太细因为太细了反而限制了它的发挥。比如我会说“做一个用户导出功能支持按注册时间筛选导出 Excel”而不会说“用 EasyExcel 的ExcelProperty注解定义列”。代码生成阶段我会让它先生成核心逻辑我审查一遍确认方向对了再让它生成周边代码Controller、DTO、测试。这样如果方向错了改起来成本低。验证阶段我会让它通过浏览器 MCP 做端到端测试同时我自己也会手动跑一遍关键路径。AI 测试覆盖的是常规路径人工测试覆盖的是边界情况两者互补。提交阶段我会让它生成 Commit Message 和变更总结我审查后提交。这样 Commit Message 的质量比我自己写的高而且不会漏掉变更点。6.3 每周复盘和持续优化每周五下午我会花半小时做一次复盘主要做三件事。第一件事是回顾本周的 Skill 更新。看看哪些 Skill 被频繁修改说明这些地方规范不稳定需要进一步明确。哪些 Skill 从来没被修改过说明这些规范已经稳定了。第二件事是检查 MCP 的使用情况。看看哪些 MCP 调用频繁哪些几乎没用。没用的 MCP 就移除减少配置复杂度。频繁调用的 MCP 就优化配置提升响应速度。第三件事是整理本周踩过的坑。把新发现的坑记录到排查速查表里把新的解决方案补充到 Skill 里。这样下周再遇到同样的问题就能秒解决。这套复盘机制看起来简单但坚持下来效果惊人。我现在的 Skill 库和 MCP 配置比三个月前完善了不止一个档次。最重要的是这套工作流已经变成了我的肌肉记忆不需要刻意去想自然而然就会按照工程化的方式去用 AI。6.4 一个真实项目的完整复盘最后分享一个真实项目的复盘。上个月我接了一个需求给一个 RuoYi-Vue-Pro 项目增加 MCP 功能模块让系统可以通过 MCP 协议对外提供能力。这个项目我全程用 Skills MCP 工作流完成总共花了三天。如果按以前裸用的方式我估计至少要一周。第一天上午我让 Claude Code 通过数据库 MCP 分析了 RuoYi-Vue-Pro 的表结构理清了用户、角色、权限的关系。下午我基于分析结果写了ruoyi-conventionsSkill把 RuoYi 的代码规范固化下来。第二天我让 Claude Code 按照 Skill 规范生成了 MCP 模块的核心代码包括 MCP 服务注册、工具定义、权限校验。中间通过浏览器 MCP 做了两次端到端测试发现并修复了三个权限相关的 Bug。第三天我让它生成了完整的单元测试和集成测试覆盖率达到了 85%。然后通过 MCP 做了压力测试确认性能达标。最后生成了变更总结和部署文档。这个项目让我最满意的地方是代码质量比我手写的还高。因为 Skill 里固化了最佳实践Claude Code 生成的代码严格遵守规范没有一处命名不一致、没有一处异常处理遗漏。Code Review 的时候同事问我是不是找了外援我说是 AI 写的他一脸不信。这个项目之后我彻底相信了AI 开发工作流的未来一定是工程化的。裸用大模型的时代已经过去了Skills 和 MCP 才是正确的打开方式。