你不需要看懂整段英文。每次看到錯誤，只做這三件事：
像 403、429、503 這種三位數，是電腦在告訴你「卡在哪一類問題」。像電話區碼，一聽就知道是哪一區（下一節有速查表）。
很多時候，提供服務的一方（例如 Google）會直接把解法的連結附在訊息裡。看到 https 開頭的網址，先點進去看看。
這是你最強的武器。把錯誤訊息整段複製，貼給 AI，問「這是什麼意思？我是初學者，請告訴我可能原因和該怎麼做」。
「這個錯誤訊息是什麼意思？我是完全不懂程式的初學者，請告訴我可能的原因和我該怎麼做。」AI 會用白話幫你翻譯，還會給你具體的下一步。你不需要自己讀懂，你只需要會「轉交」。
上一章串接時跳出 403，訊息裡 Google 直接附了一句「請到這個網址啟用功能」。點進去、按一個藍色按鈕，問題就解決了，完全不用懂程式。這就是「找數字、找網址」的實戰。
電腦的錯誤代碼有很多，但初學者其實只要認得「開頭數字」就能判斷個八九成。
| 看到的數字 | 白話意思 | 通常你要做的事 |
|---|---|---|
| 4 開頭 （403、404…） |
「問題在你這邊」：沒權限、找不到東西、功能還沒開 | 檢查權限對不對、功能有沒有開啟、網址有沒有打錯 |
| 429 | 「你太快了」：短時間內問太多次，被請你慢一點 | 等一下再試（很多程式會自己自動重試） |
| 5 開頭 （500、502、503） |
「問題在對方的伺服器」，不一定是你的錯 | 先等一下再試；如果一直發生，才需要進一步查 |
下面是三個真實會遇到的錯誤訊息。用「找數字 → 判斷哪一區 → 想下一步」試試看。
前面說過，紅字錯誤其實是好心的導航。但有一種狀況更不容易被發現：
本課專案就遇到過：上傳檔案後，AI 批改成功顯示在畫面上了，看起來完美。但去看 Google 試算表，什麼都沒寫進去。畫面沒有任何紅字、沒有任何警告，事情卻默默失敗了。這在工程上叫「靜默失敗silent failure（靜默失敗）指程式某個步驟失敗了，卻沒有對外報錯。常見原因是當初為了「不要害整個流程中斷」，刻意讓某一步就算失敗也不出聲，副作用就是失敗被藏起來。（silent failure）」。
因為當初設計時，故意讓「寫試算表」這一步「就算失敗，也不要害整個批改中斷」，畢竟批改結果已經出來了，不該因為記錄沒寫成功就讓使用者看不到結果。立意良好，但副作用就是：失敗被藏起來了。 它難查，是因為它不主動告訴你哪裡錯。
既然問題藏起來了，就用三招把它逼出來。前面那個「畫面顯示成功、試算表卻沒寫入」的例子，最後就是靠這三招組合解開的。
工程上有個概念叫 log（日誌）log 是程式運作時留下的「工作筆記」，把過程中發生的事記錄下來，像飛機的黑盒子，出事時可以回頭看到底哪一步出狀況。，是程式運作時留下的「工作筆記」，像飛機的黑盒子。請 AI 幫你修改程式，讓那個「默默失敗」的步驟把失敗的真正原因寫進 log、或顯示在畫面上。等於跟藏起來的問題說：「別躲了，出來講清楚你是誰。」
一次上傳要經過好多步驟（收檔 → 轉文字 → AI 批改 → 寫試算表）。請 AI 幫你寫一支「小腳本」，只測「寫試算表」這一個環節。就像生產線某個環節壞了，你會把那一台機器單獨拉出來通電試，問題立刻現形。果然，這支小腳本一跑，就吐出真正的原因：正是前面速查表那種「4 開頭的 403」，某個功能或 API 還沒被啟用。
AI 是你最強的除錯夥伴，但你問得好不好決定它幫不幫得上忙。好的提問請包含三件事：我做了什麼、我預期什麼、實際發生什麼（附上錯誤訊息或截圖）。把這三點一次講清楚，AI 就能快速鎖定問題。
「我做了什麼、我以為會怎樣、結果卻怎樣。」三句話，是你向 AI（或任何工程師）求助時最有效的開場。例如：「我上傳了一個 PDF，我以為結果會寫進試算表，但畫面有顯示批改結果、試算表卻是空的，這是錯誤訊息……」
答對加 20 分，答錯倒扣 10 分。