临时文件清理自动化方案：从AI工具缓存到系统目录的完整实践-平芜编程栈

说实话，我一开始没把“临时文件”这事放在心上，直到有一天发现系统盘空间莫名少了十几个G，逐个目录排查之后才发现，罪魁祸首居然是某个AI对话类工具的缓存目录。这类工具（类似 workbuddy 这类偏个人助理性质的软件）会把对话记录、运行缓存和临时文件全堆在本地，时间一长，占用高得吓人。这篇文章把我从那次排查到现在沉淀下来的整套自动化管理方案完整写出来，包括脚本、任务配置、目录识别方法和各种坑，你可以直接照着抄。

1. 临时文件从哪里来：先弄清楚你在清什么

很多人一听到“清理临时文件”就直接跑去删Temp文件夹，结果删完了空间也没释放多少，问题还一堆。这是因为临时文件这个词覆盖面太广，系统临时目录只是其中一小部分。我自己的经验是，第一步不是急着删，而是把目标目录分类清楚，搞清楚每一类文件是干嘛的、能不能删、删了有什么后果。

1.1 三大类临时数据：运行缓存、会话记录、日志文件

我习惯把这类数据分成三类，分类标准很简单：是否可再生、是否影响已有数据安全。

第一类是运行缓存，比如程序启动时加载的预览图、索引、缩略图、编译中间文件。这类文件的特点是：删了之后程序会自动重建，最多就是下次启动慢几秒。浏览器缓存、代码编辑器缓存、AI工具的模型缓存都算这一类。这类文件往往体积巨大，是清理时的优先目标。

第二类是会话记录，也就是聊天历史、操作流水、编辑记录这类带有业务含义的数据。这类数据严格说并不算“临时”数据，但很多工具会把它和缓存放在同一个数据目录里。处理这类文件要特别小心，删错了就是聊天记录全部丢失，而且基本找不回来。我个人的处理原则是：默认保留，只有确认某个记录已经不需要了，再单独去删。

第三类是日志文件，程序运行过程中输出的调试信息、错误堆栈、上报数据。日志文件的特点是单个很小，但架不住天天写，时间长了也能攒出几个G。很多日志系统是不做轮转（log rotate）的，老日志会一直保留，这也是常见的隐形占用来源。

把目录分类这件事做清楚了，后续写清理脚本才有底气。否则你拿着一个“清理所有文件”的目录列表，根本不敢放进自动任务里。

1.2 为什么workbuddy这类AI工具占用特别夸张

如果你用过 AI 对话类的工具，你会发现在不知不觉中，它的数据目录体积疯狂增长。这不是bug，而是这一类工具的架构决定的。

以 workbuddy 这类工具为例，它的本地数据目录里通常会同时存在三个东西：对话历史数据库（保存每一轮消息）、向量索引/缓存（用于让历史对话可以被检索）、运行临时文件（接口请求的中间结果、待处理的上传附件等）。问题在于，对话历史每用一次就增长一点，向量索引为了加速搜索也会不断膨胀，而临时文件如果程序没有及时清理，就会一直堆积。

更麻烦的是，这类工具的目录往往藏得很深。Windows 下默认在%LOCALAPPDATA%\workbuddy这类路径下，里面可能还有一层层的子目录，不实际进去看根本不知道每个目录占多大空间。我翻到那个目录的时候，光 Cache 文件夹就占了接近 8 个 G，而用户一般不会意识到 AI 工具会在本地存下这么多东西。

搞清楚这层来龙去脉之后，你就会明白，管理临时文件的核心矛盾不是“删除文件”，而是“如何在保留必要数据的情况下，自动把可再生数据清理掉”。下面这套方案就是围绕这个矛盾展开的。

2. 自动化管理方案怎么设计才不翻车

直接写一个“删掉所有临时文件”的脚本，然后挂在开机任务里跑，这种做法我试过，很快你就会发现它的问题：要么有些文件删不掉，要么把不该删的删了，要么空间占用依然居高不下。自动化方案需要设计，不是写脚本这么简单。

