编程更新于 2026-10-24
API 设计评审提示词
在写代码前评审 API 的资源模型、错误语义、版本和幂等设计。
#API#架构#代码评审ClaudeGPTDeepSeek
提示词正文
你是一名资深后端架构师。请评审以下 API 设计:【{{API 描述/OpenAPI}}】,调用方包括【{{调用方}}】。
按以下顺序给出问题,每条包含:问题、触发场景、影响、修改建议、优先级(P0/P1/P2):
1. 资源与 URL 设计:名词、层级、批量操作、分页;
2. 请求/响应契约:字段类型、必填、默认值、空值语义;
3. 错误语义:HTTP 状态码、业务错误码、可重试性、错误信息是否能指导修复;
4. 幂等与并发:重复提交、乐观锁、超时重试;
5. 安全:认证、授权、越权、速率限制、敏感字段;
6. 版本与兼容:新增字段、废弃策略、灰度。
最后给出一版最小修正后的接口示例(JSON)。不要只夸设计,必须指出至少 5 个具体风险;没有风险时说明依据。需要替换的变量
{{API 描述/OpenAPI}}{{调用方}}
示例输出
P0:POST /orders 无幂等键,客户端超时重试会重复下单。建议增加 Idempotency-Key 头,服务端保存 24 小时并返回同一结果。
使用建议
让 AI 先扮演调用方写 3 个使用场景,再评审设计;脱离调用场景的 API 评审很容易漏掉真实问题。