Claude Code 技能与 MCP 配置实战：32 个技能和 8 个服务器让 AI 编程效率翻倍

开头

说句实在话，我见过太多人把 Claude Code 当成一个“高级终端”来用，敲两行命令让它改个文件，然后就说“也就那样”。这种用法不能说错，但真的暴殄天物。Claude Code 真正的价值不在“对话式编程”，而在于你把它当成一个有手有脚、能自己调工具、能按你预先定义的方式思考的智能体来用。如果你还在裸用，没有配置任何技能（Skill）和 MCP 服务器，那你其实只发挥了这个工具大概两成的功力。

这篇文章不是来跟你讲 API 怎么申请、模型怎么切换这种基础操作的。我要分享的是我自己在真实项目里反复打磨出来的 32 个亲测可用的技能配置，以及 8 个让我少写无数胶水代码的 MCP 服务器。内容会覆盖背后的设计思路、具体的配置写法、实操中遇到的坑，以及怎么排查“工具注册不上”这类玄学问题。适合已经折腾过 Claude Code、想进一步提升效率的开发者，也适合那种刚装好但不知道从哪下手的新手——我尽量把每一步都写清楚，让你能直接抄作业。

1. 内容整体设计与思路拆解

先说个核心概念。Claude Code 里的 Skill 和 MCP 到底解决什么问题？一句话：它们让 Claude 从“只能聊天”变成“能干活”。但两者干的活不一样，很多人搞混。

1.1 技能（Skill）与 MCP 的定位差异

Skill 是给 Claude 预设的“思考方式和行为模式”。它不直接连接外部工具，而是告诉模型：“当你遇到某类任务时，按这套流程来想、按这套规范来做”。我把它理解成给员工写的《工作手册》。比如你写了一个“前端重构技能”，里面规定了：遇到组件拆分必须先列现有依赖、必须考虑可访问性、输出代码前必须附一份自测 checklist。Claude 读到这个 Skill 之后，处理相关任务时就会主动按这个手册走，行为稳定很多。

MCP（Model Context Protocol）则是连接外部世界的数据通道。它解决的是“让模型能读写真实文件、调用真实接口”的问题。你可以不写一行自定义代码，只通过配置就能让 Claude 读取 Figma 设计稿的图层结构、查数据库表结构、操作浏览器自动化测试、甚至直接调用蓝湖的标注数据。

很多人会问：有了 MCP，是不是就不需要 Skill 了？我的答案：这两者是配合关系，不是替代关系。MCP 给 Claude 提供“手”和“眼睛”，Skill 给 Claude 提供“大脑里的工作流程”。一个 MCP 服务器可以被多个 Skill 调用，一个 Skill 也可以在设计好流程后依赖多个 MCP 工具来落地执行。比如“设计稿转代码”这个 Skill，内部就依赖了 Figma 的 MCP 工具去读取图层数据，同时又用了一套自定义的生成规范，保证输出代码符合项目团队的风格。

1.2 为什么“裸用”会浪费大部分能力

裸用 Claude Code 时，它的行为非常“泛化”。你说“帮我改一下登录页的 bug”，它会直接猜你项目结构、猜你要改哪个文件。运气好能猜对，运气不好你就要来回纠正好几轮，Token 消耗也因此蹭蹭上涨。

而配好 Skill 之后，它会先主动识别你项目的技术栈、寻找对应的路由定义、定位登录页组件、阅读相关测试用例，再动手修改。这个“先理解再动手”的差别，带来的不只是准确率提升，而是整体体验质的变化。 我在实际对比中测过：同一批任务，裸用的失败率大概有三到四成，配置好 Skill 和 MCP 之后，失败率能压到一成以下。

此外，技能和 MCP 还能帮你把团队的“隐性知识”显性化。比如我们团队要求所有接口封装必须走统一的 request 实例，带上统一的鉴权头，错误码要统一处理。我把这套规则写成 Skill 之后，任何成员用 Claude Code 开发，生成的网络层代码都天然符合团队规范。这比在 code review 里一次次口头强调高效太多。

2. 32 个亲测技能：分类、配置与适用场景

接下来进入硬核部分。我把自己手头在用的 32 个技能按功能分了 6 大类，每个都会说明用途和配置思路。我不会把每个技能的完整 XML 都贴出来（那太长了，而且你应该按自己项目去改），但我会挑几个典型例子把结构展示清楚，其余的按“功能名 + 触发器 + 核心流程”的方式描述，方便你自行索引和编写。

