前言

C 盘空间告急大概是 Windows 老用户最持久的痛：180GB 的系统盘，不知不觉就红了。手动找大文件像寻宝——资源管理器不会告诉你哪些文件夹在偷偷长大，设置里的存储分析只给个粗略分类，真正的「空间大户」往往藏在 AppData 这种普通用户一辈子不会点开的角落。

我的机器就是个典型例子：C 盘 180GB，已用 117GB，资源管理器里翻半天也不知道钱花哪儿了。而用 ZCode 这类智能体做这件事的思路完全不同——它擅长的不正是「遍历、统计、分析、批量执行」吗？这篇文章把我查资料 + 结合实际整理出的四步方案完整记录下来：体检 → 清理 → 迁移 → 固化。

核心原则先放在最前面：智能体负责找和算，人负责决定删什么。全程建议使用 Ask before changes（默认）模式，每一批删除操作前都要过目确认。

先搞清楚：C 盘的钱都花哪儿了

动手之前，先了解一下 Windows 上真正吃空间的几类东西（这是清理方案的知识基础）：

普通用户卡在 C 盘的往往是聊天工具文件 + 浏览器缓存 + 更新缓存；开发者还要再加包管理器缓存 + WSL 虚拟磁盘两条大项。这些正是下面清理和迁移的主战场。

用 ZCode 清理的正确姿势

在开始之前，先把「怎么指挥智能体」这件事说清楚，方法比命令本身重要。

执行模式：用 Ask before changes

清理磁盘是典型的高风险批量删除场景。ZCode 默认的 Ask before changes 模式是这里唯一合理的选择：每条删除命令、每次文件改动都会先弹出确认，你逐项过目。熟练之后，可以把「只读的体检」放到 Edit automatically 下跑得快一点，但删除操作永远不要用 Full access 自动放行。

让它先报告、后动手

一次好的清理会话分两个阶段，提示词里要显式分开：

阶段一——只体检，不删除：

1
2
3
4
5
6

扫描 C 盘，找出占用空间最大的 20 个目录和最大的 10 个文件。
重点覆盖：AppData\Local、用户 Documents、Windows 系统缓存目录、
休眠文件和虚拟内存文件的大小。
以表格输出：路径 / 大小 / 属于哪类（缓存/临时文件/聊天文件/系统文件）/
是否适合安全清理。
只读分析，不要删除任何东西。

小技巧：把「只读分析，不要删除任何东西」写进提示词，或者直接用 Plan mode，让第一轮彻底零风险。

阶段二——按清单清理：

1
2
3
4

根据上面的体检报告，只清理「缓存和临时文件」这一类：
1. 逐项列出你打算删除的目录、预计释放空间、删除理由
2. 我逐项确认后再执行
3. 执行完重新统计 C 盘可用空间，对比清理前后的变化

用 Hook 给删除操作上保险

如果经常做这类清理，可以给 ZCode 配一条 PreToolUse Hook：凡是命中 rm、Remove-Item、del 且参数里出现 Windows、Program Files 的删除命令，直接 deny。相当于给智能体的危险操作加了一道硬闸——具体写法见 ZCode 的 Hooks 配置（~/.zcode/cli/config.json 里 hooks.enabled: true 后加 PreToolUse 事件，matcher 匹配 Bash 工具，脚本里检查命令文本并返回非零退出码拦截）。

空间不足时用目标模式闭环

清理是个「执行 → 验证 → 再执行」的循环，很适合目标模式：

1
2

/goal 在不卸载任何软件、不删除任何个人文件的前提下，
把 C 盘可用空间提升 30GB 以上，所有删除操作逐项向我确认

智能体会自己循环：体检 → 提方案 → 等确认 → 执行 → 复查 → 不够就找下一个目标——不用反复喊「继续」。

第一步：空间体检

体检的目标是拿到一张「钱花哪儿了」的清单。让 ZCode 用命令行工具扫描，比图形界面快得多也细得多，例如：

1
2
3
4
5
6

# 各盘剩余空间
Get-PSDrive -PSProvider FileSystem

# 指定目录总大小（对每个可疑目录执行）
"{0:N2} GB" -f ((Get-ChildItem "C:\Users\<用户名>\AppData\Local" -Recurse -ErrorAction SilentlyContinue |
    Measure-Object Length -Sum).Sum / 1GB)

