你有没有过这种经历开会到一半突然一句关键分工从耳边飘过你下意识抬起手腕按下 Apple Watch 的录音键。语音备忘录多了一条新录音然后……就没有然后了。我翻过自己的语音备忘录里面躺着四十多条录音最早的是半年前的大部分我再也没点开过。不是不想整理是整理成本实在太高——回听一小时录音手打摘要抽待办光是想想就放弃了。这个项目的出发点很简单把 Apple Watch 当成一个纯粹的捕获设备让 AI 接管后面所有脏活累活录音进去结构化的摘要、决策和待办出来。最终做出来的效果就是一枚手腕上的 AI 录音助手。这个项目适合两类人。一类是像我这样会议多、想法碎、手上又总有别的活的打工人另一类是刚入手 Apple Watch、想让它从看时间工具变成生产力工具的玩家。门槛不高核心资产生态一块 Apple Watch、一台 iPhone、一个能跑 Python 的轻量服务器。整体方案里既有硬件选型、快捷指令搭建也涉及 Whisper 转录、大模型摘要、自动化回推这些 AI 工作流的关键环节我会把我踩过的坑原原本本写出来包括那些文档里查不到的细节。1. 为什么是手表AI而不是换个录音笔1.1 被忽略的痛点录音不是目的整理才是很多人以为录音助手的核心是录得清。真正用过一段时间就会发现录音质量只是起点真正的痛点是人很少愿意回去听录音。我统计过自己的使用习惯录音完成后一周内会回听的概率大概只有三成一个月后基本为零。因为录音是原始数据不是信息。原始数据要变成信息必须经过转录、分段、去口语、提炼要点、划出待办这一整套处理而这些步骤做起来太累于是录音就成了手机里只进不出的数字杂物。Apple Watch 恰好把这个问题放大了。它让录音变得太容易了抬手就能录导致积压速度远超手机录音的时代。但苹果官方只提供了录的能力没有提供消化的能力。语音备忘录的转录功能在很多地区不可用就算可用也只给你文本不给你要点、不给你待办。所以我的判断是纯靠系统自带功能录音这条链路永远走不通必须外挂一个 AI 处理层。1.2 方案定位手表负责捕获AI 负责消化这个项目从设计第一天就把分工定死了。Apple Watch 只做一件事在最方便的时候以最低的摩擦把声音捕获下来。它可以忍受录音质量不如专业设备因为后续有 AI 兜底它可以忍受不能本地处理因为服务器会接盘。AI 层则负责所有重计算语音识别、语义理解、信息结构化甚至判断一段录音里哪些话是废话、哪些才是真正的行动项。把重活放到远端还有一个额外好处录音处理能力可以持续升级。今天用 Whisper明天有更好的开源模型直接换就行不需要动手表。这也是我坚持不把手表端塞满算法的原因。手表的算力、内存、续航都是稀缺资源与其让它气喘吁吁地跑一个小模型不如让它安安静静当好麦克风。1.3 适合谁不适合谁如果你要录的是发布会现场、嘈杂餐厅里的对话或者需要 48kHz/24bit 高保真素材这个方案不适合你Watch 的麦克风阵列本身就存在物理上限。但如果你是像我一样录的内容是工作会议、灵感碎片、电话沟通后的复盘、课堂讲座那这套链路完全够用而且体验远超传统录音笔。我也测试过一个折中替代方案用手机录音、手表只做快捷触发。实际用下来反而不如直接在手表上录。原因很简单手机掏出解锁打开录音 App 的操作成本在快速场景里仍然太高而手表上的一个表盘复杂功能点击就能开始。所以最终的定位很明确手表是捕获入口AI 是消化引擎两者缺一不可。2. 整条 AI 工作流是怎么设计的2.1 录音端为什么锚定语音备忘录 快捷指令技术选型时我一开始考虑过第三方录音 App比如 Just Press Record 或者自带云同步的录音工具。但最后放弃了原因有三个稳定性、系统集成度、以及成本。第三方 App 在 watchOS 上的后台录音策略随时可能变化而系统自带的语音备忘录是和 watchOS 深度绑定的录音可靠性最高。更关键的是快捷指令Shortcuts能够访问到系统录音能力这给了自动化拼接的可能。快捷指令在 Watch 上可以运行录制音频操作并把录音得到的文件作为变量传给下一步网络请求。这意味着我可以完全不用写任何手表 App纯靠快捷指令拼出一条自动化链路。开发成本几乎为零系统升级后适配成本也很低这对我来说是最重要的。2.2 传输层一个轻量上传接口搞定录音文件从 Watch 到服务器技术路线其实很多iCloud Drive、AirDrop、WebDAV、自建上传接口。实际对比后自建一个简单的 HTTP 上传接口是最可控的方案。原因是录音文件一旦落到 iCloud你就得等它同步还得在快捷指令里去获取文件中间环节多延迟不可控。直接在快捷指令末尾调用一个上传接口把录音文件 multipart 传上去立刻就能收到已上传的反馈链路最短。接口本身不需要任何花哨功能我给它设计了两件事接收音频文件并保存转录完成后允许客户端用录音 ID 查询结果。同步阻塞不是好选择因为转写可能要几十秒。异步轮询虽然多写一点代码但体验顺滑得多。用 FastAPI 实现这个接口只要几十行代码后面会有完整实现。2.3 处理层ASR 与 LLM 的分工与选型录音文件到了服务器后第一件事是把它变成文字。这一步我选了 OpenAI 开源的 Whisper 模型而不是云服务商的付费语音识别 API。原因有几层一是 Whisper 对中文、中英混说的支持都相当稳甚至能自动补出标点这对后续摘要非常关键二是开源模型意味着数据不用经过第三方识别服务隐私上更可控三是不按分钟计费个人使用成本几乎为零唯一成本是机器 CPU/GPU 时间。转录完成后进入第二层摘要与结构化。这一步和 ASR 是解耦的选型思路完全不同。摘要需要模型理解上下文、筛选重点、归纳决策这不是语音识别模型能干的得换成大语言模型。我倾向于把整段文字交给 LLM而不是分段喂因为跨段信息关联对摘要质量影响很大。如果录音特别长可以先用滑动窗口做粗筛再整体精炼。Prompt 设计我后面会贴出来这块直接决定输出质量。2.4 回推层让结果回到手腕AI 处理完的摘要如果不能回到手表方案就缺了最后一块拼图。苹果生态里最简单的回推方式是快捷指令定时拉取然后用 iOS 通知展示。我每天在固定时间跑一个日报快捷指令从服务器取当天所有录音的摘要拼成一份纯文本发到通知中心。想要更进一步的可以让服务端返回 JSON 数组快捷指令逐条读取并调用添加新提醒事项把待办自动写进系统提醒事项。我实际用的是双通道紧急的、需要立刻跟进的事情在录音结束后几分钟内就通过推送到达零散的、不那么急的内容进日报统一消化。回推层不需要手表端做任何事因为 iOS 通知会自动同步到 Watch 上信息最终以一次抬腕看到提醒的方式闭环体验非常自然。3. 实操搭建三阶段实现一个可跑的录音助手3.1 阶段一Watch 端一键录音与自动上传先在 iPhone 上打开快捷指令 App新建一个快捷指令命名为会议速记。添加第一个操作录制音频。这个操作在 watchOS 上可用点击后手表会进入录音界面再次点击停止返回一个音频文件变量。接着添加发送文件操作URL 填你的服务器上传接口地址比如https://你的域名/api/upload方法选 POST请求体选文件文件变量选上一步的音频文件。最后加一个显示通知操作标题写录音已上传这样每次录制完都能第一时间知道链路是否成功。整个快捷指令只有三个操作但可以跑通录音→上传的完整链路。把它添加到 Watch 表盘上的快捷指令复杂功能抬腕点击就能启动。快捷指令构建清单 1. 录制音频Watch 端 2. 发送文件 → https://your-server.com/api/upload 3. 显示通知录音已上传这个阶段最容易遇到的问题是 Watch 和 iPhone 之间的文件同步延迟。我实测下来Watch 上的录音文件要等几十秒才会出现在 iPhone 的语音备忘录里但只要快捷指令使用的是录制音频操作内部返回的文件变量就不依赖语音备忘录同步它是直接把手表本地录制的临时文件发给服务器速度反而更快。3.2 阶段二服务端转录与摘要处理服务器端我用了 FastAPIPython 生态下最省事的方案。接收上传后先把文件落到临时目录然后调用 Whisper 做转录。Whisper 建议用small以上的模型tiny和base对中文口语的识别会明显吃力。命令行大致是这样whisper meeting.m4a --model small --language zh --output_format txt --output_dir ./out转录完成后读取生成的 txt 文件交给 LLM 做摘要。我用的 Prompt 参考如下你是一个会议记录助手。以下是某段录音的转写文本。 请整理出 1. 讨论主题 2. 关键要点用简洁的条目 3. 明确决策 4. 待办事项及其负责人如果文本中有 要求省略客套话和重复内容输出用中文。把转录文本拼接在 Prompt 后面调用大模型 API 拿摘要。这里有个细节正式录音往往会包含大量口头禅、重复和无关闲聊所以我在 Prompt 里主动要求省略客套话和重复内容这能让摘要质量提升一个档次。处理结果同时保留原始文本和摘要一起存入 SQLite 数据库方便查询。3.3 阶段三把摘要变成提醒事项与日报服务端加一个GET /api/latest接口返回最近一两条录音的处理结果iPhone 端的快捷指令定期访问这个地址就能把结果拉下来拼成通知。如果想让待办自动进系统提醒事项可以让服务端返回 JSON结构约等于{ id: abc123, summary: 讨论了Q3排期确定下周上线, todos: [确认上线日期, 联系设计团队] }iPhone 上的快捷指令用获取 URL 内容拿到 JSON 后用从列表中选取和添加新提醒事项两个操作组合就能把todos数组逐条写入提醒事项。这个自动化可以放在每天 20:00运行一次也可以配合个人自动化在特定地点或时间触发。我在这个阶段还加了一个轻量日报接口汇总当天所有录音的摘要返回纯文本。快捷指令每天早晨跑一次把摘要串成早报通知。实测下来这个日报比录音本身有用得多因为它是已经消化过的信息流抬腕扫一眼就能回忆昨天说了什么。3.4 成本与配置清单整个系统我不建议一开始就追求完美配置。先在一个最低可行版本上跑起来再逐步加 server 能力。我自己的参考配置如下组件用途成本参考Apple Watch录音终端已有设备iPhone快捷指令与通知中枢已有设备轻量云服务器部署 FastAPI Whisper约 30~80 元/月Whisper small本地语音转写免费大模型 API摘要与结构化处理个人使用约 5~20 元/月SQLite记录处理结果免费转录对 CPU 的消耗比较大1 小时录音在小规格服务器上可能要转十几分钟。如果不想等建议服务器带 GPU或者干脆用云函数的异步方案录音先落对象存储再触发转录任务。我目前就是用一台小 CPU 实例 异步任务队列跑的没有 GPU但配合消息通知后使用者并不会感知到延迟。4. 踩坑实录这些问题我花了三个晚上才解决4.1 Watch 端快捷指令的限制与对策第一个坑是发送文件操作在 Watch 上并不是总是可用。我最初在 iPhone 上构建好快捷指令后直接同步到 Watch点击运行发现卡在发送文件。排查结果是 watchOS 某个版本对发送文件支持不完整必须先在 iPhone 上手动运行一次该快捷指令让它完成权限授权之后在 Watch 上才能正常跑。这个操作在苹果官方文档里写得很隐晦我是在快捷指令的运行历史记录里看到授权提示才确定的。第二个坑是长录音超时。手表通过蓝牙转发文件的速度有限一次超过十分钟的录音上传过程很容易在中途断开。我的对策是给快捷指令加了一个继续在 iPhone 上运行的设置让实际上传发生在手机网络环境。代价是运行过程中要保证手机在附近但对绝大多数会议场景来说这不是问题。第三个坑跟快捷指令的变量类型有关。录制音频返回的音频变量在某些 watchOS 版本里类型会被识别成文稿导致后续发送文件操作报错。解决方法是加一个获取文件操作把音频变量显式转换成文件类型再发送。这个兼容性处理在 watchOS 10 上尤其重要。4.2 录音质量到底有多影响转录效果这是模型层面的经典问题我说点直观数据。我在三种环境下各录了 3 分钟中文语音做测试环境Whisper small 准确率表现备注安静办公室基本没有错字直接可读咖啡厅背景音少量错字专有名词容易错需要 Prompt 纠正多人会议说话重叠句子粘连严重必须分段 说话人分离多人会议是最难搞的场景。Watch 的单麦克风没有空间指向性一旦两个人同时开口转录结果几乎没法看。我的应对是把录音文件按时长切分为 30 秒片段分别转录再拼接虽然不能解决重叠但至少可以减少长段落里的错误传导。如果是重要会议还是建议配一个领夹麦通过蓝牙接到 iPhone 上录然后再跑同一条 AI 链路。专有名词也是一个高频翻车点。比如团队内部的项目代号、客户公司名、英文缩写Whisper 第一次基本都会认错。解法有两个一是在 Prompt 里提供术语表让 LLM 在摘要时自动纠正常见错词二是用 Whisper 的initial_prompt参数把专有名词列表传进去能明显提升识别率。我现在就在快捷指令的服务器端维护了一份全局术语表每次转录前自动注入。4.3 隐私、功耗与续航的取舍把录音传到服务器很多人第一反应是隐私问题。我的处理原则是录音文件到达服务器后转录完成立即删除原音频数据库只保留文本摘要和结构化结果服务器启用 HTTPS 并限制上传接口调用频率。这样即使服务器被攻破攻击者拿到的也只是处理后的文本而不是原始语音。如果你所在场景涉及敏感信息可以在这条链路后面再叠一层本地脱敏先过滤身份证、手机号之类的字段再调大模型。功耗方面Watch 录 10 分钟音频大约消耗 5%~8% 电量连续 1 小时录制会在 30% 以上。我的使用习惯是会议录音这种高频场景控制在 20 分钟以内长内容转向 iPhone 内录。重要的是不要让手表长期处于正在上传状态所以我在快捷指令里做了失败后自动停止上传、保留文件待手动处理的分支避免手表因为反复重试而耗电。4.4 常见问题速查表把这些排查经验整理成表格方便直接对照问题现象可能原因解决办法快捷指令在 Watch 上缺发送文件watchOS 版本兼容性在 iPhone 上先完整运行一次再同步上传到一半超时蓝牙传输慢开启继续在 iPhone 上运行录音文件类型报错变量类型识别为文稿加获取文件操作显式转类型中文转录错字率高模型太小/背景噪音换 small 以上模型、切分 30 秒片段专有名词识别错误术语表缺失用 initial_prompt 注入术语表录完没有推送服务器回调失败/接口被风控检查日志加失败重试与通知确认服务器转录太慢CPU 规格低换 GPU 实例或用异步队列这条链路跑起来之后我最大的感受是问题本身不可怕可怕的是每一步都像黑盒。所以我在服务器日志里留了三处关键节点——收到文件、转录完成、摘要完成——每个节点都记录耗时。出了任何问题一眼就能定位是卡在哪一环节。5. 这个项目还能长成什么样从录音助手到语音 Agent5.1 会议纪要自动生成顺手把周报也写了一旦你手里有了稳定可靠的录音→摘要流水线下一件顺理成章的事就是自动生成会议纪要。我现在已经可以把一场 40 分钟的部门周会录音变成一份五百字左右的纪要包含议题、结论、下一步行动直接发到团队协作群里。这个能力完全来自上面那条链路只在末尾加了一个打开协作平台页面的快捷动作。周报也一样。每周日晚上我把本周所有录音摘要拼在一起让大模型按本周进展“下周计划风险项三个板块重新组织就成了一篇周报初稿。以前这部分要花我半小时以上现在我只需要打开校对一遍。这是整个项目里我使用频率最高的能力也最能体现录音助手这个词的价值——它的产出不是文字而是可以直接使用的工作成果。5.2 待办自动拆解再也不用整理过期录音摘要里出现的待办目前是用快捷指令逐条写进系统提醒事项的。这已经能用但我还在尝试把这一步做得更主动一点让 LLM 不只输出纯文本而是输出 JSON 数组包含每件事的截止时间、优先级、负责人然后由一个轻量 Agent 判断这件事该进日历、该进项目看板、还是该转给协作工具。这就是一套典型的 AI Agent 工作流录音助手不再只是记录仪而是一个会分配任务的执行者。目前的实现比较克制。我不打算让它自动发送任何对外消息只自动写入提醒事项和日历因为自动化的边界一旦放太开出错的代价会很高。建议你起步时也把 Agent 限制在只写本地待办这个范围内等跑顺了再逐步开放权限。5.3 多语言转录与跨设备知识库Whisper 天然支持多语言所以这套方案对英文、中日文录音也能转录。我试过用英语采访素材跑整条链路转录质量出乎意料地好摘要直接用中文输出也没问题。这意味着你可以把一次海外电话会的录音变成一份中文要点摘要这对信息消化效率的提升非常明显。跨设备知识库是我最近在折腾的方向。把每次录音的摘要按日期、主题、项目标签存入一个小型知识库之后想看某个客户的历史沟通脉络不用再翻几个月前的录音直接按标签查摘要就行。再激进一点可以让大模型基于知识库内容做问答那就变成了一个随身记忆库。对我来说这个扩展方向的前景比录音转文字本身大得多。5.4 与 AI 生态组合的更多玩法这套结构本质上是捕获设备 AI 工作流 行动输出的组合换成不同的捕获端和输出端玩法可以完全不一样。比如把输入从 Watch 换成汽车里的 Siri就能变成一个行车灵感记录器把输出从提醒事项换成简报接口就能变成一个团队情报汇总站。核心的 AI 处理层完全复用变的是外围设备。我还测试过一次多 AI 协作的结构Whisper 负责听写一个专门的说话人分离模型负责区分谁在说大模型负责语义摘要三个模型串成一条流水线效果比单个全能模型更好。这说明在 AI 场景里模型拆分的价值经常被低估。如果一个模型干不好三件事往往不是模型不行而是你该给它配两个队友。最后说两句实在话做这个项目最大的收获是让我重新认识了 Apple Watch。它本来只是一个通知提醒器但在 AI 工作流的加持下变成了一个低摩擦的信息输入口。它录出来的声音经过服务器上模型的消化最终转化成提醒、摘要、知识库里的条目——信息在整条链路中不断被提纯最后变成行动。我个人的建议是别急着一步到位。先搭一条最原始的链路Watch 录音自动上传回传摘要文本。用一周感受一下哪里卡、哪里慢、哪里用得别扭再决定要不要加待办自动写入、说话人分离、知识库这些高级功能。这套东西强在可迭代每一次录音都在给你提供改进的测试样本。那些积在语音备忘录里没整理的旧录音也别急着删它们是最好的数据源。