ChatGPT Work 云端会话偶尔打不开，网页和桌面端都会遇到

这个问题目前更像会话加载不稳定，而不是 ChatGPT Work 在所有场景下都无法运行。现有报告能确认的结论是：已经创建的 ChatGPT Work 会话，在 chatgpt.com 或应用中启动云端任务后，重新打开可能显示“Could not load this ChatGPT conversation”，而且同一会话有时能正常加载，有时又会报错。

哪些环境出现了问题

报告列出的覆盖范围包括 Web、iOS、Android、macOS、Windows 和 Linux。实际观察到相同问题的界面是 Web、iOS 和 macOS，因此不能据此认定 Android、Windows 或 Linux 也会复现，提交问题时最好把“平台范围”和“已经实际观察到的平台”分开写。

用于报告的客户端信息是：

• 浏览器：Arc 1.165.0 (87194)
• Chromium Engine：153.0.8010.48
• App：26.917.71314

这组版本号是排查时最有用的定位信息。尤其是 App 版本和 Arc 内核版本混在一起看，排查人员才能判断问题是否与客户端、云端会话状态或运行环境有关，不能只写一句“ChatGPT 打不开”。

怎样的操作会触发

触发方式并不复杂：打开一个以前创建的 ChatGPT Work 会话。这个会话可能是在 chatgpt.com 上创建的，也可能是在应用中发起，然后选择通过 Cloud 运行。再次进入该会话时，就有可能看到：

> Could not load this ChatGPT conversation

报告人没有发现某个特定提示词、某一种文件或某条命令能够稳定触发。只要对 ChatGPT Work in the Cloud 运行内容，就有机会遇到这个问题。

更麻烦的是它不是必现。同一个会话可能这次可以打开，下一次又加载失败。报告中的描述是“非常频繁”，而且多数时候会显示错误，但没有给出固定比例。这里的准确含义是：问题发生得很多，但仍然存在成功加载的窗口，而不是“所有会话必然失败”。

自定义 SKILL 不能直接当作根因

报告提到，ChatGPT Cloud 设置里添加了大量 custom SKILLs，报告人不确定问题是否与它们有关。这个怀疑可以保留，但目前没有验证结果。

如果后续继续排查，不能直接把“删掉 SKILL 后恢复正常”写成结论，除非已经记录了修改前后的具体结果。报告里至少应该分别记录 SKILL 数量、会话是否依赖某个 SKILL，以及云端任务重新运行后是否仍能打开。否则只能把大量自定义 SKILLs 标成可能的关联因素，不能标成已确认的故障原因。

提交问题时该留下什么信息

这类问题最怕只留下一个报错截图，因为截图无法说明为什么同一会话有时能加载。可以按下面的方式整理，但其中的未知项应明确保留为空，而不是自行补全。

Environment:
Web / iOS / macOS

Observed on:
Web, iOS, macOS

Browser:
Arc 1.165.0 (87194)

Chromium Engine:
153.0.8010.48

App version:
26.917.71314

Affected feature:
ChatGPT Work in the Cloud

Error:
Could not load this ChatGPT conversation

Reproduction:
1. Create a conversation on chatgpt.com or via the app.
2. Run it using ChatGPT Work in the Cloud.
3. Re-open the same conversation.
4. Observe whether the conversation loads or shows the error.

Reliability:
The issue is intermittent. The same conversation may load successfully on one attempt and fail on another.

诊断部分还缺少两个关键字段：带时区的发生时间，以及可复现的频率。原始素材只提供了 image2238×1882 117 KB 这类截图文件信息，没有完整截图内容，也没有时区、发生次数或成功率，所以不能把“非常频繁”改写成具体百分比。

在公司环境里遇到这种问题时，最稳妥的描述是“ChatGPT Work 云端会话重新加载失败，且同一会话加载结果不稳定”。这样能准确限定在会话加载和 Cloud 运行环节，不会把普通 chatgpt.com 会话、模型回答错误或所有平台不可用都混在一起。现阶段能落地的动作也只有两类：保留客户端版本和平台信息，按原文记录复现步骤；后续拿到具体发生时间、频率和 SKILL 关联验证结果，再补充给维护人员。没有验证前，不要把 custom SKILLs 写成根因，也不要承诺重启或删除配置一定有效。