Talent Summoner審閱
一份決策指南：在入圍名單上的人選難分高下時，如何比較他們的開源工作，把看得到的證據和假設分開，並決定下一步要查證什麼。
開源工作會讓一份難分高下的入圍名單看起來比較好比較。一位候選人附上了程式碼儲存庫的連結，另一位有幾個 pull request，第三位則沒有任何公開的程式碼。要問的是：這個來源到底證明了什麼，又有哪些需要查證。
在找到候選人之後、用同一套條件比較一小批人選時使用這個方法。這是審閱證據，不是在獎勵公開活動有多頻繁。
打開儲存庫之前，先把條件定下來
用可以觀察的方式寫出和工作相關的需求。「優秀的開源貢獻者」不是一個有用的門檻。「能審查程式碼變更、說明技術取捨，並在協作團隊中維護達到正式環境品質的程式碼」，才能讓審閱者知道要問什麼。在看到任何名字之前，先把每一部分分類為必備條件、加分條件或核准的界線。
針對每一項條件，定義哪些證據可以支持它、哪些不行。一段 pull request 的討論，或許能證明對方參與過程式碼審查和協作，但無法證明對方負責過正式環境、獨立完成整個貢獻，或目前仍然熟練。一份 README 可以描述一個專案，卻無法說明誰是作者、運作規模多大，以及當初做了哪些決定。
替每個來源留一份簡短的紀錄：
候選人／條件／需求說明版本：
儲存庫、issue 或 pull request 的網址：
查看日期和來源脈絡：
這個來源明確證明了什麼：
候選人的貢獻：直接／共同／未知：
還有哪些未知或互相矛盾的地方：
查證問題／負責人／停止條件：
決定：推進／查證／暫緩／結案：比較實際貢獻，而不是活動總量
每位候選人都用同樣的順序審閱他們的工作。先從和這項條件最相關的成果開始，然後問：
- 要解決的問題是什麼？從來源中找出使用者、系統、限制或決策。
- 候選人做了什麼？把對方親自寫的變更，和審查留言、issue、文件修改或團隊共同擁有的儲存庫分開。
- 看得到哪些脈絡？記下來源中呈現的測試、取捨、對審查意見的回應或限制。
- 哪些成果有證據支持？記下明確寫出的結果和脈絡。如果頁面上只寫「改善了」或「更快了」，就標為未查證。
- 哪些是無法得知的？把缺少的負責範圍、工作規模、時間遠近或協作細節，寫成未知。
整份入圍名單都用同一套標籤：
| 證據標籤 | 來源支持什麼 | 下一步行動 |
|---|---|---|
| 直接 | 描述的工作和重要脈絡都和條件高度相符，而且貢獻清楚到可以檢查。 | 查證剩下的範圍或成果，再用同一個門檻比較。 |
| 相近 | 這份工作有相關性，但職責、環境或負責範圍之間仍有重要的落差。 | 針對這個落差問一個聚焦的問題。 |
| 未知 | 來源沒有回答這項條件，或無法確認貢獻是誰的。 | 不要加分也不要淘汰；請對方提供可比較的證據。 |
| 互相矛盾 | 一個可靠的來源，和候選人自己說的職責或另一筆重要紀錄互相衝突。 | 兩邊的紀錄都保留，並指派一個人來釐清。 |
這些標籤描述的是證據，不是在預測工作表現。看得到的 commit 比較少，證據仍可能比較強；一份非常活躍的個人檔案，如果看不出負責範圍，也可能說明不了什麼。
解讀 GitHub 訊號時，要知道它的限制
GitHub 說明，個人檔案呈現的是一個人選擇公開分享的工作、貢獻和資訊。它的貢獻參考文件列出了哪些情況會出現在貢獻圖上，並說明有些動作只在某些情況下才會計入。貢獻圖是一份經過篩選的活動紀錄，不是能力的衡量標準。一份安靜的個人檔案無法證明候選人缺乏經驗，一張密密麻麻的貢獻圖也無法證明每個成果都是他寫的。
在允許的範圍內，實際打開儲存庫、issue 或 pull request 來看。找出對方參與的角色、所做的變更、對審查意見的回應，以及這項條件所指的那種決策的證據。不要從星星數、追蹤人數、雇主名稱、程式語言數量或熱門程度去推論資歷。把日期當成脈絡，而不是一個通用的新舊門檻。目前是否有空、有沒有興趣，是另外的問題。
授權和隱私的界線也很重要。GitHub 關於授權的說明指出，公開的儲存庫不代表自動沒有著作權限制；沒有授權條款時，就適用預設的著作權規則。不要只因為頁面是公開的，就把程式碼或個人資料複製到招募紀錄裡。只記錄你的流程允許的、和工作相關的最少量紀錄，並遵守核准的存取和保存規則。英國資訊專員辦公室（ICO）於 2024 年 11 月 6 日發布的招募 AI 指引，強調合法依據、透明、公平，以及只蒐集必要的個人資料。以上是一般資訊，不是法律意見。
用一個虛構的比較來練習
假設需求是：審查並維護一個共用服務，並向協作者說明技術上的取捨。候選人 A 有一個 pull request，修改了這個服務、回應了審查留言，還附上一個測試。對「參與程式碼審查」來說，這是直接證據；但正式環境的負責範圍和成果，仍然需要查證。
候選人 B 維護一個附有文件和 issue 回覆的個人函式庫，但儲存庫看不出共用服務的脈絡。這是相近的證據。可以問對方負責了哪些部分，以及他怎麼處理由團隊共同擁有的變更。候選人 C 出現在一個組織的儲存庫裡，但頁面上看不出他的貢獻。這是未知。請對方提出一個他能說明的具體變更，或改用其他評估方式。
在所有人都經過同樣的檢查之前，不要硬排出更細的名次。記下來源紀錄、標籤、問題和負責人。如果兩位候選人還是分不出高下，就讓他們維持同分，進入下一個可比較的檢查。
Talent Summoner 的定位
Talent Summoner 是我們的產品，提供 AI 人才搜尋、履歷排序，以及經你確認後才送出的候選人聯繫。目前的候選人排序工具（2026 年 9 月 2 日查證）可以貼上或上傳一份職缺說明，加上最多 50 份 PDF、DOCX、MD 或 TXT 格式的履歷，不需要帳號，會交回一份附白話理由的排序入圍名單和可分享的報告。用它來整理履歷審閱；它不會查證儲存庫的作者身分、不會解讀授權權利，也不會決定證據是否達到你的標準。
當現有的人選太少時，人才搜尋（同樣於 2026 年 9 月 2 日查證）會從一份職缺需求說明開始，在 LinkedIn、GitHub 和其他公開專業來源的 2 億份以上個人檔案中搜尋，依必備條件和加分條件交回排序結果，並附上白話理由。被找出來的個人檔案或儲存庫只是一條線索，不能證明負責範圍、是否有空或有沒有興趣。請把證據紀錄和產品的結果放在一起保存。
開源活動能證明候選人做得來這份工作嗎？
不能。它可以提供一份工作紀錄，但負責範圍、工作規模、脈絡和成果可能仍然是未知的。用它來決定要問哪一個查證問題。
沒有公開程式碼的候選人應該被淘汰嗎？
不應該。他的工作可能是非公開的，或是團隊協作的成果。把缺少公開證據視為未知，改用核准的工作樣本或面試問題。
commit 數量或儲存庫熱門程度，適合當排序條件嗎？
它們能提供來源脈絡，但無法證明能力、作者身分或是否適合這份工作。優先採用和核准需求相關的證據，並記下這個來源無法證明的部分。
Talent Summoner 能查證 GitHub 的作者身分或授權嗎？
不能。我們的產品可以找出公開來源的個人檔案，或整理你提供的履歷。檢查來源、釐清貢獻問題、遵守隱私和授權規則，以及做出決定，都必須由你的團隊負責。
挑一項必備條件，替入圍名單上的每位候選人審閱一個相關的儲存庫、issue 或 pull request。記下一份來源紀錄、一個證據標籤和一位查證負責人。接著，如果是你手上已有的履歷，就用候選人排序；如果缺的是找人，就用人才搜尋。