2.1 全套技能的三大类划分

从使用频率和价值维度看，32 个技能大致能分成三个梯队：

第一梯队是高频日常型，比如代码审查技能、Bug 修复技能、提交信息生成技能，这类技能几乎每个项目都会用到，我使用频率最高。

第二梯队是专项领域型，比如 Unity/Cocos 游戏开发辅助技能、设计稿转代码技能、数据库迁移技能，这些只会在特定项目里触发，但一旦用到，价值极其显著。

第三梯队是流程治理型，比如代码规范检查技能、TDD 开发流程技能、团队提交规范技能，它们主要是保证输出质量不下滑，相当于给 Claude 装了一个“质量闸门”。

2.2 典型技能拆解：代码审查技能

先说一个我每天都离不开的“代码审查技能”。它的触发器是用户文件中包含“review”或“代码审查”。它的核心指令包含四段：先梳理变更影响面、按安全性和可维护性逐条检查、输出问题分级清单、给出具体修复建议而非泛泛而谈。

用代码形式展示一下我配置里的骨架逻辑：

markdown复制# 代码审查技能

当用户提到“review”“代码审查”或需要检查代码质量时，激活本技能。

执行流程：
1. 先用 `git diff --stat` 确认本次变更范围。
2. 按文件逐一阅读 diff，重点关注：
   - 是否存在安全问题（SQL 注入、越权、敏感信息硬编码）；
   - 是否存在明显性能隐患（循环内查询、重复渲染、大对象拷贝）；
   - 是否偏离项目既有的分层规范。
3. 输出格式：按 `严重问题 / 建议改进 / 可忽略建议` 三级分类。
4. 每个问题必须给出修改示例，不允许只写“建议优化”。

这段技能代码看起来简单，但实际效果很明显。之前 Claude 在 review 时经常输出“这代码可读性可以再提升”这种正确但没用的废话。加了“必须给出修改示例”这条硬性指令之后，输出的可操作性提升了一倍不止。

2.3 32 技能完整清单速查表

下面这 32 个技能，我按类别放在一张总表里，方便你按需查阅：

每一条都是我实际跑过、不是拍脑袋想出来的。尤其是“代码提交前自检技能”，我把它配成了每次 Claude 主动问“要不要我跑一遍 ESLint、类型检查和相关测试”的提示，从源头挡住了很多低级错误。

2.4 多技能同时命中时的优先级配置

这里有个容易踩的坑：如果你在同一个项目里放了过多技能，而 Claude 一次只能加载有限上下文，它可能不知道该用哪个，甚至把两个技能混在一起执行。我的处理方式是：在每个技能的头部都加一个“interruption 条件”和“优先级”字段，同时在项目的 CLAUDE 全局指令里写清楚：若多个技能匹配，按“流程治理 > Bug 修复 > 功能开发”的顺序执行。

这样做的好处是，当一个任务同时触发“代码审查技能”和“Bug 修复技能”时，Claude 会先按 Bug 修复流程定位并修改，再用代码审查技能过一遍改动，不会出现一边改 bug 一边 review 的逻辑冲突。

3. 8 个 MCP 服务器：选型、配置与实战

有了技能作为“大脑流程”，下一步就是给 Claude 装上能触碰真实世界的“手”。这才是把效率真正拉满的关键。我把我常用的 MCP 服务器精简到 8 个，每一个都值得装、也经得起长期用。

3.1 为什么这 8 个 MCP 值得长期持有

先说结论：这 8 个分别覆盖了 设计、浏览器、数据库、代码托管、移动端、游戏引擎、第三方服务、本地环境 八个高频场景。你不需要全装，但装了之后你会发现，以前很多“让 Claude 去查一下”的环节，现在变成了“让 Claude 直接查并拿结果回来”。

这里强调一下：MCP 服务器不是越多越好。每多一个 MCP，Claude 在每次工具调用时都要多扫描一遍工具列表，过多了容易造成上下文混乱、选择困难。我见过有人一口气装了 20 多个 MCP，结果 Claude 经常调错工具。我的建议是：保持 5 到 10 个高价值 MCP，配合 Skill 里的流程约束，效果反而最好。

