maintaining-windows-health

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Maintaining Windows 11 Health

维护 Windows 11 健康状态

Recovery and prevention playbook for Windows 11 disk and memory crises. A Windows port of the
maintaining-macos-health
skill: same three layers (triage → tiered recovery → automation/alerting) and the same safety invariant — scan → JSON → user picks in a UI → apply deletes only what was picked — but with Windows-native tooling and Windows-specific "never touch" rules. The same playbook works for routine cleanup or first-time setup on a new machine.
Windows 11 磁盘与内存危机的恢复和预防手册。这是
maintaining-macos-health
skill 的 Windows 版本:采用相同的三层结构(triage → 分级恢复 → 自动化/告警)和同样的安全不变量——扫描 → JSON → 用户在 UI 中选择 → 应用阶段仅删除所选项——但改用 Windows 原生工具和 Windows 专属的“禁止触碰”规则。同一套手册既适用于日常清理,也适用于新机器的首次设置。

Table of contents

目录

When to use

使用场景

Trigger on any of:
  • Disk free < 20 % or user complains about being out of space
  • BSOD / unexpected reboot / Kernel-Power 41 / WHEA error / a new crash dump in
    C:\Windows\Minidump
  • "PC is slow", commit pressure high (
    % Committed Bytes In Use
    > 85), pagefile growing
  • User wants to set up monitoring/alerting from scratch
  • Migration to a new Windows PC → restore the same alerter
  • General "clean my PC" / "audit storage" / "free space" requests
出现以下任一情况时触发:
  • 磁盘可用空间 < 20%,或用户抱怨空间不足
  • BSOD / 意外重启 / Kernel-Power 41 / WHEA error /
    C:\Windows\Minidump
    中出现新的 crash dump
  • “PC 运行缓慢”、commit-memory 压力高(
    % Committed Bytes In Use
    > 85)、pagefile 持续增长
  • 用户希望从零开始设置监控或告警
  • 迁移到新的 Windows PC → 恢复同类告警器
  • 一般的“清理我的 PC” / “审计存储” / “释放空间”请求

Skill layout

Skill 布局

