1. 从“裸用”到工程化我为什么开始折腾 Skills 和 MCP最开始用 Claude Code 的时候我跟大多数人一样就是打开终端敲一句需求等它吐代码复制粘贴跑一下报错了再贴回去让它改。这个阶段我管它叫“裸用”——没有任何工程化包装纯靠对话上下文硬撑。头一个月确实爽写个工具函数、改个正则、生成一段样板代码效率肉眼可见地提升。但项目一旦超过三五个文件问题就全冒出来了每次新开一个会话我都得重新解释一遍项目结构、技术栈、代码规范它生成的代码风格飘忽不定一会儿用axios一会儿用fetch更头疼的是它根本不知道我数据库里有哪些表、接口返回什么字段全靠我手动喂上下文喂少了它瞎猜喂多了 token 烧得心疼。这个瓶颈的本质是把一个能力很强的模型当成了一个“无状态的代码补全器”在用。而 Claude Code 真正拉开差距的地方在于它支持Skills技能和MCPModel Context Protocol模型上下文协议这两套机制。Skills 解决的是“怎么让模型按我的规矩办事”MCP 解决的是“怎么让模型拿到它本来拿不到的信息和工具”。一个管行为规范一个管能力边界两者配合起来才算是把 Claude Code 从“聊天框”升级成了“开发工作流里的一个正式环节”。我写这篇东西不是要复述官方文档——官方文档讲的是“有什么”我想讲的是“我实际怎么用、为什么这么设计、踩了哪些坑”。如果你现在还在“裸用”阶段或者装了 Claude Code 但只把它当高级补全那这篇应该能帮你少走不少弯路。下面我会从 Skills 的设计逻辑、MCP 的接入思路、两者怎么配合、以及工程化落地时的具体配置这几个角度把我这套工作流的搭建过程完整拆一遍。2. Skills 到底解决了什么问题把“口头约定”变成“可执行规范”2.1 裸用时代的三类反复翻车先说说没有 Skills 之前我每天要重复处理的几类破事。第一类是风格漂移我项目里统一用函数式组件加 TypeScript 严格模式但只要我不在每次对话里强调它就会时不时给我整出any类型、class组件甚至混进 JavaScript 写法。第二类是流程遗漏比如我要求所有新增接口必须同时补上参数校验和错误码它经常只写主逻辑校验和错误处理要我追着提醒。第三类是上下文重复项目约定、目录结构、命名规范这些东西每开一个新会话就得重讲一遍讲完还未必记得住。这三类问题的共同点是它们都不是“模型能力不够”而是“模型不知道我的规矩”。你每次口头说一遍它就遵守一次下次不说就忘。这就像你招了个技术很强但完全不了解团队规范的外包每次派活都得附一份需求说明书。2.2 Skill 的本质一份可被自动加载的“岗位说明书”Skills 的思路很直接把这些反复要讲的规矩写成结构化的文件放在约定位置让 Claude Code 在需要的时候自动读取并遵守。一个 Skill 本质上就是一组带元信息的指令文档通常包含名称、触发条件、具体规则以及可选的示例和脚本。它跟“在对话里贴一段 prompt”最大的区别在于它是持久化的、可复用的、按场景自动匹配的。我自己的理解是Skill 相当于给模型发了一本《员工手册》。手册里写清楚了这个岗位该干什么、不该干什么、遇到某类任务走什么流程。模型接到任务时先翻手册再动手。手册不用每次重写写一次就能一直用。2.3 我实际落地的几个 Skill 及其设计取舍我目前维护的 Skill 不算多但每一个都是被真实痛点逼出来的。举几个例子说明设计思路。代码规范 Skill这个是最基础的。我把项目的技术栈、目录约定、命名规则、导入顺序、错误处理模式全部写进去。关键取舍是——规则要具体到可判定不能写“保持代码整洁”这种废话。比如我会明确写“异步操作统一用 async/await禁止 .then 链式调用”“所有对外函数必须显式标注返回类型”“组件文件用 PascalCase工具函数用 camelCase”。规则越具体模型执行越稳定。接口开发 Skill这个 Skill 专门管新增 API 的流程。它规定了一个固定顺序先定义请求/响应类型再写参数校验再写业务逻辑最后补错误码和日志。我甚至在里面放了几个“标准范例”让模型照着抄结构。实测下来有了这个 Skill 之后我几乎不用再回头补校验和错误处理了。提交信息 Skill这个比较轻量就是规定 git commit message 的格式比如feat: xxx、fix: xxx正文要写清楚改了什么、为什么改。别看事情小团队协作里这个规范能省很多沟通成本。这里有个经验Skill 不是越多越好而是越准越好。我一开始贪多写了十几个结果有些 Skill 触发条件重叠模型反而不知道该听谁的。后来我砍到五六个核心的每个职责单一、边界清晰效果反而更好。另外Skill 里的规则要定期维护项目规范变了Skill 不更新模型就会按老规矩办事这比没有 Skill 还坑。3. MCP让 Claude Code 从“闭卷考试”变成“开卷带工具”3.1 先搞清楚 MCP 是什么别被名字唬住MCP 全称 Model Context Protocol翻译过来叫“模型上下文协议”。很多人第一次听到“协议”两个字会懵觉得是不是跟 HTTP、TCP 那种网络协议一个层级的东西。其实你可以把它理解成一个标准化的插头一边是 Claude Code 这个“用电设备”另一边是各种外部能力数据库、文件系统、第三方服务这个“电源”MCP 就是中间那个统一规格的插座。只要双方都按这个规格来就能即插即用。它解决的问题是模型本身只能看到你喂给它的文本看不到你的数据库、你的文件系统、你的内部 API。以前要让模型访问这些你得手动查、手动贴效率极低还容易出错。有了 MCP模型可以主动去“调用工具”获取信息比如查表结构、读文件、调接口整个过程自动化。3.2 我接入 MCP 的优先级排序逻辑MCP 的生态现在挺热闹各种 Server 层出不穷。但我的建议是别看到什么就接什么按“信息获取频率”和“手动成本”两个维度排序。高频且手动成本高的优先接低频或手动很简单的先放放。按这个逻辑我第一批接的是这几个优先级MCP 类型解决的核心问题接入理由高数据库 MCP模型不知道表结构和字段每次手动贴 schema 太痛苦且容易过期高文件系统 MCP模型只能看到当前打开的文件跨文件重构时需要全局视野中接口文档 MCP模型不知道内部 API 契约联调阶段高频使用中浏览器/页面 MCP需要看渲染结果或抓页面结构前端调试时有用但非必需低第三方服务 MCP如设计稿、项目管理工具看团队实际用不用这个排序不是绝对的但思路是通用的先接那些“不接就没法好好干活”的再接“接了更爽”的。一上来就把所有 MCP 都配上配置复杂度陡增排查问题也麻烦。3.3 数据库 MCP 接入的完整过程与踩坑数据库 MCP 是我用得最多的一个重点讲讲。我的目标是让模型能直接查表结构、看字段类型、甚至执行只读查询来验证数据。接入过程大致分三步装 Server、配连接、验证权限。装 Server 这步一般按官方或社区提供的说明来就行关键是连接配置。这里有个坑很多人图省事直接用生产库的连接串这是大忌。我的做法是专门建一个只读账号只授予SELECT和查元数据的权限连接串放在本地环境变量里绝不写进任何会提交到仓库的文件。配好之后要验证。我会让模型执行一个简单任务比如“列出用户表的所有字段和类型”看它能不能正确调通。第一次跑通常会遇到权限报错或者连接超时这时候别急着怀疑模型先看 MCP Server 的日志——九成问题出在连接配置和权限上跟模型没关系。还有一个细节数据库 MCP 返回的 schema 信息可能很长如果表特别多会占用大量上下文。我的做法是在 Skill 里约定“只查与当前任务相关的表”避免一次性把整个库的结构都拉进来。3.4 文件系统 MCP 与“上下文爆炸”的平衡文件系统 MCP 让模型能读项目里的任意文件这听起来很美好但用不好会出事。最典型的问题是上下文爆炸模型为了理解一个函数把整个目录的文件都读了一遍token 瞬间拉满响应变慢还容易抓不住重点。我的应对策略是在 Skill 里加约束优先读与任务直接相关的文件读之前先说明为什么要读。比如重构一个组件先读组件本身和它的类型定义需要时再读调用方。另外我会给模型划定“可读目录范围”把node_modules、构建产物、日志目录排除掉避免它去读一堆无关文件。实测下来加了这些约束之后文件系统 MCP 的收益才真正体现出来跨文件重构时模型能自己找到所有引用点不用我一个个指给它看。4. Skills 与 MCP 的配合一个真实的重构任务全流程4.1 任务背景给一个老接口补全校验和错误处理光讲概念没意思我拿一个真实任务走一遍。任务是这样的项目里有个用户注册接口是老代码没有参数校验错误处理也很粗糙我要把它改造成符合当前规范的样子。这个任务同时用到了 Skill 和 MCP。4.2 第一步Skill 先定规矩任务一开始接口开发 Skill 就被触发了。它告诉模型新增或修改接口时必须按“类型定义 → 参数校验 → 业务逻辑 → 错误码 → 日志”的顺序来并且给出了一个标准范例。模型拿到这个规矩就知道不能上来就改业务逻辑得先把结构搭对。这一步的价值在于它把“我脑子里的规范”变成了“模型执行前的约束”。没有 Skill 的话我得在对话里把这一长串要求再打一遍打完还不一定被完整遵守。4.3 第二步MCP 补全信息规矩定好了但模型还不知道这个接口现在长什么样、依赖哪些表、被谁调用。这时候 MCP 上场文件系统 MCP 读取接口所在文件、相关的类型定义文件、以及调用这个接口的前端代码数据库 MCP 查出用户表的结构确认哪些字段是必填、哪些有唯一约束接口文档 MCP如果有拉出这个接口的契约确认请求响应格式。这些信息以前要我手动查、手动贴现在模型自己就能拿到。关键是它拿到的是一手信息不是我转述的可能已经过期的信息。4.4 第三步模型产出与我的校验信息齐了模型开始改代码。产出之后我不会直接信会做几件事跑类型检查、跑单元测试、人工扫一遍错误码是否和项目约定一致。这里有个经验MCP 给的信息越准模型产出越靠谱但最终校验这一步不能省。模型再强也可能对某个字段的业务含义理解偏差这种偏差只有人能把关。整个流程走下来原本要半小时的活压缩到十分钟左右而且质量更稳定。更重要的是这个流程是可复制的——下次遇到类似任务Skill 和 MCP 会自动生效我不用重新交代一遍。5. 工程化落地的配置细节与团队协作5.1 目录结构与版本管理要让这套东西在团队里跑起来目录结构得先定好。我的做法是在项目根目录下建一个专门的配置目录把 Skills 和 MCP 配置都放进去然后纳入版本管理。这样新同事拉下代码配置就是现成的不用每个人自己摸索一遍。Skills 文件建议按职责分目录比如skills/code-style/、skills/api-dev/每个目录里放对应的规则文档。MCP 配置单独一个文件连接信息用环境变量占位实际值放在各人本地的环境变量里绝不把密钥提交到仓库。5.2 团队共享时的权限与安全边界团队协作里最敏感的是权限。数据库 MCP 的只读账号、文件系统 MCP 的可读范围、第三方服务的访问令牌这些都要有明确的边界。我的原则是最小权限能只读就不给写能限定目录就不放开全盘能限定表就不放开整库。另外MCP 配置里涉及外部服务的部分要定期审查。有些服务可能一开始接了后来不用了配置还留着这就是潜在风险。我一般每个季度清一次把不用的 MCP 摘掉。5.3 新人上手时的常见卡点带过几个新同事用这套工作流卡点基本集中在几个地方。一是Skill 没生效多半是文件放错位置或者格式不对检查一下触发条件写没写对。二是MCP 连不上先看环境变量配没配、权限够不够再看 Server 日志。三是模型不遵守 Skill通常是 Skill 里的规则太模糊改成可判定的具体规则就好了。我的建议是新人上手先别急着配一堆 MCP先把一两个核心 Skill 用熟感受到“规矩被自动执行”的好处之后再逐步加 MCP。顺序反了容易劝退——一上来配置复杂度太高出问题又不知道是哪一环很容易就放弃了。6. 这套工作流跑了大半年后我的几点真实体会用了大半年最大的感受是Claude Code 的价值上限取决于你给它搭的工程化底座有多扎实。裸用的时候它是个时好时坏的助手配上 Skills 和 MCP 之后它才真正变成工作流里稳定的一环。第二个体会是Skill 的质量比数量重要得多。我见过有人收集了几十个 Skill结果互相打架模型无所适从。真正有用的就那么几个写清楚、维护好比堆一堆强。第三个体会是关于 MCP 的它解决的是信息获取问题不是判断问题。模型能拿到准确的表结构和文件内容但“这个字段该不该加校验”“这个错误码合不合理”还是得人来定。把 MCP 当成“给模型配了副好眼镜”而不是“替模型做决定”这个定位想清楚了用起来就不会跑偏。最后分享一个我踩过的坑有段时间我为了图快把数据库 MCP 配成了可写权限结果模型在一次重构里顺手改了一条测试数据虽然没造成大问题但吓出一身冷汗。从那以后所有 MCP 一律只读起步需要写操作时单独走人工确认流程。这个教训值得每个准备接 MCP 的人记一下——能力越大边界越要划清楚。
