AirBeep 实战指南：静音 iPhone 通话录音提示音的原理、安装与恢复

iOS 的通话录音开启时，系统会先播放一段提示音并提醒对方「这通电话正在录音」。这是刻意的合规设计。但在一些场景里——比如对方已经明确知情同意、你只是不想让机械提示音打断对话开头，或者录的是自己参与的会议备忘——这段提示音本身成了干扰。

AirBeep 做的事很单一：把开始和结束时的录音提示音替换成等长静音。一个开关打开是静音，再拨一次就从备份恢复原样。这个开源小工具 2026 年 10 月 7 日才建仓，三天更新到 v2.4.0，已经有 340 多个 Star。

先把三个硬前提说在前面，缺一个都不用往下看：

• 版本对得上：只支持 iOS/iPadOS 27.0–27.2 B2，正式版和其他版本不在支持范围内；
• 是实体设备：模拟器不行，必须是真 iPhone / iPad，且能侧载安装；
• 合规过关：录音的告知与同意要求以你所在地的法律为准（见下文「合规与风险」一节），这是使用前提，不是免责套话。

本文根据 AirBeep 官方仓库的 README（中英文）与发布信息整理，核对日期 2026-10-10。项目迭代非常快，功能与支持范围以仓库最新文档为准。

先说结论：功能很利落，窗口很窄

• 作用单一且明确：只替换通话录音的开始、结束两个提示音，不碰录音功能本身。
• 最大的限制不是功能，是系统版本：支持范围只有 iOS/iPadOS 27.0–27.2 B2 这一段测试版。别为了这个工具把主力机刷进测试版——测试版系统的稳定性成本，远大于一段提示音。
• 安全设计比预期扎实：首次修改前自动备份、备份永不覆盖、每次写入后回读校验、一键从备份恢复。敢动系统文件的工具，恢复路径比功能本身更重要，这一点它做对了。
• 真正的门槛在合规：去掉提示音，意味着对方可能收不到「正在录音」的系统提示。你是否还需要以其他方式告知并获得同意，取决于所在地法律，工具替你解决不了。

它到底改了什么：两个系统音频文件

AirBeep 的原理没有玄学。它请求对以下两个系统文件的容器级访问，把它们替换为等长的静音文件：

几个设计细节值得单独说：

为什么强调「等长」。 替换文件与原始时长保持一致，系统在播放节奏和校验上不会因为时长突变出现异常。这也是它和「粗暴删文件」的区别——删掉或改短，都可能让通话服务在调用时报错或行为不一致。

备份在哪、会不会丢。 首次修改之前，原始文件会自动备份到应用 Documents 目录下的 AirBeepBackups。按 README 的说法，这份备份会被保留且绝不会被覆盖，恢复时一键还原。换句话说，只要你不手工删掉这个备份目录，开关拨回去就是原样。

写入后回读校验。 每次写入完成后，工具会重新读取文件做校验，确认替换真的生效，而不是「以为写进去了」。

技术来源。 静音音频资源与替换方案来自 AirliftSilence；底层研究还包括 airlift 项目的 AirTraffic 与 Airlock（作为依赖保留），以及 Placard 提供的原始 iOS 项目结构与容器访问实现。AirBeep 本身更像站在这些研究之上的「成品化封装」：把多步操作收成一个开关。

支持范围：先对版本，再谈安装

这里要特别解释「27.0–27.2 B2」：B2 指 Beta 2，即 iOS 27 测试周期的早期版本窗口。这类工具依赖的是非公开的系统行为，README 自己也写明：不同 iOS 版本之间兼容性可能发生变化。苹果在后续 Beta 或正式版中调整相关行为，是完全正常的预期——今天能用的窗口，不保证下个版本还在。

所以判断顺序应该是：先拿起手机看自己的系统版本是否正好落在支持范围内，再考虑安装；在范围外，就等作者后续适配，不要拿主力机硬试。

安装路径：本地构建与 unsigned IPA 二选一

路径 A：Xcode 本地构建

适合本来就有开发环境的人：

1. 克隆仓库，用 Xcode 27 打开 airbeep.xcodeproj
2. 选择 airbeep target
3. 设置你自己的签名团队（Signing Team）
4. 连接实体设备，构建并安装到设备

路径 B：unsigned IPA（Releases 现成包或 GitHub Actions 云端构建）

