让 AI 去做调用——而你来检查形状

这里是实际的分工。AI 真的很擅长写调用 API 的代码：它懂那些库、懂 header 的语法、懂错误处理。让它来。这些管道不用你亲手写。

但有一件事是你的，而 AI 很不擅长：**判断数据的形状到底对不对。**一个好的工作流：

• **把真实的文档给 AI。**把文档里的示例请求和响应粘进你的提示里。AI 凭记忆猜一个 API 的形状，是头号 bug 来源——它会编出一些看起来很合理、但根本不存在的键。真实的例子能把它锚定在现实上。
• 让它先把原始响应给你看。"在解析之前，把 API 实际返回的 JSON 打印出来。"然后把它和代码所期待的对照一眼。它读取的那个键（response.current.temp）在响应里真的存在吗？一半的 API bug 都是键名对不上。
• **检查一下类型是否靠谱。**那是个 number 还是 string？一个本应总是存在的字段，会不会有时候是 null？你现在能读懂 JSON 了——用上它。
• **处理不顺利的那条路。**问一句："如果这次调用失败了、超时了、或者撞上速率限制，会发生什么？"如果答案是"应用崩溃"，那是个 bug，不是特性。

你不需要写那个请求。你需要的是读懂响应、并问一句"这是我期待的形状吗？"。这一个习惯——拿数据去对照契约——就能在你的用户看到之前，抓住大部分集成 bug。