類別 3：程式設計與技術 2 / 6
中階 Guide 14 Coding Review Debugging

程式碼審查與除錯

讓 Claude 成為你的程式碼審查夥伴 — 找出錯誤、安全問題，並獲得改進建議。

2026年3月25日 10 min read

你將學到什麼

  • 如何架構有效的程式碼審查提示，以浮現錯誤、安全問題和可維護性關切
  • 使用 Claude 系統性地除錯錯誤——從堆疊追蹤到微妙的邏輯錯誤的技巧
  • 如何獲得優先排序的、可行動的回饋，而不是泛泛的建議

使用情境

每個開發者都知道那種感覺：你已經盯著同一段程式碼好幾個小時，什麼都看不出來了。或者你正要合併一個 PR，感覺哪裡不對，但你無法說清楚是什麼。Claude 是一個不知疲倦的審查者，永遠不會疲勞，永遠不會錯過括號，並且不會在同一個文件裡待了幾個小時後有你一樣的盲點。

用 Claude 進行程式碼審查與自動化 linter 不同。Linter 執行語法規則和風格慣例。Claude 理解意圖——它可以告訴你你的錯誤處理是否真的涵蓋了你關心的失敗模式、你的演算法在特定邊界情況下是否有差一錯誤，或者一個函數是否做了太多事情應該被拆分。它還可以解釋為什麼某件事是個問題，而不只是標記它是。

除錯同樣有價值。當你遇到一個你不理解的堆疊追蹤，或你的程式碼在沒有任何錯誤的情況下產生錯誤的輸出時，Claude 可以幫助你系統性地推理執行過程。這對不熟悉領域的錯誤特別有用——你剛開始使用的函式庫、你很少接觸的語言特性，或現在由你負責的其他人的程式碼。

逐步指南

第一步：設定審查的範圍

在貼上程式碼之前，告訴 Claude 你想要什麼類型的審查。程式碼審查有多個維度，不同的情況需要不同的焦點：

  • 錯誤尋找：「尋找邏輯錯誤、差一錯誤和不正確的假設。」
  • 安全審查：「檢查常見漏洞——注入風險、不正確的輸入驗證、不安全的預設值。」
  • 效能審查：「識別瓶頸、不必要的記憶體分配和演算法效率低下。」
  • 可維護性審查：「評估可讀性、命名、複雜性，以及這是否遵循良好的關注點分離。」

沒有範圍的話，Claude 可能給你一個表面觸及所有維度的通用審查。範圍讓你在真正需要的地方獲得深入、可行動的回饋。

第二步：提供完整的背景資訊

貼上要審查的程式碼。更重要的是，添加 Claude 需要有意義地審查它的背景資訊：

  • 這段程式碼應該做什麼？
  • 什麼語言、版本和框架？
  • 是否有任何你已經承諾的已知限制或設計決策？
  • 你最擔心哪個特定領域？

範例：「這是一個用於用戶身份驗證的 Python 3.11 FastAPI 端點處理器。它接收用戶名和密碼，使用 SQLAlchemy 2.0 對我們的資料庫進行檢查，並返回一個 JWT token。我特別關心安全性——請以身份驗證漏洞和輸入驗證為重點審查它。」

第三步：用堆疊追蹤或症狀描述進行除錯

對於除錯，同時貼上程式碼和錯誤。將你的提示結構化為：

  1. 程式碼應該做什麼
  2. 實際發生了什麼（如果有的話，包含完整的錯誤訊息和堆疊追蹤）
  3. 你已經嘗試了什麼

範例：「這個函數應該將任意深度的嵌套清單展平。當我傳入 [1, [2, [3, 4]], 5] 時，它正確返回 [1, 2, 3, 4, 5]，但當我傳入 [1, [2, []]] 時，它拋出 TypeError: 'int' object is not iterable。以下是程式碼和堆疊追蹤。我已確認基本情況檢查被執行——問題似乎在遞迴分支中。」

第四步：請求優先排序的發現

在審查較大的程式碼塊時，請 Claude 對其發現進行優先排序：

「審查後，按從最嚴重到最不嚴重的順序列出你發現的問題——先是關鍵錯誤，然後是安全問題，然後是風格問題。」

這確保你首先修復最重要的問題，不要花時間在表面問題上，而安全漏洞沒有得到修補。

第五步：請求可行動的修復，而不只是描述

不要只請 Claude 識別問題——請它修復它們：

「對於你發現的每個問題，在你的解釋旁邊顯示修正後的程式碼。」

這將審查轉化為你可以直接應用的具體差異，而不是你必須自己解讀和實作的報告。

提示範本

請審查以下 [語言] 程式碼。

背景資訊：
- 它做什麼：[函數/模組目的的簡短描述]
- 框架/版本：[例如，Node.js 20、Express 4、TypeScript 5]
- 已知限制：[任何已經鎖定的設計決策]

這次審查的焦點領域：
- [例如，正確性 / 安全性 / 效能 / 可讀性]
- [如果有的話，具體的關切]

對於發現的每個問題：
1. 描述問題以及為什麼重要
2. 顯示修正後的程式碼

請按從最嚴重到最不嚴重的順序排列發現。

[在此貼上程式碼]

對於除錯：

我在除錯一個 [語言] 函數。以下是發生的情況：

預期行為：[應該發生什麼]
實際行為：[實際發生了什麼，包含任何錯誤/堆疊追蹤]
我已經嘗試了什麼：[已採取的步驟]

[貼上程式碼和錯誤訊息]

帶我了解造成這個問題的原因，並顯示修復方法。

技巧與最佳實踐

  1. 包含失敗的測試或輸入 — 如果你有觸發錯誤的具體輸入，包含它。「當我傳入空字符串時失敗」比單獨的程式碼提供了更有用的背景資訊。Claude 可以用具體例子更精確地追蹤執行過程。

  2. 不要在貼上之前淨化程式碼 — 開發者有時在請求審查前會清理他們的程式碼，刪除「令人尷尬」的部分。不要這樣做。混亂的部分往往是錯誤所在。貼上真實的東西。

  3. 問「我遺漏了什麼？」 — Claude 給出審查後，跟進：「還有什麼我沒有問到但我應該擔心的？」 這捕捉超出你所說範圍的問題。

  4. 使用 Claude 對你自己的修復進行第二意見 — 當你自己修復了一個錯誤時，貼上你的修復，問：「這個修復是否解決了根本原因，還是只處理了症狀？在哪些其他情況下這仍然可能失敗？」

  5. 對於安全審查，明確說明信任邊界 — 告訴 Claude 哪些數據是用戶提供的 vs. 內部的。安全問題在很大程度上取決於數據來自哪裡。「user_id 參數直接來自請求 URL——在這一點之前沒有經過驗證。」

動手試試

拿一個你最近寫的 pull request（或任何你正在工作的函數）。用這個提示貼入 Claude：

「請對這段 [語言] 程式碼進行以安全為重點的程式碼審查。識別任何輸入驗證差距、潛在的注入風險、不安全的假設，或可能洩露敏感資訊的錯誤處理。對於每個發現，顯示修正後的版本。」

看看 Claude 浮現了多少你的 linter 或你自己的審查所錯過的問題。