一次典型体检跑完，报告大概长这样（数字因机器而异，重点看结构）：

有了这张表，「空间去哪儿了」的谜底就揭开了——接下来的动作都有依据，而不是到处乱删。

第二步：安全清理（按风险分级）

ZCode 给出建议后，实际清理可以按下面的分级清单执行。让智能体按级别分批执行、每批确认一次，是最稳的节奏。

零风险：临时文件与回收站

一键方式（图形界面，同样是 ZCode 可以帮你调起的）：

1

cleanmgr /d C:

低风险：系统级缓存

需要确认：休眠文件与虚拟内存

这两项释放空间立竿见影，但改变系统行为，按需决定：

1
2
3
4
5

# 关闭休眠 —— hiberfil.sys 立即消失（笔记本合盖不休眠，仍可正常关机睡眠）
powercfg -h off

# 或者把休眠文件压到内存的 50%
powercfg -h -size 50

虚拟内存迁移：系统属性 → 高级 → 性能设置 → 高级 → 虚拟内存 → 更改，把 C 盘的页面文件取消「自动管理」，改设到 D 盘（初始大小可以给物理内存的 1–1.5 倍）。一台 32GB 内存的机器，这一项就能给 C 盘腾出 10GB 以上。

开发者专项：包管理器缓存

1
2

npm cache clean --force
pip cache purge

不过对开发机来说，这些缓存删了还会长回来——真正的解法在第三步的迁移。

第三步：迁移到其他盘（治本）

清理只能解决一时，迁移才是治本：让以后再产生的大文件直接落到 D 盘。假设 D 盘剩余空间充足，以下按收益从大到小。

3.1 聊天工具文件（通常是最大单项）

微信：设置 → 文件管理 → 更改目录，指到 D:\WeChatFiles，旧文件会提示迁移。QQ 同理。这一步经常能一次释放几十 GB，是普通用户收益最大的单项操作。

3.2 包管理器缓存改位置

删缓存是下策，改缓存目录是上策——以后所有缓存自动落 D 盘：

1
2
3
4
5
6
7
8
9
10
11

# npm
npm config set cache "D:\dev-cache\npm"

# pip
pip config set global.cache-dir "D:\dev-cache\pip"

# pnpm
pnpm config set store-dir "D:\dev-cache\pnpm-store"

# Yarn Classic
yarn config set cache-folder "D:\dev-cache\yarn"

Gradle、Maven、Go、Cargo 走环境变量：

1
2
3
4

GRADLE_USER_HOME = D:\dev-cache\gradle
MAVEN 的 settings.xml 里 <localRepository>D:\dev-cache\maven</localRepository>
GOPATH / GOMODCACHE   = D:\dev-cache\go
CARGO_HOME            = D:\dev-cache\cargo

让 ZCode 做这件事很合适——它可以把上面所有配置一次性执行完，再各跑一次小下载验证新位置生效。

3.3 Docker Desktop 与 WSL

Docker Desktop：Settings → Resources → Advanced → Disk image location 改到 D 盘，镜像数据整体搬家。

WSL 的虚拟磁盘（ext4.vhdx）有个著名特性：在子系统里删文件，vhdx 不会自动缩小。先在 WSL 里清理，再把磁盘压实：

1
2
3

wsl --shutdown
# 以 Ubuntu-22.04 为例，先确认 vhdx 路径，再压缩：
Optimize-VHD -Path "C:\...\Ubuntu-22.04\ext4.vhdx" -Mode Full

Optimize-VHD 需要 Hyper-V 模块；没有的话用 diskpart（select vdisk file="..." → compact vdisk）等效。整个 vhdx 也可以整体搬去 D 盘：wsl --export 导出 → wsl --import 到 D 盘新位置。

3.4 大文件夹整体搬家：mklink 目录联调

有些软件（老版本微信、某些游戏、工程目录）路径写死在 C 盘，改不了设置。这时用 NTFS 目录联调（junction）：文件实际存 D 盘，原路径仍然可用，软件毫无感知：

1
2
3

