破坏性操作的三道闸：备份、回退方案与发版 diff 审查

开场：不可逆操作的安全感来自闸门

发版时以为只改了 A 功能，实际 diff 里混进了上周调试 B 的临时改动，半成品代码进了生产环境。数据库、配置、部署这些不可逆操作，必须在执行前设闸。

一句话速览：数据库先备份、不可逆操作先给回退方案、发版前做 diff 审查。

备份拦数据损失，回退方案拦无法恢复，diff 审查拦带病发版，三道闸都设在执行之前。

GATE 1 · 备份： 数据库改动先备份。备份放项目根目录 backups/，命名带时间戳。**未备份不得执行任何 migrate、drop、alter、delete 操作。**成本是一行命令，赌的是整库数据。

# 任何涉及数据库结构或数据的改动，执行前必须先备份
cp database.db backups/database_$(date +%Y%m%d_%H%M%S).db

备份文件命名格式：{原文件名}_{YYYYMMDD_HHMMSS}.db，统一放项目根目录 backups/ 下。

GATE 2 · 回退： 不可逆操作先说回退方案。回退方案要回答三件事：**如何恢复到操作前的状态、需要哪些备份文件、预计恢复耗时。**说不出这三件事，说明操作还没想清楚。

GATE 3 · 审查： 发版前做 diff 审查。把「我以为我改了什么」和「我实际改了什么」拆开比对。SubAgent 独立分析 diff 与 Release Notes 的偏差，有风险就暂停发版。

以「新增夜间模式」发版为例：Release Notes 只写了一件事，实际 diff 有 7 个文件。

✅ 符合预期： darkTheme.css（新增）、ThemeToggle.tsx（新增）、App.tsx（挂载开关）、tokens.css（新增颜色变量）、RELEASE_NOTES.md（补充说明）
⚠️ 存在风险： messageParser.ts（改写了已有消息解析函数的分支逻辑——与夜间模式无关）、package.json（axios 从 0.27.2 升到 1.6.0——未声明的依赖升级）

有风险的文件必须暂停发版，核实后再走。

发布通道： 代码发布、版本发布、服务器部署必须通过 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 能否发现混入的改动并暂停发版，把它的风险报告存档作为流程模板。