系统清理king — Windows 系统盘清理全流程

Overview

针对王总电脑（Windows 11，系统盘 100GB）的垃圾清理技能。核心原则：先扫描报告、后确认删除、绝不误伤个人文件。

历史战绩：
- 2026-07-28 两轮清理释放 20.3GB（891 个 evtx / 7.70GB）
- 2026-09-10 清理释放 6.82GB（可用 29.55GB → 36.37GB，占用率 70.4% → 63.6%）（279 个 evtx / 2.41GB）
- 2026-09-11 evtx 根因侦查 + 清理 1.54GB（可用回到 36.52GB）
- 2026-10-04 清理释放 4.95GB（可用 30.19GB → 35.14GB）。本轮关键发现：回收站实际达 5.17GB / 38,565 条，绝大多数为 Temp 垃圾（autoclaw/qhgx/QQMusic 等临时目录），远超此前"0.28GB"的误读；回收站清理范围据此放宽为【任意 \Temp\ 路径】，并新增合同图片硬校验。桌面"销售合同-恒润昊"3 图零误删保留。

evtx 病根已于 2026-09-11 定位（AppX 部署失败循环，详见第 5 步），不再是未解之谜。

安全红线（每一步都不可违反）

1. 只删缓存和临时文件，绝不递归删除 Desktop / Documents / Downloads / Pictures / Home 根目录。
2. 禁止 rm -rf / del /S /Q / 宽通配符（如 *.tmp 全盘匹配）。只针对扫描报告中列出的具体目录逐个清理。
3. 删除前必须向用户展示完整清单并获确认。扫描阶段永远只读。
4. 每批最多 10 个目录，每批完成后核对剩余空间，任何一步失败立即停止。
5. WinSxS、Windows\Installer 属于 KEEP 类，只能监控或用 DISM 压缩，绝不手动删除。
6. 微信"聊天附件"类目录涉及个人数据，除非用户点名，否则不进清理清单。
7. 扫描器给出的 App 路径若是"整个数据目录"而非缓存子目录，禁止整目录清空 —— 必须先探结构、只清缓存子目录（见第 3.5 步）。
8. 永远不要直接清空回收站 —— 里面可能躺着用户的合同、图纸等重要文件。必须先用第 4.5 步解析来源，只清来自 C:\Windows\Temp 的条目。

工作流

第 1 步：只读扫描

运行扫描脚本（使用托管 Python）：

"C:\Users\Administrator\.workbuddy\binaries\python\versions\3.13.12\python.exe" "C:\Users\Administrator\.workbuddy\skills\system-cleanup-king\scripts\scan_disk.py"

脚本输出三类结果：
- 建议清理（SAFE）：Windows Temp、用户 Temp、浏览器缓存、App 更新缓存、pip/npm 缓存等 —— 无用户数据
- 需确认（CONFIRM）：QQ拼音、微信、剪映、夸克、豆包、钉钉等运行中 App 的缓存 —— 关闭 App 后清理更彻底
- 勿动/仅监控（KEEP）：WinSxS、Windows Installer —— 只报告大小

JSON 明细落盘在 scripts/scan_result.json，可直接读取做汇总与取精确路径。

第 2 步：报告并求确认

向用户呈现分类表格（路径 + 大小 + 分类 + 预计释放总量），并给出建议：
- "建议清理"类：等用户一句"清"即可执行
- "需确认"类：逐项列出，说明风险（如运行中 App 缓存删不干净、输入法词库删后自学习数据丢失）
- 提醒用户：正在运行的 App（豆包/夸克/剪映等）最好先关闭，否则缓存被进程锁定
- 用户回复"全清"后，仍须先执行第 3.5 步的结构探查，不可直接整目录清空

第 3 步：分批清理（Git Bash 环境）

标准清理命令（Git Bash 下最可靠）：

find "<目标目录>" -mindepth 1 -delete 2>/dev/null

锁定文件的两步法（直接 delete 报错或残留目录时）：

find "<目标目录>" -type f -delete 2>/dev/null
find "<目标目录>" -mindepth 1 -type d -delete 2>/dev/null

