模型服务选择
模型配置不是越复杂越好。能稳定使用官方 Claude 模型时，优先用默认方案；需要国内网络、团队审计或成本控制时，再考虑网关和自定义服务。
优先级
- 官方 Claude Code 账号：最简单，优先跑通学习路线。
- 企业云服务：Amazon Bedrock、Google Vertex AI、Microsoft Foundry 等适合团队合规场景。
- Anthropic 兼容 LLM Gateway：适合国内网络、团队统一接入、审计和成本控制。
- OpenAI 兼容模型服务：只能作为网关后端或实验方案，必须额外验证 Claude Code 工作流。
国内服务怎么选
国内模型服务商很多，但选择标准不是“谁便宜”或“谁回答快”，而是它能不能稳定承接 Claude Code 的 agent 场景。
- 个人学习：优先选已经适配 Claude Code 的 Anthropic 兼容网关。
- 团队开发：优先选可审计、可限额、可统一管理密钥的 LLM Gateway。
- 只想试国产模型：先做只读验证和小任务验证，不要直接上生产项目。
- 公司内网：让团队管理员确认协议、日志留存、密钥轮换、模型路由和数据合规。
选择服务时看这张表：
| 标准 | 为什么重要 |
|---|---|
| Anthropic Messages 兼容 | Claude Code 工作流更依赖这类语义 |
| 工具调用稳定 | 读写文件、运行检查、diff 解释都依赖工具链 |
| 长上下文 | 项目分析、跨文件修改、代码审查需要上下文 |
| 流式输出稳定 | 长任务不中断，体验更可控 |
| 错误信息清楚 | 排障时能知道是额度、网络、认证还是模型问题 |
| 密钥和审计 | 团队场景必须可管理、可轮换、可追踪 |
看到“兼容 OpenAI API”时，不要默认它就兼容 Claude Code。Claude Code 需要的不是普通聊天接口，而是能支持工具、长上下文和 Anthropic Messages 语义的完整链路。
不要猜模型名
模型名、Base URL 和 API Key 必须来自服务商控制台或官方文档。猜出来的模型名即使能请求，也可能能力不稳定、上下文不足或工具调用不兼容。
模型能力分层
- 强模型：适合 Plan Mode、跨文件改造、架构判断、复杂 Bug 和代码审查。
- 中等模型：适合文档、简单页面、小范围重构、错误解释和模板生成。
- 快速便宜模型：适合翻译、摘要、命名、格式整理，不适合独立改复杂代码。
如果一个网关同时提供多个模型，可以把强模型留给规划和审查，把便宜模型留给简单说明。但新手阶段不要频繁切换，先固定一个稳定模型跑通完整流程。
不同阶段怎么选
| 学习阶段 | 推荐选择 |
|---|---|
| 刚安装 | 官方或最稳定配置 |
| 学 Plan Mode | 强模型，保证计划质量 |
| 做文档和模板 | 稳定中文模型即可 |
| 修真实 Bug | 强模型或团队主力模型 |
| 提交前审查 | 尽量使用质量最高的模型 |
| 大规模重构 | 不建议用未验证网关 |
不要频繁切模型
新手阶段最容易把“模型不稳定”和“任务没说清楚”混在一起。建议先固定一个稳定配置，完整跑通：
安装 -> 模型验证 -> 只读分析 -> Plan Mode -> 小修改 -> diff -> /verify
只有当同一套提示词在简单任务里也频繁失败，再考虑切换模型。不要每个任务都换一次服务商，否则很难判断问题来自模型、网关、网络还是任务描述。
让 CC 帮忙整理配置清单
请帮我整理 Claude Code 模型配置清单。 我准备使用的服务商是：【服务商】 请告诉我需要确认： 1. Provider 类型。 2. Base URL。 3. Model 名称。 4. API Key 应该放在哪里。 5. 这个服务是否只提供 OpenAI 兼容接口，还是支持 Anthropic Messages。 6. 是否支持工具调用、流式输出、长上下文和模型列表。 7. 哪些信息不能写进项目文件。 8. 配置后如何做只读验证。 不要编造服务商参数，不确定就写“需要去控制台确认”。
服务商变更前的检查
切换模型服务商前，让 CC 先做风险检查：
我准备切换 Claude Code 模型服务商，请先帮我做风险检查。 请判断： 1. 新服务是否支持 Claude Code 需要的协议和工具能力。 2. 是否需要迁移 Base URL、模型名和密钥。 3. 是否会影响已有配置档。 4. 是否需要保留官方或旧配置作为备用。 5. 切换后用什么只读任务验证。 6. 不要输出或保存真实 API Key。
选错模型的信号
- 能聊天，但不会正确读项目。
- 经常把不存在的文件当成事实。
- 工具调用失败后不解释原因。
- diff 解释和实际文件不一致。
- 稍微长一点的任务就丢上下文。
- 代码审查只会泛泛建议，没有具体风险。
出现这些信号时，优先切换到更稳定的模型或官方配置，不要把问题都归咎于提示词。
验证模型不要直接上真实项目
切换模型后，先做三个小验证：
| 验证 | 通过标准 |
|---|---|
| 只读项目分析 | 能准确说出目录、入口、脚本，不编造文件 |
| 小范围修改计划 | 能限制改动范围，给出验收方式 |
| diff 审查 | 能指出具体文件和真实风险，不泛泛而谈 |
这三步都稳定，再进入真实项目任务。
验收结果
- 你知道默认官方模型优先。
- 你知道企业云和网关适合团队。
- 你知道国内模型必须先确认协议和能力。
- 你知道自定义模型必须做只读验证。