測試設置與比較方法

開發者 leok7v 在 GitHub 專案 ChatOKF（一個 Swift 語言的裝置端 LLM 聊天應用）中，對一個包含約 48 個檔案變更、新增 1048 行及刪除 102 行的程式碼提交進行審查。該提交涉及模組移動及新增一個 783 行的搜尋測試框架。

本地模型 Qwen3.8-Flash-Next 使用 UD-Q4_K_XL 量化版本，透過 llama-server 在 AMD Strix Halo 128GB 記憶體系統上運行，支援 ROCm 環境及 262K 上下文長度，並啟用 MTP draft head。該模型由 Claude Code 本身以無頭模式驅動，僅使用唯讀工具。

作為比較基準的審查者是 Claude (Opus)，它在 Claude Code 中先進行盲審，然後將 Qwen 的審查結果與程式碼進行比對判斷。開發者承認由 Claude 評估其競爭對手存在偏見，但所有發現均已透過原始碼驗證，主要發現還附有小型 Swift 重現範例。

審查結果對比：發現與遺漏

Qwen3.8-Flash-Next 產出了 8 個發現，全部為真實問題且無誤報。它成功捕捉了兩個 Claude 未發現的問題：一個是不遵循應用召回路徑的測試框架，另一個是將 Markdown 標頭中的分隔符號「---」誤認為描述的處理錯誤。

然而，Qwen 錯過了五個由 Claude 發現的問題，其中最重要的是停用詞過濾器比較詞幹化單字與未詞幹化列表的邏輯錯誤，導致「this」和「does」等詞彙洩漏成為搜尋詞。此外，模型還對可失敗初始化的確切回退行為以及欄位數量計算有兩處細節錯誤。

開發者指出，Qwen 在嚴重性校準及標記為「已檢查且無問題」的部分表現良好，並能像謹慎的人類一樣閱讀完整檔案並追蹤模組邊界。

執行成本與效能數據

整個審查過程耗時 41 分鐘，經歷 53 輪對話，上下文長度增長至約 110K tokens。在 4K 上下文長度下，解碼速度約為每秒 21 tokens；當上下文長度達到 128K 時，速度降至每秒約 14 tokens。

預填充（prefill）速度從每秒 520 tokens 下降至每秒 230 tokens。多令牌預測（MTP）技術在上下文長度達 64K 之前可提供約 1.5 倍的加速效果，但超過約 100K 後反而成為效能負擔。

技術限制與設定注意事項

執行時需啟用 --lazy-mode 選項，否則 27 GiB 的 n-gram 嵌入表將載入 RAM 而非保持記憶體映射狀態。此外，unsloth 提供的 MTP heads 會導致 llama.cpp 崩潰（觸發 GGML_ASSERT in set_input_k_idxs），原因是 GGUF 檔案中 MTP 層的壓縮比率為 0，開發者提供了修復分支連結。

Claude Code 會在對話中途發送系統訊息，而 Qwen 的聊天模板對此會拋出錯誤。因此需要覆蓋模板設定，使其能將該訊息渲染為系統輪次。

結論與適用範圍

開發者總結認為，Qwen3.8-Flash-Next 可作為一個可信賴的初步審查工具，適合在夜間隱私環境下運行，但使用者在採取行動前應驗證其機制，且不應將其視為微妙邏輯的最終判斷依據。

由於此測試僅基於單一程式碼提交的單次執行，開發者強調這應被視為個案經驗而非標準化基準測試結果。