Claude Opus 4.7 寫 code 有幾勁？SWE-bench、debug 同 refactor 邊界

判斷 Claude Opus 4.7 寫 code 有幾強，唔應該停喺佢可唔可以生一段 function。真正貼近工程現場嘅問題係：放入既有 repo 後，佢讀唔讀得明上下文、識唔識修真 issue、工具調用會唔會亂、長 workflow 會唔會愈做愈歪。Anthropic 已推出 Claude Opus 4.7，官方頁列明開發者可以透過 Claude API 使用 claude-opus-4-7；CNBC 亦有報道今次模型推出。

現有公開資料嘅答案幾清楚，但唔係無邊界：Opus 4.7 喺寫 code 同 debug 任務上證據好強；至於大型 refactor，暫時未見獨立、專門、標準化嘅公開 benchmark 可以單獨證明佢有幾強。

先講結論：coding／debug 值得優先試，refactor 要自己驗

TNW 報導稱 Claude Opus 4.7 是 Anthropic 最強一般可用模型，並列出 SWE-bench Pro、SWE-bench Verified、CursorBench 以及多步驟 agentic reasoning 的提升。 呢批數據足以支持一個實務判斷：如果你要模型幫手寫功能、修 bug，或者畀 coding agent 喺多檔案項目入面跑完整 workflow，Opus 4.7 係值得排前面試嘅選項。

但如果你問：大型 codebase refactor 到底比其他模型好幾多？講法就要收斂。可查來源主要講 software engineering、SWE-bench、agentic workflow 同長時間任務，無提供一個清楚拆出大型 refactoring 品質嘅獨立 benchmark。

寫 code、debug、refactor，唔好撈埋講

一個 coding model 識寫新 function，唔代表一定識修既有 bug；識修 bug，亦唔代表佢做出嚟嘅大型重構會令 reviewer 放心 merge。

能力	你真正要問嘅問題	目前公開證據
寫 code	能否理解需求、跟到既有 API、項目結構同 coding style，產出可 merge 嘅功能	證據強：TNW 報導 Opus 4.7 喺多個 coding／agentic benchmark 上高過 Opus 4.6。
Debug	能否讀懂錯誤訊息、logs、traces 同 failing tests，搵到根因並修真實 issue	證據偏強：SWE-bench Pro 被描述為測試模型解決開源項目真實軟件問題嘅能力；Anthropic 官方頁亦收錄早期用戶對 bug finding 同 fix proposal 嘅正面評語。
Refactor	能否喺唔改變行為嘅前提下，改善結構、命名、抽象邊界同可維護性	證據未定：可查來源未列出專門量度 refactoring 品質嘅獨立公開 benchmark。

最硬淨嘅公開數據：SWE-bench 同 CursorBench

TNW 報導嘅 benchmark 數據，係目前判斷 Opus 4.7 coding 能力最具體嘅公開材料之一。

指標	Claude Opus 4.7	對照數字	點樣解讀
SWE-bench Pro	64.3%	Opus 4.6：53.4%；GPT-5.4：57.7%；Gemini 3.1 Pro：54.2%	SWE-bench Pro 被描述為測模型解決開源項目真實軟件問題嘅能力，比純演算法題更接近日常 issue 修復。
SWE-bench Verified	87.6%	Opus 4.6：80.8%；Gemini 3.1 Pro：80.6%	喺 TNW 報導嘅 verified software engineering 任務上，Opus 4.7 明顯高過前代同文中列出嘅主要對照模型。
CursorBench	70%	Opus 4.6：58%	對代理式 coding workflow 嘅提升明顯，唔只係單輪補幾行 code。
多步驟 agentic reasoning	比 Opus 4.6 提升 14%	工具錯誤約降至 Opus 4.6 嘅三分之一	對需要工具調用、跨步驟操作、長流程工程任務嘅場景更有參考價值。

呢啲數字嘅重點係：Opus 4.7 嘅強項唔止係識寫 code，而係喺更接近真實工程環境嘅任務入面，處理 issue、工具同多步驟流程都更有競爭力。 不過，benchmark 分數唔等於你團隊會得到同等效率提升；資料集、工具權限、test coverage、項目規模同 reviewer 標準，都會改變實際結果。

Debug：證據比 refactor 更實在