3.2 8 个 MCP 服务器的功能速查与配置地址

注意：上面的 Figma MCP 引用的“蓝湖 MCP”在不同平台的可用性可能会有版本差异，配置前最好先去对应仓库看 README，确认当前维护状态。

3.3 配置一个 MCP 的最小实操示例

拿我这边最常用的 Playwright MCP 举例。在 Claude Code 的配置文件里加一段：

json复制{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"],
      "env": {
        "DEBUG": "true"
      }
    }
  }
}

添加完成后，重启 Claude Code 对话，用工具列表确认 playwright 已经被识别。这时候你只需要说“帮我在浏览器里打开这个页面，检查登录按钮是否可用”，Claude 就会自动驱动一个真实浏览器完成操作，并把结果反馈给你。这个能力在做端到端测试的时候简直是神器——你不需要再复制粘贴浏览器地址、手动截图、口头形容页面长什么样，直接让它自己去看。

3.4 MCP 与 Skill 的联动实战案例

这里分享一个我常用来解释两者关系的案例。我在“设计稿转代码”技能里使用了类似下面的流程：

markdown复制1. 使用 Figma MCP 读取设计稿的 frame 列表。
2. 确认设计尺寸、颜色变量、字体规范。
3. 用前端代码生成规则输出 React 组件。
4. 生成后调用 Playwright MCP 打开本地预览截图，核对还原度。

这个过程里，Skill 负责“定计划”，Figma MCP 负责“取素材”，Playwright MCP 负责“验结果”。你仔细看，这不就是一个完整的“设计师交底 — 开发实现 — 自测走查”的闭环吗？以前需要团队里不同角色接力完成的事，现在一个智能体就串起来了。虽然不可能完全替代专业前端工程师的审美判断，但它至少能把 80% 的机械转化工作做掉，剩下 20% 交给人类去打磨，效率是肉眼可见的提升。

4. 工具安装与配置避坑指南

写到这里，估计很多人已经按捺不住想去试了。但根据我的经验，第一次配置 MCP 和 Skill 时，大家都会遇到几个非常类似的坑。我把它们集中整理一下，帮你们一次跳过。

4.1 安装路径与全局环境变量的坑

第一个坑出在 MCP 服务器的执行方式上。很多人习惯直接用 npx 启动，但如果你在某个子目录里启动 Claude Code，npx 可能找不到全局安装的命令，或者因为权限问题直接报错。我的建议：所有 MCP 服务器尽量全局安装，并确保命令在 PATH 里能直接访问。

用 npm 全局安装示例：

bash复制npm install -g @playwright/mcp

然后验证：

bash复制which playwright-mcp

如果用 npx 方式配置，尽量在配置里写全 @latest 版本号，避免 npx 缓存旧包导致行为不一致。另外，Claude Code 在每次启动时会自动拉取 MCP 依赖，如果你在无网环境或用的是受限网络，这一步可能导致启动卡住，需要预留超时时间。

4.2 环境变量与 Token 消耗控制

MCP 服务器本身需要访问对应服务的 API，所以要提前准备环境变量，比如 Figma 的 Access Token、GitHub 的 Personal Access Token。我建议把这类密钥统一放到 .env 文件里，让 Claude Code 启动时自动加载，不要硬编码在配置里。省得哪天把配置分享给同事时，不小心把密钥也交出去了。

关于省 Token 这件事，也有个小技巧：如果你用一个 MCP 工具做批量查询，尽量让 Claude 先通过一次工具调用拿回足够多的上下文，再统一处理，不要频繁反复调用同一个 MCP 工具。举例来说，与其让它一台一台地查询数据库表结构，不如直接让它拉取整库的表清单，一次拿回来，再在内部筛选。这样可以极大降低“工具描述信息 + 返回内容”带来的 Token 开销。

4.3 Windows 与 macOS 的差异注意点

如果你在 Windows PowerShell 下安装，经常会遇到执行策略限制或路径分隔符的问题。一个常见的处理方法是使用 cmd /c 来包装命令：

json复制{
  "mcpServers": {
    "github": {
      "command": "cmd",
      "args": ["/c", "npx", "@modelcontextprotocol/server-github"]
    }
  }
}

