如何除錯 AI 建立的應用程式：一套實用方法

要除錯 AI 建立的應用程式，首先要刻意讓錯誤再次發生，然後收集證據：確切的步驟、錯誤訊息，以及瀏覽器主控台和網路分頁顯示的內容，再把這些整理成「我做了 X，預期 Y，結果是 Z」交給 AI。如果某次修正讓情況變得更糟，就還原到最後一個正常運作的版本，而不是在錯誤上面不斷疊加修正。要把這些事情做好，你並不需要讀懂程式碼。

本指南涵蓋整個流程，也包含一段給非開發者的瀏覽器開發人員工具快速導覽。

除錯的循環

不論是人還是 AI 來修正錯誤，每一次修復都遵循相同的循環：

1. 重現：讓錯誤能穩定地發生。
2. 觀察：收集錯誤訊息，以及應用程式當時在做什麼。
3. 描述：給 AI 精確的步驟、預期結果與實際結果。
4. 修正：讓 AI 一次只改一件事。
5. 驗證：重複完全相同的步驟，確認問題已修好，而且附近的功能沒有壞掉。
6. 必要時還原：如果情況變得更糟，就撤銷並帶著更好的資訊重新嘗試。

AI 建立的應用程式中，大部分浪費的時間都來自跳過第 1、2、5 步：只說「壞了」、不經測試就接受變更，然後在一個已經壞掉的修正之上再要求另一次修正。

第一步：重現錯誤

能隨時觸發的錯誤，已經解決了一半。試著找出能導致錯誤的最短步驟組合。

問問自己：

• **每次都會發生嗎？**如果只是偶爾發生，那發生時有什麼不同？例如某筆特定的資料、連線較慢，或是被登出了？
• **每位使用者都會遇到嗎？**換一個帳號登入試試。很多錯誤只會在沒有資料的新用戶身上出現，或只在角色不同的用戶身上出現。
• **每種裝置都會發生嗎？**試試手機寬度的螢幕，以及另一種瀏覽器。
• **是在某次特定變更之後才開始的嗎？**如果昨天還能正常運作，那最近幾次的變更就是最主要的嫌疑犯。

把步驟寫成一份簡短的編號清單，之後你會把它貼進提示詞中。

第二步：閱讀錯誤訊息

錯誤訊息看起來可能很嚇人，但你其實只需要其中幾個部分。

你不需要完全理解它，只需要原封不動地複製下來。「Cannot read properties of undefined (reading 'name')」告訴 AI，程式預期會有某些資料（可能是預約或使用者），但那些資料並不存在。如果你改寫成「某個 undefined 錯誤」，這些資訊就丟失了。

以下是幾個常見的錯誤，大致翻譯如下：

• undefined / null 錯誤：程式預期的資料沒有到達。通常是程式沒有處理載入中的狀態，或是空白的清單。
• 404 Not Found：頁面或 API 位址不存在。通常是路由打錯字，或連結指向已被改名的頁面。
• 401 Unauthorized / 403 Forbidden：請求時沒有登入，或該使用者沒有權限執行這個動作。
• 500 Internal Server Error：伺服器端的程式當掉了。真正的原因在伺服器紀錄中，而不在瀏覽器裡。
• CORS 錯誤：瀏覽器阻擋了對另一個網域的請求。通常是伺服器端的設定問題。

第三步：使用瀏覽器開發人員工具

每一款桌面瀏覽器都內建開發人員工具（「devtools」）。它會顯示頁面在背後做了什麼。在 Chrome、Edge 和 Firefox 中，在頁面任何位置按右鍵並選擇檢查（Inspect），或按 F12（Mac 上為 Cmd+Option+I）。在 Safari 中，請先到 Safari 設定中開啟「開發」選單。

你只需要用到三個分頁。

主控台（Console）

主控台分頁會列出頁面程式產生的錯誤和訊息。錯誤會以紅色顯示。如果按下某個按鈕後沒有任何反應，主控台通常會在你點擊的那一刻出現紅色錯誤。複製完整的錯誤文字（大多數瀏覽器在上面按右鍵就有複製選項）。

網路（Network）

網路分頁會列出頁面發出的每一個請求，例如載入資料、儲存表單、登入。打開它，然後重複導致錯誤的步驟。

• 留意紅色的列，或狀態碼為 400 以上的列。
• 點擊失敗的列查看它的回應（Response）。伺服器錯誤通常會在那裡附上比畫面上任何提示都更有用的訊息。
• 記下請求的網址與狀態碼。「對 /api/bookings 的 POST 回傳了 500」是一句非常有用、可以交給 AI 的描述。

如果錯誤與頁面重新載入或重新導向有關，請勾選保留紀錄（Preserve log），這樣請求就不會在頁面切換時消失。

元素（Elements）

