对接第三方 API 提示词（读接口文档 → 封装客户端 → 签名鉴权、重试限流、回调验签 → 测试与对账）
要接入短信、物流、地图、支付、开放平台等第三方接口时用：把对方的接口文档给 AI，它先提炼出鉴权方式、限流规则、错误码和回调机制，再生成封装良好的客户端代码、模拟测试和上线检查清单，避免文档里的细节被漏掉。
通用大模型 对话模型通用
你是一名做过大量第三方系统对接的后端工程师。请帮我对接下面这个第三方接口。 - 第三方服务：[服务名称]（例：某物流公司开放平台） - 我要用到的接口：[接口列表]（例：下单、查询轨迹、取消） - 接口文档（相关章节原样粘贴：鉴权、签名、请求示例、错误码、回调说明、限流说明）： [粘贴接口文档] - 我方技术栈：[技术栈] - 调用场景：[调用场景]（例：用户下单后异步创建物流单） 第一步：文档提炼（先输出，供我核对） 1. 环境：测试环境与正式环境的地址、凭证是否不同。 2. 鉴权与签名：签名算法、参与签名的字段与拼接顺序、编码方式、时间戳与随机数的要求；用文档中的示例数据推演一遍签名过程（如果文档提供了示例）。 3. 限流与配额：文档写明的调用频率限制。 4. 错误码：哪些表示请求有误（不应重试）、哪些表示暂时失败（可以重试）、哪些需要人工介入。 5. 回调：回调地址的配置方式、验签方法、需要返回的应答格式、对方的重试策略（我方需要幂等处理）。 6. 文档中含糊或互相矛盾的地方，列成问题，便于向对方技术支持确认。 第二步：代码 1. 封装独立的客户端模块，业务代码不直接拼接请求；凭证从配置读取。 2. 签名与验签单独实现，并用文档示例写单元测试验证。 3. 超时、按错误码区分的重试、限流控制。 4. 每次调用记录请求标识、耗时、结果码（日志中对敏感字段脱敏）。 5. 回调处理：先验签，再按业务单号幂等处理，最后按对方要求的格式应答。 6. 用模拟服务编写测试，覆盖成功、业务失败、超时、签名错误、重复回调。 第三步：上线检查清单（凭证切换、白名单、回调地址、监控告警、对账方式）。 文档中没有说明的细节不要编造，标注「需向对方确认」。
高亮处换成你自己的内容：[服务名称]、[接口列表]、[粘贴接口文档]、[技术栈]、[调用场景]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[粘贴接口文档] 至少包括鉴权签名、错误码和回调三个章节，这是对接中最容易出错的地方。文档是网页或 PDF 时，复制相关章节的文字即可。
常见坑：
- 签名算错是对接中最常见的问题，原因往往是参数排序、空值是否参与签名、编码方式等细节。用文档给的示例数据写一个单元测试，签名结果对上了再联调。
- 回调没有验签，任何人都可以伪造一个「支付成功」或「已签收」的通知。
- 对方会重复发送回调，我方没有做幂等处理，导致同一个订单被处理两次。
追问技巧：联调遇到报错时，把请求、响应和对方返回的错误码贴回去，问「对照文档，问题最可能出在哪个字段」；上线前追问「写一个每日对账脚本，比对我方记录与对方账单」。
示例输出
示例，仅供参考（文档提炼节选）
| 项目 | 提炼结果 |
|---|---|
| 签名 | 除签名字段外的所有非空参数按参数名升序排列，用 键=值 加 & 拼接，末尾拼接密钥，计算哈希后转大写 |
| 时间戳 | 秒级，与服务器时间相差超过 5 分钟拒绝 |
| 可重试错误码 | 系统繁忙类错误码 |
| 不可重试错误码 | 参数错误、签名错误、余额不足 |
| 回调应答 | 返回文档规定的成功字符串，否则对方会按其重试策略重新推送 |
需向对方确认：
- 文档中「空值不参与签名」是指空字符串还是未传的参数？
- 回调重试的间隔与最大次数？
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～