錯誤訊息解碼器

🍽 這道菜在做什麼

每個寫程式的人都遇過那一幕：終端機突然吐出一長串紅字，幾十行堆疊追蹤（stack trace）夾雜著看不懂的檔案路徑與函式名，最上面寫著 Cannot read properties of undefined 或 NullPointerException，你盯著它一頭霧水，不知道該從哪一行開始查。更慘的是這常常發生在最不該出事的時候——deadline 前一晚、剛部署完上線、半夜被監控警報叫醒。慌張之下開始亂試，改一行跑一次，越改越亂。

這道配方要解決的，正是「看到錯誤卻無從下手」的窘境。你把完整的錯誤訊息或堆疊追蹤貼給 AI，附上執行環境和你剛剛做了什麼，它會以冷靜的資深工程師角度，依五個步驟幫你拆解：先把錯誤白話翻譯成人話、告訴你它到底在抱怨什麼；接著列出最可能的根因並排序，最可能的放最前面，還會說明判斷理由；然後給你一份逐步排查清單，每一步要做什麼、預期看到什麼都寫清楚；再附上對應的修復方式與程式碼／指令；最後告訴你怎麼避免再次發生。如果錯誤可能跟特定套件版本有關，連網版本還會幫你查證是不是某套件的已知 bug。

最需要這道菜的有三種人。獨立開發者，卡關時身邊沒有資深同事可以問，這道配方等於一位隨叫隨到的除錯夥伴。維運與 on-call 工程師，深夜遇到線上事故時最需要冷靜的根因排序，而不是自己在恐慌中亂猜。正在學程式的自學者，看到錯誤訊息常常直接放棄，這道配方能把嚇人的紅字翻成聽得懂的話，順便教你怎麼查。原本可能要花一兩小時 Google、翻 Stack Overflow 才能定位的問題，三分鐘就能拿到一份有排序、有步驟、有修法的清單。

為什麼這樣設計

除錯這件事最大的敵人是慌亂和盲目，而這道配方的每個設計都在對治這兩點。

第一個關鍵是角色設定為「冷靜的資深工程師，擅長從錯誤訊息逆推根因」。「冷靜」這兩個字看似小事，其實很重要——它讓 AI 用一種有條理、不急著下結論的方式回應，正好中和你當下的焦慮。「從錯誤訊息逆推根因」則指定了它的核心能力：不是叫你重貼程式碼從頭看，而是學會資深工程師那套「看堆疊頂端找線索、順著呼叫鏈往回推」的逆推功夫。

第二個關鍵是根因「排序」而非只給一個答案。同一個錯誤訊息可能有好幾個成因，例如 Cannot read properties of undefined 可能是 API 還沒回傳、初始化順序錯了、或單純打錯欄位名。如果 AI 只丟一個答案而剛好猜錯，你會在錯誤方向上浪費大把時間。要求它把所有可能根因依機率排序、並說明判斷理由，你就能從最可能的開始查，命中率最高、效率也最好。這正是有經驗的工程師和新手的差別——前者懂得排優先順序。

第三個關鍵是逐步排查清單明確寫出「預期看到什麼」。除錯的精髓是「驗證假設」：你猜是 A 原因，就得做個動作確認到底是不是 A。提示詞要求每一步都註明「做什麼、預期看到什麼」，等於把假設驗證的方法直接教給你——如果你看到的跟預期一致，就確認了根因；不一致，就排除這個可能、往下一個查。最後「如何避免再次發生」這步，則把一次性的救火，升級成讓你下次不再踩同一個坑的學習。這也是為什麼這道菜建議用連網版本——很多錯誤其實是某套件特定版本的已知 bug，能上網查證才不會自己埋頭瞎猜。

怎麼用

第一步，把完整的錯誤訊息或堆疊追蹤複製下來。注意是「完整」——很多人只貼最後一行 Error: xxx，但真正的線索往往藏在堆疊中間那幾行「你自己的程式碼」裡，少貼了 AI 就難以定位。

第二步，因為這道菜常需要查最新套件版本或已知問題，建議用具備上網功能的工具（ChatGPT 連網、Claude、Gemini）。把上方提示詞整段貼進去，填好兩個關鍵欄位：「執行環境」盡量寫詳細，例如 Node.js 20 / Next.js 14 / macOS 14 / Docker，因為同樣的錯在不同版本下成因可能完全不同；「我做了什麼」寫下觸發錯誤的操作，例如「跑 npm run build 時」「按下送出表單後」。接著把錯誤堆疊貼到對應區塊。

第三步，按 Enter。AI 會依序給你白話翻譯、根因排序、排查清單、修復方式、預防建議。從排在最前面的根因開始，照排查清單一步步做，比對「預期看到什麼」來確認或排除。命中後套用對應的修復程式碼或指令，修好後別忘了看一眼「如何避免再次發生」。如果第一個根因排查後發現不是，就往清單下一個繼續。這個流程對應 frontmatter 的「貼錯誤 → 看根因排序 → 照步驟排查修復」三步。

調整技巧

回應的深淺和方向都能用講的調整。如果你是新手、看不懂它用的技術名詞，用「新手友善版」請它把每個術語都解釋一遍，連 stack trace、async 這些都白話講清楚。如果這是線上正在燒的事故、用戶正在受影響，用「線上事故版」請它「先給最快的止血方案（例如回滾、重啟、暫時關閉某功能），再談根治」，先讓服務恢復再慢慢追根因。

