情境
正式應用中的程式碼審查
情境：Pull Request 修改驗證中介層。 審查服務將差異檔、附近函式、儲存庫安全規則與變更行對照送至 codex-auto-review。 模型只能回傳指出具體失敗路徑的問題。
服務拒絕缺少檔案、變更行、嚴重度、證據與修正的意見。 評估集也包含乾淨 PR，因此意見更多不代表審查更好。
正式環境場景
程式碼審查用 LLM API
情境：Pull Request 修改驗證中介層。 審查服務將差異檔、附近函式、儲存庫安全規則與變更行對照送至 codex-auto-review。 模型只能回傳指出具體失敗路徑的問題。
正式環境實作
API、主要模型與備援設定
| 正式環境選擇 | 建議 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | OpenAI 相容伺服器端請求 |
| 主要模型 | codex-auto-review | codex-auto-review 是模型廣場目前提供的自動審查專用首選路徑。 |
| 備援模型 | gpt-5.6-terra | 審查需要更廣儲存庫推理時用 Terra；有爭議的高風險問題升級 Sol，不必每個一般 PR 都用 Sol。 |
| 升級模型 | gpt-5.6-sol | 只在主要路徑未達品質或複雜度門檻時使用 |
| 輸出規則 | 通過驗證的 JSON | JSON 問題包含檔案、行、嚴重度、標題、證據、失敗路徑與建議修正。 |
架構
程式碼審查流程如何運作
- 建立差異檔與變更行對照。
- 只取得直接相關程式碼與儲存庫規則。
- 要求附證據與最小行範圍的結構化問題。
- 格式錯誤或差異外意見予以排除，除非其依賴路徑有證據。
- 將通過的問題交給人工審查者。
API 請求
透過 LLMFly AI 呼叫 codex-auto-review
從伺服器送出請求，將範例內容與預留工具格式換成應用的資料與工具。
curl https://app.llmfly.ai/v1/chat/completions \
-H "Authorization: Bearer $LLMFLY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "codex-auto-review",
"messages": [
{"role": "system", "content": "Review the supplied diff. Report only actionable defects introduced by this change. Each finding needs file, changed line, severity, failure path, evidence, and a minimal fix."},
{"role": "user", "content": "Review this authentication middleware pull request against the attached repository rules."}
],
"response_format": {"type": "json_object"}
}'模型選擇
為什麼以 codex-auto-review 為主要模型
codex-auto-review 是模型廣場目前提供的自動審查專用首選路徑。
審查需要更廣儲存庫推理時用 Terra；有爭議的高風險問題升級 Sol，不必每個一般 PR 都用 Sol。
驗收
程式碼審查驗收檢查
| 指標 | 通過條件 |
|---|---|
| 真實缺陷找出率 | 找出評估集刻意放入的高風險缺陷 |
| 誤報率 | 乾淨對照變更不出現阻擋或捏造問題 |
| 行層級依據 | 每個問題指向最小相關行範圍並解釋失敗路徑 |
| 審查者採用率 | 合格審查者認為意見正確、可行且值得顯示 |
失敗處理
部署前要處理的失敗
- 獎勵意見數量
- 只用有缺陷範例
- 接受模糊最佳實務建議
- 無證據評論變更行之外
輸出
回傳輸出與執行紀錄
JSON 問題包含檔案、行、嚴重度、標題、證據、失敗路徑與建議修正。
每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。
常見問題
如何量測誤報？
納入乾淨變更，計算合格審查者因錯誤或不可行而拒絕的問題。
程式碼審查需要整個儲存庫嗎？
不一定。 先用差異檔與直接相關檔案，需要時再取得更多上下文。
哪種輸出格式較適合？
使用包含檔案、行、嚴重度、說明、證據與建議修正的格式。
用自己的輸入測試設定
以相同請求、工具與驗證規則比較主要和備援模型。