使用 Agent 检查与辅助清理 Windows C / D 盘空间

在 Windows 长期开发、跑 AI 项目或使用 WSL / Docker 后，C、D 盘很容易被模型、数据集、缓存、虚拟环境、构建产物等逐渐占满。

相比手动一个个文件夹排查，可以直接让 Codex、OpenCode 等 Agent 通过 PowerShell 做一次只读磁盘分析，先定位真正的空间占用来源，再决定后续清理或迁移。

建议始终分成两步： 第一步只检查，不清理。 第二步根据检查报告，再让 Agent 辅助处理指定项目。

一、C 盘空间检查

将下面提示词直接交给 Agent：

请作为 Windows 系统存储、磁盘空间审计与开发环境维护专家，对当前电脑的 **C 盘（C:\）执行一次全面、深入、严格只读的空间占用审计**。

本次审计重点针对 Windows 系统盘。相比普通数据盘，C 盘涉及 Windows 系统组件、用户配置、软件运行依赖、开发环境、缓存、虚拟磁盘和系统保留空间，因此必须在尽可能深入挖掘可回收空间的同时，严格保护系统稳定性和现有开发环境。

## 一、核心目标

当前 C 盘剩余空间严重不足。本次任务不是简单列出几个大文件夹，而是尽可能深入地定位：

1. **空间到底被什么占用了**：明确具体路径、实际大小、文件类型、所属系统组件、软件或项目及其用途。
2. **哪些空间有可能安全回收**：深入挖掘 Windows 更新残留、系统缓存、软件缓存、临时文件、旧安装包、历史构建产物、重复资源、废弃环境等。
3. **哪些内容正在持续增长**：定位可能不断占用空间的日志、浏览器缓存、开发工具缓存、AI 模型、系统更新文件、虚拟磁盘等。
4. **哪些内容不能随便删除**：明确系统关键组件、用户配置、软件依赖、数据库、虚拟磁盘和其他高风险文件。
5. **最多有希望回收多少空间**：基于实际扫描数据，给出按风险等级划分的空间回收估算。
6. **后续应该优先处理什么**：形成具体、可追踪、可用于下一轮安全清理的候选清单。

特别要求：

- 不仅要告诉我哪个目录很大，还要尽可能说明其内部是什么内容、为什么占空间、是否有清理价值。
- 不能只关注 Windows 系统目录，还要充分调查用户目录、AppData、ProgramData、软件缓存和开发环境。
- 不能因为某个文件属于 Windows 系统，就完全放弃分析；应研究是否存在 Windows 官方支持的清理方式。
- 不能因为某个文件看起来是缓存，就认定可以直接删除。
- 优先寻找低风险、可再生、恢复成本较低且回收收益明显的内容。
- 对高风险但占用巨大的内容，说明占用来源及合法、安全的管理途径，而不是直接清理。

**本轮仅负责调查、分析和输出报告，绝不执行实际清理。**

---

## 二、绝对安全边界

### 1. 全程严格只读

禁止执行任何主动改变磁盘、文件或系统状态的操作，包括：

- 删除、移动、重命名、修改任何文件或目录。
- 压缩文件、清理缓存、卸载软件、清空回收站。
- 修改文件权限、所有权或访问控制。
- 修改注册表、环境变量、系统设置、服务配置或软件配置。
- 执行 Windows 更新清理、组件清理、磁盘优化、磁盘修复。
- 修改虚拟内存、休眠、系统还原、保留存储等设置。
- 执行可能修改项目文件的构建、安装、更新、初始化操作。
- 执行 pip、Conda、npm、pnpm、uv、Docker、WSL 等清理操作。
- 停止、重启、强制结束任何正在运行的进程、服务或程序。
- 修改 Windows Defender、安全软件、浏览器或其他应用程序的数据。
- 清理 Windows 事件日志、系统日志、崩溃转储或诊断文件。
- 触发 Windows 存储感知、磁盘清理工具的实际执行。

所有清理行为必须留到后续单独授权的任务中。

审计报告直接输出到当前对话，不要主动向 C 盘或其他磁盘写入报告、脚本、日志、缓存或临时文件。

优先使用系统现有的只读查询接口。避免调用会主动生成大量日志、缓存、索引或其他持久化结果的工具。

需要说明：Windows 本身可能因正常运行产生后台写入，本任务要求的是审计操作不主动修改系统状态，不应声称能够阻止操作系统自身的所有后台写入。

### 2. 目录及数据保护

- 不读取个人文件正文、源代码正文、数据库内容、浏览器历史内容或其他敏感数据。
- 主要依据路径、名称、类型、大小、时间和必要的只读元数据判断。
- 不读取或输出 API Key、Token、密码、Cookie、SSH 私钥和其他凭据。
- 对 Symbolic Link、Junction、Reparse Point、Mount Point 不继续递归，避免循环、跨盘扫描和重复统计。
- 对无法访问的目录，不修改权限，不强行接管所有权，不触发 UAC 提权。
- 不将正在使用的软件、项目依赖、用户配置或系统文件直接归类为垃圾。
- `D:\projects\CamAct` 及其在 C 盘中能够明确识别的相关依赖、缓存、环境和配置属于保护对象，不得列为清理或迁移候选。
- 对无法确认是否被 CamAct 或其他重要项目使用的共享缓存，不得直接归类为低风险候选。
- 其他用途不明的数据默认保留。

本轮审计范围仅限 C 盘，不得为扩大扫描范围而递归访问其他磁盘。

**本任务是严格只读审计，不是清理授权。**

---

## 三、第一阶段：C 盘全局空间审计

首先获取 C 盘真实存储信息：

- 总容量
- 已使用空间
- 剩余空间
- 剩余比例
- 文件系统类型
- 是否启用 NTFS 压缩或其他相关存储机制
- 可正常遍历的目录数量及文件数量
- 未能访问或未统计的范围

容量统一使用 GiB / MiB，必要时同时给出字节数。

特别注意：

1. 尽量区分逻辑文件大小与实际磁盘分配量。
2. 考虑 NTFS 压缩、稀疏文件、硬链接等因素。
3. 注意 Windows 系统组件中的硬链接，避免重复计算实际占用。
4. 不能准确计算物理占用时，明确标注为逻辑大小。
5. 不得将父目录及其子目录容量重复相加。
6. 将扫描结果与卷级已用空间交叉核对。
7. 关注 NTFS 元数据、回收站、卷影副本、系统保留空间等普通目录扫描可能无法解释的占用。
8. 对不能解释的容量差额，尽可能通过只读系统接口调查。

需要特别区分：

- 普通文件和目录占用
- Windows 系统文件占用
- 系统保留或受保护的存储
- 回收站占用
- 系统还原与卷影副本占用
- 虚拟内存和休眠文件占用
- 文件系统元数据占用
- 扫描遗漏或权限受限的空间

最终明确：

**C 盘已用空间中，哪些可以通过实际扫描解释，哪些属于系统管理或尚未解释的占用。**

---

## 四、第二阶段：完整目录占用审计

### 1. 建立一级目录完整排行榜

统计 C:\ 下全部一级目录和根目录大型文件的占用。

重点包括但不限于：

- `C:\Windows`
- `C:\Users`
- `C:\Program Files`
- `C:\Program Files (x86)`
- `C:\ProgramData`
- `C:\Recovery`
- `C:\$Recycle.Bin`
- `C:\System Volume Information`
- 其他实际存在的隐藏目录
- C 盘根目录中的大型文件

注意：

- 实际不存在的目录无需虚构。
- 无权限访问的目录必须明确标记。
- 系统保护目录不得通过修改权限强行扫描。

输出：

- 一级目录完整排行榜
- 最大目录 Top 30
- 根目录大型单文件
- 每个目录占 C 盘已用空间的比例
- 主要目录的用途和性质

### 2. 对大型目录深入递归

优先调查：

- 单个目录大于 1 GiB。
- 占 C 盘已用空间超过 3%。
- 存在大量缓存、日志或临时文件。
- 包含大量子目录，累计占用显著。
- 用户目录或应用数据中明显异常增长的区域。

原则上深入 2～5 层，但不机械限制深度。

如果第 5 层仍未定位真正的占用来源，应在安全和权限允许的范围内继续向下追踪。

例如，不要只报告：

`C:\Users` 占用 40 GiB。

应继续深入：

`C:\Users\<用户名>\AppData\Local`

再追踪到：

`C:\Users\<用户名>\AppData\Local\某软件\Cache`

并尽可能说明：

- 当前占用多少 GiB。
- 是什么软件产生的。
- 是浏览器缓存、模型缓存、应用数据还是其他内容。
- 是否属于可再生缓存。
- 是否依赖软件内置清理功能。
- 是否存在误删风险。
- 大致可能释放多少空间。

### 3. 识别真正占空间的叶子目录

对主要占用来源尽量提供：

- 完整绝对路径
- 当前目录大小
- 文件数量
- 主要文件类型及容量构成
- 最大的几个文件或子目录
- 文件修改时间分布
- 所属系统组件、软件或开发工具
- 可能形成占用的原因
- 是否具备清理价值
- 安全处理方式及前提

避免只报告层层重复的父目录。

---

## 五、第三阶段：Windows 系统占用专项审计

这是 C 盘审计区别于普通数据盘的重要部分。

需要重点调查以下内容。

### A. Windows 组件存储

重点分析：

- `C:\Windows\WinSxS`
- `C:\Windows\servicing`
- Windows 组件存储相关目录
- Windows 更新产生的历史组件
- 已替代组件与系统仍需保留的组件

重点回答：

1. 当前组件存储的占用情况。
2. 是否存在硬链接导致目录统计偏大。
3. 是否有可靠证据表明存在可由系统清理的历史组件。
4. 如果后续需要清理，应使用什么 Windows 官方支持的方式。
5. 哪些目录绝对不应手动删除。

可以使用现有、确认不会主动改变系统状态的只读查询接口。

不要执行实际组件清理。

### B. Windows 更新缓存与历史文件

重点检查：

- `C:\Windows\SoftwareDistribution`
- `C:\Windows\SoftwareDistribution\Download`
- `C:\Windows\SoftwareDistribution\DataStore`
- `C:\Windows\Logs\CBS`
- `C:\Windows\Logs\DISM`
- Windows Delivery Optimization 相关缓存
- Windows 更新下载残留
- 更新失败或重复下载产生的文件

分析：

- 总占用
- 最大子目录
- 文件数量
- 修改时间
- 可能属于更新缓存还是重要更新状态数据
- 是否可以通过 Windows 官方工具处理

不得直接建议手动删除整个 SoftwareDistribution 目录。

### C. Windows 安装器与驱动存储

重点检查：

- `C:\Windows\Installer`
- `C:\Windows\System32\DriverStore\FileRepository`
- `C:\ProgramData\Package Cache`
- 其他安装器缓存
- 驱动安装包和历史驱动资源

明确区分：

- 软件卸载、修复依赖的安装器缓存
- 当前系统依赖的驱动
- 可能存在的旧版本驱动
- 疑似残留的安装文件

不得将 Windows Installer、DriverStore 或 Package Cache 整体视为可以直接清理的目录。

如果发现大量历史驱动或安装器缓存，应说明后续正确的系统级处理方式与风险。

### D. Windows 临时文件与诊断数据

重点调查：

- `C:\Windows\Temp`
- Windows 错误报告目录
- Windows 崩溃转储目录
- `C:\Windows\MEMORY.DMP`
- `C:\Windows\Minidump`
- Windows Update 日志
- CBS 日志
- DISM 日志
- 系统诊断日志
- 其他大型 `.log`、`.etl`、`.dmp`、`.tmp` 文件

重点识别：

- 异常巨大的单个日志文件
- 长期累积的历史日志
- 崩溃转储文件
- 失败安装或更新残留
- 大量小文件组成的大型临时目录

注意：

- 不读取日志正文。
- 不清空正在使用的日志。
- 不直接将所有临时目录内容视为安全可删除。
- 需要说明后续通过系统工具处理的可行性。

### E. Windows.old 与系统升级残留

检查是否存在：

- `C:\Windows.old`
- Windows 升级残留目录
- 以前的 Windows 安装文件
- 升级安装包
- 系统回滚相关数据

重点说明：

- 当前占用。
- 是否可能影响系统回滚。
- 是否具备通过 Windows 官方清理功能回收的潜力。
- 回收前需要满足什么条件。

如果不存在，则直接注明，不必继续分析。

### F. 系统保留空间与其他隐藏占用

重点调查：

- Windows Reserved Storage
- 系统还原点
- Volume Shadow Copy
- VSS Shadow Storage
- 系统保护占用
- 回收站
- NTFS 元数据
- 搜索索引
- Windows Defender 相关数据
- WindowsApps 和 Microsoft Store 应用存储

