技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

RemoveMacAI:把 macOS 的"减法"做成可回滚的事务

项目背景与痛点

从 Sequoia 开始,Apple Intelligence、分析遥测、Siri 建议、Spotlight 的云端补全、以及系统级广告位,都以"默认开启"的姿态铺进 macOS。问题在于,苹果给用户的开关从来不是完整的:设置面板里露出的只有一小部分,剩下的大部分散落在 NSUserDefaults 的私有域、LaunchAgent 的 KeepAlive 配置、launchd 的 disabled 覆盖数据库,甚至 TCC 权限库里。想彻底关干净,你得自己摸这些地方。

社区里不缺 debloat 脚本,但它们有一个共同的原罪:只做减法,不负责归还。一个 defaults write 之后,没人记得原始值是什么;一条 launchctl disable 之后,出问题也没法精确复原,只能靠 Time Machine 或者重装。RemoveMacAI 的定位正是把这件事工程化——原生 App 加 CLI 双入口共用一套内核,而每一个改动都带快照、都可撤销。在一个需要动系统深层配置的工具上,"可逆"不是锦上添花,而是安全底线。

核心技术揭秘

从仓库形态推断,它大概率是一个 Swift Package 拆出的多 target 结构:Core 承载规则与执行逻辑,App 用 SwiftUI 包一层界面,CLI 用 swift-argument-parser 做子命令。规则本身是声明式的(YAML/JSON 或 Swift 里的结构化常量),而不是把每条命令硬编码进 if-else——这决定了它能不能跟上 macOS 每年一次的版本演进。

真正的技术含量在于"读—比对—计划—执行—回读—提交"的闭环,而不是执行本身。因为 macOS 的系统状态极难可靠读取:defaults read 返回的值未必是当前生效值;LaunchAgent 的禁用状态实际落在 /var/db/com.apple.xpc.launchd/ 下的覆盖数据库里;TCC 是一张 SQLite 表,改它需要完整磁盘访问权限;而 Apple Intelligence 相关的偏好又分散在多个域,还可能被 MDM 描述文件覆盖。任何"盲写"都会导致幂等性崩掉——第二次运行时状态判定错误,回滚数据也会被污染。

另一条硬约束是 SIP。/System 只读,所以所有变更只能落在 ~/Library、/Library、用户 defaults 域、launchd 覆盖库和 TCC 数据库这些"可写但敏感"的位置。这也解释了它为什么不需要内核扩展、不碰系统二进制——代价是覆盖面天然受限,且高度依赖未文档化的系统行为。

graph TD A[CLI 入口(子命令)] --> C[声明式规则目录 Catalog] B[SwiftUI 原生 App] --> C C --> D{"比对期望状态与当前状态"} D -->|"已一致"| E[跳过,保持幂等] D -->|"存在差异"| F[生成操作计划 Plan] F --> G[写入前快照 Snapshot] G --> H[执行层<br/>defaults / launchctl / TCC] H -->|"执行失败"| I[按快照回滚] H -->|"执行成功"| J[回读校验] J -->|"校验不一致"| I J -->|"校验一致"| K[提交事务日志 Journal] K --> L[按条目粒度一键还原]

快照层是整个设计的支点:写前抓取原始 plist / 数据库行,写后回读确认,只有校验通过才提交事务日志。失败即回滚,未提交的变更不进历史——这就是数据库事务的思路被搬到了系统配置上。

功能亮点与差异

  • 全链路可逆:多数同类工具的回滚是"再跑一遍反向脚本",本质是重写而非还原。它存的是真实快照,因此能恢复到你机器上的具体原始值,而不是作者假设的默认值。
  • 双形态、单内核:App 面向普通用户,CLI 面向脚本化与批量装机,两者共享规则与事务逻辑,避免"图形界面关了、命令行没关"的状态分裂。
  • 规则与执行解耦:新增一个开关只是往 Catalog 加一条声明,不必改执行引擎——这是它敢于跟进新系统版本的结构性原因。
  • 不做侵入式改造:无 kext、不改系统签名、不绕 SIP,可维护性和可审计性都更好。

应用场景与落地建议

最适合两类场景:个人开发机的一次性"净化",以及团队在发机前做基线固化(CLI 接入装机脚本)。落地时注意几点:先 dry-run,看清计划再执行;执行前确认快照已落盘;分批推进而非一次全关,否则出问题难以定位是哪条规则导致;macOS 大版本升级后必须回归验证,规则很可能失效或指向已废弃的域。

更重要的是权限代价——它能改 TCC 和 launchd,就意味着它需要完整磁盘访问甚至提权,这在企业环境里大概率会触发 EDR 告警,也可能与 MDM 下发的策略冲突(MDM 强制项会覆盖本地写入,表现为"关了又回来")。因此它更适合个人设备与受控的开发机,而不适合合规审计严格的生产终端。

综合评价

优点:把"去臃肿"从一堆一次性脚本提升为有事务语义的工具,可逆性做到了少见的水准;架构分层干净,规则声明化让长期维护成为可能;App + CLI 的双入口设计务实。

短板:命脉系于未文档化的系统内部行为,版本脆弱性无法根除;高权限本身就是攻击面,一个能改 TCC 的工具被滥用或出错时后果不轻;规则库的正确性依赖人工验证,社区规模尚小,测试覆盖和长期维护都是问号。

一句话总结:它是目前思路最"正"的 macOS 减负工具——不在于关得多狠,而在于它敢承诺每一下都能收回来。

关于

GitHub 原始描述(英文)

Turn off Apple Intelligence and delete its models on your Mac. Optional tweaks for analytics, ads and pop-ups. A native app and CLI, and every change can be undone.

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
6384
价值分
3658
活跃状态
活跃

语言占比

Objective-C
Python
Shell
Swift

Release