video-db/call.md

如果你会议密集，希望笔记、行动项和后续自动化不用额外请一个机器人参会者来记录，Call.md 值得看一眼。它是以 macOS 为主的 Electron 应用，绑定 VideoDB 的云端服务，所以关键判断是：你是否接受会议音频被送到 VideoDB 处理。

解决什么问题

会前你打开笔记应用，靠记忆捕捉决定；会后还要把转写稿整理成同事或 CRM 能用的东西。Call.md 改的是中间一段：在桌面应用里开始录制，它同时采集麦克风和系统音频，并把你的声道与其他参会者分开，让实时转写呈现“你 vs 对方”。会议结束后，它会生成包含叙述性概览、要点和行动项的三段式摘要，并可导出带完整转写和会议中生成信息的 Markdown 记录。

有什么不同

卖点不是转写本身，而是这个循环。录制过程中，应用会跟踪指标、给出教练式提示和 AI 辅助，MCP 智能体可以判断信息需求并调用相关工具；会后会议数据还能推送到 n8n、Zapier 或 CRM 这类自动化平台。

这套设计让转写和 AI 功能依赖网络：README 明确说这些功能需要联网，使用时会将会话录音、转写和 AI 输入发送到 VideoDB。这里的“本地优先”指的是设置、会议历史、转写稿和生成元数据存放在本地 SQLite 数据库，凭据使用安全说明中描述的系统级存储；它不意味着分析留在你的机器上。

第二个取舍是分发方式。macOS 提供现成安装包，并有 2 小时录制上限，结束前 5 分钟提醒；暂停时间和系统睡眠不计入额度。Windows x64 只有在源码构建（npm run dist:win）后才能录制；Linux 和 Windows ARM64 构建可以打开界面、MCP 服务、工作流和历史上，但因缺少采集二进制会拒绝开始录制。这是产品边界，不是安装故障。

谁值得试

适合：使用 macOS、经常进行销售、招聘或客户复盘的从业者，想要实时辅助和可用的会议纪要，又不想让一个独立机器人加入会议，并且接受 VideoDB 处理音频。如果你已经把会议产出接进 n8n 或 CRM，并希望这一步自动化，也匹配。

不适合：需要离线会议记录的人、要在 Linux 上录制的人，或不想自己构建 Electron 应用却想在 Windows 上录制的人。不能把会议音频交给外部服务的团队应止步于隐私模型。若你只需要转写存档，实时智能体这套机制超出了需求。

使用条件与边界

即使使用桌面应用，也必须持有 VideoDB API key，转写和 AI 功能需要联网。首次录制前要授予麦克风和屏幕录制权限；排障说明提到首批转写大约要等 5–10 秒。录制上限写死在代码（MAX_RECORDING_DURATION_MS）里，修改后要重新构建，因此超长会议需要换工具或自己改构建。

语言支持并不均衡：会议语言在设置里选择，仅对下一次录制生效；README 承认不支持的语言会回退到引擎默认值而不是报错，并链接了对应 issue。日常维护包括保持 API key 有效并在设置里轮换、留意更新后打包的采集可执行文件和 SQLite 原生模块是否还在，以及开发时重建原生模块。平台矩阵和排障见项目说明，托管版操作演示见示例文档。

HotRepo 点评

HotRepo 只有一条带日期的观察：2026-10-27 当天 1,888 星、日增 +86，也是它唯一一次进入每日趋势榜。这只能说明那天的关注度，不能证明热度在升或降，仓库又年轻，持久性还无法判断。安装前真正该确认的不是流行度，而是 VideoDB 依赖：免费 API 额度覆盖什么，以及按你常见的会议长度，2 小时上限之后应用如何表现。