先说结论：Quill 的亮点是音频管线，不是又一个“万能会议 AI”

Quill 把会议记录压缩成一个菜单栏按钮。开始录制后，它分别保存自己的麦克风和 Mac 正在播放的系统音频；停止时，两轨各自做本地转写，再按起始偏移与时间戳合并。因为“我”和“对方”天然位于不同轨道，它无需额外说话人识别模型就能生成 `me` / `them` 标签。每次会话还保留原始 CAF、元数据、JSON、Markdown 与日志，后续可接自己的归档或总结脚本。

这比只宣传“本地”更值得讲。CAF 在录制过程中持续可读，进程中断时不必等容器最后封口；文件系统同时充当任务队列，存在元数据但没有转写结果的会话会在下次启动时继续处理。对访谈、播客和研究型创作者，这是一个可观察、可二次加工的素材底座，而不只是把会议摘要藏进某家 SaaS。

“两轨”“本地”和“快”都要按真实场景验收

两轨只能区分麦克风侧与系统侧。如果远端通话里有三位嘉宾，他们仍会混在同一条 `them` 轨道；如果外放导致声音漏回麦克风，还可能出现重复文本。项目提供麦克风回声处理开关，但会轻微压低其他播放声。全局系统 tap 也会收进消息提示、网页视频和音乐，公开前必须逐段检查并按所在地、会议平台和参与者约定处理录音同意。

性能数字同样要注明机器。FluidAudio 在 M4 Pro 上报告每小时音频约 19 至 20 秒，Quill 复用了这套 Core ML 管线；实际速度会受芯片、音频长度、首次模型下载和后台任务影响。更重要的是，仓库目前没有 Release 或 tag，安装流程要求 Swift 构建并复制二进制，开放 issue 已出现重复转写、错误提示、按应用捕获和崩溃恢复需求。负责任的中文评测应拿英语、普通话、粤语和中英混说分别跑一遍，公开原始片段、权限路径与失败日志。这样读者看到的是一套值得借鉴的本地录音架构，而不是把 GitHub 星数误写成成熟度或中文可用性的保证。