開源 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 面試助手指南對目前各選項做了並排比較。