嗨，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 代码审查重点关注围绕一个编码表面的代码仓库范围、会话控制、差异检查和人工切换。