对于无法通过文件遍历统计的区域，优先使用系统支持的只读查询接口。

注意：

- 不修改系统保护设置。
- 不删除还原点。
- 不清理卷影副本。
- 不修改保留存储。
- 不关闭 Defender。
- 不修改搜索索引设置。
- 不接管受保护目录权限。

---

## 六、第四阶段：系统特殊大型文件审计

重点调查 C 盘根目录和系统目录中的特殊文件。

### 1. 虚拟内存与休眠文件

检查是否存在：

- `C:\pagefile.sys`
- `C:\swapfile.sys`
- `C:\hiberfil.sys`

分别说明：

- 当前文件大小。
- 所属 Windows 功能。
- 可能影响哪些系统能力。
- 是否由 Windows 自动管理。
- 理论上是否存在系统配置层面的空间优化途径。
- 调整可能产生的功能、性能和稳定性影响。

特别要求：

不得直接删除这些文件。

不得修改虚拟内存配置。

不得关闭休眠、快速启动或相关系统功能。

对于潜在节省空间，只能作为需要用户确认的系统配置优化方向，不得归类为无条件低风险清理项。

### 2. 崩溃转储与大型系统文件

识别：

- `.dmp`
- `.etl`
- `.evtx`
- `.log`
- `.bak`
- `.old`
- `.tmp`
- 其他大型系统诊断文件

同时识别受系统管理的数据库、索引和缓存文件。

对大型文件说明：

**完整路径 | 大小 | 所属功能 | 修改时间 | 是否可能回收 | 风险等级 | 正确处理方式**

不能仅根据文件扩展名判断是否可删除。

---

## 七、第五阶段：用户目录与 AppData 深度审计

这是本次 C 盘审计的重点之一。

Windows 用户目录往往隐藏大量软件缓存、开发环境、历史数据和应用程序文件。

### 1. 用户目录完整分析

逐个调查 C:\Users 下实际存在的用户配置目录。

重点包括：

- Desktop
- Downloads
- Documents
- Pictures
- Videos
- AppData\Local
- AppData\Roaming
- AppData\LocalLow
- 用户主目录中的隐藏开发工具目录

统计：

- 每个用户目录的总体占用。
- 最大的用户数据目录。
- AppData 各区域的占用。
- 大型隐藏目录。
- 大型文件及疑似历史资源。

不读取个人文件正文或敏感内容。

### 2. AppData 深度追踪

重点寻找：

- 浏览器缓存
- 桌面应用缓存
- IDE 缓存
- AI 工具缓存
- Python 和 Node.js 包缓存
- 应用日志
- 自动更新下载包
- 历史版本缓存
- 软件崩溃转储
- Windows Store 应用缓存
- 临时文件
- 其他长期累积的应用数据

不要只输出 AppData 总容量。

对超过 500 MiB 的主要应用数据目录，尽可能继续追踪具体占用来源。

对于多个较小但合计占用明显的缓存目录，也需要汇总统计。

特别注意：

AppData 中可能包含用户账户状态、浏览器会话、软件配置、数据库和其他重要数据。

不得将 AppData 整体列为清理对象。

### 3. Windows 用户临时目录

重点检查：

- `%TEMP%`
- `%TMP%`
- `%LOCALAPPDATA%\Temp`
- 实际用户配置中的其他临时目录

分析：

- 总占用。
- 文件数量。
- 最大文件。
- 修改时间分布。
- 是否存在长期累积文件。
- 是否包含当前仍在使用的文件。
- 是否存在软件安装、解压或更新残留。

不要仅凭文件位于 Temp 目录，就断言其全部可以安全删除。

---

## 八、第六阶段：浏览器与常用软件缓存审计

重点检查当前电脑实际安装和使用的软件。

### A. 浏览器

如实际存在，调查：

- Google Chrome
- Microsoft Edge
- Firefox
- 其他 Chromium 浏览器

重点识别：

- HTTP Disk Cache
- GPUCache
- Code Cache
- Service Worker CacheStorage
- Media Cache
- Crashpad 崩溃数据
- 浏览器自动更新残留
- 多个浏览器配置目录中的重复缓存

统计每个浏览器及用户配置的大致占用。

特别注意区分：

**可再生缓存与重要用户数据。**

以下内容不得直接列为普通缓存清理项：

- 登录会话
- Cookies
- 密码
- 浏览历史
- 书签
- 扩展配置
- 用户 Profile 数据库
- Local Storage
- IndexedDB 等可能存储重要应用数据的区域

对于浏览器缓存，优先评估后续通过浏览器官方界面清理的可能性，而不是直接删除整个用户配置目录。

### B. IDE 与开发工具

重点检查实际存在的：

- VS Code
- Visual Studio
- JetBrains 系列 IDE
- Cursor
- Codex CLI
- Claude Code
- Gemini CLI
- 其他 AI 编程工具和 IDE

重点分析：

- 缓存
- 索引
- 扩展文件
- 扩展下载残留
- 工作区缓存
- 历史日志
- 临时数据
- 会话历史
- 工具下载资源
- 自动更新残留

注意：

AI 编程工具的会话记录、项目上下文、凭据和配置可能具有重要价值。

不得将 `.codex`、`.claude`、`.gemini`、IDE 用户数据目录等整体视为可删除缓存。

需要深入区分其中可再生内容与重要数据。

### C. 其他桌面软件

检查实际存在的其他大型应用数据，例如：

- 通讯软件
- 云盘客户端
- 下载工具
- 视频软件
- Office
- 游戏平台
- 开发辅助工具
- 其他桌面应用

重点寻找：

- 历史安装包
- 自动更新下载缓存
- 重复资源
- 大型日志
- 临时文件
- 可再生媒体缓存

说明软件来源和清理风险。

---

## 九、第七阶段：开发环境与 AI 资源专项审计

重点寻找分散在 C 盘用户目录、AppData、ProgramData、开发工具目录及其他位置中的资源。

### A. Python、pip、uv、Conda

检查实际存在的：

- Python 安装目录
- Conda / Miniconda / Anaconda
- `.conda`
- pip 缓存
- uv 缓存
- Poetry 缓存
- 虚拟环境
- `.venv`
- `venv`
- `__pycache__`
- `.pytest_cache`
- `.mypy_cache`
- `.ruff_cache`
- 历史构建和测试输出

重点判断：

1. 当前 Python 环境有多少套。
2. 各套环境分别占用多少空间。
3. 包下载缓存是否异常庞大。
4. 是否存在重复依赖资源。
5. 是否有旧环境和新环境并存。
6. 是否存在可再生缓存。
7. 环境是否可能与正在使用的项目关联。

不得简单建议删除整个 Python、Conda 或虚拟环境目录。

对共享包缓存要特别谨慎。

### B. Node.js、npm、pnpm、yarn

检查：

- Node.js 安装及版本管理目录
- npm 缓存
- pnpm Store
- yarn 缓存
- Corepack 缓存
- `node_modules`
- `.next`
- `.nuxt`
- `.turbo`
- 构建输出
- 历史依赖包
- 软件包下载缓存

分析：

- 全局缓存占用。
- 各项目依赖占用。
- 多套依赖是否存在重复。
- 哪些是可再生的构建缓存。
- 哪些是当前项目依赖。

特别注意 pnpm 等包管理器可能存在硬链接或共享存储，不能直接把各目录逻辑大小相加当成真实可回收空间。

### C. 其他开发工具

如实际存在，调查：

- Rust / Cargo
- Java / Maven / Gradle
- C / C++ 工具链
- .NET / NuGet
- Go
- Visual Studio 构建缓存
- Windows SDK
- 编译器缓存
- 历史安装包
- 各种构建输出目录

重点识别大型但可再生的依赖下载缓存和历史构建产物。

### D. AI 模型、数据集与实验缓存

重点检查：

- Hugging Face 缓存
- Transformers 缓存
- Torch 缓存
- ModelScope 缓存
- Ollama 模型目录
- 其他本地 AI 模型缓存
- `.safetensors`
- `.gguf`
- `.pt`
- `.pth`
- `.ckpt`
- `.bin`
- `.onnx`
- 大型数据集
- 历史 Checkpoint
- 推理输出
- 训练日志
- 临时预处理数据

尤其关注：

- C 盘用户目录中自动下载的模型。
- 多个 AI 工具重复保存的模型。
- 相同模型的多版本缓存。
- 缓存中未被当前项目使用的历史资源候选。
- 已存在于其他位置的疑似重复资源。

注意 Hugging Face 等缓存可能包含 Blob、Snapshot 和符号链接结构，必须防止重复计算。

不得仅因为模型文件较旧就判断其已经废弃。

不能确认是否被现有项目使用的模型，统一列为待确认。

### E. 项目相关缓存保护

对可能属于重要项目的：

- 虚拟环境
- 包缓存
- 构建产物
- 模型权重
- 数据集
- 实验结果
- 工具配置

应调查其空间占用，但不得擅自归类为无用。

特别保护 CamAct 相关依赖和缓存。

---

## 十、第八阶段：WSL、Docker、Hyper-V 与虚拟磁盘

调查 C 盘中是否存在：

- WSL 发行版虚拟磁盘
- Docker Desktop 数据
- Docker 镜像存储
- Docker Volume
- Hyper-V 虚拟磁盘
- VirtualBox / VMware 磁盘
- `.vhd`
- `.vhdx`
- `.vmdk`
- `.qcow2`
- 其他虚拟机镜像或备份

重点分析：

1. 虚拟磁盘文件的完整路径。
2. Windows 文件系统中当前实际占用。
3. 逻辑文件大小与实际分配量。
4. 是否存在多个发行版或历史虚拟磁盘。
5. 是否可能因容器、镜像、日志或缓存持续增长。
6. 是否存在理论可回收空间。
7. 后续应采用什么正确的管理方式。

特别区分：

- 虚拟磁盘当前占用
- 虚拟磁盘内部已使用空间
- 虚拟磁盘内部空闲空间
- Windows 端真正可能释放的容量

如果无法在严格只读、不启动或影响相关环境的条件下获取内部使用量，应明确说明。

不得执行：

- Docker prune
- Docker image / volume 删除
- WSL compact
- VHDX compact
- WSL unregister
- 虚拟磁盘压缩
- 发行版卸载
- 虚拟机快照删除

也不得为了调查而启动已停止的虚拟机或相关服务。

---

## 十一、第九阶段：大型文件、重复资源与历史产物

### 1. 最大单文件审计

统计：

- C 盘最大单文件 Top 50。
- 所有大于 1 GiB 的文件。
- 大型文件的主要类型分布。

重点关注：

- `.zip`、`.7z`、`.rar`、`.tar`
- `.exe`、`.msi`、`.iso`
- `.vhd`、`.vhdx`
- `.pt`、`.pth`、`.safetensors`、`.gguf`
- `.npy`、`.npz`、`.parquet`
- `.mp4`、`.mkv`
- `.dmp`、`.etl`、`.log`
- `.bak`、`.old`、`.tmp`
- 大型数据库
- 其他未知大型文件

对重要文件说明：

完整路径 | 文件大小 | 类型 | 可能用途 | 修改时间 | 清理价值 | 风险等级

不得读取文件正文或进行全量哈希计算。

### 2. 重复资源候选

寻找：

- 同名同大小的大型文件
- 重复安装包
- 相同模型的多份缓存
- 相同数据集的多个副本
- 多套 Python 或 Node.js 环境
- 历史版本压缩包
- 重复项目目录
- 软件更新残留
- 已解压目录与原始压缩包同时存在的情况

对于疑似重复资源，列出相关路径及大小。

注意：

- 仅凭名称和大小不能证明内容完全相同。
- 不执行完整哈希验证。
- 不得将未经校验的疑似重复文件直接计入保守可回收收益。
- 如果不同路径对应同一个硬链接文件或共享存储，不得重复计算容量。

### 3. 陈旧文件分析

对大型候选文件和目录中的文件，按最后修改时间分组：

- 最近 7 天
- 8～30 天
- 31～90 天
- 91～180 天
- 超过 180 天

重点分析：

- 很久未修改的大型缓存。
- 历史软件安装包。
- 旧构建产物。
- 历史压缩包。
- 长期累积的诊断文件。
- 旧模型和训练输出。

注意：

修改时间不等于最后使用时间。

不得单纯按照文件年龄建议删除。

---

## 十二、第十阶段：持续增长与异常占用分析

识别可能持续增长的目录：

- Windows 更新缓存
- 浏览器缓存
- 用户 Temp
- 软件日志
- Windows 诊断日志
- IDE 缓存
- AI 工具会话与缓存
- Hugging Face / Torch / ModelScope 缓存
- pip / npm / pnpm 缓存
- Docker / WSL 虚拟磁盘
- 自动备份
- 崩溃转储
- 项目构建结果
- 其他应用缓存

