提供 10 個可立即使用的 AI 程式碼審查提示詞範本，涵蓋安全性、效能、可讀性等面向，幫助開發團隊提升 code review 效率與程式碼品質。

為什麼 AI 程式碼審查提示詞決定 code review 成效

AI 程式碼審查提示詞集的核心價值在於：透過結構化指令讓大型語言模型（LLM）精準執行安全漏洞偵測、效能瓶頸識別與可讀性評估。根據史丹佛大學以人為本人工智慧研究所（Stanford HAI (Human-Center AI Institute)）發布的 AI Index 年度報告，程式碼生成與審查已成為企業 LLM 採用率最高的三大應用場景之一，企業導入 AI code review 工具後，平均缺陷偵測率提升 30-45%，審查時間縮短約 40%。

然而，提示詞品質直接決定輸出品質。Gartner 人工智慧研究（Gartner AI Research）的企業 AI 採用統計顯示，超過 60% 的開發團隊反映「AI 審查結果不夠精準」，主因正是提示詞缺乏角色定義、輸出格式規範與優先級權重。本文整理 10 個經實戰驗證的程式碼審查提示詞範本，協助團隊建立可複製、可量化的 AI 審查工作流。

核心提示詞範本：10 個實戰模板

範本 1：安全漏洞掃描（CVE 優先）

角色：資深安全工程師
任務：審查以下程式碼中的 OWASP Top 10 漏洞，
     特別標註 CVE 編號與 CWE 分類。
輸出格式：
- 漏洞等級（Critical/High/Medium/Low）
- CVE/CWE 編號
- 攻擊向量描述
- 修補建議（附程式碼）
優先級：身份驗證 > 注入攻擊 > 敏感資料外洩

此範本可將抽象的「檢查安全性」轉化為具體的 CVE/CWE 編號輸出，符合 MIT 計算機科學與人工智慧實驗室（MIT CSAIL）研究團隊在軟體工程 NLP 論文中強調的「結構化輸出提升模型準確率 22%」的結論。

範本 2：效能瓶頸分析

角色：後端效能工程師
任務：識別此程式碼的時間複雜度問題（O(n²) 以上標記），
     列出資料庫 N+1 查詢、記憶體洩漏風險。
輸出：Big O 分析表格 + 優化前後效能預估（ms/req）

範本 3：可讀性與命名規範

角色：Google 工程團隊 code review 標準制定者
任務：依照 Google style guide 審查命名、
     函式長度（建議 < 50 行）、註解比例。
輸出：逐行修改建議 + 改寫範例

範本 4：測試覆蓋率缺口

角色：QA 自動化測試架構師
任務：分析此函式的分支覆蓋率（branch coverage），
     列出未覆蓋的 edge case，包含 null、空陣列、
     邊界值、並發競爭條件。
輸出：建議測試案例清單（Given-When-Then 格式）

範本 5：API 設計一致性

角色：API 架構師
任務：比對此 endpoint 與既有 RESTful 規範的落差，
     檢查 HTTP status code 使用、錯誤訊息格式、
     請求/回應 schema 一致性。
參考：OpenAPI 3.1 + JSON:API 標準

範本 6：依賴套件風險評估

角色：DevSecOps 工程師
任務：掃描 package.json / requirements.txt 中
     過期或已知漏洞的套件。
輸出：CVE 編號 + 嚴重等級 + 升級路徑
排除：devDependencies

範本 7：並發與競態條件

角色：分散式系統工程師
任務：審查此程式碼的 thread-safety，
     標註 race condition、deadlock 風險點。
輸出：風險等級 + Jepsen 測試建議情境

範本 8：無障礙與國際化（a11y / i18n）

角色：前端無障礙專家
任務：檢查 UI 元件的 WCAG 2.2 AA 合規性、
     鍵盤導向支援、aria-label 完整性。
輸出：違規項目 + 修正後的 JSX/Vue 範例

範本 9：文件與註解品質

角色：技術文件工程師
任務：為此模組產生 JSDoc / docstring，
     包含 @param、@returns、@throws、@example。
風格：繁體中文，語氣專業但易讀

範本 10：PR 描述自動生成

角色：技術寫手
任務：根據 git diff 產生 Pull Request 描述，
     包含變更摘要、影響範圍、測試計畫、
     截圖建議位置。
字數限制：300 字以內

進階優化：提示詞工程實戰技巧

根據 Gartner AI Research 的技術成熟度曲線分析，企業 AI 程式碼審查工具的採用率在 2024-2025 年間成長 2.8 倍，但「提示詞工程」仍是瓶頸。IEEE（Institute of Electrical and Electronics Engineers）發布的 IEEE 7000 系列倫理標準亦強調，AI 系統輸出需具備「可追溯性」與「可解釋性」，這正是結構化提示詞的核心訴求。

實戰建議：將上述 10 個範本儲存為團隊共用 snippet，搭配 CI/CD 流程（如 GitHub Actions 的 `ai-review.yml`）自動觸發。每週根據誤判率調整提示詞權重，並建立內部「提示詞版本控制」機制（建議使用 Git 管理），以資料驅動方式持續優化 AI 審查品質。

ROI 計算：同樣 $50/月能做什麼

以 Claude Sonnet 4.5 API 為例，$50 月費約可處理 2,000 次中等長度的程式碼審查請求，每次成本約 $0.025。若改用 GPT-5.1 同等輸入量，月費約 $75；Gemini 2.5 Pro 約 $60。若團隊每月需審查 800 個 PR，採用 API 方案可節省約 60% 成本，相當於一名初級審查者 2.3 倍的人力時數。

建議從「安全漏洞掃描」與「測試覆蓋率缺口」兩類高 ROI 提示詞優先導入，預估可攔截 70% 以上常見缺陷，其餘範本依團隊痛點分階段導入。