2.1 动手前先回答三个问题

我把设计阶段需要想清楚的问题收敛成三个，想不清楚这三个问题，后边必然会翻车。

第一个问题：哪些目录能安全清理？这个取决于你对目录的了解程度。我会把准备纳入自动清理的目录分成“确认安全”和“需要小心”两类。系统临时目录、浏览器缓存、应用缓存这类属于确认安全，删了最多重新生成；对话记录、数据库文件就属于需要小心，绝对不能无脑进入自动清理范围。

第二个问题：清理频率定多少？频率太高，缓存频繁失效，程序性能反而受影响；频率太低，空间占用又会回升。我自己的经验是，缓存类和临时目录走高频策略，一周至少清一次；日志类文件走低频策略，一个月处理一次即可；对话记录类不做自动清理，只做定期手动审查。

第三个问题：留多少天内的文件？这是一个硬指标，也是很多脚本写崩的根源。常见做法是清理 N 天前的文件，但 N 怎么定要看业务类型。纯临时文件，比如下载中断产生的临时文件，保留 1 天足够；日志文件留 7 到 30 天是常规做法；AI 工具的运行缓存建议至少留 3 天，因为太频繁清理会导致每次启动都重建索引，机器反而更慢。

这三个问题有了明确答案，方案的设计就完成了一大半。你接下来写的每一个参数都是有依据的，而不是拍脑袋。

2.2 三种方案选型对比：任务计划、脚本、工具

确定目标之后，下一步是选实现方式。我把市面上常见的方式归纳为三种，分别适合不同场景。

第一种，系统自带工具。Windows 上有“存储感知”和“磁盘清理”，macOS 有“储存空间”管理，Linux 有bleachbit这类图形工具。优点是零成本、适合偶尔手动清一次；缺点是自动化能力弱、清理策略不透明，而且对 AI 工具这种藏在应用数据目录里的缓存往往覆盖不到。我的判断是：可以作为辅助手段，但撑不起“自动化”这三个字。

第二种，自写脚本加系统定时任务。这是我最推荐的做法，也适合长期使用的场景。用 PowerShell、Bash 或 Python 写一个清理脚本，把你要清理的目录列表和保留天数写清楚，然后挂到 Windows 任务计划程序、Linux crontab 或 macOS launchd 里。优点是完全可控、透明、可以按需扩展；缺点是要花点时间调试，而且对脚本里列出的目录负责——列错了目录就是删错数据。

第三种，第三方清理软件，比如 CCleaner 这类工具。优点是界面友好、功能齐全；缺点是我对它们默认的清理规则不够放心，尤其是一些软件会自作主张清理你不想动的东西。如果你非要用这类工具，我建议先把默认规则全部检查一遍，关掉任何涉及“历史记录”、“最近文档”的选项。

三种方案相互之间也不是二选一的关系。我自己的做法是“脚本为主、系统工具为辅”，核心业务数据的保护靠脚本里的白名单逻辑保证。

2.3 我的分层管理策略：每日、每周、每月

最后说一下我目前实际在用的管理节奏，给你一个可以直接借鉴的模板。

每日任务：这一步很简单，只清理最基础的东西——当前用户的临时目录里超过 1 天的文件。这个任务放在每天凌晨执行，几乎不影响正常使用，跑一次只要几秒钟。

每周任务：这是整个方案的核心。每周清理一次系统的Windows\Temp、AI 工具的数据缓存、浏览器缓存目录。这里只清理“可再生缓存”，保留日期阈值我设在 3 到 7 天，视目录类型而变。

每月任务：这一步做两件事，一是清理过期日志文件，二是检查有没有异常膨胀的新目录。日志清理用保留 30 天的规则；目录膨胀检查则是扫描用户数据目录，列出体积排名前 20 的子目录，我自己过一眼，看看有没有新的“隐藏胖子”出现。

