API与集成专家

解决什么问题

把一份 API 文档变成能跑的客户端代码，往往要在认证、请求构造、错误处理、重试、测试、SDK 封装之间反复横跳。现实里这些环节大多是复制粘贴拼出来的：OAuth2 的 token 刷新逻辑每个项目写一遍，429 和 503 该重试几次全靠猜，第三方返回的错误码没有统一映射，等服务上线了才发现超时配置只写了连接超时。结果是集成代码能跑，但很难维护，换个接口又要重来。

工作方式

这个技能把 API 集成拆成一条标准化流水线，输入 OpenAPI/Swagger 文档或手写接口描述和目标语言，就能按以下环节产出代码与配套资产。

• 需求解析：识别 API 类型（REST、GraphQL、gRPC、Webhook 等）、认证方式、集成模式与数据流向，据此确定调用方案。
• 认证鉴权模板：按 API Key、OAuth2.0、JWT、mTLS、HMAC-SHA256 签名等场景直接套用现成模板，包含 token 刷新、证书轮换、时间戳防重放等细节。
• 请求构造：根据文档生成请求结构体，带字段类型、必填校验和默认值；提供源到目标字段映射规则，自动识别分页/游标/批量端点，并按 Retry-After、X-RateLimit 响应头做自适应限速。
• 错误处理与重试：按四级错误矩阵决定重试次数和退避算法（指数退避、线性退避、加倍超时），叠加熔断器与降级方案，把第三方错误码映射到内部错误体系。
• 测试与质量：从 OpenAPI 契约生成 Pact 测试，一键启动本地 Mock，覆盖正常、异常、边界、并发四类场景，并给出 P50/P95/P99 与 TPS 性能基线。
• SDK 封装：生成 Python、Node.js、Java、Go 的客户端代码、三档使用示例、README、Postman Collection 和部署清单。

适用边界

前提是你手上有相对完整的接口文档，或至少能写出清晰的接口描述。它解决的是集成工程化问题，不替代接口设计评审；生成的重试和熔断参数需要结合实际 SLA 调整。认证凭据仍要由你自己安全管理，技能只负责把获取与刷新逻辑写对。