没有本地环境也不用现搭：仓库 Releases 直接提供 airbeep-v<version>-unsigned.ipa（当前 v2.4.0）；也可以在自己的 fork 里运行仓库自带的 Release unsigned IPA 工作流，云端构建出同样的包。

注意 unsigned 的含义：这个包没有有效签名，不能直接装进 iPhone。你需要用自己的 Apple ID / 开发者证书完成签名，再通过 AltStore、SideStore、Xcode 等常规侧载方式安装。签名与侧载的具体步骤取决于你用的工具，按对应工具的文档走即可；只从仓库官方 Releases 下载 IPA，不要用任何第三方转载的包——一个能改系统文件的工具，来源必须干净。

装好之后的使用动作只有一个：打开 AirBeep，拨动开关即静音；想还原时再拨一次，它会从 AirBeepBackups 的自动备份恢复原始提示音。

恢复与兜底：动手前先确认退路

这类工具的正确打开方式，是先确认怎么恢复，再谈怎么改：

• 应用内恢复是第一选择：再拨一次开关，从首次修改前的自动备份还原，前提是别删 AirBeepBackups 目录；
• 备份永不覆盖意味着多次开关不会把你的原始文件冲掉，这一点在同类工具里并不默认；
• 动手前再做一次整机备份是通用原则：改的是系统目录下的文件，任何工具都不能替你保证测试版系统上的全部行为；
• 系统更新是双刃剑：升级 iOS 可能让工具失效（支持窗口很窄），也不要为了保住这个功能而长期停留在早期测试版——安全更新比一段静音重要。

合规与风险：这一节比安装更重要

提示音存在的目的，就是让通话对方知道自己正在被录音。AirBeep 的 README 把这句话写得很直白：移除录音提示音，可能影响对方是否收到「通话正在被录音」的通知；请在当地法律允许并取得必要同意的情况下使用。

展开说三层：

第一，录音同意的规则各地不同。 有的法域是单方同意（通话一方同意即可），有的是双方同意；有的还对录音的保存、使用和作为证据有额外要求。本文不提供法律结论，你需要按自己所在地和通话对象所在地的规则确认。

第二，去掉系统提示，不等于告知义务消失。 就算在单方同意的法域，礼貌和职业场景的基本要求也是先说一句「这通电话我会录音」。静音提示音解决的是「提示音打断对话」的问题，不是「如何不让对方知道」的问题——把这工具用成后者，风险自担。

第三，非公开行为的技术风险。 它依赖特定测试版系统的非公开行为，兼容性随时可能变化；系统文件级的修改在最坏情况下需要靠恢复备份或重装系统兜底。只在你愿意承担折腾成本的设备上用，别在唯一的生产力主力机上首发尝试。

FAQ

正式版 iOS 能用吗？

按 README 的支持范围，只有 iOS/iPadOS 27.0–27.2 B2。正式版和其他版本未声明支持，不要硬试，等作者更新适配说明。

需要越狱吗？

README 未提越狱，走的是侧载安装加容器级文件访问的路径。但它是系统文件级工具，不是 App Store 应用的操作方式，安装门槛（签名、侧载、版本窗口）本身就会筛掉大部分人。

关掉提示音之后，录音功能本身受影响吗？

不受影响。它只替换开始与结束的两个提示音文件，录音照常进行。需要注意的恰恰是对方端：对方可能因此收不到系统发出的录音提示，告知与同意请自行落实。

恢复原样麻烦吗？

不麻烦。再拨一次开关即可从自动备份恢复；备份保存在应用 Documents 的 AirBeepBackups，且不会被后续操作覆盖。前提是你别手动删掉它。

Android 有类似的吗？

这个项目只有 iOS 版。Android 各厂商的通话录音提示机制完全不同，不能套用这套方案。

最后：三个前提齐了，它就是个利落的小工具

回头看 AirBeep 值得介绍的原因：需求极小，但做得完整——一个开关、改前备份、写后校验、随时恢复，致谢里把技术来源也交代得清清楚楚。三天 340 多个 Star，说明被录音提示音打断的人确实不少。

但它成立的前提有三个：版本对（正好在 27.0–27.2 B2 窗口）、设备对（愿意折腾侧载的实体机）、合规对（录音告知与同意已经落实）。三个都齐，它是顺手的好工具；缺了最后一个，技术再利落也不要用。