maintaining-windows-health

维护 Windows 11 健康状态

应对和预防 Windows 11 磁盘与内存危机的操作手册。这是 maintaining-macos-health 技能的 Windows 版本：采用相同的三层结构（分诊 → 分级恢复 → 自动化/告警），并遵循相同的安全不变量——扫描 → JSON → 用户在 UI 中选择 → 仅应用删除所选内容，但使用 Windows 原生工具，并遵守 Windows 特有的“绝不触碰”规则。此操作手册既适用于日常清理，也适用于新电脑的首次设置。

目录

• 适用场景
• 技能目录结构
• 核心思路
• 标准工作流
  • A.“立即释放空间”（事件响应）
  • B.“设置告警”（新电脑或首次设置）
  • C.告警器停止工作/发出噪声
  • D.“彻底卸载应用”
• 安全规则（不可妥协）
• 已记录的领域特有问题
• 结果等级

适用场景

出现以下任一情况时使用：

• 磁盘可用空间 < 20 %，或用户抱怨空间不足
• BSOD / 意外重启 / Kernel-Power 41 / WHEA 错误 / C:\Windows\Minidump 中出现新的崩溃转储文件
• “电脑很慢”、提交内存压力高（% Committed Bytes In Use > 85）、页面文件不断增大
• 用户希望从头开始设置监控/告警
• 迁移到新的 Windows PC → 恢复相同的告警器
• 一般性的“清理我的电脑”/“检查存储空间”/“释放空间”请求

技能目录结构

文件	用途
references/triage.md	前 5 分钟——确定触发了哪个信号（磁盘 / 提交内存 / BSOD 崩溃 /“感觉很慢”），生成只读快照
references/cleanup-tiers.md	分级清理操作手册（10 个等级，从低风险到先讨论），可安全复制粘贴的 PowerShell 代码块
references/never-touch.md	即使提升权限也绝不能删除的类别（与验证器同步的严格保护前缀 + 仅限 Windows 的危险项）
references/native-tools.md	安全底线：Microsoft 原生工具、项目产物清理标记→目标映射、应用脚本验证器规则、第三方注意事项
references/alerting.md	完整的告警器设计：3 个仅限 CRITICAL 级别的触发器、滞回、校准、任务计划程序交互式会话、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	只读预检清单（驱动器、组件存储、卷影存储、用户配置文件、驱动程序、CFA、KFM、BitLocker、重解析点、转储文件）
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 规范化、拒绝/允许最长前缀、拒绝提供程序/UNC/ADS/8.3/命令串联、两级包装器）+ 操作日志。支持 --dry-run。
assets/test_validate_command.py	针对验证器的对抗性单元测试——安全核心门禁。可在任何操作系统上运行。

操作前请阅读相关参考文件。切勿凭记忆操作这些文件——其中的细节针对 Windows 特有的故障模式进行了校准，细微改动也可能破坏安全性。

核心认知模型

1. 原生工具是安全底线。 与 macOS（Mole）不同，Windows 没有成熟的社区安全工具，因此主要依靠存储感知、清理建议、cleanmgr 和 DISM；而应用脚本验证器是清理项目产物的唯一防线。对于由操作系统自行维护的内容，请使用受支持的命令。
2. 用命令清理，不要直接删除文件夹。 WinSxS → DISM；Driver Store → pnputil；卷影副本 → vssadmin；事件日志 → wevtutil；hiberfil → powercfg。手动删除这些内容会损坏操作系统。
3. 内存信号看提交量百分比，而不是“可用 MB”。 Available MBytes 包含可回收的待机内存和缓存；真正导致 Windows 内存不足（OOM）的是提交量达到上限。
4. 通过选择 JSON 防止偏移。 HTML 界面会准确写入用户的选择；apply-cleanup-selection.py 只会删除 selected_items 中的项目。应用阶段绝不要自行编写 Remove-Item。
5. 谨慎逐步升级。 从零风险操作（存储感知、缓存、回收站）开始；只有确有需要时，才处理项目产物、Docker/WSL VHDX、组件存储，以及需要提升权限或应先讨论的项目。

标准工作流

A.“立即释放空间”（故障响应）

