开源 AI 面试助手：GitHub 能给你什么，代价又是什么

搜索开源 AI 面试助手的人通常想要两件事之一：要么希望在让代码接近真实面试前先审计它，要么想跳过订阅、完全自己运行。GitHub 上两类项目都有。大多数遵循同一套配方：一个脚本或轻量桌面壳程序捕获音频，发送到语音转文字 API，再把转录文本连同你自己的 API 密钥喂给大语言模型，最后在终端或窗口里输出建议答案。

• 自备密钥 — 项目只提供胶水代码；语音转文字和 LLM 调用都计入你自己的账户。
• 宽松许可证很常见 — 可以自由 fork 和修改，这正是爱折腾的人想要的。
• 以麦克风为先的设计 — 捕获你自己的麦克风在哪都容易；可靠地从系统音频里捕获面试官的声音才是大多数仓库的薄弱处。
• 维护参差不齐 — 有些项目在积极维护，更多则是悄悄停止提交的周末实验。

这些项目近似实现的架构 — 实时转录驱动答案生成 — 正是商业工具原生构建的同一条流水线；工作原理专题有深入讲解。

想要开源是合理的本能 — 你能逐行看清代码对你的音频做了什么，也没人能收走这个工具。本节就来摊开这种掌控实际要付出的代价。简而言之：前期的配置成本、通话中的音频捕获质量，以及之后无止境的维护。

• 配置成本 — 依赖、API 密钥、音频路由和平台怪癖都得你自己解决；原生应用把这一切压缩成一个安装包。
• 系统音频捕获 — 要听到面试官，需要在 macOS 和 Windows 上做系统级回环或虚拟音频设备，而很多项目只写了其中一个平台的文档。
• 延迟调优 — 把通用语音转文字和 LLM API 串起来能跑，但要让建议快到在对话中真正有用，就成了你自己的工程问题。
• 没有支持，没有更新 — 当系统更新或 API 变动弄坏捕获链路时，修复要等志愿者有空才来，也可能永远不来。

一位备战云厂商高级岗位的后端工程师在周六克隆了一个看起来不错的仓库：到晚上 LLM 答案能出了，但 Zoom 测试通话里面试官那一侧始终没有声音，因为系统音频需要一个 README 只为另一个操作系统写了文档的虚拟设备。修复还躺在一个未合并的 pull request 里。

SubcueAI 不是开源软件。它是 macOS 和 Windows 上的闭源原生桌面应用，源代码不在 GitHub 上 — 这个页面不会装作不是这样。放弃源码访问换来的，是把上面那些仓库留作练习题的部分全部做成成品：

• 双路音频捕获 — 你的麦克风和面试官的系统音频被原生捕获，无需配置任何虚拟音频设备。
• 悬浮本地浮层 — 建议渲染在你机器上的一个窗口里；没有任何东西加入会议。
• 无会议机器人、无浏览器插件 — 谨慎的自托管派想要的低足迹设计在这里就是默认。
• 持续维护更新 — 当操作系统改动音频栈时，修复是厂商的工作，不占用你的周末。

诚实的另一面：如果你的硬性要求是审计每一行代码、或精确控制音频会到达哪些服务，SubcueAI 满足不了，开源项目才是正确选择。无论选哪条路，同样的限制适用于所有工具 — 屏幕共享、屏幕录制、监考环境和公司管理的设备会让任何助手失效，详见 /security 页面 — 当前方案（含免费档）见 /pricing。

如果你走开源路线，请像审查任何你要把一场工作面试押上去的依赖那样审查仓库 — 通话中途挂掉的助手比没有助手更糟。一份实用清单：

• 维护信号 — 近期提交、响应及时的维护者、有人回复的 issue；面试那一周才发现项目被弃坑就太晚了。
• 音频捕获现状 — 先在 issue 里搜索你所用系统上的系统音频、回环和虚拟设备问题，再假定捕获能用。
• 仅麦克风还是双路捕获 — 只听得到你自己的工具会漏掉问题本身；面试官的音频才是关键的那一半。
• 音频去向 — 读一读 API 调用附近的代码；用你自己的密钥时，转录文本会流向你配置的那些服务商。
• 完整彩排 — 在 Zoom、Google Meet 或 Microsoft Teams 上提前几天跑一次完整模拟通话，而不是面试当天早上。

如果这份清单让你确信有人维护的应用才是更稳妥的路，最佳 AI 面试助手指南对当前各选项做了并排比较。