Windows C 盘清理

Overview

在 Windows 上定位并安全释放 C 盘空间。核心流程是「先量后删、先备份后执行」，并且不可逆数据的最终删除由用户手动完成。

本技能只管事后清理。 用户想"提前防"（预判/装软件前/会不会堆/迁盘）时，改用 windows-c-drive-space-guard。分工判据见下面「与「事前预判」的分工」。

判断不了就问一句：现在是"已经满了想清"，还是"想提前防"。

本技能沉淀的是本机环境（WorkBuddy + Git Bash + Windows 11）特有的坑，按这些规则走可以避开反复试错。所有环境限制与踩坑清单见 references/pitfalls.md。

更新日志

> 本技能每次功能 / 说明变更都会在此列出，便于快速判断「这个版本改了什么」。主流程稳定，不在此重复正文细节。

v1.7.0（2026-10-28）

• 修正一个错误认知：之前认为「Git Bash rm 不走回收站」，实测部分场景同样进了系统回收站——$Recycle.Bin 实测涨到 5.69 GB，删了 5 GB 空间纹丝不动。pitfalls 第 17 条已加修正标注，新增第 20 条：每轮批量删除后必查并清空 $Recycle.Bin，第 6 步验证清单同步加入此项。
• 新增 pitfalls 第 21 条：TrustedInstaller 所属目录的 takeown + icacls 删除前置（实测豆包 6.27 GB）。
• 新增 pitfalls 第 22 条：非系统盘 pagefile 自动扩容造成的「D 盘少了 18 GB」假象（4.5→22.65 GB），重启自然回收。
• 新增 pitfalls 第 23 条：大目录迁出 C 盘的 junction 法（robocopy + mklink /J，实测 6.27 GB 成功）。
• 案例库追加「案例 5 · 2026-10-28」：C 盘剩 3.1 GB 的全流程处置与「读数对不上」三类根因排查顺序（回收站 → 延迟释放 → pagefile）。

v1.6.1（2026-10-26）

• 修复上传解析失败：平台限制 examples_zh / examples_en 各最多 3 条（v1.5.0 补到 6 条导致上传报「最多 3 个示例」）。精简为 3 条，分别覆盖清理 / 异常排查 / 定期巡检，保留核心与新能力展示。

v1.6.0（2026-10-26）

• 把「支持定期巡检（可挂平台定时任务 / Windows 任务计划做只读监控，不删文件）」写入 description / description_zh / description_en，让平台详情页与触发路由都能体现 v1.5.0 已新增的定期巡检能力，使平台用户可见。

v1.5.1（2026-10-26）

• 新增本《更新日志》章节，逐版本列出变更点，让更新内容一眼可见。

v1.5.0（2026-10-26）

• 新增《定期巡检（主动监控）》章节：说明技能本身不会定时跑（平台 frontmatter 无 schedule/cron 字段），给出两条落地路径——路径 A 平台定时任务勾选本技能（只读不删）、路径 B Windows 任务计划程序挂 scripts/scan_cdrive.py --warn 25（剩余 <25 GB 退出码 2）。
• 补 examples_zh / examples_en 各 6 条触发语，新增「定期检查 C 盘，出一份巡检报告」等说法，让"定期巡检"诉求能被正确触发。

v1.4.0（2026-10-12）

• 新增第 7 步「异常时收集反馈」：仅在删除失败 / 空间读数异常 / 用户否认结果 / 遇 pitfalls 未覆盖新现象时收集，正常完成不询问。
• 修复 4 处失效技能交叉引用：windows-c-drive-bloat-forecast → windows-c-drive-space-guard（对方已改名，旧引用静默失效）。

铁律（不可违反）

1. 只读扫描先行：第一次接触用户的 C 盘时，先只扫描出报告，明确列出每一项后再动手删除。
2. 备份由助手做，删备份由用户做：不可逆的删除项必须先 robocopy 备份到另一分区；备份完成后只提醒用户位置和大小，绝不代为删除备份目录。
3. 涉及用户数据必须确认：聊天记录、文档、照片等在删除前用选项控件让用户明确勾选。
4. 不确定就留着：来源不明的目录不要删，标注给用户决定。
5. 预判优先于清理：用户说"提前干预"、"会不会堆"时，不要一上来就清缓存，转windows-c-drive-space-guard——搬走 10 GB 缓存和止住一个无上限增长源，价值差一个量级。

工作流程

第 1 步：确定磁盘现状

fsutil volume diskfree C:            # 唯一可信的空间读数
df -h /c /d                           # 顺带看其他分区能否放备份

用 references/pitfalls.md 里的命令核对——不要用 Git Bash 的 du 判断占用，它在 NTFS 上会虚报数倍。

第 2 步：逐层扫描占用

由粗到细三层递进，每层只保留前几名：