1. 分诊 — 阅读 references/triage.md，确认触发了哪种信号以及紧急程度。运行 assets/Audit-WinHealth.ps1（只读）进行预检盘点（驱动器、组件存储、卷影存储、驱动程序、CFA / OneDrive KFM / BitLocker / 重解析点）。
2. 记录基线快照 — 记录目标驱动器的可用空间（GB）。
3. 运行所有扫描，暂不删除 — 按照 references/cleanup-tiers.md 中的层级，以盘点模式执行（列出候选项、大小、存放时长），包括大文件可见性检查。在打开浏览器之前收集所有信息；只有用户通过 UI 选择后才能删除。清理 UI 应是一个最终问卷，将安全清理候选项、受保护／需先讨论的项目，以及可疑的大型用户／工作负载文件放在一起，而不是分成多轮 UI。
4. Python 门槛检查 — 清理 UI 需要 Python 3。检查是否有真正的解释器（py -3 --version，或不是 Microsoft Store 别名的 python.exe）。如果缺少 Python，请征求用户同意安装（winget install Python.Python.3.12），然后继续。不要悄悄跳过 UI。
5. 构建 JSON 前先确认未知项目 — 对于每个超过 500 MB 且无法用一句话解释的候选项（不熟悉的应用／文件夹、供应商缓存、VM/VHDX、模型权重），先进行调查：检查 references/never-touch.md，然后委派 web-searcher 子 Agent 快速查询（“what is <path> on Windows 11, safe to delete in 2026”）。在该项目中用用户的语言写出具体的 description（1–3 句）。绝不要显示“unknown”之类含糊的占位文本。
6. 也显示较大但不安全的项目 — 对于任何超过 500 MB、可以解释、由用户或工作负载拥有但并非安全缓存的项目，仍必须将其显示在同一个最终 UI 中，通常设为 protected: true、default_selected: false，并提供具体的 warning。例如：旧的 .7z/.zip/.iso 归档、.gguf/.safetensors 模型权重、项目／游戏资源、应用诊断转储、分析器快照、同步文件夹中的媒体，以及 VHDX 文件。必须让用户看到这些项目，因为只有用户知道它们是否仍有用。不要将受严格保护的系统内部文件列为可直接删除的候选项；只能通过受支持的工具显示，或者在没有受支持操作时完全不提供删除选项。
7. 构建一个数据 JSON — 每个候选项都必须成为一个结构化的 item（id、label、path、size_bytes、age_days、kind、PowerShell command、必填的 description、可选的 protected + warning）。使用 assets/render-cleanup-plan.py 中的架构。不可逆工具命令（DISM /ResetBase、vssadmin delete、wevtutil cl、pnputil /delete-driver、powercfg /h off）应标记为 protected: true。在这个统一 JSON 同时包含默认选中的安全项目和未勾选的受保护项目之前，不要打开 UI。
8. 渲染并打开清理 UI：

   python3 <skill>\assets\render-cleanup-plan.py %TEMP%\cleanup-data-<ts>.json
   

   它会在 127.0.0.1:18347 上提供服务、打开浏览器，并一直阻塞到用户提交／取消。提交后，它会将内容写入 %TEMP%\cleanup-selection-<ts>.json。明确告诉用户：“浏览器已打开——请勾选项目并点击 Submit，然后告诉我。”随后停止并等待。
9. 用户发来消息后 — 读取选择 JSON，在聊天中复述用户的选择（类别、项目列表、总计 GB，以及任何标记出的受保护项目覆盖），并在删除前明确征求一次确认。
10. 通过辅助工具执行 — 绝不要手动编写 Remove-Item：

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 规范化、拒绝／允许最长前缀规则、拒绝 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. “设置警报”（新设备或首次设置）

以应接收警报的用户身份，在非提升权限的 PowerShell 中运行（需要交互式会话才能显示 Toast）：

cd <skill>\assets
.\Install-WinHealthCheck.ps1     # installs BurntToast, copies script+config, registers the task, runs once

然后阅读 references/alerting.md 以调整设置。任务会注册在交互式用户会话中（而非 SYSTEM——SYSTEM 会悄无声息地拦截 Toast），每 5 分钟运行一次，并设置 -StartWhenAvailable，兼顾电池续航。首次 7 天的校准期内不会发出警报（仅记录日志）。使用 .\Install-WinHealthCheck.ps1 -Test 验证。

C. 警报器停止工作／不断发出警报

阅读 references/alerting.md § 故障排除。常见原因：

• 任务以 SYSTEM 身份运行／设置为“无论用户是否登录都运行”→ Toast 不会显示。重新运行安装程序（使用交互式主体）。
• 未安装 BurntToast → Toast 显示来源为“PowerShell”，或完全不显示。运行 Install-Module BurntToast -Scope CurrentUser。
• 笔记本电脑从不检查 → 之前设置为仅接通交流电源时运行／睡眠时暂停。重新运行安装程序（设置电池标志和 -StartWhenAvailable）。
• 高负载工作期间持续收到警报 → 创建 %LOCALAPPDATA%\win-health\silent、提高阈值或增加迟滞。

D. “彻底卸载应用”

