Talent Summoner如何
用虛構的邊界案例測試候選人配對評分準則，找出規則失效的地方，並在審閱一份難分高下的入圍名單之前，把修正交給負責的人。
用邊界案例測試配對評分準則，是在把一份難分高下的入圍名單當成可以審閱之前，先檢查規則在界線上怎麼運作。目的不是證明評分準則能預測工作表現，而是確認當證據不完整、說法不同，或和另一項要求互相拉扯時，同一項要求是否仍然得到一致的解讀。
對正在比較一份難分高下入圍名單的招募人員來說，有用的測試會留下一份可以重複執行的紀錄：測試案例、預期的處理方式、實際結果、任何差異的原因，以及由誰負責修正。把這些測試和真實候選人的證據分開。虛構的紀錄可以揭露規則失效，又不會變成對某個人的評價。
測試之前先定義預期的決定
固定需求說明的版本、審閱要回答的問題，以及做決定的負責人。把需求說明拆成必備條件、加分條件和營運界線。每一項條件，都寫下什麼樣的精確證據才算數，以及資料回答不了時要用的狀態，例如有佐證、相鄰、未知或有矛盾。
接著，在執行評分準則之前，先替每個測試案例寫下預期的處理方式。這就是測試的判準：它說明規則應該怎麼處理這筆輸入，而不是你偏好的候選人順序。例如「一個相關的同等專案，在職缺負責人確認兩者的關聯之前，算是相鄰」可以測試；「這份個人檔案應該排很前面」就不行。
把每個測試標成擷取、解讀、優先順序或交接。檢查這個訊號有沒有被呈現出來、描述有沒有超出來源能支持的程度、有沒有被偏好條件蓋過，以及有沒有連到一個看得見、由人負責的下一步。
建立一小組虛構的測試案例
建立簡短的虛構紀錄，每次只改變一項重要的特性。不要複製真實應徵者的個人資料，也不要加入捏造的雇主、成果或資格，免得被誤當成證據。一個測試案例只放測試這條規則需要的內容。
| 測試案例 | 要測的界線 | 預期的處理方式 |
|---|---|---|
| 直接證據 | 這項要求寫得很明確，附有相關的脈絡和負責範圍。 | 有佐證；保留來源和精確的解讀。 |
| 同等的說法 | 工作內容相關，但用了不同的職稱或用語。 | 先評估工作本身的訊號，再依核定的對應方式標成有佐證或相鄰。 |
| 缺少必備條件 | 紀錄對一項重要要求完全沒提。 | 未知，不是不合格；指派一個可以互相比較的查證問題。 |
| 明確的矛盾 | 某項提供的說法和要求或另一個來源互相衝突。 | 有矛盾，或暫停交給人審閱；不要把衝突平均掉。 |
| 加分條件的拉力 | 某項偏好很強，但一項必備條件仍是未知。 | 讓未知保持看得見；偏好不能在沒人注意的情況下蓋過門檻。 |
| 關鍵字誘餌 | 出現了熟悉的詞，卻沒有相關的工作或脈絡。 | 不算支持這項條件；記下為什麼光有這個詞不夠。 |
可以的話，加入一組成對的邊界案例。先寫一位虛構人物「負責」一次正式環境的資料遷移，再只把「負責」改成「協助」。這能在不靠職稱或關鍵字的情況下，測試負責程度。另一組可以只改變核定的地點界線。這些是流程探測，不是基準資料；不要用它們算準確率。作品集型職缺的候選人篩選評分準則提供了一組現成的配對：一份精美但工作證據很薄的作品集，對上一份樸素但證據扎實的作品集。
逐項條件執行測試
讓每個測試案例都跑同一個版本的評分準則，並保留輸入、輸出和時間戳記。先拿評分準則給的狀態和說明，和預期的處理方式比較。看整體順序之前，先審閱證據的說法：一個看起來合理的排序，可能藏著錯誤的條件標籤；一個較低的名次，也可能來自明確的界線，而不是缺陷。
每一處差異，都要精確地分類：
- 偽陽性：輸出把關鍵字、職稱或相鄰的工作，當成符合這項要求的證明。
- 偽陰性：輸出漏掉一個核定的同等說法，或相關的脈絡。
- 未知被抹平：缺少的資訊變成負面、正面或很有把握的結論。
- 優先順序錯誤：加分條件彌補了一項還沒解決的必備條件或界線。
- 證據過度延伸：說明加入了測試案例裡沒有的範圍、負責程度、時間點或成果。
每一個失效，都保存最小、可以重現的例子。如果要求本身模稜兩可，先暫停，請做決定的負責人修改需求說明。如果規則很清楚，但輸出錯了，就只改一條規則，重跑受影響的那一組案例，並記下其他案例有沒有跟著變動。避免為個別候選人開例外，那會削弱下一次的審閱。
把結果整理成交接紀錄
另一位同事應該不需要口頭說明，就能重跑這個測試。紀錄裡要有職缺和評分準則的版本、測試案例編號、條件、預期狀態、實際狀態、來源或輸入摘錄、失效類型、建議的變更、審閱者、負責人和停止條件。
邊界案例測試編號：[編號]
職缺／評分準則版本：[職缺]／[版本]
條件與類別：[條件]／[必備條件 | 加分條件 | 界線]
測試案例輸入：[虛構紀錄或受控的變更]
預期的處理方式：[狀態 + 精確理由]
實際的處理方式：[狀態 + 說明]
差異類型：[偽陽性 | 偽陰性 | 未知被抹平 | 優先順序 | 過度延伸 | 成對結果不一致]
建議的修正：[一條規則或需求說明的變更]
重跑範圍：[測試案例編號或候選人組合]
負責人／停止條件：[姓名或角色]／[條件]
處置：[保留 | 修改 | 暫停 | 往上呈報]只有在負責人記下處置和重跑範圍之後，才結束這次測試。輸出穩定，不代表評分準則公平、正確或完整；它只表示這個測試案例在測過的版本下，得到了相同的結果。把測試紀錄和評分準則的變更歷史放在一起，讓之後的審閱者分得出入圍名單的變動，是因為證據變了，還是因為規則變了。
Talent Summoner 能幫上什麼
Talent Summoner 是我們的產品，做 AI 人才搜尋、履歷排序，以及經你確認後才送出的聯繫訊息。目前的候選人排序工具（2026 年 9 月 2 日查證）可以貼上或上傳一份職缺說明，加上最多 50 份 PDF、DOCX、MD 或 TXT 格式的履歷，不需要帳號，就會交回一份排序入圍名單，附上白話理由和可分享的報告。用一組受控的虛構輸入，檢查你提供的要求是怎麼被呈現的，同時把你的預期處理方式和邊界案例紀錄放在報告之外。產品頁沒有說明專用的評分準則測試工具，也沒有通用的邊界案例狀態量表。
如果缺的是手上的履歷來源，人才搜尋從一份需求說明出發，在 LinkedIn、GitHub 和其他公開專業來源的 2 億份以上個人檔案中搜尋，交回排序結果，附上必備條件、加分條件和白話理由。把公開來源的結果當成有待查證的探索素材。評分準則、可以互相比較的查核，以及入圍名單的決定，仍然由你的團隊負責。
配對評分準則裡，什麼算是邊界案例？
一筆落在規則界線上的受控輸入：證據缺少、說法同等、互相矛盾，或某項偏好碰上一項未知的必備條件。用虛構的測試案例。
缺少證據，應該讓必備條件的測試不合格嗎？
不應該。除非有一道以證據為準的門檻適用，否則標成未知。記下缺少的事實、可以互相比較的查核，以及負責人。
一次評分準則測試應該包含多少個案例？
沒有通用的數字。每一條重要規則各準備一個一般案例和一個邊界案例，再為受控的變更加上成對的案例。
Talent Summoner 能自動執行邊界案例測試嗎？
產品頁說明的是上傳、排序結果、理由和可分享的報告，不是邊界案例的測試工具。測試案例和重跑，請放在你自己的流程裡。
下一次遇到難分高下的入圍名單時，先固定需求說明，建立一小組成對的測試案例，再請一位同事照著交接紀錄重跑一次。一次只解決一處規則差異；手上已經有履歷，就用候選人排序，缺的是人選來源，就用人才搜尋。
