当你用 AI 做的应用在凌晨两点崩了该怎么办（而你又不是开发者）

你没写一行代码就做出了一个应用。它整整一周都好好的。然后一位用户在凌晨 1:47 给你发消息，说注册按钮点了没反应，而你被床头柜上手机的微光惊醒。

如果你从没修过一个线上应用，这一刻可能糟透了。你不读代码。你不知道”数据库”到底是什么意思。你拿不准它是真坏了还是只是有点怪，而平时能帮你的人都睡了。

这里有一套冷静、有条理的行动手册，专门应对用 AI 做的应用崩了、而你又不会写代码的情况。其中大部分是关于”别把事情搞得更糟”，而这恰恰是没人提醒你的那部分。

第一件事：不要重新部署

在你的 AI 应用构建器里，某个地方有一个按钮，写着类似”重新发布”、“重新部署”或”上线”的字样。你正要忍不住去按它。先别，现在还不行。

在一个半坏的应用上按下重新部署，可能会把坏掉的状态固定下来，抹掉手边那些用于调试的数据信息，还会让任何人 —— 包括 AI 构建器自己 —— 更难弄清楚到底哪里出了错。

第一步永远是看，而不是动手。你甚至还没确认什么东西坏了呢。

步骤一 —— 自己重现这个问题

在一个全新的浏览器窗口里打开应用 —— 隐身模式或无痕模式最好，因为它会清掉任何旧的登录状态或缓存，这些东西可能让应用在你这儿和在用户那儿表现得不一样。

试着做用户报告的那件事，原原本本地做。如果他们说注册按钮不工作，那你就试着注册。如果他们说仪表盘是空白的，那你就试着登录、查看仪表盘。

你在找的是三种情况之一：

**对所有人都坏了。**你撞上了同一个问题。这其实是最容易修的那种，因为它是稳定的。
**对你能用。**这是最棘手的情形，因为问题出在用户特有的某种状况上（他们的浏览器、他们的账号、他们的数据）。
**时好时坏。**这次能用，下次就坏了。这是最让人焦虑、但也最有信息量的 —— 它通常意味着某个东西超时了，或者某种资源用尽了。

记下你看到的是这三种里的哪一种。等你去求助的时候会用上。

步骤二 —— 先检查那些显而易见的外部因素，再去怪你的应用

数量惊人的”我的应用坏了”时刻，根本不是你的应用。在你一头扎进 AI 构建器之前，先检查：

**互联网本身没问题吧？**打开另外几个网站看看。如果你的 wifi 不稳，那可能你的应用好好的，坏掉的人是你。
**是 AI 构建器自己宕机了吗？**大多数 AI 应用构建器都有一个状态页（搜产品名加上 “status”）。如果他们今晚不太平，你就不用再去琢磨别的了。
**是你连接的某个工具挂了吗？**如果你的应用用 Stripe 收款、用某个邮件服务发通知、用某个数据库服务存数据，这些里面任何一个都可能宕机。每一个都有自己的状态页。检查你应用依赖的那几个。

大概每五次里有一次，答案是”其实不是我的应用”，然后你就可以回去睡觉了。

步骤三 —— 看那条报错信息，哪怕它吓到你

如果你的应用显示出一个带文字的界面 —— 哪怕看起来像乱码 —— 也要读它。截个图。尤其是如果有一长串字母和数字（人们管这叫”堆栈跟踪”；它看起来像一锅字母汤，但当你去求助时，它是你能拿出来的最有用的东西）。

大多数 AI 应用构建器还有一个地方，能看到最近发生的报错。它可能叫日志（Logs）、活动（Activity）、错误（Errors）或控制台（Console）。打开它。你不需要看懂里面大部分内容 —— 你要找的是最近的那段红色文字、或者最近的那条报错，以及它发生的时间。时间很重要：一条昨天早上的报错，多半不是你的用户刚刚没法注册的原因。

把那条报错复制下来。过一会儿你要把它粘到一个有用的地方去。

步骤四 —— 问 AI 构建器有什么变了

这是大多数非技术构建者用得最少的一招。打开和 AI 构建器的对话，用大白话说：

