ROUTE
开发者 AI 实战:把 API 调用做得能上线
从超时、重试、结构化输出和成本日志开始,把 Demo 级的 AI 调用变成能跑批量的客户端。
3 篇已发布15 分钟读完
适合谁
- 已经能调通模型接口,但一跑批量任务就遇到 429、超时和脏数据。
- 想把 AI 调用接进自己的工具或内部系统。
- 需要向团队解释“为什么这个任务失败了、花了多少钱”。
做完得到什么
- 一个不依赖特定服务商的重试客户端。
- 一套可复用的错误分类和退避策略。
- 结构化输出校验和 token 成本日志。
两篇怎么配合
客户端负责发请求、在 429 时重试;json-guard 负责校验返回的 JSON。网络层和内容层分开,排错时才知道是请求没发出去,还是模型答歪了。
后续可以加什么
- 请求去重和幂等键。
- 失败任务落盘与断点续跑。
- 按批次汇总的成本报表。
- 多模型路由与降级。
先把单次调用做稳,再考虑并发和路由。顺序反过来,排错会非常痛苦。
按顺序做
每一步都建立在上一步的产物上,建议不要跳步。
1约 4 分钟别让一次 429 毁掉整批任务:写一个能重试的 AI API 客户端
用原生 fetch 实现超时、指数退避、Retry-After 处理、JSON 校验和成本日志,让批量 AI 任务在限流和抖动下仍能跑完。
- 2约 5 分钟
AI 返回的 JSON 不稳:加一层校验和重试
模型返回 200 不代表字段可用。用一个不依赖第三方库的 Node 脚本校验字段类型、数值范围和枚举,失败自动重试,仍失败就落盘人工看。
- 3约 6 分钟
CSV 变 SQL:本地模型写查询,SQLite 验算
把 CSV 读进内存 SQLite,让本地模型只写一条 SELECT,再由数据库执行并打印结果。模型负责翻译问题,SQLite 负责给答案,数字不靠模型编。