目录
一、整体概览
二、需求文档（PRD）环节
三、设计图环节（Figma → 代码）
第1步：读取需求文档，利用Figma生成对应设计图
第2步：获取 Figma 个人访问令牌
第 3 步：添加 MCP Server
第 3 步：测试跑通
四、接口文档环节
方式一：直接读取
方式二：配置 Apifox MCP
总结：
五、编码环节：AI IDE 选型
六、项目管理环节
七、质量管理/代码管理
八、Claude Code Skills 与 MCP 完全指南：区别、作用域与实用推荐
一、先用一句话理解 Skills 和 MCP
二、Skills 到底是什么？
三、MCP 到底是什么？
四、Skills 和 MCP 的核心区别
五、Skills、MCP、Plugin、Hook、Subagent 怎么区分？
六、Skills 的作用范围
6.1 本机通用 Skill
6.2 项目通用 Skill
6.3 项目组通用 Skill
七、MCP 的作用范围
9.1 local MCP
9.2 user MCP
9.3 MCP 的项目组通用怎么做？
八、Skills 与 MCP 作用范围对比
九、什么时候应该做成 Skill？
十、什么时候应该做成 MCP？
十一、好用的 Skills 推荐
11.1 Superpowers
11.2 Code Review
11.3 Feature Development
11.4 Git / Commit Skills
11.5 Frontend Design
11.6 Document Skills
11.7 Skill Creator
十二、MCP 推荐
12.1 Context7
12.2 GitHub
12.3 Playwright
12.4 Swagger / OpenAPI
12.5 Database
12.6 Sentry
12.7 不要安装太多 MCP
十三、一套比较实用的组合
十四、如何判断该用 Skill 还是 MCP？
十五、最终总结
一、整体概览
需求(PRD) → 设计稿(Figma) → 接口文档(API) → 编码(AI IDE) → 项目管理(任务跟踪) → 代码评审(PR + CI)
二、需求文档（PRD）环节
一般项目都配备有项目经理或产品经理，会输出需求文档
或者：口语化需求丢给 AI（ChatGPT / Claude / Kimi），要求输出结构化 PRD：背景目标、功能点拆解、交互流程、验收标准。
三、设计图环节（Figma → 代码）
第1步：读取需求文档，利用Figma生成对应设计图
Figma有免费额度，但次数有限，也可以尝试导入外部设计图
第2步：获取 Figma 个人访问令牌
打开 figma.com → 右上角头像 →Settings
左侧选Security→ 滚到Personal access tokens
点Generate new token→ 名称随意（如
claude-mcp）只勾这两项权限（最小权限原则）：
✅
File content（read）— 核心，读取设计稿内容✅
Dev resources（read）— 读取 Dev Mode 标注（可选）
生成后立即复制保存，只显示一次
示例：
第 3 步：添加 MCP Server
claude mcp add figma-framelink -- npx -y figma-developer-mcp --figma-api-key=你的key --image-dir=D:/MyProject/mahjong/.figma-downloads --stdio参数说明：
--figma-api-key：你的 Figma 个人访问令牌--image-dir：Figma 里图片下载到本地的目录（保留你原来这个路径挺好，避免图片混进项目目录）
验证是否成功添加MCP：
claude mcp listfigma-framelink: ✔ Connected则为成功
第 3 步：测试跑通
提问示例：根据这个 Figma 设计实现一个 React 组件，使用 Tailwind CSS：
https://www.figma.com/design/xxxxx?node-id=123-456
链接生成如下图：
四、接口文档环节
方式一：直接读取
一般开发接口文档都在内网的某个网址，可以直接给地址让大模型读取
方式二：配置 Apifox MCP
claude mcp add swagger -- cmd /c npx -y apifox-mcp-server@latest --oas=http://192.168.x.x:8080/v3/api-docs总结：
- 不同类型接口文档有不同处理方式，只实践了其中两种
- 读取接口文档是一方面，重要的是接口生成是否符合规范。规范靠"约定文件 + 模板"沉淀，AI 每次照抄
可按照以下结构，生成项目级的skills，保证团队按规范生成接口
.claude/skills/ └── api-generator/ ├── SKILL.md # 技能说明（必需）：触发条件 + 完整规范 └── templates/ # 模板文件（可选，AI 按需读取） ├── request.ts ├── common.ts └── module.example.ts五、编码环节：AI IDE 选型
claude code / cursor / codex / trae都可以
六、项目管理环节
一些项目管理平台会有对应的MCP，但添加MCP可能加大token消耗，建议直接用需求文档
七、质量管理/代码管理
hooks 自动 lint → 主干推送拦截 → CLAUDE.md 纪律 → GitHub/GitLab 双平台 CI Review
可以根据实际项目让ai给你生成项目级别的skill，主要流程就是上面，可根据项目调整
执行：
直接项目下访问对应的skill，例如skill叫/dev-workflow，执行dev-workflow则可跑整体流程
或直接说：执行提交流程
或：
跑一下测试和类型检查 → 只执行第 1 步
review 一下当前改动 → 只执行第 3 步，输出 BLOCKER/SUGGESTION/QUESTION
提交代码 → 跳过推送，只分 commit
推送并创建 PR → 从第 5 步开始
示例：
目录结构：
dev-workflow/ ├── SKILL.md # 技能核心：触发条件 + 五步流程 + 铁律 ├── README.md # 安装指南（5 步即插即用） ├── templates/ │ ├── claude-md-snippet.md # 粘贴进项目 CLAUDE.md 的纪律规范 │ └── settings.hooks.json # hooks 配置（改文件自动 lint + 拦截主干直推） └── ci/ ├── github-claude-review.yml # GitHub Actions：PR 自动触发 Claude Review └── gitlab-claude-review.yml # GitLab CI：MR 自动触发 Claude Review新项目接入：
# 1. 安装 skill（项目级，进 Git 团队共享） cp -r dev-workflow 你的项目/.claude/skills/ # 2. 把 templates/settings.hooks.json 合并进项目 .claude/settings.json # 3. 把 templates/claude-md-snippet.md 追加进 CLAUDE.md # 4. 按平台复制 ci/ 下对应文件，配置好 token日常使用：
执行提交流程 → 测试 → 自查 → 规范提交 → 推送分支 → 创建 PR /review → 以 reviewer 视角输出 BLOCKER / SUGGESTION / QUESTIONskill附件：
八、Claude Code Skills 与 MCP 完全指南：区别、作用域与实用推荐
使用 Claude Code 一段时间后，很容易遇到几个概念：
Skills
MCP
Plugins
Hooks
Subagents
尤其是Skills 和 MCP，刚开始使用 Claude Code 时很容易混淆：
Skill 和 MCP 到底有什么区别？
什么应该安装到本机？
什么应该放到项目里？
团队如何共享 Skills 和 MCP？
哪些 Skills 和 MCP 比较值得使用？
本文从实际开发角度，把这些问题一次整理清楚。
一、先用一句话理解 Skills 和 MCP
最简单的理解：
Skill = 告诉 Claude「怎么做」
MCP = 给 Claude「工具做什么」
例如：
Skill
告诉 Claude：
开发页面时： 1. 先分析现有代码 2. 尽量最小修改 3. 不随意升级依赖 4. 修改后检查兼容性 5. 最后进行代码 Review这是一个：
工作方法 / 工作流程 / 专业经验
MCP
给 Claude 一个外部工具：
Swagger MCP ↓ 读取 OpenAPI ↓ 查看接口 ↓ 查看参数 ↓ 查看返回值Claude 可以直接调用这个工具。
所以可以简单记成：
Skill = 方法论 MCP = 工具能力二、Skills 到底是什么？
Skill 可以理解成：
一个可以被 Claude Code 使用的「专业技能包」。
一个 Skill 通常可以包含：
SKILL.md 参考资料 脚本 模板 示例例如：
.claude/ └── skills/ └── vue-development/ ├── SKILL.md ├── examples/ └── templates/SKILL.md可以描述：
你是一个前端开发专家。 开发组件时： 1. 优先复用现有组件 2. 不随意修改公共样式 3. 修改前先分析影响范围 4. 遵循项目已有编码规范 5. 修改完成后进行检查以后遇到相关任务，Claude 就可以使用这套知识和流程。
Skills 的核心价值不是单纯“给 Claude 更多知识”，而是：
把重复的工作流程、专业经验和最佳实践沉淀下来。
三、MCP 到底是什么？
MCP 全称：
Model Context Protocol它解决的问题是：
让 Claude 能够连接外部工具和数据。
例如：
Claude Code │ ├── GitHub MCP ├── Swagger MCP ├── Database MCP ├── Playwright MCP ├── Sentry MCP └── Slack MCP通过 MCP，Claude 可以进一步：
查询数据库
查询 API 文档
操作 GitHub
操作浏览器
查看错误监控
查询项目管理系统
调用企业内部 API
所以 MCP 更像是：
Claude 的外部工具箱。
四、Skills 和 MCP 的核心区别
假设你告诉 Claude：
帮我开发一个用户列表页面。
没有 Skill
Claude：
自己判断应该怎么开发有 Skill
加入：
Frontend Development SkillClaude 可以知道：
这个项目应该按照什么方式开发有 MCP
再加入：
Swagger MCPClaude 可以：
查询接口 ↓ 获取参数 ↓ 获取返回值 ↓ 生成页面两者结合
最终：
Skill ↓ 告诉 Claude 怎么做 MCP ↓ 提供 Claude 可以调用的工具 Claude Code ↓ 结合两者完成任务因此：
Skill 解决「怎么做」，MCP 解决「能做什么」。
五、Skills、MCP、Plugin、Hook、Subagent 怎么区分？
Claude Code 不只是一个聊天工具，它已经逐渐形成了一套完整的 Agent 开发体系。
可以简单理解：
| 能力 | 解决的问题 |
|---|---|
| Skill | 怎么做 |
| MCP | 调用外部工具 |
| Plugin | 打包多个能力 |
| Hook | 自动触发操作 |
| Subagent | 专门负责某类任务 |
例如：
Claude Code │ ┌────────────────┼────────────────┐ ↓ ↓ ↓ Skill MCP Hook 怎么做 工具 自动触发 │ │ │ ↓ ↓ ↓ 开发规范 Swagger 自动 lint PR流程 GitHub 自动格式化 测试流程 数据库 自动检查如果把多个能力组合起来，就可以进一步形成：
Plugin六、Skills 的作用范围
Skills 的作用范围主要取决于：
Skill 文件放在哪里。
实际开发中，可以把它理解成三种范围：
本机通用 项目通用 项目组通用6.1 本机通用 Skill
通常放在用户级 Claude 配置目录：
~/.claude/skills/例如：
~/.claude/ └── skills/ └── my-code-review/ └── SKILL.md特点：
当前电脑 │ ├── 项目A ├── 项目B └── 项目C ↓ 都可以使用适合：
个人代码审查习惯
个人 Git 工作流
自己的开发方法
自己常用的工作流程
不希望提交到项目仓库的 Skill
例如：
my-git-workflow my-code-review my-debug-workflow6.2 项目通用 Skill
放在当前项目：
项目/ └── .claude/ └── skills/例如：
project/ ├── src/ ├── package.json └── .claude/ └── skills/ └── development/ └── SKILL.md这个 Skill 就属于当前项目。
适合：
项目编码规范
项目开发流程
项目测试流程
项目特殊技术约束
项目内部业务规则
6.3 项目组通用 Skill
项目组通用 Skill，本质上通常还是：
项目/.claude/skills/但需要：
把
.claude/skills/提交到 Git。
例如：
git add .claude/skills git commit -m "add claude skills" git push其他开发人员：
git pull就可以获得相同的 Skill。
因此：
项目通用 ↓ .claude/skills/ 项目组通用 ↓ .claude/skills/ ↓ 提交 Git ↓ 团队成员共享所以两者目录可能完全一样。
真正的区别是：
项目通用是“当前项目需要”；项目组通用是“团队共同维护并通过 Git 分发”。
七、MCP 的作用范围
MCP 和 Skills 的管理方式不完全一样。
Claude Code 中常见的 MCP scope 可以理解成：
local user9.1 local MCP
例如：
claude mcp add swagger -- cmd /c npx -y apifox-mcp-server@latest --oas=http://192.168.x.x:8080/v3/api-docs不指定--scope时，通常使用 local scope。
可以理解为：
当前项目使用的 MCP。
例如：
项目 A ↓ Swagger MCP ↓ 项目 A 的接口文档如果切换到其他项目，可能就无法继续使用这个 MCP。
9.2 user MCP
如果希望 MCP 在自己的多个项目中都可以使用：
claude mcp add --scope user swagger -- cmd /c npx -y apifox-mcp-server@latest --oas=http://192.168.x.x:8080/v3/api-docs可以理解成：
当前用户 │ ├── 项目A ├── 项目B └── 项目C ↓ Swagger MCP适合：
Swagger
GitHub
Context7
通用数据库工具
通用开发工具
自己长期使用的 MCP
9.3 MCP 的项目组通用怎么做？
团队如果希望所有成员使用统一的 MCP 配置，通常可以把 MCP 配置纳入项目配置，例如：
.mcp.json项目结构：
project/ ├── .mcp.json ├── .claude/ │ └── skills/ └── src/然后提交到 Git。
这样团队成员拉取项目后，可以获得统一的 MCP 配置。
不过需要特别注意：
不要把 Token、密码、数据库密码等敏感信息直接提交到 Git。
推荐使用环境变量或个人本地配置保存敏感信息。
因此团队 MCP 更适合：
Git ↓ 共享 MCP 配置 + 环境变量 ↓ 每个人自己的敏感信息八、Skills 与 MCP 作用范围对比
可以记住下面这张表：
| 能力 | 本机通用 | 项目通用 | 项目组通用 |
|---|---|---|---|
| Skill | ~/.claude/skills/ | .claude/skills/ | .claude/skills/+ Git |
| MCP | --scope user | local | .mcp.json/ Plugin + Git |
| 核心用途 | 个人能力 | 项目能力 | 团队统一能力 |
一句话：
Skill 看文件放在哪里，MCP 看配置 scope 或项目配置。
九、什么时候应该做成 Skill？
可以使用一个非常简单的判断方法：
如果你经常告诉 Claude：
“以后都按照这个方法做。”
那么非常适合做成 Skill。
例如：
代码 Review 流程 PR 流程 前端开发流程 测试流程 文档生成流程这些都属于：
Skill十、什么时候应该做成 MCP？
如果你想告诉 Claude：
“你可以访问这个外部系统。”
那么更适合使用 MCP。
例如：
GitHub Swagger 数据库 浏览器 Sentry Slack Jira这些属于：
MCP十一、好用的 Skills 推荐
下面这些是比较值得关注的 Skill / Plugin 能力。
11.1 Superpowers
Superpowers 是一套面向 AI Coding Agent 的软件开发工作流，核心思路不是简单告诉 Claude“怎么写代码”，而是让 Agent 按照更完整的软件工程流程工作。
典型流程：
需求 ↓ 澄清需求 ↓ 制定计划 ↓ 设计方案 ↓ 拆分任务 ↓ 实现 ↓ 测试 ↓ Review它尤其适合：
中大型功能开发
多步骤任务
需要先设计再编码的任务
希望减少 Claude 直接开始乱改代码的情况
希望让 AI Coding 更接近真实软件开发流程
Superpowers 的核心价值可以概括成：
让 Claude 不只是“写代码”，而是按照软件工程流程完成任务。
如果平时经常让 Claude Code 独立完成一个完整 Feature，非常值得尝试。
11.2 Code Review
代码审查类 Skill 也非常值得安装。
典型流程：
修改代码 ↓ Code Review ↓ Bug 性能 安全 兼容性 可维护性 ↓ 输出问题特别适合团队项目。
可以让团队形成统一的 AI Code Review 标准。
11.3 Feature Development
Feature Development 类 Skill 适合：
从需求到完整功能开发。
典型流程：
需求 ↓ 分析代码 ↓ 制定方案 ↓ 拆任务 ↓ 修改代码 ↓ 测试 ↓ Review如果经常使用：
“帮我把这个功能完整做出来”这一类 Skill 非常实用。
11.4 Git / Commit Skills
如果经常让 Claude 帮忙处理 Git，可以使用 Git / Commit 相关能力。
例如：
检查修改 ↓ 分析 diff ↓ 生成 commit message ↓ commit ↓ push ↓ PR特别适合团队统一 Commit Message 和 PR 流程。
11.5 Frontend Design
前端开发者可以关注：
frontend-design适合：
页面设计
UI 实现
组件设计
响应式布局
前端界面优化
尤其是：
“根据这个需求帮我设计并实现页面”这类任务。
11.6 Document Skills
如果经常让 Claude Code 处理办公文档，可以关注官方的 Document Skills。
主要包括：
PDF Word Excel PowerPoint适合：
读取文档 生成文档 修改文档 分析 Excel 生成 PPT 处理 PDF如果你的工作中经常涉及这些文件，属于非常高频的生产力能力。
11.7 Skill Creator
如果已经开始大量使用 Skills，非常推荐：
skill-creator它解决的问题是：
如何把自己的工作流程沉淀成 Skill。
例如你每天都会：
分析需求 ↓ 查询接口 ↓ 修改代码 ↓ 测试 ↓ Review ↓ 生成总结那么就可以把这套流程沉淀成：
my-development-workflow以后重复使用。
这也是从：
“使用别人提供的 Skill”进阶到：
“自己构建 Skill”的重要一步。
十二、MCP 推荐
12.1 Context7
它主要解决：
查询各种开发框架和库的文档。
例如：
Vue React Vite Node Next.js 各种 npm packageClaude 遇到一个 API 时，可以先查询相关文档，再写代码。
特别适合解决：
“这个 API 到底应该怎么用？”避免完全依赖模型记忆。
12.2 GitHub
如果代码托管在 GitHub：
GitHub MCP非常值得使用。
可以围绕：
Repository Issue PR Code Workflow进行操作。
典型场景：
查看 Issue ↓ 分析需求 ↓ 查相关代码 ↓ 修改代码 ↓ 检查 PR这样 Claude Code 就可以更深入地参与整个开发流程。
12.3 Playwright
前端开发非常推荐：
Playwright MCP它可以让 Claude 通过浏览器进行页面操作和验证。
例如：
启动浏览器 ↓ 打开页面 ↓ 点击按钮 ↓ 填写表单 ↓ 检查结果 ↓ 截图适合：
UI 调试
页面验证
E2E
回归测试
前端问题排查
这是一个非常典型的：
Skill + MCP组合。
Skill 可以告诉 Claude：
页面应该怎么测试。
Playwright MCP 则真正提供：
操作浏览器的能力。
12.4 Swagger / OpenAPI
如果项目有 Swagger / OpenAPI：
Swagger MCP非常值得配置。
例如：
用户说： “帮我实现用户列表页面”Claude 可以：
Swagger MCP ↓ 查询用户列表接口 ↓ 获取参数 ↓ 获取返回结构 ↓ 生成 API 调用 ↓ 生成页面这比手动把接口文档复制给 Claude 高效很多。
12.5 Database
如果项目使用：
MySQL PostgreSQL可以考虑数据库 MCP。
Claude 可以：
查看表结构 ↓ 查看字段 ↓ 查询数据 ↓ 分析问题不过数据库 MCP 一定要注意权限。
推荐：
开发数据库 + 只读账号不要直接给 Claude：
生产数据库 + 最高权限12.6 Sentry
如果项目使用 Sentry，可以考虑 Sentry MCP。
典型场景：
线上错误 ↓ Sentry ↓ 错误堆栈 ↓ 请求信息 ↓ 相关代码 ↓ Claude 分析特别适合：
“线上这个错误到底是什么原因？”
这种问题。
12.7 不要安装太多 MCP
这是非常重要的一点。
不要看到一个 MCP 就安装一个。
例如：
20 个 MCP + 100 个工具并不一定比：
5 个 MCP + 20 个高频工具更好。
因为 MCP 越多，Claude 面对的工具越多，需要判断：
这个任务应该使用哪个工具？反而可能增加复杂度。
更推荐：
高频 Skill + 高频 MCP + 项目专用能力十三、一套比较实用的组合
对于大多数开发者，可以从下面这套开始：
Skills
Superpowers Code Review Feature Development Git / Commit Frontend Design Skill CreatorMCP
Context7 GitHub Playwright Swagger / OpenAPI Database Sentry不需要一次全部安装。
可以根据自己的工作流逐渐增加。
十四、如何判断该用 Skill 还是 MCP？
最后再总结一次：
“告诉 Claude 怎么做”
使用：
Skill例如：
代码 Review 流程 开发流程 测试流程 项目规范“让 Claude 可以访问某个系统”
使用：
MCP例如：
GitHub Swagger 数据库 浏览器 Sentry“发生某个事件自动执行”
考虑：
Hook例如：
保存代码 ↓ 自动格式化“组合多个能力”
考虑：
Plugin十五、最终总结
Claude Code 可以理解成一套 AI 软件工程系统：
Claude Code │ ┌────────────────┼────────────────┐ ↓ ↓ ↓ Skill MCP Hook │ │ │ ↓ ↓ ↓ 怎么做 能做什么 什么时候做 │ │ │ └────────────────┼────────────────┘ ↓ Plugin 能力组合与分发而作用范围可以记成：
Skill ~/.claude/skills/ ↓ 本机通用 项目/.claude/skills/ ↓ 项目通用 项目/.claude/skills/ + Git ↓ 项目组通用MCP：
--scope user ↓ 当前用户通用 local ↓ 当前项目 .mcp.json / Plugin + Git ↓ 项目组共享最终可以用三句话记忆：
Skill 是方法，MCP 是工具。
个人习惯放本机，项目规范放项目，团队规范提交 Git。
不要追求 MCP 越多越好，而应该围绕真实开发流程建立“少而精”的 Skill + MCP 组合。
对于刚开始使用 Claude Code 的开发者，与其一次安装几十个工具，不如先建立这样一套基础能力：
Superpowers + Code Review + Context7 + GitHub + Playwright + Swagger然后随着自己的开发流程不断增加 Skill 和 MCP。
真正高效的 Claude Code，不是“装了多少 MCP”，而是：
让 Claude 越来越了解你的工作方式，同时拥有完成工作所需要的工具。
