在 SlopCodeBench 上對 Opus 5 進行基準測試

長期編碼基準測試揭示模型退化

**當前的前沿 LLM（包括 Opus 5）目前仍無法被依賴用於 "lights-off" 軟體工程，因為它們在需求演變時難以維護代碼品質。**儘管 Opus 5 相較於其前身僅有微幅改進，但它仍無法在不引入缺陷或增加技術債的情況下完成複雜的多階段編碼挑戰。

多數傳統編碼基準測試會一次性提供完整的問題陳述，這會獎勵能夠解決當時問題的模型。相對地，SlopCodeBench（由 UW Madison 的研究者於 2026 年 3 月提出）透過多個「檢查點」來測試模型演變代碼庫的能力。模型會逐步接收需求，迫使它調整現有代碼以適應新規範——這個過程與真實世界的軟體工程相符。

Opus 5 在 SlopCodeBench 上的表現

**Opus 5 在 SlopCodeBench 的一個子集上達到了 24% 的嚴格通過率，相較於原始論文中報告的 Opus 4.6 的 17% 率略有提升。**然而，「嚴格通過」指標——要求所有新測試必須通過且所有繼承的回歸測試必須保持綠色——揭示了顯著的限制。

在跨越 17 個檢查點（涵蓋簡單、中等和困難問題）的測試中，結果如下：

• Opus 5: 4/17 次嚴格通過 (24%)
• Opus 4.8: 1/17 次嚴格通過 (6%)
• Sonnet 5: 1/17 次嚴格通過 (6%)

儘管通過率較高，Opus 5 表現出對「昂貴冗長」的傾向。它編寫的函數數量是 Opus 4.8 的五倍，且總代碼行數顯著增加（約 29,000 行，而其他模型僅約 9,000 行）。這部分體積主要用於編寫測試，但生產代碼量的增加並未帶來正比例的正確性提升。

量度「Slop」：代碼品質與複雜度

**SlopCodeBench 使用 41 個確定性指標來追蹤代碼庫退化，顯示所有測試模型的複雜度會隨時間增長。**這些指標被分類為大小、複雜度（例如循環複雜度）、重複、分解和規則違反。

代碼品質的主要發現：

• 複雜度增長： 沒有任何模型能在不增加跨檢查點複雜度的情況下完成挑戰。Opus 4.8 展現了最極端的退化，其最糟的函數達到了循環複雜度 93。
• 代碼重複： Opus 4.8 的重複率從 4.6% 上升至 16.8%，因為新需求與初始設計衝突。Opus 5 的重複率保持相對平穩（2.41% 至 2.64%），這表明它在處理結構變化時略有改進。
• Slop 密度： 大量代碼行觸發了「slop rules」（衡量冗長和不良模式的指標）。在三個問題中，Opus 5 的 93% 代碼行被標記。與經人工審查的 AI 生成 TypeScript 單體倉庫相比，Opus 5 的「lights-off」生成代碼每千行代碼（kLOC）的 slop 觸發次數超過 11 倍。

維護 AI 代碼的道路

**SlopCodeBench 上的高失敗率表明，維護代碼庫的能力與解決單一編碼任務的能力是不同的技能。**為了提升軟體品質的信號，作者提出一種「交付」評估：讓前沿模型（如 Opus 5 或 Fable）編寫前 N 個檢查點，然後測試較小的「較笨」模型（如 Sonnet 5）是否能成功實作檢查點 N+1。

如果較小的模型無法在較大模型的工作基礎上進行構建，這就強烈表明較大的模型未能維護乾淨且可維護的架構。

社群觀點與反駁

從業者的討論表明，結果可能受到代理 harness 和系統提示的影響，而不僅僅是模型的原始能力。

"當代理能夠觸碰任何東西時，slop 會累積；因此，將其限制在一個接縫上並讓其旁邊添加而非就地編輯，比模型選擇更為重要。"

其他使用者指出，儘管 Opus 5 在速度和 token 效率方面相較於 4.8 有所改進，但它可能不像早期版本或其他專門模型（如 Fable）那樣是一次「革命性」的飛躍。

基準測試挑戰摘要

挑戰	難度	重點
circuit_eval	簡單	命令列介面、布林邏輯、向量訊號、三值邏輯、優化
database_migration	中等	SQLite 遷移、資料轉換、外鍵、回滾
dynamic_config_service_api	困難	REST API、版本控制、模式註冊、變更管理工作流程