更强、更便宜的 AI 模型不断涌现。发布应用时选用的模型，几周后可能已不再是最佳选择。但如果该模型的 ID 写死在已发布的 iOS 应用或已部署的服务器中，每次升级都意味着又一次发版。用户还在使用旧版本，怎么让应用用上最新模型？Haimaker 让你无需重新部署即可更新应用所使用的模型。 将 haimaker/auto 作为模型 ID 发送，然后在控制台中更改默认模型或针对特定提示词的规则。
每次有新模型发布，这个问题都会重现。开发者需要针对自己的业务场景测试质量、成本和能力。将模型选择放在已部署代码之外，就能根据这些结果灵活调整，而不用安排又一次应用或服务器发版。
固定的模型 ID 在发布后会过时
固定的模型 ID 让每次模型升级都依赖于应用的发布流程。开发第一版时这还不算大问题，但上线之后，每一个有潜力的新模型或价格变动都可能意味着改代码、跑测试、部署服务器或提交移动端更新。新模型随时可能在两次发版之间出现。
对于 iOS 应用，嵌入在客户端中的模型 ID 无法为尚未更新的用户改变。Apple 会在分发前审核应用更新，而且用户可能在新版本上线后很长时间仍停留在旧版本。将 API 调用移到后端可以避免在应用中暴露提供商密钥，但后端中硬编码的模型 ID 仍然需要改配置或重新部署。
仅靠网关端点并不能解决问题。如果请求指定了固定的模型，调用方仍然被绑定在那个选择上。例如，OpenRouter 支持命名模型以及其自身的 openrouter/auto 路由器。自动路由器可以将底层模型选择排除在已部署代码之外。Haimaker 则让你在应用发布后，针对自己的提示词类别调整路由策略。
已部署的应用如何跟上新模型？
从应用发送一个稳定的模型 ID，把选择策略交给 Haimaker。路由器有一个默认模型用于处理未匹配的请求，还有规则将特定类型的提示词发送到其他模型。路由器绑定在一个 API 密钥上。当你更改其目标时，后续请求就能到达不同的模型，即使已部署的调用方仍然发送 haimaker/auto。
对于移动端产品，应用应调用你的后端，由后端调用 Haimaker，这样可以避免将 API 密钥暴露在用户设备上。服务端应用可以直接使用同样的模式：请求代码保持不变，运维人员在控制台中调整路由器即可。设置文档介绍了如何创建路由器、选择默认模型、分配 API 密钥以及测试请求。
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 秒，因此控制台中的修改大约需要一分钟才能对所有后续请求生效。
更新默认模型，再将低成本任务单独路由
更改默认模型会升级整体工作负载。当新模型对某项任务更便宜或效果更好时，规则允许你做更精细的调整。这种区分很重要：一个应用可能需要能力强的默认模型来处理长文本编辑，同时将简短的标题建议发送到成本更低的模型。这两个决策都可以在发布后更改，而无需改变调用方的模型 ID。
设想一个写作应用，后端通过同一个路由器发送所有 AI 请求。一个新发布的模型提升了长文本编辑效果，团队测试后更改了路由器的默认模型。之后，一个更便宜的模型足以胜任标题建议。团队添加了一条规则，包含”为这篇笔记建议五个简短标题”和”给这篇草稿拟一个简洁的标题”等示例，然后将该规则指向更便宜的模型。使用旧版本应用的用户通过现有后端即可享受到这两项改进。
对于基于示例的规则，每个任务使用 3 到 10 个代表性提示词。匹配的请求会被路由到规则的目标模型；未匹配的请求使用默认模型。能力检查会防止规则将视觉、工具调用或结构化输出请求发送到无法处理的模型。路由日志会显示实际路由到的模型以及选中该模型的规则。关于匹配和回退机制的详情，请参阅我们的路由详解和成本路由指南。
这对上线后的团队意味着什么？
最大的好处是模型选择可以跟随实际工作负载而非发版日历。团队可以采用新的默认模型、将重复性提示词类别迁移到更便宜的模型，或者在效果变差时恢复之前的目标。服务器代码和已安装的移动端客户端继续发送相同的 API 请求，团队只需把精力放在测试和审查路由决策上。
| 上线后的变更 | 代码中固定模型 | 使用 haimaker/auto |
|---|---|---|
| 出现更好的通用模型 | 更改模型 ID 并发布代码或配置 | 测试后更改路由器的默认模型 |
| 更便宜的模型适合某类提示词 | 添加应用路由逻辑并部署 | 为该提示词类别添加或编辑规则 |
| 模型变更导致输出质量下降 | 回滚代码或配置变更 | 恢复之前的路由器目标 |
| 用户仍在使用旧版移动端构建 | 嵌入的模型 ID 保持旧值 | 后端可以使用当前的路由器策略 |
当服务器发版有其他无关工作排队时，这也很有帮助——模型决策不必等那个部署窗口。通过将不同的路由器分配给不同的 API 密钥，可以为不同的工作负载使用独立的路由器；Haimaker 支持每个密钥一个路由器。
路由变更仍然需要与代码变更同样的审慎判断。控制台沙箱可以显示某个提示词会命中哪个模型，但它不能证明输出质量是好的。用代表性提示词对拟采用的模型进行测试，检查实际输出，关注已解析模型的日志，如果质量下降就回退到之前的目标。Haimaker 改变的是模型选择；更改提示词、工具 schema 或应用行为仍然需要应用层面的工作。
为下一次发版做好模型选择的准备
创建一个路由器，选择默认模型，并将其分配给后端使用的 API 密钥。在请求中发送 haimaker/auto，然后测试几个代表业务场景的提示词。当新模型到来时，先用这些提示词对其进行评估，再决定是否更改默认模型或针对特定场景的规则。Haimaker 文档涵盖了路由器设置、测试沙箱和路由历史。
新模型可能在下一次发版之前就到来。将模型选择交给 Haimaker，应用就能始终用上最新模型，而开发者可以把发版周期留给真正需要新代码的变更。
常见问题
如何在已发布的移动应用中更换 AI 模型？
让应用调用你的后端，由后端向 Haimaker 发送 model: ‘haimaker/auto’。之后你可以在控制台中更改路由器的默认模型或提示词规则，而无需提交新的移动端构建。路由器更改最多需要 60 秒生效。
通过 Haimaker 切换模型是否需要重新部署服务器？
不需要。如果已部署的服务器已经在发送 model: ‘haimaker/auto’ 并使用了分配给路由器的 API 密钥，你可以在控制台中更改路由器的目标模型。对应用提示词、请求格式或代码的更改仍然需要常规部署。
能否只将简单的提示词迁移到更便宜的模型？
可以。为简单任务添加一条包含 3 到 10 个示例提示词的规则，并选择一个更便宜的目标模型。Haimaker 会检查目标模型是否支持该请求，而未匹配任何规则的提示词将使用路由器的默认模型。