macOS 上相对好一点，但要注意首次启动时可能弹“无法验证开发者”的提示。处理方法是在系统设置里允许对应脚本运行，或者干脆在终端跑一遍安装命令，让它被 Gatekeeper 放行。另外，如果是公司安全管控的设备，需要确认是否允许 Claude Code 做本地网络监听，因为部分 MCP 服务器要靠本地端口通信。

4.4 Claude Code 与自定义模型配置的兼容性问题

许多人会尝试把 Claude Code 的端点切换到其他兼容模型，比如内网部署的模型服务。这时候经常出现一个著名的报错：“... is not a model this version of Claude Code recognizes”。这个问题的根源在于：Claude Code 内置的模型白名单不包含你输入的这个模型名。解决办法通常有两种：一是用环境变量把模型名映射到当前版本支持的模型上，二是更新 Claude Code 到最新版本，看它是否已扩展白名单。如果你切的是某款开源模型或非官方接入方式，还要检查模型服务是否完整支持 Claude Code 的工具调用协议。因为 MCP/Hub 式的工具调用依赖底层模型的 function calling 能力，如果模型本身不支持结构化工具输出，技能和 MCP 都会失灵。

5. 实操过程与核心环节实现

理论讲了不少，现在我们真正进入一段实操的现场。我会以一个相对真实的需求为例，逐步展示从配置技能到集成 MCP 的完整链路。

5.1 从零开始：建立项目级技能目录

先建立一个目录，推荐放在项目的 .claude/skills 下。你可以按技能名建子文件夹，每个子文件夹下至少要有一个 SKILL.md，用来描述技能触发条件和执行流程。结构如下：

text复制.claude/
└── skills/
    └── code-review/
        └── SKILL.md

为了后续扩展，我习惯在 SKILL.md 的头部写 YAML front matter，里面记录技能名称、描述和触发关键词。模型读取时会优先解析这些元信息，然后在正文中读取更详细的操作要求。

markdown复制---
name: code-review
description: 当用户想进行代码审查、检查提交质量或准备发起 MR 时使用。
triggers:
  - review
  - 代码审查
  - code review
---

5.2 实操演练：在 Claude Code 中接入 GitHub MCP 并自动提交 PR 自检

假设我手头有个前端项目，刚改完一个 bug，想让 Claude 自动把变更提交并生成一个 Pull Request，同时完成自检。我配置了 GitHub MCP，操作顺序如下：

1. 在对话中说：“请帮我 review 当前代码变更，然后以 fix: 修复登录按钮重复点击 为提交信息提交到新分支，最后创建 PR。”
2. Claude Code 先触发“代码提交前自检技能”，内部执行了一套检查命令单，包括跑 lint、类型检查、相关测试。
3. 如果检查有问题，它会直接停下来报错，告诉你具体文件和原因。如果没有问题，它会自动创建分支、提交并推送。
4. 推送后，它调用 GitHub MCP 创建 PR。创建成功后会返回 PR 链接和相关 CI 状态。

这个过程中最重要的不是“它能自动提交”，而是 它能在提交前完成自查。很多人不敢让 AI 直接提交代码，担心的就是没有质量闸门。通过技能把质量闸门显式写进去，这个问题就解决了。

5.3 设计稿到前端代码的完整链路

再展示一个“设计稿到前端代码”的典型场景。我先让 Claude 列出当前设计稿的所有 Frame：

text复制请列出这个 Figma 文件中的所有 Frame，并标出主画板的尺寸。

Claude 调用 Figma MCP 后，会返回类似这样的结构化数据：每个 Frame 的 id、名称、绝对坐标、尺寸、背景色、内部文本节点等。接着，我让它按“移动端优先、右侧固定操作栏”的布局生成 React Native 代码。由于我在“设计稿转代码技能”里已经约定了组件拆分策略，它生成的代码就不会是一个巨大的、无法维护的 View 嵌套，而会按区块拆分成独立组件，并附带基础的样式定义。

最后，我让它自查一遍“文本溢出”“按钮点击区域过小”等问题。这些细节如果是人肉开发，很容易漏；但如果你把自检项写进技能，模型的执行会稳定很多。这种联动的价值，一句话总结就是：流程确定性提升，结果不随心情随机波动。

6. 常见问题与排查技巧实录

就算配置得再顺，总会有翻车的时候。下面这些都是我实际踩过、也帮身边同事排查过的典型问题，整理成速查表，供你遇到类似情况时直接对照。

