macOS语音助手开发：TCC权限避坑指南与提醒事项写入实践

1. 为什么语音助手会撞上 macOS 的隐私墙

1.1 需求来源：给"嘴上的助手"补齐写进系统的能力

我一直想做一个小工具：做饭的时候喊一声"十分钟后提醒我关火"，或者躺在床上说一句"明天早上九点提醒我带身份证"，然后系统真的把这件事记下来，到点再弹一条通知。市面上语音助手很多，但大部分只能帮你设个闹钟、查个天气，真正能写进 iCloud 提醒事项、并且能跨设备同步的，少之又少。于是我想自己动手做一个 macOS 上的语音助手智能体，把「语音识别 + 意图解析 + 提醒事项写入 + 倒计时」串起来。

想法很美好，真正开工之后才发现，最卡进度的不是语音识别模型，也不是意图解析逻辑，而是 macOS 的 TCC 权限体系。TCC 全称 Transparency, Consent, and Control，是 macOS 和 iOS 上负责隐私保护的一套机制。你的程序想访问提醒事项、日历、通讯录、照片，甚至是想用 AppleScript 去控制别的 App，都需要经过 TCC 这一关。它就像你家门口的保安，问你是谁、要进去干什么、有没有业主授权。

这篇文章不是教科书式的原理科普，而是我实际把「语音助手智能体」跑通、踩完坑之后的完整记录。适合正在做 macOS 工具类 App、想做本地语音助手的开发者，也适合对系统权限机制好奇、想搞懂"为什么明明给了权限还是不行"的朋友。我会把完整的授权链路、写入 iCloud 提醒事项的两种方案、倒计时稳定性设计、以及若干测试了很久才发现的问题都写清楚。

1.2 TCC 到底在保护什么：提醒事项权限和自动化权限不是一回事

很多第一次做 macOS 开发的人，都会在 TCC 上栽跟头，因为它的权限划分比想象中细得多。就拿这个项目来说，你至少会碰到两到三种完全不同的权限授权。

第一种是提醒事项访问权限。只要我们想往 Reminders.app 里写入数据，就必须请求NSRemindersUsageDescription对应的权限。注意，这个权限和日历权限是分开的，你就算已经授权了日历，也读不了提醒事项。系统里它们分别叫"日历"和"提醒事项"，在「系统设置 → 隐私与安全性」里是两个独立条目。

第二种是自动化权限，也叫 Apple Events 授权。当你用 AppleScript 或 JXA 脚本去 tell application "Reminders" 时，触发它的那个进程（比如终端、Xcode、或者你自己写的 App）会弹出一个"想要控制Reminders"的授权框。这个权限的语义是"某个 App 可以控制另一个 App"，而不是"某个 App 可以访问提醒数据"。

第三种是通知权限，用于倒计时结束后的本地通知推送。虽然它不是 TCC 管理下的"隐私数据"权限，但同样受系统管控，而且有个让很多新手困惑的点：通知权限和前面两种权限在设置里是分开的入口。

我最初天真地以为，只要在 Info.plist 里写上用法描述、程序启动时请求一下权限就能通吃。实际上，如果你的程序没有明确的入口去触发对应 API，系统根本不会弹出对应的授权框。而且拿到"提醒事项权限"并不等于你可以用 AppleScript 去写 Reminders，后者走的是完全独立的授权通道。这两个权限之间的关系，后面我会用实际案例展开讲。

1.3 目标产物长什么样：本地 Agent 的最小闭环

在写代码之前，我先把这个智能体的架构想清楚了。它的核心链路是这样的：麦克风录音 → 语音转文字 → 意图解析 → 动作执行 → 结果反馈。

在这个闭环里，动作执行部分最依赖 macOS 系统能力。我的 Agent 需要具备两个核心工具：

