1. 手忙脚乱的“裸用”阶段我从哪一步开始觉得不对劲先说一个我自己的真实场景。几个月前我把 Claude Code 装好第一次在终端里敲下claude的时候确实有一种“这才是 AI 编程该有的样子”的错觉它能直接读项目文件、能改代码、能跑命令不需要我在浏览器里复制粘贴大段代码。头两周我几乎把所有能用它干的活都丢给了它改样式、写单测、补注释、修 lint 报错效率确实比纯手写高了一大截。但这种“裸用”的爽感没有维持太久。大概第三周我在做一个遗留前端项目业务逻辑很绕同一个需求连续让 Claude Code 改了三轮。我发现我每天都在重复同一件事把项目背景、技术栈、目录结构、相关文件路径一遍又一遍地复制进对话里。它确实记住了这次对话里的内容可下次开新会话所有上下文清零我又得从头喂一遍。真正让我下决心改造的是某次对线上问题的排查。那段代码涉及一个支付状态的机内流转我让 Claude Code 帮我查问题它分析得很像回事却始终没有主动去读那几个关键的状态机文件——因为我不知道该让它读哪个文件它也不知道项目中哪些文件真正相关。最后是我自己打开编辑器翻了大半个小时再把关键代码段粘给它。整个过程中我感受到一种荒诞我明明有一个能在本地终端里工作的 AI却还是在像用网页版一样靠手动喂上下文。那之后我认真盘点了一下“裸用”阶段的问题大致有三类上下文管理靠人肉。对话一开能记住的上下文有限项目越大越容易“前后矛盾”临时续接新会话等于失忆。外部工具和数据源是断的。Claude Code 能读文件夹里的代码但拿不到 Git 仓库的状态、拿不到需求文档、拿不到线上接口的实时返回。它更像一个聪明的“代码抄写员”而不是真正接入开发链路的助手。经验不可沉淀。我花了十几分钟调教出来的“该怎么审查这段代码”的套路关掉终端之后就消失了下次还要重新说一遍。后来我做的事情其实可以用一句话概括给 Claude Code 装上“固定的作业流程”和“可调用的外部工具”。前者是Skills后者是MCP。这张对比表基本就说明了我整个改造前后的差别维度裸用状态工程化之后上下文靠对话内临时提供关闭即失忆通过 Skill 文件自动加载背景与规则外部数据读不到 Git、数据库、接口状态MCP Server 按需提供实时数据任务流程每次口头重新交代固定流程由 Skill 驱动稳定可复用人工介入频繁补上下文、指文件只做最终审核和关键决策经验沉淀存在脑子里换台机器就没了沉淀为 Skill 文件跟项目走如果你也正处于“用着 Claude Code 但总觉得差点意思”的阶段这篇文章就是我在完成这次改造之后的完整复盘为什么接 MCP、怎么设计 Skills、两者怎么配合以及我踩过的坑和现在还留着的人工环节。2. MCP为什么值得接它不是“插件”是给模型补上手脚的协议层MCP 的全称是 Model Context Protocol一个模型上下文协议。很多人第一次听到这个名字会觉得很高深其实它的作用用一个比喻就能说清楚如果大模型是一个大脑MCP 就是给这个大脑接上眼睛、耳朵和手的 USB-C 接口。在接入 MCP 之前Claude Code 的能力边界非常清晰它能看到你项目里的代码文件能执行终端命令除此之外的外部世界对它来说都是盲区。GitHub 上有没有新的 issue线上接口返回的 JSON 长什么样数据库里某个订单的状态是什么这些它一概不知道。你只能在对话里把结果复制给它它才能基于这份“二手信息”做分析。MCP 改变了这件事。它定义了一套标准化的通信方式MCP Server 负责暴露能力——可以是读取工具、数据源、也可以是某个具体操作Claude Code 作为 MCP Client在需要的时候主动去调用这些工具。关键在于调用是由模型自己决定要调哪些、按什么顺序调不再需要你手动把数据搬进对话框。拿我最常用的配置举例。我在 Claude Code 里接了一个 GitHub 相关的 MCP Server配置完成后我可以直接这样对 Cloude Code 说“看一下这个仓库最近的 PR有没有测试覆盖率下降的列出来。”它会自己去调 GitHub API拉取 PR 列表和检查状态然后给我一份汇总。整个过程我不需要复制任何链接、不需要口头描述 PR 内容它自己就把信息拿回来了。除了 GitHub我实际接入过的 MCP Server 有这几类你可以做个参考MCP Server 类型典型用途我实际用来做什么文件系统类按路径读写文件、搜索目录跨目录整理代码片段、批量改名Git/GitHub 类拉取仓库状态、issue、PR、commit自动整理 changelog、审查 PR数据库类直连数据库执行查询排查线上数据不一致问题浏览器类控制浏览器访问页面、取 DOM验证前端页面状态、抓取接口返回调试器类对接调试工具读取运行时上下文配合本地调试定位崩溃栈在开发调试场景里MCP 的价值还会被进一步放大。比如调试类工具可以通过 MCP 和 Claude Code 对接让 AI 直接读取调试器的当前栈、寄存器、反汇编结果而不是靠你手动把崩溃信息复制进去。这种“工具直连”带来的效率提升比单纯把对话模型做得再聪明都明显。当然接哪些 MCP Server 完全取决于你的场景我自己的原则是只在真正需要的时候把外部数据源接进来而不是为了“显得专业”把所有 Server 都装上。配置 MCP 的方式也很直接Claude Code 支持通过命令把 Server 注册进去。我一般会在项目根目录下执行类似这样的命令注册一个本地 Serverclaude mcp add 我的数据源 --env API_KEYxxx -- npx 某个-server包注册完之后项目启动时 Claude Code 会自动加载这个 MCP Server并把它提供的工具列进可调用清单里。这里有一个容易被忽略的重点MCP Server 本质上是本地运行的一个进程你给它配了哪些密钥、它就能访问哪些资源权限边界完全由你控制。你不给它配数据库的写权限它就不会有写库的能力。所以不要担心接了 MCP 就等于把整个项目裸奔给了 AI真正的风险控制点还是在你的配置上。关于权限我有一条自己的判断标准只开放“读取和分析”类能力默认不开放“写入和改动”类能力。比如数据库类的 MCP Server我只会用只读账号去连GitHub 类的 Server我会限制成读取 PR、commit 的状态不在对话里直接让它做 force push 这种事。这一条原则帮我避开过好几次潜在的灾难后面讲踩坑的时候会再展开。3. Skills的正确打开方式别把它当成会说话的提示词文件夹搞定了 MCP 之后我一度以为工作流已经很理想了但很快发现了新的问题Claude Code 确实能调用工具了可它不知道“什么时候该用”“按照什么流程来做”。比如我让它处理一个需求它一会儿先问我业务逻辑一会儿自己埋头就改一会儿又想起来问我要不要跑测试。每次都像在跟一个实习生磨合你得在旁边不停引导。直到我认真去理解 Claude 官方提出的 Agent Skills 机制这个问题才算解掉。Skills 是一种结构化的“技能包”它不再是一段直白的提示词而是一个包含说明文件、示例、脚本、资源文件的文件夹。Claude Code 会扫描这些文件夹根据技能描述自动判断“当前任务是否匹配某个技能”然后按技能文件里定义的流程去执行。打个比方MCP 给了 AI 手脚Skills 给的是岗位说明书和作业指导书。你给 AI 一个“前端代码审查员”的 skill它就会按照你在 skill 里定义的检查清单去逐项核对代码先看 props 命名和类型再查状态管理是否合理然后检查有没有多余的重复渲染。这套流程是固定的、可复现的不会因为这次对话心情好就多查两项、下次忘了就少查两项。要理解 Skills 的设计逻辑最好的方式就是看它的目录结构。以我常用的项目为例我会在项目下建一个.claude/skills/目录里面每个子目录就是一个独立的技能.claude/skills/ ├── code-review/ # 代码审查技能 │ ├── SKILL.md # 核心说明文件 │ └── examples/ │ ├── review-sample-1.md │ └── review-sample-2.md ├── git-commit/ # 提交信息规范技能 │ └── SKILL.md └── frontend-refactor/ # 前端重构技能 ├── SKILL.md └── scripts/ └── check-imports.sh其中SKILL.md是整个技能的入口格式上最前面有一段 YAML 风格的元信息里面最关键的是name和description。description尤其重要——Claude Code 就是靠读这句描述来判断“当前这个任务值不值得加载这个技能”。我把一个审查技能的描述字段设计成下面这个样子--- name: code-review description: 用于对前端 TypeScript 代码进行系统性审查重点检查类型定义、组件边界和状态管理当用户要求审查或 review 代码时使用。 ---注意这里有个细节描述里写的是“当用户要求审查或 review 代码时使用”而不是笼统的“用于改善代码质量”。原因后面我会重点讲——技能的触发逻辑好不好九成取决于描述字段写得多具体。如果你写得太宽泛Claude Code 几乎会在每个任务里都尝试加载这个技能结果就是上下文被无关内容占满响应质量反而下降。我把这个现象叫作“技能误触发”。和普通提示词模板相比Skills 的核心优势我认为有三点这也是我在实际使用中最明显的体感差异自动发现而非手动粘贴。普通提示词需要你复制粘贴给模型Skills 是模型根据任务描述自己决定加载哪个。这省掉的不只是操作时间还避免了“忘了给提示词”导致步骤缺失。结构化支持挂载更多资源。一个 skill 目录里可以放示例文件、参考文档、检查清单、执行脚本它的信息量远超一段文字提示词模型在执行时可以把这些内容当作执行依据。版本可管理经验可迁移。技能包就是一个文件夹可以放进 Git 仓库里管理。我换了新电脑git clone下来就能恢复整套工作习惯不需要重新调教。很多人在社区里分享的 Skills比如搜索热词里反复出现的 Superpowers Skills、Codex 的 Skills 集合本质上都是这个思路的产物。Claude 官方也专门写过一篇文章叫《Claude Agent Skills: A First Principles Deep Dive》从第一性原理的角度讲技能系统的设计逻辑我建议大家有空去读读。不过要先说明别人的技能包可以参考但别指望直接拿来用就很贴合。因为技能的核心是“执行你期望的流程”而你期望的流程往往和分享者不完全一样。我现在的工作习惯是参考别人的思路然后自己捏一个定制版。4. 组合落地的完整路径以“前端需求拆解自测审查”为例理论部分讲得差不多了下面直接给你看我最近跑得最顺的一条工作流拿 Claude Code 处理一个前端需求从拆解、实现到自测和审查全链路由 Skills MCP 驱动。这个例子比较有代表性因为前端开发几乎是目前社区里 Skills 讨论度最高的场景热搜词里“前端开发 skills”“superpower skills”常年排在前列不是没有原因的——前端项目文件多、依赖重、改造成本高AI 如果没一套固定流程很容易改一处坏一片。4.1 环境准备先把地基打牢我后面给的方案依赖以下环境你如果从零开始先把这三步走完安装 Claude Code。全局安装命令一般是npm install -g anthropic-ai/claude-code装完在项目目录下执行claude就能进入交互式终端。Windows、macOS、Linux 都有对应安装方式Ubuntu 这类 Linux 系统上注意先确认 Node.js 版本不要太旧否则会拿到安装报错。在项目下建.claude/skills/目录规划好技能清单。我的习惯是给每个技能一个独立子目录名字用-连接的小写字母。按需注册 MCP Server。前端场景我最常接的是文件系统和浏览器调试两类前者让 AI 能跨目录读文件后者让它能打开本地页面验证效果。这些准备工作做完之后我会在claude启动时先做一次“项目预检”让 Claude Code 读一遍package.json和目录结构确认它清楚当前项目的技术栈和脚本命令。这一步很关键因为后面所有流程都建立在“AI 知道自己是在哪个项目里干活”这个前提下。4.2 第一步需求拆解的 Skill 配置我没有直接让 AI 上来就写代码而是先设计了一个“需求拆解”技能。这个技能的作用是当我把一段原始需求丢给它时它不会立刻动手而是先按固定结构输出拆解结果。--- name: requirement-breakdown description: 将模糊的业务需求拆解为可执行的前端任务清单包含改动文件、状态管理影响、测试计划和风险点当用户提供需求描述并期望开始开发时使用。 ---光有描述还不够SKILL.md的正文部分我写了五段固定结构需求理解一致性确认、影响面分析、拆解任务列表、执行顺序建议、需要用户确认的前置问题。这样做的好处非常明显决策过程被前置了。在真正改代码之前AI 已经和我对齐了“要做什么”“先做什么”“哪里可能有坑”而不是闷头写完再返工。4.3 第二步用 MCP 把“自测”环节闭环掉需求拆解确认完之后进入开发和自测阶段。这里就是 MCP 发挥主力的地方了。我注册了一个浏览器调试类的 MCP Server配置好本地预览地址后Claude Code 可以直接在浏览器里打开我的开发环境页面读取页面上的渲染结果和 console 输出。于是“改完代码-刷新页面-看报错-继续改”这个循环就从“我把报错复制给它”变成了“它自己打开页面、自己观察渲染结果、自己修”。我只需要在关键节点上确认一下方向对不对。这个体验和我最初“裸用”时的差异你自己对比一下就知道了。配合上面说的测试代码生成技能Claude Code 还会在改完成之后自动补一轮关键路径的单元测试。这一整套做下来一个普通中等复杂度的前端需求从接收描述到自测通过我实际盯人的时间大概只有以前的三分之一。4.4 第三步代码审查 Skill 的检查清单设计开发完成之后我最后一个固定动作是跑一遍“前端代码审查”技能。这个技能的执行重点在类型安全、组件边界、状态管理等几个维度。这里也顺便回答一个很多刚接触 Skills 的人都会问的问题为什么不让 Claude Code 直接用“审查一下代码”这种模糊指令非要单独建一个技能文件夹因为模糊指令没有稳定标准。昨天它审查时按 A 标准查今天可能按 B 标准查你要每一项都重新描述一遍很麻烦。而技能把标准固化了——我把自己多年积累的前端经验浓缩成了一份检查清单放进 SKILL.md 里的“强制检查项”区块。以后每次审查都会按同一份清单走。说实话光是这点就值回改造的功夫了。4.5 组合起来的流程长什么样把 MCP 和 Skills 配合起来整个工作流就成了一个可复制的流水线我丢需求给 Claude Code它调用“需求拆解”技能产出任务清单我确认后它开始实现并用 MCP 连到浏览器/文件系统完成自测最后调用“代码审查”技能做一轮自查发现问题再回到实现步骤。这个流程本身也是可以沉淀为另一个更高层的 skill 的我管它叫“前端需求全流程处理”不过本质上只是把上面几个技能串联起来。我观察过几周的实测数据在不考虑极端复杂逻辑的情况下一个典型的中型页面需求从拿到需求到产出可提交代码我的累计人工介入时间从平均 45 分钟降到大约 15 分钟。代码审查环节发现的问题类型也发生了变化低级代码规范问题明显变少剩下的是业务逻辑和交互设计层面的问题这些本来也更需要人来判断。5. 真金白银踩过的坑以及我现在还保留的“人肉”环节任何工具用到深处都会踩坑Skills MCP 的组合也一样。我把这段时间高频踩过的坑整理出来按“问题-原因-对策”列了个表每条都是从实际项目里淌出来的教训。坑现象原因我的对策技能误触发无关任务也加载 skill上下文被占满description 写得太宽泛比如“提升代码质量”描述里写清精确的触发场景MCP Server 没启动工具调用静默失败AI 假装执行过依赖的本地服务端口没起来启动前先主动验证 server 状态多个工具名称冲突AI 调用了错误的工具返回奇怪结果不同 MCP Server 暴露了相同命令用前缀命名区分避免裸工具名权限放太开AI 意外改动不该动的文件MCP Server 配置了写权限只读账号/只读配置优先新版本配置失效升级 Claude Code 后 MCP 注册丢失配置文件格式或路径变化升级后固定检查claude mcp list关于技能误触发我再展开说具体一点。我最早设计过一个“数据库查询”的 Skilldescription 字段我偷懒写了“用于查询数据库信息”。结果它几乎在每个任务里都被加载导致 Claude Code 在处理前端样式调整时脑子里还挂着一堆数据库操作上下文。后来我把描述改成了“当用户明确要求查询数据库、需要查表结构或分析 SQL 执行计划时使用”误触发率立刻降下来了。这个坑太典型社区里大量“Skills 没用”的抱怨相当一部分根源就出在这里。除了这些工具层面的坑更要命的是 Agent 能力边界的问题。我现在有明确的三类任务不会交给 Claude Code 自己做主第一类是涉及删除/覆盖不可恢复内容的操作。比如批量删除文件、批量重命名重要目录哪怕它有 MCP 的文件系统权限我也坚持自己执行或者事先 review 完整的文件清单。不是不信任它而是这类操作的“失败成本”太高一次误操作可能毁掉不可逆的工作成果。第二类是跨系统协调的最终决策。比如要发布上线、要合并到主干分支、要修改他人正在维护的模块。AI 可以帮忙做分析、出建议、列 checklist但最后的“拍板”动作我会人工完成。这既是为了安全也是为了让 AI 不越过团队协作的边界。第三类是涉及产品方向和业务取舍的判断。AI 能判断“这个函数能不能拆”但它判断不了“这个功能该不该砍”。这类问题我连让 AI 下结论的 prompt 都不会写最多让它列出利弊选项。在工具配置层面我现在的习惯是MCP 只接必要的那几个 server不追求种类多Skills 的描述字段保持精确每个技能的检查清单定期更新每完成一个项目我会顺手把其中可复用的流程沉淀成一个新的 Skill 或改进旧的 Skill。这套体系现在已经变成了我日常开发的一部分新电脑上只要把配置目录同步过来整套工作习惯就跟着过来了。最后再分享一个小技巧你在设计 Skill 时不要一开始就想着把流程写得很完美先写一个 70 分版本实际跑几次把跑偏的地方补进SKILL.md的“常见问题”区块里。我那几个最常用的技能都是这样从粗糙版本迭代出来的。这种“先用起来再逐步固化”的思路比一开始就设计一个庞大完美的技能系统要实际得多——毕竟工具的最终目的不是让流程看起来很复杂而是让你在复杂里省下真正的时间。