针对主要对象说明：

1. 当前占用。
2. 主要文件类型。
3. 文件时间分布。
4. 是否有多个历史版本。
5. 是否存在持续累积的迹象。
6. 如果不处理，未来可能造成什么存储风险。
7. 后续有什么安全控制或管理方式。

单次扫描不能证明真实增长速率。

不得编造每天增长多少 GiB。

对于没有历史数据支持的判断，明确标记为“疑似持续增长”。

---

## 十三、第十一阶段：清理价值与风险分类

所有潜在回收对象必须按照以下标准分类。

### P1：低风险、高收益候选

主要考虑：

- 有证据支持的可再生缓存。
- 历史临时文件候选。
- 明确不包含关键配置的非活跃缓存。
- 可重新下载或重新生成的资源。
- 明显积累的非关键历史日志候选。

要求：

- 具体路径。
- 当前占用。
- 预计可回收空间。
- 判断依据。
- 清理前提。
- 恢复难度。
- 是否可能影响软件正常运行。

P1 也不代表本轮可以执行删除。

对于有任何重要依赖疑虑的内容，不得归入 P1。

### P2：应通过 Windows 官方工具或软件自身机制处理

例如：

- Windows 更新缓存。
- Windows 组件存储。
- Windows.old。
- 系统管理的临时文件。
- Windows 错误报告。
- 旧驱动资源。
- 软件安装器缓存。
- Docker 数据。
- WSL 虚拟磁盘。
- Conda / 包管理器缓存。

说明：

- 当前占用。
- 可能的回收收益。
- 正确处理途径。
- 前置条件。
- 对系统或软件的潜在影响。

不得给出直接暴力删除系统目录的建议。

### P3：适合迁移或归档

例如：

- 大型下载文件。
- 历史压缩包。
- 大型模型。
- 数据集。
- 视频文件。
- 历史项目成果。
- 大型备份。

说明：

- 迁移后可能释放多少空间。
- 是否为唯一副本。
- 是否被现有软件依赖。
- 是否需要调整路径。
- 是否建议先验证备份完整性。

### P4：高风险，不应直接删除

包括：

- Windows 系统文件。
- 组件存储关键数据。
- 驱动存储。
- Windows Installer 关键缓存。
- 当前使用的软件。
- 活跃虚拟环境。
- 当前项目依赖。
- 用户配置。
- 数据库。
- 虚拟磁盘。
- Git 数据。
- 用户凭据。
- 唯一备份。
- 明确保护的项目及其缓存。

允许统计占用，但不得将其作为直接删除候选。

### P5：用途未知，需要人工确认

对无法可靠判断用途的内容，统一标记为待确认。

不得为了提高理论可回收容量而将未知内容归入低风险候选。

---

## 十四、第十二阶段：空间回收潜力估算

基于实际扫描结果，分别估算：

### 1. 保守低风险可回收空间

仅包含证据充分、恢复成本较低且处理前提明确的候选。

### 2. 条件性可回收空间

包括：

- 需要先确认用途的缓存。
- 需要软件专用工具处理的数据。
- Windows 官方清理功能可能回收的系统文件。
- 需要先确认是否仍使用的旧资源。

### 3. 迁移可释放空间

包括：

- 可迁移的模型。
- 数据集。
- 大型个人文件。
- 备份。
- 历史项目归档。

必须以迁移完成且确认源文件可以安全移除为前提。

### 4. 系统配置优化潜力

单独评估：

- 休眠文件。
- 虚拟内存相关占用。
- 系统还原存储。
- 其他可以通过 Windows 设置管理的空间。

此类属于改变系统配置，不得与普通缓存清理混为一谈。

只有能够合理估算时才给出容量。

### 5. 综合理论上限

计算所有候选经验证并成功处理后的潜在释放容量。

要求：

- 对父子目录去重。
- 对重复候选去重。
- 对硬链接和共享存储避免重复计算。
- 同一文件不能同时计入清理和迁移收益。
- 系统配置优化单独列示，避免混入普通低风险清理。
- 不得将受保护项目及缓存计入可回收空间。
- 不得将虚拟磁盘内部空闲空间直接视为 Windows 可立即回收空间。
- 不得将逻辑文件大小直接视为保证释放的物理容量。
- 不得将未经验证的重复资源计入保守回收量。
- 不能可靠估算的部分给出区间或标记为无法确定。

最终尽可能给出：

- 当前 C 盘剩余容量。
- 完成保守低风险清理后的预计剩余容量。
- 完成条件性清理后的预计剩余容量。
- 完成迁移后的预计剩余容量。
- 综合理论上限对应的剩余容量。

所有容量估算必须说明假设条件。

---

## 十五、执行方式与效率要求

1. **直接执行完整审计，不要停留在计划介绍。**
2. 优先使用 Windows 自带 PowerShell、CIM、文件系统元数据和安全只读查询接口。
3. 先完成 C 盘整体扫描，再对主要占用区域深度分析。
4. 优先遍历并统计目录元数据，避免反复全盘扫描。
5. 控制内存和 CPU 占用，不影响现有开发任务。
6. 避免将全部文件元数据一次性加载到内存。
7. 可以分阶段统计，但尽量复用已获取的数据。
8. 不下载、安装或更新任何软件。
9. 不启动额外的后台服务。
10. 不修改系统配置。
11. 不执行会主动进行磁盘清理、修复或优化的命令。
12. 不使用可能大量写入磁盘的分析工具。
13. 遇到访问拒绝时记录原因并继续审计其他区域。
14. 遇到 Reparse Point、Junction 或 Mount Point，记录但不跨路径递归。
15. 对已经明确属于 Windows 系统关键组件的目录，可以优先通过只读元数据和系统接口分析，避免没有必要的逐文件深度扫描。
16. 对大型用户缓存和开发环境，尽可能深入到具体可操作目录。
17. 保持审计过程稳定，避免占用大量系统资源导致软件卡顿。
18. 不因单个目录统计失败而提前结束。
19. 对未覆盖区域、权限限制、统计误差和未知占用如实说明。
20. 不为了追求扫描覆盖率而修改安全边界。

特别要求：

如果系统盘本身空间紧张，应避免使用需要在 C 盘生成大型临时数据的分析方法。

本轮报告应直接通过当前对话输出，不需要生成额外文件。

如果审计耗时较长，可以按阶段汇报进度，但应继续完成其他安全可执行的扫描，不要在只完成根目录分析后提前结束。

---

## 十六、最终报告格式

所有结论必须来自当前电脑的实际扫描和只读查询结果。

不得用常见 Windows 经验数据冒充本机实测数据。

重点输出能够指导下一轮安全清理的具体证据和结论，不要堆砌无关的原始命令日志。

### 1. C 盘空间总览

| 指标 | 数值 |
|---|---|
| 总容量 | |
| 已使用 | |
| 剩余空间 | |
| 剩余比例 | |
| 可解释的文件占用 | |
| 系统管理或保留空间 | |
| 无法解释或未覆盖的空间 | |
| 扫描文件数量 | |
| 扫描目录数量 | |

同时说明统计口径、扫描覆盖率和误差来源。

### 2. C 盘空间占用 Top 10 根因

按主要占用来源排序。

每项包括：

- 具体路径。
- 占用大小。
- 实际存储内容。
- 所属 Windows 组件、软件或项目。
- 为什么会产生这些文件。
- 是否具备回收价值。
- 是否存在安全处理方式。

重点区分：

**系统必要占用、软件正常占用、可再生缓存、历史残留和未知占用。**

### 3. 最大目录排行榜

至少展示 Top 30，实际不足 30 项则列出全部。

| 排名 | 完整路径 | 大小 | 主要内容 | 所属软件/系统 | 清理价值 |
|---|---|---|---|---|---|

对主要大目录进一步展开到真正占空间的子目录。

避免父子目录重复进入同一层级排行榜而导致误导。

### 4. 最大单文件排行榜

至少展示 Top 30，实际不足 30 项则列出全部。

| 排名 | 完整路径 | 大小 | 类型/用途 | 修改时间 | 风险与建议 |
|---|---|---|---|---|---|

对于超过 1 GiB 的其他文件，额外列出全部相关文件或合理分组。

### 5. Windows 系统空间专项分析

分别说明：

- Windows 组件存储
- Windows 更新缓存
- Windows Installer
- DriverStore
- Windows.old
- 系统临时文件
- 系统日志与崩溃转储
- 虚拟内存文件
- 休眠文件
- 回收站
- 系统还原与卷影副本
- 系统保留空间
- Windows Defender
- 搜索索引
- 其他隐藏占用

每项包含：

- 当前占用。
- 是否属于正常占用。
- 是否存在可回收潜力。
- 是否可以通过 Windows 官方支持的途径处理。
- 手动处理风险。

### 6. 用户目录与 AppData 占用

重点展示：

- 用户目录总体大小。
- AppData\Local 最大占用来源。
- AppData\Roaming 最大占用来源。
- AppData\LocalLow 主要占用。
- 用户临时文件。
- 浏览器缓存。
- IDE 和 AI 工具缓存。
- 其他大型软件缓存。

务必深入到具体软件和具体目录。

### 7. 开发环境与 AI 资源占用

单独汇总：

- Python / pip / uv / Conda
- Node.js / npm / pnpm / yarn
- Visual Studio / VS Code / JetBrains
- Codex CLI / Claude Code / Gemini CLI
- Hugging Face / Torch / ModelScope
- AI 模型与数据集
- 项目虚拟环境
- 构建与测试缓存
- Docker / WSL / 虚拟机
- 其他大型开发工具

说明具体路径、占用大小和潜在回收价值。

### 8. 潜在清理候选清单（最重要）

尽可能全面列出所有值得进一步核实的候选。

按“预计可回收空间 × 安全程度 × 操作成本”综合排序。

| 优先级 | 完整路径 | 当前占用 | 预计可回收 | 具体内容 | 清理依据 | 风险与前提 | 建议处理方式 |
|---|---|---|---|---|---|---|---|

要求：

1. 不要只列 5～10 项。
2. 尽可能找全有实际价值的候选。
3. 优先精确到可以单独处理的目录或文件。
4. 对分散在多个位置的小型缓存进行合理汇总。
5. 不得把同一个文件重复计入多个候选。
6. 对无法确认的内容明确标记。
7. 对需要 Windows 官方清理机制的内容单独说明。
8. 不得把系统关键文件伪装成低风险候选。
9. 不得把受保护项目及其依赖列为候选。
10. 每项必须明确说明为什么值得考虑回收。

### 9. 持续增长风险

列出可能持续增长的目录。

| 完整路径 | 当前大小 | 增长来源 | 判断依据 | 风险程度 | 后续建议 |
|---|---|---|---|---|---|

区分已确认事实和推测。

### 10. 不建议清理的高风险目录

| 完整路径 | 当前占用 | 主要用途 | 不建议直接清理的原因 |
|---|---|---|---|

重点保护：

- Windows 关键组件。
- 系统驱动。
- 安装器依赖。
- 用户配置。
- 活跃开发环境。
- 重要项目依赖。
- 数据库。
- 虚拟磁盘。
- 其他无法确认的关键资源。

### 11. 空间回收潜力汇总

| 类别 | 预计可释放容量 | 风险 | 前提 |
|---|---|---|---|
| 保守低风险候选 | | | |
| Windows/软件专用清理候选 | | | |
| 其他条件性清理候选 | | | |
| 迁移与归档候选 | | | |
| 系统配置优化潜力 | | | |
| 综合理论上限（去重） | | | |

注意：

分类展示可以保留不同处理方式，但综合理论上限必须按实际底层文件和存储空间去重。

给出不同处理情景下预计的 C 盘剩余空间，并说明估算误差。

### 12. 最终行动优先级 Top 10～20

根据实际调查结果，明确下一轮最值得优先处理的具体对象。

每项说明：

1. 具体绝对路径。
2. 当前保存的是什么。
3. 占用多少空间。
4. 预计可以释放多少空间。
5. 为什么建议优先处理。
6. 是否有依赖或系统风险。
7. 清理前需要确认什么。
8. 后续应通过 Windows、软件官方工具还是人工确认后处理。
9. 是否容易恢复。
10. 是否值得实际处理。

不要只建议：

“清理系统缓存”
“清理浏览器缓存”
“删除临时文件”
“清理 Windows 更新”
“删除旧环境”

必须给出本机实际发现的具体路径、容量及判断依据。

---

## 十七、审计完成标准

只有满足以下条件，才认为本轮审计完成：

