切图、压缩、传 COS、复制链接、粘回代码。一个页面 5 张图就要重复 5 遍。我受够了，写了个 Skill 把这活儿交给 AI。

起因：每天在 Figma 和 COS 控制台之间反复横跳

我做小程序开发，日常跟设计师对接。每次拿到 Figma 设计稿，写代码之前得先处理图片：

1. Figma 里一张张切图导出
2. 打开 TinyPNG 网站，把 PNG 拖进去压缩
3. 登录腾讯云 COS 控制台，上传
4. 复制 CDN 链接，粘到代码里
5. 下一张，重复

一个页面 5 张图，这套操作就要走 5 遍。说实话，这活儿谁干谁烦。

后来我发现 Claude Code 有个 Skill 机制，可以教它执行自定义流程。花了2小时折腾出来一个 image-auto-upload Skill，现在图片这块基本不用我操心了。

效果直接看下面的图片

截图里能看到整个链路：

1. 左上角是 Figma 设计稿
2. 左侧终端里 Claude Code 在自动识别图片素材
3. 中间是tinypng压缩 + 上传 COS 的过程
4. 右上角 COS 控制台里文件已经上传成成功
5. 右下角是小程序里的最终效果

我就输入了一句"根据 Figma 设计稿实现这个页面（自行切图上传替换）"，它自己全办了。

Skill 是个什么东西

简单说，Skill 就是一个文件夹，放在 .claude/skills/ 下面，里面告诉 Claude 怎么完成某个特定任务。

Claude Code 本身能读代码、写代码、跑命令，但它不知道你们项目的图片要传到哪个 COS Bucket，不知道 PNG 要先压缩，不知道上传路径的前缀规则。这些"项目私货"，你得自己教它。Skill 就是干这个的。

目录结构长这样：

.claude/skills/image-auto-upload/
├── SKILL.md              # 给 Claude 看的操作手册
├── README.md             # 给人看的使用文档
├── resources/            # 放待上传的图片
│   └── README.md
└── scripts/              # 执行脚本
    ├── upload_images.cjs  # Node.js 上传脚本
    └── compress_png.py    # Python 压缩脚本

最核心的是 SKILL.md。Claude 读这个文件来理解：什么时候该用这个技能、具体怎么操作、调什么脚本、结果怎么展示。

SKILL.md 怎么写

这个文件写得好不好，直接决定 Claude 能不能正确干活。我拆开讲讲。

触发场景

## 触发场景

### 场景 1：Figma 设计稿实现
当根据 Figma 设计稿实现页面时，如果设计稿中包含图片素材：
1. 列出可上传的图片素材（图片名称、类型、用途）
2. 等待用户确认需要上传哪些图片
3. 执行上传并返回 CDN URL

### 场景 2：直接上传
当用户直接告知需要上传的图片或图片文件夹时，直接执行上传流程。

两种触发方式。一种是实现 Figma 设计稿时 Claude 自己发现有图片，会先问你要不要上传；另一种是你直接说"上传图片"，它立刻执行。

我一开始只写了第二种，后来发现配合 Figma Agent 用的时候，Claude 不知道该主动处理图片，还得我手动提醒。加上第一种之后就顺畅了。

处理流程

将图片放入 resources/ 文件夹
      │
      ▼
  是图片文件？(png/jpg/jpeg/webp/gif/svg)
      │
  ┌───┴───┐
 YES     NO → 跳过
  │
  ▼
  是 PNG 格式？
  ┌───┴───┐
 YES     NO
  │       │
  ▼       │
自动压缩   │
  │       │
  └───┬───┘
      │
      ▼
 上传到 Tencent COS
      │
      ▼
  返回 CDN URL
      │
      ▼
 自动清理源文件

几个设计上的考虑：

• PNG 先过 TinyPNG API 压缩再传，JPG/WebP 直接传。PNG 压缩率一般在 60%-80%，省的流量还是挺可观的
• .DS_Store 之类的杂文件自动跳过，不用手动清理
• 传完自动删源文件。一开始我没加这个，resources 目录越来越大，后来加了自动清理

输出格式

| 图片名称 | CDN URL |
|----------|---------|
| icon.png | https://xxx.cos.ap-nanjing.myqcloud.com/applet/icon.png |
| bg.jpg   | https://xxx.cos.ap-nanjing.myqcloud.com/applet/bg.jpg |