du -sh /c/Users /c/Windows /c/ProgramData "/c/Program Files" "/c/Program Files (x86)"
du -sh /c/Users/*/AppData/Roaming/* /c/Users/*/AppData/Local/* | sort -rh | head -40
du -sh /c/ProgramData/* | sort -rh | head -30

单个大目录再往下一层挖，直到能说清每个条目属于哪个软件。执行 scripts/scan_cdrive.sh 可一次跑完常用扫描层。

第 3 步：判断各项能否删除

按确定性从高到低分类，出报告给用户：

判断软件是否还装着时，注册表读取在部分环境会失败，改用开始菜单快捷方式 + Program Files 目录名交叉核对。

特殊情况：删除被反复重建的缓存（如 WPS addons）时，可用 Bash 的 rd 法绕过——cd 到父目录后 cmd //c "rd /s /q <子目录名>"。前提是已备份且对应软件已退出，否则陷入了删了又回填的循环。

第 4 步：备份

robocopy "<源路径>" "<目标路径>" /E /NFL /NDL /NJH /NJS /R:1 /W:1

robocopy 返回码 0~7 都代表成功。备份完成后用 PowerShell 精确复核文件数和总字节数，再通知用户「备份位于 XXX，确认系统无误后可自行删除」。

第 5 步：删除

Users 目录下（AppData、Documents）——先在同一次工具调用里注册批准再删：

& $env:CODEBUDDY_NODE_BIN $env:CODEBUDDY_SAFE_DELETE_BULK_GUARD approve --scope turn
Remove-Item -LiteralPath "<路径>" -Recurse -Force -Confirm:$false -ErrorAction Stop

ProgramData / Program Files 下——回收机制不支持，一律被拒（trash-failed）。两条路：

1. 首选：写好 .cmd 批处理让用户管理员运行（内容就是 rd /s /q "路径" 若干行）。
2. 目录位于 Users 但 Remove-Item 失败时：切到父目录后用 cmd //c "rd /s /q <子目录名>"（双斜杠 //c 防止 MSYS 把 / 转成路径）。

遇到文件被占用就跳过该目录，先让用户关闭对应软件。WPS 之类的软件会在后台重建缓存——必须让用户退出进程，否则删完立刻回填（详见 pitfalls）。

第 6 步：验证并收尾

• 先查并清空系统回收站——本环境删除（含部分 rm）会先进 $Recycle.Bin，不清等于没删（实测删 5 GB 回收站涨 5.69 GB，见 pitfalls 第 20 条）。
• 等 几分钟再读空间，避开异步回收造成的假性缩水；读数与清理明细对不上时，按「回收站 → 延迟释放（阳性对照）→ pagefile 扩容」顺序排查（pitfalls 20/15/22）。
• 若曾为防止休眠改过电源计划，清完务必恢复：

powercfg /change monitor-timeout-ac 10
powercfg /change standby-timeout-ac 30
powercfg /change hibernate-timeout-ac 0
powercfg /change disk-timeout-ac 20

• 生成 Markdown 报告，包含：空间对比、清理明细、备份位置、待办事项。

第 7 步：异常时收集反馈

平台只提供聚合指标（安装量/调用量），不提供用户原声；技能详情页也没有反馈/评价入口（2026-10-12 实测确认）。本步骤用于把真实失败场景带回案例库。

仅在出现下列情况时执行，正常完成时不要问——反馈只在异常时有价值，常态化询问会变成骚扰：

• 有清理项删除失败（文件被占用、权限不足、回收机制拒绝）
• 空间读数异常（等几分钟后不降反升，或降幅远小于清理明细之和）
• 用户对结果有疑虑、否认，或要求恢复已删内容
• 遇到 references/pitfalls.md 里没有的新现象

收集方式，按优先级：

1. 主路径（零门槛）：把异常现象完整写进对话——卡在哪一步、命令原文输出、报错信息、清理前后的空间读数对比。写清楚用户才能直接看懂，也方便他整段复制带走。
2. 写入案例库：拿到现象后按下方沉淀规则追加到 references/case-notes.md。
3. 预留渠道（可选，不强求）：若用户愿意把现象发给作者，地址 fuyk7902@agent.qq.com。
   这只是预留出口，普通用户大概率不会用——不要依赖它，也不要反复催促。第 1、2 步才是主力。

常见可清理项速查

健康参考：全新 Win11 约 30 GB，累积更新一年后 35~45 GB 属正常。日常建议 C 盘至少留 20~25 GB 余量。

与「事前预判」的分工

本技能只管已经发生的堆积。若用户想问「装软件前会不会堆」「怎么提前防止」「哪些软件在持续占用 C 盘」，
改用 windows-c-drive-space-guard 技能（C盘空间守卫）。

分工判据：

不要因为用户说"检查一下C 盘"就默认走清理。 实测踩过：用户说「预检查、提前干预」，
给的是清理报告——方向完全错。预判的价值在于止住增长，清理只能回收存量。

清理前建议先看预判结果：如果某软件还在持续往 C 盘写数据，只清存量是治标，
清完还会涨回来。预判技能会指出哪些是「止住增长」的动作。

定期巡检（主动监控）

先讲清楚一件事，免得误解：技能本身不会自己定时跑。
平台技能规范里没有 schedule / cron / 定时触发这类字段（frontmatter 官方字段只有
name / display_name / display_name_en / description / description_zh / description_en /
examples_zh / examples_en / allowed-tools / version / author），
技能是"给 AI 读的说明书 + 脚本"，只能被对话或定时任务触发，不会自己执行。

所以"定期检查"必须由下面两层之一来承载。当用户说「定期检查 C 盘」「以后自动盯着点空间」时，
不要回答"技能不支持定时"就完事，直接按下面两条帮他搭。

路径 A：平台内的定时任务（推荐，用户零成本）

WorkBuddy 客户端左侧「定时任务」→ 新建 → 在「专家·技能·连接器」里勾选本技能 →
提示词填下面这段 → 选频率（建议每周一 9 点，或改成"每周一、三"）。

可直接粘贴的提示词：

调用 windows-c-drive-cleanup 技能对 C 盘做一次只读巡检：
1) 用 scripts/scan_cdrive.py 扫描占用，并用 fsutil volume diskfree C: 读取剩余空间；
2) 与上一份巡检报告对比，指出这段时间新增或增长最快的堆积点；
3) 把报告存到 <工作目录>/C盘巡检报告/<YYYY-MM-DD>.md；
4) 只出报告并给出可清理项与处置建议，**不要删除任何文件、不要修改任何系统设置**；
5) 若剩余空间低于 25 GB，在报告开头显著标注告警。

关键约束写进提示词：只读、不删。删除决定权必须留在用户手上。

路径 B：Windows 任务计划程序（不依赖 WorkBuddy 也能用）

scripts/scan_cdrive.py --warn 25 本身就是为外部调度留的钩子：剩余空间低于阈值时退出码为 2。
把它挂成计划任务，脚本每次跑完自行落一份报告：

python "<技能目录>\scripts\scan_cdrive.py" --warn 25

任务计划程序里把"如果任务失败，无论用户是否登录都要运行"勾上，并把起始位置设为技能目录。
注意：需要 Python 在 PATH 里（本机为 E:\program\python313\，已加用户级 PATH）。

巡检报告该包含什么

频率建议

巡检 ≠ 清理。 巡检的价值是发现"哪里在持续涨"，交给 windows-c-drive-space-guard 去根治；
清存量只是让当前读数好看，下个周期还会涨回来。

Resources

scripts/scan_cdrive.py

路径 A 主工具（Python 版，优先于 scan_cdrive.sh）。占用扫描 + 堆积点定位 + 27 个已知软件堆积点。

python scan_cdrive.py                # 扫描报告
python scan_cdrive.py --warn 25      # 剩余 <25 GB 时退出码 2，可挂计划任务
python scan_cdrive.py --json

> 优先用这个 Python 版而非 scan_cdrive.sh：du 在 NTFS 上虚报数倍，且 junction 会导致结果离谱（实测把 99 GB 的盘算出 301 GB）。scan_cdrive.sh 保留作为快速相对排序参考。

scripts/scan_cdrive.sh

路径 A 的 Bash 版本（历史保留）。输出按占用降序，但数字仅用于目录间相对排序，不可进报告。

references/pitfalls.md

环境限制与踩坑清单——du 虚报、junction 循环计数、硬链接重复、延迟释放、回收机制路径限制、powercfg 参数转义、批量删除护栏、禁用项清单。遇到删除失败、空间读数异常、或统计数字明显超过磁盘容量时先查这里。

references/case-notes.md

追加式实战案例库（含实测数字与判据）。清理完成后如出现新的根因、新的处理手法、新的环境坑，或原判断需要修正，按下面的沉淀规则写入。

沉淀规则（Knowledge Persistence）

技能本身是静态文件，不会自动更新。为让后续复用越来越准，每次收尾时执行以下沉淀动作：

1. 判定是否值得沉淀：出现过新的根因、新的处理手法、新的环境坑，或原流程判断错了需要修正（任一命中即沉淀）。
2. 先向用户报告：用一两句话说明"发现了什么、准备写进哪里"，取得确认后再写文件。未获确认不写入。
3. 写入 references/case-notes.md：以追加方式记录，只记可复用的判断依据与命令，不记流水账；修正性内容写明"之前错了、正确是什么"。
4. 禁止直接改写 SKILL.md 正文：主流程保持稳定。确需改动时先说明理由并确认，改完 version 递增小版本号。
5. 跨机型/系统差异归类写入案例库（如不同 Windows 版本的回收机制差异、厂商自带清理工具的可用性），供下次按关键标识快速命中。
6. 实测数字必须留档：本技能的判据高度依赖量级（虚报倍数、缓存典型大小、释放延迟时长），记录时带上具体数值，不要只写结论。