摘要
- OpenAI 于 7 月 22 日 07:32:04 UTC 开立事件，范围是文件上传与图像生成错误升高。
- 07:54 仍在调查；09:26:27 表示问题已识别，正在实施缓解。
- 本批固定截止为 09:40:04，因此文章事实状态只能是“已识别、仍在进行”。
- 09:44:41 的“缓解已应用、正在监控恢复”发生在截止之后。
- 截止时没有根因、受影响人数、错误比例、地区、数据丢失或与上一事件的因果联系。
故障页面会在报道成文后继续变化。最常见的失真不是数字错误，而是把后来出现的恢复信息写成客户当时已经知道的信息。
09:40 时，使用 OpenAI 的团队仍面对一个未完成的缓解过程。对它们而言，问题是是否继续上传文件、是否提交图像队列、是否切换流程。四分多钟后的更新不能替这些决策提前提供信心。
输入端和输出端同时被点名
文件上传是材料进入系统的入口，图像生成是某些工作流的最终出口。同一条事件记录覆盖两者，意味着任务可能在进入前失败，也可能在产生资产时失败。
OpenAI 没有列出产品、文件格式、地区或客户等级，也没有给出失败率。可以确认的是两项功能错误升高，不能写成每一次上传和生成都失败。
队列管理因此必须区分：上传被拒绝、请求已接受、处理状态未知、结果已生成但未返回。把所有未知状态一键重试，会造成重复资产、重复费用和审计困难。
功能复现不等于根因复现
新事件开始前约 4 小时 42 分钟，OpenAI 刚在 02:50 关闭另一条持续较长的 ChatGPT 图像生成事件。图像依赖用户很快再次进入不稳定期，这种时间接近具有运营意义。
但新事件还增加了文件上传，并使用独立事件编号和时间线。截止时 OpenAI 没有公开两次事件的共同原因，也没有证明此前的永久修复失效。
准确说法是图像功能附近再次发生事件，且影响面扩大；技术因果仍未知。
“仍在进行”是完整的新闻状态
报道不必等到事件解决才成立，只需公开截止边界并保持时态。本文冻结在 09:40:04。09:44 监控状态属于后续更新。
即使进入监控，也不等于已经解决。它只表示缓解已经应用，供应商正在观察恢复。客户仍应使用小规模合成请求，等待稳定窗口，再逐步释放积压。
文件和图像需要两套探测
从既有内容成功生成一张图，不能证明新文件可以上传；上传成功也不能证明图像链路可用。两条路径应分别测试，并记录请求标识和幂等信息。
在供应商事件期间，低频小探针比整批重放更安全。恢复后，系统要先核对未知请求是否已经产生结果，再决定重试。
截止时，OpenAI 仍在实施缓解。这不是忽略后来改善，而是拒绝让时间窗口失去意义。下一篇更新可以写监控，本篇必须写当时仍在进行。