FileUse for
references/triage.md
First 5 minutes — which signal fired (disk / commit-memory / BSOD-crash / "feels slow"), read-only snapshot
references/cleanup-tiers.md
Tiered cleanup playbook (10 tiers, low-risk → discuss-first), copy-paste-safe PowerShell blocks
references/never-touch.md
Categories that must not be deleted even elevated (hard-protected prefixes synced with the validator + Windows-only dangers)
references/native-tools.md
The safety floor: native Microsoft tooling, project-artifact purge marker→target map, the apply-script validator rules, third-party caveats
references/alerting.md
Full alerter design: 3 CRITICAL-only triggers, hysteresis, calibration, Task Scheduler interactive session, BurntToast + ntfy, S0ix/battery
assets/win-health-check.ps1
Production PowerShell monitor (PS 5.1 compatible)
assets/win-health-check.config.ps1
Default thresholds
assets/Install-WinHealthCheck.ps1
Registers the scheduled task in the interactive user session;
-Test
/
-Uninstall
assets/Audit-WinHealth.ps1
Read-only preflight inventory (drives, Component Store, shadow storage, profiles, drivers, CFA, KFM, BitLocker, reparse points, dumps)
assets/render-cleanup-plan.py
Interactive HTML cleanup-plan UI. Renders categorised checkboxes from a JSON of scan findings, serves on
127.0.0.1:18347
, opens the browser, waits for the user's selection, writes it to
%TEMP%\cleanup-selection-<ts>.json
. Used by Workflow A. Requires Python 3.
assets/apply-cleanup-selection.py
The only sanctioned way to apply a cleanup selection. Reads
selected_items
from a selection JSON and executes each item's
command
via PowerShell. Windows-rewritten validator (NTFS canonicalization, deny/allow longest-prefix, provider/UNC/ADS/8.3/chaining refusal, two-tier wrappers) + operations log. Supports
--dry-run
.
assets/test_validate_command.py
Adversarial unit tests for the validator — the safety-core gate. Runs on any OS.
Read the relevant reference before acting. Do NOT operate from memory of these files — the details are calibrated to Windows-specific failure modes and small changes break safety.
文件用途
references/triage.md
前 5 分钟:判断触发了哪个信号(磁盘 / commit-memory / BSOD-crash / “感觉很慢”),生成只读快照
references/cleanup-tiers.md
分级清理手册(10 个层级,从低风险到需先讨论),包含可安全复制粘贴的 PowerShell 代码块
references/never-touch.md
即使提升权限也绝不能删除的类别(与验证器同步的硬保护前缀,以及 Windows 专属风险)
references/native-tools.md
安全底线:Microsoft 原生工具、项目产物清理的 marker→target 映射、应用脚本验证器规则和第三方工具注意事项
references/alerting.md
完整的告警器设计:3 个仅限 CRITICAL 的触发器、迟滞、校准、交互用户会话中的 Task Scheduler、BurntToast + ntfy、S0ix/电池
assets/win-health-check.ps1
生产环境 PowerShell 监控脚本(兼容 PS 5.1)
assets/win-health-check.config.ps1
默认阈值
assets/Install-WinHealthCheck.ps1
在交互式用户会话中注册计划任务;支持
-Test
/
-Uninstall
assets/Audit-WinHealth.ps1
只读预检清单(驱动器、Component Store、shadow storage、用户配置文件、驱动程序、CFA、KFM、BitLocker、重解析点、dump)
assets/render-cleanup-plan.py
交互式 HTML 清理计划 UI。根据扫描结果 JSON 渲染分类复选框,在
127.0.0.1:18347
提供服务,打开浏览器,等待用户选择,并将结果写入
%TEMP%\cleanup-selection-<ts>.json
。用于工作流 A。需要 Python 3。
assets/apply-cleanup-selection.py
应用清理选择的唯一许可方式。从选择 JSON 中读取
selected_items
,并通过 PowerShell 执行每个项目的
command
。包含 Windows 版验证器(NTFS 规范化、deny/allow 最长前缀、拒绝 provider/UNC/ADS/8.3/链式路径、两层包装器)和操作日志。支持
--dry-run
。
assets/test_validate_command.py
针对验证器的对抗性单元测试——这是安全核心关卡,可在任意操作系统上运行。
执行操作前先阅读相关参考文档。不要凭记忆操作这些文件——其中的细节针对 Windows 专属故障模式进行了校准,任何微小改动都可能破坏安全性。

Core mental model