优先使用 winget uninstall --id <App.Id>（干净且受支持）。对于残留难以清理的应用，BCUninstaller 是对开发者友好的选择（请检查残留项列表）。切勿手动删除 Program Files 安装目录或注册表项来“移除”应用——这会导致 MSI／卸载状态成为孤项。移除用户数据文件夹前务必确认。

安全规则（不可妥协）

1. 对于任何等级 ≥ 5 的操作或任何提升权限的操作，未经试运行和用户确认，绝不删除。
2. 绝不绕过 references/never-touch.md——即使用户明确提出要求也不行。应予以拒绝并说明后果。
3. **使用命令清理，而非直接删除文件夹。**使用 DISM 清理 WinSxS，使用 pnputil 清理 Driver Store，使用 vssadmin 清理卷影副本，使用 wevtutil 清理日志（清除前先导出），使用 powercfg 清理 hiberfil。绝不对此使用 Remove-Item。
4. **注册表绝不是清理目标。**不得使用注册表清理工具（Microsoft 不支持）。验证器会拒绝通过注册表提供程序执行的删除操作。
5. **应用阶段只读取选择 JSON。**应用时绝不手动编写 Remove-Item 命令，也不使用早期扫描中硬编码的路径——这样会误删用户未勾选的项目。使用 assets/apply-cleanup-selection.py，它只会遍历 selected_items。
6. Remove-Item 会永久删除（不会进入回收站），递归删除还可能通过联接点越界——务必使用 -LiteralPath，绝不递归删除重解析点。用户拿不准时，优先移至隔离区。
7. **不得将自动清理与警报绑定。**警报只负责通知，由用户自行决定。
8. 分类处理前保留崩溃转储文件——它们是取证证据，不是待清理内容。

捕获的领域特性

• SYSTEM 会话无法显示 Toast。 以 SYSTEM 身份运行的计划任务会执行，但 Toast 会静默无效（Session 0 没有桌面）。请在交互式用户会话中注册任务——这相当于 macOS 上的“osascript → Script Editor”陷阱。
• Remove-Item -Recurse 会跟随联接点，并可能删除目标内容——这是经典的数据丢失问题。开发目录中到处都是联接点（npm/pnpm 存储区、Docker、WSL）。请使用 -LiteralPath；绝不要递归处理 FILE_ATTRIBUTE_REPARSE_POINT。
• Remove-Item 会绕过回收站——删除会立即且永久生效，不像拖到回收站那样。
• OneDrive KFM 会将 Desktop/Documents/Pictures 重定向到 OneDrive——在那里删除文件会同步到所有设备。文件按需功能的占位文件（RECALL_ON_DATA_ACCESS/OFFLINE）对应云端原始文件；删除占位文件会删除云端文件。
• 受控文件夹访问会阻止删除 Documents/Pictures/Desktop 中的文件，并由 Defender 返回 Access Denied——请区分这与真正的错误。
• Available MBytes 包含备用内存/缓存——“可用”值高并不代表状态良好；提交限制耗尽才是真正的 OOM 信号。
• pagefile.sys 和 swapfile.sys 是两个不同的文件；删除 C:\Windows\Installer 和 Package Cache 会导致 MSI 修复失败；Prefetch 不应清理（这是个误区）。
• **现代待机（S0ix）**会使唤醒计时器变得不可靠，并隐藏 S3——这是正常现象，不是故障。任务会在睡眠期间暂停，并通过 -StartWhenAvailable 在唤醒后补执行。
• 通用规则：如果你无法用一句话描述某个文件夹（尤其是大于 500 MB 的文件夹），就不要猜——先委派 web-searcher 查询，再填写该项的 description。即使你能描述它，只要它可能包含用户数据，仍应在唯一的最终清理界面中将其列为受保护项，并默认不勾选。

效果范围

在一台承受高强度 AI/Docker/WSL 负载、可用空间降至约 8 % 的开发机器上，具有代表性的恢复效果：

• 最大的单项贡献：通过 Tier 7 清理项目构建产物（node_modules、bin/obj、target、.next）。
• WSL2 / Docker *.vhdx 压缩（而非删除）：通常可释放 10–40 GB。
• 多次累积更新后，通过 DISM 清理组件存储：可释放数 GB。
• 包管理器缓存（npm/pnpm/NuGet/pip/cargo/gradle）：可释放数 GB。
• Downloads 检查（旧安装程序、ISO）：效果不定，通常可释放 10–20 GB。
• 提权层级（回滚检查后清理 Windows.old、清理传递优化文件、导出并清除日志）：效果不定。

已安装主动告警器，并设置 7 天校准窗口；上线前已通过合成磁盘触发测试验证。具体数字会随工作负载和磁盘大小变化——轻度用户释放较少；重度 AI/Docker/WSL/IDE 用户释放较多。