如何除錯 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 錯誤是典型的徵兆。伺服器紀錄，即後端運行時的文字輸出，通常包含真正的錯誤，以及堆疊追蹤（即失敗時正在執行的函數清單）。

在哪裡找到它們，取決於你使用的工具。在大多數 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：讓 agent 像用戶一樣在即時預覽中點擊操作，並回報損壞的流程。
• /fix：讓 agent 專門針對損壞的部分進行處理。
• Plan 模式：讓 agent 先調查並解釋，然後才進行任何編輯。
• Code → terminal：顯示你應用程式的伺服器紀錄。
• Revert to this point：在任何回覆上使用，可把專案還原至該檢查點。

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

常見問題