器库yueser.com

给长任务加断点续跑

收录 2026-11-06

跑三小时的任务挂掉,不该从第一秒重来。

我有一个耗时很长的批处理任务:[任务、单次规模、失败情况]。请帮我设计断点续跑:1)确定 checkpoint 的粒度(按批、按文件、按时间),并说明如何权衡开销;2)设计状态记录格式:已完成、处理中、失败项、幂等键;3)说明「处理中」的条目在崩溃后如何判定与重做;4)给出并发与乱序下避免重复处理的办法;5)说明旧 checkpoint 与代码变更不兼容时怎么办(版本号/失效策略);6)给出验收方式:模拟中断后验证结果与一次跑完一致。
本站原创

中文原文

复制前替换这些占位符 1

把方括号里的内容换成你的具体信息,替换后再粘贴给 AI。

  • [任务、单次规模、失败情况]
使用建议

断点信息要包含幂等键,否则重跑就是重复处理。

可以这样改

  • 要求它先复述需求与约束,确认无误再写代码。
  • 让它给出最小改动 + 回滚方式,而不是整文件重写。

交付物(这次应拿到什么)

  • 可运行的最小改动(含直接可用的代码块)
  • 影响面清单:改了哪些文件、哪些调用点要跟着改

常见错法

  • 一次让它改十个文件,最后分不清哪处改动导致了新问题。
  • 只贴报错不贴代码和版本,拿到无法落地的修法。

输出验收(怎么判断能用)

  • 改动可运行、可回滚,且没顺手改无关代码。
  • 边界条件(空值、超长、并发)有说明或测试。

适用场景与注意

  • 适合:让它先复述需求和约束,再给最小可运行改动。
  • 注意:贴报错时同时给版本号与最小复现,否则它容易给出看似合理但不适配的写法。

所属合集

同方向的其他提示词