核心思维模型

  1. Native tooling is the safety floor. Unlike macOS (Mole), Windows has no mature community safety tool — so Storage Sense / Cleanup recommendations /
    cleanmgr
    / DISM do the heavy lifting, and the apply-script validator is the only line behind project-artifact purge. Use the supported command for anything the OS maintains itself.
  2. Clean with commands, not by deleting folders. WinSxS → DISM; Driver Store → pnputil; shadow copies → vssadmin; Event Logs → wevtutil; hiberfil → powercfg. Hand-deleting these corrupts the OS.
  3. Commit %, not "available MB", is the memory signal.
    Available MBytes
    includes reclaimable standby/cache; commit-limit exhaustion is the real Windows OOM.
  4. Drift protection via the selection JSON. The HTML UI writes exactly what the user picked;
    apply-cleanup-selection.py
    deletes only
    selected_items
    . Never hand-roll
    Remove-Item
    in the apply phase.
  5. Escalate conservatively. Start zero-risk (Storage Sense, caches, Recycle Bin), only reach project artifacts, Docker/WSL VHDX, Component Store, and elevated/discuss-first tiers if needed.
  1. 原生工具是安全底线。 与 macOS 的 Mole 不同,Windows 没有成熟的社区安全清理工具,因此由 Storage Sense / Cleanup recommendations /
    cleanmgr
    / DISM 承担主要清理工作;在清理项目产物之前,apply-script 验证器是唯一一道防线。凡是由操作系统自行维护的内容,都应使用受支持的命令。
  2. 使用命令清理,不要手动删除文件夹。 WinSxS → DISM;Driver Store → pnputil;shadow copies → vssadmin;Event Logs → wevtutil;hiberfil → powercfg。手动删除这些内容会损坏操作系统。
  3. 内存信号应关注 commit 百分比,而不是“可用 MB”。
    Available MBytes
    包含可回收的 standby/cache;耗尽 commit limit 才是真正的 Windows OOM。
  4. 通过选择 JSON 防止漂移。 HTML UI 会准确记录用户所选项目;
    apply-cleanup-selection.py
    仅删除
    selected_items
    。在应用阶段,绝不能自行编写
    Remove-Item
    。
  5. 保守地逐级升级。 从零风险项目开始(Storage Sense、缓存、Recycle Bin),仅在确有需要时才处理项目产物、Docker/WSL VHDX、Component Store,以及需要提升权限或事先讨论的层级。

Standard workflows

标准工作流

A. "Free space NOW" (incident response)