元素（或檢視器）分頁會顯示頁面的結構與樣式。它對版面問題最有用：把滑鼠移到某個元素上，就能看到它的大小與間距被高亮顯示。你不需要在這裡修改任何東西，只要能說出「在手機上頁尾寬度是 2,000 像素，把整個頁面擠向一側」就已經足夠。

第四步：檢查伺服器紀錄

有些錯誤發生在伺服器端，瀏覽器看不到。網路分頁中的 500 錯誤是典型的徵兆。伺服器紀錄（後端執行時的文字輸出）通常會包含真正的錯誤，以及堆疊追蹤（stack trace，即失敗當下正在執行的函式清單）。

你能在哪裡找到它們，取決於你使用的工具。在大多數 AI 應用程式建構工具中，你可以打開該專案的終端機或紀錄檢視，或直接問 AI：「檢查最近一次請求的伺服器紀錄是否有錯誤，並告訴我是哪裡失敗了。」

第五步：向 AI 描述錯誤

把你收集到的資訊整理成以下格式：

在「預約」頁面，以會員身分登入：我在明天 9:00 的課程上點了取消。預期結果：預約消失，課程多出一個空位。實際結果：畫面上沒有任何變化。主控台顯示 BookingCard.tsx:31 出現 TypeError: Cannot read properties of undefined (reading 'id')，網路分頁顯示 DELETE /api/bookings/123 回傳 500。請找出原因、修正它，並確認只有一筆預約的會員和有多筆預約的會員都能正常取消。

每個部分的作用：

• 在哪裡、以什麼身分：把範圍縮小到一個畫面與一種角色。
• 確切步驟：讓 AI 能夠重現錯誤。
• 預期與實際：定義什麼叫做「已修好」。
• 錯誤文字與失敗的請求：直接指出原因所在。
• 「請確認……」：要求 AI 驗證，而不只是修改。

如果 AI 已經嘗試修正兩次都失敗，請它在改任何東西之前先解釋：

先不要改程式碼。你認為是什麼原因造成這個問題？有什麼證據支持你的判斷？

錯誤的推論在寫出來之後很容易被發現，而且修正它的成本遠低於修正一個錯誤的程式碼。

第六步：驗證，然後檢查附近的功能

當 AI 說已經修好時，請重複第一步中的確切步驟。接著檢查周圍的功能：

• 不同使用者角色執行同一個動作
• 沒有資料時與資料很多時，執行同一個動作
• 與你修正的頁面共用元件的其他頁面
• 如果修正碰到了版面，請用手機寬度的螢幕檢查

AI 的變更有時會修好一條路徑，卻悄悄弄壞另一條。現在花兩分鐘檢查，可以省下之後一個小時的困惑。

第七步：還原，而不是繼續堆疊

如果某次修正讓情況變得更糟，或者你已經來回三輪仍然毫無進展，就回頭。還原到最後一個正常運作的版本，然後用更好的證據重新描述問題，幾乎總是比在三次錯誤修正之上再要求第四次修正更有效。每一次失敗的嘗試都會留下程式碼，而這些程式碼會干擾下一次的嘗試。

有助於輕鬆還原的好習慣：

• 每次變更後都測試，這樣你才知道是哪一個變更弄壞了東西。
• 保持變更小：每則訊息只包含一個功能或修正。
• 在開始有風險的工作前，先記下最後一個正常版本。
• 如果程式碼在 Git 中，就提交正常運作的版本，以便隨時回去。

AI 建立的應用程式中常見的錯誤模式

當問題其實不是錯誤時

有些「錯誤」其實是 AI 完全照著指示在做，而描述本身不夠明確。如果你要求的修正其實是行為上的改變，請直接說明：「改成……」。如果你發現自己也不確定正確的行為應該是什麼，請先決定這件事。我們關於為 AI 應用程式建構工具撰寫提示詞的指南，說明了如何清楚地指定規則。如果你正在為真正的使用者準備應用程式，把 AI 原型推向正式上線則涵蓋了上線前值得做的檢查。

在 Mythex 中除錯

Mythex 為除錯循環的每一個步驟都提供了工具：

• 預覽：用來重現錯誤，包括手機尺寸的畫面。
• /test：讓代理程式像使用者一樣，在你的即時預覽中點擊操作，並回報壞掉的流程。
• /fix：讓代理程式專門針對壞掉的地方進行修正。
• 計畫（Plan）模式：讓代理程式在編輯任何東西之前，先調查並解釋。
• 程式碼 → 終端機：顯示你應用程式的伺服器紀錄。
• 回到這個時間點（Revert to this point）：在任何一則回覆上使用，就能把專案還原到該檢查點。

如果發布失敗，發布對話框通常會提供使用 AI 修復（Fix with AI）的選項，它會讀取建置輸出或應用程式的紀錄。請參考文件中的除錯你的應用程式與發布疑難排解。

常見問題