Hermes误删我的5篇稿件后,我搭了四重防护
今天发生了一件事,让我意识到给AI助手设置安全机制有多重要。
我让桌面端 Hermes 执行清理多余文件的操作时,它因为判断错误,一口气删掉了十几个文件,其中有几个是还没有归档的有用的文件。
那种看着屏幕上突然少了一堆文件的感觉,真的有点慌。
这不是第一次了。
AI助手执行批量操作时,有时候会对"删除"这个动作理解得很直接——你说删,它就真删了。不带犹豫,不带回收站,直接 rm。

传统的备份也有局限性。
我们确实每天都在做备份,但备份是"事后"的——它能帮我们恢复昨天的状态,但帮不了我们找回今天下午三点被误删的那5个今天上午10点才创建的文件。
我需要的是一个更即时的保护机制。亡羊补牢,为时不晚,说干就干。
第一道防线:回收站机制
我给 workspace 目录加了一个回收站机制。所有"删除"操作不再真正删除文件,而是移到.trash/目录。

核心是让 Hermes 自己创建一个删除文件的脚本。执行删除时,用这个脚本替代直接的rm命令。
它的逻辑很简单:把文件复制到回收站目录,带一个时间戳命名,然后再删除原文件。
这样即使删错了,回收站里还有一份完整的副本。
被删除的文件会出现在.trash/目录下,文件名变成20260716_160854_xxx.md这种格式,一眼就能看出是什么时候删的。
如果发现删错了,Hermes 可以直接从.trash/恢复。
回收站不能无限堆积,所以我又让 Hermes 写了一个clean-trash.sh来自动清理。超过7天的文件会被自动删除,释放空间。
有了这层保护,AI助手就算误操作了,我们也至少有7天的时间窗口来恢复。
第二道防线:项目文件Git版本控制
回收站解决了"删错了能找回"的问题,但还有一个问题:文件被覆盖了怎么办?
比如 AI 助手在编辑一个项目文件,改了一半出了问题,把原来的版本覆盖掉了。
这时候回收站帮不了我们,因为文件没有被删除,只是被修改了。
所以我给我的项目目录 dev-projects/ 目录下的所有项目都配了 Git 仓库。规则写在 AGENTS. md 里。

因为大部分代码由 Hermes 自动编写,所以为了省事,我把 commit 也交给了它。
Hermes 每完成一个功能模块或修复一个 bug ,就自动执行 git add + commit。
Hermes 会在commit message 写清楚每次修改都做了什么。不需要等人来手动敲命令,版本历史是自动维护的。
出了问题,可以直接回退到任意历史版本。
这比回收站更精细。回收站只能找回被删除的文件,而 Git 能找回被修改前的状态。

Commit 粒度以"完成一个可独立运行的功能"为单位。改完一个小功能就 commit,出了问题回退的成本很低。反之攒了一大堆改动再 commit,出了问题回退就是灾难。
第三道防线:R2云端备份
回收站和 Git 都依赖本地磁盘。如果硬盘坏了,或者整台机器出了问题,这两层保护就都失效了。
所以我加了第三道防线:Cloudflare R2 免费云端备份。
我让 Hermes 写了个备份脚本,通过每天定时任务自动执行,保留最近 15 天的内容,超过15天的旧备份自动清理。

建议备份的内容和备份方法稍微有点繁琐,可以看我之前的文章:
Hermes数据备份容灾全攻略,免费实现从本地到云端双保险。这里就不重复说了。
云端备份我们选择 Cloudflare R2 而不是其他云存储的原因是:
(1) Hermes 原生支持 rclone 加密上传;
(2) R2 的流量免费,不用担心备份量太大产生额外费用。

不过恢复备份的流程比前面几种方式复杂得多,所以还是尽量把前两道防线做扎实,恢复备份文件作为最后的手段。
第四道防线:操作目录黑白名单
前三道防线是被动保护——出了问题能找回。但更理想的做法是主动预防,从源头上限制 AI 助手能操作哪些目录。
NAS 端 Docker 部署的 Hermes 天生跑在沙盒里,不用担心搞坏容器外的文件。但 PC 端的目前还没有沙盒功能,那就得再做个限制了。

我在 workspace 根目录下创建了 AGENTS.md 文件,定义了操作权限规则,白名单模式:
(1)D:/aiwork/ 目录可读写,其他目录只读。
(2)Hermes 配置文件修改需要用户确认。
这样Hermes 每次启动时会自动读取。虽然是软限制,但也没有更好的办法。希望官方 Windows 版本早点支持沙盒。
最后想说的
经过以上几道防线的配合,我现在面对 AI 助手的误操作终于不是手足无措了。日常小问题用回收站秒恢复,中等问题用Git回退,大问题从备份文件重建。
这就是我用半年 AI 助手的血泪教训:不把所有鸡蛋放在一个篮子里。单一的保护机制总有盲区,多层防御才能覆盖各种场景。各位大佬还有哪些手段,不妨也端出来互相交流下哈。
