【制造·硬件】C 盘 120G 只剩 25G：我用三条 junction 把 WorkBuddy 的 4.9G 数据整体搬到 E 盘

背景与痛点

我是一名消费电子行业的电池保护板（PCM）工程师，日常用 WorkBuddy 处理客户项目资料整理、TI 电量计日志分析、以及一堆重复性的文档工作。工位这台机器的 C 盘是 120G 的固态，从拿到手那天起就没宽裕过。

2026 年 9 月 23 日早上我跑了一次体检，结果是这样的：

Filesystem Size Used Avail Use% Mounted on

C: 120G 95G 25G 80% /c

D: 180G 66G 114G 37% /d

E: 178G 66G 112G 38% /e

C 盘 80% 满，只剩 25G；而 D、E 两个盘各自还剩 100G 以上。空间不是没有，是站错了地方。

罪魁祸首是 WorkBuddy。它默认把应用数据写在 C:\Users\<用户名>\.workbuddy，这个目录我实测已经长到 4.9G，拆开看更吓人：

• logs —— 2.3G，会话与运行日志，增长最快

• binaries —— 779M，Python / Node 托管运行时

• workspace —— 452M，会话工作区与产物

• plugins —— 127M，插件缓存

• skills —— 3.9M，技能包

• memory —— 40K，记忆文件

▲ 图1 C盘体检：df 与 du 真实输出，.workbuddy 各子目录实测体积

我对 C 盘的容忍度是零：只要 WorkBuddy 在 C 盘大量堆积数据，我就会直接卸载。所以这件事必须一次性解决，而且解决完之后不能再复发。

环境说明

• 系统：Windows 10 企业版 22H2

• 磁盘：C 120G（系统盘）/ D 180G / E 178G

• WorkBuddy 本体已装在 E:\Workbuddy（软件位置和用户数据是两回事）

• 目标：只搬数据，不改软件安装位置，不动任何用户已有文件

输入材料

动手前我交给 WorkBuddy 的三样东西：

1. 磁盘体检的原始输出：df -h /c /d /e 的结果，以及 du -sh 逐层扫出来的 .workbuddy 各子目录体积（见上表）。

2. 我自己的硬约束（这是最重要的输入）：C 盘是红线；任何系统级 / 全局性改动——环境变量、路径重定向、注册表——必须先征得我同意，不许先斩后奏，改完要告诉我改了什么、怎么回滚。

3. 已有的历史记录：之前几轮会话里 WorkBuddy 记下的 C 盘数据点清单（哪些目录会涨、哪些是噪音、哪些不能碰）。

WorkBuddy 配置

这一轮我没有用任何专家或 MCP，用的是最朴素的配置，但有两个能力是关键的：

• 本地文件访问：让 WorkBuddy 直接读磁盘、跑 fsutil / reg query / du，而不是靠它自己猜路径。所有数字都是它跑出来贴给我的，不是编的。

• 定时云端任务（automation）：迁移做完之后，我让它建了一条每月 1 号 10:00 自动执行的清理任务（automation id 60036964-73ab-4b0f-b50e-a81393e98f19），负责清理更新器旧安装包、崩溃转储、IPC 残留空目录，并在 C 盘剩余低于阈值时通知我。

我给它的提示词大意是这样的：

我的 C 盘只剩 25G，WorkBuddy 的数据目录已经 4.9G。请给出一套把数据整体迁到 E 盘的方案，要求：

1. 只做重定向，不删除任何用户数据；

2. 迁移前必须保留可回滚的备份；

3. 任何系统级改动（环境变量 / 注册表 / junction）先列清单给我确认，我点头再执行；

4. 做完后给我三条可以在命令行自测的验证命令。

操作步骤

第 1 步：先盘点，不急着动手

df -h /c /d /e