“我的应用坏了。用户没法注册 —— 按钮点了没反应。这是日志里的报错：[粘贴进去]。过去 24 小时里有什么变了，可能是什么引起的？”

一个好的 AI 构建器会告诉你，最近的哪个改动最可能是罪魁祸首。有时你会立刻认出来（“哦，我昨天让它把表单做得好看点，那大概把提交逻辑搞坏了”）。有时它会指向一个你不记得碰过的东西，这同样有用 —— 它意味着有某个自动的东西变了，比如一个连接的工具更新了。

先别让 AI 构建器开始动手修。你还在诊断阶段。我见过人们把小问题搞大的最常见方式，就是在还没人搞清楚什么坏了之前，就让 AI 开始”修”东西。

步骤五 —— 决定要不要回滚

几乎每个 AI 应用构建器都让你能回到应用的某个早先版本。有时它叫”历史”、“版本”、“检查点”或”回滚”。

如果你能清楚地记得有那么一个小时、或者一天，应用是好好的，那回到那个版本，就是单单一招里最可靠的。它的代价是你在这中间做的那些改动（你可能本来也不要它们了），而它给你换来的是一个能用的应用，让你醒来时有它可用。

一条好的准则：如果坏掉的是用户每天都要做的事（注册、登录、付款），先回滚，往后再修。能用但旧，永远胜过坏掉但新。

如果坏掉的是你今天刚加、还没人指望的功能，那你可以让它先坏着，到了早上头脑清醒了再修。

步骤六 —— 如果你非得让 AI 构建器来修

如果回滚没法做、或者你已经决定不回滚，那就让 AI 构建器提出一个修复方案。在它修的时候，记住两件事：

**在批准之前，读一读它打算改什么。**你不会全看懂，但你能看出来它是在改一个聚焦的小东西，还是在重写半个应用。在凌晨两点，小而聚焦的改动，比大刀阔斧的改动安全得多。

**用尽可能笨的方式去测这个修复。**别只是问一句”修好了吗？“就信了答案。真的自己在一个隐身窗口里打开应用，去做那件原本坏掉的事。如果修对了，那件坏掉的事现在就好了。如果它没好，别只因为 AI 构建器说它好了就接受这个改动。

步骤七 —— 给用户回个话，哪怕你还没修好

那位在凌晨 1:47 给你发消息的用户，并不指望你还在线。但如果你在，一句简短的回复比一个修复更重要：

“谢谢你告诉我 —— 我正在看这个问题。一旦它恢复正常，我马上给你发消息。”

如果他们是付费用户，这一条消息，就是他们到处跟人说”你响应得很快”和到处跟人说”你把我晾着不理”之间的区别。修复可以等到早上。回复不能等。

更大的功课：把你的应用当成它可能会崩那样去做

如果你觉得这事很让人焦虑，那一线希望在于：这段经历会重塑你做应用的方式。在你第一次凌晨两点的事故之后，你会开始换个做法：

**你会加一个状态检查。**一个简单的页面，告诉你应用的重要部件是否在正常工作，这样你就不用登录进去才知道。
**你会留一份用户数据的备份。**大多数 AI 构建器都能在你提出请求时导出你的数据。一周做一次，花 30 秒，在最坏的情况下能救你。
**你会写下你的应用都依赖什么。**一张简短的清单，列出每一个连接的工具（支付、邮件、数据库、存储），这样当东西在凌晨两点崩了，你手上有一张核对清单，而不是一堆猜测。
**你会一次只改一样东西。**当你一口气改了 10 样东西、应用崩了，你根本不知道是哪个改动搞坏的。当你一次只改一样，你就知道。

你可以不写代码就做出一个应用。你也可以不当开发者就让它一直跑下去 —— 但这里涉及的技能，和做应用的技能是不一样的。这些技能你多半是用最痛的方式学会的，而且通常都在一个不合时宜的钟点。

好消息是：每发生一次，它就少吓人一点。到第三次，它从令人惊恐变成了令人厌烦。到第十次，它就只是一个再普通不过的星期二。