嗨，Lena 來了~ Claude Code Opus 5.5 是我會明確做出的模型選擇之一，而不是假設已經激活。原因很簡單：opus 別名在每個提供程序上的解析方式不同，並且恢復的 Claude Code 會話可能會使用之前使用的模型重新打開。

因此，在進行有實際意義的測試之前，我希望對齊三件事：Claude Code 顯示的當前運行模型、我授權它操作的代碼倉庫，以及用來評判試用效果的結果。

證據説明： Anthropic 於 2026 年 9 月 22 日宣佈 Opus 5.5。我於 9 月 24 日檢查了當前文檔。此處未安裝 Claude Code，因此下面的練習是可重現的過程，而不是完整的模型測試。

檢查訪問並更新Claude Code

從以下開始：

claude --version

Anthropic 表示 Opus 5.5 需要 Claude Code v2.1.280 或更高版本。如果您的安裝較舊，請運行：

claude update

然後再次檢查版本。如果安裝行為異常，claude doctor 是比反覆重新安裝或更改模型設置更有用的下一步。

型號可用性還取決於 Claude Code 背後的帳户。您需要符合條件的付費 Claude 計劃、控制台帳户或通過受支持的雲提供商進行訪問。一個免費的 Claude.ai 帳户本身是不夠的。

組織設置在這裏也很重要。如果 Opus 5.5 根本沒有出現，我會在假設本地 Claude Code 安裝已損壞之前檢查帳户、提供商和託管模型限制。

為會話選擇 Opus 5.5

使用當前模型選擇器

在 Claude Code 中，輸入：

/model

然後尋找 Opus 5.5。

Anthropic的Claude Code模型配置指南為選擇器提供了兩種略有不同的行為：

s 切換當前會話而不更改保存的默認值。
Enter 選擇模型並保存以供將來使用。

作為試用，我更喜歡s。我不希望評估會議悄悄改變我通常使用的模型。

您還可以輸入：

/model claude-opus-5-5

這將保存選擇。

有一個細節很容易被忽略：opus 是一個別名，而不是版本引腳。

在撰寫本文時，它映射到 Anthropic 的 API 上的 Opus 5.5、AWS 上的 Claude Platform、Amazon Bedrock 和 Google 的 Agent Platform，而 Microsoft Foundry 仍然以不同的方式解決它。如果練習的目的是專門評估 Opus 5.5，我會使用完整的模型名稱，而不是信任別名。

在 CLI 中使用完整型號名稱

對於 Anthropic 的 API 的新會話：

claude --model claude-opus-5-5

這會將模型應用於該啓動，而無需重寫您保存的默認值。

雲部署可能不太整潔。根據提供商的不同，等效項可能是推理配置文件 ARN、部署名稱或提供商特定的模型版本，而不是 Anthropic 的純模型字符串。在這種情況下，提供程序配置是測試設置的一部分，而不是要忽略的實現細節。

驗證哪個模型處於活動狀態

選擇模型後，運行：

/status

這是我信任的支票。它顯示活動模型、版本和帳户，並且配置的狀態行也可以公開模型。

這種區別很重要，因為要求 Claude Code 使用模型與證明會話實際上在模型上開始並不完全相同。組織許可名單、提供商配置、回退和恢復會話都會使該假設變得複雜。

如果 /status 顯示出意外的內容，請先停止並修復選擇。我不會嘗試根據模型的寫作風格、編碼行為或之前會話中記住的標籤來識別該模型。

我還將記錄提供商以及型號名稱。兩個會話可以顯示相似的人類可讀模型名稱，同時解析為下面不同的提供程序部署標識符。

給它一個小的、可逆的代碼倉庫任務

對於第一個測試，我會避免構建功能。

使用一次性代碼倉庫或沒有憑據等機密信息、生產憑據或客户數據的安全測試分支。首先確認工作樹：

git status --short

然後運行代碼倉庫的正常本地測試命令。一旦你知道起始狀態是健康的，就創建一個分支：

git switch -c trial/opus-5-5

這為您提供了一個清晰的比較點，而無需假裝 Git 分支是安全邊界。

有用的第一份簡介可能如下所示：

“在指定函數中為空輸入添加一個迴歸測試。僅在測試失敗時更改其實現。僅觸摸該函數和測試文件。不添加依賴項，不使用網絡，並在提交或推送之前停止。運行現有的本地測試命令；報告更改的文件和結果。”

在運行之前，我會用真實路徑、確切的函數名稱和已知的測試命令替換通用引用。

任務是故意無聊的。這很有用。

