最近我刷到 Nomily 这个开源项目时第一反应是“这不就是我一直想要的东西吗”。它把 Apple Watch 的录音能力和 AI 总结捏在了一条链路上而且用了 BYOKBring Your Own Key模式你带上自己的大模型 API Key录音音频在本机完成转写与提炼不依赖任何第三方订阅平台。整条链路打通之后我的使用习惯被彻底改掉了——现在开会、通勤、遛狗时想到什么抬一下手腕说几句过几分钟手机上就会多一条结构化笔记而不是躺在录音列表里再也不会打开的回放文件。这篇文章我会把这个项目的设计思路完整拆开从 wearable 端的录音实现到传输机制、转写选型、提示词工程再到部署和排坑讲清楚每个环节为什么这么设计、有什么可替换方案、实操时要注意什么。适合三类人Apple Watch 用户想搭一套高定制度 AI 录音流watchOS/开源开发者想学习完整链路设计以及单纯对“随身 AI Agent”工作流感兴趣的人。1. 项目拆解Apple Watch 到 AI 总结的完整链路1.1 这个项目解决的核心痛点先聊痛点。手机录音功能其实已经非常成熟但“打开录音 App → 解锁屏幕 → 找到录制按钮 → 点击 → 开始讲话 → 之后再打开回放整理重点”这个流程里每一步都在消耗耐心。真正常用录音的人是少数不是因为不想记而是入口太重。Apple Watch 的出现本来是想解决“抬手即得”的问题但系统自带的录音机只能录不能转写更不能总结第三方 App 不是订阅制就是闭源数据还得经过别人的服务器。Nomily 解决的正是这个断层把“采集”放到最自然的入口手腕把“理解”交给最合适的新工具大模型中间通过苹果自家的 WatchConnectivity 传输整体形成一条从“随口说”到“结构化总结”的完整闭环。它不是一个花哨功能堆砌的 App而是把每一环都做干净再用开源方式把选择权交给使用者。1.2 完整数据链路与各环节职责把整个链路拆开来看一共是五六个接力环节每个环节都有独立的职责和技术选型录音采集Apple Watch 通过系统录音能力捕获麦克风输入生成 m4a/aac 编码的音频文件。本地暂存watchOS 端 App 沙盒内保存录音文件同时记录时间戳、时长、触发来源等元数据。跨设备传输通过 WatchConnectivity 框架把录音文件从 Apple Watch 可靠地传给已配对的 iPhone。语音转写iPhone 端调用 ASR 引擎云端或本地把音频转成带标点的文本。模型总结把转写文本送入 LLM用你的 BYOK Key生成结构化总结、待办提取、要点归纳。结果落盘保存 Markdown 格式的总结文本并保留原始音频与转写文本作为可回溯资料。这个链路里最容易翻车的地方是第 3 步和第 4 步的衔接watchOS 的文件传输不像消息发送那么快转写引擎又有自己的格式和上下文要求。项目在这两环都做了不少工程化处理后面我会单独展开。1.3 为什么是 BYOK 模式BYOK 是整项目里我最认可的设计决策。传统做法是开发者自己接入大模型、封装成付费订阅用户的录音要经过平台服务器再转回数据流动链路长、隐私风险高、价格还贵。BYOK 直接把“模型能力”和“应用逻辑”解耦应用只负责采集、调度、展示模型能力由用户自己的 API Key 直连厂商接口提供。带来的好处非常实际。第一没有订阅费用按量付费用得少花得少每天几条录音一个月下来可能就几杯奶茶钱比年费订阅划算不少。第二数据路径短音频和文本直接从 iPhone 发到模型服务商不经过任何第三方中转服务器隐私边界清晰可解释。第三模型可替换只要兼容 OpenAI 接口你可以随时把默认模型换成更便宜或者更懂特定领域的模型这是闭源产品给不了的自由。当然代价也明显使用者得自己申请 API Key、管理配额需要一点动手门槛这个项目本来就是给愿意折腾的人准备的。2. Apple Watch 端录音能力与传输机制2.1 watchOS 录音的工程基础在手腕上做录音第一件事是理解 watchOS 的音频能力边界。我最早以为只需要把 iPhone 那套 AVAudioRecorder 代码搬过去就行实际跑起来发现差别很大。核心实现通常是用 AVFoundation 的 AVAudioRecorder 或更底层的 AudioQueue配置一个 AVAudioSession 处理录音会话。这里有几个必选项在 Info.plist 里声明 NSMicrophoneUsageDescription否则首次录音会直接崩溃或静默失败。配置音频会话类别为 playAndRecord默认端口选听筒或扬声器避免录音音量低不可闻。录音格式建议用 AAC-LC 编码的 .m4a兼容性最好也利于后续传输和转写。watchOS 端的硬件和系统策略比 iPhone 激进得多屏幕会频繁休眠App 不进后台太久就会被挂起音频会话也可能被其他声音打断。我第一次真机测试时录到一半屏幕熄灭再点亮发现录音已经停了——这就是没有处理好 session 激活时机导致的。可行的做法是录音开始时用 beginReceivingRemoteControlEvents 这类接口保持会话活跃同时把录音状态写入 UserDefaultsApp 重新激活时可以自动恢复或提示用户。参数选择上对语音识别来说 16kHz 采样率已经够用不需要用 44.1kHz 的高保真规格。我实际对比过 Whisper API 对 16kHz 单声道 AAC 和 48kHz 立体声的识别结果差距微乎其微但文件体积差了好几倍传输速度也天差地别。所以这个项目默认配置走的是 16kHz、单声道、AAC-LC每分钟音频体积大概在 300KB 到 500KB 量级一小时也只有二十兆左右对一次几秒到几分钟的灵感录音来说毫无压力。2.2 音频文件怎么传输到 iPhone录音完成后文件要高效、可靠地传到 iPhone。watchOS 和 iOS 之间的通信基本都得走 WatchConnectivity 框架它有几种传输类型针对这个场景需要分清主次transferFile适合传输完整文件系统会把文件放入后台传输队列支持 WiFi 和蓝牙可靠性好。录音结束应该优先走这条路。sendMessage适合传递小指令比如“开始处理第几条录音”“请求新的转写”响应快但大文件不适合。transferUserInfo适合同步少量元数据比如录音时长、时间戳比 sendMessage 更省资源。工程实现上Watch 端 App 在 init 里创建 WCSession 并调用 activate()然后实现 delegate 的回调。发送侧调用 transferFile(:metadata:)iOS 端在 session(:didReceive:metadata:) 回调里拿到临时文件 URL立刻拷贝到自己的 Documents 目录。提示WatchConnectivity 的 didReceive 回调给的是临时目录必须第一时间 copy 到自己的沙盒目录否则文件随时会被系统清理。另一个实际经验是传输时机。watchOS 设备转瞬间进入低功耗模式后系统会暂停后台传输如果你录音完立刻锁屏文件可能要等到下次点亮屏幕才传过去。最稳的策略是录音结束时保持 Watch App 在前台几秒立即发起 transferFile这样基本都能秒传。要是在户外没有手机在旁文件就会留在 Watch 本地等项目下次打开时再补传所以本地缓存与清理策略也要配套。2.3 录音侧的参数选择与资源控制再补充几个属于“细节决定成败”的录音参数控制点。首先是时长管理。Apple Watch 不是为连续几小时录音设计的长时间录音会导致机身发热、电池健康下降系统也会在资源紧张时杀掉录音进程。我在测试中会把单条录音限制在 10 到 15 分钟以内超过就自动分段。分段还有个好处转写引擎处理短音频的准确率和稳定性都更高音频太长容易触发云端服务的上下文截断长会议录音拆成几段后逐段转写再合并总结效果反而更好。其次是麦克风方向问题。Watch 的麦克风在抬腕姿势下自然朝向说话人这个设计很聪明但你如果把手垂下来走路时说话收音效果会大打折扣。项目没法改变物理拾音特性但可以在转写阶段对特别低音量或高噪声的录音做预处理。我给 iPhone 端加了一个可选的“自动增益补偿”步骤用简单波形分析把过低的音频振幅拉高亲测对 whisper 识别率有明显帮助。最后是磁盘清理。Watch 端存储宝贵录完并确认 iPhone 收到后本地文件就应该主动删除iPhone 端则保留原始音频和最终总结转写中间文本可以选择 7 天自动清理。这样整条链路既不会撑爆小容量 Watch也保留了可回溯的原始素材。3. iPhone 端转写、总结与落盘3.1 语音转写引擎的选择转写是录音到总结的“翻译官”这一步的质量直接决定后面 AI 总结的天花板。这个项目在实际选型中主要比较过两条路线本地 ASR 和云端 ASR。本地方案以 whisper.cpp、whisperkit 或 faster-whisper 为代表模型放在 iPhone 上跑。优点非常突出完全离线、隐私最好、转写成本为零适合处理敏感内容或飞行模式场景。缺点也同样明显对中文支持相比云端模型偏弱时延高十几分钟音频可能要等上一阵而且连续转写会让机身发热、掉电明显。适合偶尔录几条的轻度用户。云端方案以 OpenAI Whisper API 这类按分钟计费的服务为代表识别精度高、中文标点完整、响应快而且不用在手机上维护模型文件。代价是按量付费目前 Whisper API 大致是每分钟 0.006 美元的量级对每天几条灵感录音来说成本可以忽略但对重度会议记录用户就得算一笔账。我个人的建议是项目保持这两种后端可切换的设计日常默认走云端信噪比高、要求严格的场景切本地。实现上用协议抽象一个 Transcriber 接口云端和本地各实现一份配置里填一个后端选择字段就够。代码结构不复杂但换来的是很实用的灵活性。3.2 AI 总结环节的提示词设计转写文本出来后调用大模型做总结是最有意思、也最需要调优的部分。很多人以为把文字丢给模型就行实际效果往往很泛。Nomily 的做法是把提示词分场景管理。如果是轻量灵感类比如“明天下午三点和晓明对一下项目排期”模型应该输出简洁的待办条目不需要长篇分析。如果是会议录音则要输出“主题 关键决策 待办事项 责任人与时间点”的结构。我给项目里预设了两套提示词模板用户也可以在设置页自己改系统提示词示例你是一个高效的个人助理。用户提供了一段语音转写文本请提取其中的主题、关键信息、待办事项和明确的时间节点。要求 1. 只输出用户确实提到的内容不要补充任何不存在的信息 2. 不确定的信息用[不确定]标注 3. 最终以Markdown列表输出控制在300字以内。这里有两个关键参数需要调temperature 要低一点0.2 到 0.3 比较合适避免模型发散max_tokens 也要设防止长文本总结被硬截断在中间。还有一个细节是“不要编造”这条声明几乎每次实测都能减少幻觉。用过 LLM 的都知道模型在信息不全时特别容易“脑补”声明越明确输出越老实。对超长音频我建议先分段总结再合并而不是一次性把所有转写文本都怼进上下文。分段总结保留每段核心句合并阶段再把若干段“摘要句子”汇总这样既绕开上下文窗口限制又能把核心观点最大化保留效果比硬塞完整文本好得多。3.3 输出格式与本地存储总结完成后怎么落盘也是个没有标准答案的设计点。项目选择生成标准 Markdown 文件目录结构类似Documents/ recordings/ 原始音频 .m4a transcripts/ 转写文本 .txt summaries/ 最终总结 .md文件命名用“日期_时间_主题关键词”的方式比如 2025-06-11_0930_项目排期.md。这样在文件 App、备忘录或任何支持 Markdown 的工具里都能直接检索和二次编辑。除了落盘iPhone 端还应该提供“分享”和“继续追问”两个入口。分享可以直接把总结发到备忘录、飞书、邮件继续追问是很多 AI 笔记产品容易忽略但价值极高的功能用户对刚生成的总结有疑问比如“这里面提到的最晚交付时间到底是哪天”可以直接对这条录音的上下文进行追加提问而不是重新跑一遍完整总结。从使用体验来说这两个功能让一条静态笔记活了起来我实际使用中几乎每天都会用到追问功能。4. BYOK 的成本、安全与隐私设计4.1 API Key 的保存与保护BYOK 模式绕不开 API Key 的安全问题。作为开源项目代码都公开了Key 如果写死在代码里等于把信用卡贴在门口。正确的做法要分两层构建期和运行期。构建期通过配置文件注入仓库里只放 config.example.plist包含键名和示例值真实 Key 由使用者本地填写。同时把包含真实配置的文件加入 .gitignore避免误提交。运行期最稳的保存位置是 iOS 的 Keychain而不是 UserDefaults。Keychain 里的数据经过系统级加密App 删除后仍可能保留适合重装快速恢复读取时要用 Security 框架的 SecItemCopyMatching。设置页放一个输入框 显隐开关就够了不建议做联网校验因为校验调用本身就会让 Key 多一次暴露。我见过太多 Open Source 项目因为 Key 泄露被刷爆账单的案例。所以项目里还做了一层防护默认关闭“自动转录新录音”开关必须手动确认开启每次调用前弹出“本次将消耗约多少算力费用”的估算提示。这样即使 Key 被误用用户能尽早发现。提示任何时候都不要把真实 API Key 提交进 Git 历史。已经提交过的不是删文件就能解决必须去服务商后台轮换 Key。4.2 成本估算与额度控制既然 BYOK 意味着用户自己掏模型费用成本感知就必须做清楚。这里给一个很粗略的量级参考每天录 5 条、每条 1 分钟的灵感录音转写费用大约每天 0.03 美元量级加上总结输出的 token 费用一个月通常不会超过 3 到 5 美元。重度用户如果每天录 1 小时会议成本会明显上升就值得考虑本地模型或改用更经济的供应商。控制成本我建议做三件事。第一在模型供应商后台设置月度预算上限和告警阈值这是兜底。第二在 App 设置里提供“处理策略”可以只处理最近 7 天的录音、可以对录音时长超过 15 分钟的分段转写、跳过草稿。第三模型选择上下功夫总结任务用便宜的小模型比如 gpt-4o-mini 这类轻量级完全够用转写走专用的 ASR 服务各司其职比所有环节都用同一个高规格模型省钱得多。项目配置里把“转写模型”和“总结模型”分开设置也是出于这个考虑。4.3 数据隐私边界隐私是这个项目最不需要怀疑的部分。因为 BYOK 的天然架构优势录音和文本从你的 iPhone 直接发送给你指定的模型服务商不经过项目开发者或任何第三方中转服务器。项目没有账号体系、没有云同步、没有遥测埋点代码开源可审计这比绝大多数商业录音软件要干净。需要提醒的是即使直连模型厂商数据也并非“不存在”。主流模型服务商默认会对 API 请求做短期留存用于排障和模型改进如果你处理的是机密信息需要到服务商控制台关闭数据留存或开启合规模式更稳妥的做法是直接切换本地模型一切数据不出本机。Nomily 把这种选择权放在用户手里本身就是 BYOK 模式的精髓。5. 开源项目部署与二次开发5.1 项目结构与核心代码模块一个这种规模的开源项目仓库结构通常值得仔细看因为它代表作者的架构取舍。Nomily 大致分为三个模块watchos/录音入口、会话管理、文件传输、本地缓存。ios/接收文件、ASR 调度、提示词管理、LLM 调用、结果展示与分享。shared/数据结构定义、配置模型、通用常量两端共同引用。核心文件职责可以用一张表说明文件/模块职责WatchRecorder.swift配置 AVAudioSession、AVAudioRecorder启停录音WatchTransferService.swift封装 WCSessiontransferFile 与元数据同步FileReceiver.swiftiOS 端接收音频并完成沙盒拷贝Transcriber.swift定义 ASR 后端协议云端/本地实现PromptBuilder.swift按场景组装提示词模板Summarizer.swift调用 LLM处理重试与分段总结SettingsView.swiftBYOK Key 配置、模型选择、预算开关如果想改造成自己的项目不要动 shared 层优先在 ios 端扩展功能即可两端依赖关系简单清晰。5.2 从源码到真机的完整部署步骤把一个双端开源项目跑起来比单纯跑 iOS Demo 要多几步。我按实际顺序整理一遍第一步克隆仓库用 Xcode 打开 ios 工程watchos 工程一般会作为 target 一起管理。确认电脑上安装的 Xcode 版本满足项目要求太老的版本编译 SwiftUI 双端工程会报错。第二步修改 Bundle Identifier 为你的唯一前缀并在 Signing 面板选择 Team。注意 Watch App 的 Bundle ID 需要与 iPhone App 形成关联一般格式是 iPhone 的 Bundle ID 后加 .watchkitapp这个不要自己乱改Xcode 在创建 target 时已经配好你只需要同步修改前缀。第三步准备配置文件。复制 config.example.plist 为 config.plist填入你的模型 API Key 相关占位或运行期提示文案。记住不要提交这个文件。第四步选择 iPhone 作为部署目标Xcode 会自动尝试把 Watch App 安装到已配对的 Apple Watch 上。确保 Watch 解锁、亮屏且和 iPhone 保持在蓝牙或同一 WiFi 范围内。第一次配对安装需要输入 Apple Watch 密码等待进度条走完就好。第五步在 iPhone 上打开 App进入设置填入 API Key如果配置走的是运行期输入。这时去 Watch 端打开录音界面第一次录会弹麦克风权限请求一定选允许否则后面所有录音都会静默失败。录一段、传一首、看总结是否生成跑通一次完整流程后再按自己的使用习惯调整提示词和模型。这套流程对第一次搞双端开发的初学者来说最大的门槛反而是各种小环境问题。比如开发者证书过期、Watch 系统版本比 iOS 旧导致 WatchConnectivity 接口缺失、iPhone 与 Watch 登录不同 Apple ID 导致配对异常。遇到问题先看控制台日志多数情况输出都会直接指向原因。5.3 可扩展方向这个项目最让我喜欢的地方是留白够大几乎就是给 AI 录音工作流搭了一个基础框架任何方向都能继续长。我自己已经在计划中的扩展方向包括结果自动同步到备忘录或 Notion把总结文本通过 Share Sheet 或 URL Scheme 推给第三方笔记工具顺手还能把链接转成稍后读清单录音触发源从“Watch 录音键”扩展到 AirPods 双击唤起让入口更自然把 iPhone 端的本地模型换成 ollama 支持的接口用家里那台闲置机器当转写服务器。如果你对“口头待办自动变成任务清单”感兴趣也可以在这个基础上对接待办事项的标准接口。这些都是想清楚数据链路后可以很自然延伸出去的功能。开源项目的价值也正在于此你不是拿它当终点而是拿它当起点。6. 常见问题与排查技巧实录6.1 录音侧问题我在测试阶段遇到最多的是“录了一段但回放没声音”。排查顺序是这样第一步看 Watch 端是否真的给了麦克风权限设置里没开的话直接授权第二步看 AVAudioSession 的配置如果 category 设置成 playback 而不是 playAndRecord录音会无声甚至失败第三步看录音文件属性用文件 App 导出后用播放器确认编码格式是否为 m4a/AAC如果录成了特殊格式播放器和 ASR 都不认识。还有一个比较隐蔽的问题Apple Watch 抬腕时如果检测到手腕上没有佩戴部分系统版本会暂停录音会话。测试时建议按真实佩戴姿态验证而不是把表摘下来对着麦克风吹气。6.2 传输与同步问题iPhone 收不到 Watch 文件九成原因是 WCSession 没有正确激活或 delegate 没有实现。检查这几个点iPhone 端和 Watch 端都要创建 WCSession 并调用 activate两端缺一不可。iOS 端要在 AppDelegate 或 SwiftUI 生命周期里尽早完成激活回调里先拷贝临时文件再处理别的。文件大、传输慢时可以选择让 iPhone 和 Watch 同时处于同一个 WiFi 网络速度会快很多。如果发现只有部分文件能收到看看 Watch 端是否因为低功耗模式挂起了传输。此时不要频繁重发否则系统会堆积大量重复请求。正确做法是在 Watch 端增加“待传文件”列表等 Watch 唤醒后再批量补传而且每次只传未完成的那部分。6.3 转写与总结质量问题转写乱码或者识别不准第一排查对象是音频采样率。如果录音被配置成了 8kHz 或更低很多 ASR 引擎的预处理会直接失效英文还行中文标点和口语词基本全崩。第二是环境噪声户外风声、咖啡馆背景音都会显著拉低识别率。第三是方言我拿普通话模型直接转粤语效果惨不忍睹但换成支持多语言的 Whisper 大模型后明显改善。总结太啰嗦或者信息缺失一般不是模型笨而是提示词没给到约束。把字数上限写死、把输出格式明确列出、把“只提取用户提到的内容”写进 system prompt三个小改动通常能立竿见影。至于模型偶尔编造时间或人名我的做法是提示词里加一条“不确定的信息用[不确定]标注”不要试图让模型猜。实测这条声明能明显减少“一本正经地胡说八道”。6.4 费用与额度异常问题账单比预期高先看是不是有两个环节都在计费并且重复运行。比如转写和总结各调用一次没问题但如果你把“分段转写后的文本”又整体送进同一个模型做第二次总结费用就会叠加。这类重复调用在日志里都能看到建议开一个“调用记录”页面每次请求消耗的分钟数/token 数都列出来一眼就能定位异常。Key 泄露是最坏的情况。一旦发现账单异常或代码仓库疑似暴露了 Key第一时间到服务商控制台吊销并重新生成同时开启用量告警。开源项目使用者要养成一个习惯任何 Key 都不要提交到 Git 历史已经提交过的要轮换而不是只删文件因为 Git 历史删不干净。最后分享几条我实际用了三周后觉得最值的小经验第一录的时候把关键信息用短句说清楚说成“明天下午三点和张三开会评审排期”AI 总结的信息密度会高很多意识流长句反而容易被提炼掉重点第二每天录完睡前瞄一眼总结随手分个类一周后就是很好的周报素材第三周末批量回顾总结文件时你会发现那些“随口说”的想法才是最能反映你真实想法的东西单凭这一点这套链路就很值得搭。