候選人排序 QA 檢查清單

候選人排序 QA（品質檢查），是在大家被排序結果先入為主之前，確認面試小組手上的排序資料包已經可以拿來討論。它要問的是：職缺需求說明、候選人資料、證據標籤和說明，是否完整到足以進行一次可比較的審閱。它是一道「準備好了沒」的關卡，不是第二個分數，不保證公平，也無法取代面試小組的判斷。

對一個還在規劃階段、要校準評分的面試小組來說，有用的結果是一份簡短的清單：已確認的輸入、看得到的缺口，以及審閱者能回答的問題。在面試小組開會之前跑完這份檢查清單。讓 QA 紀錄綁定一個職缺和一份候選人資料包，這樣之後有任何變動都能追溯。

先定義什麼叫「通過」

先寫下一個決策問題，例如：「這個職缺的哪些候選人，應該進入下一輪由人進行的審閱？」記下決策負責人、面試小組開會日期、候選人範圍，以及核准的職缺需求說明是哪一個版本。不要讓排序結果重新定義這個問題。

需求說明應該寫出這個人必須做的工作，並把必備條件、加分條件和真正的營運限制分開。針對每一項條件，寫下哪些證據可以支持它、哪些仍是未知，以及誰能查證。除非團隊已經把「文化契合度高」這種籠統的需求，轉換成每位審閱者都能檢查的工作相關行為，否則不要用它。

打開結果之前，先對標籤達成共識。像有證據支持、相近、未知和互相矛盾這樣一小組標籤，只要定義有寫下來，就很好用。這些標籤描述的是某項條件的證據，不是在描述一個人的價值。未知是一個要轉交出去的問題，不是不及格的分數。

檢查輸入的資料包

在看排序之前，先審閱資料包。把下面這些檢查當成一道關卡，而不是私下修補候選人紀錄的理由。

QA 檢查	要回答的問題	通過的訊號
需求說明的完整性	職缺需求說明是否已核准、有版本、有負責人？	指明一份目前的需求說明，並附上核准脈絡和決策負責人。
條件是否清楚	另一位審閱者看得懂每項條件的意思嗎？	每一項都有分類、證據標準，以及允許的同等經歷路徑。
候選人範圍	是否清楚納入了哪些紀錄、為什麼納入？	資料包有一份標明日期的候選人清單，沒有無法解釋的增減。
檔案和身分檢查	審閱者能打開每個來源、分辨每筆紀錄嗎？	檔案或連結都能讀取、已去除重複，並對應到一個候選人代號。
來源檢查	審閱者找得到每項重要說法背後的陳述嗎？	在可行的情況下，記下來源檔案、段落或連結。
存取權限和敏感資料	資料包是否只分享給需要的人？	負責人依照組織的資料處理流程，並移除不必要的個人資料。

如果某項檢查沒通過，就把資料包標為暫緩，並寫出最小的修正方式。缺少來源，不是推論負面結果的理由。如果發現重複的紀錄，保留原始紀錄，並記下哪一筆才是準的。如果需求說明在蒐集候選人之後改過，就建立一個新版本，並決定這份資料包是否需要重跑。

把排序當成審閱的輔助來檢查

現在從整份資料包中抽查實際的結果：包括排在前面的候選人、接近推進門檻的候選人，以及至少一筆證據不完整的紀錄。這是檢查資料包是否準備好的抽樣，不是人為設計的極端案例測試。目的是看看面試小組能不能直接解讀結果，而不用去猜系統或操作的人是什麼意思。

用下面這些問題檢查每一個抽到的結果：

說明是否指向某一項具體的職缺條件，而不是籠統的印象或重複出現的關鍵字？
必備條件和加分條件是否清楚分開，讓偏好不會悄悄彌補一項還沒解決的需求？
缺少的證據是否標為未知，並指派一個人負責查證？
互相矛盾的說法或不清楚的負責範圍，是否看得出來，而不是被混進一段很有把握的摘要裡？
審閱者能不能從說明回頭找到原本提供的來源？
任何順序上的變動，是否都能用核准的需求說明和候選人證據來解釋，而不是因為一條沒有紀錄的規則改變？

不要把排在前面當成能力、作者身分、是否有空或可能表現的證明。也不要把排在後面當成最終淘汰。QA 結果應該說明面試小組可以檢查什麼，以及還需要問什麼。

把 QA 發現轉成面試小組的問題

開會前，把每一個重要的缺口都轉換成一個中立的問題。這樣可以減少臨場發揮的質問，也讓可比較的候選人走在可比較的審閱路徑上。