上传完用表格展示结果，方便直接复制 URL。

两个脚本，一个压缩一个传

整个 Skill 靠两个脚本干活。

PNG 压缩（compress_png.py）

import tinify

def compress_image(input_path, output_path=None):
    tinify.key = TINYPNG_API_KEY  # 从 .env.skills 读取

    input_size = input_file.stat().st_size
    source = tinify.from_file(str(input_file))
    source.to_file(str(output_path))  # 压缩后覆盖原文件
    output_size = output_path.stat().st_size

    compression_ratio = round((1 - output_size / input_size) * 100, 2)
    return { "compression_ratio": compression_ratio }

逻辑很直白：读文件、调 TinyPNG API、写回去覆盖原文件。TinyPNG 免费额度每月 500 次，个人项目完全够用。

COS 上传（upload_images.cjs）

const COS = require('cos-nodejs-sdk-v5');

// 上传单个文件（分片上传）
function uploadFile(filePath, key) {
  // 1. 初始化分片上传
  cos.multipartInit({ Bucket, Region, Key }, (err, data) => {
    // 2. 上传分片
    cos.multipartUpload({ ... Body: fs.createReadStream(filePath) }, () => {
      // 3. 完成上传
      cos.multipartComplete({ ... });
    });
  });
}

// 上传整个文件夹（递归子目录）
async function uploadFolder(folderPath, prefix) {
  for (const file of files) {
    if (!isImageFile(file)) continue;  // 跳过非图片
    compressPng(file);                  // PNG 先压缩
    await uploadFile(file, key);        // 传到 COS
    fs.unlinkSync(file);               // 删源文件
  }
}

用了 COS SDK 的分片上传，支持递归子目录。上传成功删源文件，失败的留着方便重试。

密钥放哪

COS 密钥和 TinyPNG API Key 放在项目根目录的 .env.skills 里：

# .env.skills（记得加 .gitignore）
COS_BUCKET=your-bucket-name
COS_REGION=ap-nanjing
COS_UPLOAD_PREFIX=applet
TINYPNG_API_KEY=your-tinypng-api-key

这个文件不进 Git，密钥不会泄露。

实际用起来是什么感觉

配合 Figma 用（我最常用的方式）

我项目里还有个 figma-designer Agent，配置里写了一条：

遇到图片，先自动切到本地，然后调用 skills 进行压缩上传 COS，然后替换代码

所以流程是这样的：

1. 我在 Figma 里选中要实现的页面
2. 在 Claude Code 里说"根据 Figma 设计稿实现这个页面"
3. Claude 通过 Figma MCP 读设计稿，识别出图片素材
4. 自动导出图片 → 压缩 PNG → 传 COS → 拿到 CDN URL
5. 用 URL 替换代码里的图片引用，生成 Vue 组件

我只管最后看一眼代码对不对。中间图片那一堆事，完全不用管。

说实话第一次跑通的时候还挺意外的，没想到几个工具串起来能这么顺。

手动传几张图

有时候设计师单独丢几张图过来，不走 Figma 流程：

我：帮我上传 resources 里的图片

Claude：发现 resources 目录下有 3 张图片：
- banner.png (PNG，将自动压缩)
- icon-success.png (PNG，将自动压缩)
- photo.jpg (JPG，直接上传)

正在处理...

[banner.png] 正在压缩 PNG... 压缩完成 (72% reduction)
[banner.png] 上传完成
[icon-success.png] 正在压缩 PNG... 压缩完成 (65% reduction)
[icon-success.png] 上传完成
[photo.jpg] 上传完成

========== 上传完成 ==========
成功: 3 个文件
失败: 0 个文件

| 图片名称 | CDN URL |
|----------|---------|
| banner.png | https://xxx.cos.../applet/banner.png |
| icon-success.png | https://xxx.cos.../applet/icon-success.png |
| photo.jpg | https://xxx.cos.../applet/photo.jpg |

源文件已自动清理。

批量传一整套图

比如一次性传一套图标：

resources/
├── icons/
│   ├── home.png
│   ├── cart.png
│   └── user.png
└── backgrounds/
    ├── login-bg.jpg
    └── main-bg.jpg

上传后目录结构原样保留：

applet/icons/home.png
applet/icons/cart.png
applet/icons/user.png
applet/backgrounds/login-bg.jpg
applet/backgrounds/main-bg.jpg