- 已统计 C 盘总体容量和使用情况。
- 已完成根目录与主要隐藏目录的全面审计。
- 已深入主要大型目录。
- 已找到最大目录和最大单文件。
- 已调查 Windows 组件存储和更新缓存。
- 已调查 Windows Installer、DriverStore 等关键系统目录。
- 已调查虚拟内存、休眠文件、系统还原和其他系统管理空间。
- 已深入检查用户目录与 AppData。
- 已调查浏览器、IDE 和 AI 编程工具缓存。
- 已调查 Python、Conda、Node.js 等开发环境。
- 已检查模型缓存、数据集和大型 AI 资源。
- 已检查 Docker、WSL、虚拟磁盘等潜在占用。
- 已识别分散的小目录和大量小文件构成的高占用区域。
- 已寻找大型重复资源和历史产物候选。
- 已识别疑似持续增长目录。
- 已形成具体、可追踪的潜在清理清单。
- 已对可回收空间进行风险分级及去重估算。
- 已明确系统高风险目录和不能确认的内容。
- 已解释扫描覆盖范围、统计差异及未解决的容量差额。
- 全程没有主动修改任何文件、软件、系统或磁盘配置。

## 十八、最终执行要求

本次调查的最终目标不仅是知道 C 盘为什么满，更重要的是：

**尽可能深入地发现真正占用空间的具体对象，并筛选出所有值得下一轮安全清理的高价值候选。**

特别优先关注：

1. Windows 系统中可以通过官方工具安全处理的历史残留。
2. AppData 中体积庞大但容易被忽视的软件缓存。
3. 浏览器、IDE、AI 编程工具长期积累的缓存。
4. Python、Conda、npm、pnpm、uv 等开发工具的下载与构建缓存。
5. AI 模型、模型下载缓存和重复资源。
6. 长期累积的日志、临时文件和崩溃转储。
7. 系统更新、安装器和其他软件的历史残留。
8. C 盘根目录中的特殊大型系统文件及系统保留空间。
9. 数量庞大、单文件不大但累计占用明显的小文件。
10. 其他通过常规 Windows 存储设置难以发现的大型占用。

对于每一个高价值候选，尽可能明确：

**完整路径 + 当前大小 + 具体内容 + 占用原因 + 清理依据 + 风险等级 + 预计可释放空间 + 后续安全处理方法。**

不要为了追求回收空间而建议破坏 Windows、开发环境或用户数据的处理方式。

不要为了让报告看起来完整而编造目录容量、软件依赖或清理收益。

如果某项内容无法在严格只读条件下确认，必须如实标注。

请现在直接开始执行完整的 C 盘只读深度审计，尽可能完成全部安全可执行的检查。

完成审计后，输出完整报告、空间回收潜力评估和下一轮清理候选清单，然后停止，等待我的下一步指令。

**再次强调：本轮只审查、不清理、不迁移、不修改任何文件、软件或系统配置。**

二、D 盘空间检查

将下面提示词直接交给 Agent：

请作为 Windows 磁盘空间审计、数据存储管理与开发环境维护专家，对当前电脑的 **D 盘（D:\）执行一次全面、深入、严格只读的空间占用审计**。

本次审计重点针对 Windows 数据盘、开发项目盘及软件资源存储盘。

与 C 盘系统盘不同，D 盘通常主要存储开发项目、源代码、数据集、AI 模型、实验结果、软件安装目录、开发环境、构建产物、下载文件、历史备份和其他用户数据。

因此，本次审计应当将重点放在：

**深入定位项目、软件、开发环境和历史文件的实际空间占用，尽可能发现可以安全回收的缓存、临时文件、重复资源、废弃环境和历史产物，同时严格保护现有项目、源代码、实验数据及软件运行依赖。**

需要注意：

不能预先假设 D 盘中一定存在某些目录，也不能因为 D 盘不是 Windows 系统盘，就认为其中的文件可以随意删除。

应基于当前电脑实际存在的目录、文件和软件环境开展分析。

## 一、核心目标

当前 D 盘剩余空间严重不足。本次任务不是简单列出几个大文件夹，而是尽可能深入地定位：

1. **空间到底被什么占用了**：明确具体路径、实际大小、文件类型、所属软件、开发项目或数据资源及其用途。
2. **哪些空间有可能安全回收**：深入挖掘软件缓存、临时文件、旧安装包、历史构建产物、重复资源、废弃环境、历史实验结果、冗余数据等。
3. **哪些内容正在持续增长**：定位可能不断占用空间的日志、开发工具缓存、AI 模型、数据集、实验输出、构建文件、虚拟磁盘和自动备份。
4. **哪些内容不能随便删除**：明确重要项目代码、当前开发环境、软件依赖、数据库、模型权重、实验结果、Git 数据、虚拟磁盘和其他高风险文件。
5. **最多有希望回收多少空间**：基于实际扫描数据，给出按风险等级划分的空间回收估算。
6. **后续应该优先处理什么**：形成具体、可追踪、可用于下一轮安全清理的候选清单。

特别要求：

- 不仅要告诉我哪个目录很大，还要尽可能说明其内部是什么内容、为什么占空间、是否有清理价值。
- 不能只关注几个大型项目目录，还要充分调查软件安装目录、隐藏目录、开发环境、缓存、数据集、模型和历史文件。
- 不能因为某个目录属于正在使用的项目，就完全放弃空间占用分析；但不得未经确认就建议删除项目内部文件。
- 不能因为某个文件看起来是缓存，就认定可以直接删除。
- 优先寻找低风险、可再生、恢复成本较低且回收收益明显的内容。
- 对高风险但占用巨大的内容，说明占用来源及合法、安全的管理途径，而不是直接清理。
- 特别关注大量小文件累积、不同项目重复依赖、历史版本并存和实际分配空间与逻辑大小不一致的问题。
- 充分区分可以清理的历史产物、可以迁移的大型资源、需要用户确认的文件，以及绝对不能擅自处理的项目数据。

**本轮仅负责调查、分析和输出报告，绝不执行实际清理。**

---

## 二、绝对安全边界

### 1. 全程严格只读

禁止执行任何主动改变磁盘、文件或系统状态的操作，包括：

- 删除、移动、重命名、修改任何文件或目录。
- 压缩文件、清理缓存、卸载软件、清空回收站。
- 修改文件权限、所有权或访问控制。
- 修改注册表、环境变量、系统设置、服务配置或软件配置。
- 执行磁盘优化、磁盘修复、文件系统修复。
- 修改虚拟内存、系统还原、卷影副本等设置。
- 执行可能修改项目文件的构建、安装、更新、初始化操作。
- 执行 pip、Conda、npm、pnpm、uv、Docker、WSL 等清理操作。
- 执行 Git 清理、垃圾回收、历史重写或仓库维护操作。
- 停止、重启、强制结束任何正在运行的进程、服务或程序。
- 修改浏览器、IDE、AI 编程工具或其他应用程序的数据。
- 清理日志、崩溃转储、数据库或诊断文件。
- 执行会修改文件元数据或目录结构的操作。
- 启动可能自动生成项目文件的 IDE、构建系统或开发环境。
- 触发 Windows 存储感知、磁盘清理工具的实际执行。

所有清理行为必须留到后续单独授权的任务中。

审计报告直接输出到当前对话，不要主动向 D 盘或其他磁盘写入报告、脚本、日志、缓存或临时文件。

优先使用系统现有的只读查询接口，避免调用会主动生成大量日志、缓存、索引或其他持久化结果的工具。

需要说明：Windows 和正在运行的软件本身可能产生正常后台写入。本任务要求的是审计操作不主动修改系统状态，而不是声称能够阻止操作系统自身的所有后台写入。

### 2. 目录及数据保护

- 不读取个人文件正文、源代码正文、数据库内容、浏览器历史内容或其他敏感数据。
- 主要依据路径、名称、类型、大小、时间和必要的只读元数据判断。
- 不读取或输出 API Key、Token、密码、Cookie、SSH 私钥和其他凭据。
- 对 Symbolic Link、Junction、Reparse Point、Mount Point 不继续递归，避免循环、跨盘扫描和重复统计。
- 对无法访问的目录，不修改权限，不强行接管所有权，不触发 UAC 提权。
- 不将正在使用的软件、项目依赖、用户配置、数据库或重要资源直接归类为垃圾。
- 重要开发项目、训练数据、实验结果、模型权重、Git 仓库和唯一备份，默认应予以保护。
- 对无法确认是否仍被项目或软件使用的共享缓存，不得直接归类为低风险候选。
- 其他用途不明的数据默认保留。

### 3. CamAct 项目绝对保护（最高优先级）

以下目录属于明确保护对象：

`D:\projects\CamAct`

该目录及其所有子目录、文件、数据、依赖和历史产物，均不得作为删除、移动、修改、压缩或迁移对象。

保护范围包括但不限于：

- 项目源代码。
- Git 仓库及其历史数据。
- benchmark_zip。
- benchmark_pro_optimized。
- 各种 Benchmark 数据。
- 原始测试数据。
- 历史测评结果。
- 历史运行日志。
- 测评中间产物。
- 实验记录。
- 模型输出。
- 数据库。
- 虚拟环境。
- 构建产物。
- 缓存目录。
- 临时工作目录。
- 配置文件。
- 其他所有子目录及文件。

特别要求：

1. 可以根据严格只读的元数据统计 CamAct 的总体空间占用，并分析其占 D 盘空间的比例。
2. **不得将 CamAct 内部任何文件或目录列为清理、迁移、压缩或归档候选。**
3. 即使发现 `__pycache__`、`.pytest_cache`、历史日志、临时文件或其他看似可再生的内容，也不得推荐对其进行清理。
4. 不得以“可以重新生成”“已经过时”“属于缓存”等理由降低保护等级。
5. 不得执行任何可能影响其项目运行、测试记录、实验可复现性或数据完整性的操作。
6. 其他位置若存在可以明确识别的 CamAct 专属依赖、环境、模型或缓存，也应纳入保护。
7. 对无法确认是否被 CamAct 使用的共享开发资源，不得直接认定为可清理。
8. CamAct 的空间占用可以单独统计，但必须从全部可回收空间估算中排除。

**该保护规则高于本提示词中所有其他清理价值分析要求。**

### 4. 审计范围限制

本轮审计范围仅限 D 盘。

不得为扩大扫描范围而递归访问 C 盘或其他磁盘。

如果 D 盘中的符号链接、Junction 或挂载点指向其他磁盘，应记录其存在，但不继续递归。

如果某些 D 盘软件依赖 C 盘中的共享环境，可以通过现有只读元数据说明关联，但不得跨盘扫描或修改。

**本任务是严格只读审计，不是清理授权。**

---

## 三、第一阶段：D 盘全局空间审计

首先获取 D 盘真实存储信息：

- 总容量。
- 已使用空间。
- 剩余空间。
- 剩余比例。
- 文件系统类型。
- 卷类型和实际盘符映射。
- 是否启用 NTFS 压缩或其他相关存储机制。
- 可正常遍历的目录数量及文件数量。
- 未能访问或未统计的范围。

容量统一使用 GiB / MiB，必要时同时给出字节数。

特别注意：

1. 尽量区分逻辑文件大小与实际磁盘分配量。
2. 考虑 NTFS 压缩、稀疏文件、硬链接等因素。
3. 注意开发环境、包管理器、数据集和重复资源中的硬链接，避免重复计算实际占用。
4. 不能准确计算物理占用时，明确标注为逻辑大小。
5. 不得将父目录及其子目录容量重复相加。
6. 将扫描结果与卷级已用空间交叉核对。
7. 关注 NTFS 元数据、回收站、卷影副本、文件系统保留空间等普通目录扫描可能无法解释的占用。
8. 对不能解释的容量差额，尽可能通过只读系统接口调查。
9. 对大量小文件造成的文件系统分配开销，应在可测量的范围内进行说明。
10. 不得将文件逻辑大小的简单求和直接当作实际可释放空间。

需要特别区分：

- 普通项目文件和目录占用。
- 软件安装和开发环境占用。
- AI 模型与数据集占用。
- 历史实验结果、备份和构建产物。
- 缓存及临时文件占用。
- 回收站占用。
- 系统还原与卷影副本占用（如 D 盘实际启用）。
- 文件系统元数据占用。
- 隐藏文件和受保护目录占用。
- 扫描遗漏或权限受限的空间。

最终明确：

**D 盘已用空间中，哪些可以通过实际扫描解释，哪些属于系统管理、受保护资源或尚未解释的占用。**

---

## 四、第二阶段：完整目录占用审计

### 1. 建立一级目录完整排行榜