QA 發現	面試小組的問題	下一位負責人
提到了某項需求，卻沒有附上來源段落。	哪一個來源應該支持這項條件？候選人最少需要回答什麼問題？	證據負責人
一項強烈的偏好似乎主導了排序，但某項必備條件仍是未知。	這項必備條件是還沒確認，還是有可靠的證據顯示不符合？	職缺負責人
紀錄描述的是團隊成果，卻沒有寫出這個人的貢獻。	這位候選人負責了、決定了或改變了什麼？可比較的候選人又會被怎麼問？	面試負責人
兩筆紀錄看起來描述的是同一個人或同一份工作。	哪一筆紀錄才是準的？重複的那筆是否已保留在稽核紀錄裡？	資料包負責人
審閱者對同一項條件可能有兩種解讀。	什麼樣看得到的工作，能讓每位審閱者的解讀都一樣？	決策負責人

在每個問題旁邊寫下期望的回答形式。例如，要求提供一個來源、一個範圍明確的實例，或一個定義好的查證步驟。不要要求面試小組用更快的投票來解決輸入資料的問題。

校準之前，先簽核資料包

替資料包標上一個狀態，並記下理由：

可以交給面試小組：必要的輸入都齊全，重要的未知都有負責人，問題也準備好了。
暫緩，等待證據：一個缺少或互相矛盾的來源，可能會改變下一步。
修正需求說明：某項條件模稜兩可、重複，或沒有寫成和工作相關的內容。
確認資料處理：存取權限、隱私或其他營運限制，需要相關負責人在審閱前處理。

簽核紀錄應包含 QA 負責人、日期、需求說明版本、候選人範圍代號、發現的問題、下一步行動和停止條件。停止條件可以是「在確認必備條件的來源之前，不比較推進分數」。把原始資料包和修正後的版本連結起來。當面試小組知道自己能回答哪些問題時，QA 就完成了，而不是等到每個未知都被硬塞成一個分數。如果之後重跑改變了排序，就把它加進入圍名單變動的決策紀錄，而不是覆蓋已簽核的資料包。

可以直接複製的 QA 紀錄

這份紀錄可以直接從頁面上複製，貼進招募文件使用；不另外提供下載檔。

職缺和需求說明版本：
決策負責人：
QA 負責人和日期：
候選人範圍：

[ ] 已記錄核准的需求說明和各項條件的定義
[ ] 必備條件、加分條件和營運限制已分開
[ ] 候選人檔案或連結都能讀取，且已去除重複
[ ] 重要證據都有來源，或明確標為未知
[ ] 抽查的說明都對應到核准的條件
[ ] 矛盾、缺少的證據和負責範圍的缺口都有下一步行動
[ ] 面試小組的問題使用可比較的提問方式，並有具名負責人
[ ] 已記錄狀態、停止條件和下一個審閱時間點

Talent Summoner 的定位

Talent Summoner 是我們的產品，提供 AI 人才搜尋、履歷排序，以及經你確認後才送出的候選人聯繫。目前的候選人排序工具（2026 年 9 月 3 日查證）可以貼上或上傳一份職缺說明，加上最多 50 份 PDF、DOCX、MD 或 TXT 格式的履歷，不需要帳號，會交回一份附白話理由的排序入圍名單和可分享的報告。把這份報告當成這道 QA 關卡的輸入。我們的產品不會決定面試小組的條件、不會查證每一個來源，也不會做出最後的錄用決定。

當候選人資料包不完整、需要一次核准過的搜尋時，人才搜尋（2026 年 9 月 3 日查證）會從一份職缺需求說明開始，在 LinkedIn、GitHub 和其他公開專業來源的 2 億份以上個人檔案中搜尋。它的排序結果是需要查證的線索，不能證明負責範圍、目前是否有空或有沒有興趣。把找到的候選人加進面試小組的資料包時，要清楚標明來源管道。

候選人排序 QA 要檢查什麼？

它檢查職缺需求說明、候選人資料包、證據紀錄、排序說明和面試小組的問題，是否已經準備好進行一次可比較、由人進行的審閱。它不會為排序背書，也不會預測工作表現。

QA 和面試小組的校準是一樣的嗎？

不一樣。QA 是在校準開始之前，確認審閱資料包能被正確解讀。校準則是之後的討論，談審閱者如何把共同認可的條件套用到證據上。

證據不足時，面試小組該怎麼做？

維持未知，找出經授權的來源或可比較的問題，指派一位負責人，並記下停止條件。不要把沒有資料轉換成淘汰的分數。

Talent Summoner 能自動完成面試小組的 QA 嗎？

不能。我們的產品可以依職缺說明替你提供的履歷排序，並附上白話理由，但檢查來源、準備可比較的問題和做出決定，仍然由團隊負責。

下一次面試小組開會前，複製這份 QA 紀錄，把需求說明和候選人範圍定下來，抽查說明，並替每一個重要缺口寫一個有負責人的問題。接著，如果是你手上已有的履歷，就用候選人排序；如果需要一次核准過的搜尋，就用人才搜尋。