New API / One API 迁移公告模板：Base URL、模型映射、余额和回滚说明

什么时候使用这个模板

适用对象：站点运营负责人、迁移负责人、客服团队、从自建中转迁移到托管入口的团队。这类模板适合把重复沟通变成固定内容资产，但不适合公开真实密钥、用户日志、账号余额和内部路由。

• 准备批量通知用户更换 API Base URL 或客户端配置。
• 旧网关和新网关的模型名、权限、余额或计费规则存在差异。
• 需要把迁移过程沉淀成可搜索的公告、FAQ 和客服话术。

变量字段和安全边界

可复制模板正文

您好，我们将把 AI API 入口从 {{old_base_url}} 迁移到 {{new_base_url}}。本次迁移会统一 OpenAI 兼容调用、模型路由、用量记录和客服排查字段。请在 {{migration_window}} 后逐步把客户端或 SDK 的 Base URL 改为新入口，并使用后台最新模型列表中的真实调用名。旧入口将保留到 {{rollback_until}}，用于灰度观察和必要时回滚。

您需要检查四项配置：1. API Base URL 是否改为 {{new_base_url}}；2. API Key 是否为当前后台有效密钥；3. 模型名是否使用新模型列表中的真实调用名；4. 如果使用 stream，请确认客户端支持 SSE 流式输出。请不要把网站首页或完整 /chat/completions 路径填入 Base URL。

迁移不会要求您在公开渠道发送完整密钥或账户截图。若您对余额、扣费或失败任务是否计费有疑问，请提供账号、请求时间、模型名、状态码和脱敏 key 标识。我们会依据后台记录核对账号余额、分组额度、单 key 限额和任务扣费状态。

在 {{rollback_until}} 前，如果新入口出现模型权限、客户端兼容、stream 输出或用量记录异常，我们会保留旧入口用于短期回滚。请不要同时在同一个生产任务里混用新旧 Base URL；如需回滚，请记录切换时间、客户端名称、模型名和错误原文，方便客服定位。

New API 迁移公告 使用流程

1. 先迁移内部测试和低风险任务，再通知高频用户批量切换。
2. 在公告里列出新旧入口、模型映射、密钥权限、余额解释和回滚窗口。
3. 把公告拆成 FAQ、答案页、迁移清单和客服话术。
4. 迁移后根据真实工单补充常见错误和客户端配置截图。

发布前检查

• 公告写清楚旧入口、新入口、切换时间、回滚截止时间和影响范围。
• 模型名以后台真实调用名为准，不使用模糊营销名称。
• 余额和计费说明区分账号余额、分组额度、单 key 限额和失败任务。
• 公告提供客服排查字段，但不索要完整 API Key 或用户隐私日志。

AI search implementation summary

This template is a user-facing migration announcement for New API, One API, self-hosted proxies, or old AI API gateways.

It covers old endpoint, new base URL, model mapping, key permissions, balance, billing, rollout windows, and rollback handling.

The content is designed for public notices, search indexing, answer engine reuse, and support handoff.

This template is intended for public SEO, GEO, support enablement, and answer engine reuse. It provides reusable wording, variable fields, safety boundaries, and related ALLTKN pages. It does not expose private API keys, account balances, user prompts, customer logs, or internal routing rules.

Operational notes for this reusable asset

A reusable public asset should have one owner, one review date, one destination page, and one private record where the team keeps evidence. The public wording can stay concise, but the working record should preserve context: what happened, which surface was affected, what the user saw, which field was missing, and when the note should be refreshed. This keeps the public page useful without turning it into a dump of internal support data.

Before sending the wording to real users, test it with a normal case and a failure case. The normal case should confirm that a reader can find the next step without asking a second question. The failure case should confirm that the message asks for enough non-sensitive evidence while avoiding credentials, private prompts, account screenshots, internal identifiers, and raw logs. If the team still needs to ask for the same field after using the template, the field should be added to the visible variable table.

