- 運用系統化框架，將用戶反饋轉化為可執行的測試與錯誤修復計劃
- 運用人工智慧輔助除錯，並採用「教我」模式理解修復方案
- 編寫簡單的測試以驗證修正方案是否有效，並捕捉潛在的回歸問題
- 使用瀏覽器開發人員工具來識別和診斷問題
- 已除錯的最小可行產品：您的 最小可行產品應用程式，其中P0/P1級別的錯誤已修復
- 回饋分級系統：運用三問框架與MoSCoW方法制定的優先行動計畫
- 問題追蹤器：系統化記錄錯誤、根本原因及修復方案的文件
- 測試檢查表： 用於回歸預防與問題追蹤的文件
- 學生們已完成一個可運作的最小可行產品（包含畫面、導航功能及人工智慧特性） 《打造您的AI驅動原型》課程
- 學生已完成 反覆迭代與精進您的最小可行產品 並整合來自5至10位用戶的測試反饋
此刻你已打造出由人工智慧驅動的最小可行產品（MVP），並在分享前測試過邊緣案例。如今真實用戶已試用你的應用程式，並提供了反饋。某些功能運作順暢，其他功能則可能讓用戶困惑或意外當機。這很正常，每間新創公司都會經歷這樣的階段。
正如你在《迭代與精進你的最小可行產品》中探討的，收集並整合用戶反饋對於優化最小可行產品至關重要。當前的挑戰在於將這些反饋轉化為程式碼修正方案。當用戶反映「功能無法運作」時，我們需要釐清具體可修復的問題點。發現錯誤時，不僅要掌握修正方法，更需理解修正原理——如此才能有效降低問題復發的機率。
在本單元中，我們將透過系統化的除錯方法，幫助您提升除錯速度與信心。您將運用人工智慧輔助除錯技術——這並非為了盲目編寫程式碼，而是協助您理解程式運作的本質與原因。您還將學習編寫測試程式，在使用者發現問題之前就將其攔截。
從回饋到行動方案
用戶反饋雖珍貴，卻常以雜亂無章的形式呈現。
- 「應用程式當機」可能表示按鈕無反應、頁面凍結，或出現錯誤訊息。
- 「我搞不懂」可能指標籤不清、說明書遺漏，或是流程令人困惑。
在迭代與精煉您的最小可行產品（MVP）階段，您投入時間與使用者測試產品並收集反饋。隨後，您對發現的問題進行了優先級排序與分類。
在本單元中，我們將延續前幾單元的範例應用程式TutorMatch。此學生端平台採用 React 與 JavaScript 開發，能協助學生根據學習困境識別所需的補習類型。TutorMatch 是在 Github Codespaces 上建置的。本次活動中，您將使用您自己的最小可行產品（MVP）與使用者回饋進行實作。TutorMatch 範例僅供參考。
活動 1
建立您的意見回饋分流系統
預估時間：20分鐘
我們將建立一套系統來分類用戶反饋，並將其轉化為優先級行動計劃。此舉能節省除錯時間，因為我們會優先處理最重要問題，而非僅著眼於最先發現或傾向修復的項目。
1. 開啟 Github 與 Codespaces
在 GitHub 上開啟您的儲存庫，並開啟您的 Codespace。
若您仍有未關閉的儲存庫分支，請使用該分支及代碼空間。
否則，請建立新分支。開啟先前使用的相同代碼空間，但需切換分支——在終端機視窗中輸入以下指令即可：
gitpull origin main
gitcheckout 新分支名稱
gitcheckout -b 新分支名稱
2. 收集使用者測試的反饋意見
在您的使用者測試中，您運用測試分析工作表對問題進行了優先排序與分類。
請在您的工作表中找到該資訊，因為您將需要它來進行此活動。
3. 請 Copilot 協助整理問題
在此，我們將透過問題追蹤系統記錄問題及行動方案。
- 在您的 Codespace 中建立一個名為 test ，並建立名為 issue_tracker.md 。您可在檔案總管面板中執行此操作（點擊新建檔案圖示）。
- 請要求 Github Copilot 根據您測試中發現的頂層 P0/P1 問題，提供一套結構化且分類的待辦事項清單。您可使用此範本：
我正在根據用戶測試反饋對應用程式進行除錯。請協助我為每個問題建立結構化的問題描述。
針對以下每個問題，請提供：
- **摘要：** 一句話描述
- **類別：** 錯誤、可用性、功能缺失或功能強化
- **使用者經歷：**他們所見或未見的事物
- **可能的根本原因：** 2-3個關於此現象發生原因的假設（編號）
- **首先該查看哪裡：**該調查哪個檔案或程式碼區段
- **建議修復方案：** 一個起點（並非完整解決方案）
以下是我的問題：
- 請將您最關切的P0/P1問題複製並貼至提示框底部。您可包含工作表表格中已有的內容。
- 閱讀 Copilot 生成的內容。針對每個問題，請自問：
- 這些可能的根本原因對我的應用程式來說合理嗎？
- 「首先查看的位置」是否指向我程式碼的正確部分？
- 若發現任何異常，請告知 Copilot。例如：「針對問題 1，我的應用程式採用 React 框架與 Groq API。錯誤發生於使用者提交表單時。能否重新分析根本原因？」
- 一旦您滿意，請將精煉後的描述複製到您的 issue_tracker.md 檔案中並儲存該檔案。
4. 將變更提交至 GitHub
將您的變更進行階段化並提交至儲存庫分支。
「教我」模式
當程式出錯時，我們常會忍不住將錯誤訊息貼給人工智慧，要求「修復這個」。人工智慧通常會提供可運作的程式碼（尤其使用Gemini 3模型或同類強大大型語言模型時）。但你將無法理解其原理與運作方式，這意味著下次遇到類似問題時，你仍可能再次陷入困境。
教我 「教我」模式 能改變這種狀況。與其要求AI提供解決方案，不如先請它解釋問題所在。在提示語中加入以下指令：
在提供任何程式碼之前，請先說明問題的潛在成因，並解釋每種解決方案可能奏效的原因。在我們確定最佳解決方案之前，切勿急於更新程式碼。我的目標是理解問題本質，而非僅止於解決問題。
此指令改變了AI的回應方式。雖然Copilot通常很擅長展示其思考過程並標示程式碼變更，但在更新程式碼前明確要求解釋，是避免重蹈覆轍的絕佳學習方式。
沒有「教我」模式
您：當我點擊「獲取推薦」時，我的應用程式顯示「無回應」。請修復此問題。
AI：於第61行新增3行程式碼。後端已更新為檢查回應中的Groq API錯誤，並將錯誤詳情（包含錯誤代碼）傳回前端，而非預設顯示「無回應」。
這雖然快速，但你無法獲得完整說明，無法理解實際發生的狀況與真正問題所在。
採用「教我」圖案
您：當我點擊「獲取推薦」時，應用程式顯示「無回應」。在提供任何程式碼前，請先說明問題成因、列舉可能原因、擬定修復方案，並解釋建議修復方案的可行性。我希望理解問題本質，而非僅解決症狀。
AI：關鍵問題：
fetch 不會在發生 HTTP 錯誤時拋出異常。
所以這段程式碼：
即使 Groq 返回，也將樂意執行：
401 (API 金鑰無效)
429 (速率限制)
400（錯誤的模型名稱）
在這些情況下，Groq 會返回一個 錯誤 JSON，不是 choices因此這行：
退回到 "No response."
應用程式顯示「Groq 未回應」，實際上系統已回應，但發生了錯誤。
解決方案：在執行 fetch 操作後立即添加明確的狀態檢查：
然後僅在 JSON格式正確時進行解析。
開發者工具
每個瀏覽器都內建 開發人員工具 ，讓您能窺見幕後運作。您使用了 開發者工具 簡要操作過開發者工具來檢視localStorage。現在您將使用其他分頁：
- 控制台標籤頁 – 顯示應用程式產生的 JavaScript 錯誤與日誌訊息。紅色訊息為錯誤，黃色訊息為警告。
- 網路分頁 – 顯示應用程式向外部服務（如 Groq API）發出的所有請求。呈現狀態碼與回應資料。
- 元素標籤 – 顯示頁面的 HTML 結構與 CSS 樣式。有助於診斷版面配置與視覺呈現問題。
它們共同能揭示用戶難以察覺的問題，您可藉此獲取所需證據來解決這些問題。
在接下來的活動中，你將運用持續建構的流程解決首要問題：從分類清單出發，建立假設，運用「教我」模式釐清根本原因，最後實施解決方案。
活動 2
「教我」除錯模式
預估時間：30分鐘
1. 開啟您的 Codespace 與 Issue Tracker
- 開啟活動 1 中的 Codespace。
- 定位 issue_tracker.md 檔案，該檔案列有您的 P0 與 P1 問題，請開啟它。
- 請從您最高優先級的P0問題開始處理，該問題已被歸類為錯誤。若您沒有P0問題，則從最高優先級的P1問題著手，但該問題必須是已確認的錯誤或缺陷。
2. 重現錯誤並記錄所見現象
- 在終端機視窗中輸入npm run dev（若應用程式為 React/JS）即可執行您的應用程式。
- 若該錯誤/問題涉及後端問題（例如 API 呼叫），請同時啟動您的後端伺服器。在另一個終端機視窗中，於伺服器資料夾內輸入npm run dev。
- 請嘗試完全按照測試人員或您的筆記所述引發問題的步驟操作，以重現該問題。
- 精確記錄發生了什麼：
- 頁面會變空白嗎？
- 按鈕會毫無作用嗎？
- 是否出現錯誤訊息？
- 若您在應用程式本身或任一終端視窗（應用程式端或伺服器端）中看到錯誤訊息，請複製精確的文字內容。此細節將使後續步驟的處理效率大幅提升。
3. 使用開發人員工具收集證據
- 在應用程式瀏覽器視窗中，開啟開發人員工具（按 F12 或右鍵點擊 → 檢查）。
- 遇到任何問題，請從控制台開始：
- 點擊「控制台」標籤頁。
- 輸入「清除」以清除舊訊息。
- 重現該錯誤。
- 複製任何紅色錯誤訊息。
- 若涉及人工智慧或數據，請查閱 Network：
- 點擊「網路」標籤頁。
- 重現該錯誤。
- 尋找您的 API 請求（請尋找您 API 的網域）。
- 檢查狀態碼與回應。
- 若涉及人工智慧或數據，且您在應用程式視窗的開發人員工具中未見任何內容：
- 在執行後端伺服器的瀏覽器視窗中開啟開發人員工具。
- 點擊「控制台」標籤頁。
- 輸入「清除」以清除舊訊息。
- 重現該錯誤。
- 複製任何紅色錯誤訊息。
4. 建立假說
在請求人工智慧協助之前，請先檢視活動一中 Copilot 提出的潛在根本原因，以及您在問題追蹤器中記錄的相關資訊。
- 開啟您的問題追蹤系統。
- 針對您正在重現的問題，請檢視該問題的可能根本原因。
- 你可以複製列出的可能根本原因，或寫下自己的假設，但務必寫下內容。
「我認為發生此狀況的原因在於_______________」
提示：提出假設（即使是錯誤的假設）能讓除錯過程更有效率。這不僅是說「它壞了」，而是表明「我認為是X導致故障，需要驗證此推論」。這類額外脈絡對大型語言模型極具幫助，能協助它們縮小可能原因的範圍。
5. 使用「教我」模式請求 Copilot 協助
請 Copilot 或其他大型語言模型協助您除錯。您可以使用此範本並替換為您的具體問題：
在提供任何程式碼並進行修復之前，請先解釋造成此問題的原因以及修復方案的運作原理。我希望理解問題本質，而非僅止於解決問題。
問題：[複製並貼上問題內容，包含摘要、類別、可能根源、優先檢查項目及建議修復方法]。提供盡可能詳盡的背景資訊有助於提升大型語言模型（LLM）的回應品質。
我的假設：[你認為造成這種情況的原因]
預期結果：[我認為應該發生的情況]
6. 應用修復方案前請先閱讀說明
- 在應用任何修正方案前，請先閱讀 Copilot 的說明。
這是關鍵步驟。 當 Copilot 回應時，請先閱讀說明。確保您能理解並能回答以下問題：- 根本原因是什麼？
- 為何建議的修正方案能解決根本原因？
- 這類問題是否可能出現在應用程式的其他部分？
- 若對解釋內容有不明白之處，請提出後續問題，例如：「能否說明此處的含義？」
7. 套用修正方案
一旦您理解問題並同意修復方案，即可執行修復程序。您可選擇以下任一方式：
- 根據 Copilot 的說明手動修改程式碼。這是個絕佳機會，讓您更自在地下手鑽研程式碼，將學習進程推向更高層次。
- 請 Copilot 執行修改：「現在將你描述的修正套用到我的程式碼」。
Copilot 將直接套用修正並更新程式碼中的所有相關位置。若系統要求您審閱變更，請先閱讀建議內容再接受。此即所謂：人工介入的 AI 輔助除錯 人工介入。
8. 測試修復方案
測試方法：執行您的應用程式，嘗試重現原始錯誤。
問題是否仍然存在？
若如此，請重複上述步驟並循環執行。
在某些情況下，問題可能存在多種假設性成因，並對應著不同的建議修復方案。若該問題確屬此類情況，您只需返回並再次要求 Copilot 轉向下一個可能的修復方案。您可提供更多關於此錯誤的背景資訊，協助 Copilot 優化修復計劃。
9. 更新您的問題追蹤器並提交
- 完成後，請務必記錄issue-tracker.md檔案。您可以將此文件新增至您已修復的問題下。
例如：
- 問題 1：[ 問題描述]
- 根本原因：[實際問題所在]
- 我在程式碼中修改了哪些內容[修復內容簡述]
- 測試結果：[是/否 — 此修正是否解決問題？]
- 日期：[ 今日]
- 將此修正提交至 GitHub，並附上正確的提交說明，例如：
修正：[簡述您修正的內容]
良好的提交訊息應描述修正內容，而非錯誤本身：
良好範例：
- 修正：處理結果顯示中的空API回應
- 修正：新增載入狀態以防止重複提交
反面示例：
- 已修復錯誤
- 更新程式碼
10. 為您的下期雜誌重複此步驟
回到步驟 1，選擇您下一個最高優先級的問題，並遵循相同的流程：
假設 → 「教我」 → 理解 → 修正 → 測試 → 提交
您亦可處理部分非錯誤類問題，例如可用性問題或功能缺失，只要您已將其優先級標記為P0 或P1。雖然在提示方式上需稍作調整，但您仍可請求Copilot協助處理這類其他問題。
使用開發者工具除錯 UI 與 API 問題
有些漏洞需要透過查看應用程式本身才能診斷出來。以下是一些範例：
- 按下按鈕時毫無反應，卻沒有任何錯誤訊息告知原因。
- 人工智慧未返回任何回應，但你無法判斷是請求失敗還是回應內容為空。
- 頁面的一部分遺失，但HTML代碼與CSS看起來是正確的。
在上述每種情況中，您只能觀察到結果卻無法追溯成因。開發人員工具（DevTools）能讓您直觀地檢視問題根源。本活動中，您將運用開發人員工具蒐集問題相關證據，再將這些證據提交給 Copilot 以實現更精準的修復方案。
在下面的影片中，我們將調試TutorMatch應用程式中的一些問題。程式碼已進行修改以模擬這些潛在問題。
如影片所示，以下是使用開發人員工具（DevTools）修復問題的一般流程。
開啟 GitHub Codespace 與開發工具
- 前往 GitHub 並導航至您的 MVP 儲存庫。
- 開啟新分支（或使用現有的開發分支）。開啟任何現有的代碼空間，並確保切換至正確的分支。
- 在 Codespaces 內執行您的應用程式。
- 在瀏覽器分頁中，於頁面任意位置點擊滑鼠右鍵，選擇「檢查（或按下 F12）」以開啟開發人員工具面板。
2. 推測此問題屬於使用者介面問題，抑或邏輯/API問題
在深入研究標籤之前，先問問自己：你所面對的是哪種類型的問題？這將決定你該從何處著手。
你所看見的
類型
在開發人員工具面板中查看的位置
元素遺失、未對齊或重疊
使用者介面問題
元素標籤頁
按鈕無反應或顯示錯誤資料
邏輯問題
控制台標籤頁
AI 功能未返回任何回應或錯誤
API問題
網路標籤頁
頁面佈局在修復後看起來有問題
使用者介面問題
元素標籤頁
無法讀取未定義屬性
邏輯問題
控制台標籤頁
3. 針對介面問題 - 使用「元素」標籤進行檢視
若您的問題屬於視覺層面，例如版面配置、間距、元素遺漏等。
- 點擊開發人員工具中的「元素」標籤頁
- 使用元素選擇器工具（開發者工具左上角的游標圖示，或按下 Ctrl+Shift+C / Cmd+Shift+C）。
- 將游標懸停於頁面問題區域，即可標示該 HTML 元素並顯示其 CSS 樣式
4. 針對邏輯與 API 問題 — 請檢查後台的控制台與網路分頁
若您的問題涉及資料、行為或 API 呼叫，請檢查後端伺服器的瀏覽器視窗。請從「控制台」標籤頁開始檢視。
- 點擊「控制台」標籤頁。
- 點擊清除按鈕清除舊訊息，重新開始。
- 現在請在應用程式中重現該錯誤，並開始接收新訊息的傳入
- 留意新訊息：例如：
- 紅色訊息 是錯誤訊息，通常包含檔案名稱、行號及錯誤描述
- 黃色訊息 代表警告。這些訊息值得留意，但未必會引發問題。
- 若出現任何錯誤訊息，請複製該訊息。
- 若控制台未顯示任何錯誤，請切換至「網路」標籤頁。
- 清除現有記錄並重新重現此錯誤（請注意，網路標籤頁僅記錄標籤頁開啟期間發出的請求）。
- 尋找您的 API 呼叫。它通常顯示為 郵寄:
- 尋找分析功能或 /api/analyze
- 若請求失敗，狀態將顯示於 紅色顯示。
- 即使狀態 綠色 (200)，請點擊最右側的請求與回應欄位，並檢查以下詳細資訊
- 複製狀態碼、請求與回應主體，以及任何錯誤訊息。這些都是你的證據。
檢查事項
如何找到它
其意義為何
狀態代碼
狀態欄位，或標題標籤頁
該數字會告知您發生了哪種類型的錯誤
請求
點擊「請求」標籤（最右側）
您的應用程式傳送的內容——有助於檢查輸入是否錯誤
回應
點擊「回應」標籤頁（最右側）
伺服器實際傳回的錯誤訊息，或回應內容本身，可能格式不正確。
以下是一些常見的狀態代碼：
狀態代碼
意義
共同事業
200
成功
一切運作正常（若結果仍錯誤，請檢查您傳送的內容與收到的回應）
400
錯誤請求
您的 API 金鑰遺失、過期或不正確
401
未經授權
伺服器實際傳回的錯誤訊息，或回應內容本身，可能格式不正確。
403
禁忌
您的 API 金鑰沒有執行此操作的權限
429
請求過多
您已達到速率限制——請稍候片刻後再試一次
500
伺服器錯誤
API 服務端出現問題——請稍後再試
5. 運用您的證據與 Copilot
- 返回 Codespaces 將您的開發工具發現結果導入 Copilot。這些證據能讓您的除錯提示更加具體明確。
- 請使用此範本輸入您的證據：
請先不要給我任何程式碼。只需解釋造成此問題的原因，以及修正方案為何有效。我希望理解問題本質，而非僅止於解決問題。
**問題：** [當使用者觸發該功能時發生的狀況]
**開發者工具證據：**
– 控制台錯誤：[貼上錯誤訊息，或「無控制台錯誤」]
– 網路狀態代碼：[例如：401]
– 請求：[貼上應用程式傳送的內容（如適用）]
– 回應：[貼上來自 API 的錯誤訊息或內容回應]
由於您提供了具體證據而非模糊描述，Copilot 得以給出精確的解釋與針對性解決方案。
6. 在開發人員工具中套用修正並驗證
在 Copilot 說明問題並讓您理解後，請在您的 Codespace 中套用修正方案。接著透過執行應用程式並重現導致問題的步驟來驗證。您應能在應用程式本身進行驗證，但亦可使用開發人員工具進行驗證：
- 關於 API 修復： 開啟後台的「網路」標籤頁，觸發先前失敗的相同操作。檢查：
- 請求現在是否返回 200（成功）？
- 「回應」標籤頁是否顯示預期資料？
- 針對 UI 修正：請使用 「元素」標籤頁（前端）確認元素現已顯示且樣式正確。
- 邏輯修正：觸發操作時，請檢查控制台（前端）是否出現新的紅色錯誤訊息。
7. 部署並提交您的修正方案
更新您的 issue-tracker.md ，記錄您在開發工具中發現的問題及解決方式。完成後，請將變更加入待提交區塊並將修正內容提交至您的儲存庫分支。
驗證與文件測試
您已學會運用開發者工具來診斷某些棘手問題。在您對最小可行產品（MVP）進行除錯與程式碼更新時，必須驗證所有元件能否協同運作、記錄操作步驟，並將變更合併至主分支。
測試是確認修正方案確實有效，且未破壞其他功能的關鍵步驟。在接下來的活動中，您將學習如何轉換測試計畫，使其能以更系統化的方式驗證應用程式的功能。此方法不僅能協助人工智慧理解應通過的測試項目，甚至可自動執行測試流程。
活動 3
測試、驗證並記錄您的修正方案
預估時間：25分鐘
1. 開啟 GitHub Codespace 並建立您的測試檢查清單
沒有檢查清單的測試意味著我們會遺漏測試案例或測試不一致。我們將不再手動輸入結構，而是使用 Copilot 根據您的錯誤修復和應用程式功能，生成一份全面的測試檢查清單。
- 前往 GitHub 並導航至您的 MVP 儲存庫。
- 導航至您的開發分支（或建立新分支），並從現有活動中開啟任何現有的程式碼空間。
- 開啟您的 Codespace。
- 請務必切換至開發分支。
- 建立一個名為 test-checklist.md 於您的 Codespace 中 test 資料夾中建立名為
- 請使用此範本向 Copilot 提供您的證據：
請在 [您的應用程式名稱] 的 test 資料夾中，將內容新增至 test_checklist.md 檔案，並採用以下結構：
– 標題欄位，內含應用程式名稱、最後測試日期及測試人員姓名預留位置
– 核心功能部分涵蓋以下主要特性：[列出您的2-3項主要功能]
– 邊緣案例章節包含常見情境：空輸入、長輸入（100+ 字）、快速點擊、行動裝置視口測試
– 最近的錯誤修復部分
針對「近期錯誤修復」部分，請檢視我於當前分支的近期提交記錄，並為每項修復建立專屬測試案例。每項測試應驗證錯誤已解決，並描述預期行為。
使測試案例具體且可操作——他人應能直接執行測試案例，無需提出疑問。
2. 檢視您的檢查表輸出結果
檢視生成的檢查清單，並自問：
- 核心功能測試是否涵蓋了從ENT 9開始的主要用戶旅程？若未涵蓋，請補足缺失步驟。
- 是否有未列出的邊緣案例是我的使用者實際遇到的？若有，請手動新增。
- 錯誤修復測試是否與我實際修復的內容相符？
- 測試案例是否足夠具體？
若發現內容有缺漏之處，您可自行補全，或要求 Copilot 強化特定段落，並確保這些內容被完整納入生成的檔案中。
3. 逐項檢查您的清單
系統性地處理每一行：
- 請精確執行所列步驟。
- 將實際發生的情況與預期結果進行比較。
- 標記通過或未通過。
- 若任何環節出錯，請記錄問題所在。
徹底測試的要訣：
- 請在全新的無痕/私人瀏覽器視窗中進行測試，以避免使用快取資料。
- 先測試正常路徑（一切運作如預期）。
- 接著測試邊界情況（空輸入、極長輸入、快速點擊）。
- 在行動裝置檢視窗格上測試（開發人員工具 → 裝置模式，或直接在手機上測試）
若測試失敗：
- 這是一項 回歸 問題——這意味著修復方案破壞了其他功能。
- 返回活動 2 並應用「教我」模式。
- 有時初始修復僅解決症狀而非根源問題。
4. 提交變更並合併至主分支
- 完成所有測試並填寫結果後，請將變更暫存至分支並提交。
- 前往 GitHub，將你的分支合併到主分支。
反思
回應使用者測試問題並除錯您的應用程式是一項持續進行的過程。請自問以下問題：
關鍵術語
- 錯誤：應用程式中未按預期運作的缺陷。當機、錯誤結果及混淆行為皆屬此類。
- P0 / P1 / P2 / P3：問題的優先級等級。P0 為關鍵級（阻斷使用者操作），P1 為重要級（造成困擾但尚可運作），P2 為次要級（發生頻率低），P3 為美觀級（精修調整）。
- 莫斯科法：一種優先級框架，將項目歸類為「必須」、「應當」、「可能」和「不會」四類，適用於特定迭代週期。
- 根本原因：錯誤發生的深層原因——不僅是使用者所見的現象，更在於程式碼中導致錯誤發生的本質。解決根本原因可防止問題再次發生。
- 「教我」模式：一種除錯方法，要求人工智慧先解釋問題再提供解決方案。此法著重建立理解，而非複製貼上解決方案。
- 開發者工具：瀏覽器開發者工具（F12 或右鍵點擊 → 檢查）。包含用於錯誤偵測的控制台、用於 API 呼叫的網路分頁，以及用於佈局檢查的元素分頁。
- 控制台標籤頁：顯示 JavaScript 錯誤、警告及日誌訊息。紅色條目為錯誤，並附帶指向問題所在的檔案名稱與行號。
- 網路分頁：顯示應用程式發出的所有 HTTP 請求，包含 API 呼叫。呈現狀態碼、請求詳情及回應資料。
- 元素標籤頁：顯示頁面的 HTML 結構與 CSS 樣式。有助於診斷版面配置與視覺問題。
- 狀態碼：由伺服器返回的數字，用以指示成功（200）、客戶端錯誤（400-499）或伺服器錯誤（500-599）。
- 問題追蹤器：記錄錯誤、其優先級、根本原因及修復方案的文件。能使除錯工作井然有序，並提供變更歷史紀錄。
- 回歸：在修復某個問題時，意外導致先前正常運作的功能失效。測試檢查表有助於發現回歸問題。
其他資源
- Chrome 開發者工具文件：瀏覽器開發者工具官方指南
- HTTP狀態碼：理解API回應代碼的參考指南
- GitHub Pull Requests：如何建立與管理拉取請求
- GitHub Copilot 指南：進階使用者技巧
