破坏性操作的三道闸
数据库先备份、不可逆操作先给回退方案、发版前做 diff 审查
本页解决的问题
先给结论「破坏性操作的三道闸」要解决的关键问题是什么？
数据库先备份、不可逆操作先给回退方案、发版前做 diff 审查
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
核心原则：不可逆操作的安全感来自闸门。备份拦数据损失，回退方案拦无法恢复，diff 审查拦带病发版，三道闸都设在执行之前。
数据库改动先备份
备份放项目根目录 backups/，命名带时间戳。未备份不得执行任何 migrate、drop、alter、delete 操作。成本是一行命令，赌的是整库数据。
不可逆操作先说回退方案
回退方案要回答三件事：如何恢复到操作前的状态、需要哪些备份文件、预计恢复耗时。说不出这三件事，说明操作还没想清楚。
发版前做 diff 审查
把「我以为我改了什么」和「我实际改了什么」拆开比对。SubAgent 独立分析 diff 与 Release Notes 的偏差，有风险就暂停发版。
你是本次发版的 reviewer。Release Notes 只写了一件事，但实际 diff 有 7 个文件。逐个判断每个文件的改动「符合预期」还是「存在风险」，全部标完后生成审查报告。
✨ 新增夜间模式：可以在设置里切换暗色界面，长时间使用不再刺眼。
选择一个操作类型，逐项勾选它要通过的闸门，然后尝试执行。漏了哪项，就会看到对应的后果。
备份命令（SQLite 示例）
# 任何涉及数据库结构或数据的改动，执行前必须先备份
cp database.db backups/database_$(date +%Y%m%d_%H%M%S).db备份文件命名格式：{原文件名}_{YYYYMMDD_HHMMSS}.db，统一放项目根目录 backups/ 下。
发布通道
- 代码发布、版本发布、服务器部署必须通过 GitHub
- 服务器通过
git pull或 CI/CD 流水线拉取代码 - 紧急热修复可以例外，事后必须补 commit 同步
- 在用户明确确认之前，打 tag、push、部署全部禁止
凭据管理
- 所有凭据通过环境变量或 secrets 管理
- 禁止硬编码在代码或配置文件中
- Key 一旦进入 git 历史等于永久泄露，只能作废重发
设计意图：Release Notes 描述的是预期改动，实际 commit 里可能混入无关调整甚至误删。正规团队靠 CI/CD 加 PR review 拦这个问题，独立开发者往往跳过 review 直接 push，diff 审查规则等于让 SubAgent 充当 reviewer。
提交物：一份风险审查报告。① 在测试仓库里故意混入一个与发版主题无关的改动（比如改掉一个已有函数的逻辑）；② 写一份只描述主题功能的 Release Notes，让 AI 按「取完整 diff → 逐文件比对 → 分类处理」三步做审查；③ 检查 AI 能否发现混入的改动并暂停发版，把它的风险报告存档作为流程模板。
素材来源：开源仓库 itshen/xs_vibe_rules 中 rule-opensource.mdc 第六章 6.4/6.5「数据库备份与回退方案」、第十章「部署与环境」。
从「数据库改动先备份」把感觉变成判断
「核心原则： 不可逆操作的安全感来自闸门。备份拦数据损失，回退方案拦无法恢复，diff 审查拦带病发版，三道闸都设在执行之前」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「备份放项目根目录 backups/ ，命名带时间戳。未备份不得执行任何 migrate、drop、alter、delete 操作。成本是一行命令，赌的是整库数据」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- 代码发布、版本发布、服务器部署必须通过 GitHub
- 服务器通过 git pull 或 CI/CD 流水线拉取代码
- 紧急热修复可以例外，事后必须补 commit 同步
漂亮不等于容易用
把「提交物：一份风险审查报告。① 在测试仓库里故意混入一个与发版主题无关的改动（比如改掉一个已有函数的逻辑）；② 写一份只描述主题功能的 Release Notes，让 AI 按「取完整 diff → 逐文件比对 → 分类处理」三步做审查；③ 检查 AI 能否发现混入的改动并暂停发版，把它的风险报告存档作为流程模板」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「数据库改动先备份」走到「不可逆操作先说回退方案」
「数据库改动先备份」先把问题落在「备份放项目根目录 backups/ ，命名带时间戳。未备份不得执行任何 migrate、drop、alter、delete 操作。成本是一行命令，赌的是整库数据」上；到了「不可逆操作先说回退方案」，讨论继续推进到「回退方案要回答三件事：如何恢复到操作前的状态、需要哪些备份文件、预计恢复耗时。说不出这三件事，说明操作还没想清楚」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「数据库改动先备份」：备份放项目根目录 backups/ ，命名带时间戳。未备份不得执行任何 migrate、drop、alter、delete 操作。成本是一行命令，赌的是整库数据
- 「不可逆操作先说回退方案」：回退方案要回答三件事：如何恢复到操作前的状态、需要哪些备份文件、预计恢复耗时。说不出这三件事，说明操作还没想清楚
- 「最后的要点」：所有凭据通过环境变量或 secrets 管理
最后的「最后的要点」把讨论落到「所有凭据通过环境变量或 secrets 管理」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。