这个我踩过坑。一开始上传脚本不支持子目录，所有文件都平铺到根路径下，文件名一冲突就覆盖了。后来加了递归目录支持才解决。

想自己搞一个？照着来

1. 建目录

mkdir -p .claude/skills/image-auto-upload/{scripts,resources}

2. 装依赖

# PNG 压缩
pip install tinify

# COS 上传
npm install cos-nodejs-sdk-v5

3. 配环境变量

项目根目录建 .env.skills：

COS_BUCKET=your-bucket-name
COS_REGION=ap-nanjing
COS_UPLOAD_PREFIX=your-prefix
TINYPNG_API_KEY=your-tinypng-api-key

TinyPNG API Key 去 tinypng.com/developers 申请，免费的，每月 500 次额度。

4. 写 SKILL.md

这步最花时间，也最值得花时间。几个经验：

1. 触发场景写清楚，不然 Claude 不知道什么时候该用
2. 流程用流程图或步骤列表，别写大段文字
3. 命令给完整的，能直接复制执行的那种
4. 定义好输出格式，不然每次返回的结果格式都不一样

我第一版 SKILL.md 写得太简略，Claude 经常漏步骤。后来补了流程图和具体命令，就稳定多了。

5. 加 .gitignore

echo ".env.skills" >> .gitignore
echo ".claude/skills/image-auto-upload/resources/*" >> .gitignore
echo "!.claude/skills/image-auto-upload/resources/README.md" >> .gitignore

到底省了多少事

列个对比吧：

操作	手动	用 Skill
切图导出	一张张从 Figma 导出	自动识别导出
PNG 压缩	开 TinyPNG 网站拖拽	自动调 API
上传 COS	登控制台手动传	脚本自动传
复制链接	一个个复制 URL	表格直接给
替换代码	手动粘贴	自动替换
5 张图耗时	大概 10 分钟	30 秒左右

代码量也不大，Python 脚本 136 行，Node.js 脚本 290 行。写 SKILL.md 反而花的时间更多，因为要反复调试 Claude 的理解是否准确。

说到底，Skill 就是把你脑子里"这个项目图片该怎么处理"的经验，写成 Claude 能看懂的文档。教一次，后面就不用再操心了。

如果你项目里也有类似的重复操作，可以试试写个 Skill。不一定是图片上传，任何有固定流程的事情都行。

一句话生成整套 API：我用 Claude Code 自定义 Skill + MCP 搞了个接口代码生成器

从 Swagger 文档到 TypeScript 类型、API 函数、Mock 数据，一句指令全自动。

前言

做前端的应该都经历过这种事：

后端丢来一个 Swagger 链接，然后你得：

1. 打开文档，一个个看接口定义
2. 手写 TypeScript 类型（请求参数、响应结构）
3. 写 API 调用函数
4. 造 Mock 数据给本地开发用
5. 注册 Mock 路由

一个模块少说 2-3 个接口，这些重复劳动能耗掉半天。

后来我想，这活儿能不能自动化？于是折腾了一套方案，现在只要一句话：

实现接口：https://gateway.xxx.cn/doc.html#/组织架构服务/供应商管理/page_1

Claude Code 会自己打开 Swagger 文档、提取接口信息、让你勾选要实现哪些接口，然后并行生成所有代码。

这篇文章记录一下整个搭建过程和实际跑起来的效果。

整体架构

先看全貌，方案分三块：

┌─────────────────────────────────────────────────┐
│                  api-add Skill                   │
│              (工作流编排 / 入口)                    │
├─────────────────────────────────────────────────┤
│                                                  │
│  ┌──────────────────┐                            │
│  │ chrome-devtools   │  ← 读取 Swagger 文档       │
│  │      MCP          │  ← 提取接口信息             │
│  └──────────────────┘                            │
│           │                                      │
│           ▼                                      │
│  ┌──────────────────────────────────┐            │
│  │        Agent Team (并行)          │            │
│  │  ┌────────────┐ ┌─────────────┐  │            │
│  │  │ api-define │ │ mock-create │  │            │
│  │  │  (Haiku)   │ │  (Haiku)    │  │            │
│  │  │            │ │             │  │            │
│  │  │ TS 类型    │ │ Mock 数据    │  │            │
│  │  │ API 函数   │ │ Mock 路由    │  │            │
│  │  └────────────┘ └─────────────┘  │            │
│  └──────────────────────────────────┘            │
│                                                  │
└─────────────────────────────────────────────────┘

