2026 年 9 月 29 日，一个名叫 RemoveMacAI 的开源命令行工具在 GitHub 上发布。它的唯一目标，是从 macOS 27 的磁盘底层挖出那些用户以为已经删掉的 Apple Intelligence 模型文件。
在 macOS 27 的设置菜单中，苹果取消了控制 Apple Intelligence 的全局单一开关。当用户在系统设置面板中逐一关闭各项 AI 功能后，那些体积总计约 12GB 的模型权重文件，依然会驻留在固态硬盘的系统目录里。你按下的只是 UI 界面上的功能触发器。底层服务不仅保留着参数模型，还维持着随时拉取更新的下载通道。
界面开关变为虚假安慰剂
一台标配 256GB 存储的 Mac，原本就要承受操作系统和预置应用的挤压。端侧模型时代的到来，意味着又有 12GB 的空间要强制分配给 AI 模型。苹果宁可让这些巨大的数据块在硬盘里长期闲置。他们不愿在设置界面开放一个让用户自主释放物理存储的按钮。
这种设计将界面的「关闭功能」和底层的「卸载模型」拆分成了两个不相干的状态。系统设置面板不再提供一键清空本地资产的通道。开发者在提交 RemoveMacAI 的初始版本时，在 README 开头特别强调了这批模型文件占用「about 12 GB」的存储空间。
但在随后的代码更新中，作者提交了一个名为「Drop the model size from the README intro」的修改记录。他将关于体积的具体数字从开头移除，仅在技术功能清单里低调保留。开发者争夺的核心直指谁在这个系统里拥有最终的文件裁量权。
保留在本地的并非只有静态的模型权重。macOS 的后台资产分发机制会持续监听操作系统的功能状态。只要系统级的下载通道不被物理切断，系统随时可以通过后台静默更新机制，拉取最新的大模型覆盖原有文件。
三步连环绕过系统屏障
面对深入操作系统的锁定机制，RemoveMacAI 给出了一套不需要关闭系统完整性保护（SIP）的底层解法。这个由 82% Swift 和 14% Objective-C 混合编写的工具只面向 Apple silicon，当前版本 0.2.3。它明确标注 macOS 27.0.1 必须搭配该版本及以上才能稳定执行。
图：RemoveMacAI 仓库首页展示的运行状态截图。来源：RemoveMacAI 仓库（docs/hero.png）
工具切除模型的第一步，是向系统强制安装特制的配置描述文件。它直接写入苹果官方为企业管理预留的限制键，并强行锁定那些原本没有对应限制键的偏好设置项。这一步从底层配置层面阻断了 AI 功能的运行路径。
第二步是对本地存量模型文件的物理清除。工具并不使用常规的命令行强删文件，而是直接调用 macOS 的 Unified Asset Framework（UAF）服务发起资产删除请求。由于请求是通过系统自带的合法资产管理接口下发的，工具全程在开启 SIP 的严苛环境中完成了 12GB 文件的擦除指令。
第三步是阻断系统自我修复的后台流量。苹果的系统进程拥有强大的后台恢复逻辑。一旦检测到核心资产丢失，便会触发 MobileAsset 框架进行重试下载。工具逐一修改了每一种被删资产类型的 MobileAsset 下载服务器网络地址，将其强行指向无效端点。这直接切断了 macOS 重新连接苹果官方服务器下载模型的能力。
连根拔除诱发应用崩溃
强制剥离系统级 AI 模型，不可避免地带来大面积的功能断裂。执行 removemacai off 后，所有依赖苹果端侧模型的系统组件立刻陷入瘫痪。调用 Foundation Models 框架的第三方原生应用将无法执行生成任务。快捷指令应用里系统预装的 Use Model 动作也会当场返回错误。
这种技术链路的断裂直接波及到上层的用户级体验。备受关注的 Visual Intelligence 视觉识别功能，以及日历应用里的自然语言事件编辑特性，都会随着这 12GB 文件的抹除而一并失去作用。
引人注意的是，在 macOS 27 系统的内部架构中，Spotlight 搜索窗口的底层处理进程名就叫作 Siri。哪怕 AI 界面功能已经被切断，部分核心系统服务依然受到 SIP 框架的最高保护。它们在后台环境持续加载运行。Apple Intelligence 早就不是一个可以独立拔除的应用模块，它深度融合进了文件管理和系统基础架构之中。
图：RemoveMacAI 提供的详细功能状态输出视图。来源：RemoveMacAI 仓库（docs/status.png）
RemoveMacAI 核心逻辑的实现并非毫无技术沉淀。整个工具建立在另一位独立开发者 4evy 编写的 pared 项目基础之上。pared 团队最早通过逆向手段，摸清了 Unified Asset Framework 资产管理服务的工作逻辑。他们顺势定位了大模型文件集合分布以及系统相关设置键的隐秘运作机制。
争夺设备最终控制权
在代码工程的交互设计上，RemoveMacAI 提供了标准的工具链严谨度。其公开的单行安装脚本内置了校验和验证逻辑，在下载完成后自动核对发布包的二进制完整性。工具不但提供了 status 和 features 这种信息查看命令。它还为核心的 off 动作配备了 --keep、--dry-run 和 --yes 等细粒度控制参数。不带参数运行则会唤起交互式的向导流程。
项目提交历史中一次针对计数的代码修复，从侧面暴露了 macOS 机制的深不可测。作者提交了一次名为「Stop reporting freed space before macOS deletes the model files」的逻辑修正。在那次修改之前，该工具会抢在操作系统真正删掉硬盘文件前，提前向用户报告已经释放的存储空间。
macOS 内部的 UAF 资产服务在执行删除动作时是异步调用的。如果工具按常规的文件操作逻辑在发出指令后立刻统计磁盘占用，拿到的数据只会是未被真正清空的假象。系统底层服务 API 返回的状态与物理硬盘上文件真实状态发生脱节。这给所有外部介入工具设置了一道难以逾越的障碍。
在执行 removemacai revert 命令行指令后，可以完整撤销所有的配置写入和地址修改。系统后续能正常且干净地卸载这个第三方工具。这种无需妥协的可逆设计，是对封闭生态的直接回应。苹果把恢复更新的可逆性留在了系统本身的手里。开发者把物理删除的可逆性夺回到了终端用户端。当大模型成为系统的内置基建，设置面板里的那个功能开关，早已经不再是用户能够掌控的最高硬件权限。
参考链接：
- RemoveMacAI GitHub Repository
- 4evy pared GitHub Repository