语音识别我用的是系统自带的 SFSpeechRecognizer，意图解析则采用"规则匹配 + 大模型兜底"的混合策略。这样做的原因后面专门讲。整体工程我用 Swift 写，因为 Swift 调用 EventKit 和 UserNotifications 最直接，不需要跨语言桥接。Xcode 新建项目、开启沙盒、添加 Info.plist 权限描述，这些是我最先做的事。

为什么强调"本地 Agent"？因为语音助手如果完全依赖云端，延迟、断网、隐私都是问题。而 macOS 的提醒事项、倒计时这类操作，天然就应该在本地完成。把智能体跑在本地，只有意图解析这种需要"聪明"判断的部分才走大模型，这样既有智能，又够快够稳。

2. TCC 权限申请的真实链路：从信息属性声明到系统弹窗

2.1 Info.plist 里必须提前写好的 usage 描述

在 macOS/iOS 开发里，访问受保护数据的第一步不是调用 API，而是先在 Info.plist 里声明用途。如果你的 App 没有写对应的 usage 描述，系统会在运行时直接让 App 崩溃或者拒绝调用，而不是弹窗询问用户。

做这个语音助手智能体，我至少要在 Info.plist 中加上：

<key>NSMicrophoneUsageDescription</key> <string>用于语音输入，识别你的指令</string> <key>NSSpeechRecognitionUsageDescription</key> <string>用于将语音转换为文字，理解你的需求</string> <key>NSRemindersUsageDescription</key> <string>用于向 iCloud 提醒事项写入你创建的待办</string> <key>NSAppleEventsUsageDescription</key> <string>用于通过 AppleScript 控制提醒事项等应用</string>

这里有个细节很多人不知道：NSAppleEventsUsageDescription并不是在 App Store 审核时强制要求的键，但如果你在沙盒环境下用 AppleScript 控制其他 App，没有这个描述，系统拒绝执行时你根本看不出原因，日志里只会有一句非常模糊的 "Not authorized to send Apple events"。加上之后虽然不能让你直接绕过授权弹窗，但至少行为更规范。

另一个容易忽略的坑是：这些 usage 描述虽然同名，但在 macOS 和 iOS 上的表现不一样。iOS 上只要声明了、请求了，弹窗一般都会出现；macOS 上如果用户之前拒绝过，系统不会主动再弹，你得引导用户去系统设置里手动打开。

2.2 让 App 获得"自动化"授权：Apple Events 的工作原理

Apple Events 是 macOS 上老牌的进程间通信机制。osascript执行的 AppleScript 脚本、NSAppleScriptAPI、以及 JXA（JavaScript for Automation），底层全部依赖它。

当你执行下面这行命令时：

osascript -e 'tell application "Reminders" to get name of every reminder'

系统会先检查「自动化」权限数据库里有没有记录：终端 App 是否有权限控制 Reminders.app。如果没有，系统弹出授权框；如果用户点了拒绝，那之后的每一次尝试都会被静默拦截。注意，这里的授权对象是"发起脚本的进程"。你得理解一个关键点——Apple Events 的 TCC 记录是"甲方→乙方"形式。如果你在终端里弹过一次授权框并允许了，那只代表终端可以控制 Reminders；如果你自己写的 App 内部也调了同样的 AppleScript，那它还需要再次弹窗、再次授权。

这也是为什么我在架构里做了一个取舍：优先用 EventKit API 写提醒事项，只有当 EventKit 不可用（某些非标准环境）时才退回 AppleScript。因为 EventKit 的权限模型更清晰，只有一个"提醒事项"授权，不会牵扯到甲方乙方这种复杂关系。

2.3 tccutil 重置权限：验证与调试的必备操作

开发过程中最痛苦的事不是代码报错，而是权限状态被"记住"了，想重新测试授权弹窗只能干瞪眼。这时候就要用到tccutil命令。

# 重置所有应用的提醒事项权限 tccutil reset Reminders # 重置某个指定 App 的提醒事项权限 tccutil reset Reminders com.yourcompany.YourApp # 重置自动化权限 tccutil reset AppleEvents