• Skill：自定义技能，定义工作流怎么跑
• MCP (Model Context Protocol)：让 AI 能操控浏览器，直接读文档
• Agent Team：两个 Agent 同时干活，一个写类型和 API，一个写 Mock

下面一个个说。

一、Chrome DevTools MCP -- 让 AI "看见"浏览器

MCP 是什么？

MCP（Model Context Protocol）是 Anthropic 出的一个开放协议，让 AI 能跟外部工具交互。简单说就是 AI 的插件系统，接上不同的 MCP Server，AI 就多了一种能力。

为什么要用 Chrome DevTools MCP？

Swagger/Knife4j 文档是动态渲染的 SPA 页面。你用 fetch 或 curl 去请求，拿到的只是一个空壳 HTML，接口信息全靠 JS 渲染出来，根本抓不到。

Chrome DevTools MCP 能让 AI 操控一个真实的浏览器：

• 打开页面，等 JS 渲染完
• 读取页面的可访问性树（Accessibility Tree）
• 点击元素、做页面交互

说白了就是让 AI 能像人一样看网页。

怎么配置

在 Claude Code 里添加 chrome-devtools MCP server：

chrome devtools mcp github 地址

• 打开 github 项目页面，找到 Claude Code 的配置指令。进入项目根目录，终端执行：

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

• 然后在项目 .claude 目录下创建 mcp.json：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest"
      ]
    }
  }
}

配好之后 Claude Code 就能操作浏览器了，主要用到这几个工具：

工具	干什么的
navigate_page	打开指定 URL
take_snapshot	获取页面快照（可访问性树）
click	点击页面元素
fill	填写表单
take_screenshot	截图

我们这个场景主要用前三个：导航、快照、点击。

二、api-add Skill -- 工作流编排

Skill 是什么？

Claude Code 的 Skill 就是一个 Markdown 文件，告诉 AI 碰到什么情况该怎么做。里面写清楚：

• 什么时候触发
• 按什么步骤执行
• 有什么限制

文件放在 .claude/skills/<skill-name>/SKILL.md，Claude Code 启动时会自动加载。

api-add Skill 怎么设计的

我想要的效果是：给一个 Swagger URL，自动把接口文档变成可用的代码。

.claude/skills/api-add/SKILL.md

---
name: api-add
description: 从 Swagger 文档或 md 文档快速创建 API function、
  TypeScript 类型定义和 Mock 实现。
  触发关键词：实现接口、创建接口、添加API、接口定义。
---

# API from Swagger Doc

## skill 触发场景

### 场景1
用户提供接口 url，并说实现接口定义

### 场景2
用户指定一个 md 文档，则直接从文档中读取接口定义

## 工作流程

### 第一步：获取接口信息

使用 chrome-devtools-mcp 读取 Swagger 文档：

1. 使用 navigate_page 打开 Swagger URL
2. 使用 take_snapshot 读取页面内容
3. 展开左侧菜单，获取当前分类下的所有接口列表
4. 使用 AskUserQuestion，列出所有接口供用户选择
5. 用户确认后，逐一点击并提取完整信息

### 第二步：创建 Agent Team 并行生成代码

创建 2 个 teammate 分别负责：
- api-define：TypeScript 类型 + API 函数
- mock-create：Mock 数据 + Mock 路由

### 第三步：清除 teams 并结束

这里说几个我做的选择：

1. 为什么用 MCP 而不是直接请求 API？

Swagger 文档是前端渲染的 SPA，HTTP 请求拿不到内容。必须在真实浏览器里跑一遍 JS 才能看到接口信息。

2. 为什么要让用户选接口？

一个模块可能有十几个接口，但这次迭代可能只用到其中两三个（或者部分接口已经实现过了）。让用户自己勾选，省得生成一堆用不上（或者重复）的代码。

3. 为什么用 Agent Team？

写 TypeScript 类型/API 函数和写 Mock 数据/路由，这两件事互不依赖。让两个 Agent 同时跑，时间省一半。而且 Agent 用的是 Haiku 模型，比主模型便宜很多。

✏️ 我测试了一下，单独写⬆是6分钟多一点；使用agent teams 是4分钟多一点（因为是小功能， 时间节省不太明显， 但贵在省时间。 你可以尝试大功能，比如实现一个复杂的模块，时间节省会更明显）

