文章 / 工程方法

AI 任务超时后，先别点重试：防止重复执行的五个检查

2026-10-12 · 温舒 · Codex 辅助整理

以假设的文章生成与发布场景，说明请求编号、结果待核对、幂等和失败恢复；附五项故障检查与官方来源。

背景与范围

下面是一份 AI 应用的工程设计清单，采用“生成文章并提交发布”的假设场景说明。它不是已交付客户项目的复盘，也不包含未经测试的性能结论。

用户点击生成文章，页面等了很久，最后提示超时。最直观的处理是再点一次。但第一次请求可能已经被服务端接受，甚至已经产生了结果。前端没收到响应，只能证明响应链路没有按时完成，不能证明业务动作没有发生。

如果任务还包含计费、图片生成或对外发布，直接重试就可能产生两份结果。把“超时”和“失败”写成同一种状态，是这类问题的常见起点。

我建议在提交前生成一次操作编号，并把它与账号、内容版本和动作类型关联。用户刷新页面后，应继续查这个编号，而不是立即创建一个新的任务。

这与幂等请求的思路一致：同一次意图的重试，使用同一个请求标识。AWS Builders’ Library 的相关文档介绍了调用方提供唯一请求标识的设计，并讨论了服务端原子记录请求与修改结果的重要性。

注意，不是正文一样就一定是同一次操作。同一篇文章发往不同平台，或者用户确实要制作第二个版本，应有不同的业务编号；同一编号却换了参数，则应报冲突，不能静默覆盖。

一个简单的任务列表可以区分：待处理、执行中、待核对、已确认成功、已确认失败。

这里最关键的是“待核对”。它适用于请求可能已送达、但尚无明确回执的情况。界面应告诉用户下一步是查任务或平台内容列表，而不是一律显示“失败，重新生成”。

示例：文章发布请求超时后，先查询平台后台是否已有对应稿件；有稿件就保存平台记录编号。没有查询入口时，挂起并人工核对，而不是靠再次点击碰运气。

只读查询通常比创建任务更容易安全重试，但也应遵守平台限制。涉及生成费用或发布动作时，需要先确认服务端是否支持幂等、幂等标识能保留多久，以及远端是否能按任务编号查询。

本地的“我没有记录到结果”，不等于远端没有执行。尤其是程序崩溃发生在“远端完成、本地尚未保存”的间隙，简单的文件去重并不能提供跨系统的一次且仅一次保证。

Celery 文档建议任务函数具备幂等性，并说明了消息确认与执行时机的关系。启用延迟确认或自动重试，不会替业务代码消除重复副作用。

对于普通 AI 内容任务，一个可实施的起点是：数据库唯一约束保护业务编号，工作者领取任务时带租约，完成后保存结果引用，超时后进入核对流程。以上是设计建议，具体事务与恢复策略仍要按数据库和平台接口验证。

1. 连续点击两次提交，是否只产生一个逻辑任务？ 2. 请求发出后立即断网，恢复后能否找回原任务？ 3. 远端成功、本地保存前退出，是否会再次创建或发布？ 4. 同一编号改了正文，系统是否明确提示参数冲突？ 5. 平台显示“审核中”，本地是否错误显示成“已发布”？

这些测试比只验证“成功生成了一次”更接近真实交付。验收时保留请求编号、远端记录编号、时间和状态；日志不要保存访问密钥或完整登录凭据。

问：加一个“按钮置灰”就够了吗？答：它能减少当前页面的重复点击，但挡不住刷新、网络重发或多台设备同时操作。

问：所有超时都不能自动重试吗？答：不是。要看动作有没有副作用、是否具备可靠幂等协议和可查询回执。结果已知与结果未知，需要不同处理。

问：只要用了队列就稳定了吗？答：队列解决任务调度的一部分问题。内容正确性、权限、重复执行、失败恢复和发布回执仍需分别验证。

我关注 AI 产品从演示走向可用工具的工程细节。公开文章与自用实验记录：https://wenshu.tnyma.com/

外部文档用于说明规则；本项目的产出与限制以案例及日志中的实际记录为准。