最近 OpenAI 发布 GPT-5.6 后引发了一场不小的讨论：在预发布材料与系统卡中，官方承认
Sol 模型在 Agent
编程场景下，由于过度追求目标或过宽解释权限，可能偶尔采取破坏性动作。团队成员也证实，确实收到并调查了少量关于意外删除文件的报告。不少开发者也在社交媒体上抱怨：AI
在后台重构项目或修改配置文件时，误把用户的根目录 $HOME
或者整个项目代码库给删掉了。
在只有人类手动敲代码的时代，误删通常只是一两个文件，而且手滑后我们能立刻意识到。但当 Cursor、Claude Code、Codex 等 AI agent 获得直接修改本地文件的权限后，破坏力完全不在一个数量级：它能在几秒钟内后台改动上百个文件，等你几小时后发现不对劲时，错误早已被扩散覆盖。
大家的第一反应往往是得赶紧搞个备份。但大多数没有运维背景的开发者面对备份却很茫然，或者误把同步盘当成了备份。
其实在 AI 时代，AI 既是放大误删风险的始作俑者，也是让搭建备份系统变得前所未有简单的超级助手。只要你厘清几个基本概念，并掌握结果确定性的表达方式，就能在一杯咖啡的时间里，建立一套连 AI 也毁不掉的可靠备份系统。
在搭建之前，我们需要先纠正两个最常见的认识误区，并理清几个基本概念。
rsync）或同步盘不是真正的备份？很多人习惯用 rsync --delete
命令或者网盘同步工具，把电脑里的文件定时镜像到另一台机器或云端。这看起来很省心：那边的目录结构和这边一模一样，打开就能用。
但这藏着一个致命死角：镜像保存的是当前状态，而不是历史记录。
如果今天下午 AI agent 误删了一个重要的文件夹，而你当时没注意到；到了晚上，定时镜像任务悄悄跑了一轮，它会忠实地把目标端对应的文件夹也抹掉，让两边保持一致。镜像没有任何故障，它甚至工作得太好了——好到把你当前的错误，忠实地复制到了备用设备上。
镜像只给你另一份今天，给不了你能够回到过去的昨天。真正用于防范误删的备份，必须具备版本化的能力。
既然要保留历史，如果每天都完整复制一份几百 GB 的数据，硬盘很快就会爆满。这时候就需要增量备份。
增量备份的原理是：第一次做完整备份，之后每次只记录新增或被修改的数据块。像 Borg Backup 就是其中的佼佼者，它具备极强的去重和压缩能力：就算你每天备份一次，只要大部分文件没变，新增的存储占用就极小，速度也快得惊人。更重要的是，Borg 的每一个历史归档在挂载时都呈现为一个完整的时间点快照——你可以随时翻回昨天、上周甚至上个月的任何一个时刻，把被误删的文件完整捡回来。
备份最忌讳的就是靠人手去点。靠手是形成不了纪律的，哪天忘了点，哪天刚好出事。备份必须自动化：
- Linux / macOS 下通常使用 cron 定时任务管理器； - Windows
下则对应使用 Task Scheduler（任务计划程序）。
同时，自动化系统必须失败敏感：如果硬盘满了、网络断了、或者权限不够导致备份失败，系统绝对不能悄无声息，必须留下明确的报错日志并提醒你。
如果你此前从未搭过备份，最简单的起点不是去学各种命令行，而是买一块外置移动硬盘。
移动硬盘的优势在于物理直观、不占用主盘空间，平时插在电脑上自动跑，必要时还可以拔掉实现离线隔离。
crontab 表达式或 Windows 计划任务。这会劝退 99%
的普通用户。AI 会自动帮你查路径、检查环境、撰写自动化脚本并配置 cron
或 Task Scheduler。
当你掌握了基本备份后，还可以根据场景进行进阶升级：
单靠外置移动硬盘，依然存在电脑和硬盘同处一室发生意外（或忘记插硬盘）的风险。
如果你手头有一台局域网内 24 小时不关机的机器（比如旧电脑、NAS 存储或小服务器），最好的方案是把它作为备份节点： - 网络建议：备份主机最好插上有线网卡，局域网千兆/万兆传输速度远快于 Wi-Fi； - AI 实施：让 AI 帮你生成 SSH 密钥，并配置本地到局域网 Server 的异机加密 Borg 备份。你甚至不需要自己登录 SSH 终端，AI 会自动处理好两台机器之间的鉴权与通信。
如果你备份的对象包含正在运行的程序或数据库（如 PostgreSQL、MongoDB 等），千万不能直接去复制数据库的数据目录！因为数据库在运行中随时有写入，直接复制会导致数据块不一致，恢复出来的数据库根本无法启动。
正确做法： 先让 AI
编写前置处理逻辑，调用数据库一致性导出工具（如 pg_dump 或
mongodump）生成导出文件，然后再把这个导出的 Dump 产物纳入
Borg 的增量备份中。这样既保证了数据一致性，又利用 Borg
完成了历史版本归档。
在备份领域有一句铁律：没有测试过恢复的备份，约等于没有备份。
很多人设好了 Borg，也挂了
cron，以为万事大吉，结果真正出事时才发现密钥丢了、路径写错了、或者提取出来的文件是损坏的。
这就引出了我们在此前博客《从过程确定性到结果确定性》中强调的核心理念：在使用 AI 时代，不要去微操 agent 的每一步过程（过程确定性），而是要定义可执行的成功标准，并要求它提供验收证据（结果确定性）。
当你让 AI 帮你搭备份时，如果你只是命令它“你去运行 Borg 命令、设个 crontab”，这是在微操过程；真正靠谱的做法，是要求 AI 在备份完成后，必须完成一次真实恢复测试：
每次备份完成后，系统必须自动从刚生成的备份中提取一个真实的、非敏感的文件（比如某个项目配置文件或文档），恢复到源目录之外的新位置，并自动比对内容和 SHA-256 哈希值。只有当提取出来的文件能完好无损地打开、比对完全一致时，才能宣布本次备份成功。
这就是结果确定性：不看日志有没有报错，不看脚本返回值是不是 0，而是看真实文件有没有被成功带回来。
你可以直接复制以下这段 Prompt，粘贴给你的 AI agent（如 Claude Code、Cursor、Codex 等），让它自动为你搭建这套具备结果确定性验证的备份系统：
请先只读盘点这台电脑的重要数据、操作系统、现有备份和可用的独立存储，再为我建立一套自动运行、保留历史版本、可以验证恢复的加密备份。不要只给教程；在安全边界内完成实现，并用证据报告结果。
完成必须同时满足：
- 备份目标位于源数据之外的独立物理磁盘或局域网/异机 Server，仓库不会被再次纳入备份源；
- 重要目录与排除项经过盘点；若包含运行中的数据库，先用应用一致的方式（如 pg_dump/mongodump）导出，再备份导出产物；
- 备份会按当前平台支持的方式自动运行（Linux/macOS 用 cron，Windows 用 Task Scheduler），失败会留下可见日志，重复运行不会破坏数据；
- 首次运行不执行 prune、compact、删除旧文件或清理恢复目录；任何删除性维护先展示真实预览并等我确认；
- 在首次归档前，从每个恢复域选择真实、非敏感文件，记录路径、大小和 SHA-256；归档后把样本恢复到源目录和仓库之外的新目录，逐项比对，保留恢复目录让我检查；
- 最终报告分别列出 PASS、BLOCKED 和 NOT RUN，并附仓库位置、归档标识、日志路径、恢复目录和比对结果。只要恢复比对没有通过，就不能宣布整体完成。
未经我明确确认，不要读取秘密值、申请宽泛管理员权限、修改现有定时任务或执行任何破坏性动作。若当前是 Windows，先验证所选工具对 Windows 文件与调度机制的稳定支持；不适配就停止实装并说明更安全的原生替代方向。若缺少独立存储、凭证或只有我能提供的业务判断，请明确报告阻塞，不要用未经验证的临时方案冒充完成。AI agent 的普及，让文件误删的风险从偶然手滑变成了常态隐患；但同时也把过去繁琐复杂的运维门槛拉到了地平线。
我们不再需要去记 crontab 语法，不需要去死磕 Borg
的命令行参数。我们只需要掌握清晰的基本概念（增量历史版本而非镜像），选择合适的介质（从外置硬盘到局域网
Server），并用结果确定性去约束
AI——先证明数据能完整拿得回来，再把更大的权限交给它。
把繁琐的执行交给 AI，把终点的定义与验收保留给自己。这才是 AI 时代最舒心的安全之道。