Higgsfield 图片生成超时，其实早已完成

屏幕上显示的是 Timeout after 6m0s; last status "in_progress"（等待 6 分钟后超时，最后状态为“处理中”）。

任务运行器把这张图记为失败。没有任何文件下载下来。在我这边看来，任务已经没戏了。

这几件事凑在一起很危险，因为重新生成看起来成了理所当然的下一步。命令失败了，磁盘上没有图片，队列也已经等了 6 分钟。很容易就会以为 Higgsfield 根本没完成。

这个判断会让我再花 1 个积分。

任务并没有丢。Higgsfield 仍在服务器上处理，后来完成了，完整图片就在那里，最初那 1 个积分也已经扣掉了。

失败的是等待结果的客户端，不是生成本身。

一个标签掩盖了两种状态

我的运行器把结果标记为 FAIL。

这个标签在技术上有用，但范围太宽。它只告诉我，命令没能走完预期的本地流程，却没告诉我原因。

这条命令原本要等待 Higgsfield，接收完成后的结果，再下载图片。远端状态还停在 in_progress 时，6 分钟的等待上限就到了。下载步骤没有执行，运行器于是记录为失败。

但超时并没有取消服务器上的任务。Higgsfield 还在继续工作。

这就造成了本地和远端状态的错位。我的文件夹显示图片缺失，服务器显示任务最终完成。计费记录跟着服务器走，不会因为我的文件夹里空着就不扣费。

如果我把每次本地失败都当成生成失败，就会为已经完成的工作再付一次钱。

重新生成之前，我先查了服务器

找回图片的第一条规则是：先别重新提交任何任务。

我列出了最近的 20 个生成任务：

generate list --size 20

超时的任务就在这些记录中。从本地运行器的角度看，它成了一个无人跟进的任务。创建它的命令已经停止等待，远端任务却继续执行，只是本地进程没有再跟到完成。

在最近任务列表里找到已完成的任务，还不能告诉我哪个下载文件对应那张缺失的图。我需要把服务器的结果与磁盘上已有的图片逐一核对。

于是，我把最近任务中每个可用 URL 对应的图片下载下来，计算 MD5 哈希值，再与项目文件夹中已有图片的哈希值比较。

匹配上的，都是我已经有的图片。

唯一没有匹配任何本地图片的，就是那张缺失的生成结果。

找回过程就是这样。我没有改写提示词，没有重新生成，也没有再花 1 个积分。我排除了磁盘上已有的所有结果，由此确认了远端那张已完成的图片。

这次找回的成本是 0 积分。

状态决定处理办法

超时和审核拒绝可能被算进同一个失败总数，但处理方式不同。

如果超时时最后状态仍是 in_progress，说明客户端停止了等待，不能证明服务器停止了生成。下一步应该查看最近任务，并与已下载的文件核对。

审核拒绝并返回 status: nsfw 则不同。这种任务需要修改提示词后重新尝试。最近任务列表里并没有一张已完成的图片等着找回。

把这两种结果不加区分地塞进 FAIL，会让人采取错误的行动，把本可补回的下载变成第二次付费生成。

真正有用的问题不是“我的命令失败了吗？”，而是“远端任务最后到了什么状态？”

这是两个不同的问题。

为什么只看文件名不够

找回图片靠的是内容比对。

最近任务列表里有多个结果，本地文件夹里也有多张图片。单看列表，只能知道有任务完成了，无法确定哪一张是本地漏掉的。

MD5 比对给出了可重复核验的答案。服务器图片的哈希值只要与本地文件相同，就说明它已经在手里。那个匹配不上的哈希值，指向的就是已完成、却没有在超时命令执行期间下载下来的图片。

几次生成时间相近时，这一点尤其重要。有用的证据不是运行器最后给出的标签，而是服务器最近的结果与磁盘上实际文件之间的对应关系。

服务器记录说明 Higgsfield 完成了什么，哈希值说明我已经拿到了什么。两者的差集，就是需要找回的内容。

我现在遵循的规则

在证实生成失败之前，我只把超时视为等待失败。

看到 Timeout after ...; last status "in_progress"，我会先停下来，不急着重新提交。我查看最近任务，下载结果 URL 对应的文件，将它们的 MD5 哈希值与磁盘图片比较，找回没有匹配上的文件。

只有确认遭到拒绝，例如 status: nsfw，我才回头改提示词。

今天就可以查一下你的运行器或笔记，看看哪些地方把超时和审核拒绝放进了同一条 FAIL 处理路径。在下一张超时图片让你付两次钱之前，把它们分开。

---

这篇文章里的每个解决办法，都是先犯了错才换来的。错在我的电影里，总比错在你的品牌上好。