你在面試完一位候選人之後，也許會有「感覺對」或「感覺不對」的直覺——但如果我問你：
「另一位 HR 用同樣的方法面試這個人，會得到一樣的結論嗎？」
老實說，大多數面試官會停頓一下。不是因為他們不專業，而是因為這個問題從來沒被真的回答過。我們習慣用「經驗」、「直覺」、「手感」作為面試的操作語言，但這些詞彙有一個共同的問題——它們都存在你的腦袋裡，別人看不到，也複製不了。
前一段時間，我一直在做一個「面試助手」。做到最後我才發現，AI 不是我的替身，是我的顯微鏡——它不能代替我判斷，但它把我腦袋裡那些模糊的「感覺對」「感覺不對」逼出來、攤開來，讓我第一次真的看見我在找什麼樣的人。
而當這些判斷開始被寫出來、被版本化、被團隊共用，我慢慢意識到一件更根本的事：我真正在做的事不只是「面試」，而是在「定義這間公司想要成為什麼樣子」。
這篇文章想分享的，表面上是一套 AI 面試助手的設計決策，底層談的其實是——一間組織如何把「面試官的判斷」從一個人的直覺，變成可以被累積、被檢討、被交接的資產。
第一個問題：標準只存在腦袋裡，就等於沒有標準
我們先來拆解一下，為什麼不同面試官看同一個候選人會得出不同結論。
原因通常不是「有人判斷能力比較好」，而是：
- 每個人對「溝通能力好」的定義都不一樣
- 同一位面試官，在一天中不同時段、不同心情下，打出來的分數會飄移
- 候選人順序效應——先面試到的強者會抬高後面的門檻
真正的問題不是判斷能力，而是標準沒有被寫下來。
但你可能會說：我們公司有面試題庫、有評分表啊。
是的，但絕大多數公司的評分表都會落入同一個陷阱：評分表是靜態的、評分行為是事後補的。你會看到一個面試官在面試結束後，憑著模糊的印象去勾選「溝通能力：良好」。那個勾選背後，並沒有具體的行為案例，也沒有跟其他候選人的比較基準。
有文件不等於有標準；有標準不等於標準被一致地執行。
這件事我想了很久，才意識到：面試標準其實不是一份文件，而是一套需要被運行、被觀察、被修正的系統。所以我嘗試著，將這一套系統重新按照「人」的認知順序做拆解、顯化，再將其封裝成能夠讓AI執行的流程。
第二個思考：食譜不是寫下來就算數的
我在前一篇〈AI Agent：點完餐之後，才是真正的開始〉裡提過一個比喻——廚師是能力，食譜是流程。同一位廚師，沒有食譜的時候仍然會做菜，但結果會不穩定；而一間餐廳真正能長期累積的，不是某位廚師的個人手藝，而是那一套被整理過、可以重複執行的做菜方法。
招募標準也是。
但食譜要發揮價值，必須符合三個條件：
- 它要有版本——當你發現「鹽巴放少一點更好」，你需要能記下這個改動，而不是直接蓋掉舊版、忘記為什麼這樣改
- 它要能被重複執行——不同廚師按同一份食譜，應該做出接近一致的菜
- 它要能從實際料理中學習——客人吃完之後的反應，應該要回饋到食譜本身
我後來發現，系統設計要解決的其實就是這三件事。下面這幾個設計決策，每一個都在回應其中一點。
設計一：標準是有版本的，像 Git 一樣
系統裡的每一份評分標準都有一個不變的識別碼（例如 STD001），但它可以有多個版本——v1、v2、v3。
當你面試了十個人之後，發現某個維度的滿分描述根本沒人達得到，或是你發現「獨立執行力」這個維度其實反映的是另一個你更在意的能力——這時候你不會去把原本的標準蓋掉，而是基於舊版產生一個新版本。舊版自動被標記為 deprecated，但不會刪除。
這樣做有兩個理由。
第一，歷史報告指得回去。一年前你用 v1 面試小王，打了 72 分；今年 v3 的滿分描述改過了，但小王那份報告仍然是 v1 時代的產物——你打開它，系統告訴你「這是 v1」，你就知道當時用的尺是什麼。
如果你需要的話，甚至可以用v3再評估一次小王——進一步將這個調整具體化。
第二，標準的演化過程本身有價值。你從 v1 改到 v2 到 v3，每次改的理由、每次新增刪減了哪個維度，都是一份公司在「我們想找什麼樣的人」這件事上的思考軌跡。把它保留下來，比單純「我們現在用這份」有價值得多。
版本化的標準會變成公司的資產，而不是某個人離職後就失效的知識。
設計二：每一份評估報告，都會被存兩份
這是整套系統裡我自己最滿意的一個設計。
每次系統幫你評估一位候選人之後，會產生兩份一模一樣的報告：
- 一份叫做 official copy——這是你的工作副本，你可以改分數、改評語、加備註
- 一份叫做 comparison copy——這是 AI 的原始輸出，永遠不動
為什麼要存兩份？因為這兩份報告之間的差異，才是整個系統最有價值的訊號。
當你把 AI 給的「技術能力 85 分」改成「技術能力 70 分」，系統不會只是記下你改了——它會在你累積了幾次類似修改之後，幫你分析：
「你在過去三份報告中，都把 AI 對『技術能力』的評分往下修。看起來你對這個維度的嚴格度比 AI 推斷的標準還高。是不是要更新 v2，把評分標準的滿分描述改得更嚴格？」
換句話說，你修改報告的行為本身，就是在教系統「你想找什麼樣的人」。
這件事對 HR 來說非常關鍵。過去在傳統的 AI 面試工具裡，你改了 AI 的建議，通常只是「改掉就算了」——這些寶貴的偏好訊號從來沒有被記錄、被學習。而這套系統把「人類修改 AI 輸出」這個永遠在發生的行為顯式化了，變成可以被系統迭代標準的結構化資料。
AI 不是在替你判斷，而是在看你怎麼判斷，然後幫你把你的判斷寫下來。
設計三：讓 AI 模擬一個有紀律的面試委員會
這是整套系統架構上最「技術」的一個決策，但背後的理由其實非常 HR。
你想想看，如果你讓一位面試官一口氣讀完履歷、聽完 60 分鐘逐字稿、看完所有維度的評分標準，然後要他一次給出「推薦 / 不推薦」的結論——他很難不被月暈效應（halo effect）影響。候選人某一段講得特別精彩，會讓整份評估的分數都偏高；某個維度被發現不足，又會讓其他維度也被連帶低估。
這是人類認知的先天限制，其實 AI 也一樣。
所以系統在做履歷篩選和面試評估時，都刻意設計成多層隔離：
- 第一層：一個維度配一次 LLM 呼叫，各自獨立分析，不讓模型知道其他維度的結論
- 第二層：只讀第一層的輸出，整合出「整體結論」，但這時候已經看不到履歷原文了
- 第三層：只看關鍵維度跟整體結論，最後給出推薦標籤
每一層 LLM 都不知道上下文全貌，只能根據前一層的產出往下走。聽起來很囉嗦，成本也確實比一次性呼叫 LLM 高很多（每個候選人每個維度要呼叫三到四次），但好處是：每一個判斷的依據都是可追溯的，不會發生「我也不知道為什麼 AI 突然覺得這個人很好」的情況。
讓 AI 模擬一個有紀律的面試委員會——先讓每位委員分頭看各自主題、最後才開聯席會議，比讓一個人憑感覺給結論可靠得多。
補充：把模型的隨機性也關掉
還有一個跟「可追溯」同一個精神的小設計——大多數 AI 系統每次回應都在「擲骰子」，從好幾個可能答案裡隨機選一個。這是為什麼同一個問題你問 ChatGPT 兩次，回覆會有些微不同。
在聊天場景裡這沒什麼大不了，但在面試評估裡這是災難——它意味著同一份履歷、同一套標準，今天跑一次、明天跑一次，可能會得到不同結論。這不是 AI 學到了新東西，純粹是隨機。
所以我把這個機制徹底關掉（temperature=0, top_k=1）。結果是：
同一份履歷 + 同一套標準 + 同一個模型 = 永遠得到同一份評估。
這不是為了「更準」，而是更可追究。當結果真的不一樣時，你會很清楚差異來自哪裡——模型換了、標準改了、或履歷逐字稿本身有差。而不是「模型今天心情不一樣」。
面試這種會影響人命運的判斷，不應該有一個環節的差異來自於骰子。
設計四：一個人的工具，一個團隊的尺
前面四個設計談的都是「標準本身」跟「執行可靠度」。但真正的 HR 工作從來不是一個人的事，而是一個團隊——好幾位面試官、幾位主管、甚至跨部門的 collaborator。
所以系統設計上我選了 local-first 這條路線。但這裡要先澄清一個常見的誤解——local-first 的意思不是「所有資料都留在本機」，而是「哪些資料共享、哪些留本機，由你這個團隊自己決定，而不是由某家 SaaS 廠商替你決定」。
具體來說，系統裡每一個資料夾都可以獨立指定它的位置：
- 評分標準：共享（NAS / Git / Dropbox 都行）—— 這是團隊一致性的根本
- 評估報告：共享——HR 團隊互相看得到，避免重複面試、避免盲點
- 候選人履歷：通常 HR 群組內共享（但不對全公司開放）
- 面試逐字稿：最敏感，多半留本機或嚴格授權
- 個人準備的面試題庫：留本機（你面試前的工作筆記，共享反而奇怪）
這個組合出來的結果很漂亮：團隊共享那些該共享的「判斷基準」跟「評估產出」，而每個面試官保留那些屬於自己工作流程的私人資料。
用食譜的比喻來說——總店訂下食譜、分送到每間分店，每位廚師各自在自己的廚房裡做菜。食譜是共享的、中央管理的；但每間分店當天的訂單、備料筆記、客人反饋，是留在各自店裡的。這樣做既有「連鎖的一致性」，又保留「每家店的自主性」。
而且更重要的是——這個共享 vs 本機的劃分不是系統寫死的，是你的團隊隨時可以調整的。今天你們只共享標準；三個月後覺得評估報告也該透明化，把那個資料夾也搬到共享位置就好了。不需要換系統、不需要 migrate 資料、不需要跟廠商談合約。
這是傳統 HR SaaS 最痛的地方：要嘛全員上雲、被綁死在一家廠商；要嘛各用各的、沒有共同標準。Local-first 讓你擁有「團隊一致性」，又不犧牲「個人自由度」，而且那條分界線永遠在你手上。
守住一條線：AI 是工具人，人才是決策者
寫到這裡，你可能會覺得——所以這是一套很聰明的 AI 面試系統？
不完全是。
回到文章一開始我說的那句話：AI 不是你的替身，是你的顯微鏡。
當我需要把「溝通能力」這個維度寫成具體的評分標準時，我才發現我對「好的溝通」的定義模糊得可怕；當我要決定「哪些維度是關鍵維度」時，我才意識到我過去的很多「直覺」，其實是好幾個判斷糾纏在一起的結果；當我看著 iterate_standard 告訴我「你過去三份報告都把某個維度往下修」時，我才承認——那個維度我原本設計的滿分描述根本就是錯的。
這些事情不會因為你做了 AI 工具就自動浮現，但 AI 工具會逼你把它們寫出來。
所以這套系統的核心哲學其實只有一句話：
HR 不需要一個能代替他決定的 AI。HR 需要一個能幫他把判斷變得一致、可追蹤、能迭代的工具。AI 在這個系統裡永遠是工具人，human 永遠是決策者。
系統裡所有的設計都在守這條線——輸出永遠是「建議」而不是「決定」，標準的迭代需要人確認，報告要人修改才有學習訊號，每一份歷史報告都能追溯回當時的標準版本。
跨過這條線，這就不再是「讓 HR 做得更好的工具」，而是「取代 HR 判斷的系統」——而那是完全不同的東西，也會服務完全不同的目的。
結尾：面試到最後，你其實是在定義自己
文章開頭我說過一句話：我真正在做的事不只是「面試」，而是在「定義這間公司想要成為什麼樣子」。寫到這裡，我想把這句話講完。
過去我在面試中靠直覺判斷，我以為這是我的專業；現在我發現，直覺很多時候是「標準還沒被說清楚」的替代品。當標準被寫出來、被執行、被修正，你會意識到：
你真正在面試的，從來不只是一個人，而是在定義你想找的那種人。
而當你開始這樣看待面試——它就再也不是一份需要靠直覺完成的 judgment call，而是一套可以跟團隊一起迭代、一起成長的系統了。
這也正好呼應我之前寫過的兩篇文章——
〈生成式 AI，不只是點餐這麼簡單〉說：「要用好一項工具，前提是要對它理解足夠透徹。」
〈AI Agent：點完餐之後，才是真正的開始〉說：「不是 AI 變強了，而是食譜清楚了。」
而這一篇想接著說的是：當食譜開始累積、開始版本化、開始被團隊共用，你會發現你不只是在寫食譜——你其實是在寫這間餐廳的靈魂。
這套系統目前以 MIT License 開源在 GitHub。你可以自由拿去用、改、甚至商用。我選擇開源是因為——一部分是想讓它當作我的作品集，一部分是想聽聽其他在做 HR 或 AI 的人會怎麼回饋我，但最重要的是，如果這套思考方式能讓某個正在為面試標準煩惱的 HR 少走一點冤枉路，那就值得了。
如果你的團隊正在思考怎麼把面試標準從個人經驗變成組織資產，歡迎試用，也歡迎提 issue 跟我討論你的 HR workflow。
CTA
如果你認同我的內容有所幫助，
歡迎在「方格子」或是「Linkedin」給我一個愛心or讚！
如果你認為我的內容可以幫助到更多人，
歡迎在各種管道進行分享！
如果你想要給我回饋或是有任何想法，
歡迎在「方格子」或是「Linkedin」留言告訴我！
