范叶亮写智能体、模型和数据系统时，习惯先把定义和边界钉死。把「从 rm -rf * 说起」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

喜新

故事要从昨晚的事故说起，在软路由中删除了一个 Docker 容器，想着相关配置和数据目录也都用不到了就删掉吧。进入目录后「聪明」的我就执行了 rm -rf * ，等回头去看命令执行情况已然为时已晚。为什么说我「聪明」呢，因为自从知道 一个空格引起的 /usr 被删除的血案 后，在做删除动作时我都会谨慎再谨慎，然而这次的悲剧在于目录下通过 NFS 挂载了 NAS 上的远程目录，删除前忘记取消挂载了，结果就是 NAS 上 4 块盘里面的影视资料被我一键清空了。

想着十多个 TB 的影视资料就这么没了，到也没有太伤感，毕竟技术男认为总还是可以恢复的，无非就是费些时间的问题。所以做的第一件事就是把 NAS 关机了，因为一旦再写入新的数据，被删除的数据可能就真的无法恢复了。关机后就开始找 SATA 线（NAS 里面是 3.5 寸的机械硬盘，使用 SATA 口通信），发现没有就赶紧买了一根第二天可以到的，至此第一笔 60 大洋（3.5 寸的硬盘还得单独供电，好不容易找到一个便宜的带电源的套装）损失就出去了。然后就开始各种找资料，NAS 里面的硬盘格式是 Btrfs 的，可用的恢复工具一下子就少了，翻着翻着发现就已经凌晨一点。怀着一丝丝担忧还是决定先睡了，明天早起再说吧，反正 SATA 线最快也得下午才能到。

怀旧

这一切的一切要往前捯就只怪我「喜新厌旧」。搬到新家利用软路由和 NAS 搭建了一套家庭影音中心 ，老老实实看就得了呗，非要瞎鼓捣。在 Jellyfin 中显示的影视信息读取的元信息文件有些问题，提的 PR 也是做了各种测试才成功合并到主干，尽管只是改了一行代码的位置，但维护人员的严谨还是很让我受教的。虽然合并到了主干，但由于大版本更新发布还未确定时间，当时自己就临时针对当前版本调整了代码编译部署到了自己的软路由上先用起来了。

后续稳定版本也发布了几个修复问题的小版本更新，但合并的代码并不在更新范围内，自己懒了也就没再更新 Docker 镜像。直到昨天晚上也许就是闲来无事，想着要不就更新到非稳定版本用吧，同时一不做二不休还把刮削用的 tinyMediaManager 也更新下吧，然后就没有然后了，事故就发生了。

再出发

我是一个比较喜欢尝鲜的人，每天到公司不执行一下 brew update & brew upgrade 就不舒服。而且还不能搞成定时任务，就得手动执行，然后看着相关工具更新到最新版本就会很舒服。我承认在一些「大型」项目中，兼容和稳定才是第一追求，但我认为我还真么参与到过那种「大」到处处都要为兼容和稳定考虑的项目中过，所以我还是很喜欢尝试新的特性。当然工作中尝鲜用到的也得至少是正式发布的版本。最近的一次大迁移就是把我所有的 Python 项目都从 3.7 升级到了 3.10，为啥不是 3.11 呢，因为有些依赖包没我走得快，对 3.11 还不支持。我大部分是在做数据和算法工作，少部分时间也会用 Python 写一些工程性质的代码，在这个领域我认为「喜新」是一件好事，这会让你在面对一个问题时更有可能说出「我行」。

我其实还挺两面派的，刚刚还在「喜新厌旧」，现在又说「怀旧」。老人经常说人要有个「念想」，但此时此刻我发现我的「念想」有点儿多了，多到可能束缚到了我的前行。NAS 是我大概 6 年前买的了，去年淘汰了里面两块老旧的小硬盘，又补上了两块 8TB 的。里面存的都是从 PT 站下载的高清影视资料，今年也终于成功的将 PT 站的账号升到了永久保号的等级，看了看上传量也近 20TB 了。文件被删掉的那一刻都是在想怎么恢复，但当发现恢复有一定的难度后，我突然有在想要不要恢复。

落地时建议先做的 5 件事

1. 先写清任务能不能被自动验证：能验证的交给系统和评测，不能验证的留给人审。
2. 本地部署先算显存、延迟和失败回滚，不要只看能跑通一次。
3. 多智能体只在单智能体触到上下文或专业边界时再拆。
4. Token、微调和压缩都要有对照数字，避免口号式优化。
5. 结论写成可检查清单：接口、超时、评测集、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，最该拿走的是「单智能体先做好工具和提示，再谈编排」。数字员工、技能市场和网关应共用同一套评测与权限，而不是各写一套角色人设。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源