大模型能力接入业务系统之后，很多团队会发现一个此前从未遇到过的问题：模型服务本身也可能成为故障点。接口限流、模型版本升级导致的输出风格突变、服务商临时不可用，这些情况都会直接冲击线上业务。传统的灾备方案关注的是服务器、数据库和网络，而现在，Prompt层面的灾备设计同样重要。一套设计良好的灾备Prompt体系，能够在主模型异常时自动切换备用模型、在多模型之间做容错编排、在极端情况下优雅降级，保证业务不中断。
为什么Prompt也需要灾备设计
很多团队把Prompt当作一段静态文本，写在配置文件里就不再维护。这种做法在单一模型、单一服务商的环境下问题不大，但一旦业务对多个模型有依赖，或者需要在多个服务商之间做切换，Prompt的脆弱性就会暴露出来。不同模型对同一段Prompt的响应差异可能非常大：有的模型对系统角色的遵循度高，有的则更看重用户消息中的指令；有的模型支持JSON模式输出，有的只能靠提示词约束格式。
Prompt灾备的本质，是让提示词体系具备可切换、可降级、可回滚的能力。具体来说包含三个层面：第一是内容层面的兼容性，即同一套业务意图能够用适配不同模型的表达方式描述；第二是结构层面的解耦，把Prompt模板、业务变量、模型参数分离管理，避免改一处动全身；第三是运行层面的容错，当主模型输出不符合预期时能够自动重试或切换。只有这三个层面都设计到位，业务连续性才有保障。
一个常见的反面案例是：某团队为模型A精心调优了Few-shot示例，输出质量很好。后来模型A接口限流，临时切换到模型B，结果输出格式完全失控，下游解析程序大量报错。问题不在于模型B能力不行，而在于那套Prompt本身是为模型A量身定制的，没有做兼容性设计。
主备模型切换场景下的Prompt设计
主备切换是灾备中最典型的场景。设计思路是维护一套与模型无关的抽象指令，再针对每个候选模型维护差异化的适配层。抽象指令描述业务意图、输出结构、约束条件，适配层则处理各模型的特性差异，比如角色标签的支持程度、JSON输出的约束方式、上下文窗口的限制等。
下面是一个Python示例，展示了如何用模板加适配器的方式实现主备切换：
import json
# 与模型无关的抽象指令模板
BASE_PROMPT = """
你是一个企业客服助手。请严格遵守以下规则：
1. 只回答与产品相关的问题
2. 每次回复必须包含字段：answer、confidence、need_human
3. 无法确定答案时，将need_human设为true
用户问题：{question}
"""
# 针对不同模型的适配器
class PromptAdapter:
def render(self, question: str) -> list:
raise NotImplementedError
class ModelAAdapter(PromptAdapter):
def render(self, question: str):
# 模型A支持system角色，输出用json_object模式
return [
{"role": "system", "content": BASE_PROMPT},
{"role": "user", "content": question}
]
class ModelBAdapter(PromptAdapter):
def render(self, question: str):
# 模型B不支持system角色，指令合并进user消息
return [
{"role": "user",
"content": BASE_PROMPT.format(question=question)
+ "\n请只输出JSON，不要输出其他任何文字。"}
]
def call_with_failover(question, primary, backup, adapter_map):
"""主备切换：主模型失败或输出非法时自动降级"""
for model in [primary, backup]:
try:
result = model.invoke(adapter_map[model.name].render(question))
data = json.loads(result)
if "answer" in data:
return data
except (json.JSONDecodeError, KeyError, TimeoutError):
continue
# 全部失败，走降级回复
return {"answer": "系统繁忙，请稍后再试或联系人工客服。",
"confidence": 0, "need_human": True}
这段代码的关键点在于两点。一是Prompt渲染的职责交给了适配器，业务逻辑不感知模型差异，切换时不需要修改业务代码。二是call_with_failover函数在切换之前会先做输出校验，切换的触发条件不只是接口报错，还包括输出格式非法这种软故障。软故障往往比硬故障更隐蔽，如果没有格式校验，切到备用模型后业务可能带着错误数据继续运行，造成更难排查的问题。
在提示词内容层面，主备两套Prompt应保持指令结构一致、表达方式各自优化。建议将输出格式约束写成模型无关的描述，例如统一要求JSON字段名小写、禁止在JSON外包裹Markdown代码块，这些约束在绝大多数模型上都能生效。
降级策略与兜底回复的提示词写法
当主备模型都不可用时，系统需要进入降级模式。降级不是简单地返回一句报错，而是要保证用户体验的连续性。常见的降级分三级：一级降级是切换到更小更稳定的轻量模型，用简化版Prompt处理简单问题；二级降级是走检索匹配，从历史高质量回复库中找相似问答；三级降级是固定话术加人工入口。
一级降级的简化版Prompt值得特别说明。轻量模型的指令遵循能力通常弱于大模型，Prompt要做针对性的减法：减少多任务叠加、缩短指令链、Few-shot示例从五个减到两个、输出字段只保留必需项。示例如下：
【轻量模型降级版Prompt】
你是客服助手。规则：
1. 只回答产品相关问题
2. 回复格式：{"answer": "..."}
3. 不确定就回复：这个问题需要人工处理
示例：
问：怎么退货？
答：{"answer": "登录后在订单页点击申请退货，7天内有效。"}
二级降级依赖向量检索，此时提示词的角色从生成指令变成了匹配辅助。可以在历史问答入库时就用统一的Prompt生成标准化的问法变体，提高检索命中率。这个预处理Prompt同样需要纳入灾备管理，因为一旦入库格式变化，整个检索库都要重建。
三级降级的固定话术也需要提示词层面的配合。话术要提前告知用户当前状态、给出替代路径、设置恢复预期，比如说明预计恢复时间、提供人工客服入口。这些内容看似简单，但建议由产品与运维共同评审后写进配置，而不是工程师临时手写，避免故障时刻的慌乱措辞引发用户不满。
Prompt的版本管理与灰度回滚机制
灾备不只是故障发生时的切换，还包括故障发生后快速定位和回滚的能力。Prompt每次修改都应该像代码一样纳入版本管理，记录修改原因、影响的模型、验证结果。推荐用Git管理Prompt模板仓库，配合CI流程在每次变更时自动跑一批回归用例，比对输出是否符合预期结构。
灰度发布同样适用于Prompt。新版本Prompt先对5%的流量生效，观察输出质量指标和用户反馈，确认稳定后再全量。回滚时只需将配置指向旧版本标签，秒级生效。下面是一个简单的配置结构示例：
{
"prompt_versions": {
"customer_service": {
"current": "v2.3.1",
"canary": "v2.4.0",
"canary_ratio": 0.05,
"rollback_to": "v2.3.0",
"compatible_models": ["model-a", "model-b"]
}
},
"failover_rules": {
"triggers": ["timeout", "json_parse_error", "rate_limit"],
"max_retries": 2,
"circuit_breaker_threshold": 5
}
}
配置中compatible_models字段很重要，它声明了每个Prompt版本经过验证的模型列表。切换备用模型时，系统只允许使用该列表内的模型，防止未经测试的组合被推到线上。熔断阈值和最大重试次数则避免在模型服务整体异常时反复无效调用，加速进入降级流程。
最后要强调演练的价值。灾备Prompt体系搭好之后，应该定期做故障演练：人为停掉主模型、注入格式异常输出、模拟限流，验证切换和降级链路是否真的能跑通。很多团队的灾备方案在真实故障时失灵，原因就是从未演练过。把Prompt灾备纳入业务连续性计划的定期评审范围，与服务器、数据库的灾备演练放在同等地位，才能真正守住业务连续性的底线。