Litmus
從你自己的程式庫生出考題，還會看候選人怎麼用 AI
Litmus 用公司自己的程式庫、工單與職缺描述自動生成非同步的程式測驗，評估候選人實際在你的技術棧上會怎麼工作，並且會追蹤他們使用 AI 工具的過程。
功能特色與適用場景
技術面試最大的荒謬之處是：你考的是反轉二元樹，實際工作是在十年老專案裡改一個沒人看得懂的模組。Litmus 想解的就是這個落差——直接從公司的程式庫、Jira 工單與職缺描述生成貼合真實工作的題目。更有意思的是它的評分方式：除了在沙箱裡用確定性的測試框架驗證正確性，它還完整記錄候選人的過程——檔案改了幾次、commit 歷史長什麼樣、以及使用 AI 工具的情況。最後一項在 2026 年特別重要，因為現在的問題已經不是「你會不會用 AI」，而是「你會怎麼用」。另外可設定以 LLM 進行質性評估，看架構思維與決策品質。整合面支援 Ashby、Greenhouse、Lever 等 ATS，候選人資料自動同步。客戶包含 Neo Scholars、Mercor、Composio 等。定價依招募需求與量體客製，未公開費率。
適合軟體團隊各階段的技術評估，特別是新創與成長期公司；程式庫太混亂或涉密的公司需先評估可行性。
主要功能
- 從公司程式庫、工單與職缺描述自動生成考題
- 追蹤候選人過程：檔案迭代、commit 歷史、AI 工具使用
- 沙箱即時評分，確定性測試驗證正確性
- 可設定 LLM 進行架構與決策的質性評估
- 整合 Ashby、Greenhouse、Lever 等 ATS
常見用途
- 初篩階段的非同步技術評估
- 用真實程式庫的任務取代白板題
- 評估候選人在特定技術棧上的實際能力
- 觀察候選人如何運用 AI 工具解題
- 多職缺的技術評估標準化
TheAI學院 編輯建議
編輯實測後的真心話「會不會用 AI」在 2026 年已經不是問題了，「怎麼用」才是。我看過候選人用 AI 三十秒交出一個能跑但完全不能維護的答案，也看過有人用 AI 快速理解陌生程式庫再自己寫出乾淨的解法——這兩種人的差距，傳統面試完全看不出來。Litmus 把過程記錄下來，這個方向我覺得很對。前提是：先告訴人家你在記錄。
主要功能
- 從公司程式庫、工單與職缺描述自動生成考題
- 追蹤候選人過程：檔案迭代、commit 歷史、AI 工具使用
- 沙箱即時評分，確定性測試驗證正確性
- 可設定 LLM 進行架構與決策的質性評估
- 整合 Ashby、Greenhouse、Lever 等 ATS
適用場景
- 初篩階段的非同步技術評估
- 用真實程式庫的任務取代白板題
- 評估候選人在特定技術棧上的實際能力
- 觀察候選人如何運用 AI 工具解題
- 多職缺的技術評估標準化
Litmus 的優點與缺點
優點
- 題目貼近真實工作，訊號品質遠高於制式演算法題
- 追蹤 AI 使用方式，符合當代開發者的實際工作型態
- 非同步進行，不占用面試官與候選人的同步時間
- 整合主流 ATS，流程不必額外搬資料
缺點
- 需要提供程式庫存取，涉密專案有疑慮
- 未公開定價，需洽談
- 追蹤 AI 使用可能引發候選人的隱私疑慮
- 題目品質高度依賴公司程式庫本身的可讀性
Litmus 常見問題
把程式庫給第三方安全嗎？
這是導入前必須解決的問題。合理的做法是只提供去識別化的子集、或專門建立的模擬程式庫，而不是整份生產程式碼。合約中也要明確約定資料用途、保存期限與是否用於模型訓練。涉及客戶資料的專案更要謹慎。
追蹤候選人怎麼用 AI，這樣公平嗎？
我認為公平的前提是「事先明確告知」。現在的開發者本來就會用 AI，假裝不會反而失真。重點是要提前說清楚：允許使用 AI，且過程會被記錄與評估。偷偷監測就是另一回事了，那會有法律與信任問題。
台灣公司適用嗎？
概念適用，但要注意兩點：一是台灣《個人資料保護法》對招募過程蒐集的資料有規範，追蹤行為紀錄需事先告知並取得同意；二是題目自動生成的品質依賴程式庫的註解與結構，很多台灣公司的老專案可能生不出好題目。
使用者評價
還沒有足夠評價，搶先分享你的使用心得！
