如何更新你用 AI 做的应用，又不把已经在用它的人坑了

你的应用第一版很好改。要是哪里坏了，唯一会注意到的人就是你自己。后来真实的人开始用它了 —— 现在每一次改动都像是在给一个清醒着的病人动手术。学会更新你用 AI 做的应用而不把它弄坏，大体上就是养成一套流程的事，而这套流程比你想象的要简单。

我们认识一位经营家教生意的老板，就用最痛的方式学到了这一点。她那个排课应用顺顺当当跑了好几个月，于是某天晚上，她让 AI 构建器做一个小改进：把所有地方的 “Session”（课时）改名成 “Lesson”（课），因为她的家教们实际上就是这么叫的。构建器爽快地改了名 —— 结果连带着把存放现有预约的那个地方也一起改了。第二天早上，三位家教打开自己的日历，发现里面空空如也。数据没丢，但应用再也找不到它了，她花了紧张的一整天才把它重新接上。

那次改动本身没有任何不合理之处。她只是还没有一套流程，去应对”应用已经有用户之后该怎么更新”。这篇文章就是那套流程 —— 四个习惯，每次改动大概多花十五分钟，就能避开大多数灾难。

为什么有了用户之后，更新就变得不一样了

一旦有别人开始靠你的应用过日子，有三件事就变了：

• **现在里面有数据了。**那些在空应用上无害的改动 —— 改名、重构表单 —— 可能会把人们已经填进去的信息断开连接或者搅乱。
• **人们有了习惯。**你的用户记住了按钮在哪儿。哪怕是一个改进，只要它挪动了人家每天都在用的东西，那也是一种干扰。
• **问题什么时候来，你说了不算。**当应用只属于你一个人时，搞砸一个晚上无所谓。现在，搞砸一个周二早上，就意味着三位家教对着空日历。

这些都不意味着你该停止改进你的应用。停止改变的应用，是慢慢地死，而不是突然地死。它意味着，改动需要一点仪式感。

习惯一：动任何东西之前，先备份

这一条没得商量。在做任何比改错别字更大的改动之前，确保你手上有一份当前的应用数据备份 —— 并且知道怎么恢复它。

如果你已经设置好了自动备份，这个习惯就缩成对 AI 构建器问一句话：“上一次备份是什么时候，我要怎么恢复它？” 如果答案既笃定又是最近的，那就继续。如果你还没设置备份，那就在下一次更新之前先把它做好 —— 我们写过一篇备份你用 AI 做的应用的完整指南，这是你这个月花在自己产品上最值的一个小时。

上面那个家教应用的故事之所以有个圆满的结局，正是因为她的平台一直在备份。否则，那紧张的一天就会变成灾难性的一天。

习惯二：点头答应之前，先问”这会搞坏什么？”

下面这个问题，大多数构建者从来没想到要问，但它顶得上另外三个习惯加起来的作用。在你向 AI 构建器描述完一个改动、并在你批准它之前，加上一句：

“在你做这个改动之前 —— 它可能会影响到哪些现有的功能或数据？”

这之所以管用，是因为 AI 通常看得见你看不见的那些关联。那位家教应用的老板没法知道 “Session” 同时也是存放预约的那个地方的名字。构建器知道 —— 只是她从来没问。后来她重建自己的流程时，这一个问题就成了那道能拦住问题的步骤：它提示她，改动定价表单会影响到两张旧发票，而加一个必填字段会把那些当初没填它就注册了的老客户挡在外面。

读那个答案，要像飞行员读天气报告一样。“这只是表面改动，没别的东西碰到它” —— 晴空万里，走起。“这会改变预约的存储方式” —— 那就是你该放慢脚步、再备份一次、也许还得要一个更温和版本改动的信号。

习惯三：一次只改一样东西，并像个陌生人那样去测它

把五个改进打包成一次大更新，感觉很高效。其实恰恰相反：等出问题时，你不会知道是这五个里哪一个引起的，而要撤销坏掉的那一个，就意味着把五个全撤回去。

一个改动，然后检查。检查这件事，和拆分一样重要：

• **用第二个账号，别用你的管理员账号。**你看到的应用是管理员视角的；你的用户看不到那些。用一个普通用户身份登录 —— 专门为此留一个固定的测试账号 —— 然后把你这次改动碰到的那条路径走一遍。（如果你从没测过自己的应用，这里教你在没有测试背景的情况下怎么做。）
• **检查你改的那个东西，以及挨着它的那个东西。**如果你更新了预约表单，那就预约一次 —— 然后也打开一个旧的预约，确认它还能正常显示。更新带来的损坏，大多出现在旧数据上，而不是新数据上。
• **现在就做，别等明天。**改完立刻测，趁它还新鲜、还小。改动后五分钟就发现的问题，显然是这次改动造成的。周五才发现的问题，可能是任何原因。

习惯四：挑一个安静的时间，并搞清楚怎么撤销

最后两条关于时机的常识，专业人士都在用，而非开发者很少听人说起：

**在用户离开的时候上线。**你大概知道自己应用的节奏 —— 那个家教应用在工作日下午最忙，在周日晚上几乎没人。周日晚上，就是改动该发生的时候。万一出了岔子，你有好几个小时去修，赶在任何人到来之前，而不是只剩几分钟。

**在你需要撤销之前，先搞清楚怎么撤销。**问你的 AI 构建器：“如果这个改动惹出问题，你能把它退回去吗？那需要做些什么？” 有时答案是”一键搞定”。有时是”退回改动很容易，但改动之后产生的数据，可能塞不回旧版本里。“你想听到这个答案的时候，是你心平气和的时候，而不是三位家教正在私信轰炸你的时候。

而当一个改动对用户是可见的 —— 挪动了一个按钮、改了一个字段名、加了一个步骤 —— 就告诉他们。一句简短的消息（“你会发现 Sessions 现在叫 Lessons 了 —— 还是同样的预约，只是名字更亲切”）就能把一个让人摸不着头脑的意外，变成一个有人正在用心照看他们所依赖的产品的信号。

十五分钟版

整套流程就在这儿，小到能记在一张便利贴上：先备份当前 → 问问会搞坏什么 → 一次只改一样 → 像陌生人那样测，连旧数据一起测 → 选安静时段 → 搞清楚怎么撤销 → 告诉你的用户。

那些照着类似流程做的老板，并不比莽撞的人更少更新自己用 AI 做的应用 —— 反而更新得更多，因为每一次改动都不再是一场赌博。这才是真正的回报：不是去避免出问题，而是保持足够的信心，让你能持续改进那个人们正指望着的东西。

下次你正要让构建器做一个改动时，试试习惯二里的那个一句话提问，看看它会揭出些什么。而如果就是这篇文章终于让你下决心去设置备份了 —— 从这里开始。