OpenQodex:在 push 之前為 Claude Code 與 Codex 做開源 AI 程式碼評審
OpenQodex 是面向 Claude Code 與 Codex 的開源推送前 AI 程式碼評審工具。一條 openqodex review 命令會圈定未推送提交與未提交改動,執行匹配的掃描器,只保留改動行上的發現,再由獨立評審程序核查,並用指令碼校驗後輸出 HTML、Markdown、JSON、SARIF 報告。無需額外金鑰、賬號或伺服器。
AI 編碼智慧體把寫程式碼的速度提了上去,卻沒有同步提高審查的速度。diff 越來越大,人眼越來越疲憊,真正有問題的那幾行很容易被淹沒在一堆看似合理的改動裡。OpenQodex 的切入點很樸素:把評審放到 push 之前,讓它成為你離開本地機器前的最後一道關。它面向 Claude Code 與 Codex 兩類智慧體,也可以直接在終端裡執行。核心只有一條命令,openqodex review。它先弄清楚你這次到底改了什麼:尚未推送的提交,加上所有未提交的改動。接著,它按改動檔案的型別挑選合適的掃描器去跑,並且只保留落在你改動過的那些行上的發現,舊程式碼裡的歷史包袱不會來打擾你。 掃描器的結果只是原料。OpenQodex 隨後會自己啟動一個評審者,也就是一個獨立的 Claude Code 或 Codex 程序,讓它去讀一份被凍結的改動副本。這個評審者要逐條核對掃描器的發現,同時會拿到每一行被改動的程式碼。它給出的答案不會被直接採信,OpenQodex 會用指令碼再檢查一遍,最後合成一份報告。這個設計的要點在於分工:規則型掃描器擅長穩定、可重複地發現模式,但誤報多、不懂上下文;語言模型擅長理解意圖和上下文,卻可能遺漏或編造。讓後者去裁決前者的每一條輸出,再由確定性的指令碼去核對後者的結論,三層互相牽制,比單獨依賴任何一方都更可信。 評審者的隔離程度,是這個專案最值得細看的部分。按 README 的說法,Claude Code 作為評審者時只帶讀取、搜尋和列目錄三類工具,執行在改動副本之內,不載入你的任何設定、鉤子、外掛、記憶或指令檔案。它的事件流會記錄每一次讀取,所以報告裡能列出它讀過哪些檔案。Codex 的情況略有不同:它在只讀沙箱中啟動,讀取範圍被限制在改動副本和系統目錄,命令沒有網路,也不載入你的配置、外掛、鉤子和倉庫裡的指令檔案。但文件也坦率承認兩點:它仍會載入全域性的 ~/.codex/AGENTS.md,而且它的事件流並不顯示每一條命令,因此報告只能寫明「讀取未被記錄」。把這類邊界寫進文件,比宣稱絕對安全更讓人放心,也提醒使用者按自己的威脅模型判斷。
「完整」在這裡有明確的定義。一次評審只有在三件事都成立時才算完成:每個階段都執行過;每一條掃描器發現都被評審者提出,或者帶著理由被丟棄;每一行改動都曾出現在評審者面前,可以是在任務簡報裡、在 OpenQodex 後續發來的訊息裡,或者對 Claude Code 而言,在它讀過的某個檔案裡。任何一條不滿足,工具都會列印「Review incomplete」,而不是給出一個看似圓滿的結論。這相當於把「覆蓋率」從口號變成了可檢查的條件。對於習慣了「LGTM」式含糊結論的團隊,這是一個值得借鑑的做法。 輸出同樣講究剋制。結束時終端會列印一張簡短的回執:結論、評審者的摘要、每條發現佔一行(編號、嚴重程度、類別、標題、檔案與行號),以及 report.html 和 report.md 的絕對路徑。完整報告同時落盤為 HTML、Markdown、JSON 和 SARIF 四種格式,SARIF 方便接入已有的安全工具鏈。report.html 是磁碟上的單個檔案,把每個改動檔案渲染成 diff,把每條發現掛在對應程式碼行下面,再附上覆蓋情況、掃描器清單和影響面。據 README,它不執行任何指令碼、不載入任何外部資源、轉義所有字串,並對掃描器發現的金鑰做脫敏。修復的決定權留給人:隨附的技能會讓智慧體先展示回執,再問「全部修復,還是告訴我修哪幾條」,只修你點名的發現,openqodex findings 1,3 可以把指定的發現完整列印出來。
接入成本很低。npx openqodex init 會在本機尋找 Claude Code、Cursor、Codex CLI 和 Cline,列出將要寫入的所有檔案並只詢問一次,然後指出它找到的評審者,或需要你修復的問題。它需要 Node 22 或更新版本和 git,支援 macOS 與 Linux,Windows 使用者需藉助 WSL,除已登入的 Claude Code 或 Codex 之外不需要任何其他金鑰、賬號或伺服器。除了預設的本地改動,它還能用 review --all 評審整個倉庫,或用 review 加分支名、加 '#42' 這樣的拉取請求編號,評審並不在你當前工作區的內容。當前版本為 0.12.0,採用 Apache-2.0 許可。
這種做法對日常開發流程的改變也值得一提。以往的程式碼評審大多發生在拉取請求開啟之後,評審者面對的是已經成形的提交歷史,作者的上下文早已散落。把評審挪到 push 之前,意味著問題在最便宜的時刻被發現:改動還在本地,作者記憶猶新,修復不會打斷任何同事。再加上所有掃描結果都被限定在你親手改過的行上,報告裡的每一條發現都與你此刻的工作直接相關,不必在歷史遺留問題裡翻找。對於由智慧體批次產出程式碼的團隊,這一步等於在提交與共享之間加了一道便宜而可靠的閘門,也讓人類審查者可以把精力留給架構取捨和業務判斷這類機器仍然難以替代的部分。 從行業角度看,它代表了一種正在成形的模式:評審不再是合併之後的流程,而是智慧體工作流裡的一個本地、可審計的步驟。當然也要保持清醒。讓同一家族的模型去評審同類模型寫的程式碼,可能共享盲區;Codex 路徑的可審計性明顯弱於 Claude Code 路徑;0.12.0 的版本號也說明它仍處於早期。我們引用的是公開的 README 節選,對未覆蓋的部分不做斷言。但它把「證據、覆蓋、人來決定」這三件事做進了產品的骨架,這一點值得每一個把智慧體接進日常開發的團隊認真對待。
Sources
FAQ
OpenQodex 的 openqodex review 到底評審哪些程式碼?
它評審尚未推送的提交加上所有未提交的改動,並只保留落在改動行上的掃描器發現。用 --all 可評審整個倉庫,加分支名或 '#42' 這類編號可評審不在當前工作區的分支或拉取請求,它會把目標取到臨時資料夾裡評審。
評審者和你的本地環境隔離到什麼程度?
據 README,Claude Code 評審者只帶讀取、搜尋、列目錄工具,在改動副本內執行,不載入你的設定、鉤子、外掛、記憶或指令檔案,事件流可列出讀過的檔案。Codex 在只讀沙箱中執行、命令無網路,但仍會載入全域性 ~/.codex/AGENTS.md,且讀取不會被完整記錄,報告會如實說明。
什麼情況下評審會被判為不完整?
只要有一個階段沒跑完,或某條掃描器發現既沒被提出也沒被帶理由丟棄,或某行改動沒有出現在評審者面前,工具就會列印「Review incomplete」,而不是給出看似圓滿的結論。