Debug 嘅核心唔係將 error message 丟畀模型，然後收一段睇落合理嘅 patch。更重要係模型能否定位正確檔案、理解程式路徑、只改最小必要範圍，並避免引入 regression。SWE-bench Pro 呢類以真實開源項目問題為基礎嘅任務，所以比一般 coding puzzle 更能反映 bug fix 能力。

Anthropic 官方發布頁亦將 Opus 4.7 放喺進階軟件工程同複雜長時間任務嘅脈絡下介紹，並列明開發者可透過 Claude API 使用呢個模型。 官方材料中收錄嘅早期用戶評語，包括 Replit 指出它喺分析 logs and traces、finding bugs、proposing fixes 方面更有效率同準確。

呢度要分清來源性質：早期用戶評語來自官方發布材料，唔等同獨立第三方盲測。 所以較穩陣嘅講法係，Opus 4.7 對從真實 repo issue 產生修補嘅證據偏強；但如果你關心 live debugging、某個特定 framework 嘅疑難雜症，或者大型 monorepo 入面跨服務錯誤，仍然要用自己嘅任務集驗證。

Refactor：值得試，但未到可以拍心口講最強

大型重構比修 bug 更難量度。Test pass 只代表行為大致無壞，唔代表抽象邊界更清楚、耦合更低、命名更一致，亦唔代表 reviewer 會覺得個 diff 易睇、易收貨。

就可查來源而言，Anthropic 官方發布同 TNW 報導都集中喺 coding、SWE-bench、agentic workflow 同長時間多步驟任務；但未有提供清楚、獨立、專門拆分大型重構品質嘅公開 benchmark。

因此，對 refactor 能力最負責任嘅判斷係：Opus 4.7 好值得優先試，因為佢喺真實 issue 修復、工具使用同多步驟 workflow 上嘅底層能力有明顯提升；但呢個仍然係間接證據。 如果大型重構係你團隊核心工作，應該直接測行為保持、test pass rate、diff 可 review 性、命名一致性同後續維護性，而唔係只睇通用 coding 排行榜。

一般可用最強，唔等於 Anthropic 所有模型絕對最強

TNW 將 Opus 4.7 稱為 Anthropic 最強一般可用模型；Anthropic 官方頁亦列出 claude-opus-4-7 可透過 Claude API 使用。 但一般可用唔等於 Anthropic 任何內部或受限模型之中能力最高。

Alpha Spread 報導指出，Anthropic 稱 Opus 4.7 仍 broadly less capable than Claude Mythos Preview；CNBC 亦以 Opus 4.7 與 Mythos 的取捨作為報道角度。 換句話講，如果你問目前一般可用嘅 Anthropic coding 模型是否應該優先評估 Opus 4.7，公開證據支持將佢排得好前；但如果你問佢係咪 Anthropic 全部模型入面絕對最強，現有來源唔支持咁講。

如果要引入，點樣做 A/B test

公開 benchmark 可以幫你決定值唔值得試，但唔能夠替你證明喺你自己 codebase 一定最好。如果要將 Opus 4.7 放入 IDE、內部 coding agent 或 Claude API workflow，最好用同一份 repository snapshot 做對照測試。

建議分三類任務測：

1. 功能開發：畀同一份需求同同一個項目狀態，睇模型能否產出可 merge 嘅 diff。
2. Debug 修復：提供 failing test、錯誤 log 或 issue 描述，評估佢搵根因、控制修補範圍同避免 regression 嘅能力。
3. Refactor 任務：要求模型喺保持行為不變嘅前提下改善結構，再由工程師評估可讀性、test pass rate、diff 可 review 性同維護性。

評分時，至少記錄 test 有無過、需唔需要人工回退、有無工具調用錯誤、reviewer 會唔會接受修改，以及模型能否講清楚設計取捨。呢啲會比一次 demo 更接近真實引入效果。

Bottom line

Claude Opus 4.7 喺寫 code 同修真實 repo 問題上，公開證據相當強：TNW 報導嘅 SWE-bench Pro、SWE-bench Verified、CursorBench 同多步驟 agentic reasoning 數據，都支持佢比 Opus 4.6 有明顯進步，並且喺報導中列出嘅主要對照模型之間具競爭力。

對 debug，可以講證據偏強，因為 SWE-bench 類任務同官方早期用戶評語都指向更好嘅 bug 修復同工程 workflow 能力。 對 refactor，就應該保持保守：目前可查來源未有提供獨立、專門、標準化嘅 refactoring benchmark；如果大型重構係你嘅核心工作，仍然要用自家 codebase 做 A/B test 後再決定是否引入。