要点：
- 用 for d in ...; do 循环逐目录执行，并打印每个目录 清理前MB -> 清理后MB，便于核对
- 剩余几十~几百 MB 属正常（运行中进程锁定），不要强行硬删
- npm-cache 类海量小文件目录必须单独后台执行：2026-09-10 实测 find -delete 耗时 16 分 49 秒，混在一批里会导致整批超时被 SIGTERM 中断（已完成的目录不受影响，续跑剩余目录即可）

⚠️ 最关键的坑：删除方式决定空间是否真释放

• 2026-09-11 实测：用 Python os.remove 删了 1.04GB，C 盘可用空间纹丝不动（34.99→34.98GB），全部进了回收站
• 所以优先用 find -delete；若只能用 Python（如 bash 工具链损坏时），删完必须执行第 4.5 步清理回收站，否则等于白干
• 注意：本机 bash 工具链偶尔损坏（cut/wc/grep/head 报 command not found），此时改用 Python 完成一切工作

第 3.5 步：App 缓存的安全边界（关键，勿跳过）

扫描脚本对"剪映/夸克/豆包"给出的路径可能是整个 App 数据目录（如 AppData\Local\Quark、AppData\Local\Doubao），直接整目录清空会丢登录态、聊天记录、本地设置。

正确做法：
1. 用 du -sm "<路径>"/* | sort -rn | head -20 逐层探明子目录构成
2. 只清真正的缓存子目录：Cache、Code Cache、GPUCache、DawnCache、GrShaderCache、remote_resource_cache、image_cache、gecko_cache、ShaderCache、optimization_guide_hint_cache_store
3. 必须保留：Local Storage、IndexedDB、WebStorage、Cookies、Extensions、Service Worker、user_info、preference.json、sandbox_envs_dir、sandbox_runtime、hot_fix（热修复包）
4. 清前用 tasklist /FO CSV + Python 解码 GBK 确认 App 未运行（未运行才能清干净；三个 App 均未运行时实测可清出 1.45GB）

第 4 步：复核释放量（禁用 df -h）

注意：Git Bash / PortableGit 的 df -h 在本机报告不准，禁止据此下结论。

首选 PowerShell：

Get-WmiObject Win32_LogicalDisk -Filter "DeviceID='C:'" | Select-Object Size,FreeSpace

坑（2026-09-10 实测）：本机 PowerShell 工具不回显 stdout —— 连 Write-Output "test" 都只有 exit code 无输出，且从 Bash 调用 powershell.exe 会被安全策略拦截。此时改用托管 Python 的 shutil.disk_usage（走 Win32 API，与 PowerShell 同源、结果准确）：

"C:\Users\Administrator\.workbuddy\binaries\python\versions\3.13.12\python.exe" -c "import shutil;t,s,f=shutil.disk_usage('C:/');print('TotalGB=%.2f UsedGB=%.2f FreeGB=%.2f'%(t/1024**3,(t-f)/1024**3,f/1024**3))"

对比清理前后 FreeSpace，向用户汇报实际释放 GB 数。
注意：实测释放量常比各项清理量之和少 0.5~1GB，属正常现象（清理期间系统自身持续写入临时文件），不是清理失败。

第 4.5 步：回收站核查与安全清理（实测空间没释放、或清理收尾时必做）

如果删完文件但可用空间几乎没变，几乎一定是文件进了回收站；此外回收站本身常堆积数 GB 临时垃圾，应在清理收尾时一并清掉。

1. 先看清回收站真实规模与来源分布（解析 $I 元数据还原原始路径/大小/删除时间，按来源目录汇总）：
   bash "C:\Users\Administrator\.workbuddy\binaries\python\versions\3.13.12\python.exe" "D:\evtx_watch\parse_recyclebin.py"
   ⚠️ 2026-10-04 实测：回收站可达 5.17GB / 38,565 条，且绝大多数为 AppData\Local\Temp 下的临时垃圾（autoclaw/qhgx/QQMusic 等），绝非只有 C:\Windows\Temp。清理范围必须覆盖任意 \Temp\ 路径，不能只盯 Windows\Temp。

2. 运行健壮版清理脚本（技能自带，已内置安全守卫 + 硬校验）：
   bash "C:\Users\Administrator\.workbuddy\binaries\python\versions\3.13.12\python.exe" "C:\Users\Administrator\.workbuddy\skills\system-cleanup-king\scripts\purge_recyclebin_temp.py"
   该脚本会依次：
   - 解析全部 $I，只挑原始路径含 /temp/ 或以 /temp 结尾的条目（范围覆盖用户 Temp 与 App 临时目录）；
   - 安全守卫：任何原始路径含 合同/销售/desktop/桌面/文档/图片/photo/重要/备份 一律排除；
   - 硬校验：独立扫描全部 $I，确认"合同"类 $R 绝不在删除集合内（命中 >0 立即中止）；
   - 用原生 find -delete 真正释放空间（自动定位 Git 的 find.exe；找不到时写出 ASCII 清单 _rb_purge.txt 并打印 Git Bash 手动删除命令）；
   - 对比删除前后 C: 可用空间，汇报本次释放量。
   - 想先只核查不删，加 --dry-run。

3. 绝不允许直接清空整个回收站（除非用户明确点名并要求）。桌面"销售合同-恒润昊"3 张图（2026-09-11 发现、2026-10-04 再次确认）必须永远保留——硬校验就是为此而设。

4. 删除清单落盘在同目录 _rb_purge.txt（每行一个 ASCII 的 $R/$I GUID 路径，无中文，规避 bash 编码问题）。若脚本回退到手动模式，在 Git Bash 执行：
   bash while IFS= read -r p; do find "$p" -delete 2>/dev/null; done < "D:\evtx_watch\_rb_purge.txt"

第 5 步：病根检查（evtx 异常）—— 根因已定位

结论（2026-09-11 确认）：这不是"日志异常写入"，而是 AppX 部署失败循环产生的诊断归档。

完整的因果链

1. 系统反复尝试安装/更新 Windows App Runtime（MicrosoftCorporationII.WinAppRuntime，WinUI 3 应用运行时依赖）
2. 安装失败：
   - Result code = 0x80073CF6（包无法注册）
   - Component failure code = 0x800706D9（ERROR_EPT_S_NOT_STARTED，相关系统服务未运行）
   - Failed component name = windows.firewall ← 直接指向 Windows Defender 防火墙组件
3. 每次失败，AppX 部署框架自动做两件事：
   - 生成 C:\Windows\Temp\AppxErrorReport_<GUID>.txt（约 850 字节）
   - 批量归档 9 个诊断通道的事件日志到 C:\Windows\Temp\
4. 系统持续重试 → 反复产生归档 → 24 小时内失败 20 次，堆积 1.55GB

关键的 9 个通道（固定组合，这是 AppX 部署失败诊断的标准上下文）

文件命名与大小规律（下次一眼识别）

• 命名：<通道名>_<LogFileGUID>.evtx，如 Application_92F074A4-4198-0003-1B70-F5929841DD01.evtx
• 单个文件大小恒等于该通道的 maxSize（Application 20.07MB / Store 19.07MB / AppXDeploymentServer 5.07MB）——可用 wevtutil gl <通道> 核对
• 文件数恒为 9 的倍数（每次失败固定产出 9 个）
• 配套 AppxErrorReport_<同一GUID>.txt 是关键证据文件
• 归档内容是数月前的历史日志（不是当前时间），因为归档的是各通道累积的完整日志文件

排查手段与限制

• 排除系统自动归档：wevtutil gl Application 显示 autoBackup: false —— 9 个通道的自动备份全部关闭，证明是外部程序主动导出，不是 Windows 自带机制
• wevtutil el 可用（本机 1184 个通道属正常）；logman query -ets 可看 ETW 会话（注意 ETW 输出是 .etl，而 .evtx 只能由事件日志服务/EvtExportLog 产生，别混淆）
• 本机受限命令（均为黑名单，禁止调用、禁止绕过）：reg.exe、sc.exe；PowerShell 工具不回显 stdout
• 读取归档内容的正确命令（/lf:true 不可少）：
  bash wevtutil qe "<完整路径>.evtx" /lf:true /f:text /c:2000
  注意：路径分隔符混用（C:/x\y.evtx）会报 "指定的通道路径无效"；输出字段是英文 Source: 而非"来源:"
• 分析脚本：D:\evtx_watch\analyze_evtx.py（统计通道分布、事件来源 TOP、日期分布）

处置建议（给用户的方案）

• 治本：修复 Windows Defender 防火墙服务（mpssvc）与基础筛选引擎（BFE）——让用户打开 services.msc 确认这两个服务为"自动/正在运行"；高度怀疑被第三方安全软件（本机装有 360、Kinsec、AntiCheatExpert 等）禁用，这是国产安全软件的常见行为
• 兜底：若短期内无法根治，可设置定期清理 C:\Windows\Temp\*.evtx 的任务，或把相关通道 maxSize 调小以减少单次归档体积
• 止损：每次清理这些文件时，记得检查回收站（第 4.5 步）
• 监控脚本 D:\evtx_watch\watch_evtx.py 仍可复用于验证"修复后是否还在堆积"

已排除的误判

• C:\Windows\Temp 下 <计算机名>-<日期>-<时间>.log（如 WY-PC-20260911-0923.log）是 Office ClickToRun 的详细遥测日志，内容中不含任何 evtx 导出记录 —— Office C2R 不是元凶
• reg.exe 禁止使用，故 Autologger 注册表方向无法排查（也已无必要）

第 6 步：记录

清理完成后，在工作区 .workbuddy/memory/YYYY-MM-DD.md 追加本次清理日志：清理项、释放量、病根状态，供下次对比复发速度。

第 6.5 步：技能自迭代（常态化，每次清理后必做）

王总要求：每次完成清理任务后，对自身做一轮迭代升级，并同步更新技能库、配置与功能模块。具体动作：

1. 复盘本次踩到的坑 / 新发现，把可复用经验固化回本技能：
   - 新增或修改 scripts/ 下的脚本（如回收站清理脚本的健壮化）；
   - 更新上方「安全红线」「工作流」「已知坑位速查」；
   - 在 Overview 战绩表中追加本轮释放量与关键发现。
2. 优先修正已确认的错误：例如旧 purge_recyclebin_temp.py 用 os.remove（不释放空间）、只匹配 C:\Windows\Temp（范围过窄）——一律改为原生 find -delete + 任意 \Temp\ 宽匹配 + 合同硬校验。
3. 跨任务通用约束（本机环境坑）如被再次印证，同步到「已知坑位速查」与项目/用户记忆。
4. 如某流程已足够通用且稳定，可考虑抽成独立技能（SkillManage）以便复用；本技能自身用 Edit 直接维护即可（已 agent_created: true）。

> 迭代原则：只沉淀长期有效、可复用的知识；不记录一次性报错与临时过程；涉及敏感信息（密码/密钥）绝不写入技能或记忆。

已知坑位速查

Resources

scripts/

• scan_disk.py — 只读扫描脚本，产出分类报告与 scan_result.json，不删任何文件
• purge_recyclebin_temp.py — 健壮版回收站清理：解析 $I 元数据，宽匹配任意 \Temp\ 来源、安全守卫排除用户文件、合同 $R 硬校验、原生 find -delete 真释放空间。支持 --dry-run

配套工具（技能目录外，D:\evtx_watch\）

• watch_evtx.py — evtx 写入/归档监控脚本
• start_watch.bat — 一键启动器（纯 ASCII 路径，避免中文路径在批处理中乱码）
• analyze_evtx.py — 归档 evtx 分析：通道分布、事件来源 TOP、日期分布
• parse_recyclebin.py — 解析回收站 $I 元数据，还原原始路径/大小/删除时间
• clean_temp.py — 精确清理 Temp 下 evtx / AppxErrorReport / Office 日志
• collect_rb_temp.py / purge_recyclebin_localtemp.py — 2026-10-04 迭代过程中的过渡脚本，功能已并入上面 scripts/purge_recyclebin_temp.py，可忽略或删除