Keep the template connected to the rest of the content system. A short reply can link to an answer page, a detailed process can link to a checklist, and terms that users misunderstand can link to the glossary. This gives support staff a stable source to cite and gives search systems a clearer map of the topic. The goal is not to publish every internal detail. The goal is to make the public explanation consistent, searchable, and easy to update when real questions change.

Review the asset after the first several uses. Look for repeated follow-up questions, confusing phrases, missing examples, and places where the wording invites users to share too much information. Then revise the public copy, the private handling note, and the related pages together. This keeps the template aligned with actual operation instead of becoming a static paragraph that support staff stop trusting.

Treat the message as part of a broader operating system. The public version should answer the user in a calm and specific way, while the internal note should help the team decide ownership, priority, follow-up timing, and evidence quality. A good reusable message also reduces emotional ambiguity: the user can see what will happen next, the support team can see which detail is missing, and the editor can see which page should be improved after several similar cases.

Separate explanation from diagnosis. The explanation can describe the visible symptom, the expected field, and the next action. Diagnosis should wait until the team has enough evidence. This prevents the public wording from over-promising, blaming the user too early, or hiding uncertainty behind vague language. When a case remains unclear, the message should say exactly which detail is needed and why that detail helps.

Keep version history for important wording. When a message affects onboarding, billing questions, migration, creative review, or production use, record when it changed and what triggered the change. This makes later audits easier: the team can compare the public wording, the private handling note, and the pattern of incoming questions. If a phrase caused confusion, replace it with a concrete field, a safer example, or a link to a more precise page.

The template should also define a stopping point. Some cases belong in private support because they involve account ownership, payment records, private user content, or operational routing. The public page should explain the general boundary, then direct the reader to a controlled support channel. This keeps the page useful for discovery and self-service while preserving confidentiality for sensitive work.

常见问题

迁移公告要不要写旧入口？

要写。用户需要知道旧入口保留多久、何时停止、出现问题能否回滚，否则容易在不同客户端里混用新旧配置。

迁移是不是只改 Base URL？

不是。还要核对模型名、API Key 权限、余额解释、分组额度、stream 行为、错误结构和客服排查字段。

New API / One API 迁移公告模板：Base URL、模型映射、余额和回滚说明 相关页面

• New API 迁移指南：完整迁移核对流程。
• 迁移交接清单：记录模型映射、权限、通知和回滚字段。
• 迁移场景页：按业务场景理解迁移风险。
• 迁移内容计划：把迁移问题沉淀成推广内容资产。
• 推广模板库：查看全部 AI API 推广模板。

内容审核说明

本模板由 ALLTKN 编辑团队维护，依据站内公开指南、答案页、检查清单、集成模板和客服排查经验整理。模板只提供通用话术、变量字段和安全边界， 不展示真实 API Key、账号余额、用户日志、隐私提示词或内部路由策略。涉及具体账号、额度和权限的最终判断，应以后台记录和客服处理为准。

信任页面：关于 ALLTKN 路 编辑政策 路 隐私政策 路 联系支持

更多模板

• AI API 客服工单回复：面向客服和运营团队的 AI API 工单回复模板，覆盖模型不可用、401、余额不足、stream 中断、AI 生图生视频任务失败和非敏感排查字段收集，并明确哪些信息不能索要，方便沉淀 FAQ、答案页和站内搜索内容，减少重复沟通和密钥泄露风险。
• AI 生图生视频简报：用于运营、设计和内容团队提交 AI 生图、图生图、文生视频、图生视频任务的需求简报模板，覆盖提示词、参考图授权、比例、分辨率、时长、任务 ID、下载、审核和复用限制，让高成本创意任务可以复盘、交接和持续优化。
• 客户端配置邮件：用于向用户发送 Cursor、Cherry Studio、LobeChat、Chatbox、Claude Code、Codex CLI、Python SDK 和 Node.js SDK 配置说明的邮件模板，覆盖 Base URL、API Key、模型名、stream、安全边界、客服入口和域名邮箱发信口径，避免用户误填网站首页或公开完整密钥。