---
title: 无需重新部署，让应用持续使用更好的 AI 模型
description: 更强、更便宜的 AI 模型不断涌现。使用 Haimaker 更新已部署应用背后的模型，无需发布新的移动端版本或更改服务器配置。
date: 2026-09-16T00:00:00.000Z
location: 加利福尼亚州旧金山 – 2026 年 9 月 16 日
image: /images/change-ai-models-without-redeploying-hero.jpg
keywords: '无需重新部署即可更换 AI 模型, 动态 AI 模型路由, 移动应用 AI 模型, AI 模型升级'
faq:
  - question: 如何在已发布的移动应用中更换 AI 模型？
    answer: >-
      让应用调用你的后端，由后端向 Haimaker 发送 model:
      'haimaker/auto'。之后你可以在控制台中更改路由器的默认模型或提示词规则，而无需提交新的移动端构建。路由器更改最多需要 60 秒生效。
  - question: 通过 Haimaker 切换模型是否需要重新部署服务器？
    answer: >-
      不需要。如果已部署的服务器已经在发送 model: 'haimaker/auto' 并使用了分配给路由器的 API
      密钥，你可以在控制台中更改路由器的目标模型。对应用提示词、请求格式或代码的更改仍然需要常规部署。
  - question: 能否只将简单的提示词迁移到更便宜的模型？
    answer: >-
      可以。为简单任务添加一条包含 3 到 10 个示例提示词的规则，并选择一个更便宜的目标模型。Haimaker
      会检查目标模型是否支持该请求，而未匹配任何规则的提示词将使用路由器的默认模型。
locale: zh-cn
translationKey: change-ai-models-without-redeploying
---
更强、更便宜的 AI 模型不断涌现。发布应用时选用的模型，几周后可能已不再是最佳选择。但如果该模型的 ID 写死在已发布的 iOS 应用或已部署的服务器中，每次升级都意味着又一次发版。用户还在使用旧版本，怎么让应用用上最新模型？**Haimaker 让你无需重新部署即可更新应用所使用的模型。** 将 `haimaker/auto` 作为模型 ID 发送，然后在控制台中更改默认模型或针对特定提示词的规则。

每次有新模型发布，这个问题都会重现。开发者需要针对自己的业务场景测试质量、成本和能力。将模型选择放在已部署代码之外，就能根据这些结果灵活调整，而不用安排又一次应用或服务器发版。

## 固定的模型 ID 在发布后会过时

固定的模型 ID 让每次模型升级都依赖于应用的发布流程。开发第一版时这还不算大问题，但上线之后，每一个有潜力的新模型或价格变动都可能意味着改代码、跑测试、部署服务器或提交移动端更新。新模型随时可能在两次发版之间出现。

