OpenRouter 測試 Claude Sonnet 與 Opus，Haiku 令選擇更複雜
OpenRouter 將 Claude Sonnet 與 Opus 連同 Haiku 5.5 一同測試，報告顯示三者在編程方面打成平手，挑戰了在所有情況下都使用最昂貴選項的理據。其 10 月 30 日的比較建議，日常工作使用 Sonnet 5.5、大量工作使用 Haiku 5.5，而失敗代價高昂的困難任務則使用 Opus 5.5。重要分別在於：完成一項界定清晰的任務，與在不確定任務中持續作出判斷，兩者並不相同。
根據該平台的 Claude model comparison，每個模型均通過其獲分配的編程練習。這項發現令按聲譽或預設設定選擇模型的團隊面臨壓力。同時，它亦留下了一個重要問題：何時較棘手的任務足以證明應升級至更強模型？
實際答案取決於模型出錯後會造成甚麼影響。被拒絕的分類、不正確的文件摘要，以及有缺陷的架構決策，後果各不相同。Sonnet 看來是合理的起點，而 Haiku 與 Opus 則服務於這個光譜的兩端。將它們視為可互換的選擇，會過度延伸現有證據；將其產品層級視為完整的採購指南，亦會錯失重點。
Claude Sonnet 與 Opus 測試在狹窄範圍內得出平手結果
OpenRouter 的結果支持在其測試過的任務中使用較便宜的模型，但未能證明它們在所有軟件工作上具備同等能力。
該平台描述了 11 個附有隱藏測試的編程問題，即模型在產生答案時無法檢視的檢查機制。每個模型均通過全部 25 次嘗試。另一項 Claude Code 練習亦由所有模型成功完成。OpenRouter 明確承認，這些任務規模小且規格清晰。
這項限定決定讀者應如何解讀這個標題結果。定義清楚的函式為模型提供可努力達成的目標；測試套件則提供外部驗證。這些條件合在一起，令成功較在開放式工程任務中更容易識別。
試想像實作一項已獲同意的計算，與決定企業實際需要哪種計算方式之間的分別。前者可以有明確的輸入、輸出及邊界情況；後者則需要解讀不一致的需求、找出缺失資訊，並察覺原始要求何時指向錯誤方向。
兩種活動都涉及推理，但對系統提出不同要求。通過實作測試，對第一種活動確實提供有用資訊；至於第二種活動，特別是在沒有人寫下正確答案時，則提供較少證據。
這個分別在軟件儲存庫內同樣重要。局部修正可以保持既有行為並通過現有檢查，卻忽略更廣泛的相依關係。相反，技術上令人印象深刻的重新設計，亦可能因改變其他團隊倚賴的假設而失敗。
因此，關鍵問題是評估是否與所委派的任務相似。對於例行程式碼生成，這項比較提供了令人鼓舞的證據；對於文件不完整的陌生系統，則仍有較多未解決之處。
此外亦應留意商業利益。OpenRouter 銷售模型存取服務，並在比較內容旁推廣其評估服務。這種關係不會令測量結果失效，但會令可重現的方法與獨立確認尤其重要。
這則消息是對模型層級較狹窄但更有用的挑戰。當任務有清晰終點時，付費使用更強模型不一定會改善可觀察到的結果。買方現在有具體理由質疑一刀切的預設選擇。
當一般任務佔應用程式工作量的大部分時，這種壓力會更大。看似在示範期間無關痛癢的模型選擇，可能成為反覆出現的營運決策。這項比較令決策更接近以量度得出的任務表現為依據。
Sonnet 的中間定位令一刀切預設選擇承受壓力
Sonnet 最有力的論點是，在團隊尚未知道哪些任務需要特別處理前，它可提供一個實用基準。
Anthropic 於 9 月 28 日推出 Sonnet 5.5，將其定位為適合有明確範圍的日常工作、錯誤修正及文件建立。其 Sonnet performance assessment 亦表示，Opus 在需要持續判斷的複雜、開放式工作上仍然更強。
這個定位大致符合 OpenRouter 的建議，但其含意需要審慎看待。預設選擇是針對尚未分類工作的起始假設；當任務顯示出意料之外的難度時，應能輕易修訂。
對工程經理而言，壓力落在模型選擇背後的政策上。將每項要求都交給 Opus，須解釋組織因此獲得甚麼額外好處；將所有工作都交給 Haiku，則須解釋將如何偵測失敗。
Sonnet 佔據這兩項責任之間的位置。它為團隊提供基準，用以衡量更強與更小模型的表現。當比較納入獲接受的結果、審核時間，以及修復錯誤所需工作量時，這個基準便會變得有用。
想像一個根據問題描述及會議記錄草擬更新內容的內部助手。大部分要求可能只是直接整合資訊；偶爾的要求則可能需要協調團隊之間互相衝突的承諾。單一模型政策會掩蓋這種差異。
以 Sonnet 作為預設，是一項營運選擇，而非聲稱 Sonnet 最能處理所有要求。該助手仍需要能識別衝突證據並要求額外審視的方法。否則，預設選擇便會成為未經檢視的上限。
同樣邏輯亦適用於程式碼審查。根據明確慣例檢查局部改動，與判斷新的驗證設計是否保留安全假設，兩者並不相同。將兩種活動都稱為「程式碼審查」，會令工作量看來比實際更一致。
對於想知道哪個 Claude 模型應擔任日常角色的讀者而言，任務邊界比附加於要求上的職稱更重要。開發人員可以提交例行工作，而一條簡短的管理問題亦可能需要大量判斷。
當團隊明確描述這些邊界時，Claude Sonnet 與 Opus 的討論便更可付諸行動。模型會收到甚麼資訊？甚麼構成可接受的答案？誰會發現失敗，又會多快發現？
這些問題亦說明 Sonnet 何時應失去其預設位置。若較小模型持續產出獲接受的結果，且審核工作量相若，基準應向下調整；若困難個案反覆需要介入，這些個案便應走另一條路徑。
這項組織變化不大，但影響深遠。模型選擇成為由證據支持、可修訂的營運政策，不再完全依賴採購時聽來最安全的產品名稱。
Haiku 改變委派工作的經濟效益，而非判斷的需要
當應用程式能將界定清晰的工作與依賴該工作作出的決策分開時，Haiku 便特別值得留意。
Anthropic 於 10 月 7 日推出 Haiku 5.5，並將其描述為適合頻繁、成本敏感任務的模型。其列出的用途包括摘要、分類、資料庫查詢及子代理，即處理較大型任務部分工作的受委派助手。這些角色見於其 Haiku workload guidance。
架構上的含意直接明確。一個助手未必需要以同一模型收集資訊，以及決定資訊代表甚麼。分開這些責任，便有機會將能力配對至實際工作。
以一個根據客戶意見準備簡報的假設產品規劃助手為例。其中一個組件可抽取要求並附上支持它們的段落；另一個則可協調互相矛盾的說法，並建議哪些事項值得關注。抽取步驟與建議步驟，需要不同程度的推理。
當委派產出具備可辨識結構，而且有低成本驗證方法時，較小模型便會變得吸引。較大的決策仍取決於所抽取段落是否準確、完整及相關。
因此，委派會將部分責任轉移至周邊應用程式。系統需要清晰的任務邊界、可靠的來源參照，以及處理缺失資訊的規則。沒有這些控制措施，一系列廉價步驟可能造成昂貴的誤解。
關鍵問題是，應用程式能否在不完全重做工作的情況下驗證受委派工作。將引述段落與來源核對相對直接；要確立助手已在一批文件中找出所有相關矛盾，則較為困難。
這正是知識工作流程提供有用比較之處。一個 searchable knowledge base 有助保存答案背後的材料。模型選擇則決定哪個助手處理這些材料，以及獲賦予多少判斷空間。
應透過這條完整鏈條評估 Haiku 的角色。一段看來流暢的簡短摘要，仍可能遺漏會改變決策的例外情況；結構化抽取亦可能看似有效，卻將主張連結至錯誤來源。
這些都是應量度下游接受程度，而非產出外觀的理由。若審閱者反覆重新打開文件以重建缺失的背景，表面效率其實已將工作轉移至人手。
反過來亦同樣重要。當任務範圍狹窄且結果容易核對時，處處使用更強模型可能浪費資源。單靠產品名稱無法證明其額外價值。
對比較哪個 Claude 模型適合受委派工作的團隊而言，Haiku 是可信的候選選擇。它最有力的理據來自清晰邊界與可量度的接受程度；最薄弱的理據則是以「較小任務自然更安全」的假設取代判斷。
這個分別令建議保持務實。Haiku 擴闊應用程式建構者可用的選項，但不會免除他們界定每個組件必須完成甚麼的責任。
Opus 必須透過所避免的失敗證明其價值
使用 Opus 的理據在於困難工作及避免返工，而非預期它會贏得每一個短篇基準測試。
Anthropic 於 9 月 22 日推出 Opus 5.5，並將其定位為適合高要求的編程及專業任務。其 Opus capability assessment 警告，基準測試的差距已愈來愈難作為現實差異的可靠指引。這些仍是開發商的評估，而非普遍保證。
這種表述有助解釋，為何一場界定清晰的編程平手結果並不能決定採購選擇。較強模型的價值可能在任務缺乏清晰規格時浮現；亦可能在早期錯誤改變後續工作方向時顯現。
設想一項涉及陌生服務且文件不完整的假設性遷移工作。助理必須找出既有行為、識別相依關係、維持相容性，並說明尚未解決的假設。成功提交修補程式只是任務的一部分。
即使模型迅速得出看似合理的解決方案，若它採用了錯誤的詮釋，仍可能帶來更多工作。審閱者其後需要重建其推理過程、找出錯誤假設，並撤銷相關改動。
真正相關的衡量標準，是取得獲接受結果的完整過程。當中包括模型的工作、人手監督、驗證及修正。單靠請求層面的比較，無法反映這些後果。
這並不代表 Opus 必然會在某項特定遷移工作中表現較佳，而是說明要證明使用它有理據，需要哪一類證據。買家應尋找的證據，是在具代表性的困難任務中，是否出現較少具重大影響的錯誤、更清楚地表達不確定性，或需要較少人工介入。
任務長度本身並非完美的替代指標。一份長文件可能包含重複內容及直接明確的問題；一項簡短請求，卻可能隱藏了有關權限、安全性或不相容業務要求的棘手決策。
更有力的訊號，是模糊性與後果的組合。助理是否需要自行發現何者重要？錯誤假設會否擴散？在輸出影響其他工作之前，審閱者能否可靠地發現問題？
在這些情況下，分配更多能力或屬合理。不過，這項分配仍需要來自機構自身任務的證據支持。高階模型不應永久獲得免於評估的待遇。
模型選擇所能達成的事亦有其限度。較強的助理無法補上缺失的授權，也無法令未經審閱的生產環境改動變得可接受。能力、權限及驗證仍是彼此獨立的要求。
就 Claude Sonnet 與 Opus 而言，這帶來一條比「簡單與困難」更精確的分界線。Sonnet 可作為一般基準；只有當工作反覆暴露出會影響最終成果的弱點時，Opus 才值得成為例外選擇。
這個標準亦可保障買家不會只為安心感而付費。問題變成 Opus 是否改變結果，或減少圍繞結果所需的工作；若兩者皆否，它在產品層級中的位置便欠缺實際理據。
編碼結果打成平手，可靠性及整合問題仍未解決
小型評估可以揭示機會，卻未必能衡量採用它的全部風險。
OpenRouter 的比較值得留意，因為它提出了一個實際的採購問題。不過，其結論仍取決於特定的一組任務、設定及成功準則。要由這組資料推展至生產環境政策，仍需要額外證據。
其中一項限制關乎涵蓋範圍。評估可以測試某個函數能否處理已界定的情況，卻可能大致未有衡量可維護性及未來相容性。通過所有現有檢查，並不代表每項重要要求都已獲涵蓋。
另一項限制關乎重複條件。重複執行一項範圍受限的任務，可以提供該項任務的一致性資訊，但不能取代對更廣泛陌生問題的測試。
當表面差異很小時，這些區別尤其重要。些微領先可能反映所選任務、執行環境或模型設定。買家不應把不大的分數差距轉化為永久排名。
周邊軟件同樣重要。模型可以表現出色，但應用程式可能錯誤處理其回應、遺失有用脈絡，或錯誤解讀工具結果。營運可靠性屬於整個系統。
OpenRouter 的獨立基準測量區分模型、供應商、搜尋引擎及工具預算。這種區分突顯買家面對的一個實際問題：更換模型，可能同時改變執行過程的其他部分。
例如，應用程式可能在切換模型時同步修改指示。若獲接受的結果有所改善，機構不能立即把改進完全歸因於模型本身。新指示或許解釋了部分差異。
比較供應商聲稱時，同樣需要這份審慎。Anthropic 有動機說明其整個產品系列的價值；OpenRouter 亦有動機令模型比較及路由更具實用性。兩種觀點均提供證據，但都不能取代獨立測試。
持懷疑態度閱讀，並不代表要否定任何一家公司，而是要把測量結果與圍繞它們建立的建議分開看待。所報告的編碼平手，是所述設定下的一項測量；建議的預設政策則是更廣泛的判斷。
最有力的內部審查，會檢視分歧而非只看整體分數。Haiku 在何處產生被 Sonnet 否決的答案？Opus 在何處發現遺漏的假設？哪些分歧實際改變了審閱者的決定？
這些個案所揭示的，比無差別的成功率更多。它們能顯示較強模型是否帶來有用判斷，還是僅僅寫出不同答案。
因此，尚未解決的問題是實際的：機構能否在不同模型之間分配工作，同時保留獲接受的成果？OpenRouter 提供了值得調查的理由，卻沒有為每個程式庫、文件集合或客戶互動提供通用答案。
下一批訊號應顯示建議在哪些情況下成立
若日常工作質素得以維持、困難任務的優勢變得可量度，而且較小模型的節省可在完整流程中保留，這項建議便會更有說服力。
未來數月首先值得留意的訊號，是針對較長、規格較少的任務所作的獨立測試。有用的報告應展示原始請求、相關限制、人手介入及最終驗收決定，並讓未成功的嘗試與成功示範一同可見。
若 Opus 在這些情況下持續減少具重大影響的錯誤，其保留角色便更有支持。若 Sonnet 在相若監督下能與之匹敵，採用較廣泛 Sonnet 預設方案的理據便會更強。
這個訊號很重要，因為故事尚未解決的部分關乎持續判斷。加入更多短練習可以擴大涵蓋範圍，卻不能直接回答 OpenRouter 留下的問題。
第二個訊號，是由團隊將範圍受限工作交給 Haiku 時所取得的生產環境證據。重要結果包括獲接受的答案、升級處理、審閱者修正，以及下游決策是否仍然準確。模型的貢獻應在其輸出進入更大流程後仍然可見。
若 Haiku 能維持這些成果，使用它處理超出偶發背景任務的工作之理據便會更強。若審閱者反覆修補遺漏內容或重建證據，這項建議便需要設下更窄的界線。
知識工作者可透過在 AI knowledge base 中保留來源材料及決策，讓這些證據更容易檢視。目的在於延續性：審閱者需要看到甚麼支持某個答案，以及為何出現例外。
第三個訊號，是模型選擇能否在整個應用程式中維持可靠。團隊應留意執行行為、成本核算，以及受委派結果處理方式的變化。若整合問題掩蓋了實際發生的事，再有利的模型比較亦會失去實際價值。
若這些營運細節變得可預測，按任務選擇模型便更容易維持。若它們仍不一致，團隊便需要權衡額外複雜性與分配請求所帶來的好處。
這些訊號合起來，會在建議最薄弱之處檢驗它們：檢視受限練習以外的工作、受委派輸出的質素，以及連接它們的系統之可靠性。當中沒有任何一項要求宣告整個 Claude 系列的永久勝者。
任何重新評估 Claude Sonnet 與 Opus 的人，應先由團隊已接受或拒絕的工作開始。納入一般請求，以及耗費審閱時間的棘手個案。比較答案前保留原始證據、界定驗收標準，並檢視模型在哪些地方出現分歧。然後再考慮 Haiku 能否承擔範圍受限的一部分，而不把隱藏工作轉嫁給審閱者。只在 Opus 的額外判斷帶來可觀察效益時保留它的角色，並在證據改變時修訂決定。有用的成果，是團隊能夠解釋、檢視及改進的模型政策。當你計算通往獲接受結果的整個過程後，哪些任務仍值得使用較強模型？
