RemoveWindowsAI：一键移除 Windows 11 中的所有 AI 组件
基于 PowerShell 的系统清理脚本，旨在从 Windows 11 中彻底移除 Copilot、Recall 等 AI 组件，适合注重隐私的高级用户与运维人员，但存在高风险、兼容性与许可不明等限制，应在可恢复环境中谨慎使用。
GitHub zoicware/RemoveWindowsAI 更新 2026-01-15 分支 main 星标 8.4K 分叉 262
PowerShell Windows 11 系统精简 隐私保护 CBS 包管理 Appx 移除

💡 深度解析

3
如果没有启用备份或回滚失败，如何恢复被删除的系统组件？有哪些现实可行的恢复路径与风险？

核心分析

问题核心：在未启用脚本备份或回滚失败的情况下，如何尽可能恢复被删除的系统组件，以及每种恢复方式的可行性与风险。

技术分析

  • 首选恢复路径：
    1. 脚本自带回滚：如果 -backupMode 已启用并且备份完整，优先使用 -revertMode。
    2. DISM 与 SFC 修复：运行 DISM /Online /Cleanup-Image /RestoreHealth 然后 sfc /scannow，尝试从 Windows Update 或指定的源修复组件。
    3. 就地升级（in-place upgrade）：使用相同或更高版本的 Windows 安装媒体执行修复安装，通常能恢复系统文件与组件而不丢失个人数据。
    4. 重装系统：当上述方法都失败时，作为最后手段进行全新安装并恢复数据。

  • 每种方法的限制与风险：

  • DISM/SFC：依赖可用的修复源。若 CBS 数据库已严重损坏，这些工具可能无法完全修复。
  • 就地升级：通常有效但耗时，并可能被企业策略或加密策略阻止。
  • 重装：最稳妥但代价最大，需确保数据备份完整。

实用建议

  1. 尽快停止进一步变更并收集日志（脚本输出、事件查看器），以便诊断问题范围。
  2. 先尝试 DISM + SFC，记录输出以决定是否需要更激进的修复（就地升级）。
  3. 若有重要数据，先备份用户数据（外部磁盘或网络位置）再做系统级修复或重装。
  4. 在企业环境中联系支持团队或使用官方修复流程，避免自行执行可能影响支持合同的操作。

重要提示：没有备份时恢复成本与复杂性显著增加。脚本运行前启用 -backupMode 是降低风险的最直接措施。

总结：缺乏备份并非无法恢复，但会增加使用 DISM/SFC、就地升级或重装的可能性和成本。始终优先做好备份以避免高代价恢复。

87.0%
该脚本如何在 CBS（Component-Based Servicing）层面移除锁定的 AI 包？这种方法的优势和风险是什么？

核心分析

问题核心：脚本声称能从 CBS（Component-Based Servicing）存储中移除隐藏和被锁定的 AI 包，这比仅卸载 Appx 包更能彻底清理系统级组件，但也引入更高的系统风险。

技术分析

  • 实现方向（推断）：脚本在管理员权限下直接定位 CBS 存储中的包标识或安装文件，通过文件级清理或调用低层维护命令删除这些包，绕开 Appx/Store 的不可卸载保护。脚本要求使用 Windows PowerShell 5.1，表明会使用一些与系统服务深度交互的命令。
  • 主要优势：
  • 彻底性：能够移除被标记为“系统级”或“非可移除”的 AI 包，覆盖 WindowsWorkload 相关组件。
  • 恢复隐私/关闭功能：对被系统保护的 AI 功能也能进行清理。
  • 主要风险：
  • 系统完整性风险：直接修改 CBS 可能破坏组件数据库，使 Windows Update、DISM 或 SFC 运行时出现错误。
  • 更新兼容性风险：重大系统更新可能因为组件状态不一致而失败或反弹（被重新安装或引发修复）。

实用建议

  1. 仅在测试或快照保护的环境执行，不在关键生产机直接操作。
  2. 启用备份模式并保存备份产物，以便尝试官方修复路径或脚本回滚。
  3. 若出现系统异常，优先使用 DISM /Online /Cleanup-Image 与 SFC /scannow 查找并修复依赖问题。

重要提示：CBS 层的改动属于高危操作，建议只有高级用户或系统管理员在完全备份的前提下执行。

总结：CBS 层删除可实现比常规方法更深入的清理效果，但风险显著，需权衡彻底性与系统稳定性，优先在可回滚环境中执行。

86.0%
脚本所用的“安装自定义 Windows Update 包以防止再安装”机制有多可靠？长期有效性如何？

核心分析

问题核心：脚本采用安装自定义 Windows Update 包来阻止系统重新安装被移除的 AI 包。这是一种主动钉住（pinning）策略，但其可靠性和持久性依赖多项外部因素。

技术分析

  • 短期有效性：通过引入自定义更新包（可能占用相同包标识或提供替代实现），可以在当前 Windows 更新策略和包命名下阻止 Windows Update 将原包写回 CBS 存储。对已知、固定包名和路径的情况通常奏效。
  • 长期局限性：
  • 签名与验证：Windows Update 和 CBS 对包签名、元数据有严格要求，微软可能更改签名策略或发布强制覆盖包。
  • 包标识变更：如果微软更改包名或安装路径，已有的占位包可能失效。
  • 重大系统升级：feature updates 或 cumulative updates 可能绕过或重置这些防护措施。
  • 维护成本：要持续有效，需要维护脚本与更新包以跟随微软的更改。

实用建议

  1. 把防再安装视为短期防护措施，而非永久保证；定期检查脚本更新并关注系统更新日志。
  2. 若希望长期稳定，需要建立监控流程：定期验证被钉住的包是否仍被系统恢复。
  3. 在受管理环境中，优先通过企业管理工具（WSUS、SCCM）结合策略层面阻止不需要的包，而非仅靠本地占位包。

重要提示：此机制并不等同于官方支持的卸载/阻止方式，微软发布的后续更新可能会恢复或改变行为。

总结：自定义更新包在短期是有用且有效的防回安装策略，但其长期可靠性受限，需持续维护与监控。

84.0%

✨ 核心亮点

  • 覆盖 Copilot、Recall 与 AI 服务的全面清理
  • 支持备份模式与可选回滚，提高恢复可行性
  • 需管理员权限并要求在 PowerShell 5.1 下运行
  • 仓库无明确许可且贡献者/版本信息缺失，维护风险高

🔧 工程化

  • 使用 PowerShell 脚本禁用注册表项、移除 Appx 与 CBS 中锁定的 AI 包
  • 可替换现代应用为经典版本，并包含任务/文件清理与隐藏设置页面功能

⚠️ 风险

  • 对 CBS 和系统包的强制修改可能导致更新失败或系统不稳定
  • 缺少许可证与活跃维护信息，法律与长期兼容性存在不确定性
  • 反病毒软件可能误报需临时禁用或添加排除，增加操作复杂度

👥 适合谁？

  • 面向高级用户、系统管理员与隐私关注者，适用于想彻底去除 AI 组件的场景
  • 建议具备管理员权限与 PowerShell 操作经验，并在虚拟机或备份环境中先行测试