改坏了，五分钟退回去

一句话

能一键退回上一个能用的版本，你才敢改线上的东西。

因为它是其余六条的保险。

前面六条讲的都是「怎么别出事」。这一条讲的是「出事之后怎么在五分钟内恢复」。

有回滚能力的人，改线上是日常操作。没有的人，每次部署都是赌博——赌完了还得靠 AI 现场救火，而它救不回来的概率不低。

回滚不是一件事，是三件：

前两层几乎白送，第三层要提前准备。

L3 讲过：每次验证通过就提交一次。

这里补一条上线场景的规矩：上线用的版本要打标记。

git tag -a v1 -m "第一版，能用"
git push --tags

出事了：

git checkout v1     # 回到那个能用的版本

**知道「上一个能用的版本」是哪个，比什么都重要。**没有标记的话，一堆 commit 里你分不清哪个是好的。

Vercel、Netlify、Cloudflare Pages 这类平台，部署历史里每一次都能一键回滚，不用碰命令行。

**现在就去找到那个按钮在哪。**别等出事的时候现找。

配置改坏了比代码更难查——因为代码有 git，配置经常没有。

两条规矩：

第 2 条听着土，但它救过很多人。

代码退回去了，删掉的数据不会自己回来。

这是 L5 事故库里那条 agent 删库的真正代价——代码好好的，数据没了。

1. 确认你的数据库有自动备份，并且知道怎么恢复

托管型数据库基本都自带每日备份，但：

2. 不给 AI 生产库的删除权限

这条是事故四的直接教训。

按「最坏情况下它能造成多大破坏」来给权限，不是按「它平时挺靠谱」来给：

部署之前，问自己一句：

如果这次上线把东西弄坏了，我现在知道怎么退回去吗？

答不上来就别按那个键。先花五分钟搞清楚退路，比事后花五小时救火划算。

回头再看那张清单，现在每一条你都能给出明确答复了。

**这就是「玩具」和「作品」的全部差距。**不是代码写得多好，是这七件事有没有做。