阅读视图

发现新文章，点击刷新页面。

我写了个 Claude Code Skill，再也不用手动切图传 COS 了

掘金前端

jerrywus

2026年2月9日 15:31

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

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

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

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

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

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

效果直接看下面的图片

截图里能看到整个链路：

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

我就输入了一句"根据 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，然后替换代码

所以流程是这样的：

我在 Figma 里选中要实现的页面
在 Claude Code 里说"根据 Figma 设计稿实现这个页面"
Claude 通过 Figma MCP 读设计稿，识别出图片素材
自动导出图片 → 压缩 PNG → 传 COS → 拿到 CDN URL
用 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

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

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

我第一版 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 搞了个接口代码生成器

掘金前端

jerrywus

2026年2月9日 10:24

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

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

前言

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

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

打开文档，一个个看接口定义
手写 TypeScript 类型（请求参数、响应结构）
写 API 调用函数
造 Mock 数据给本地开发用
注册 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 强制约束
人为错误	字段名拼错、类型写错	从文档直接提取，基本不会错

总结

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

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

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

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

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

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