这套分层策略的好处是：短期高频清理保住空间，长期低频清理兜底，目录审查防止新问题漏网。接下来我直接上实际操作部分。

3. Windows 与 Linux 下落地：可直接抄的脚本和配置

下面这部分是可以直接复制使用的内容。我把 Windows、Linux 和 AI 工具目录处理拆开写，每个部分都包含脚本、定时任务配置以及参数说明。

3.1 Windows：PowerShell 清理脚本 + 任务计划程序

Windows 下我推荐用 PowerShell 写脚本，因为它在处理文件属性和任务计划集成方面比 CMD 舒服太多。下面这个脚本是我现在的主力版本，逻辑很简单：遍历一组目录，删除指定天数前的文件，并跳过白名单子目录。

# Clean-Temp.ps1 # 使用说明：修改 $targetDirs 和 $keepDays 后直接运行 # 参数说明： # - 只处理文件，不删除目录结构 # - 默认跳过名称包含"Database"或"Records"的子目录，保护会话数据 param( [int]$KeepDays = 3 ) # 要清理的目标目录列表，按需增删 $targetDirs = @( "$env:TEMP", "$env:WINDIR\Temp", "$env:LOCALAPPDATA\workbuddy\Cache", "$env:LOCALAPPDATA\workbuddy\Code Cache", "$env:LOCALAPPDATA\Microsoft\Windows\Explorer" ) # 白名单子目录关键词：命中则跳过 $protectedKeyWords = @("Database", "Records", "IndexedDB") $cutoffTime = (Get-Date).AddDays(-$KeepDays) foreach ($dir in $targetDirs) { if (-not (Test-Path $dir)) { continue } Get-ChildItem -Path $dir -Recurse -File -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt $cutoffTime } | Where-Object { $protected = $false foreach ($kw in $protectedKeyWords) { if ($_.FullName -match $kw) { $protected = $true; break } } -not $protected } | Remove-Item -Force -ErrorAction SilentlyContinue }

几个参数细节，我说一下为什么这么定。

第 11 行的$KeepDays = 3，对多数缓存目录来说是刚刚好的值：太短了缓存频繁失效，太长了空间回收不明显。如果你发现某个目录最终占用还是很高，单独把这个目录的天数调大或调小，而不是一刀切，才会更有效。

第 14 到 17 行是核心目录列表，这是整个脚本最需要你花时间确认的部分。我刚在电脑上拿workbuddy举例，但不同工具的缓存目录结构差异很大，建议先用du或者WinDirStat扫一遍，把实际占用高的目录加进去，而不是直接照抄。

第 22 到 24 行的白名单关键词是对应对话记录类文件的。你按-Recurse深度遍历时，有些缓存目录下也会混着索引数据库文件，而通常这个文件是单独存放的，加这个保护条件可以避免误删。

脚本写完之后，把它保存为.ps1文件，再挂到任务计划程序里。具体步骤：

打开“任务计划程序”，创建基本任务，名称填“Weekly Temp Cleanup”。
触发器选择“每周”，我设在周日凌晨 3 点，这时机器基本闲置。
操作选择“启动程序”，程序填powershell.exe，添加参数填：

-ExecutionPolicy Bypass -File "C:\Scripts\Clean-Temp.ps1" -KeepDays 3

注意-ExecutionPolicy Bypass这个参数，它会让当前任务跳过 PowerShell 的执行策略限制，否则脚本可能因为策略原因无法运行。任务计划程序里的账户建议用当前管理员账户，选择“不管用户是否登录都要运行”，这样不会因为锁屏状态而中断。

3.2 Linux：tmpfiles 与 cron 的双保险

Linux 下的临时文件清理有一套现成的机制，但默认配置比较保守，对应用缓存目录不会覆盖到。我采用“systemd-tmpfiles 管系统目录 + cron 脚本管应用目录”的组合。

