代碼審查：按嚴重程度分級

提交前想讓模型先掃一遍，但要能分清「必須改」和「可以不改」。

提示詞全文

請審查下面的代碼，按嚴重程度分成三級輸出。

代碼：
```
{{代碼}}
```

分級標準：
- 🔴 必須改：會導致錯誤結果、安全漏洞、或明確的效能問題
- 🟡 建議改：可讀性、可維護性問題，不影響當前功能
- 🟢 可以不改：風格偏好，改了更好但不改也行

每個問題給出：
1. 問題所在（文件名:行號 或 函數名）
2. 為什麼是問題
3. 具體修改建議（給出修改後的代碼片段）
4. 不改的後果

要求：
- 不要列出「看起來沒問題」的部分，只說問題
- 如果某個問題依賴上下文我沒提供，直接說明「需要看 XXX 才能判斷」
- 不要建議引入新的第三方依賴

為什麼這樣寫

• 三級分類解決了「審查結果太長看不完」的問題。不分級時，模型會把風格問題和邏輯錯誤混在一起列。
• 要求「給出修改後的代碼」而非「建議修改」，能省掉你自己改的步驟。
• 「不要建議引入新依賴」是實務限制 —— 審查建議最常見的廢話就是「可以用 lodash 的 xxx」。

成本

按上面這段提示詞估算（輸入 196 tokens、輸出 300 tokens）。輸出長度依任務而定，實際會有差異。

變體

• 只關心安全時，把分級標準換成「可利用 / 理論風險 / 無風險」，並要求標注攻擊路徑。
• 審查大文件時，先讓模型列出「這個文件負責什麼、有幾個函數」，再逐個審查。

常見失敗

• 一次貼超過 500 行時，模型會遺漏後段，建議按函數分批。
• 不限制「不要建議新依賴」，會得到大量無法落地的重構建議。

相關

全部提示詞 · 編程類提示詞 · 成本計算器 · 價格表