6.1 常见问题速查表

6.2 排查“MCP 工具注册不上”的完整思路

在所有问题里，最常见的其实是“MCP 注册不上”。比如你满心欢喜配好了 Figma MCP，但在 Claude Code 里用工具列表一查，什么都没有。这时候不要慌，按顺序做几步：

第一步，确认服务器本身能跑。打开终端，手动执行配置里的启动命令，看有没有报错。如果是 npx 包，直接运行一遍，看是否能正常拉起服务并打印“MCP server running”之类的日志。

第二步，确认 Claude Code 自身识别配置。用 claude mcp list 查看已注册的服务器名称和状态。如果列表里有，但工具列表为空，大概率是服务器在注册时没有正确输出 MCP 协议要求的 JSON-RPC 握手信息。这时检查版本兼容性，很多老版本包不支持新版协议。

第三步，检查网络。部分 MCP 服务器需要访问外网做 OAuth 或 API 调用，如果你的网络环境有限制，即使进程起来了，工具调用也会失败。可以把浏览器调试模式打开，观察网络请求是否被中断。

第四步，如果以上都没问题，试试重启 Claude Code 会话。很多 MCP 服务器只在会话启动时加载一次，改了配置文件必须重启才生效。

6.3 降低 Token 成本的三条经验

关于省 Token，我有一套实际使用中的三步法。

第一，把“大而全的检索”改成“小而准的检索”。比如让 MCP 查询数据库，不要让它 SELECT * 返回全表，而是写清楚只要字段名和索引信息。返回越少 Token 占用越少。

第二，把“一次问多次”改成“多次问一次”。让 Claude 在做 MCP 调用前先汇总要问的问题。比如你有 10 个页面要检查，不要让它逐个打开再逐个汇报，而是让它批量打开并记录状态，最后统一给出结论。这样能省掉大量重复工具描述带来的开销。

第三，善用技能里的“低噪音模式”。我有个“简洁回答技能”，会在执行完任务后不输出冗长的解释，只返回最终结果。单独看好像只是少了几句废话，但累积起来量非常大。比如让“playwright 打开 30 个页面并检查状态”，如果每步都解释半天，整体 Token 消耗会非常夸张；开启低噪音模式后，能压缩大概一半以上的不必要输出。

6.4 技能不生效？从触发词反查问题

技能的“不生效”十有八九不是技能本身写错了，而是触发条件太窄。我见过有人把一个技能命名为 git-commit-standard，同时在 description 里只写了“commit”一个词，结果他输入“帮我提交代码”时，技能没有激活。

正确写法是在 description 和 triggers 里覆盖同义表达，比如：

markdown复制description: 当用户要求提交代码、生成 commit message、规范化提交、准备 commit 时使用。

模型对自然语言的匹配能力很强，但你得把常见的说法喂进去。不要只留一个生僻的英文术语，否则它很难把这个技能和用户的真实意图关联起来。

7. 安全边界、权限控制与项目适配

Claude Code 的能力越强，越要重视“边界”。给它接上浏览器操作、数据库只读和代码托管操作之后，如果不做控制，风险会成倍增加。

7.1 让人放心的权限前置检查清单

我给自己强制规定了一组检查项，每次新增 MCP 或技能前都过一遍：

• 这个 MCP 是否只需要只读权限？比如数据库类尽量用只读账号。
• 是否允许 Claude 在真实浏览器中执行操作？如果不能，用 headless 模式或指定专用测试环境。
• Git 操作是否允许直接 push？建议在普通开发时不放开 push，只有显式命令才让它执行。
• 敏感信息是否可能被工具返回并写入日志？检查 MCP 返回内容是否有密钥字段，有则做脱敏。
• 多 Agent 并发时，是否会发生资源竞争？比如两个 Claude 实例同时改同一个文件。

7.2 最小权限原则下的 MCP 配置示例

以 GitHub MCP 为例，官方方案通常会要求一个高权限 token，因为要读仓库、提 issue、管理 PR。但我们大多数场景下只需要读代码和创建 PR，所以可以创建一个自定义 token，只勾选 repo 和 pull requests 权限。如果只是做代码搜索，甚至可以只给 public_repo。