# 以把 D:\moved\WeChatFiles 接回原路径为例
robocopy "C:\Users\x\Documents\xwechat_files" "D:\moved\xwechat_files" /E /MOVE /R:1 /W:1
mklink /J "C:\Users\x\Documents\xwechat_files" "D:\moved\xwechat_files"

执行顺序很重要：先搬文件（robocopy /MOVE），再建链接（mklink /J）；操作前关闭对应软件。让 ZCode 执行时，把这两条命令拆开逐步确认——尤其确认 robocopy 完成之后再建链接。

下载、桌面、文档这些用户文件夹不必用 mklink：资源管理器里右键文件夹 → 属性 → 位置，直接改路径，Windows 原生支持。

第四步：验证与固化

清理迁移做完，让 ZCode 复跑一次体检脚本，对比前后数字——比如一次典型的成套操作下来，常见收益是：更新缓存 + Temp + 休眠文件 + 微信迁移 + npm 迁移，合计释放 30–50GB，C 盘从飘红回到从容。

想让这件事不反弹，还有两个固化手段：

1. 定时体检：用 ZCode 的 Automations 建一个每周任务，「扫描 C 盘可用空间和 Top10 大目录，环比增长超过 2GB 就输出报告」——空间被谁吃掉，一周内就能知道
2. Hook 长期护栏：保留第二步提到的 PreToolUse 拦截 Hook，给以后所有会话里的危险删除命令兜底

安全红线：这些事不要让智能体做

最后把红线列清楚，写进你的提示词或 AGENTS.md 都行：

• 不要删 C:\Windows、C:\Program Files 下的任何东西（更新缓存和 DISM 是仅有的两个例外，且用上面给定的官方方式）
• 不要用「强制删除/递归删除」去清 AppData——正在运行的软件的缓存目录删了轻则丢登录态，重则丢配置
• WinSxS 不要手动删，只能走 DISM
• pagefile.sys、swapfile.sys 不能直接删文件，只能通过虚拟内存设置改
• system32 报错为「拒绝访问」是保护机制，绕过它的办法只有一个：不要绕
• 大规模删除前，先让智能体把清单写进一个 txt 备着，误删了还有据可查

常见问题

ZCode 会不会乱删文件？

只要你待在默认的 Ask before changes 模式，每一条删除命令都要你点确认，它「想乱删」也没有执行机会。真正要注意的是不要图省事切到 Full access 跑清理。

为什么我删了 WSL 里的文件，C 盘还是没变大？

因为 ext4.vhdx 只增不减——Linux 侧删除只是标记空间空闲，虚拟磁盘文件不会自动收缩，需要 Optimize-VHD 或 diskpart 压实，见 3.3。

DISM 跑了很久正常吗？

StartComponentCleanup 在补丁装得多的机器上跑十几分钟到半小时都正常，中途别关机。加 /ResetBase 可以清得更狠，但代价是已装更新无法再卸载，介意就别加。

清理和迁移，哪个优先？

先体检，按报告来。一般顺序是：先删零风险缓存（快、立刻见效），再迁大文件（慢、治本），最后做系统级瘦身（DISM、休眠文件）。如果只剩几个 GB 急着救急，前两步就能救回来。

小结

这套流程的本质，是把「清理 C 盘」从一门玄学变成一条流水线：

1. 体检——智能体扫描统计，把空间去向变成一张表
2. 清理——按风险分级执行，人在环上逐批确认
3. 迁移——缓存改配置、聊天文件改目录、虚拟磁盘搬家、大文件夹上 junction
4. 固化——Hook 拦危险命令，定时任务防反弹

智能体的价值不在于「替你删」，而在于它能把散落在几百个目录里的空间去向在几分钟内算清楚，然后把方案摆到你面前——决定权始终在你手里。C 盘飘红的朋友，值得花半小时跑一遍这套流程。

参考

• Microsoft：释放 Windows 中的驱动器空间
• Microsoft Learn：DISM 命令行选项
• Microsoft Learn：powercfg 命令行选项
• Microsoft Learn：mklink 命令
• Microsoft Learn：robocopy 命令
• npm 官方文档：npm config
• pip 官方文档：缓存机制
• Docker Desktop：设置文档
• Microsoft Learn：WSL 文档
• ZCode 官网

推荐链接

• 大佬CM博客
• 大佬周润发博客
• 大佬青云志博客