排查過程也可以即時互動。照著做了第一步、看到的結果跟預期不一樣，就把實際看到的輸出貼回去說「我做了第二步，但看到的是這個」，AI 會根據新線索修正根因判斷、給你下一步。這種一來一回的對話式除錯，往往比一次性的長篇回覆更快逼出真正的問題。

注意事項

最關鍵的一條：AI 給的修復方式，跑之前一定要看懂、想清楚。它有時會「自信地給出錯誤指令」，特別是那種會動到系統的破壞性操作——例如 rm -rf、git reset --hard、DROP TABLE、force push。這類指令一旦跑下去可能刪掉檔案、清掉資料、覆寫歷史，無法復原。執行任何破壞性指令前，務必確認你真的理解它在做什麼，重要資料先備份。AI 不會替你的資料負責，按下 Enter 的後果是你的。

其次，根因判斷的準確度高度取決於你給的資訊。環境、版本、作業系統講得越清楚，判斷越準；資訊不足時 AI 只能用猜的，給出的根因可能整個錯方向。涉及正式環境的修復更要謹慎——在 production 上直接套 AI 給的指令風險很高，能先在測試環境驗證就先驗證。如果問題牽涉資料庫遷移、金流、用戶個資，這些後果嚴重的領域務必人工把關，必要時請更資深的人複核，別讓 AI 的「最可能根因」變成你唯一的依據。AI 是幫你縮小範圍、加速定位的助手，最終的判斷與執行責任仍在你身上，修完務必複查確認問題真的解決、且沒引發新問題。

台灣情境案例

桃園一位做電商後台的全端工程師，某個週五傍晚部署完新版，網站突然開始間歇性回傳 500 錯誤，但不是每次都錯，重整幾次又會好。他登進伺服器看 log，是一長串 Node.js 的堆疊，最上面寫著 ECONNREFUSED 127.0.0.1:6379，下面幾十行全是套件內部的呼叫鏈，他盯了十分鐘毫無頭緒，眼看就要加班過週末。

他把完整堆疊貼進連網的 AI，環境填「Node.js 20 / Docker Compose / Redis」，操作寫「部署新版後間歇性 500」。AI 先白話翻譯：「程式想連 Redis 但被拒絕，6379 是 Redis 的預設埠」。接著排出根因，第一名是「Redis 容器啟動比 app 慢，app 搶先連線時 Redis 還沒就緒」，並指出「間歇性」這個特徵正是啟動時序問題的典型徵兆。排查清單要他「跑 docker compose logs redis 看 Redis 是不是比 app 晚就緒」，他一看果然如此。

AI 給的修復是在 Docker Compose 加上健康檢查與 depends_on 的就緒條件，並建議在連線端加重試機制。他照做後問題消失，預防建議那段也讓他學到「容器化環境不能假設依賴服務一定先起來」。原本可能燒掉整個週末的事故，半小時就收工回家了。

延伸用法

除錯是開發循環裡最常觸發的環節，它跟其他工具串起來特別順。如果是在 Code Review 階段就想提前攔截潛在錯誤，可以先用PR Code Review 助手把變更掃一遍。修好錯誤、改完程式碼準備提交時，接上Git Commit 訊息產生器把這次修正寫成清楚的提交訊息，順便在內文記下根因，下次再遇到就有跡可循。

想找更多工程師日常的救命配方，可以逛食譜總覽；如果你想把「監控告警 → AI 解碼 → 排查 → 修復 → 復盤」整套事故處理流程標準化，工作流專區有可參考的範本。需要快速生出事故報告、post-mortem 或預防清單時，產生器也能幫你省下整理的時間。把這道配方放進你的除錯習慣，下次半夜看到紅字，就不會再慌了。

材料

• 具備上網能力的 AI 工具（ChatGPT 連網／Claude／Gemini）
• 完整的錯誤訊息或堆疊追蹤

步驟

1. 貼錯誤：貼完整堆疊，附上環境與你做的操作。
2. 看根因排序：從最可能的原因開始查。
3. 照步驟排查修復：一步步排查，套用修復方式。

配方本體（可複製帶走）

# 角色
你是冷靜的資深工程師，擅長從錯誤訊息逆推根因。

# 任務
請幫我搞懂這個錯誤並修好它。

執行環境：{例如 Node.js 20 / Docker / macOS，盡量填}
我做了什麼：{觸發錯誤的操作}
完整錯誤訊息 / 堆疊：
{貼上}

請依下列順序輸出：
1. 白話翻譯：這個錯誤到底在說什麼
2. 最可能的根因（排序，最可能在前），並說明判斷理由
3. 逐步排查清單（每一步要做什麼、預期看到什麼）
4. 對應的修復方式與程式碼／指令
5. 如何避免再次發生
若錯誤可能跟特定套件版本有關，請查證並提醒。
繁體中文說明，指令與程式碼保留原樣。

試吃報告

變化版

• 新手友善版：請它把每個技術名詞都解釋一遍。
• 線上事故版：請它先給最快的止血方案，再談根治。

你可能也想看