對於第一次模型檢查，我不太關心模型是否可以發明令人印象深刻的實現，而更關心它是否尊重範圍，注意到現有的測試結構，進行最小的必要更改，並在我告訴它停止的地方停止。

保持權限提示處於啓用狀態，並僅批准任務實際需要的內容。

查看差異，而不僅僅是測試結果

一旦 Claude Code 完成，我會檢查：

git status --short

git diff --check

git diff

Git 的當前 diff 文檔準確地解釋了這些比較所顯示的內容，但重要的審查仍然屬於您：模型是否觸及您允許的文件，以及更改是否確實與摘要相符？

這裏的一個陷阱是普通的 git diff 不顯示未跟蹤的文件。分別檢查它們，而不是將看起來乾淨的差異視為沒有出現任何其他內容的證據。

然後自己運行本地測試命令並記錄退出狀態。

通過測試是有用的證據，但這還不夠。模型可以通過所請求的測試，但仍然會創建不必要的文件、編輯約定範圍之外的內容或引入簡報明確排除的依賴項。

如果試驗無法通過審查，我將僅恢復實驗中涉及的文件，檢查並刪除任何新創建的文件，然後返回到起始分支。

即使扔掉代碼，也保留測試輸出。失敗的試驗通常比干淨的演示提供更多信息，因為它們顯示了模型忽略範圍或概要未指定的地方。

對於 EvoX 代碼審查，我帶來的產物很簡單：分支名稱、實際差異和測試日誌。本地 EvoX 材料可能支持代碼倉庫審查，但這並不意味着自動 Claude Code 會話切換。

返回正常模型

如果測試使用 s 或 --model，請啓動新的 Claude Code 會話而不進行覆蓋，然後再次運行 /status。

如果您在 /model 中按 Enter 鍵，請選擇正常型號（或默認值），然後按 Enter 鍵，以便選擇再次成為保存的默認值。

項目和組織設置仍然可以覆蓋用户級別的首選項，因此我將驗證新的會話，而不是假設重置有效。

稍後重新開庭審理時也是如此。恢復的 Claude Code 會話可以恢復與該早期會話關聯的模型。

常見問題解答

組織管理員可以限制用户在 Claude Code 中選擇哪些型號嗎？

是的。託管 availableModels 設置和企業控件可以限制模型選擇器中顯示的內容。

如果託管環境中缺少 Opus 5.5，請在對本地安裝進行故障排除之前先諮詢管理員。

項目能否在不更改用户全局默認值的情況下固定 Opus 5.5？

是的。項目的 .claude/settings.json 可以指定：

"model": "claude-opus-5-5"

當代碼倉庫有意在一個模型上標準化時，這很有用，儘管共享項目設置應與團隊其他成員一起審查。

對於一次性評估，我仍然更喜歡 --model，因為它保持全局默認不變。

恢復較舊的 Claude Code 會話是否會保留其原始模型？

通常，是的，當使用 Anthropic 的 API 時。

但也有例外。停用的模型、組織限制、顯式啓動覆蓋和特定於提供程序的部署行為可能會更改會話恢復時實際可用的內容。

這就是為什麼 /status 也屬於恢復測試的開始。

Opus 5.5 和其他 Claude 型號之間的使用限制有何不同？

Anthropic 宣佈 Pro、Max 和 Team 計劃的五小時使用限制更高，但沒有明確適用於每種工作負載的通用“每個模型 X 任務”數字。

使用/usage查看自己賬户的額度。我不會僅僅因為兩個模型在同一個選擇器中可用而假設它們相同地消耗該津貼。

Opus 5.5 是否可以通過每個受支持的雲提供商獲得？

Anthropic 列出了自己的平台：AWS、Google Cloud 和 Microsoft Foundry。

這並不意味着每個帳户、區域、部署或組織都會自動擁有訪問權限。提供程序命名也有所不同，並且 opus 別名不會在所有地方解析為 Opus 5.5。

為了進行真正的比較，請在開始判斷輸出之前驗證提供程序部署標識符和 /status 中顯示的模型。

往期文章：

如果您想要圍繞有界代碼倉庫任務構建另一個 Claude Code 工作流程，Obsidian Claude Code 庫到代碼工作流程展示瞭如何檢索受控上下文、將其應用到代碼、運行檢查以及僅在審核後寫回。
為了評估更強的推理設置是否真正改善代碼倉庫工作，Muse Spark 1.3 智能體推理比較了固定編碼任務下的完成質量、干預、延遲和任務成本。
如果您主要關心的是保持編碼智能體工作的可審查性，T3 代碼審查重點關注圍繞一個編碼表面的代碼倉庫範圍、會話控制、差異檢查和人工切換。