系统目录方面，/tmp和/var/tmp的清理规则写在/etc/tmpfiles.d/目录下。默认配置里/tmp下超过 10 天未访问的文件会被清理，/var/tmp则是 30 天。如果你的需求是更积极地清理，可以新建一个配置文件覆写默认行为：

# /etc/tmpfiles.d/clean-tmp.conf # 注意：这里的规则是“析取”式的，年龄以文件最后修改时间为准 # 系统默认可能已经包含了类似规则，重复定义只会合并不会冲突 d /tmp 1777 root root 1d

这个写法表示/tmp下修改时间超过 1 天的文件会被systemd-tmpfiles --clean清理。注意第一列是d，表示只清理匹配目录内符合过期条件的文件，不递归处理目录本身，这点跟D是不同的，后者会连内容一起清空，慎用。

但systemd-tmpfiles只管系统临时目录，应用程序的数据目录它不会碰。所以应用缓存部分，我用 cron 脚本补上。下面是一个针对 AI 工具和常见缓存目录的清理脚本：

#!/bin/bash # /usr/local/bin/clean-app-cache.sh # 每周日凌晨 4 点执行，删除指定目录下 7 天前的缓存文件 TARGET_DIRS=( "$HOME/.cache/workbuddy" "$HOME/.cache/browser" "$HOME/.local/share/Trash/files" ) # 保护规则：跳过任何包含 records 或 database 的路径 find "${TARGET_DIRS[@]}" -type f -mtime +7 2>/dev/null | grep -viE 'records|database|indexeddb' | xargs -r rm -f

注意脚本里用了mtime +7，含义是“最后修改时间在 7 天以上”的文件，这个参数跟 Windows 脚本里的LastWriteTime对应。xargs -r是关键，-r表示当输入为空时直接不执行，避免删错东西。

然后加到 crontab 里：

# crontab -e 0 4 * * 0 /usr/local/bin/clean-app-cache.sh

这里0 4 * * 0表示每周日凌晨 4 点执行。选这个时间点的原因很简单：这个时间段用户操作最少，缓存文件的占用冲突最小，删除成功率最高。

3.3 AI 对话类应用的缓存与记录目录怎么单独处理

前面两个小节把通用目录覆盖到了，但 AI 对话类工具还有自己的特殊性——它的数据目录里同时混着缓存、日志和对话记录，用通用脚本一刀切会出问题。这一节专门讲这类目录怎么处理。

我用一个真实排查过程来展示：当时某台 Windows 机器上，workbuddy的数据目录在%LOCALAPPDATA%\workbuddy下，整个目录占了 12.5GB。我进入这个目录用du -sh排了一遍，问题集中在三个子目录：

12.5GB %LOCALAPPDATA%\workbuddy ├── 7.2GB Cache # 运行缓存，可再生，安全清理 ├── 3.1GB Code Cache # 预编译缓存，可再生，安全清理 ├── 1.8GB GPUCache # 图形渲染缓存，可再生，安全清理 └── 0.4GB Local Storage # 混合内容，需要逐个检查

这里面的处理策略是：Cache、Code Cache、GPUCache三个目录直接进自动清理脚本，保留 3 天以内的文件；Local Storage目录则不放进自动清理列表，因为里面既有可再生的缓存，也有对话状态相关的数据，只做月度手动检查。

这样分开处理的原因，其实是 AI 工具的运行机制决定的：它的对话记录通常存在单独的数据库中，但本地索引和渲染缓存是独立的。如果图省事把整个workbuddy目录都清了，短期看空间是释放了，下次启动时工具会长时间卡在重建索引上，体验极差。正确的做法永远是把“可再生”和“不可再生”区分开，然后只自动清理前者。

4. 排查与避坑：这些问题我基本都遇到过