统计 `D:\` 下全部一级目录和根目录大型文件的占用。

重点包括但不限于实际存在的：

- `D:\projects`
- `D:\project`
- `D:\Projects`
- `D:\Software`
- `D:\Programs`
- `D:\Program Files`
- `D:\Program Files (x86)`
- `D:\ProgramData`
- `D:\Users`
- `D:\Downloads`
- `D:\Documents`
- `D:\Desktop`
- `D:\Data`
- `D:\Datasets`
- `D:\Models`
- `D:\AI`
- `D:\Cache`
- `D:\Temp`
- `D:\Backup`
- `D:\Archive`
- `D:\Games`
- `D:\$Recycle.Bin`
- `D:\System Volume Information`
- 其他实际存在的隐藏目录。
- D 盘根目录中的大型文件。

注意：

- 上述路径只是可能存在的目录类型，实际不存在的目录无需虚构。
- 不能仅凭目录名称判断其用途。
- 无权限访问的目录必须明确标记。
- 系统保护目录不得通过修改权限强行扫描。
- 对明确保护的 CamAct 项目，只能进行只读占用统计，不得列为后续清理对象。

输出：

- 一级目录完整排行榜。
- 最大目录 Top 30。
- 根目录大型单文件。
- 每个目录占 D 盘已用空间的比例。
- 主要目录的用途和性质。

### 2. 对大型目录深入递归

优先调查：

- 单个目录大于 1 GiB。
- 占 D 盘已用空间超过 3%。
- 存在大量缓存、日志或临时文件。
- 包含大量子目录，累计占用显著。
- 存在大量项目依赖、模型、数据集或实验输出。
- 存在历史备份、历史版本或重复安装包。
- 具有明显异常增长迹象的目录。

原则上深入 2～5 层，但不机械限制深度。

如果第 5 层仍未定位真正的占用来源，应在安全和权限允许的范围内继续向下追踪。

例如，不要只报告：

`D:\projects` 占用 60 GiB。

应继续深入：

`D:\projects\某项目`

再追踪到：

`D:\projects\某项目\.venv`

或者：

`D:\projects\某项目\outputs\checkpoints`

并尽可能说明：

- 当前占用多少 GiB。
- 是什么软件或项目产生的。
- 是源代码、依赖环境、缓存、模型、实验结果还是其他内容。
- 是否属于可再生资源。
- 是否可能影响现有项目。
- 是否存在历史版本或明显重复。
- 是否存在误删风险。
- 大致可能释放多少空间。

对于 CamAct 等明确保护对象，只做允许的只读统计，不提供内部清理建议。

### 3. 识别真正占空间的叶子目录

对主要占用来源尽量提供：

- 完整绝对路径。
- 当前目录大小。
- 文件数量。
- 主要文件类型及容量构成。
- 最大的几个文件或子目录。
- 文件修改时间分布。
- 所属软件、开发项目或数据资源。
- 可能形成占用的原因。
- 是否具备清理价值。
- 安全处理方式及前提。

避免只报告层层重复的父目录。

### 4. 大量小文件专项统计

除了大型单文件，还要识别：

- 文件数量极多的目录。
- 大量小型日志。
- Python 字节码缓存。
- Node.js 依赖。
- 包管理器文件缓存。
- Git 对象文件。
- 临时解压文件。
- 编译中间文件。
- 小型图片、帧文件和数据切片。
- 数据集预处理结果。
- 其他数量庞大的小文件。

重点分析：

1. 文件数量。
2. 逻辑总容量。
3. 实际分配空间（能够可靠获取时）。
4. 目录用途。
5. 是否属于可再生文件。
6. 是否存在清理风险。

不得因单个文件较小就忽略其累计空间占用。

---

## 五、第三阶段：D 盘开发项目与数据资源专项审计

这是 D 盘审计区别于 C 盘系统盘的重要部分。

需要重点调查以下内容。

### A. 开发项目与源代码仓库

重点分析 D 盘中实际存在的：

- 各类开发项目。
- Git 仓库。
- Python 项目。
- Node.js / Web 项目。
- C / C++ 项目。
- Java / Rust / Go 项目。
- AI / 机器学习项目。
- 算法实验项目。
- 课程实验项目。
- 历史竞赛项目。
- 其他工程目录。

重点回答：

1. 当前有哪些主要项目。
2. 每个项目总体占用多少空间。
3. 哪些项目明显占用较大。
4. 占用主要来自源代码、依赖、模型、数据、实验结果还是缓存。
5. 是否存在多个历史版本目录。
6. 是否存在大型构建文件或可再生产物。
7. 是否存在明显重复的项目副本。
8. 哪些项目可能仍在使用。
9. 哪些内容属于唯一数据或重要成果。
10. 哪些内容需要用户确认才可能处理。

特别注意：

- 不得修改项目文件。
- 不得执行项目构建。
- 不得安装依赖。
- 不得执行 Git 清理。
- 不得仅因项目长时间未修改就认定已经废弃。
- 不得将项目中的全部 `build`、`dist`、`output`、`logs` 等目录直接认定为垃圾。
- 必须考虑实验复现、历史测评结果和项目运行依赖。

CamAct 项目严格按照第二部分的绝对保护规则执行。

### B. 历史实验结果与构建产物

重点寻找：

- `outputs`
- `output`
- `results`
- `runs`
- `experiments`
- `checkpoints`
- `logs`
- `artifacts`
- `build`
- `dist`
- `target`
- `.next`
- `.nuxt`
- `.turbo`
- `.cache`
- `tmp`
- `temp`
- 历史测试产物。
- 训练中间文件。
- 推理输出。
- 历史模型 Checkpoint。
- 编译生成文件。
- 自动生成的数据处理结果。
- 其他项目中间产物。

分析：

- 总占用。
- 最大子目录。
- 文件数量。
- 修改时间。
- 是否存在多个历史运行版本。
- 是否存在重复实验输出。
- 是否属于可以重新生成的内容。
- 是否包含最终成果或唯一实验数据。
- 是否仍被当前项目依赖。

重点区分：

**可再生的构建缓存与具有科研、实验、测评价值的历史产物。**

不得简单地将历史实验结果或旧 Checkpoint 视为可删除文件。

尤其不能对 CamAct 的历史测评记录、中间产物或构建结果提出清理建议。

### C. 数据集与预处理资源

重点检查：

- 原始数据集。
- 解压后的数据集。
- 历史下载数据。
- 数据集缓存。
- 预处理数据。
- 训练集。
- 验证集。
- 测试集。
- 标注数据。
- 视频数据。
- 图像数据。
- 音频数据。
- Parquet / Arrow 数据。
- NumPy 数据。
- LMDB。
- 数据库。
- 数据集版本副本。

重点识别：

- 同一数据集是否存在多个版本。
- 压缩包与解压目录是否同时存在。
- 是否存在疑似重复下载。
- 是否存在历史预处理结果。
- 是否存在可以重新生成的缓存。
- 是否存在唯一原始数据。
- 是否被当前项目依赖。
- 是否适合后续归档或迁移。

注意：

1. 不读取数据集正文。
2. 不修改原始数据。
3. 不执行数据清洗或重建。
4. 不根据目录名称直接推断数据集重复。
5. 不将数据集总大小直接视为可清理空间。
6. 对无法证明已经存在可靠备份的数据，默认保留。

### D. AI 模型、权重与训练资源

重点检查：

- Hugging Face 模型。
- Transformers 模型。
- ModelScope 模型。
- Torch 权重。
- Ollama 模型。
- 本地推理模型。
- 历史训练 Checkpoint。
- LoRA / Adapter。
- 微调结果。
- 模型缓存。
- 自动下载模型。
- 预处理缓存。
- 推理中间文件。
- 多版本模型文件。

主要文件类型：

- `.safetensors`
- `.gguf`
- `.pt`
- `.pth`
- `.ckpt`
- `.bin`
- `.onnx`
- `.engine`
- `.pkl`
- `.npy`
- `.npz`

重点回答：

1. 哪些模型文件占空间最大。
2. 是否存在同一模型的多个版本。
3. 是否存在疑似重复权重。
4. 是否存在下载缓存和正式模型副本同时保留。
5. 是否存在历史实验中间权重。
6. 是否仍被项目使用。
7. 是否属于唯一训练成果。
8. 如果后续需要释放空间，是否适合迁移或归档。

特别注意：

Hugging Face、ModelScope 等缓存可能存在 Blob、Snapshot、符号链接等共享结构，必须避免重复计算。

不得因为模型较旧就认定可以删除。

不能确认是否仍被项目使用的模型，统一列为待确认。

### E. 压缩包、安装包、历史备份

重点检查：

- `.zip`
- `.7z`
- `.rar`
- `.tar`
- `.tar.gz`
- `.gz`
- `.iso`
- `.exe`
- `.msi`
- `.msix`
- `.bak`
- `.backup`
- `.old`
- 项目历史压缩包。
- 软件安装包。
- 历史版本备份。
- 下载完成后的安装文件。
- 自动备份目录。
- 历史导出数据。
- 其他存档文件。

重点分析：

- 当前占用。
- 文件修改时间。
- 是否存在多个历史版本。
- 是否属于已安装软件的安装包。
- 是否可能与已解压目录重复。
- 是否为唯一备份。
- 是否仍可能用于环境恢复或项目复现。
- 是否适合人工确认后清理或迁移。

注意：

压缩包和解压目录同时存在，并不能单独证明压缩包可以删除。

对于重要项目备份，应优先确认其是否具备唯一备份价值。

### F. Git 仓库与版本历史

检查实际存在的：

- `.git`
- Git 对象存储。
- Git LFS 数据。
- 历史仓库副本。
- 大型仓库。
- 工作树。
- 多版本项目副本。
- 与 Git 关联的构建文件。

重点分析：

- 仓库总体占用。
- `.git` 占用。
- 是否存在大型 Git LFS 文件。
- 是否存在多个仓库副本。
- 是否可能包含历史大文件。
- 是否存在疑似重复项目目录。

注意：

- 不执行 `git gc`。
- 不执行 `git prune`。
- 不执行 `git clean`。
- 不重写 Git 历史。
- 不修改分支或工作树。
- 不删除 `.git` 目录。
- 不以仓库历史较大为由直接建议清理。

如果无法在严格只读条件下安全确认 Git 内部具体占用来源，可以仅报告文件系统层面的统计。

---

## 六、第四阶段：软件安装目录与特殊大型文件审计

D 盘虽然通常不是 Windows 系统盘，但可能安装了大量软件、开发工具、游戏和应用程序。

因此，应重点调查 D 盘中实际存在的软件安装目录，而不是机械复制 C 盘的 Windows 系统组件审计。

### 1. 软件安装目录

重点检查实际存在的：

- `D:\Program Files`
- `D:\Program Files (x86)`
- `D:\Programs`
- `D:\ProgramData`
- `D:\Software`
- `D:\Applications`
- `D:\Tools`
- 各种自定义软件安装目录。
- 软件版本管理目录。
- 历史安装目录。
- 便携版软件目录。

分别说明：

- 当前目录大小。
- 所属软件。
- 软件主要用途。
- 是否属于正在使用的软件。
- 是否存在多个安装版本。
- 是否存在大型缓存。
- 是否存在安装器或自动更新残留。
- 是否包含软件必需资源。
- 是否存在理论可回收空间。

特别要求：

不得将整个软件安装目录列为普通缓存清理项。

不得因为软件目录长期未修改，就认定其不再使用。

如发现疑似旧版本，应说明如何通过后续人工确认、软件自身卸载机制或其他正规方式处理。

### 2. 软件安装器与自动更新缓存

重点寻找：

- 历史安装包。
- 自动更新下载文件。
- 版本升级残留。
- 安装解压缓存。
- 软件包缓存。
- 软件部署产物。
- 历史驱动安装包。
- 游戏更新缓存。
- 其他安装器数据。

重点区分：

- 软件运行必需文件。
- 修复或卸载需要的安装缓存。
- 可重新下载的资源。
- 疑似历史残留。
- 用户主动保存的安装包。

不得仅根据扩展名判断是否可删除。

### 3. 虚拟内存与系统管理文件

检查 D 盘是否实际存在：

- `D:\pagefile.sys`
- `D:\swapfile.sys`
- `D:\hiberfil.sys`
- 其他系统管理的大型特殊文件。

特别注意：

与 C 盘不同，D 盘通常不是 Windows 启动系统所在卷。

不能假设 D 盘一定存在虚拟内存、休眠文件或 Windows 系统组件。

如果存在相关文件，应先判断其是否为当前 Windows 实际使用的系统管理文件，还是历史系统安装残留。

分别说明：

- 当前大小。
- 所属功能。
- 是否由 Windows 自动管理。
- 是否影响系统运行。
- 是否存在配置层面的空间优化途径。
- 调整可能产生的功能、性能和稳定性影响。

不得直接删除这些文件。

不得修改虚拟内存配置。

不得关闭任何系统功能。

### 4. D 盘回收站、卷影副本与受保护空间

重点调查：

- `D:\$Recycle.Bin`
- `D:\System Volume Information`
- D 盘卷影副本。
- D 盘系统保护数据。
- 文件系统元数据。
- 其他隐藏或受保护的存储。

对无法通过普通文件遍历统计的区域，优先使用现有只读系统接口。

需要说明：

- 当前占用。
- 是否属于 D 盘实际使用空间。
- 是否存在潜在回收价值。
- 后续需要通过什么 Windows 官方机制处理。
- 是否会影响文件恢复或备份。

不得：

- 清空回收站。
- 删除卷影副本。
- 删除系统还原数据。
- 接管受保护目录。
- 修改系统保护设置。
- 删除文件系统元数据。

### 5. 历史 Windows 安装或系统残留

如果 D 盘实际存在：

- `D:\Windows`
- `D:\Windows.old`
- `D:\Recovery`
- 历史系统备份目录。
- 旧系统迁移文件。
- 旧版 Windows 安装文件。

需要首先判断：

1. 是否属于当前正在使用的 Windows 系统。
2. 是否属于历史安装。
3. 是否包含系统回滚或恢复数据。
4. 是否属于用户主动保存的系统备份。
5. 是否存在官方支持的处理方式。

如果不存在，直接注明，不必展开。

特别注意：

**不得将 C 盘的 WinSxS、Windows Installer、DriverStore、SoftwareDistribution 等审计要求无条件套用到 D 盘。**

只有 D 盘实际存在相关文件，并且确实占用 D 盘容量时，才进行对应分析。

---

## 七、第五阶段：项目目录与用户数据深度审计

这是本次 D 盘审计的重点之一。

D 盘往往保存大量开发项目、用户主动存储的数据、软件下载资源，以及部分迁移或重定向后的应用数据。

### 1. 项目目录完整分析

逐个调查 D 盘中实际存在的主要开发项目目录。

重点包括：

- 项目源代码。
- 隐藏开发目录。
- 虚拟环境。
- 项目依赖。
- Git 数据。
- 构建输出。
- 测试输出。
- 实验日志。
- Checkpoint。
- 数据集。
- 中间产物。
- 最终成果。
- 历史版本。

统计：

- 每个项目总体占用。
- 最大的项目。
- 各项目主要占用构成。
- 大型隐藏目录。
- 大型文件。
- 疑似历史资源。
- 可再生缓存候选。

不读取源代码正文或敏感内容。

特别注意：

开发项目中的 `logs`、`results`、`outputs` 等目录可能具有重要价值。

不得将其整体列为普通缓存。

对 CamAct 继续执行绝对保护规则。

### 2. 重定向用户目录与应用数据

如果 D 盘实际存在用户目录或重定向路径，重点调查：

- Desktop。
- Downloads。
- Documents。
- Pictures。
- Videos。
- AppData\Local。
- AppData\Roaming。
- AppData\LocalLow。
- 用户主目录中的隐藏开发工具目录。
- 自定义用户数据目录。

统计：

- 每个用户目录总体占用。
- 最大的用户数据目录。
- 应用数据占用。
- 大型隐藏目录。
- 大型文件。
- 历史资源。

注意：

只有相关目录实际位于 D 盘时才进行扫描。

不得为了补全 AppData 分析而递归扫描 C 盘。

### 3. 应用数据和软件缓存深度追踪

重点寻找：

- 浏览器缓存。
- 桌面应用缓存。
- IDE 缓存。
- AI 工具缓存。
- Python 和 Node.js 包缓存。
- 应用日志。
- 自动更新下载包。
- 历史版本缓存。
- 软件崩溃转储。
- 临时文件。
- 其他长期累积的应用数据。

不要只输出某个软件目录的总容量。

对超过 500 MiB 的主要应用数据目录，尽可能继续追踪具体占用来源。

对于多个较小但合计占用明显的缓存目录，也需要汇总统计。

特别注意：

应用目录可能包含用户账户状态、软件配置、数据库、会话历史和其他重要数据。

不得将整个应用数据目录视为可清理缓存。

### 4. D 盘临时文件目录

重点检查实际存在的：

- `D:\Temp`
- `D:\TMP`
- `D:\Cache`
- 软件自定义临时目录。
- 项目构建临时目录。
- 下载或解压临时目录。
- 环境变量指向 D 盘的临时目录。

分析：

- 总占用。
- 文件数量。
- 最大文件。
- 修改时间分布。
- 是否存在长期累积文件。
- 是否包含当前仍在使用的文件。
- 是否存在软件安装、解压或更新残留。
- 是否存在已结束任务留下的临时资源候选。

不要仅凭文件位于 Temp 目录，就断言其全部可以安全删除。

---

## 八、第六阶段：浏览器与常用软件缓存审计

重点检查实际将软件、用户数据或缓存存储在 D 盘的应用程序。

### A. 浏览器

如 D 盘实际存在相关目录，调查：

- Google Chrome。
- Microsoft Edge。
- Firefox。
- 其他 Chromium 浏览器。
- 浏览器便携版。
- 重定向的浏览器缓存目录。

重点识别：

- HTTP Disk Cache。
- GPUCache。
- Code Cache。
- Service Worker CacheStorage。
- Media Cache。
- Crashpad 崩溃数据。
- 浏览器自动更新残留。
- 多个浏览器配置目录中的重复缓存。

统计每个浏览器及用户配置的大致占用。

特别注意区分：

**可再生缓存与重要用户数据。**

以下内容不得直接列为普通缓存清理项：

- 登录会话。
- Cookies。
- 密码。
- 浏览历史。
- 书签。
- 扩展配置。
- 用户 Profile 数据库。
- Local Storage。
- IndexedDB 等可能存储重要应用数据的区域。

对于浏览器缓存，优先评估后续通过浏览器官方界面清理的可能性，而不是直接删除整个用户配置目录。

### B. IDE 与开发工具

重点检查实际存在的：

- VS Code。
- Visual Studio。
- JetBrains 系列 IDE。
- Cursor。
- Codex CLI。
- Claude Code。
- Gemini CLI。
- 其他 AI 编程工具和 IDE。

重点分析：

- 缓存。
- 索引。
- 扩展文件。
- 扩展下载残留。
- 工作区缓存。
- 历史日志。
- 临时数据。
- 会话历史。
- 工具下载资源。
- 自动更新残留。
- 软件安装目录。
- 多版本程序文件。

注意：

AI 编程工具的会话记录、项目上下文、凭据和配置可能具有重要价值。

不得将 `.codex`、`.claude`、`.gemini`、IDE 用户数据目录等整体视为可删除缓存。

需要深入区分其中可再生内容与重要数据。

### C. 其他桌面软件

检查 D 盘中实际存在的其他大型应用数据，例如：

- 通讯软件。
- 云盘客户端。
- 下载工具。
- 视频软件。
- Office。
- 游戏平台。
- 游戏安装目录。
- 开发辅助工具。
- 远程桌面工具。
- 虚拟机管理软件。
- 其他桌面应用。

重点寻找：

- 历史安装包。
- 自动更新下载缓存。
- 重复资源。
- 大型日志。
- 临时文件。
- 可再生媒体缓存。
- 历史软件版本。
- 软件生成的中间文件。

说明软件来源和清理风险。

不得因为软件安装在 D 盘，就将其整个目录视为可迁移或删除。

---

## 九、第七阶段：开发环境与 AI 资源专项审计

重点寻找分散在 D 盘项目目录、软件安装目录、自定义环境目录及其他位置中的资源。

### A. Python、pip、uv、Conda

检查实际存在的：

- Python 安装目录。
- Conda / Miniconda / Anaconda。
- `.conda`
- pip 缓存。
- uv 缓存。
- Poetry 缓存。
- 虚拟环境。
- `.venv`
- `venv`
- `env`
- `__pycache__`
- `.pytest_cache`
- `.mypy_cache`
- `.ruff_cache`
- 历史构建和测试输出。

重点判断：

1. 当前 Python 环境有多少套。
2. 各套环境分别占用多少空间。
3. 包下载缓存是否异常庞大。
4. 是否存在重复依赖资源。
5. 是否有旧环境和新环境并存。
6. 是否存在可再生缓存。
7. 环境是否可能与正在使用的项目关联。
8. 是否存在项目专属环境与全局环境。
9. 是否存在大量重复安装的第三方库。
10. 是否存在已经无法确认用途的环境。

不得简单建议删除整个 Python、Conda 或虚拟环境目录。

对共享包缓存要特别谨慎。

对于项目内部的环境，必须明确其所属项目。

CamAct 及其相关环境不得列为清理候选。

### B. Node.js、npm、pnpm、yarn

检查：

- Node.js 安装及版本管理目录。
- npm 缓存。
- pnpm Store。
- yarn 缓存。
- Corepack 缓存。
- `node_modules`
- `.next`
- `.nuxt`
- `.turbo`
- 构建输出。
- 历史依赖包。
- 软件包下载缓存。

分析：

- 全局缓存占用。
- 各项目依赖占用。
- 多套依赖是否存在重复。
- 哪些是可再生的构建缓存。
- 哪些是当前项目依赖。
- 是否存在历史构建输出。
- 是否存在已经停止使用的项目环境候选。

特别注意：

pnpm 等包管理器可能存在硬链接或共享存储，不能直接把各目录逻辑大小相加当成真实可回收空间。

不能因为多个项目存在相似依赖，就直接认定删除其中一份可以释放对应容量。

### C. 其他开发工具

如实际存在，调查：

- Rust / Cargo。
- Java / Maven / Gradle。
- C / C++ 工具链。
- .NET / NuGet。
- Go。
- Visual Studio 构建缓存。
- Windows SDK。
- Qt / Quartus / ModelSim 等开发工具。
- 编译器缓存。
- 历史安装包。
- 各种构建输出目录。
- 多版本 SDK。
- 历史编译产物。

重点识别大型但可再生的依赖下载缓存和历史构建产物。

同时区分：

- 软件本身的安装文件。
- 当前依赖的 SDK。
- 项目特定环境。
- 下载缓存。
- 可再生编译缓存。
- 历史版本资源。

不得直接删除正在使用的工具链。

### D. AI 模型、数据集与实验缓存

重点检查：

- Hugging Face 缓存。
- Transformers 缓存。
- Torch 缓存。
- ModelScope 缓存。
- Ollama 模型目录。
- 其他本地 AI 模型缓存。
- `.safetensors`
- `.gguf`
- `.pt`
- `.pth`
- `.ckpt`
- `.bin`
- `.onnx`
- 大型数据集。
- 历史 Checkpoint。
- 推理输出。
- 训练日志。
- 临时预处理数据。

尤其关注：

- D 盘项目目录中自动下载的模型。
- 多个 AI 工具重复保存的模型。
- 相同模型的多版本缓存。
- 缓存中未被当前项目使用的历史资源候选。
- 已存在于其他位置的疑似重复资源。
- 历史实验产生的中间权重。
- 临时转换格式产生的模型副本。

不得仅因为模型文件较旧就判断其已经废弃。

不能确认是否被现有项目使用的模型，统一列为待确认。

### E. 项目相关缓存保护

对可能属于重要项目的：

- 虚拟环境。
- 包缓存。
- 构建产物。
- 模型权重。
- 数据集。
- 实验结果。
- 测评记录。
- 工具配置。
- Checkpoint。
- 数据处理产物。

应调查其空间占用，但不得擅自归类为无用。

特别保护 CamAct 相关全部文件、依赖和缓存。

### F. 开发环境重复占用分析

重点检查：

- 多套 Python 环境中重复安装的包。
- 不同项目中的多个 `node_modules`。
- 多版本 SDK。
- 多套编译工具链。
- 重复模型依赖。
- 重复下载的安装包。
- 多项目共享缓存。
- 不同包管理器各自保存的下载资源。

特别要求：

1. 识别可能存在的重复资源。
2. 区分硬链接共享与真实副本。
3. 不得只根据同名目录认定可以回收。
4. 不得建议直接删除仍被项目使用的环境。
5. 对重复环境的潜在回收收益必须保守估算。
6. 对未知依赖一律标记为待确认。

---

## 十、第八阶段：WSL、Docker、Hyper-V 与虚拟磁盘

调查 D 盘中是否存在：

- WSL 发行版虚拟磁盘。
- Docker Desktop 数据。
- Docker 镜像存储。
- Docker Volume。
- Hyper-V 虚拟磁盘。
- VirtualBox / VMware 磁盘。
- `.vhd`
- `.vhdx`
- `.vmdk`
- `.qcow2`
- 其他虚拟机镜像或备份。

重点分析：

1. 虚拟磁盘文件的完整路径。
2. Windows 文件系统中当前实际占用。
3. 逻辑文件大小与实际分配量。
4. 是否存在多个发行版或历史虚拟磁盘。
5. 是否可能因容器、镜像、日志或缓存持续增长。
6. 是否存在理论可回收空间。
7. 后续应采用什么正确的管理方式。
8. 是否存在当前正在使用的虚拟机。
9. 是否存在历史快照或备份。
10. 是否存在无法确认用途的虚拟磁盘。

特别区分：

- 虚拟磁盘当前占用。
- 虚拟磁盘内部已使用空间。
- 虚拟磁盘内部空闲空间。
- Windows 端真正可能释放的容量。

如果无法在严格只读、不启动或影响相关环境的条件下获取内部使用量，应明确说明。

不得执行：

- Docker prune。
- Docker image / volume 删除。
- WSL compact。
- VHDX compact。
- WSL unregister。
- 虚拟磁盘压缩。
- 发行版卸载。
- 虚拟机快照删除。

也不得为了调查而启动已停止的虚拟机或相关服务。

---

## 十一、第九阶段：大型文件、重复资源与历史产物

### 1. 最大单文件审计

统计：

- D 盘最大单文件 Top 50。
- 所有大于 1 GiB 的文件。
- 大型文件的主要类型分布。

重点关注：

- `.zip`、`.7z`、`.rar`、`.tar`
- `.exe`、`.msi`、`.iso`
- `.vhd`、`.vhdx`
- `.pt`、`.pth`、`.safetensors`、`.gguf`
- `.npy`、`.npz`、`.parquet`
- `.mp4`、`.mkv`
- `.dmp`、`.etl`、`.log`
- `.bak`、`.old`、`.tmp`
- 大型数据库。
- 大型模型文件。
- 数据集压缩包。
- 项目历史备份。
- 其他未知大型文件。

对重要文件说明：

**完整路径 | 文件大小 | 类型 | 可能用途 | 修改时间 | 清理价值 | 风险等级**

不得读取文件正文或进行全量哈希计算。

### 2. 重复资源候选

寻找：

- 同名同大小的大型文件。
- 重复安装包。
- 相同模型的多份缓存。
- 相同数据集的多个副本。
- 多套 Python 或 Node.js 环境。
- 历史版本压缩包。
- 重复项目目录。
- 软件更新残留。
- 已解压目录与原始压缩包同时存在的情况。
- 不同路径中的疑似相同视频、图片和数据文件。
- 多个版本的项目备份。

对于疑似重复资源，列出相关路径及大小。

注意：

- 仅凭名称和大小不能证明内容完全相同。
- 不执行完整哈希验证。
- 不得将未经校验的疑似重复文件直接计入保守可回收收益。
- 如果不同路径对应同一个硬链接文件或共享存储，不得重复计算容量。
- 不得对受保护项目执行去重或合并。
- 不得将 CamAct 的任何数据作为重复文件清理候选。

### 3. 陈旧文件分析

对大型候选文件和目录中的文件，按最后修改时间分组：

- 最近 7 天。
- 8～30 天。
- 31～90 天。
- 91～180 天。
- 超过 180 天。

重点分析：

- 很久未修改的大型缓存。
- 历史软件安装包。
- 旧构建产物。
- 历史压缩包。
- 长期累积的诊断文件。
- 旧模型和训练输出。
- 历史备份。
- 长期未更新的项目目录。

注意：

修改时间不等于最后使用时间。

不得单纯按照文件年龄建议删除。

对历史科研成果、测评数据、原始数据和唯一备份应特别谨慎。

### 4. 压缩包与解压目录关联分析

重点寻找：

- 压缩包及其疑似解压目录。
- 安装包及其已安装程序。
- 数据集下载包及解压数据。
- 模型压缩包及解压权重。
- 项目备份压缩包及当前项目目录。

尝试通过名称、目录结构、文件数量及时间等只读元数据建立候选关联。

需要说明：

1. 是否有较强证据支持二者关联。
2. 是否能够确认文件内容重复。
3. 哪些文件可能仍是唯一备份。
4. 是否具有理论空间回收潜力。
5. 为什么需要进一步人工确认。

没有充分证据时，只能标记为疑似重复。

---

## 十二、第十阶段：持续增长与异常占用分析

识别可能持续增长的目录：

- 开发项目输出。
- Python 环境和缓存。
- npm / pnpm / yarn 缓存。
- IDE 缓存。
- AI 编程工具会话与缓存。
- Hugging Face / Torch / ModelScope 缓存。
- 模型下载目录。
- 数据集缓存。
- 训练 Checkpoint。
- 推理输出。
- 项目运行日志。
- 自动备份。
- Docker / WSL 虚拟磁盘。
- 编译和测试产物。
- 浏览器缓存。
- 下载目录。
- 临时文件。
- 软件更新缓存。
- 游戏更新文件。
- 其他应用缓存。

针对主要对象说明：

1. 当前占用。
2. 主要文件类型。
3. 文件时间分布。
4. 是否有多个历史版本。
5. 是否存在持续累积的迹象。
6. 如果不处理，未来可能造成什么存储风险。
7. 后续有什么安全控制或管理方式。

重点识别：

- 某些项目是否每次运行都产生独立输出。
- 是否存在大量历史训练目录。
- 是否存在持续新增的 Checkpoint。
- 是否存在不断累积的日志。
- 是否存在工具自动下载资源。
- 是否存在自动备份持续保留历史版本。
- 是否存在异常膨胀的依赖目录。

单次扫描不能证明真实增长速率。

不得编造每天增长多少 GiB。

对于没有历史数据支持的判断，明确标记为“疑似持续增长”。

不得为了验证增长而长时间运行监控或创建额外日志文件。

---

## 十三、第十一阶段：清理价值与风险分类

所有潜在回收对象必须按照以下标准分类。

### P1：低风险、高收益候选

主要考虑：

- 有证据支持的可再生缓存。
- 历史临时文件候选。
- 明确不包含关键配置的非活跃缓存。
- 可重新下载或重新生成的资源。
- 明显积累的非关键历史日志候选。
- 已确认与当前项目无关的历史构建缓存。
- 已确认不影响使用的软件更新下载缓存。

要求：

- 具体路径。
- 当前占用。
- 预计可回收空间。
- 判断依据。
- 清理前提。
- 恢复难度。
- 是否可能影响软件正常运行。
- 是否可能影响现有开发项目。

P1 也不代表本轮可以执行删除。

对于有任何重要依赖疑虑的内容，不得归入 P1。

### P2：应通过 Windows 官方工具或软件自身机制处理

例如：

- D 盘回收站。
- D 盘卷影副本。
- Windows 管理的特殊文件。
- 软件安装器缓存。
- 软件自动更新残留。
- Docker 数据。
- WSL 虚拟磁盘。
- Conda / 包管理器缓存。
- 游戏平台缓存。
- 软件版本管理目录。
- 需要专用工具处理的缓存。
- 实际位于 D 盘的其他系统管理数据。

说明：

- 当前占用。
- 可能的回收收益。
- 正确处理途径。
- 前置条件。
- 对系统或软件的潜在影响。

不得给出直接暴力删除软件安装目录、系统管理文件或虚拟磁盘的建议。

### P3：适合迁移或归档

例如：

- 大型下载文件。
- 历史压缩包。
- 大型模型。
- 数据集。
- 视频文件。
- 历史项目成果。
- 大型备份。
- 历史实验数据。
- 旧版安装包。
- 不需要频繁访问的大型资源。

说明：

- 迁移后可能释放多少空间。
- 是否为唯一副本。
- 是否被现有软件依赖。
- 是否需要调整路径。
- 是否建议先验证备份完整性。
- 迁移是否会影响项目运行。
- 是否存在更适合的归档方式。

本轮仅进行分析，不执行迁移。

明确保护的项目不得列为 P3。

### P4：高风险，不应直接删除

包括：

- 重要项目源代码。
- Git 数据。
- 当前使用的软件。
- 活跃虚拟环境。
- 当前项目依赖。
- 用户配置。
- 数据库。
- 虚拟磁盘。
- 模型权重。
- 唯一数据集。
- 重要实验结果。
- 历史测评记录。
- 唯一备份。
- 当前运行所需的 SDK。
- 系统管理文件。
- 明确保护的项目及其缓存。

**`D:\projects\CamAct` 及其所有子目录、文件和关联资源，必须归入绝对保护对象。**

允许统计占用，但不得将其作为直接删除、迁移或压缩候选。

### P5：用途未知，需要人工确认

对无法可靠判断用途的内容，统一标记为待确认。

重点包括：

- 不明软件目录。
- 无法确认归属的缓存。
- 无法确认用途的虚拟环境。
- 未知项目备份。
- 疑似重复但未验证的数据。
- 长期未修改但可能重要的资源。
- 其他高占用的未知文件。

不得为了提高理论可回收容量而将未知内容归入低风险候选。

---

## 十四、第十二阶段：空间回收潜力估算

基于实际扫描结果，分别估算：

### 1. 保守低风险可回收空间

仅包含证据充分、恢复成本较低且处理前提明确的候选。

例如：

- 已确认可再生的缓存。
- 已确认非活跃的临时文件。
- 有充分依据的非关键日志候选。
- 已确认不影响项目运行的构建缓存。

不包含任何 CamAct 文件。

### 2. 条件性可回收空间

包括：

- 需要先确认用途的缓存。
- 需要软件专用工具处理的数据。
- 可能属于历史版本的软件资源。
- 需要先确认是否仍使用的旧环境。
- 需要人工确认的历史安装包。
- 疑似重复但尚未验证的资源。

不能把全部条件性候选都当作一定能够释放的空间。

### 3. 迁移可释放空间

包括：

- 可迁移的模型。
- 数据集。
- 大型个人文件。
- 备份。
- 历史项目归档。
- 视频素材。
- 大型历史实验结果。

必须以迁移完成且确认源文件可以安全移除为前提。

明确保护的 CamAct 项目及其资源不得计入。

### 4. 软件或系统配置优化潜力

单独评估：

- 虚拟磁盘可优化空间。
- 软件缓存位置调整。
- 软件自动下载缓存管理。
- 可安全调整的数据保存策略。
- D 盘虚拟内存占用（如存在）。
- 卷影副本或其他系统管理空间（如存在）。

此类属于改变软件或系统配置，不得与普通缓存清理混为一谈。

只有能够合理估算时才给出容量。

### 5. 综合理论上限

计算所有候选经验证并成功处理后的潜在释放容量。

要求：

- 对父子目录去重。
- 对重复候选去重。
- 对硬链接和共享存储避免重复计算。
- 同一文件不能同时计入清理和迁移收益。
- 软件配置优化单独列示，避免混入普通低风险清理。
- 不得将受保护项目及其缓存计入可回收空间。
- 不得将虚拟磁盘内部空闲空间直接视为 Windows 可立即回收空间。
- 不得将逻辑文件大小直接视为保证释放的物理容量。
- 不得将未经验证的重复资源计入保守回收量。
- 不能可靠估算的部分给出区间或标记为无法确定。

最终尽可能给出：

- 当前 D 盘剩余容量。
- 完成保守低风险清理后的预计剩余容量。
- 完成条件性清理后的预计剩余容量。
- 完成迁移后的预计剩余容量。
- 综合理论上限对应的剩余容量。

所有容量估算必须说明假设条件。

同时区分：

**实际能够释放的磁盘空间与仅仅看起来重复的逻辑文件大小。**

---

## 十五、执行方式与效率要求

1. **直接执行完整审计，不要停留在计划介绍。**
2. 优先使用 Windows 自带 PowerShell、CIM、文件系统元数据和安全只读查询接口。
3. 先完成 D 盘整体扫描，再对主要占用区域深度分析。
4. 优先遍历并统计目录元数据，避免反复全盘扫描。
5. 控制内存和 CPU 占用，不影响现有开发任务。
6. 避免将全部文件元数据一次性加载到内存。
7. 可以分阶段统计，但尽量复用已获取的数据。
8. 不下载、安装或更新任何软件。
9. 不启动额外的后台服务。
10. 不修改系统配置。
11. 不执行会主动进行磁盘清理、修复或优化的命令。
12. 不使用可能大量写入磁盘的分析工具。
13. 遇到访问拒绝时记录原因并继续审计其他区域。
14. 遇到 Reparse Point、Junction 或 Mount Point，记录但不跨路径递归。
15. 对已经明确属于重要项目、用户数据或软件核心文件的目录，应优先通过只读元数据分析，避免不必要的内容读取。
16. 对大型用户缓存、软件缓存和开发环境，尽可能深入到具体可操作目录。
17. 保持审计过程稳定，避免占用大量系统资源导致软件卡顿。
18. 不因单个目录统计失败而提前结束。
19. 对未覆盖区域、权限限制、统计误差和未知占用如实说明。
20. 不为了追求扫描覆盖率而修改安全边界。
21. 不执行会创建、初始化或重建项目文件的命令。
22. 不执行包管理器清理或环境重建。
23. 不对 CamAct 执行任何修改操作。
24. 不追踪指向 C 盘或其他磁盘的符号链接。
25. 对大量小文件目录，优先采用高效的文件系统元数据统计方式。
26. 对已知目录结构，避免重复递归遍历。
27. 对超过 1 GiB 的主要资源优先定位真实占用来源。
28. 不运行训练、推理、编译或项目测试来判断文件用途。

特别要求：

如果 D 盘本身空间紧张，应避免使用需要在 D 盘生成大型临时数据的分析方法。

本轮报告应直接通过当前对话输出，不需要生成额外文件。

如果审计耗时较长，可以按阶段汇报进度，但应继续完成其他安全可执行的扫描，不要在只完成根目录分析后提前结束。

---

## 十六、最终报告格式

所有结论必须来自当前电脑的实际扫描和只读查询结果。

不得用常见 Windows 经验数据冒充本机实测数据。

重点输出能够指导下一轮安全清理的具体证据和结论，不要堆砌无关的原始命令日志。

### 1. D 盘空间总览

| 指标 | 数值 |
|---|---|
| 总容量 | |
| 已使用 | |
| 剩余空间 | |
| 剩余比例 | |
| 可解释的文件占用 | |
| 系统管理或保留空间 | |
| 无法解释或未覆盖的空间 | |
| 扫描文件数量 | |
| 扫描目录数量 | |

同时说明统计口径、扫描覆盖率和误差来源。

### 2. D 盘空间占用 Top 10 根因

按主要占用来源排序。

每项包括：

- 具体路径。
- 占用大小。
- 实际存储内容。
- 所属软件、开发项目或数据资源。
- 为什么会产生这些文件。
- 是否具备回收价值。
- 是否存在安全处理方式。

重点区分：

**重要项目数据、软件正常占用、可再生缓存、历史残留、重复资源和未知占用。**

### 3. 最大目录排行榜

至少展示 Top 30，实际不足 30 项则列出全部。

| 排名 | 完整路径 | 大小 | 主要内容 | 所属软件/项目 | 清理价值 |
|---|---|---|---|---|---|

对主要大目录进一步展开到真正占空间的子目录。

避免父子目录重复进入同一层级排行榜而导致误导。

对 CamAct 可以记录占用，但清理价值必须明确标为“绝对保护，不参与清理”。

### 4. 最大单文件排行榜

至少展示 Top 30，实际不足 30 项则列出全部。

| 排名 | 完整路径 | 大小 | 类型/用途 | 修改时间 | 风险与建议 |
|---|---|---|---|---|---|

对于超过 1 GiB 的其他文件，额外列出全部相关文件或合理分组。

### 5. 开发项目与数据资源专项分析

分别说明：

- 主要开发项目。
- Git 仓库。
- Python 项目环境。
- Node.js 项目依赖。
- 历史构建产物。
- 实验结果。
- 模型 Checkpoint。
- AI 模型与数据集。
- 历史下载文件。
- 压缩包。
- 项目备份。
- 疑似重复项目。
- 大量小文件。
- 其他隐藏占用。

每项包含：

- 当前占用。
- 主要内容。
- 所属项目或软件。
- 是否属于正常占用。
- 是否存在可回收潜力。
- 是否可以重新生成。
- 是否需要人工确认。
- 手动处理风险。

对重要项目单独强调保护要求。

### 6. 软件安装目录与用户数据占用

重点展示：

- D 盘软件安装目录。
- 自定义应用程序目录。
- 软件更新缓存。
- 重定向用户目录（如存在）。
- AppData 数据（如实际位于 D 盘）。
- 临时文件。
- 浏览器缓存。
- IDE 和 AI 工具缓存。
- 其他大型软件缓存。
- 游戏和其他应用资源。

务必深入到具体软件和具体目录。

### 7. 开发环境与 AI 资源占用

单独汇总：

- Python / pip / uv / Conda。
- Node.js / npm / pnpm / yarn。
- Visual Studio / VS Code / JetBrains。
- Codex CLI / Claude Code / Gemini CLI。
- Hugging Face / Torch / ModelScope。
- AI 模型与数据集。
- 项目虚拟环境。
- 构建与测试缓存。
- Docker / WSL / 虚拟机。
- 其他大型开发工具。

说明具体路径、占用大小和潜在回收价值。

### 8. 潜在清理候选清单（最重要）

尽可能全面列出所有值得进一步核实的候选。

按“预计可回收空间 × 安全程度 × 操作成本”综合排序。

| 优先级 | 完整路径 | 当前占用 | 预计可回收 | 具体内容 | 清理依据 | 风险与前提 | 建议处理方式 |
|---|---|---|---|---|---|---|---|

要求：

1. 不要只列 5～10 项。
2. 尽可能找全有实际价值的候选。
3. 优先精确到可以单独处理的目录或文件。
4. 对分散在多个位置的小型缓存进行合理汇总。
5. 不得把同一个文件重复计入多个候选。
6. 对无法确认的内容明确标记。
7. 对需要软件官方清理机制的内容单独说明。
8. 不得把重要项目文件伪装成低风险候选。
9. 不得把受保护项目及其依赖列为候选。
10. 每项必须明确说明为什么值得考虑回收。
11. 对有实际清理价值但仍存在风险的对象，列出具体风险及需要用户确认的事项。
12. 对可能影响实验复现、历史测评或开发环境的文件，必须明确说明。

特别要求：

**清理候选清单不得出现任何 `D:\projects\CamAct` 内部文件或目录，也不得包含其能够明确识别的专属依赖和缓存。**

### 9. 持续增长风险

列出可能持续增长的目录。

| 完整路径 | 当前大小 | 增长来源 | 判断依据 | 风险程度 | 后续建议 |
|---|---|---|---|---|---|

区分已确认事实和推测。

### 10. 不建议清理的高风险目录

| 完整路径 | 当前占用 | 主要用途 | 不建议直接清理的原因 |
|---|---|---|---|

重点保护：

- CamAct 项目及其全部子目录。
- 重要开发项目。
- Git 仓库。
- 活跃开发环境。
- 当前项目依赖。
- 模型权重。
- 原始数据集。
- 实验结果。
- 历史测评数据。
- 用户配置。
- 数据库。
- 虚拟磁盘。
- 软件安装目录。
- 其他无法确认的关键资源。

### 11. 空间回收潜力汇总

| 类别 | 预计可释放容量 | 风险 | 前提 |
|---|---|---|---|
| 保守低风险候选 | | | |
| Windows/软件专用清理候选 | | | |
| 其他条件性清理候选 | | | |
| 迁移与归档候选 | | | |
| 软件/系统配置优化潜力 | | | |
| 综合理论上限（去重） | | | |

注意：

分类展示可以保留不同处理方式，但综合理论上限必须按实际底层文件和存储空间去重。

给出不同处理情景下预计的 D 盘剩余空间，并说明估算误差。

CamAct 及其受保护资源不得计入任何可释放空间。

### 12. 最终行动优先级 Top 10～20

根据实际调查结果，明确下一轮最值得优先处理的具体对象。

每项说明：

1. 具体绝对路径。
2. 当前保存的是什么。
3. 占用多少空间。
4. 预计可以释放多少空间。
5. 为什么建议优先处理。
6. 是否有依赖或数据安全风险。
7. 清理前需要确认什么。
8. 后续应通过 Windows、软件官方工具还是人工确认后处理。
9. 是否容易恢复。
10. 是否值得实际处理。

不要只建议：

“清理项目缓存”

“清理软件缓存”

“删除临时文件”

“删除旧环境”

“清理模型”

“删除历史实验结果”

“删除重复项目”

必须给出本机实际发现的具体路径、容量及判断依据。

---

## 十七、审计完成标准

只有满足以下条件，才认为本轮审计完成：

- 已统计 D 盘总体容量和使用情况。
- 已完成根目录与主要隐藏目录的全面审计。
- 已深入主要大型目录。
- 已找到最大目录和最大单文件。
- 已调查主要开发项目和项目依赖。
- 已调查 Git 仓库和历史项目资源。
- 已调查历史构建和实验产物。
- 已调查模型权重、数据集与 AI 资源。
- 已调查软件安装目录和更新缓存。
- 已调查 D 盘回收站、卷影副本和其他系统管理空间。
- 已检查特殊大型系统文件（如实际存在）。
- 已调查 D 盘实际存在的用户数据目录。
- 已调查浏览器、IDE 和 AI 编程工具缓存。
- 已调查 Python、Conda、Node.js 等开发环境。
- 已检查 Docker、WSL、虚拟磁盘等潜在占用。
- 已识别分散的小目录和大量小文件构成的高占用区域。
- 已寻找大型重复资源和历史产物候选。
- 已分析压缩包与疑似解压目录的关系。
- 已识别疑似持续增长目录。
- 已形成具体、可追踪的潜在清理清单。
- 已对可回收空间进行风险分级及去重估算。
- 已明确重要项目、高风险目录和不能确认的内容。
- 已解释扫描覆盖范围、统计差异及未解决的容量差额。
- 已对 CamAct 项目执行完整的保护规则。
- 全程没有主动修改任何文件、软件、项目或磁盘配置。

---

## 十八、最终执行要求

本次调查的最终目标不仅是知道 D 盘为什么满，更重要的是：

**尽可能深入地发现真正占用空间的具体对象，并筛选出所有值得下一轮安全清理的高价值候选。**

特别优先关注：

1. 开发项目内部体积庞大但可以重新生成的构建缓存。
2. Python、Conda、npm、pnpm、uv 等开发工具的下载与构建缓存。
3. AI 模型、模型下载缓存和重复资源。
4. 大型数据集、历史预处理数据及疑似重复副本。
5. 历史软件安装包、压缩包及解压后的重复资源。
6. 长期积累的日志、临时文件和软件更新残留。
7. 历史项目版本、备份和实验产物。
8. 软件安装目录中的历史版本和自动更新资源。
9. Docker、WSL、虚拟机等可能占用大量空间的虚拟磁盘。
10. 数量庞大、单文件不大但累计占用明显的小文件。
11. Git、包管理器和模型缓存中的共享存储或硬链接导致的统计问题。
12. 其他通过常规 Windows 存储设置难以发现的大型占用。

对于每一个高价值候选，尽可能明确：

**完整路径 + 当前大小 + 具体内容 + 占用原因 + 清理依据 + 风险等级 + 预计可释放空间 + 后续安全处理方法。**

特别强调：

- 尽可能扩大安全清理候选的发现范围，但不得降低安全判断标准。
- 不要因为某个文件属于项目目录，就忽略其占用；也不得因为其属于项目缓存，就直接建议删除。
- 不要为了追求回收空间而建议破坏开发环境、科研数据、实验结果或用户文件的处理方式。
- 不要为了让报告看起来完整而编造目录容量、软件依赖或清理收益。
- 不能确认是否可以安全处理的内容，必须明确说明其具体用途、可能风险和需要人工确认的条件。
- 不要将未经核实的历史文件、模型、项目备份直接认定为废弃资源。
- 对 CamAct 项目严格执行绝对保护，不能出现任何例外。

如果某项内容无法在严格只读条件下确认，必须如实标注。

请现在直接开始执行完整的 D 盘只读深度审计，尽可能完成全部安全可执行的检查。

完成审计后，输出完整报告、空间回收潜力评估和下一轮清理候选清单，然后停止，等待我的下一步指令。

**再次强调：本轮只审查、不清理、不迁移、不修改任何文件、软件、开发项目或系统配置。**

三、拿到报告后如何辅助清理

完成检查后，不建议直接让 Agent “把能删的都删掉”。

更安全的方式是根据报告，选择一项或几项明确的内容，再让 Agent 单独处理，例如：

• 清理确认无用的开发缓存；
• 清理旧的构建产物；
• 处理 npm / pip / Hugging Face 等缓存；
• 找出重复的数据集压缩包；
• 将大型模型或数据集迁移到其他磁盘；
• 通过 Docker、WSL、Conda 等软件自身机制释放空间。

四、推荐使用流程

Agent 只读扫描 C 盘
        ↓
查看空间占用报告
        ↓
Agent 只读扫描 D 盘
        ↓
找出 Top 空间占用根因
        ↓
人工选择需要处理的项目
        ↓
让 Agent 针对单个项目给出处理方案
        ↓
确认风险与预计释放空间
        ↓
再执行清理 / 迁移