更新於 2025年9月22日
12 分鐘
你需要的不是更多的註解,而是更好的 Prompt。一個平庸的 AI 程式碼審查和一個精準的程式碼審查之間的差異,通常取決於你如何提問。
你是一位資深的 [語言/框架] 工程師,正在為 [專案/領域] 審查程式碼。目標:[錯誤修復 | 效能 | 可讀性 | 安全性 | DX | API 一致性]約束:[風格指南、支援的版本、記憶體/時間限制、函式庫約束]上下文:- 運行時/環境:[Node 20, JVM 17, Python 3.11, iOS 17, etc.]- 關鍵相依性:[清單]- 架構:[單體、微服務、無伺服器、六角形等]- 相關介面/合約:[連結或內嵌]任務:1) 審查以下程式碼以達到 [目標]。2) 找出具有證據的特定問題(行號參考、複雜性估計、邊緣情況)。3) 提出最小、有針對性的差異。4) 提供最終重構的版本。5) 解釋權衡取捨和風險。程式碼:```[language]// 在此貼上程式碼為什麼它有效:- 框定角色和目標。- 設定約束和上下文。- 強制證據和結構。- 產生差異 + 最終程式碼 + 測試。---## 常見情境的快速入門範本### 1) 錯誤修復 + 安全網```text扮演資深的 [語言] 工程師。 審查正確性和隱藏的邊緣情況。重點:競爭條件、null/None 處理、差一錯誤、輸入驗證、錯誤傳播。提供:帶有行號參考的問題、最小差異和帶有測試的安全重構。目標:在不改變公共行為的情況下,降低時間和記憶體複雜度。提供:當前複雜度、建議複雜度、微最佳化與演算法變更,以及要執行的基準。為了清晰起見進行重構:更好的命名、更小的函數、單一職責。新增文件字串/JSDoc,簡化控制流程,刪除無效程式碼。 保持公共 API 穩定。威脅模型:來自 [來源] 的不受信任的輸入。檢查:注入、反序列化、SSRF、XSS、CSRF、authZ/authN、秘密處理。建議:安全的函式庫、驗證模式和最小差異。我們正在從 [lib A] 遷移到 [lib B]。列出重大變更、提出一個適配器層,並提供一個帶有測試的增量推出計畫。環境:Python 3.11、FastAPI、Pydantic v2。合約:即使部分失敗,端點也必須使用 { data, meta } 回傳 200。約束:必須保持非同步; 無法新增新的重量級相依性。1) 評論:列出具有證據的具體問題。2) 差異:用於修復的最小變更。3) 重構:乾淨、慣用的最終程式碼。4) 測試:涵蓋 happy path + 3 個邊緣情況的單元測試。提出 3 個重構選項:- 選項 A:最小變更- 選項 B:適度重新設計- 選項 C:完全重寫對於每個:優點/缺點、複雜度、風險、遷移計畫以及何時選擇它。約束:相同的公共 API、<50ms p95、<10MB 額外記憶體、沒有新的運行時相依性。展示你的重構如何透過測量或推理來滿足每個約束。你是一位資深的 Python 工程師。 目標:正確性 + 效能。環境:Python 3.11、FastAPI、httpx、Pydantic v2。 合約:永遠不要在部分失敗時引發異常。任務:審查和重構。 提供評論 → 最小差異 → 最終重構 → 測試。程式碼:```pythonfrom fastapi import APIRouterimport httpxrouter = APIRouter@router.get("/users/{user_id}")async def get_user(user_id: str):async with httpx.AsyncClient as client:profile = await client.get(f")posts = await client.get(f")return {"data": {"profile": profile.json, "posts": posts.json}}這個 Prompt 給了 Grok 4 工作、護欄和輸出形狀,因此它的建議很容易應用。---## 從原始建議到可交付的程式碼:一個迭代迴圈像對待結對程式設計師一樣對待 Grok 4。 使用一個緊密的迴圈:1. 從最小的可重現程式碼和約束開始。2. 要求評論 + 有針對性的差異。3. 在本地應用差異; 執行測試/基準。4. 將失敗/輸出貼回到 Grok 4 中,並顯示:「這是失敗的案例; 調整。」5. 鎖定約束:「不要改變公共 API。 保持複雜度 O(n)。」6. 要求測試和基於屬性的案例。迭代 Prompt:```text這是測試失敗和基準。 保持先前的約束。 提出最小的變更以修復所有紅色測試,而不破壞公共 API。 僅回傳統一差異。使用 {severity, category, rationale} 註釋每個建議。 如果行為可能改變,請包含修改前/修改後程式碼片段和一個步驟的遷移計畫。tsconfig 目標、Node/瀏覽器環境、捆綁器樹狀結構刪減和 ESLint/Prettier 規則。JSDoc/TSDoc 和可辨識聯合,以實現更安全的類型。mypy 目標、pydantic v1 與 v2、同步與非同步,以及類型提示等級。hypothesis 請求 pytest 裝置和屬性測試。context.Context 傳播和使用 %w 進行錯誤包裝。proptest 案例。使用來自此儲存庫根目錄的正確檔案路徑,以統一差異的形式回傳輸出。 僅包含變更的程式碼區塊。 差異中沒有註解。 然後包含一個單獨的註解區段。使用兩個區塊回應:1) ```diff...變更...---## 強制執行非功能性需求 (NFR)如果你需要保證延遲、記憶體或相容性,請將它們放在 Prompt 中並要求 Grok 4 進行自我檢查:```textNFR:p95 延遲 +< 與基準相比為 20 毫秒,記憶體增量 < 5MB,零新的運行時相依性,相同的公共 API。新增一個自我檢查區段,確認每個 NFR,並提供粗略的推理或微基準測試想法。使用引用的行或程式碼片段,用一句話解釋每個變更。 如果不確定,請提出澄清問題,而不是猜測。如果需求不明確,請在繼續之前提出最多 3 個澄清問題。角色:資深的 TypeScript 工程師。目標:在不改變公共 API 的情況下,提高可讀性和運行時安全性。環境:Node 20、TypeScript 5.4、用於驗證的 Zod、ESLint Airbnb、strictNullChecks。約束:除了 Zod 之外,沒有新的運行時相依性,沒有重大變更,保持 O(n) 複雜度。任務:- 評論 → 差異 → 重構 → 測試 → 註解。- 使用 {severity, category, rationale} 標記問題。- 包含一個用於輸入驗證的 Zod 架構和 4 個單元測試。程式碼:```tsexport function parseUser(raw: any) {if (!raw) return nullreturn {id: raw.id || '0',name: raw.name || 'Unknown',age: parseInt(raw.age),}}---## 讓 Grok 4 尊重樣式和架構使用具體規則錨定模型:```text樣式:Airbnb TS。 偏好提早回傳、避免深度巢狀、使用明確類型。架構:保持純函數; 沒有副作用。 在邊界進行輸入驗證。執行一個精神 ESLint 傳遞並列出你期望的違規行為,然後修復它們。對於每個變更,命名重構模式(例如,提取函數、引入參數物件)並解釋何時在此程式碼庫中應用它。僅使用儲存庫上下文。 審查此 PR 中變更的檔案以達到 [目標]。 使用嚴重性和理由內嵌註釋發現。 提出保留公共 API 和 NFR 的差異。 僅包含觸及變更路徑的測試。