尧图网页设计 
1. 为什么裸用AI 编程助手迟早会撞墙我大概是从去年下半年开始把 Claude Code 当成主力开发工具的。刚开始那两个月体验确实惊艳——终端里敲一句话它就能读文件、改代码、跑测试感觉像多了个不知疲倦的结对程序员。但用得越久问题越明显每次开新会话我都得重新交代项目结构、代码规范、常用命令同一个生成组件的任务今天让它按 A 风格写明天它又给我 B 风格更别提那些需要跨多个工具、多个数据源的复杂任务光靠对话根本串不起来。这就是典型的裸用状态——把 AI 编程助手当成一个更聪明的聊天框所有上下文靠人肉喂所有流程靠临时指挥。它当然能用但用久了你会发现真正消耗时间的不是写代码本身而是反复对齐意图、反复纠正风格、反复搬运上下文。工程化的核心就是把这些重复劳动沉淀成可复用的资产让 AI 每次开工时自动加载正确的工作手册和工具箱。这套工作手册就是Claude Code Skills这个工具箱就是MCPModel Context Protocol。前者解决AI 该怎么做、按什么规范做的问题后者解决AI 能碰到哪些外部系统、能调用哪些真实能力的问题。两者叠加才把 AI 开发工作流从临时对话升级成可交付的工程管线。这篇文章我会把这两块拆开讲透再讲它们怎么协同最后给一份可以直接抄的落地清单。适合已经在用 Claude Code、但总觉得差点意思的开发者也适合刚接触 Skills 和 MCP、想搞清楚它们到底解决什么问题的人。2. Skills 与 MCP 到底各管什么先建立正确的心智模型2.1 一句话区分Skills 是怎么做MCP 是能做什么很多人第一次接触这两个概念会混淆因为它们都跟扩展 AI 能力有关。我用一个生活化的类比把 Claude Code 想象成一个刚入职的工程师。Skills相当于你交给他的岗位操作手册——我们团队写 React 组件必须用函数式 TypeScript样式统一走 CSS Modules提交前必须跑 lint 和单测。它约束的是行为方式和知识。MCP相当于给他开通的系统权限和工具账号——数据库连接、Figma 设计稿读取、Jira 任务查询、本地调试器接口。它扩展的是可触达的外部世界。一个管脑子里的规范一个管手上的工具。缺了 SkillsAI 每次输出风格飘忽、不懂你的项目约定缺了 MCPAI 只能在你贴给它的文本里打转碰不到真实系统。2.2 为什么必须是这两个而不是写更长的提示词有人会问我把规范全写进系统提示词不就行了短期可以长期一定崩。原因有三第一提示词是易失的。会话一关上下文清零下次还得重贴。Skills 是持久化在文件系统里的资产跟着项目走跟着版本走。第二提示词无法按需加载。你不可能把所有场景的规范都塞进一次对话那样既浪费上下文窗口又稀释重点。Skills 支持按任务触发写前端时加载前端规范写数据库迁移时加载迁移规范各管各的。第三提示词碰不到真实系统。你没法用一段文字让 AI 真的去查数据库、真的去读设计稿。这必须靠 MCP 这样的协议层去对接。所以正确的姿势不是写更长的提示词而是把知识沉淀成 Skills把能力接入 MCP让提示词回归它该干的活——描述这一次的具体任务。2.3 两者的协同关系Skills 可以指挥 MCP这是最容易被忽略、也最有价值的一点Skills 里可以写明在什么情况下调用哪个 MCP 工具。比如一个发布检查Skill可以规定先通过 MCP 查询 CI 流水线状态再通过 MCP 拉取最近的 issue 列表最后按固定格式输出发布报告。这样 AI 拿到的不是零散的工具而是一套编排好的动作序列。Skills 负责决策逻辑MCP 负责执行能力两者咬合起来才形成完整的工作流。3. Claude Code Skills 实战把项目规范变成可复用资产3.1 Skills 的目录结构与加载机制Claude Code 的 Skills 本质上是一组放在特定目录下的 Markdown 文件通常配合元数据每个 Skill 描述一类任务的做法。常见的组织方式是在项目根目录下建一个 skills 目录每个子目录或文件对应一个技能点。加载机制上它遵循按需注入的原则——AI 根据当前任务判断该激活哪个 Skill而不是一股脑全塞进上下文。这个设计的好处是上下文预算可控。你要知道上下文窗口是稀缺资源塞太多无关规范反而会让 AI 抓不住重点。按需加载让每次对话只携带最相关的知识输出质量明显更稳。我自己的目录大致长这样这是基于常见实践的合理组织你可以按团队习惯调整project-root/ skills/ frontend-component.md api-design.md db-migration.md release-checklist.md code-review.md每个文件聚焦一件事文件名即意图方便人和 AI 都能快速定位。3.2 一个前端组件 Skill 的完整写法拆解光说结构太虚直接看一个我实际在用的前端组件 Skill 长什么样。下面是我精简后的版本# 前端组件开发规范 ## 适用场景 当任务涉及创建或修改 React 组件时激活。 ## 技术约束 - 一律使用函数式组件 TypeScript禁止 class 组件 - 样式使用 CSS Modules禁止内联 style动态计算除外 - 组件 props 必须显式定义 interface禁止 any - 副作用统一用 useEffect依赖数组必须完整 ## 命名约定 - 组件文件PascalCase如 UserCard.tsx - 工具函数camelCase - 常量UPPER_SNAKE_CASE ## 必须遵守的检查项 1. 导出前确认无未使用的 import 2. 所有异步操作必须有 loading 和 error 状态 3. 可访问性交互元素必须有 aria-label 或可见文本 ## 输出格式 先给出组件代码再列出你做的关键决策最后提示需要补充的测试点。拆开看这个 Skill 干了四件事界定触发场景避免误激活、锁定技术约束消除风格漂移、明确命名约定保证一致性、规定输出格式让结果可预期。最后那条输出格式特别关键——它让 AI 每次交付都带上决策说明和测试提示我 review 的时候一眼就能看懂它为什么这么写。3.3 写 Skill 的三条硬经验用了大半年我总结出三条写 Skill 的铁律都是踩坑换来的。第一条一个 Skill 只干一件事。我早期图省事把前端、后端、数据库规范全塞进一个文件结果 AI 经常张冠李戴写后端时套用前端命名。拆成独立文件后误用率大幅下降。第二条约束要具体到可验证。代码要优雅这种话等于没说禁止 any依赖数组必须完整才是 AI 能执行、你能检查的。凡是无法用眼睛或工具验证的规范都别写进去。第三条给正例也给反例。只写要用函数式组件AI 偶尔还是会给你 class。加上一句反例class UserCard extends React.Component是禁止的命中率立刻提升。人对反例敏感模型也是。提示Skill 文件不要写太长。超过两三百行AI 反而会漏读关键约束。宁可拆成多个小 Skill也不要堆成一篇长文。4. MCP 实战让 AI 真正碰到你的系统和工具4.1 MCP 是什么用USB 接口理解它MCP 全称 Model Context Protocol直译是模型上下文协议。名字唬人本质很简单它是一套标准接口让 AI 能以统一的方式连接外部工具和数据源。还是用类比在 MCP 出现之前每接一个工具数据库、设计稿、任务系统都得写一套专用对接代码像早年每个手机品牌都有自己的充电口。MCP 相当于把接口统一成 USB-C——只要工具实现了 MCP 服务端AI 就能用同一套方式调用它。对开发者来说这意味着接入成本大幅降低可复用的连接越来越多。MCP 通常提供三类能力工具Tools即 AI 可以主动调用的动作比如查询数据库、创建 issue资源Resources即 AI 可以读取的数据比如文件、文档提示模板Prompts即预置的交互模板。日常用得最多的是 Tools。4.2 典型 MCP 接入场景与配置思路我目前工作流里常驻的 MCP 有这么几类每一类都对应一个真实痛点场景接入的 MCP 类型解决什么问题设计稿还原设计工具 MCPAI 直接读设计稿的图层、间距、颜色不用我截图描述任务管理项目管理 MCPAI 能查 issue、更新状态不用我复制粘贴数据库操作数据库 MCPAI 能查表结构、跑只读查询辅助写迁移脚本本地调试调试器 MCPAI 能读取断点信息、调用栈辅助定位问题配置上MCP 服务一般在 Claude Code 的配置文件里声明指定启动命令和参数。以数据库 MCP 为例思路大致是在配置里登记服务端的启动方式Claude Code 启动时拉起这个服务之后 AI 就能通过它执行查询。具体命令因工具而异核心是声明式配置 按需启动。注意接入数据库类 MCP 时务必只授予只读权限或严格限制可操作的表。让 AI 拥有写权限是高风险操作除非你有一套完善的回滚机制。4.3 MCP 与 Skills 的联动编排一个发布检查流程单用 MCP 只是多了几个工具真正威力在于用 Skill 把它们编排起来。我写过一个发布检查Skill逻辑是这样的# 发布前检查流程 ## 触发条件 当用户提到准备发布上线检查时激活。 ## 执行步骤 1. 调用 CI 相关 MCP 工具获取最近一次流水线状态 2. 调用任务管理 MCP拉取当前迭代未关闭的 issue 3. 调用数据库 MCP确认待执行的迁移脚本已就绪 4. 汇总以上信息按固定模板输出检查报告 ## 报告模板 - 流水线状态通过 / 失败附失败原因 - 未关闭 issue数量 列表 - 迁移脚本就绪 / 缺失 - 结论可以发布 / 阻塞项如下这个 Skill 本身不含任何代码它只是一段决策逻辑但配合 MCP 提供的执行能力AI 就能自动跑完一整套发布前检查。我实测下来原本要手动翻三四个系统、花十几分钟的事现在一句话触发几十秒出报告。这就是 Skills MCP 协同的典型价值把跨系统的重复流程压缩成一次自然语言指令。5. 从裸用到工程化我的完整工作流改造记录5.1 改造前后的对比我把改造前后的状态列成表你能直观看到差距维度裸用阶段工程化阶段上下文准备每次手动交代项目背景Skill 自动加载零交代代码风格每次输出不一致由 Skill 锁定稳定可预期跨系统操作人工复制粘贴MCP 直连AI 自主调用复杂流程靠临时指挥Skill 编排一键触发结果可复现差依赖当次对话好规范沉淀在文件里改造的核心动作其实就两步把重复交代的东西写成 Skill把重复搬运的操作接成 MCP。听起来简单但落地时有顺序讲究。5.2 我的改造顺序先 Skill 后 MCP我建议先做 Skills再做 MCP。原因很实际Skills 是纯文本零成本、零风险改起来随时改MCP 涉及外部系统接入有配置成本和权限风险。先用 Skills 把规范漂移这个最痛的问题解决掉你会立刻感受到输出质量的提升有了正反馈再去做 MCP 这种重活。具体节奏我是这么走的第一周把最常写的三类代码组件、接口、迁移的规范各写成一个 Skill观察一周看误用情况迭代措辞。第二周接入一两个低风险的 MCP比如只读的任务查询跑通链路。第三周开始写编排型 Skill把 MCP 串起来。整个过程不要贪多一次只改一个变量才能看清每个改动带来的效果。5.3 一个真实任务的完整走查拿给用户列表页加一个筛选功能这个任务举例走一遍工程化流程第一步我在终端里描述任务。Claude Code 识别到涉及前端组件自动激活前端组件 Skill于是它知道要用函数式组件、CSS Modules、完整依赖数组。第二步它需要确认现有的接口返回结构。这时它调用 API 文档相关的 MCP 资源直接读取接口定义而不是让我贴。第三步它按 Skill 规定的输出格式先给组件代码再列关键决策比如为什么用受控组件最后提示测试点。第四步我 review 后让它补测试它再次依据 Skill 里的测试规范生成用例。整个过程我几乎没有重复交代任何背景风格也完全一致。对比裸用阶段同样的任务我要多花五六轮对话去纠正风格和补充上下文。省下来的不是单次几分钟而是长期累积的认知负担。6. 常见问题与排查技巧实录6.1 Skill 不生效或误触发怎么办这是最高频的问题。排查思路按顺序来先确认文件位置和命名。Skill 没被识别八成是放错了目录或文件名不符合约定。对照官方文档确认路径。再看触发条件是否写清楚。如果 Skill 里没写适用场景AI 就不知道何时激活。补上明确的触发描述。检查是否被其他 Skill 覆盖。多个 Skill 约束冲突时AI 可能选错。把职责边界划清楚一个 Skill 一件事。误触发则相反通常是触发条件写太宽。把涉及代码时激活改成创建或修改 React 组件时激活精准度立刻上来。6.2 MCP 连不上或工具调用失败MCP 类问题排查我整理成一张速查表现象可能原因排查动作服务起不来启动命令或路径错误手动执行启动命令看报错工具列表为空服务端未正确注册工具检查服务端日志调用超时网络或权限问题确认目标系统可达、凭证有效权限被拒账号权限不足核对授予的权限范围提示MCP 出问题时第一步永远是脱离 AI 手动跑一遍服务端。能手动跑通问题就在配置或权限手动都跑不通问题在服务本身。这个二分法能省掉大量瞎猜。6.3 上下文被撑爆的处理经验Skills 和 MCP 用多了上下文消耗会变快。我的应对经验是Skill 保持精简MCP 结果做摘要。比如数据库 MCP 返回一大张表不要让原始结果全进上下文而是在 Skill 里规定只提取需要的字段。另外长会话该断就断把阶段性成果沉淀回 Skill 文件比硬撑着一个超长会话更高效。6.4 几个我踩过的坑第一个坑过早追求大而全的 Skill 体系。我一开始想一次性把所有规范写完结果写了三天没人用因为太理想化。后来改成用到哪写到哪反而落地快。第二个坑给 MCP 开了过大的权限。有次图方便给了写权限AI 一个误操作改了测试数据。从那以后所有 MCP 一律最小权限原则。第三个坑Skill 写完就不管了。规范会随项目演进Skill 也得跟着更新。我现在把 Skill 维护纳入 code review改规范时同步改 Skill避免文档和实际脱节。7. 落地清单今天就能开始的五步如果你看到这里想动手我建议按这个顺序来每一步都能独立见效盘点重复劳动。回想最近一周你反复跟 AI 交代了哪些背景、反复纠正了哪些风格。这些就是第一批 Skill 的素材。写第一个 Skill。挑最痛的那一个按触发场景 技术约束 命名约定 输出格式四段式写控制在两百行内。观察并迭代。用一周记录误用和漏用的情况针对性改措辞。别急着写第二个。接入一个低风险 MCP。从只读的查询类工具开始跑通链路建立信心。写一个编排型 Skill。把已有的 MCP 串成一个流程体验一句话触发整套动作的感觉。我个人在实际操作中的体会是这套改造最大的收益不是省了多少时间而是让 AI 的输出变得可预期、可复现。裸用阶段你永远不知道它这次会给你什么工程化之后它像一个熟悉你团队规范的老员工交付质量稳定在一个可接受的水位线上。这个确定性才是把 AI 真正纳入生产流程的前提。后续你还可以往更细的方向扩展比如给不同项目维护不同的 Skill 集或者把 MCP 编排成更复杂的多步工作流但那是下一步的事了先把这五步走扎实。 Claude Code工程化实战：用Skills与MCP告别AI编程裸用时代
1. 为什么裸用AI 编程助手迟早会撞墙我大概是从去年下半年开始把 Claude Code 当成主力开发工具的。刚开始那两个月体验确实惊艳——终端里敲一句话它就能读文件、改代码、跑测试感觉像多了个不知疲倦的结对程序员。但用得越久问题越明显每次开新会话我都得重新交代项目结构、代码规范、常用命令同一个生成组件的任务今天让它按 A 风格写明天它又给我 B 风格更别提那些需要跨多个工具、多个数据源的复杂任务光靠对话根本串不起来。这就是典型的裸用状态——把 AI 编程助手当成一个更聪明的聊天框所有上下文靠人肉喂所有流程靠临时指挥。它当然能用但用久了你会发现真正消耗时间的不是写代码本身而是反复对齐意图、反复纠正风格、反复搬运上下文。工程化的核心就是把这些重复劳动沉淀成可复用的资产让 AI 每次开工时自动加载正确的工作手册和工具箱。这套工作手册就是Claude Code Skills这个工具箱就是MCPModel Context Protocol。前者解决AI 该怎么做、按什么规范做的问题后者解决AI 能碰到哪些外部系统、能调用哪些真实能力的问题。两者叠加才把 AI 开发工作流从临时对话升级成可交付的工程管线。这篇文章我会把这两块拆开讲透再讲它们怎么协同最后给一份可以直接抄的落地清单。适合已经在用 Claude Code、但总觉得差点意思的开发者也适合刚接触 Skills 和 MCP、想搞清楚它们到底解决什么问题的人。2. Skills 与 MCP 到底各管什么先建立正确的心智模型2.1 一句话区分Skills 是怎么做MCP 是能做什么很多人第一次接触这两个概念会混淆因为它们都跟扩展 AI 能力有关。我用一个生活化的类比把 Claude Code 想象成一个刚入职的工程师。Skills相当于你交给他的岗位操作手册——我们团队写 React 组件必须用函数式 TypeScript样式统一走 CSS Modules提交前必须跑 lint 和单测。它约束的是行为方式和知识。MCP相当于给他开通的系统权限和工具账号——数据库连接、Figma 设计稿读取、Jira 任务查询、本地调试器接口。它扩展的是可触达的外部世界。一个管脑子里的规范一个管手上的工具。缺了 SkillsAI 每次输出风格飘忽、不懂你的项目约定缺了 MCPAI 只能在你贴给它的文本里打转碰不到真实系统。2.2 为什么必须是这两个而不是写更长的提示词有人会问我把规范全写进系统提示词不就行了短期可以长期一定崩。原因有三第一提示词是易失的。会话一关上下文清零下次还得重贴。Skills 是持久化在文件系统里的资产跟着项目走跟着版本走。第二提示词无法按需加载。你不可能把所有场景的规范都塞进一次对话那样既浪费上下文窗口又稀释重点。Skills 支持按任务触发写前端时加载前端规范写数据库迁移时加载迁移规范各管各的。第三提示词碰不到真实系统。你没法用一段文字让 AI 真的去查数据库、真的去读设计稿。这必须靠 MCP 这样的协议层去对接。所以正确的姿势不是写更长的提示词而是把知识沉淀成 Skills把能力接入 MCP让提示词回归它该干的活——描述这一次的具体任务。2.3 两者的协同关系Skills 可以指挥 MCP这是最容易被忽略、也最有价值的一点Skills 里可以写明在什么情况下调用哪个 MCP 工具。比如一个发布检查Skill可以规定先通过 MCP 查询 CI 流水线状态再通过 MCP 拉取最近的 issue 列表最后按固定格式输出发布报告。这样 AI 拿到的不是零散的工具而是一套编排好的动作序列。Skills 负责决策逻辑MCP 负责执行能力两者咬合起来才形成完整的工作流。3. Claude Code Skills 实战把项目规范变成可复用资产3.1 Skills 的目录结构与加载机制Claude Code 的 Skills 本质上是一组放在特定目录下的 Markdown 文件通常配合元数据每个 Skill 描述一类任务的做法。常见的组织方式是在项目根目录下建一个 skills 目录每个子目录或文件对应一个技能点。加载机制上它遵循按需注入的原则——AI 根据当前任务判断该激活哪个 Skill而不是一股脑全塞进上下文。这个设计的好处是上下文预算可控。你要知道上下文窗口是稀缺资源塞太多无关规范反而会让 AI 抓不住重点。按需加载让每次对话只携带最相关的知识输出质量明显更稳。我自己的目录大致长这样这是基于常见实践的合理组织你可以按团队习惯调整project-root/ skills/ frontend-component.md api-design.md db-migration.md release-checklist.md code-review.md每个文件聚焦一件事文件名即意图方便人和 AI 都能快速定位。3.2 一个前端组件 Skill 的完整写法拆解光说结构太虚直接看一个我实际在用的前端组件 Skill 长什么样。下面是我精简后的版本# 前端组件开发规范 ## 适用场景 当任务涉及创建或修改 React 组件时激活。 ## 技术约束 - 一律使用函数式组件 TypeScript禁止 class 组件 - 样式使用 CSS Modules禁止内联 style动态计算除外 - 组件 props 必须显式定义 interface禁止 any - 副作用统一用 useEffect依赖数组必须完整 ## 命名约定 - 组件文件PascalCase如 UserCard.tsx - 工具函数camelCase - 常量UPPER_SNAKE_CASE ## 必须遵守的检查项 1. 导出前确认无未使用的 import 2. 所有异步操作必须有 loading 和 error 状态 3. 可访问性交互元素必须有 aria-label 或可见文本 ## 输出格式 先给出组件代码再列出你做的关键决策最后提示需要补充的测试点。拆开看这个 Skill 干了四件事界定触发场景避免误激活、锁定技术约束消除风格漂移、明确命名约定保证一致性、规定输出格式让结果可预期。最后那条输出格式特别关键——它让 AI 每次交付都带上决策说明和测试提示我 review 的时候一眼就能看懂它为什么这么写。3.3 写 Skill 的三条硬经验用了大半年我总结出三条写 Skill 的铁律都是踩坑换来的。第一条一个 Skill 只干一件事。我早期图省事把前端、后端、数据库规范全塞进一个文件结果 AI 经常张冠李戴写后端时套用前端命名。拆成独立文件后误用率大幅下降。第二条约束要具体到可验证。代码要优雅这种话等于没说禁止 any依赖数组必须完整才是 AI 能执行、你能检查的。凡是无法用眼睛或工具验证的规范都别写进去。第三条给正例也给反例。只写要用函数式组件AI 偶尔还是会给你 class。加上一句反例class UserCard extends React.Component是禁止的命中率立刻提升。人对反例敏感模型也是。提示Skill 文件不要写太长。超过两三百行AI 反而会漏读关键约束。宁可拆成多个小 Skill也不要堆成一篇长文。4. MCP 实战让 AI 真正碰到你的系统和工具4.1 MCP 是什么用USB 接口理解它MCP 全称 Model Context Protocol直译是模型上下文协议。名字唬人本质很简单它是一套标准接口让 AI 能以统一的方式连接外部工具和数据源。还是用类比在 MCP 出现之前每接一个工具数据库、设计稿、任务系统都得写一套专用对接代码像早年每个手机品牌都有自己的充电口。MCP 相当于把接口统一成 USB-C——只要工具实现了 MCP 服务端AI 就能用同一套方式调用它。对开发者来说这意味着接入成本大幅降低可复用的连接越来越多。MCP 通常提供三类能力工具Tools即 AI 可以主动调用的动作比如查询数据库、创建 issue资源Resources即 AI 可以读取的数据比如文件、文档提示模板Prompts即预置的交互模板。日常用得最多的是 Tools。4.2 典型 MCP 接入场景与配置思路我目前工作流里常驻的 MCP 有这么几类每一类都对应一个真实痛点场景接入的 MCP 类型解决什么问题设计稿还原设计工具 MCPAI 直接读设计稿的图层、间距、颜色不用我截图描述任务管理项目管理 MCPAI 能查 issue、更新状态不用我复制粘贴数据库操作数据库 MCPAI 能查表结构、跑只读查询辅助写迁移脚本本地调试调试器 MCPAI 能读取断点信息、调用栈辅助定位问题配置上MCP 服务一般在 Claude Code 的配置文件里声明指定启动命令和参数。以数据库 MCP 为例思路大致是在配置里登记服务端的启动方式Claude Code 启动时拉起这个服务之后 AI 就能通过它执行查询。具体命令因工具而异核心是声明式配置 按需启动。注意接入数据库类 MCP 时务必只授予只读权限或严格限制可操作的表。让 AI 拥有写权限是高风险操作除非你有一套完善的回滚机制。4.3 MCP 与 Skills 的联动编排一个发布检查流程单用 MCP 只是多了几个工具真正威力在于用 Skill 把它们编排起来。我写过一个发布检查Skill逻辑是这样的# 发布前检查流程 ## 触发条件 当用户提到准备发布上线检查时激活。 ## 执行步骤 1. 调用 CI 相关 MCP 工具获取最近一次流水线状态 2. 调用任务管理 MCP拉取当前迭代未关闭的 issue 3. 调用数据库 MCP确认待执行的迁移脚本已就绪 4. 汇总以上信息按固定模板输出检查报告 ## 报告模板 - 流水线状态通过 / 失败附失败原因 - 未关闭 issue数量 列表 - 迁移脚本就绪 / 缺失 - 结论可以发布 / 阻塞项如下这个 Skill 本身不含任何代码它只是一段决策逻辑但配合 MCP 提供的执行能力AI 就能自动跑完一整套发布前检查。我实测下来原本要手动翻三四个系统、花十几分钟的事现在一句话触发几十秒出报告。这就是 Skills MCP 协同的典型价值把跨系统的重复流程压缩成一次自然语言指令。5. 从裸用到工程化我的完整工作流改造记录5.1 改造前后的对比我把改造前后的状态列成表你能直观看到差距维度裸用阶段工程化阶段上下文准备每次手动交代项目背景Skill 自动加载零交代代码风格每次输出不一致由 Skill 锁定稳定可预期跨系统操作人工复制粘贴MCP 直连AI 自主调用复杂流程靠临时指挥Skill 编排一键触发结果可复现差依赖当次对话好规范沉淀在文件里改造的核心动作其实就两步把重复交代的东西写成 Skill把重复搬运的操作接成 MCP。听起来简单但落地时有顺序讲究。5.2 我的改造顺序先 Skill 后 MCP我建议先做 Skills再做 MCP。原因很实际Skills 是纯文本零成本、零风险改起来随时改MCP 涉及外部系统接入有配置成本和权限风险。先用 Skills 把规范漂移这个最痛的问题解决掉你会立刻感受到输出质量的提升有了正反馈再去做 MCP 这种重活。具体节奏我是这么走的第一周把最常写的三类代码组件、接口、迁移的规范各写成一个 Skill观察一周看误用情况迭代措辞。第二周接入一两个低风险的 MCP比如只读的任务查询跑通链路。第三周开始写编排型 Skill把 MCP 串起来。整个过程不要贪多一次只改一个变量才能看清每个改动带来的效果。5.3 一个真实任务的完整走查拿给用户列表页加一个筛选功能这个任务举例走一遍工程化流程第一步我在终端里描述任务。Claude Code 识别到涉及前端组件自动激活前端组件 Skill于是它知道要用函数式组件、CSS Modules、完整依赖数组。第二步它需要确认现有的接口返回结构。这时它调用 API 文档相关的 MCP 资源直接读取接口定义而不是让我贴。第三步它按 Skill 规定的输出格式先给组件代码再列关键决策比如为什么用受控组件最后提示测试点。第四步我 review 后让它补测试它再次依据 Skill 里的测试规范生成用例。整个过程我几乎没有重复交代任何背景风格也完全一致。对比裸用阶段同样的任务我要多花五六轮对话去纠正风格和补充上下文。省下来的不是单次几分钟而是长期累积的认知负担。6. 常见问题与排查技巧实录6.1 Skill 不生效或误触发怎么办这是最高频的问题。排查思路按顺序来先确认文件位置和命名。Skill 没被识别八成是放错了目录或文件名不符合约定。对照官方文档确认路径。再看触发条件是否写清楚。如果 Skill 里没写适用场景AI 就不知道何时激活。补上明确的触发描述。检查是否被其他 Skill 覆盖。多个 Skill 约束冲突时AI 可能选错。把职责边界划清楚一个 Skill 一件事。误触发则相反通常是触发条件写太宽。把涉及代码时激活改成创建或修改 React 组件时激活精准度立刻上来。6.2 MCP 连不上或工具调用失败MCP 类问题排查我整理成一张速查表现象可能原因排查动作服务起不来启动命令或路径错误手动执行启动命令看报错工具列表为空服务端未正确注册工具检查服务端日志调用超时网络或权限问题确认目标系统可达、凭证有效权限被拒账号权限不足核对授予的权限范围提示MCP 出问题时第一步永远是脱离 AI 手动跑一遍服务端。能手动跑通问题就在配置或权限手动都跑不通问题在服务本身。这个二分法能省掉大量瞎猜。6.3 上下文被撑爆的处理经验Skills 和 MCP 用多了上下文消耗会变快。我的应对经验是Skill 保持精简MCP 结果做摘要。比如数据库 MCP 返回一大张表不要让原始结果全进上下文而是在 Skill 里规定只提取需要的字段。另外长会话该断就断把阶段性成果沉淀回 Skill 文件比硬撑着一个超长会话更高效。6.4 几个我踩过的坑第一个坑过早追求大而全的 Skill 体系。我一开始想一次性把所有规范写完结果写了三天没人用因为太理想化。后来改成用到哪写到哪反而落地快。第二个坑给 MCP 开了过大的权限。有次图方便给了写权限AI 一个误操作改了测试数据。从那以后所有 MCP 一律最小权限原则。第三个坑Skill 写完就不管了。规范会随项目演进Skill 也得跟着更新。我现在把 Skill 维护纳入 code review改规范时同步改 Skill避免文档和实际脱节。7. 落地清单今天就能开始的五步如果你看到这里想动手我建议按这个顺序来每一步都能独立见效盘点重复劳动。回想最近一周你反复跟 AI 交代了哪些背景、反复纠正了哪些风格。这些就是第一批 Skill 的素材。写第一个 Skill。挑最痛的那一个按触发场景 技术约束 命名约定 输出格式四段式写控制在两百行内。观察并迭代。用一周记录误用和漏用的情况针对性改措辞。别急着写第二个。接入一个低风险 MCP。从只读的查询类工具开始跑通链路建立信心。写一个编排型 Skill。把已有的 MCP 串成一个流程体验一句话触发整套动作的感觉。我个人在实际操作中的体会是这套改造最大的收益不是省了多少时间而是让 AI 的输出变得可预期、可复现。裸用阶段你永远不知道它这次会给你什么工程化之后它像一个熟悉你团队规范的老员工交付质量稳定在一个可接受的水位线上。这个确定性才是把 AI 真正纳入生产流程的前提。后续你还可以往更细的方向扩展比如给不同项目维护不同的 Skill 集或者把 MCP 编排成更复杂的多步工作流但那是下一步的事了先把这五步走扎实。