再比如数据库类 MCP。我会单独建一个“只读查询账号”，只授予 SELECT 权限。然后在 MCP 配置里的数据库连接串上使用这个账号，这样即使模型被提示注入攻击类的恶意 prompt 诱导，它最多也只能查数据，无法删表或改库。这是最基本的底线。

7.3 如何在多人协作项目中统一配置

如果你的团队有 5 个成员，大家各自使用不同的技能和 MCP 版本，时间久了必然出现行为不一致。

最直接的办法：把技能和 MCP 配置提交到仓库里，让所有成员通过 git 同步。另外，在项目根目录的全局指令文件里，写入统一的规则和限制。比如规定“所有 MCP 工具调用前必须先输出计划”，那么每个成员在本地使用时都会受这条规则约束。还有一个经验是：为不同的分支定义不同的权限等级。比如在 main 分支上，不允许放开 push 权限，Claude 只能生成 diff 和提交建议，实际 push 由人类执行；而在个人 feature 分支上，可以放开自动提交。这种方式既享受了 Agent 带来的效率提升，又保持了主分支的安全稳定。

8. 从“能用”到“好用”的调优心得

最后这部分，我想聊一些更偏“手感”的东西。配置只是起点，真正的效率提升来自不断调优。

8.1 通过日志复盘优化技能质量

Claude Code 会输出每一步的操作记录，很多开发者忽略了这个宝藏。当某个任务执行不佳时，我会把日志翻出来，找到它是在哪一步开始偏离预期的。如果是识别错了技能，就调整触发词；如果是在执行过程中丢了重要约束，就把约束提到更靠前的位置；如果它始终输出过长的解释，就加一个“只输出必要内容，禁止额外解释”的指令。这种复盘式调优，比盲目加更多技能有效得多。

8.2 场景模板化：不要让模型每次都重新发明流程

我的做法是把自己常做的任务模板化。比如起一个新项目时，我有一套“项目脚手架技能”，里面写好了要执行哪些命令、要生成哪些目录、初始化哪些配置文件。以后每次开新仓库，只要告诉 Claude 项目名和技术栈，它就能按固定流程生成出结构一致的项目骨架。这有点像是把日常工作流写成了剧本，Claude 只需要按剧本走，不会因为模型随机性而每次生成不同的结构。

8.3 从 ChatGPT 迁移到 Claude Code 的适应期技巧

如果你之前是重度 ChatGPT/Codex 用户，转过来时可能会不适应。最典型的问题是你习惯把一大段需求全部丢给 AI，让它自由发挥。但 Claude Code 在小步快跑的场景下体验反而更好。你可以让它先做一小步，你确认后再继续。尤其当它要调用外部 MCP、动真实环境时，一步一步确认能避免很多灾难。

另外，Claude Code 对上下文窗口的使用方式比 Web 端更激进，它会自动做 token 压缩。但如果你发现它“忘了”早期的约束，最好把关键约束在当前消息里再重复一次，或者把它们放进项目级指令中，让它每次都读到。

8.4 一个关于模型选择的现实建议

标题有点敏感，但如果非要说模型的“上限”，就我个人在各类接入方式下的体验来看，Claude 系列的模型在复杂工具调用、长上下文理解和指令遵循上确实有明显优势。但工具本身不等于模型，你的提示词设计、技能拆分、MCP 配置才是决定最终效果的核心。哪怕你用的是相对弱一些的模型，只要把任务拆得足够小、把流程约束得足够死，也能完成相当多工作。

个人经验收尾

写了这么多，最想跟你们说的一句话是：不要盲目上配置，先理清自己的痛点。

我的第一个技能“Bug 定位与修复技能”就是因为当时老让 Claude 改错文件而写的；我的第一个 MCP“Playwright MCP”是因为我实在不想再手动截图告诉它页面变成什么样了。你不需要一次性把这 32 个技能和 8 个 MCP 全部装齐，那只会让你陷入配置地狱。挑你最痛的两三个点，先补齐对应的技能和 MCP，用顺了再慢慢扩。

最后再分享一个小技巧：每次你新写一个 Skill，先拿一个真实历史任务去“回测”它。如果这个技能真能比裸用时的输出好一截，才值得保留；如果提升不明显，删掉也不可惜。技能和 MCP 不是装饰品，它们最终服务的只有一件事——让你的开发流顺畅到不需要反复打断、不需要重复交代、不需要事后大改。这也是我配置所有这些内容的唯一标准。