这个提示词用来做什么
文档只有成功示例，接入方在 401、429、超时和重复提交上反复来问
提示词全文
请审阅下面这份 API 文档，只找「会让调用方卡住或做错」的失败路径，不要改文案风格。
## 输入
接口说明：{端点、方法、鉴权方式、请求/响应字段}
限制：{速率限制、超时、分页、并发、配额}
错误码：{现有错误码与含义}
业务约束：{幂等要求、金额/库存/状态变更、回调}
## 输出
1）失败路径矩阵：列出至少 10 种失败情形（鉴权过期、权限不足、参数缺失、资源不存在、冲突、限流、超时、上游失败、重复提交、部分成功），每种写：触发条件、返回什么、调用方应该做什么、是否可重试、重试要不要退避。
2）最小示例：为「成功、参数错误、鉴权失败、限流、超时」各写一个最短请求与响应示例，标出哪些字段是稳定契约、哪些可能变。
3）幂等与重复提交：说明同一个请求重发时会发生什么；如果没有幂等键，明确写清楚调用方要自己承担什么。
4）踩坑清单：列出 5 个最容易让接入方误判的点，例如「HTTP 200 但业务失败」「分页漏数据」「回调先于同步响应到达」。
5）验收问题：给文档作者 5 个问题，用来确认这些失败路径真的被实现和测试过。
## 纪律
- 不要写「请妥善处理错误」；要写清楚重试几次、间隔多久、什么情况下不要重试。
- 区分「客户端错误」和「服务端错误」，不要把 4xx 和 5xx 混成一个处理分支。
- 没有实现的错误码不要编造；标成「待确认」。
怎么用
- 把上面的提示词全文复制到对话窗口或工作流里。
- 把花括号占位符（如 {任务描述}）替换成你自己的内容。
- 条目越具体，产出越稳定；不需要的条目可以直接删掉。
输出示例
第 1 条的「是否可重试」比错误码本身更重要：同样是 409，有的表示重复提交可以忽略，有的表示状态冲突必须人工处理。第 4 条要求写「HTTP 200 但业务失败」，是因为很多接入方只判断状态码，最后把失败当成功落库。
基本信息
- 分类：文档
- 标签：API 文档 · 错误处理 · 重试 · 幂等 · 开发者体验
- 收录日期：2026-10-20