脚本写好了、任务挂上了，不代表万事大吉。我在跑这套方案的两年里，遇到过的问题远不止“脚本报错”这么简单，很多问题是跑了很久之后才暴露出来的。这一节把这些坑整理成实录，顺便给你一张速查表。

4.1 文件被占用删不掉

这是最高频的问题。Windows 下最常见的情况是某个文件正在被进程使用，删除时报“另一个程序正在使用此文件”。这种情况脚本里一般会静默跳过（因为我的清理脚本带了-ErrorAction SilentlyContinue），但结果就是目录越来越大，你以为清理了，实际没清掉。

排查思路分两步。第一，用handle.exe（Windows Sysinternals 工具）或资源监视器的“CPU”选项卡去查是哪个进程锁住了文件；第二，把清理时间调整到进程空闲时段。比如 AI 工具如果你设定为开机自启，那么凌晨 3 点它很可能还在后台运行，锁住缓存文件。我后来把任务时间挪到了凌晨 4 点 30 分，并在任务前加了一个Stop-Process的步骤，问题明显减少。

但注意，脚本里不要动不动就杀进程。有些服务进程你杀了它，系统或应用的状态会异常。我的原则是：先试试能不能删，删不了就跳过，等下次空闲时段再处理，而不是强制结束进程。

4.2 记录被误删，聊天历史全没了

这个问题属于最严重的一类，我见过有人把清理目标写得太宽，连IndexedDB和Local Storage都划进了清理范围，结果整个应用的使用记录全部丢失。这种情况一旦发生，基本没有恢复手段，因为这些文件不是数据库自动备份的一部分。

我的建议是两条硬性规则：第一，任何自动化清理脚本都必须包含白名单机制，强制跳过包含Database、Records、IndexedDB、LocalStorage等关键词的路径；第二，在任务计划里多加一步，把清理前的目录体积快照写到一个日志文件里，这样万一出了问题，你至少能知道清理前后发生了什么。

你可以给 PowerShell 脚本加一行日志输出：

# 在脚本开头记录执行前的目标目录体积 $beforeSize = (Get-ChildItem $env:LOCALAPPDATA\workbuddy -Recurse -File | Measure-Object -Property Length -Sum).Sum Add-Content -Path "C:\Scripts\cleanup-log.txt" -Value "$(Get-Date) before: $beforeSize bytes"

这条日志成本极低，但关键时刻能救你一命——当你发现某个应用数据变少了，翻日志就能立即确认是哪次清理造成的。

4.3 删除之后空间没变化

还有一种特别迷惑的情况：脚本显示删了几个 G 的文件，但系统磁盘剩余空间几乎没变。我之前排查过一次，最后发现原因很蠢——删除的文件被进程持有着，Windows 和 Linux 在文件被进程打开时删除，文件不在目录里了，但占用的空间要等进程释放句柄后才真正回收。所以你看到的“删除成功”不代表空间已经释放。

另一个常见原因是回收站。如果脚本把文件删进了回收站而不是彻底删除，那空间自然没释放。PowerShell 的Remove-Item默认是永久删除，但如果你用了某些封装函数，可能就进了回收站。检查一遍你的脚本，确认没有走回收站逻辑。

4.4 临时文件清理问题速查表

最后把这些问题整理成一张速查表，方便你之后定位。

现象	最可能原因	处理方案
删除时报文件被占用	进程持有文件句柄	调整任务时间为空闲时段，或先关闭应用再清理
删除后空间未释放	句柄未释放，或文件进了回收站	使用任务管理器关闭进程；确认删除为永久删除
某些块空间反复占用	应用每次启动重建缓存	把清理周期从每日改为每周，减少重建频率
脚本运行报错无输出	PowerShell 执行策略拦截	添加`-ExecutionPolicy Bypass`参数
目录以肉眼可见速度增长	应用日志或分析数据未轮转	给日志目录加上保留天数限制，或配置 log rotate
清理后应用启动变慢	缓存完全被清空	保留较短的缓存窗口期，至少 3 天