你写 API 的时候,有没有被产品经理反复改需求搞崩溃过?
以前我写一个用户模块的 API,光接口定义就改了 4 版。每次改完还得同步更新文档,测试用例也得跟着调。一套流程下来,半天没了。
后来我开始用 AI 辅助 API 设计,效率提升了不止一倍。今天把实战经验整理出来。
用 AI 做需求拆解
拿到产品需求后,别急着写接口。先让 AI 帮你拆解。
比如产品经理说:“我要一个用户注册功能,支持邮箱和密码登录,还要能第三方登录。”
你可以这样问 AI:
帮我设计一个用户注册 API 的需求文档。
要求:
1. 支持邮箱密码注册
2. 支持 Google OAuth 登录
3. 需要邮箱验证
4. 返回 JSON 格式
请列出所有需要的接口、请求参数、响应格式和错误码。
AI 会给你一份结构化的需求清单,包括:
- POST /api/v1/auth/register — 邮箱注册
- POST /api/v1/auth/verify-email — 邮箱验证
- POST /api/v1/auth/oauth/google — Google 登录
- GET /api/v1/auth/status — 登录状态查询
每个接口还会附带请求参数和响应示例。这比你直接在脑子里想要清晰得多。
用 AI 生成 OpenAPI 规范
需求确认后,下一步是写接口规范。推荐用 OpenAPI(Swagger)格式。
把刚才的需求丢给 AI,让它生成完整的 OpenAPI YAML:
openapi: 3.0.3
info:
title: User Auth API
version: 1.0.0
paths:
/auth/register:
post:
summary: 用户注册
requestBody:
required: true
content:
application/json:
schema:
type: object
required: [email, password]
properties:
email:
type: string
format: email
password:
type: string
minLength: 8
responses:
'201':
description: 注册成功
content:
application/json:
schema:
$ref: '#/components/schemas/User'
AI 生成的 OpenAPI 规范可以直接导入 Swagger UI 或 Postman,省去手动敲一遍的时间。
用 AI 设计错误码体系
很多团队的 API 错误码设计得很乱。有的用 HTTP 状态码,有的自定义错误码,有的混着用。
让 AI 帮你统一设计一个错误码体系:
我的 API 需要以下错误类型:
1. 参数校验失败
2. 认证失败
3. 权限不足
4. 资源不存在
5. 服务内部错误
6. 第三方服务调用失败
请设计一套统一的错误码方案,包含错误码数字、HTTP 状态码、错误消息模板。
得到的结果类似:
| 错误码 | HTTP 状态 | 场景 | 消息模板 |
|---|---|---|---|
| 1001 | 400 | 参数校验失败 | 字段 {field} 不符合要求 |
| 1002 | 401 | 认证失败 | 请重新登录 |
| 1003 | 403 | 权限不足 | 您没有操作权限 |
| 1004 | 404 | 资源不存在 | 请求的资源不存在 |
| 5001 | 500 | 服务内部错误 | 服务暂时不可用 |
| 5002 | 502 | 第三方调用失败 | 外部服务响应超时 |
有了这套体系,后续所有接口保持一致的错误返回格式,前端对接也省心。
用 AI 自动生成 Mock 数据
接口设计好了,后端还没写完,前端怎么办?
让 AI 生成 Mock 数据是最快的方案。给 AI 一段 OpenAPI 描述,它就能输出对应的 JSON 响应:
{
"code": 0,
"message": "success",
"data": {
"id": "usr_8f3k29d",
"email": "demo@example.com",
"name": "张三",
"created_at": "2026-07-16T08:00:00Z",
"is_verified": true
}
}
配合 WireMock 或者 MockServer,前端可以直接联调,不用等后端上线。
用 AI 写 API 文档
最后一步,文档。
把 OpenAPI 规范和你的业务逻辑说明一起交给 AI,让它生成面向开发者的 API 文档:
基于上面的 OpenAPI 规范,帮我写一份开发者文档。
要求:
1. 每个接口有详细说明和使用场景
2. 提供 cURL 请求示例
3. 列出常见错误和处理方式
4. 语言简洁,适合快速查阅
生成的文档结构大概是:
用户注册
接口地址: POST /api/v1/auth/register
功能说明: 用户使用邮箱和密码注册新账号。密码长度至少 8 位,需包含字母和数字。
请求参数:
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| string | 是 | 邮箱地址 | |
| password | string | 是 | 登录密码,最少 8 位 |
cURL 示例:
curl -X POST https://api.example.com/api/v1/auth/register \
-H "Content-Type: application/json" \
-d '{"email":"user@example.com","password":"secure123"}'
成功响应:
{
"code": 0,
"message": "success",
"data": { "id": "usr_xxx", "email": "user@example.com" }
}
总结
AI 辅助 API 设计的核心思路是:让 AI 帮你做那些重复性高、容易出错的活——需求拆解、规范编写、错误码设计、Mock 数据生成、文档撰写。
你只需要把控架构决策和业务逻辑,剩下的交给 AI。
下次设计 API 的时候,试试这个流程。你会发现,以前半天搞不定的事情,现在半小时就能收尾。