前端 + AI 全链路开发教程：从设计图、需求文档、接口文档到项目管理

一、整体概览

二、需求文档（PRD）环节

[三、设计图环节（Figma → 代码）](#三、设计图环节（Figma → 代码）)

第1步：读取需求文档，利用Figma生成对应设计图

[第2步：获取 Figma 个人访问令牌](#第2步：获取 Figma 个人访问令牌)

[第 3 步：添加 MCP Server](#第 3 步：添加 MCP Server)

[第 3 步：测试跑通](#第 3 步：测试跑通)

四、接口文档环节

方式一：直接读取

[方式二：配置 Apifox MCP](#方式二：配置 Apifox MCP)

总结：

[五、编码环节：AI IDE 选型](#五、编码环节：AI IDE 选型)

六、项目管理环节

七、质量管理/代码管理

[八、Claude Code Skills 与 MCP 完全指南：区别、作用域与实用推荐](#八、Claude Code Skills 与 MCP 完全指南：区别、作用域与实用推荐)

[一、先用一句话理解 Skills 和 MCP](#一、先用一句话理解 Skills 和 MCP)

[二、Skills 到底是什么？](#二、Skills 到底是什么？)

[三、MCP 到底是什么？](#三、MCP 到底是什么？)

[四、Skills 和 MCP 的核心区别](#四、Skills 和 MCP 的核心区别)

[五、Skills、MCP、Plugin、Hook、Subagent 怎么区分？](#五、Skills、MCP、Plugin、Hook、Subagent 怎么区分？)

[六、Skills 的作用范围](#六、Skills 的作用范围)

[6.1 本机通用 Skill](#6.1 本机通用 Skill)

[6.2 项目通用 Skill](#6.2 项目通用 Skill)

[6.3 项目组通用 Skill](#6.3 项目组通用 Skill)

[七、MCP 的作用范围](#七、MCP 的作用范围)

[9.1 local MCP](#9.1 local MCP)

[9.2 user MCP](#9.2 user MCP)

[9.3 MCP 的项目组通用怎么做？](#9.3 MCP 的项目组通用怎么做？)

[八、Skills 与 MCP 作用范围对比](#八、Skills 与 MCP 作用范围对比)

[九、什么时候应该做成 Skill？](#九、什么时候应该做成 Skill？)

[十、什么时候应该做成 MCP？](#十、什么时候应该做成 MCP？)

[十一、好用的 Skills 推荐](#十一、好用的 Skills 推荐)

[11.1 Superpowers](#11.1 Superpowers)

[11.2 Code Review](#11.2 Code Review)

[11.3 Feature Development](#11.3 Feature Development)

[11.4 Git / Commit Skills](#11.4 Git / Commit Skills)

[11.5 Frontend Design](#11.5 Frontend Design)

[11.6 Document Skills](#11.6 Document Skills)

[11.7 Skill Creator](#11.7 Skill Creator)

[十二、MCP 推荐](#十二、MCP 推荐)

[12.1 Context7](#12.1 Context7)

[12.2 GitHub](#12.2 GitHub)

[12.3 Playwright](#12.3 Playwright)

[12.4 Swagger / OpenAPI](#12.4 Swagger / OpenAPI)

[12.5 Database](#12.5 Database)

[12.6 Sentry](#12.6 Sentry)

[12.7 不要安装太多 MCP](#12.7 不要安装太多 MCP)

十三、一套比较实用的组合

[十四、如何判断该用 Skill 还是 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

bash 复制代码

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：

bash 复制代码

claude mcp list

figma-framelink: ✔ Connected 则为成功

第 3 步：测试跑通

提问示例：根据这个 Figma 设计实现一个 React 组件，使用 Tailwind CSS：

https://www.figma.com/design/xxxxx?node-id=123-456

链接生成如下图：

四、接口文档环节

方式一：直接读取

一般开发接口文档都在内网的某个网址，可以直接给地址让大模型读取

方式二：配置 Apifox MCP

bash 复制代码

claude mcp add swagger -- cmd /c npx -y apifox-mcp-server@latest --oas=http://192.168.x.x:8080/v3/api-docs

总结：

不同类型接口文档有不同处理方式，只实践了其中两种
读取接口文档是一方面，重要的是接口生成是否符合规范。规范靠"约定文件 + 模板"沉淀，AI 每次照抄

可按照以下结构，生成项目级的skills，保证团队按规范生成接口

bash 复制代码

.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 步开始

示例：

目录结构：

bash 复制代码

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

新项目接入：

bash 复制代码

# 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

日常使用：

bash 复制代码

执行提交流程        → 测试 → 自查 → 规范提交 → 推送分支 → 创建 PR
/review            → 以 reviewer 视角输出 BLOCKER / SUGGESTION / QUESTION

skill附件：

八、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 Skill

Claude 可以知道：

复制代码

这个项目应该按照什么方式开发

有 MCP

再加入：

复制代码

Swagger MCP

Claude 可以：

复制代码

查询接口
    ↓
获取参数
    ↓
获取返回值
    ↓
生成页面

两者结合

最终：

复制代码

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-workflow

6.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
user

9.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 package

Claude 遇到一个 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 一定要注意权限。

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 Creator

MCP

复制代码

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 越来越了解你的工作方式，同时拥有完成工作所需要的工具。