磁盘又满了，但这次不能只找大文件
这次的问题是从一个很具体的场景开始的：一台日常用于创作和 AI 协作的电脑，磁盘空间反复告急。有一次它只剩下很少的可用空间，过了一段时间又因为系统自动回收可清除空间，暂时恢复了一些。表面上看，这像是一次普通的磁盘清理任务；只要找出占用最大的目录，删掉缓存，再清空废纸篓，问题似乎就结束了。
但我很快发现，磁盘治理和清理垃圾不是一回事。电脑里有聊天记录、剪辑草稿、下载中的视频、临时音频、软件的过程文件，也有已经完成的内容和以后还需要回看的历史。它们都可能很大，却不能用同一个动作处理。正在写入的文件不能搬，已经验证过的成片可以归档，过程缓存可以清理，重要记录则要保留可查询的入口。
如果不把这些东西分开，结果通常只有两种：要么清理得很激进，把还没用完的数据一起删掉；要么为了安全什么都不动，磁盘继续变满，最后软件连新消息都写不进去。磁盘空间问题的第一问，不应该是“什么最大”，而应该是“这份数据现在处于什么生命周期”。
先把数据分成几种命运
一开始，我希望多台电脑和外部存储都能自动管理空间。后来真正落地时，保留标准被重新定义成了3类：生产内容、过程结论和必要记录。生产内容包括成片、最终文稿和以后还会继续使用的有效素材；过程结论是已经完成判断、但可能需要追溯的结果；必要记录则是为了让历史查询、恢复和对账继续成立的索引或账本。
相反，不是所有中间版本都值得永久保留。下载后已经用完的原始视频、可重新生成的临时音频、软件重复产生的过程文件，可能只适合短期留在本机。电影剪辑草稿也不能简单归入“垃圾”：一集完成后，它可以整体归档到安全存储，本机只留下位置记录；在剪辑仍未结束时，它就是正在使用的工作集，不能移动。
这个分类改变了我的判断方式。过去我会把“能删”理解成“现在可以删”，现在则要继续追问：它是否还在被软件使用？是否已经有可靠副本？搬走之后能否按原路径被读取？删除后是否有可恢复的落点？同一个文件，在不同阶段可能有不同命运，文件名本身并不能回答这些问题。
按设备和软件拆开处理
这次还有一个容易被忽视的差异：几台电脑看起来运行着相似的软件，但角色并不相同。有的机器偏向写作和协作，有的机器承担剪辑，有的机器只是中转或归档。外部存储也不是一个可以随意倾倒的黑箱，它要先确定哪些数据适合放进去、如何校验，以及掉线时如何发现。
所以，我没有设计一个“全盘清理”按钮，而是把任务拆成设备规则和软件规则。通用守护只负责观察空间、判断阈值和记录动作；具体软件的数据怎么生成、哪些目录可以动，则交给对应的软件规则。没有明确规则的数据，先进入待确认区域，不因为它占用空间大就自动处理。
这种拆分看起来慢一些，却能避免把不同问题混成一个问题。比如，剪辑草稿需要等待软件关闭或项目完成，再整份迁移并测试找回；聊天历史需要在迁移前后做查询比对；下载任务则要判断文件是否还在持续写入。不同设备和软件的差异，不是自动化的麻烦，而是自动化必须承认的边界。
如果不这样拆，最危险的情况不是少释放了一点空间，而是把一个仍在运行的任务当成闲置数据。那样即使文件最终被复制到了外部存储，也可能因为源文件还在变化，得到一个无法恢复的半成品。
清理、迁移和删除不是同一个动作
低空间时，我把处理动作分成了3档。第一档是清理可重新生成的过程数据，例如已经完成任务留下的临时视频和音频；第二档是迁移仍然有效、但不必常驻本机的数据，例如已经完成的剪辑草稿和历史会话；第三档才是可恢复删除，也就是先进入有边界的回收站或隔离位置，经过一段时间或更低的空间阈值后，才允许真正清除。
这几档的顺序很重要。最容易犯的错误捷径，是磁盘一满就全盘清缓存、清空废纸篓，或者直接删掉几个最大的文件，把“能删”当成“现在可以删”。我没有选择这条路，是因为低空间本身会制造判断压力，而压力下最容易遗漏文件正在使用、备份未完成和用户仍需要访问这3件事。
实际运行中，曾经出现过过程数据规则过宽，误伤了一批报告和脚本的情况。好在这些内容被原路还原，并补上了保护规则：报告、源码和成片目录不作为普通过程数据处理。这次边界暴露得很及时，它说明“规则已经写了”不等于“规则已经可靠”。
迁移也必须有顺序：先复制到安全存储，再做完整校验和抽样回读，确认新位置可用后，才处理本机副本；本机副本进入可恢复位置，而不是直接消失。对于正在下载的视频，先验证单个文件能否通过原位置的链接继续被软件读取，再批量迁移。一次验证通过，才有资格扩大范围。
阈值只是触发器，账本才是安全感
空间阈值解决的是“什么时候需要行动”，不能解决“应该动什么”。后来采用的做法，是把正常迁移、低空间应急和更低空间清理分成不同触发线，提前在空间开始下降时处理可迁移数据，而不是等系统已经快要失去写入能力才救火。回收站也设置了时间和空间双重条件，并且只处理守护进程自己放进去的内容，避免碰到用户手动保留的文件。
但真正让我放心的，不是阈值本身，而是每次迁移都有记录。记录里至少要能回答：原来在哪里、现在在哪里、什么时候移动、校验是否通过、恢复入口是什么。聊天记录迁移前后还要跑固定查询，确认最近记录和历史关键词的结果没有变化；剪辑草稿则要抽取样本，从外部存储找回并确认软件能打开。
这件事让我重新意识到，数据治理的安全感不是“我相信脚本不会错”，而是“脚本错了，我还能知道发生了什么并退回来”。后来有一次用户担心协作软件里的历史变得不可见，核对账本和运行日志后，才确认那些记录不在迁移范围内，真正的问题更接近磁盘过满导致软件无法继续写入。没有账本时，这两件事很容易被混为一谈。
每一次破坏性动作都应该留下可回读、可核对、可恢复的证据链。
把自动化做成可回退的流程
我现在理解的可复用方法，可以压缩成一条流程：先盘点，再贴生命周期标签；按设备和软件建立规则；对正在使用的数据设置禁止线；对有效数据先迁移并校验；对过程数据采用隔离或回收站；每轮执行后回读结果，最后再根据账本决定是否扩大范围。
这条流程里，最重要的不是自动化有多快，而是每一步都能被暂停。外部存储掉线时，任务应该停在复制或校验阶段，而不是继续删除源文件；软件仍在写入时，任务应该等待，而不是把最新文件判断成旧文件；状态记录没有更新时，应该先修复记录链路，再相信下一轮扫描结果。
我也不会把一次成功迁移理解成规则已经成熟。之前出现过重复文件检查误判占用，修正后才重新合并；某台电脑的外部盘曾经掉线，原本“挂载点还在”也不能证明它真的可读；一个守护进程虽然还在工作，状态记录却停留在较早时间，说明进程存活和状态可信是两件事。
真正成熟的流程，不是它永远不出错，而是它把错误限制在可回退的位置，并且能通过回读及时发现。自动化的终点不是替人做完清理，而是把“为什么可以动、动完是否成功、失败后如何回来”固定下来。
下次我会怎么做
下次再遇到磁盘空间告急，我会先暂停“删除”这个念头，按顺序问4个问题：谁在增长？它是否仍在使用？它属于生产内容、过程数据还是必要记录？如果必须离开本机，恢复路径在哪里？这4个问题没有回答清楚之前，只做只读盘点，不做批量写入。
接着，我会先处理不影响工作的可迁移数据，再处理可重新生成的过程数据，最后才考虑回收站和永久清除。每一步都保留一条简单账目，并至少抽查一次读取结果。对于新的软件或新的设备，不直接套用旧规则，而是先观察它的写入方式和失败后果。
如果用户只说“把空间清出来”，我会把真正的目标解释成“让系统恢复可用，同时不丢掉以后还需要的东西”。这会让任务从一次救火，变成一套可以持续运行的边界管理。磁盘治理最终治理的不是字节，而是数据从产生、使用、归档到退出的完整生命周期。只有生命周期先被定义，自动清理才不会变成自动遗忘。