发布错误现在用直白的语言说明发生了什么

Mythex 发布失败时，发布对话框现在会用一句简明的话告诉你发生了什么：构建失败、应用在启动后停止、应用未能启动、文件太大，或者我们这边出了问题，并提供 Fix with AI 和 Try again。构建和应用的原始输出仍会传给代理，因此 Fix with AI 可以读取它并修复项目，但你不必再自己去看这些输出。

有什么变化

一句你可以据此行动的说明

每次发布失败现在都有一个类型，该类型在失败发生的那一刻就根据我们掌握的事实确定，例如哪一步失败了、应用的机器是否报告了崩溃、它是否曾开始接受连接，而不是事后通过阅读错误文本来判断。每种类型都有自己的说明：

每次失败都提供 Fix with AI

每次失败都会显示 Fix with AI 和 Try again。当你使用 Fix with AI 时，代理会在其自身的上下文中私下收到失败的类型以及完整的构建或应用输出。如果你的应用中有问题，它会修复。如果没有问题（例如暂时繁忙，或是我们这边的问题），它可以直接再次发布。你不必去判断这是哪种失败。

上线之后的问题

发布可能成功，而应用却在几分钟之后失败。Mythex 会定期检查已发布的应用。如果一个在线应用持续崩溃，或者仍在运行却不再接受连接，这次发布就会被标记为失败，你会收到一封邮件，项目中会显示该说明以及 Fix with AI。应用打印的内容会被保存，供代理阅读。

上传前检查大小

对于静态站点，所有文件的大小以及文件总数都会在任何内容上传之前进行检查。如果有超出限制的，你会收到一条说明，列出每一个过大的文件，而不是在中途失败。

我们为什么要做这个

过去，发布失败时会显示发布所用工具打印出的任何内容。在九月底的某一周，大多数失败都显示的是构建方的文本，而这些文本其实是我们自己需要处理的：计费联系人、内部版本号、镜像仓库路径、存储错误。Fix with AI 随后又把这些同样的文本粘贴进聊天。人们被要求去调试我们的基础设施。

其中有些内容还根本是错的。一个没有在其端口上监听的应用，被报告为「我们这边的问题」，而问题其实在应用本身。超过大小限制的静态文件也被同样地报告，而再次发布永远不可能成功。

此外，Mythex 中每一个对失败作出反应的部分（对话框、通知、Fix with AI、我们自己的告警）过去都是通过匹配错误文本中的词语来判断发生了什么。只要措辞一变，这种做法就会失效。现在，失败类型会在失败发生的地方被记录下来，其余部分都读取这个类型。

在处理这件事的同时，我们也把同样的规则应用到了其他错误上：

• 聊天。 如果回复流式传输时连接中断，你现在会看到我们的说明，而不是浏览器的「Load failed」或「Failed to fetch」。
• 自定义域名。 关于购买或连接域名的说明，现在根据响应的状态和代码来选择，而不是直接转发域名服务商自己的文字。
• 图片生成。 卡片显示的是我们的说明；代理获得的是服务的详细信息。

如何使用

1. 像平常一样，从 Publish 按钮发布。
2. 如果失败，阅读对话框中的一行说明。
3. 点击 Fix with AI。代理会读取构建输出或你应用的日志，修复出错的地方，并在应用本身不需要修复时重新发布。
4. 或者点击 Try again，再次发布同一个版本。这对于「暂时繁忙」和「我们这边的问题」来说是正确的选择。
5. 如果说明与链接名有关，请先更改链接名，然后再次发布。对于其他任何错误，请保持相同的名称。

限制

• 某些失败会显示不同的按钮：链接名已被占用时会建议其他名称，积分用完时则会提供增加积分的途径。
• 静态站点的单个文件限制约为 25–30 MB（取决于站点类型），文件总数最多 20,000 个。较大的文件最好保存在存储中，并通过链接引用。
• 此变更之前的失败发布没有类型，因此它们显示的是一条中性的说明，而不是具体原因。
• 如果「我们这边的问题」一直出现，请联系支持，并提供项目 ID 和链接名。

每条说明及其处理方法的完整列表，见发布故障排查。如果你正在手动修复一个顽固的应用，我们的指南如何调试 AI 构建的应用会一步步讲解。至于重新发布时线上站点会发生什么，请参阅你的已发布应用现在在重新发布时保持在线。