跳到正文
跟我做

ROUTE

开发者 AI 实战:把 API 调用做得能上线

从超时、重试、结构化输出和成本日志开始,把 Demo 级的 AI 调用变成能跑批量的客户端。

3 篇已发布15 分钟读完

适合谁

  • 已经能调通模型接口,但一跑批量任务就遇到 429、超时和脏数据。
  • 想把 AI 调用接进自己的工具或内部系统。
  • 需要向团队解释“为什么这个任务失败了、花了多少钱”。

做完得到什么

  • 一个不依赖特定服务商的重试客户端。
  • 一套可复用的错误分类和退避策略。
  • 结构化输出校验和 token 成本日志。

两篇怎么配合

客户端负责发请求、在 429 时重试;json-guard 负责校验返回的 JSON。网络层和内容层分开,排错时才知道是请求没发出去,还是模型答歪了。

后续可以加什么

  • 请求去重和幂等键。
  • 失败任务落盘与断点续跑。
  • 按批次汇总的成本报表。
  • 多模型路由与降级。

先把单次调用做稳,再考虑并发和路由。顺序反过来,排错会非常痛苦。

按顺序做

每一步都建立在上一步的产物上,建议不要跳步。

  1. 1约 4 分钟

    别让一次 429 毁掉整批任务:写一个能重试的 AI API 客户端

    用原生 fetch 实现超时、指数退避、Retry-After 处理、JSON 校验和成本日志,让批量 AI 任务在限流和抖动下仍能跑完。

  2. 2约 5 分钟

    AI 返回的 JSON 不稳:加一层校验和重试

    模型返回 200 不代表字段可用。用一个不依赖第三方库的 Node 脚本校验字段类型、数值范围和枚举,失败自动重试,仍失败就落盘人工看。

  3. 3约 6 分钟

    CSV 变 SQL:本地模型写查询,SQLite 验算

    把 CSV 读进内存 SQLite,让本地模型只写一条 SELECT,再由数据库执行并打印结果。模型负责翻译问题,SQLite 负责给答案,数字不靠模型编。