A. “立即释放空间”(事件响应)

  1. Triage — read
    references/triage.md
    , identify which signal fired and how urgent. Run
    assets/Audit-WinHealth.ps1
    (read-only) for the preflight inventory (drives, Component Store, shadow storage, drivers, CFA / OneDrive KFM / BitLocker / reparse points).
  2. Snapshot baseline — record free GB on the target drive.
  3. Run all scans, don't delete yet — work the tiers in
    references/cleanup-tiers.md
    in inventory mode (list candidates, sizes, ages), including the large-file visibility pass. Capture everything before opening the browser; deletion comes only after the user picks via the UI. The cleanup UI should be a single final questionnaire containing safe cleanup candidates, protected/discuss-first items, and large suspicious user/workload files together, not a sequence of separate UI rounds.
  4. Python gate — the cleanup UI needs Python 3. Check for a real interpreter (
    py -3 --version
    , or a
    python.exe
    that isn't the Microsoft Store alias). If Python is missing, ask the user for permission to install it (
    winget install Python.Python.3.12
    ), then continue. Do not silently skip the UI.
  5. Resolve unknown items before building JSON — for every candidate > 500 MB you cannot explain in one sentence (unfamiliar app/folder, vendor cache, VM/VHDX, model weights), research it first: check
    references/never-touch.md
    , then delegate a quick lookup to the
    web-searcher
    subagent ("what is
    <path>
    on Windows 11, safe to delete in 2026"). Write a concrete
    description
    (1–3 sentences in the user's language) into the item. Never show vague placeholders like "unknown".
  6. Show large-but-not-safe items too — any explainable item > 500 MB that is user-owned or workload-owned but not a safe cache must still appear in the same final UI, normally
    protected: true
    ,
    default_selected: false
    , with a concrete
    warning
    . Examples: old
    .7z/.zip/.iso
    archives,
    .gguf
    /
    .safetensors
    model weights, project/game assets, app diagnostic dumps, profiler snapshots, synced-folder media, and VHDX files. Visibility is required because only the user can know whether these are still needed. Do not include hard-protected system internals as bare-delete candidates; show them only through supported tools, or omit deletion entirely if no supported action exists.
  7. Build one data JSON — every candidate becomes a structured
    item
    (id, label, path, size_bytes, age_days, kind, PowerShell
    command
    , mandatory
    description
    , optional
    protected
    +
    warning
    ). Use the schema in
    assets/render-cleanup-plan.py
    . Irreversible-tool commands (DISM
    /ResetBase
    ,
    vssadmin delete
    ,
    wevtutil cl
    ,
    pnputil /delete-driver
    ,
    powercfg /h off
    ) should be marked
    protected: true
    . Do not open the UI until this unified JSON contains both safe default-selected items and protected unchecked items.
  8. Render and open the cleanup UI:
    powershell
    python3 <skill>\assets\render-cleanup-plan.py %TEMP%\cleanup-data-<ts>.json
    It serves on
    127.0.0.1:18347
    , opens the browser, and blocks until Submit/Cancel. On submit it writes
    %TEMP%\cleanup-selection-<ts>.json
    . Tell the user out loud: "браузер открыт — поставь галочки, нажми Submit, потом пингани меня." Then stop and wait.
  9. After the user pings — read the selection JSON, render their choices back in chat (categories, item list, total GB, any protected overrides flagged), and ask one explicit confirmation before deleting.
  10. Apply via the helper — never hand-rolled
    Remove-Item
    :
powershell
python3 <skill>\assets\apply-cleanup-selection.py %TEMP%\cleanup-selection-<ts>.json
#   add --scan-root D:\projects to allow bare deletes on an external dev drive
It reads
selected_items
, validates each
command
(NTFS canonicalization, deny/allow longest-prefix, provider/UNC/ADS/8.3/chaining refusal), skips protected items not in
protected_overrides
, runs each via
powershell.exe
, and logs to
%LOCALAPPDATA%\win-health\operations.log
.
--dry-run
previews. The selection JSON is the single source of truth. 11. Post-check — report the free-space delta, then
Dism /Online /Cleanup-Image /CheckHealth
+
sfc /scannow
to confirm nothing was broken. Stop at the goal.
Hard-protected items (per
references/never-touch.md
) must always appear in the UI with
"protected": true
+ a concrete
warning
— the UI dims them and requires a per-item confirm before they can be checked. Never omit a protected item user data depends on; visibility teaches the surrounding risk.
  1. Triage —— 阅读
    references/triage.md
    ,判断触发了哪个信号及其紧急程度。运行
    assets/Audit-WinHealth.ps1
    (只读),获取预检清单(驱动器、Component Store、shadow storage、驱动程序、CFA / OneDrive KFM / BitLocker / 重解析点)。
  2. 记录基线 —— 记录目标驱动器的可用 GB 数。
  3. 运行所有扫描,但暂不删除 —— 按
    references/cleanup-tiers.md
    中的层级,以 inventory 模式执行(列出候选项、大小和存在时间),同时进行大文件可见性扫描。打开浏览器前应收集全部信息;只有用户在 UI 中选择后才能删除。清理 UI 应是包含安全候选项、受保护或需先讨论的项目,以及大型可疑用户/工作负载文件的单一最终问卷,而不是多轮独立 UI。
  4. Python 前置检查 —— 清理 UI 需要 Python 3。检查是否存在真正的解释器(
    py -3 --version
    ,或确保
    python.exe
    不是 Microsoft Store 别名)。如果缺少 Python,应询问用户是否允许安装(
    winget install Python.Python.3.12
    ),然后继续。不要静默跳过 UI。
  5. 构建 JSON 前先解决未知项目 —— 对于每个无法用一句话解释的 > 500 MB 候选项(陌生应用或文件夹、厂商缓存、VM/VHDX、模型权重),必须先调查:查阅
    references/never-touch.md
    ,然后将快速查询委托给
    web-searcher
    subagent(“
    <path>
    在 Windows 11 上是什么,2026 年是否可安全删除”)。在项目中写入具体的
    description
    (用用户语言撰写 1–3 句话)。绝不能使用“unknown”之类的含糊占位内容。
  6. 也要展示体积较大但不安全的项目 —— 任何能够解释、且属于用户或工作负载但并非安全缓存的 > 500 MB 项目,仍必须出现在同一个最终 UI 中,通常设置为
    protected: true
    、
    default_selected: false
    ,并附上具体的
    warning
    。示例包括旧的
    .7z/.zip/.iso
    压缩包、
    .gguf
    /
    .safetensors
    模型权重、项目或游戏素材、应用诊断 dump、Profiler 快照、同步文件夹中的媒体文件,以及 VHDX 文件。必须展示这些项目,因为只有用户才能判断它们是否仍然需要。不要将硬保护的系统内部内容作为可直接删除的候选项;只能通过受支持的工具处理,或者在没有受支持操作时完全省略删除。
  7. 构建单一数据 JSON —— 每个候选项都转换为结构化
    item
    (id、label、path、size_bytes、age_days、kind、PowerShell
    command
    、必填
    description
    ,以及可选的
    protected
    和
    warning
    )。使用
    assets/render-cleanup-plan.py
    中的 schema。不可逆工具命令(DISM
    /ResetBase
    、
    vssadmin delete
    、
    wevtutil cl
    、
    pnputil /delete-driver
    、
    powercfg /h off
    )应标记为
    protected: true
    。在统一 JSON 同时包含默认选中的安全项目和未选中的受保护项目之前,不要打开 UI。
  8. 渲染并打开清理 UI:
    powershell
    python3 <skill>\assets\render-cleanup-plan.py %TEMP%\cleanup-data-<ts>.json
    它会在
    127.0.0.1:18347
    提供服务、打开浏览器,并阻塞等待用户点击
    Submit
    或
    Cancel
    。点击提交后,它会写入
    %TEMP%\cleanup-selection-<ts>.json
    。明确告知用户:“浏览器已打开——勾选项目,点击
    Submit
    ,然后提醒我。”随后停止并等待。
  9. 用户提醒你之后 —— 读取选择 JSON,在聊天中回显用户的选择(分类、项目列表、总 GB 数,以及标记出的任何 protected override),并明确询问一次确认后再执行删除。
  10. 通过辅助脚本应用——绝不能自行编写
    Remove-Item
    :
    powershell
    python3 <skill>\assets\apply-cleanup-selection.py %TEMP%\cleanup-selection-<ts>.json
    #   add --scan-root D:\projects to allow bare deletes on an external dev drive
    它会读取
    selected_items
    ,验证每个
    command
    (NTFS 规范化、deny/allow 最长前缀、拒绝 provider/UNC/ADS/8.3/链式路径),跳过未列入
    protected_overrides
    的受保护项目,通过
    powershell.exe
    执行各项操作,并将日志写入
    %LOCALAPPDATA%\win-health\operations.log
    。
    --dry-run
    可用于预览。选择 JSON 是唯一的事实来源。
  11. 执行后检查 —— 报告可用空间变化,然后运行
    Dism /Online /Cleanup-Image /CheckHealth
    和
    sfc /scannow
    ,确认系统未受损。达到目标后即可停止。
硬保护项目(依据
references/never-touch.md
)必须始终出现在 UI 中,并带有
"protected": true
和具体的
warning
——UI 会将其变暗,并要求用户逐项确认后才能勾选。绝不能省略用户数据所依赖的受保护项目;展示它们有助于说明周边风险。

B. "Set up alerting" (new machine or first time)

B. “设置告警”(新机器或首次设置)

Run a non-elevated PowerShell as the user who should receive alerts (interactive session — required for toasts):
powershell
cd <skill>\assets
.\Install-WinHealthCheck.ps1     # installs BurntToast, copies script+config, registers the task, runs once
Then read
references/alerting.md
for tuning. The task is registered in the interactive user session (NOT SYSTEM — that silently swallows toasts), every 5 minutes,
-StartWhenAvailable
, battery-friendly. The first 7-day calibration window is silent (logs only). Verify with
.\Install-WinHealthCheck.ps1 -Test
.
以应当接收告警的用户身份运行非提升权限的 PowerShell(交互式会话——Toast 通知所必需):
powershell
cd <skill>\assets
.\Install-WinHealthCheck.ps1     # installs BurntToast, copies script+config, registers the task, runs once
然后阅读
references/alerting.md
以调整配置。任务会注册在交互式用户会话中(绝不能使用
SYSTEM
——那样 Toast 通知会被静默吞掉),每 5 分钟运行一次,启用
-StartWhenAvailable
,并兼顾电池续航。前 7 天的校准窗口保持静默,仅记录日志。使用
.\Install-WinHealthCheck.ps1 -Test
进行验证。

C. Alerter stopped working / making noise

C. 告警器停止工作或频繁触发

Read
references/alerting.md
§ Troubleshooting. Common causes:
  • Task running as SYSTEM / "whether user is logged on or not" → toasts silently never render. Re-run the installer (interactive principal).
  • BurntToast not installed → toast attributed to "PowerShell" or absent.
    Install-Module BurntToast -Scope CurrentUser
    .
  • Laptop never checks → was AC-only / paused in sleep. Re-run installer (battery flags +
    -StartWhenAvailable
    ).
  • Constant alerts during heavy work → create
    %LOCALAPPDATA%\win-health\silent
    , raise thresholds, or increase hysteresis.
阅读
references/alerting.md
的“Troubleshooting”章节。常见原因包括:
  • Task 以
    SYSTEM
    身份运行,或启用了“whether user is logged on or not” → Toast 通知会静默失效。重新运行安装脚本,并使用交互式 principal。
  • 未安装 BurntToast → Toast 会显示为来自“PowerShell”,或者完全不出现。运行
    Install-Module BurntToast -Scope CurrentUser
    。
  • 笔记本从不检查 → 任务仅在接通电源时运行,或在睡眠期间被暂停。重新运行安装脚本,并启用电池标志和
    -StartWhenAvailable
    。
  • 密集工作期间持续告警 → 创建
    %LOCALAPPDATA%\win-health\silent
    ,提高阈值,或增大迟滞。

D. "Uninstall an app cleanly"

D. “干净卸载应用”

Prefer
winget uninstall --id <App.Id>
(clean, supported). For apps with stubborn leftovers, BCUninstaller (review the leftover list) is the dev-friendly option. Never hand-delete
Program Files
install dirs or registry keys to "remove" an app — that orphans the MSI/uninstall state. Always confirm before removing user data folders.
优先使用
winget uninstall --id <App.Id>
(干净且受支持)。对于存在顽固残留项的应用,BCUninstaller 是对开发者友好的选择,但应先审查残留项列表。绝不要手动删除
Program Files
下的安装目录或注册表项来“卸载”应用,否则会使 MSI/卸载状态孤立。删除用户数据文件夹前,始终需要确认。

Safety rules (non-negotiable)

安全规则(不可协商)

  1. Never delete without dry-run + user confirmation for any tier ≥ 5 or any elevated operation.
  2. Never bypass
    references/never-touch.md
    — even if the user explicitly asks. Push back, explain the consequence.
  3. Clean with commands, not folders. WinSxS via DISM, Driver Store via pnputil, shadows via vssadmin, logs via wevtutil (export before clear), hiberfil via powercfg. Never
    Remove-Item
    these.
  4. The registry is never a cleanup target. No registry cleaners (Microsoft-unsupported). The validator refuses registry-provider deletes.
  5. Apply phase reads only the selection JSON. Never hand-roll
    Remove-Item
    or hard-code paths from the earlier scan when applying — that's how you delete items the user unchecked. Use
    assets/apply-cleanup-selection.py
    , which iterates
    selected_items
    only.
  6. Remove-Item
    is permanent
    (no Recycle Bin) and recursive deletes can escape through junctions — always
    -LiteralPath
    , never recurse a reparse point. Prefer move-to-quarantine when the user is unsure.
  7. No auto-cleanup tied to alerts. Alerts notify; the human decides.
  8. Keep crash dumps until triaged — they're forensic evidence, not cleanup.
  1. 对于第 5 层及以上的任何层级或任何提升权限的操作,绝不能在未执行 dry-run 且获得用户确认的情况下删除。
  2. 绝不能绕过
    references/never-touch.md
    ——即使用户明确要求也应拒绝,并说明可能造成的后果。
  3. 使用命令清理,而不是删除文件夹。 WinSxS 使用 DISM,Driver Store 使用 pnputil,shadow copies 使用 vssadmin,日志使用 wevtutil(清除前先导出),hiberfil 使用 powercfg。绝不对这些内容使用
    Remove-Item
    。
  4. 注册表永远不是清理目标。 不使用注册表清理工具(Microsoft 不支持)。验证器会拒绝针对注册表 provider 的删除操作。
  5. 应用阶段只读取选择 JSON。 绝不能自行编写
    Remove-Item
    ,也不能硬编码早期扫描得到的路径后再执行删除——这正是误删用户未勾选项目的原因。应使用
    assets/apply-cleanup-selection.py
    ,它只遍历
    selected_items
    。
  6. Remove-Item
    是永久删除
    (不会进入 Recycle Bin),递归删除还可能通过 junction 逃逸——始终使用
    -LiteralPath
    ,绝不递归处理 reparse point。如果用户不确定,应优先移入隔离区。
  7. 不要将自动清理与告警绑定。 告警只负责通知,决定权始终在用户手中。
  8. 完成 triage 前保留 crash dump——它们是取证证据,不是清理对象。

Domain quirks captured

已涵盖的领域特性

  • SYSTEM session can't show toasts. A scheduled task as SYSTEM executes but its toasts silently no-op (Session 0 has no desktop). Register the task in the interactive user session — the Windows analog of the macOS "osascript → Script Editor" trap.
  • Remove-Item -Recurse
    follows junctions
    and can delete the target's contents — the classic data-loss bug. Dev trees are full of junctions (npm/pnpm store, Docker, WSL). Use
    -LiteralPath
    ; never recurse a
    FILE_ATTRIBUTE_REPARSE_POINT
    .
  • Remove-Item
    bypasses the Recycle Bin
    — deletion is immediate and permanent, unlike dragging to the bin.
  • OneDrive KFM redirects Desktop/Documents/Pictures into OneDrive — deleting there propagates to all devices. Files On-Demand placeholders (
    RECALL_ON_DATA_ACCESS
    /
    OFFLINE
    ) are cloud originals; deleting the stub deletes the cloud file.
  • Controlled Folder Access blocks deletes in Documents/Pictures/Desktop with Access Denied from Defender — distinguish from a real error.
  • Available MBytes
    includes standby/cache
    — high "available" doesn't mean healthy; commit-limit exhaustion is the real OOM signal.
  • pagefile.sys
    and
    swapfile.sys
    are two different files
    ;
    C:\Windows\Installer
    +
    Package Cache
    break MSI repair if deleted; Prefetch should not be cleaned (myth).
  • Modern Standby (S0ix) makes wake timers unreliable and hides S3 — normal, not a fault. The task pauses in sleep and catches up on wake via
    -StartWhenAvailable
    .
  • General rule: if you can't describe a folder in one sentence (especially > 500 MB), don't guess — delegate a
    web-searcher
    lookup before writing the item's
    description
    . If you can describe it but it may be user data, still show it in the single final cleanup UI as protected and unchecked by default.
  • SYSTEM
    会话无法显示 Toast。
    以
    SYSTEM
    身份运行的计划任务虽然能够执行,但其 Toast 通知会静默失效(Session 0 没有桌面)。应将任务注册在交互式用户会话中——这相当于 Windows 中 macOS“osascript → Script Editor”陷阱的对应问题。
  • Remove-Item -Recurse
    会跟随 junction
    ,可能删除目标内容——这是典型的数据丢失缺陷。开发目录中遍布 junction(npm/pnpm store、Docker、WSL)。使用
    -LiteralPath
    ;绝不递归处理
    FILE_ATTRIBUTE_REPARSE_POINT
    。
  • Remove-Item
    会绕过 Recycle Bin
    ——与拖入回收站不同,删除会立即且永久生效。
  • OneDrive KFM 会将 Desktop/Documents/Pictures 重定向到 OneDrive——删除这些位置的内容会传播到所有设备。Files On-Demand 占位文件(
    RECALL_ON_DATA_ACCESS
    /
    OFFLINE
    )对应云端原件;删除 stub 就会删除云端文件。
  • Controlled Folder Access 会阻止删除 Documents/Pictures/Desktop 中的内容,Defender 会返回 Access Denied——应将其与真实错误区分开。
  • Available MBytes
    包含 standby/cache
    ——较高的“可用”值并不意味着系统健康;耗尽 commit limit 才是真正的 OOM 信号。
  • pagefile.sys
    和
    swapfile.sys
    是两个不同的文件
    ;删除
    C:\Windows\Installer
    或
    Package Cache
    会破坏 MSI 修复能力;Prefetch 不应清理,这是一个误区。
  • Modern Standby(S0ix) 会使唤醒计时器变得不可靠,并隐藏 S3 状态——这是正常现象,并非故障。任务会在睡眠期间暂停,并在唤醒后通过
    -StartWhenAvailable
    补执行。
  • 通用规则:如果无法用一句话描述某个文件夹(尤其是 > 500 MB),不要猜测——先委托
    web-searcher
    查询,再编写项目的
    description
    。如果能够描述它,但它可能属于用户数据,仍应在单一最终清理 UI 中将其显示为受保护且默认不勾选。

Outcomes scale

成效规模

A representative recovery on a dev machine that hit ~8 % free under heavy AI/Docker/WSL load:
  • Largest single contribution: project build artifacts (
    node_modules
    ,
    bin
    /
    obj
    ,
    target
    ,
    .next
    ) via Tier 7 purge.
  • WSL2 / Docker
    *.vhdx
    compaction (not deletion): often 10–40 GB reclaimed.
  • Component Store cleanup via DISM after many cumulative updates: a few GB.
  • Package-manager caches (npm/pnpm/NuGet/pip/cargo/gradle): a few GB.
  • Downloads
    review (old installers, ISOs): variable, often 10–20 GB.
  • Elevated tier (Windows.old after rollback check, Delivery Optimization, exported+cleared logs): variable.
Active alerter installed with a 7-day calibration window; verified via the synthetic disk-trigger test before going live. Numbers scale with workload and disk size — light users see less; heavy AI/Docker/WSL/IDE users see more.
以下是一个代表性恢复案例:某开发机在繁重的 AI/Docker/WSL 负载下,可用空间降至约 8%。
  • 最大单项来源:项目构建产物(
    node_modules
    、
    bin
    /
    obj
    、
    target
    、
    .next
    ),通过第 7 层清理释放。
  • 压缩 WSL2 / Docker
    *.vhdx
    (不是删除):通常可回收 10–40 GB。
  • 多次累积更新后,通过 DISM 清理 Component Store:可回收数 GB。
  • 包管理器缓存(npm/pnpm/NuGet/pip/cargo/gradle):可回收数 GB。
  • 审查
    Downloads
    中的旧安装包和 ISO:可回收空间不等,通常为 10–20 GB。
  • 提升权限的层级(确认可回滚后的 Windows.old、Delivery Optimization、导出后清除的日志):回收量不定。
主动告警器已安装,并设有 7 天校准窗口;正式启用前已通过合成的磁盘触发测试完成验证。实际数值会随工作负载和磁盘容量变化——轻度用户回收空间较少;重度 AI/Docker/WSL/IDE 用户回收空间更多。