Claude程式碼提示範本包：除錯、重構與架構審查

讓以下每個提示詞都能發揮效果的四項限制條件

在進入提示詞之前，先說明它們共通的規則。把這些規則加進任何程式碼提示詞裡，帶來的改善會比換一個模型還大。

說明你的版本。 訓練資料會偏向討論最多的主要版本，而那往往不是你目前使用的版本。我們使用的是[框架][版本]，[語言][版本]這句話能避免大多數過時的答案。

限制修改範圍。 要求修正錯誤，卻常常得到一次重構。盡量減少變動，保留現有的結構與命名，並列出你更動的每一行程式碼，附上一行理由說明，是這份文件中最有用的一句話。

先要求假設，再要求解法。 被問「哪裡出錯」的模型，會把猜測包裝成結論給你。被要求列出依可能性排序的原因和低成本檢查方式的模型，則會給你一份除錯計畫。

要求說明失敗模式。 這可能會弄壞什麼？這是在修正原因還是症狀？這句話能抓出AI協助中代價最高的一類問題：讓症狀消失、但缺陷仍然存在的修改。

除錯

1. 依可能性排序的假設

這是錯誤訊息、相關程式碼，以及我已經排除的可能原因。先不要給我修正方式。請列出四個最可能的原因，依可能性排序，並針對每一項提供成本最低、能確認或排除它的檢查方式。錯誤訊息：[貼上]。程式碼：[貼上]。已排除：[列表]。技術堆疊：[語言、框架、版本]。

2. 間歇性錯誤

這個問題會間歇性發生，大約[頻率]，發生在[條件]下。請列舉可能造成這個特定症狀的間歇性失敗類型：時序、順序、資源耗盡、外部依賴、執行間的狀態外洩、時鐘或時區、快取。針對每一種，說明程式碼中哪些地方支持或反駁這個原因，以及我應該記錄哪些資訊來區分它們。程式碼：[貼上]。

3. 在本機可以運作

這在本機可以正常運作，但在[環境]中會失敗。請列出所有可能造成這個特定症狀的環境差異類型：設定、環境變數、版本、檔案系統與大小寫敏感度、時區與地區設定、網路與DNS、權限、資源限制，以及建置或打包方式的差異。根據症狀依可能性排序，並提供每一項的診斷指令。

4. 採用修正方式前先說明原因

請說明這個修正方式為什麼有效、它沒有修正到什麼，以及它可能會弄壞什麼。如果真正的原因在別處，而這只是針對症狀的修補，請直接說明。

程式碼審查

5. 審查一個diff

請以嚴格審查者的角度審查這個diff。依優先順序分類：正確性錯誤、安全性問題、未處理的失敗模式、競態條件，最後才是風格。針對每個發現，說明嚴重程度、具體行數，以及為什麼這在這個程式碼庫中很重要，而不是泛泛而談。不要評論格式問題。如果diff沒有問題，請直接說明，不要硬找問題。慣例：[描述]。Diff：[貼上]。

6. 安全性檢查

請專門針對安全性問題審查這段程式碼：注入攻擊、身分驗證與授權漏洞、不安全的反序列化、程式碼或紀錄中的機密資訊、未經驗證的輸入進入敏感操作，以及相依套件風險。針對每一項，請具體說明攻擊路徑，而不只是列出類別名稱。並清楚說明在沒有看到[部署方式、驗證層、資料敏感度]的情況下，哪些是你無法評估的。

7. 失敗模式稽核

針對這段程式碼中的每一個外部呼叫，說明它變慢時、失敗時、回傳非預期資料時，以及部分成功時分別會發生什麼事。目前哪些情況沒有被處理？哪些會是無聲失敗？

最後這一項找到的實際生產環境問題，比一般審查還要多，因為它問的正是沒有人寫過測試的那些路徑。

重構與架構

8. 重構計畫

請提出一份分階段的計畫來重構[描述]。限制條件：[x]的公開API不能改變，我們採取持續部署，所以每個步驟都必須能獨立上線，並且每個步驟之後測試都必須通過。針對每個步驟，說明變更內容、風險、驗證方式，以及如何回滾。依風險由低到高排序。先不要寫程式碼。

9. 為另一方辯護

基於[背景與限制條件]，我選擇了[方案A]而非[方案B]。請提出B最強有力的論點。若B是正確的，我們的限制條件必須符合哪些前提，其中有哪些在這裡確實成立？不要直接下結論說兩者都可行。

10. 理解你接手的程式碼

這是主要的原始碼檔案。請整理出：進入點、從請求到回應的資料流、被共用的狀態及其被修改的位置、外部依賴以及各自無法使用時會發生什麼事，以及根據複雜度與耦合度判斷最可能有錯誤的三個區域。並明確說明哪些部分是你根據我提供的資料無法判斷的。

最後這個指示很重要。模型會根據檔名，描述你沒有貼上的檔案的行為。強制模型明確列出未知項目，能告訴你接下來該去讀哪些程式碼。

測試

11. 你原本不會寫的測試

請為這個函式撰寫測試案例，重點放在我可能沒有考慮到的輸入：邊界值、空值與null、unicode、極大值、並行呼叫，以及實作中任何隱含的假設。針對每個測試，說明它在檢驗哪個假設。函式：[貼上]。

12. 測試這套測試組

這是一個函式與它現有的測試。有哪些行為沒有被涵蓋到？具體來說：錯誤路徑、邊界值、參數之間的互動，以及實作中任何沒有測試斷言到的行為。不要重寫現有的測試。

第二個提示詞價值更高，卻很少被用到。覆蓋率百分比告訴你哪些程式碼行有被執行，而不是哪些行為真正被驗證到，而這兩者之間的落差，正是回歸錯誤藏身之處。

第二意見模式

這整套範本中槓桿效益最高的習慣，也是唯一需要用到不只一個模型的做法。

先從一個模型那裡得到答案，然後換一個模型，把答案交給它：

另一位工程師針對這個問題提出了這個解法。請找出它有哪些問題：邊界情況下的正確性、並行處理、錯誤處理、在[規模]下的效能，或者是否有被忽略的更簡單做法。如果這個解法確實沒問題，請直接說明，不要硬找異議。問題：[貼上]。提出的解法：[貼上]。

會有兩種結果，而且都很有用。要不是第二個模型找到真正的漏洞，讓你在合併之前就知道；要不就是即使被要求提出異議，它仍然表示同意，這本身就是有意義的確認。用同一個模型反覆討論，這兩種結果你都得不到，因為模型審查自己的輸出時，大多會贊同自己。

把它用在做錯了代價很高的決定上：資料庫schema變更、並行處理修正，任何牽涉到身分驗證或金錢的事。日常工作則不需要。完整工作流程請參考並排比較多個模型、在對話中途切換模型，以及用多個模型撰寫與除錯程式碼。

需要留意的事項

捏造出來的API。 自信地給出不存在的方法名稱、參數和設定鍵值，尤其是最近有更新過的函式庫。函式簽章看起來會很正確。在建立於任何不熟悉的東西之前，請先查證真正的文件。

沒有信心程度的訊號。 正確的修正方式和微妙錯誤的修正方式，用的語氣同樣篤定。語氣不能告訴你任何事。

無聲的範圍擴大。 這正是第二項限制條件存在的原因。

安全劇場。 在你的程式碼中指出漏洞類別，是很有用的第一步審查。但這不是一次完整的稽核，而且模型並不了解你的威脅模型、部署方式或資料敏感度。

把你每週都會用到的提示詞放在方便複製貼上的地方，並把長期適用的限制條件放進專案的指示設定裡，這樣它們就會自動套用到該專案中的每一個對話。