这是开发调试的必备操作。比如我想测试用户第一次打开 App 时的完整流程，就在每次打包重装后跑一遍tccutil reset Reminders com.xxx.xxx。要注意的是，tccutil reset需要当前用户有权限，而且有些系统级权限（比如"完全磁盘访问权限"）不能通过这个命令重置，只能手动去系统设置里关掉再打开。

还有一个调试技巧：查看当前 TCC 授权状态可以直接读 TCC 数据库。用户级数据库在：

~/Library/Application Support/com.apple.TCC/TCC.db

不过新系统上直接 sqlite3 查询可能没有权限，更简单的方法是去「系统设置 → 隐私与安全性」里对着看。这就是我建议的第一个自检顺序：代码请求权限前，先看看系统设置里有没有出现你的 App，没有就说明请求代码压根没正确触发。

3. 写 iCloud 提醒事项：两条技术路线的选择与实测

3.1 AppleScript 直连 Reminders 的利与弊

先说 AppleScript 方案。它的核心思路很简单：让系统自带的事件脚本，替你把提醒事项写进 Reminders.app。

tell application "Reminders" set newReminder to make new reminder at end of reminders set name of newReminder to "明天早上九点带身份证" set due date of newReminder to date "2025年7月1日 09:00:00" end tell

这套方案的好处非常明显：不需要引入 EventKit 框架，不需要自己处理 iCloud 同步，Reminders.app 会替你完成一切，而且还能利用 Reminders 本身的"到期时间"提醒逻辑。脚本代码也简单，几乎所有用 AppleScript 写过 Reminders 的人都熟悉这种写法。

但它的缺点同样突出。第一，自动化授权链路太复杂。你的 App 请求控制 Reminders 时，弹窗问的是"某某 App 想要控制 Reminders"，普通用户根本分不清这和提醒事项权限有什么区别；第二，AppleScript 运行速度偏慢，每条指令都有进程间通信开销，语音助手要求低延迟，每多一秒都影响体验；第三，AppleScript 的字符串处理对新文本格式支持不够好，当提醒事项内容包含特殊符号或 emoji 时，偶尔会出现编码问题。

所以我的结论是：AppleScript 适合快速验证原型，不适合作为正式 App 的核心路径。如果你只是自己在终端里写写脚本，那无所谓；但如果你要把智能体做成一个独立产品，我更推荐 EventKit。

3.2 用 EventKit 在 Swift 侧拉起 EKReminder

EventKit 是苹果官方提供的事件工具框架，直接对接日历和提醒事项数据库。在 Swift 里创建一条提醒事项的代码并不复杂：

