程式開發進階
Code Review 提示詞:找出潛在 bug 與可讀性問題
請 AI review 一段程式碼時,明確要求分類回報——bug、可讀性、效能——比籠統問「這段程式碼怎麼樣」得到更能直接動手改的結果。
適用工具:ClaudeChatGPTGemini
單純問「幫我看看這段程式碼」,AI 通常會給一堆建議,但嚴重的 bug 和無關痛癢的風格意見混在一起,很難第一眼判斷該先處理哪個。
這個提示詞要求依類別分類回報,並標出優先序,讓結果能直接拿去排改動清單,而不是一長串需要自己再篩一次的建議。
請 review 以下這段[程式語言]程式碼。這段程式碼的目的是:[簡述功能]。
請依以下類別分類回報,每一項標註優先序(高/中/低):
- Bug/邏輯錯誤:會導致錯誤結果或崩潰的問題
- 邊界條件遺漏:輸入為空、超出範圍、型別不符等情況有沒有處理
- 可讀性:命名、註解、結構是否讓人容易看懂
- 效能:有沒有明顯沒必要的重複運算或低效寫法
如果程式碼整體沒問題,直接說明,不用為了湊建議硬找問題。
程式碼: [貼上程式碼]
怎麼用
- 先處理標「高」的項目。 這是最快看出 review 有沒有價值的地方——真正的 bug 通常就在這一類。
- 功能說明寫清楚,AI 才抓得到邏輯錯誤。 沒講清楚這段程式碼該做什麼,AI 只能檢查語法層面的問題,抓不出「寫得出來但邏輯不對」的 bug。
- 對「沒問題」的回報保持合理懷疑。 AI 有時會因為看不出更多問題而說沒事,複雜或牽涉業務邏輯的程式碼,還是需要真人再看一次。
常見問題
- AI review 能取代真人 code review 嗎?
- 不能完全取代,尤其是牽涉業務邏輯是否正確、架構決策是否合理這類需要團隊脈絡的判斷。AI review 適合當第一輪篩檢,抓出明顯的 bug 和風格問題,省下真人 reviewer 的時間去看更需要判斷力的部分。
- 為什麼要限制優先序,不要它全部列出來?
- 沒有優先序的話,AI 常常把嚴重的 bug 和無關痛癢的命名建議混在一起列,很難分辨該先改哪個。要求標優先序,是為了讓回報結果直接可以排進行動清單。
同分類的其他提示詞
看懂陌生程式碼:請 AI 逐層解釋在做什麼
接手別人的程式碼、或回頭看自己很久以前寫的東西,用這個提示詞請 AI 從整體邏輯講到關鍵細節,比自己一行一行推快很多。
幫函式補測試案例:連你沒想到的邊界條件一起補
給 AI 一段函式,請它補測試案例時明確要求涵蓋邊界條件與異常輸入,而不是只測試「正常會發生的情況」這種容易漏測的寫法。
更新於 .全部提示詞