du -sh "C:/Users/u64699/.workbuddy"/*

先把「谁占了 C 盘」量化清楚，避免迁了一圈发现大头在别处。实测确认大头就是 .workbuddy 后，才开始设计重定向。

第 2 步：三条重定向（核心）

• 第一条：%USERPROFILE%\.workbuddy → E:\WorkBuddyData，4.9G，应用数据本体

• 第二条：%LOCALAPPDATA%\pip → E:\pip-cache，80M，Python 包下载缓存

• 第三条：用户级 TEMP / TMP → E:\Windows-Temp，1.5G，系统与脚本临时文件

▲ 图2 三条重定向清单与迁移命令执行过程

第一条是主战场，做法是「同步 → 备份 → 建 junction」：

robocopy "C:\Users\u64699\.workbuddy" "E:\WorkBuddyData" /MIR /R:1 /W:1

ren "C:\Users\u64699\.workbuddy" ".workbuddy_BAK_20260906"

mklink /J "C:\Users\u64699\.workbuddy" "E:\WorkBuddyData"

第二条和第三条更轻量：pip 缓存直接 mklink /J 指到 E 盘；TEMP 改的是 HKCU\Environment 下的 TEMP / TMP 两个值，指向 E:\Windows-Temp。

这里有个必须遵守的纪律：这几步都属于系统级改动，WorkBuddy 在动手前把三条重定向的路径、影响面、回滚方法列成清单发给我，我确认后才执行。事后它也主动报告了改了什么、怎么还原。

第 3 步：验证（junction 有没有真的生效）

fsutil reparsepoint query "C:\\Users\\u64699\\.workbuddy"

真实输出（节选）：

重分析标记值 : 0xa0000003

标记值: Microsoft

标记值: Name Surrogate

标记值: 装入点

替换名称: \??\E:\WorkBuddyData

打印名称: E:\WorkBuddyData

看到「装入点」+「替换名称 \??\E:\WorkBuddyData」，说明 junction 建对了。写入 C:\Users\u64699\.workbuddy 的任何字节，实际都落在 E 盘。

pip 那条同理，替换名称是 \??\E:\pip-cache。

▲ 图3 迁移后验证：fsutil 与 reg query 的真实输出

第 4 步：确认 TEMP 改到位

reg query "HKCU\\Environment" | grep -Ei "TEMP|TMP"

TEMP REG_EXPAND_SZ E:/Windows-Temp

TMP REG_EXPAND_SZ E:/Windows-Temp

第 5 步：落盘复核

重定向之后再看一次 E 盘落点：E:\WorkBuddyData 4.9G、E:\Windows-Temp 1.5G、E:\pip-cache 80M —— 三个数字都对得上，说明写入真的走了新路径，不是只建了个空壳链接。

验证结果

• C 盘当前：120G 总容量 / 95G 已用 / 25G 可用 / 80% 满（体检当天实测）

• 三条 junction 全部通过 fsutil reparsepoint query 验证，替换名称正确

• 用户级 TEMP / TMP 已指向 E 盘

• WorkBuddy 启动、登录、跑任务全部正常——应用侧对 junction 完全无感，这是整件事能成立的前提

• 稳定性观察一周后，880MB 的迁移备份目录按计划删除，回滚通道才正式关闭

顺带一提：这轮之后 C 盘的压力并没有彻底消失，因为 80% 是系统和其他软件共同堆出来的，WorkBuddy 只是其中一块。但至少这一块不会再涨了——这是这次治理真正的意义。

踩坑与注意事项

1. 系统级改动必须先问，别先斩后奏。 我在这上面发过一次火：WorkBuddy 自作主张改了环境变量，虽然目的确实是帮我省 C 盘，但没打招呼。后来它把这条写进了长期记忆——凡涉及环境变量、路径重定向、注册表、安装卸载，一律先列清单等确认。

2. 用 junction，不要用符号链接。 mklink /J 建的是目录联接（junction），不需要管理员权限，对应用程序完全透明，兼容性远好于 /D 符号链接。搬应用数据目录只认 junction。

3. 迁移顺序不能反。 必须 robocopy /MIR 同步 → 重命名原目录做备份 → 再建 junction。直接 move 或者先建链接后拷数据，一旦中途失败就是数据丢失。备份目录至少保留一周再删。

4. 只改 `HKCU`，不要动 `HKLM`。 用户级环境变量影响面可控，改错了删掉即可；系统级变量会影响所有用户和服务进程，出问题排查成本极高。

5. TEMP 改完对已运行的进程不生效。 环境变量是在进程启动时读取的，改完必须重开终端、重启相关程序才会走新路径。刚改完就去看效果，会误判为失败。

6. 别把工作空间设在 junction 内部。 WorkBuddy 的默认工作空间要单独改到 E 盘的其他路径，不要指向已经 junction 出去的目录树里面，否则容易出现路径递归和重复统计。

7. junction 会被部分清理工具误判。 某些磁盘清理软件把联接点当成"异常目录"或"无效快捷方式"报警，看到提示先别急着删，先用 fsutil reparsepoint query 确认真身。

8. 迁移完要留长期机制，不能一劳永逸。 光搬一次不够，更新器安装包、崩溃转储、临时目录每个月都会重新长出来。所以我配了每月 1 号 10:00 的定时云端任务做例行清理，并设了「C 盘剩余低于阈值就通知我」的告警。

产出物

这轮做完留下的东西：

1. `README-c-drive-cleanup.md` —— 一次性迁移 + 长期维护的完整说明文档，包含文件清单、操作步骤、告警阈值、常见问题六个章节。

2. `migrate-to-E.bat` —— 一键迁移脚本：增量同步 → 备份改名 → 建 junction → 自动验证。

3. `cleanup-workbuddy-c-drive.bat` —— AppData 残留清理脚本，清临时目录、崩溃转储、7 天前的旧安装包。

4. 月度定时云端任务 —— automation id 60036964-73ab-4b0f-b50e-a81393e98f19，每月 1 号 10:00 跑清理。

5. 三条自检命令 —— fsutil reparsepoint query 查 junction、reg query 查 TEMP、du -sh 查落盘体积。每次跑完任务我都让 WorkBuddy 把这三条的实测结果贴一遍，不给"应该没问题"这种话。

总结

• C 盘告急时先量化再动手，du -sh 比感觉可靠。

• 应用数据目录搬家的最优解是 junction：应用无感、无需管理员权限、可回滚。

• 三条重定向（应用数据 / pip 缓存 / TEMP）加起来把 WorkBuddy 的 C 盘写入彻底清零。

• 迁移只是开始，配一条定时清理任务才能真正止血。

• 最重要的一条：让 AI 改系统级配置前，先让它列清单给你看。