import EventKit let store = EKEventStore() store.requestAccess(to: .reminder) { granted, error in guard granted else { return } let reminder = EKReminder(eventStore: store) reminder.title = "明天早上九点带身份证" reminder.calendar = store.defaultCalendarForNewReminders() var components = DateComponents() components.year = 2025 components.month = 7 components.day = 1 components.hour = 9 components.minute = 0 reminder.dueDateComponents = components do { try store.save(reminder, commit: true) } catch { // 处理保存失败 } }

和 AppleScript 相比，EventKit 是官方推荐的编程接口，类型安全、性能好，而且权限模型清晰：只要用户授权"提醒事项"，你就可以在这个 App 内直接写。不需要关心甲方乙方那套，也不用跟 AppleScript 解释"你这个字符串里有一个笑脸符号"。

用 EventKit 还有一个隐藏好处：你可以读取当前的提醒事项列表，做去重和冲突检测。比如用户说"提醒我买牛奶"，而当前列表里已经有一条几乎一样的提醒，你可以问一句"你已经有一个类似的提醒了，要我替换吗？"这种智能体才有的交互，用 AppleScript 几乎是做不到的。

3.3 实测中最重要的对象生命周期问题

写 EventKit 代码最大的坑，不是 API 不会调用，而是EKEventStore 对象的生命周期管理。

我记得第一次测试时，写入请求偶尔成功、偶尔失败，失败的错误信息是 "The operation couldn’t be completed. (EKErrorDomain error 0.)"，非常让人摸不着头脑。后来排查了很久才发现，是因为我把EKEventStore写成了局部变量，函数返回后它就被释放了，异步回调里再拿这个 store 去 save reminder 就报错。

正确做法是把store作为属性持有，或者至少在保存完成之前保持强引用：

final class RemindersTool { private let store = EKEventStore() func saveReminder(title: String, dueDate: Date) async throws { let granted = try await store.requestAccess(to: .reminder) guard granted else { throw AgentError.reminderAccessDenied } let reminder = EKReminder(eventStore: store) reminder.title = title reminder.calendar = store.defaultCalendarForNewReminders() reminder.dueDateComponents = Calendar.current.dateComponents( [.year, .month, .day, .hour, .minute], from: dueDate ) try store.save(reminder, commit: true) } }

另外还有一个必须注意的点：写入最好放到主线程或串行队列，避免多个语音指令并发写入时出现数据竞争。智能体可能同时收到"加个提醒"和"设个倒计时"两条指令，如果共用一个EKEventStore，一定要做好并发控制。

4. 分钟级倒计时：在后台不被杀掉的通知方案

4.1 为什么本地通知比后台 Timer 更可靠

倒计时的需求看起来简单：设定时长，到点提醒。但 macOS 上如果直接用一个 Timer 变量在后台倒计时，会遇到一个很现实的问题：App 可能被系统挂起，甚至被用户手动退出。

我一开始真的试过用一个Timer.scheduledTimer循环，测试时发现屏幕亮着没问题，但只要 App 进入后台，Timer 就不会准时触发。这其实不是你的代码写得不对，而是 macOS 的资源管理策略——它不会让一个普通 App 在后台无限期占用 CPU。

那解决方案是什么？用本地通知（Local Notification）。你把"几分钟后触发"这个请求提交给系统，由系统在指定的时间弹出通知横幅。就算你的 App 进程已经死了，通知也能照常发送。这本质上是一种"外包"策略：把倒计时的发起权的执行权交给系统，而不是自己死扛。

import UserNotifications let center = UNUserNotificationCenter.current() center.requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in // 用户允许后，才能添加通知 } let content = UNMutableNotificationContent() content.title = "倒计时结束" content.body = "关火！厨房里还煮着东西" content.sound = .default let trigger = UNTimeIntervalNotificationTrigger( timeInterval: 600, repeats: false ) let request = UNNotificationRequest( identifier: UUID().uuidString, content: content, trigger: trigger ) center.add(request) { error in // 添加成功回调 }

这里最需要注意的坑是：本地通知的最小时间间隔不是你想多小就多小。虽然 UNTimeIntervalNotificationTrigger 理论上支持任意大于 0 的区间，但如果 timeInterval 小于 60 秒，系统在某些 macOS 版本上会有奇怪的容忍度问题。所以如果你说"20秒后提醒我"，建议用 Timer + 本地通知兜底，或者直接依赖 UI 内提示。

4.2 UNUserNotificationCenter 的授权与触发逻辑

本地通知的授权是一个单独的用户提示，第一次调用requestAuthorization时系统会弹窗。如果你的 App 在启动时已经请求了提醒事项和麦克风权限，再弹第三个通知权限，用户很可能不耐烦。

所以我选择在用户第一次下达倒计时指令时才请求通知权限，而不是启动时就请求。这样请求的上下文非常明确，用户刚说完"十分钟后提醒我关火"，紧接着系统问"是否允许发送通知"，人人都能理解为什么要这个权限，授权率会高很多。

另外，通知权限在 macOS 上还有"临时授权"的概念：用户可以选择"允许发送临时通知"，这种通知不会打扰人，只会在通知中心里显示。对倒计时这种强提醒场景，临时授权不够用，但如果你想做"每日语录""喝水提醒"这类弱提醒，可以试一下：

let options: UNAuthorizationOptions = [.alert, .sound, .provisional] center.requestAuthorization(options: options) { granted, error in }

实际效果上，临时授权的通知不会弹横幅，只是静静地出现在通知中心。倒计时场景必须弹横幅、响声音，所以我最终还是只用正式授权。有一点要提的是，你在开发环境点击通知横幅，App 可能会收到回调，但如果你要跳转到特定页面，还需要在 AppDelegate 里实现通知响应方法。这个逻辑一般跟深链绑定，如果你的智能体只是纯提醒，不跳转也没关系。

4.3 多意图连续指令下的状态机设计

语音助手不止处理单条指令。用户可能一口气说三句："帮我设个十分钟的倒计时，等等，改成五分钟，然后提醒我晚上八点开会。"

这种连续指令对智能体架构提出了一个要求：你的状态管理不能只靠函数调用，需要有一个意图合并和覆盖机制。

我实现了一套非常简单的状态机，核心思路是维护一个"当前活跃意图"数组：

• 新增倒计时：创建新 timer 条目，分配新 identifier
• 修改倒计时：找到最近一条 timer 条目，取消对应通知，创建新通知
• 取消倒计时：删除所有 active 条目并取消通知

struct TimerState: Codable { var identifier: String var title: String var fireDate: Date var isActive: Bool } final class TimerCoordinator { private(set) var activeTimers: [TimerState] = [] func addTimer(title: String, seconds: TimeInterval) { let id = UUID().uuidString let fireDate = Date().addingTimeInterval(seconds) let state = TimerState(identifier: id, title: title, fireDate: fireDate, isActive: true) activeTimers.append(state) scheduleNotification(id: id, title: title, fireDate: fireDate) } func modifyMostRecentTimer(newSeconds: TimeInterval) { guard let last = activeTimers.last, last.isActive else { return } cancelNotification(identifier: last.identifier) activeTimers.removeLast() addTimer(title: last.title, seconds: newSeconds) } }

这里要特别强调持久化。你在开发时可能不会意识到，用户设了一个 50 分钟的倒计时，可能中途重启了电脑或者强制退出了 App。如果只把 timer 存在内存里，重启之后就全丢了。所以每次新增、修改、取消状态机，都应该同步把最新状态写入UserDefaults或本地 JSON 文件，App 启动时再恢复。本地通知本身是系统管理的，重启后通知仍然会触发，但你的界面要显示"还剩多少分钟"，就必须依赖持久化状态。

5. 语音识别与意图解析的本地化组合

5.1 语音转文字选型：系统 SFSpeechRecognizer 还是本地 Whisper

语音助手的入口是语音转文字。macOS 上主流的方案有两类：苹果原生SFSpeechRecognizer和本地 Whisper 模型。

SFSpeechRecognizer的优点是与系统深度集成，因为它是通过系统语音识别服务转写的，很多时候会利用苹果的云端节点提升准确率。但它的缺点也是明显的：你必须先获得NSSpeechRecognitionUsageDescription和麦克风权限，而且网络状态差的时候识别速度明显变慢。我实测下来，上下文稍长、口音稍微特殊的句子，系统 SR 的成功率只能算"能用"，距离"好用"还有距离。

本地 Whisper 的优势则是完全离线、识别质量好，尤其是搭载 Apple Silicon 的 Mac 上跑量化版本速度还不错。但缺点是需要下载模型、初次启动慢，而且如果你用 SwiftUI 写 App，还需要处理 Python/Core ML 的桥接，工程复杂度会上一个台阶。

我的选型思路是：优先用 SFSpeechRecognizer 负责启动阶段的唤醒词和短指令，因为系统 API 够快；如果是长句或者复杂指令，再把音频数据丢给本地 Whisper 模型做二次转写。这个"长短结合"的策略在实测中体验最好，不会因为模型加载导致语音响应卡顿。

实际实现时，SFSpeechRecognizer 的用法非常直接：

import Speech let recognizer = SFSpeechRecognizer(locale: Locale(identifier: "zh-CN")) let request = SFSpeechAudioBufferRecognitionRequest() request.shouldReportPartialResults = true recognitionTask = recognizer?.recognitionTask(with: request) { result, error in if let result = result { let text = result.bestTranscription.formattedString // 实时更新界面，判断是否完整指令 } }

注意shouldReportPartialResults放在 true，这样用户可以边说边看到文字，避免说完之后还要等很久才出结果。

5.2 意图解析采用"规则 + 大模型兜底"的混合策略

转出文字之后，智能体需要理解用户想干什么。这一步如果用纯大模型，效果很好但延迟不稳定；如果纯用规则，遇到多样表达就废了。我最后采用的策略是：先用规则匹配处理高频、格式化指令，遇到无法归类的表达式再交由大模型解析。

高频规则覆盖了下面这类指令：

规则匹配我用的是一组正则表达式 + 时间解析器。正则负责提取"X分钟后""X小时后""明天早上X点"这些结构和数量词；时间解析器负责把中文日期表达换算成绝对时间。

func parseDuration(from text: String) -> TimeInterval? { let pattern = #"(\d+)\s*(分钟|秒|小时)"# guard let match = text.range(of: pattern, options: .regularExpression) else { return nil } // 提取数字和单位，换算成秒 } func parseDueDate(from text: String) -> Date? { // 处理"明天上午九点""今晚八点"等表达 }

这套规则的好处是：所有解析都在本地毫秒级完成，配合语音输入可以做到几乎无感的交互体验。至于大模型兜底，我接入的是本地可调用的 LLM API，设定了一个很小的 system prompt：输出必须是 JSON，包含intent_type、title、time等字段。大模型解决的是"今天下午开完会之后提醒我给客户回电话"这种需要推理的复杂表达。

5.3 打断、修正与模糊表达的处理

语音交互最大的特性是"说错、改口、打断"很常见。上一秒说"设一个十分钟倒计时"，下一秒又说"不不不，改成二十分钟"。如果你的智能体只会机械地解析每一条指令，那结果就是创建了两条提醒项。

针对这种场景，我做了一个"修正检测"模块，核心逻辑很简单：

• 如果用户在新指令的开头说出"不""等等""改为""算了""不是"，则将上一条活跃指令标记为"待覆盖"
• 如果用户没有明确否定词，但两句话间隔小于 5 秒且内容高度相似，也视为一次修正
• 弹窗确认"你确定要把原来的十分钟倒计时改成二十分钟吗？"，确认后执行覆盖

这个模块不用太聪明，覆盖几类高频场景就行。实际体验中，它对"用户觉得自己说错了想重来"的容忍度提升很大，至少比直接重复执行好得多。另一个模糊表达是语音转文字结果里常有同音字和语气词，比如"提醒我买伞"转成了"提醒我买三"。这种情况我建议在意图解析后加一层"实体清洗"，把常见误转词映射回正确词，数据表要自己积累，没有捷径。

6. 从踩坑到稳定：一组真实案例与避雷清单

6.1 案例一：只给了"提醒事项"权限，AppleScript 照样失败

这是我踩得最莫名其妙的一个坑。当时我的智能体已经获得了提醒事项权限，界面里能看到"提醒事项：已授权"。但当我调用 AppleScript 写入时，却收到了osascript 执行失败，错误 -1743。查了很久才发现，-1743就是"没有自动化权限"的典型错误。

原因说起来很简单：EventKit 的提醒事项权限，和 AppleScript 控制 Reminders.app 的自动化权限，是两个完全独立的 TCC 分类。只授权前者，后者必然拦截。解决方案两种：一是放弃 AppleScript，全部改用 EventKit；二是在代码里显式触发 Apple Events 授权请求，引导用户去系统设置里授权。

我最终选了前者，把全部写入逻辑迁到 EventKit，这才彻底摆脱了那个依赖链。如果你的项目确实离不开 AppleScript，记住排查思路：先看 Reminders 权限，再看 Apple Events 权限，两个都要有。

6.2 案例二：App 重装后所有权限清空

开发语音助手的阶段，我频繁重装 App、改签名、升级版本。有一次测试时发现，之前明明已经授权的权限全部失效了，系统设置里也找不到这个 App。一开始以为是代码 bug，排查老半天才发现，原来 TCC 权限记录与 App 的 bundle identifier 和代码签名绑定。

只要你的 App 签名变了、重新安装或者跑的是 Xcode 的 Debug/Release 不同配置，TCC 就认定这是"一个新的 App"，之前的授权记录全部作废。这个机制是为了防止恶意 App 通过重装来重置授权状态，但对开发者来说确实不太友好。解决办法也很朴素：不要频繁重签，发布测试时用 TestFlight 或其他稳定的分发渠道；如果你是开发环境调试，直接用tccutil reset建立稳定基线。

6.3 案例三：TCC 弹窗不出现时的检查顺序

权限弹窗是最容易出问题的环节之一。有时候你会发现，代码明明调用了requestAccess，但系统毫无反应，没有弹窗也没有报错。这时候不要慌，按下面的顺序查：

1. Info.plist 有没有写对键名。NSRemindersUsageDescription写错一个字母或者大小写不对，系统直接不弹窗
2. 权限是不是之前已经在系统设置里被拒了。macOS 对被拒绝的权限很保守，不会再主动弹第二次
3. 你的 App 是不是正在被调试。Xcode 的调试会话有时候会干扰 TCC 弹窗，断点触发时弹窗没出现，代码又往下跑了，授权请求就卡死了
4. 是否用了tccutil reset。开发环境下最好先重置对应权限再测试

照着这个顺序做，我基本能在三分钟内定位弹窗问题。另外提醒一句，requestAccess的回调可能在任意线程，UI 更新记得回主线程。

6.4 几个值得提前做好的工程决策

最后分享几个我在工程上踩过几次之后才想通的决策，对后续稳定运行帮助很大。

第一个是所有系统权限请求尽量集中管理。新建一个PermissionManager，统一负责请求、查询状态、跳转系统设置，不要在每个工具模块里各自 request。这样无论是排查问题还是向用户展示授权状态，都会轻松很多。

第二个是给 Agent 增加"权限缺失"时的优雅降级。如果用户拒绝了提醒事项权限，语音助手不应该直接报错，而是可以退化成"用嘴读出这条提醒，同时在界面上展示一个可复制文本"。这个降级方案让 App 在一部分权限没开的情况下依然可用，体验会提升一个档次。

第三个是给倒计时和提醒事项区分两种通知声音。倒计时结束用急促的提示音，提醒事项到期用温和的提示音。用户不用看屏幕，光听声音就知道是"时间要到了"还是"有件事该做了"。这个细节很多人忽略，但实际体验差距非常大。

第四个是构建单元测试时屏蔽 TCC 干扰。测试 TCC 相关逻辑容易受到系统弹窗阻塞，所以我用协议封装了EKEventStore和UNUserNotificationCenter，测试时注入 mock。一开始多花点时间，后面每次回归测试都会省钱。

把上面这些点全部处理好之后，这个语音助手智能体才算真正可以稳定用了。我现在的日常是：做饭、运动、看书的时候自然地喊一句话，剩下的交给它。macOS TCC 这面墙并没有消失，只是我在墙上装了扇门。