讓 AI 去做呼叫——而你來檢查形狀

這裡是實際的分工。AI 真的很擅長寫呼叫 API 的程式碼：它懂那些庫、懂 header 的語法、懂錯誤處理。讓它來。這些管道不用你親手寫。

但有一件事是你的，而 AI 很不擅長：**判斷資料的形狀到底對不對。**一個好的工作流：

• **把真實的文件給 AI。**把文件裡的示例請求和響應粘進你的提示裡。AI 憑記憶猜一個 API 的形狀，是頭號 bug 來源——它會編出一些看起來很合理、但根本不存在的鍵。真實的例子能把它錨定在現實上。
• 讓它先把原始響應給你看。"在解析之前，把 API 實際返回的 JSON 打印出來。"然後把它和程式碼所期待的對照一眼。它讀取的那個鍵（response.current.temp）在響應裡真的存在嗎？一半的 API bug 都是鍵名對不上。
• **檢查一下型別是否靠譜。**那是個 number 還是 string？一個本應總是存在的欄位，會不會有時候是 null？你現在能讀懂 JSON 了——用上它。
• **處理不順利的那條路。**問一句："如果這次呼叫失敗了、超時了、或者撞上速率限制，會發生什麼？"如果答案是"應用崩潰"，那是個 bug，不是特性。

你不需要寫那個請求。你需要的是讀懂響應、並問一句"這是我期待的形狀嗎？"。這一個習慣——拿資料去對照契約——就能在你的使用者看到之前，抓住大部分整合 bug。