三、Agent 定义 -- 分工干活

除了 Skill，还得定义两个 Agent，它们才是真正写代码的。

api-define Agent

.claude/agents/api-define.md

---
name: api-define
description: 实现指定模块的 api function & typescript 类型的创建
model: haiku
color: green
---

实现指定模块的 api function & typescript 类型的创建，
严格按以下要求实现：

1. 严格参照 .claude/rules/ 中的编码规范
2. 完整实现：TypeScript 类型、API 函数

mock-create Agent

.claude/agents/mock-define.md

---
name: mock-create
description: 实现指定 api 接口的 mock 实现
model: haiku
color: orange
---

实现指定 api 接口的 mock 实现，严格按以下要求实现：

1. 严格参照 .claude/rules/ 中的编码规范
2. 完整实现：Mock 服务器（mocks 目录），
   实现 Express 接口（routes、controllers、data）

几个值得说的点：

• model: haiku -- 用轻量模型就够了，写这种模式化的代码不需要大模型，跑得快还省钱
• "严格参照编码规范" -- 靠 .claude/rules/ 里的规则文件约束代码风格，后面会讲
• color -- 终端里用不同颜色区分两个 Agent 的输出，看着方便

四、实战演示

来看实际跑一遍是什么样。我要给"供应商管理"模块实现接口。

Step 1：触发 Skill

只需要输入一句话：

实现接口：https://gateway.xxx.cn/doc.html#/组织架构服务/供应商管理/page_1

Claude Code 会自动识别到 api-add Skill，加载后通过 MCP 打开 Swagger 文档：

Step 2：读取文档，选择接口

AI 通过浏览器快照读到页面内容，找到左侧菜单里"供应商管理"下的所有接口，弹出选择框让我勾：

它做了这几件事：

• 识别了左侧菜单的接口列表（POST 分页列表、GET 配置商户）
• 点进每个接口 Tab，提取了完整的请求参数和响应结构
• URL 指向的"分页列表"被标成了推荐选项

我两个都选了。

Step 3：Agent Team 并行干活

确认后，Claude Code 起了一个 Agent Team，两个 Agent 同时开工：

截图里能看到：

• api-definer（绿色）在写 TypeScript 类型定义和 API 函数
• mock-creator（橙色）在写 Mock 数据和路由
• 两个同时跑，互不影响
• 底部状态栏显示着两个 Agent 的运行状态

Step 4：完成，收工

两个 Agent 干完活，自动关闭并清理资源：

最终生成了这些文件：

# API & 类型定义
src/types/supply-company.ts          ← TypeScript 类型
src/api/supply-company/index.ts      ← API 函数

# Mock 实现
mocks/routes/data/supply-company-page.json    ← Mock 数据
mocks/routes/supply-company.controller.cjs    ← Mock 控制器
mocks/routes/org.cjs                          ← 路由挂载（已更新）

五、看看生成的代码

代码质量怎么样？直接贴。

TypeScript 类型定义

部分展示：

// src/types/supply-company.ts

/** 供应商分页查询参数 */
export interface ISupplyCompanyPageParam extends IPageParam {
  /** 供应商名称 */
  name?: string;
}

/** 供应商分页列表项 */
export interface ISupplyCompanyPageVO {
  /** 供应商组织id */
  orgId: number;
  /** 公司编码 */
  code: string;
  /** 供应商名称 */
  orgName: string;
  /** 负责人id */
  staffId: number;
  /** 负责人姓名 */
  userName: string;
  /** 状态 */
  status: string;
  /** 所属商户 */
  merchantName: string;
  /** 创建人 */
  creator: string;
  /** 创建时间 */
  createTime: string;
}

I 前缀、JSDoc 注释、继承 IPageParam，跟项目里手写的一模一样。

API 函数

部分展示：

// src/api/supply-company/index.ts

export async function querySupplyCompanyPage(
  params: ISupplyCompanyPageParam
) {
  let total = 0;
  let data = [] as ISupplyCompanyPageVO[];
  params = toConditional(params);

  try {
    const { code, context, message } = await Http.post<{
      total: number;
      data: ISupplyCompanyPageVO[];
    }>(`${baseUrl}/page`, { ...params });

    if (code !== EResponseCode.Succeed) {
      throw new Error(message || '服务器异常，请稍后再试~');
    }
    total = context?.total || 0;
    data = context?.data || [];
  } catch (error) {
    throw new Error(getHttpErrorMessage(error));
  }

  return { total, data };
}

