Talent Summoner如何
一套實用方法：把職缺需要的技能轉成看得見的公開訊號，標出不確定之處，並修正效果不佳的人才搜尋對應方式。
你的候選人來源太少，於是開始搜尋「客戶系統整合」或「負責正式環境 API」。個人檔案都提到了相關工具，卻沒有一份說明這個人實際負責什麼。你應該擴大搜尋、放棄這個對應方式，還是提出一個更好的問題？
技能是職缺要求完成的工作；公開訊號則是看得見、讓這項技能值得進一步審閱的線索。訊號支持的是一個假設，不能證明能力、作者身分、能否到職或是否有興趣。建立對應表，就是要把這個差別明確寫出來。
從看得見的技能開始
把每一項重要要求改寫成「行動、範圍和情境」。「溝通能力強」太籠統。「向技術型客戶說明整合方案的取捨，並協調交付時的交接」才能讓審閱者知道要找什麼。如果職缺真的需要，「有 API 經驗」可以改寫成「負責過一個正式環境的 API 整合，從上線一路到維運」。
在看個人檔案之前，先把結果分類：
- 必備條件：真正會影響這個人能否勝任這份工作的要求。
- 加分條件：有用的背景資訊，但不應該悄悄變成淘汰規則。
- 界線：與工作相關的條件，例如地點、工作時段或工作許可。
接著，為每一項必備條件寫一個證據問題：公開的專業來源可能呈現什麼內容，讓這一項值得進一步查證？搜尋要以工作內容為準，而不是名氣或某個偏好的職稱。
建立技能與訊號對應表
每一項要求寫成一列。來源原文、你的解讀和不確定之處要分開記錄：
| 需要的技能 | 看得見的公開訊號 | 可能支持的判斷 | 仍然未知的部分 |
|---|---|---|---|
| 負責正式環境的 API 整合 | 專案或工作描述提到 API 整合、涉及的系統，以及這個人自述的職責 | 相關的整合工作值得審閱 | 正式環境經驗的深度、決策權限、成果和目前的熟練程度 |
| 向客戶說明技術取捨 | 案例研究、演講或個人檔案描述了如何說明限制、協調技術交付 | 面對客戶的技術溝通經驗可能相關 | 這個人在這份工作中、面對這些客戶和限制時會怎麼溝通 |
| 在交付期間提升系統可靠度 | 公開文章或專案紀錄描述一次事故、版本發布或維運調整，並寫明具體角色 | 有處理維運問題的經驗 | 這個人是否主導應變、規模多大、結果如何 |
| 使用 TypeScript | 程式碼庫、作品集或工作描述指出某個相關專案使用 TypeScript | 這個人可能在那個情境下用過這個語言 | 是否為本人撰寫、深度、是否用在正式環境，以及距今多久 |
如果來源回答不了最後一欄，就記為未知，不要寫成一句肯定的判斷。如果訊號描述的是相關工作，而且兩者之間有實質的銜接，就標為相近，並寫下銜接點。例如，一位協調過多次 API 導入的解決方案工程師，可能是「負責內部平台遷移」的相近證據；但工作環境和實際負責的範圍仍需要查證。
分五輪套用對應表
- 定義搜尋用語。加入職稱的不同寫法、工具名稱、專案用語，以及一到兩條核准過的相近路徑。記下每個詞可能代表什麼；不要要求一份個人檔案同時出現所有關鍵字。
- 只記下最小但有用的線索紀錄。保存來源、網址或頁面、查看日期和相關原文。有了這份紀錄，其他審閱者就能回頭追查一份內容經過挑選或可能變動的個人檔案。
- 標示兩者的關係。把每一項條件標為有證據支持、相近、未知或有矛盾。這些標籤描述的是資料本身，不是預測工作表現。
- 寫一個查證問題。問的是負責範圍、規模、情境、時效或成果。「這個整合裡，哪些部分是你親自負責的？」比「你懂 API 嗎？」有用得多。
- 比較不同的個人檔案。對熟悉的職稱、相近的背景和資訊有限的個人檔案，套用同一條證據規則。如果換了名字或雇主，標準就跟著變，代表這張對應表還沒準備好。
診斷效果不佳的對應表
候選人來源太少時，先檢查對應方式，再考慮增加管道：
| 常見問題 | 實際狀況 | 修正方式 |
|---|---|---|
| 把關鍵字當成能力 | 把「TypeScript」當成工程深度的證明 | 要求有相關專案或職責，再查證範圍 |
| 用職稱走捷徑 | 「Head of」的職稱就被當成有領導力，卻沒有描述任何決策 | 搜尋實際負責的成果、決策，以及團隊或系統的範圍 |
| 有作品就等於是本人做的 | 假設程式碼庫或案例研究就是這位候選人的成果 | 詢問對方貢獻了什麼、能說明哪些部分，並查看來源的背景 |
| 沒有訊號就等於沒有技能 | 一份簡短的個人檔案因為少了某個詞，就被排到後面 | 標為未知，並用同一個查證問題 |
| 把名氣或熱門程度當成證據 | 用雇主、學校、星數或追蹤人數取代與工作相關的成果 | 拿掉這個替代指標，定義一個與要求直接相關的訊號 |
| 證據過時或互相矛盾 | 不同來源的日期或職責對不起來 | 兩份線索紀錄都保留，查看背景，並指定一個人來釐清 |
| 軟實力定義模糊 | 「有策略思維」或「文化契合」沒有可以觀察的行為 | 改成可以評估的決策、互動或工作成果 |
如果每一位候選人都因為同一個原因不符合，問題可能出在技能的定義，而不是人才市場。一次只測試一項調整：把行動範圍縮小、加一條相近路徑，或拿掉一項偏好。保留舊版對應表，才分得出是證據變好了，還是標準單純降低了。
負責任地使用公開訊號
只收集符合核准招募目的所需的資料。英國資訊專員辦公室（ICO）指出，在招募中使用 AI 的組織應該確認合法依據、記錄各方責任、監控公平性和準確性、說明資料如何使用，並把收集範圍限制在必要的程度。這份 2024 年 11 月 6 日的指引屬於一般資訊，不是法律意見；請依你所屬組織的規定辦理。流程檢查可以參考 ICO 對招募用 AI 的考量重點。
訊號要與工作相關。不要從公開頁面推斷受保護或敏感的特徵、個性、家庭狀況或動機，也不要把對方沒有回應當成可以繼續聯繫的許可。美國國家標準暨技術研究院（NIST）把它的 AI 風險管理框架定位為自願採用的指引，協助在 AI 的設計、使用和評估中納入可信賴性。它是風險管理的參考資料，不是招募標準，也不是法律結論。
Talent Summoner 的定位
Talent Summoner 是我們依職缺發掘候選人的產品。它的人才搜尋流程於 2026 年 10 月 3 日查證，會從一份職缺說明開始，在 LinkedIn、GitHub 和其他公開的專業來源中搜尋超過 2 億份個人檔案，回傳一份排序好的入圍名單，附上必備條件、加分條件和白話的理由。用對應表把條件和未知事項寫清楚，再親自檢查來源。這個產品的重點是發掘候選人；它不會證實訊號、查證說法、確認對方有沒有興趣或能否到職，也不會替你做錄用決定。
如果你面對的其實是手上現有的一批履歷，候選人排序是另一個獨立的流程，依職缺說明整理你提供的履歷。請把它和公開來源的人才搜尋分開看待。兩個流程都無法取代查證、聯繫、面試或最後的人選決定。
重點整理
把一項技能對應到它所指的工作、可能呈現這項技能的公開訊號，以及仍然存在的不確定之處。對應方式失效時，先修正證據規則，再擴大搜尋。候選人來源太少，可以成為放寬假設的理由，但不能成為把薄弱訊號當成證明的理由。
常見問題
什麼是候選人的公開訊號？
在允許使用的專業來源中，一項看得見、與工作相關、讓候選人值得審閱的細節，例如一個專案、一項職責、一份作品或相關的背景。它是用來發掘候選人的訊號，不能證明技能、作者身分、能否到職或是否有興趣。
個人檔案列出某項技能，就能證明候選人做得到嗎？
不能。列出的工具或技能可能代表接觸過，但負責範圍、深度、情境和時效仍然未知。記下這個訊號，說明它支持什麼，再提出一個聚焦的問題。
候選人在某項必備條件上沒有任何公開訊號，該怎麼辦？
把這項條件標為未知，而不是不具備。先檢查是來源不完整，還是搜尋用語太窄，再對可比較的候選人套用同樣的查證流程。
Talent Summoner 能查證候選人的公開訊號嗎？
不能。我們的人才搜尋流程可以搜尋公開的專業來源，並依職缺需求說明整理出一份附理由的排序入圍名單。檢查來源、釐清未知事項、聯繫候選人、面試和做決定，都必須由你的團隊負責。
從你正在招募的職缺中挑一項必備條件，寫下它的行動和範圍，再建立三列：直接訊號、核准過的相近訊號，以及未知。接著開始一次聚焦的人才搜尋，用同一張對應表檢查每一筆結果。
Talent Summoner 的產品資訊取自我們線上的人才搜尋和候選人排序頁面，於 2026 年 10 月 3 日查證。我們每季重新查證本頁，如果有任何變動，歡迎告訴我們。