对于 iOS 应用，嵌入在客户端中的模型 ID 无法为尚未更新的用户改变。[Apple 会在分发前审核应用更新](https://developer.apple.com/app-store/review/)，而且用户可能在新版本上线后很长时间仍停留在旧版本。将 API 调用移到后端可以避免在应用中暴露提供商密钥，但后端中硬编码的模型 ID 仍然需要改配置或重新部署。

仅靠网关端点并不能解决问题。如果请求指定了固定的模型，调用方仍然被绑定在那个选择上。例如，OpenRouter 支持命名模型以及其自身的 [`openrouter/auto` 路由器](https://openrouter.ai/docs/guides/routing/routers/auto-router)。自动路由器可以将底层模型选择排除在已部署代码之外。Haimaker 则让你在应用发布后，针对自己的提示词类别调整路由策略。

## 已部署的应用如何跟上新模型？

从应用发送一个稳定的模型 ID，把选择策略交给 Haimaker。路由器有一个默认模型用于处理未匹配的请求，还有规则将特定类型的提示词发送到其他模型。路由器绑定在一个 API 密钥上。当你更改其目标时，后续请求就能到达不同的模型，即使已部署的调用方仍然发送 `haimaker/auto`。

对于移动端产品，应用应调用你的后端，由后端调用 Haimaker，这样可以避免将 API 密钥暴露在用户设备上。服务端应用可以直接使用同样的模式：请求代码保持不变，运维人员在控制台中调整路由器即可。[设置文档](https://docs.haimaker.ai/docs/auto_router)介绍了如何创建路由器、选择默认模型、分配 API 密钥以及测试请求。

```js
import OpenAI from "openai";

// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
  baseURL: "https://api.haimaker.ai/v1",
  apiKey: process.env.HAIMAKER_API_KEY,
});

const response = await client.chat.completions.create({
  model: "haimaker/auto",
  messages: [{ role: "user", content: prompt }],
});
```

上面的代码在默认模型更改时不需要换模型名称。Haimaker 会缓存路由器配置[最多 60 秒](https://docs.haimaker.ai/docs/auto_router)，因此控制台中的修改大约需要一分钟才能对所有后续请求生效。

## 更新默认模型，再将低成本任务单独路由

更改默认模型会升级整体工作负载。当新模型对某项任务更便宜或效果更好时，规则允许你做更精细的调整。这种区分很重要：一个应用可能需要能力强的默认模型来处理长文本编辑，同时将简短的标题建议发送到成本更低的模型。这两个决策都可以在发布后更改，而无需改变调用方的模型 ID。

设想一个写作应用，后端通过同一个路由器发送所有 AI 请求。一个新发布的模型提升了长文本编辑效果，团队测试后更改了路由器的默认模型。之后，一个更便宜的模型足以胜任标题建议。团队添加了一条规则，包含"为这篇笔记建议五个简短标题"和"给这篇草稿拟一个简洁的标题"等示例，然后将该规则指向更便宜的模型。使用旧版本应用的用户通过现有后端即可享受到这两项改进。

对于[基于示例的规则](https://docs.haimaker.ai/docs/auto_router)，每个任务使用 3 到 10 个代表性提示词。匹配的请求会被路由到规则的目标模型；未匹配的请求使用默认模型。能力检查会防止规则将视觉、工具调用或结构化输出请求发送到无法处理的模型。[路由日志](https://docs.haimaker.ai/docs/auto_router)会显示实际路由到的模型以及选中该模型的规则。关于匹配和回退机制的详情，请参阅我们的[路由详解](/blog/auto-router-v2-smart-routing/)和[成本路由指南](/blog/cost-optimization-routing-ai-requests/)。

## 这对上线后的团队意味着什么？

最大的好处是模型选择可以跟随实际工作负载而非发版日历。团队可以采用新的默认模型、将重复性提示词类别迁移到更便宜的模型，或者在效果变差时恢复之前的目标。服务器代码和已安装的移动端客户端继续发送相同的 API 请求，团队只需把精力放在测试和审查路由决策上。

| 上线后的变更 | 代码中固定模型 | 使用 haimaker/auto |
| --- | --- | --- |
| 出现更好的通用模型 | 更改模型 ID 并发布代码或配置 | 测试后更改路由器的默认模型 |
| 更便宜的模型适合某类提示词 | 添加应用路由逻辑并部署 | 为该提示词类别添加或编辑规则 |
| 模型变更导致输出质量下降 | 回滚代码或配置变更 | 恢复之前的路由器目标 |
| 用户仍在使用旧版移动端构建 | 嵌入的模型 ID 保持旧值 | 后端可以使用当前的路由器策略 |

当服务器发版有其他无关工作排队时，这也很有帮助——模型决策不必等那个部署窗口。通过将不同的路由器分配给不同的 API 密钥，可以为不同的工作负载使用独立的路由器；Haimaker 支持[每个密钥一个路由器](https://docs.haimaker.ai/docs/auto_router)。

路由变更仍然需要与代码变更同样的审慎判断。控制台沙箱可以显示某个提示词会命中哪个模型，但它不能证明输出质量是好的。用代表性提示词对拟采用的模型进行测试，检查实际输出，关注已解析模型的日志，如果质量下降就回退到之前的目标。Haimaker 改变的是模型选择；更改提示词、工具 schema 或应用行为仍然需要应用层面的工作。

## 为下一次发版做好模型选择的准备

创建一个路由器，选择默认模型，并将其分配给后端使用的 API 密钥。在请求中发送 `haimaker/auto`，然后测试几个代表业务场景的提示词。当新模型到来时，先用这些提示词对其进行评估，再决定是否更改默认模型或针对特定场景的规则。[Haimaker 文档](https://docs.haimaker.ai/docs/auto_router)涵盖了路由器设置、测试沙箱和路由历史。

新模型可能在下一次发版之前就到来。将模型选择交给 Haimaker，应用就能始终用上最新模型，而开发者可以把发版周期留给真正需要新代码的变更。

## 常见问题

#### 如何在已发布的移动应用中更换 AI 模型？

让应用调用你的后端，由后端向 Haimaker 发送 model: 'haimaker/auto'。之后你可以在控制台中更改路由器的默认模型或提示词规则，而无需提交新的移动端构建。路由器更改最多需要 60 秒生效。

#### 通过 Haimaker 切换模型是否需要重新部署服务器？

不需要。如果已部署的服务器已经在发送 model: 'haimaker/auto' 并使用了分配给路由器的 API 密钥，你可以在控制台中更改路由器的目标模型。对应用提示词、请求格式或代码的更改仍然需要常规部署。

#### 能否只将简单的提示词迁移到更便宜的模型？

可以。为简单任务添加一条包含 3 到 10 个示例提示词的规则，并选择一个更便宜的目标模型。Haimaker 会检查目标模型是否支持该请求，而未匹配任何规则的提示词将使用路由器的默认模型。

<a href="https://app.haimaker.ai/sign-up?utm_source=blog&utm_medium=cta&utm_campaign=change-ai-models-without-redeploying_end" class="cta-button">设置 HAIMAKER</a>