项目里标准的 API 写法：async/await + try/catch + toConditional + 错误处理，一个不差。

Mock 数据

部分展示：

// mocks/routes/data/supply-company-page.json
[
  {
    "orgId": 1001,
    "code": "SC-2025-001",
    "orgName": "上海奢品供应链有限公司",
    "staffId": 2001,
    "userName": "张经理",
    "status": "ENABLED",
    "merchantName": "LuxMall旗舰店",
    "creator": "系统管理员",
    "createTime": "2025-01-15 10:30:00"
  }
  // ... 更多数据
]

Mock 数据的字段值是有意义的中文内容，不是那种 "string" 占位符。

Mock 控制器

部分展示：

// mocks/controllers/supply-company.controller.cjs

const express = require('express');
const router = express.Router();
const supplyCompanyList = require('./data/supply-company-list.json');

/**
 * 供应商分页列表
 * POST /page
 */
router.post('/page', (req, res) => {
  let all = JSON.parse(JSON.stringify(supplyCompanyList));
  const { page = 1, size = 50, name } = req.body || {};

  // 按供应商名称模糊搜索
  if (name) {
    all = all.filter((item) =>
      String(item.orgName).includes(String(name))
    );
  }

  const total = all.length;
  const start = (Number(page) - 1) * Number(size);
  const end = start + Number(size);
  const data = all.slice(start, end);

  res.json({
    code: 0,
    message: null,
    context: { total, data },
    traceId: '',
    spanId: '',
  });
});

module.exports = router;

分页、模糊搜索、标准响应格式，都按项目的 Mock 规范来的。

六、代码质量靠什么保证？Rules

你可能会想：AI 怎么知道我们项目的编码规范？

靠 .claude/rules/ 目录。这是 Claude Code 的规则系统，你可以理解为给 AI 写了一份项目编码手册：

.claude/rules/
├── api.md           ← API 实现标准（函数命名、错误处理模式）
├── ts-define.md     ← TypeScript 规范（I前缀、E前缀、JSDoc）
├── mock.md          ← Mock 服务器架构（路由、控制器、数据文件）
├── components.md    ← 组件库参考
├── vue-single-file.md ← Vue SFC 标准
└── ...

每个 Agent 工作时都会读这些规则文件。所以生成出来的代码风格跟项目里手写的一致，不会出现那种一看就是 AI 写的通用代码。

七、想复刻？文件结构在这

如果你想在自己项目里搞一套，需要这些文件：

.claude/
├── agents/
│   ├── api-define.md          ← API 定义 Agent
│   └── mock-define.md         ← Mock 创建 Agent
├── skills/
│   └── api-add/
│       └── SKILL.md           ← 工作流编排 Skill
├── rules/
│   ├── api.md                 ← API 编码规范
│   ├── ts-define.md           ← TypeScript 规范
│   └── mock.md                ← Mock 规范
└── ...

# MCP 配置（项目级或全局）
.mcp.json                      ← Chrome DevTools MCP 配置

八、效果对比

维度	手动开发	api-add Skill
耗时	6.5m	4.3m
类型定义	手动从文档抄	自动提取，不会漏字段
API 函数	复制模板手动改	自动生成，符合规范
Mock 数据	手动编假数据	自动生成，内容像真的
代码规范	看个人习惯	Rules 强制约束
人为错误	字段名拼错、类型写错	从文档直接提取，基本不会错

总结

回头看，这套方案做了四件事：

1. 用 MCP 让 AI 能读浏览器里的 Swagger 文档
2. 用 Skill 把多步骤任务编排成一句话就能触发的流程
3. 用 Agent Team 让两个轻量 Agent 并行干活，省时间也省钱
4. 用 Rules 约束代码风格，保证生成的代码跟手写的一样

说到底就是把"从文档到代码"这个重复劳动自动化了。

这套方案也不只能用在 Swagger 上。改一下 Skill 的工作流，Apifox、Postman、自定义 Markdown 文档、GraphQL Schema，只要浏览器能打开的接口文档都能接。

如果你也在用 Claude Code，可以试试 Skill + MCP 这个组合。

---

觉得有用的话点个赞，也欢迎在评论区聊聊你的 Claude Code 玩法。