在不影响发布的情况下分诊失败的翻译

在多语言发布中，“失败”并不是单一状态。

模型请求可能失败。翻译可能已经完成，但无法推送到 Contentful。已本地化的条目可能已更新但尚未发布。把这三种情况都归为同一个红色状态，会让仪表板更简单，却会让恢复工作更困难。

从失败阶段开始

翻译、推送和发布是彼此独立的操作，并且依赖关系不同。

翻译失败可能源于提供商超时、模型响应无效，或受保护内容验证失败。推送失败可能涉及权限、字段验证，或 Contentful 版本冲突。发布失败可能反映条目状态、环境配置，或发布模式的问题。

第一个分诊筛选应该回答：哪个阶段需要关注？

这会立即缩小责任归属和后续步骤的范围。

展示影响范围

一个失败的请求需要足够的标识信息来支持决策：

• 条目名称和 ID
• 源语言区域设置和目标语言区域设置
• 批次
• 失败阶段
• 最近一次错误
• 尝试次数和最后一次尝试时间
• 后续阶段是否曾经开始

如果没有这些上下文，操作人员就只能逐个打开每个请求，手动重建整个发布过程。

批次视图还应区分部分失败和完全失败。如果 50 个语言区域中有 49 个成功，团队应该能够在恢复一个请求的同时，继续推进已经完成的工作。

从正确的边界重试

重试应该从失败的阶段继续，而不是重复之前每个已经成功的阶段。

如果翻译成功而推送失败，就应保留已审核的翻译并重试推送。如果 Contentful 已更新而发布失败，就应针对当前条目状态重试发布。

从翻译阶段重新开始可能会产生不同的文案、使审核失效、增加成本，并掩盖原始问题。

按阶段感知的重试可以让成功的工作保持稳定。

区分瞬时故障和永久故障

有些失败很适合自动重试：

• 提供商超时
• 速率限制
• 短暂的网络中断
• 可恢复的版本冲突

另一些则需要人工处理：

• 无效的内容配置
• 缺少语言区域启用
• 权限被拒绝
• 无法恢复的受保护结构
• 审核后目标字段发生变更

重试策略应该有明确的上限，并且可见。达到自动重试上限后，请求就应该进入人工队列，同时保留最后一条有用的错误信息。

让失败列表保持轻量

运维界面通常是在事情已经出问题时使用的。它们不应为每一行触发深度 CMS 数据补全，也不应轮询得过于激进，以至于页面制造的负载比它监控的工作进程还大。

应先返回稳定的请求元数据。只有当操作人员打开请求时，才获取完整的条目详情。

快速筛选本身就是恢复的一部分。

要点

一个红色徽章并不是恢复系统。

按阶段区分失败，展示受影响的范围，并且只重试失败的那个操作。在明确的限制内自动处理瞬时恢复，并为其他所有情况保留可操作的错误信息。当工作流让下一步决策变得显而易见时，团队就能够容忍个别失败。