什麼是 ATS？求職者追蹤系統完整解說

求職者追蹤系統——如果你聽過招募人員使用「ATS」這個縮寫的話——是雇主用來管理其招募管道的軟體。當你在公司的職涯頁面點擊「投遞」並填寫表單時，你就是在向他們的 ATS 提交。當招募人員閱讀你的履歷、發送篩選邀請、安排面試或發送拒絕郵件時，他們都是透過 ATS 進行的。它是你和人類之間的層，而且候選人端的「ATS 最佳化」副業建議很可能誇大了這一層實際過濾的程度。

值得了解你的申請實際經過什麼流程，因為 ATS 的設計影響兩件事：申請表填寫需要多長時間，以及招募人員在另一端如何看到你的履歷。

軟體實際做什麼

ATS 同時負責四項工作。它託管公開的職缺發布——大多數公司網站上的「職涯」頁面是由 ATS 提供的，嵌入在公司的網域或 ATS 的子網域上。它接收申請並將其儲存在結構化資料庫中。它管理招募人員的工作流程：審查履歷、留下筆記、為候選人評分、安排面試、發送範本郵件。它還運行分析——填補時間、招募來源、各階段之間的轉化率、多元化報告，整個招募儀表板。

2026 年的主要 ATS

以下是你作為求職者最常遇到的系統。每個都有可辨識的 URL 模式，使其容易從職涯頁面連結中識別。

Workday

URL 模式：*.myworkdayjobs.com 或帶有 Workday 風格篩選器的 jobs.[company].com。

使用者：大多數大型企業（Fortune 500、大型上市公司、跨國製藥、銀行、專業服務公司）。

求職者體驗：繁重。長表單、頻繁的「建立帳戶」要求、多步驟申請流程。Workday 是為招募人員而非求職者設計的。

公開數據暴露：不穩定。部分 Workday 租戶會輸出 JSON-LD 結構化資料；許多不會。我們關於 JSON-LD JobPosting 的文章涵蓋了對監控的影響。

Greenhouse

URL 模式：boards.greenhouse.io/[company] 或 [company].greenhouse.io。

使用者：中端科技公司（歷史上的 Stripe、Airbnb 等級公司），B 輪到上市階段的新創，注重人力資源的現代企業。

求職者體驗：輕量。簡短表單、清晰的階段、合理的預設值。

公開數據暴露：出色。每個公開職缺都有乾淨的 JSON-LD 結構化資料，這就是為什麼 Greenhouse 的職缺能快速出現在 Google Jobs 上。

Lever

URL 模式：jobs.lever.co/[company]。

使用者：中端科技，與 Greenhouse 客戶類似的特徵。歷史上偏好設計感的公司。

求職者體驗：輕量，公開職缺頁面比 Greenhouse 更乾淨。

公開數據暴露：非常好。每個頁面都有 JSON-LD。

Ashby

URL 模式：jobs.ashbyhq.com/[company] 或 [company]/jobs。

使用者：高成長新創，A 輪到 C 輪，主要是科技和注重設計的公司。自 2023 年以來持續從 Greenhouse 和 Lever 搶奪市佔率。

求職者體驗：主要 ATS 中最輕量。簡短的申請流程，更少的必填欄位。

公開數據暴露：出色。乾淨的結構化資料和維護良好的網站地圖。

Phenom

URL 模式：通常嵌入雇主網域（URL 中沒有明顯的「phenom」），但可在頁面原始碼中看到。

使用者：大型企業，尤其是那些想在招募後端之上疊加品牌化職涯體驗的企業。

求職者體驗：因雇主客製化而差異很大。有些很優秀；有些比原始 Workday 更差。

公開數據暴露：良好。Phenom 通常輸出比一般系統更豐富的 JSON-LD。

iCIMS

URL 模式：careers-[company].icims.com 或嵌入雇主網域。

使用者：傳統大型企業，尤其在醫療、零售和製造業。

求職者體驗：繁重。通常需要建立帳戶。

SmartRecruiters

URL 模式：jobs.smartrecruiters.com/[company] 或 careers.[company].com。

使用者：中大型企業，特別是歐洲總部的企業（該公司最初是歐洲的）。

求職者體驗：中等。夠乾淨，但不如 Greenhouse 或 Ashby 輕量。

SAP SuccessFactors

URL 模式：career[X].successfactors.com 或嵌入雇主網域。

使用者：大型傳統企業，尤其是使用 SAP 處理更廣泛人力資源體系的企業。

求職者體驗：繁重。通常是所有主要 ATS 中摩擦最大的。

Oracle Taleo

URL 模式：URL 中以某種形式包含 taleo。

使用者：大型企業中日益縮小的份額，主要是那些運行 Oracle HCM 的企業。到 2026 年被視為舊系統，但仍然廣泛部署。

求職者體驗：過時。幾乎總是需要建立帳戶。許多候選人講述的「最糟糕的求職申請體驗」都是指某個 Taleo 實例。

ATS 實際如何處理你的申請

你點擊「投遞」後的高層流程：

1. 表單接收。你的輸入進入結構化資料庫。履歷被解析（準確度不一）為結構化欄位：姓名、聯絡方式、工作經歷、教育背景。
2. 淘汰問題。如果職缺有淘汰問題（「你是否有在英國工作的資格？」、「你是否有 5 年以上的 Java 經驗？」），回答「否」的求職者可能被自動淘汰。這是最接近「ATS 拒絕你」的情況，而且是基於你明確的是／否回答，而非履歷解析。
3. 可選的評分。部分 ATS 會根據關鍵字匹配和先前的訊號套用自動評分。這在 2026 年越來越普遍，但仍非所有地方的預設值。
4. 招募人員審查。申請進入招募人員的隊列。他們按順序審查（我們在關於審查順序的文章中涵蓋了例外情況）。
5. 階段推進。如果進入候選名單，申請會經過各個階段（篩選、技術面試、現場面試、錄取通知）。每個階段都有自己的狀態、溝通範本和時間線。

「ATS 最佳化」的迷思與現實

圍繞「對 ATS 友善的履歷」建議有一整個副業產業，誇大了 ATS 本身過濾的程度。以下是什麼是對的、什麼是錯的。

迷思：「如果你的履歷不匹配關鍵字，ATS 會拒絕你。」

現實：大多數現代 ATS 不會根據關鍵字自動拒絕。Workday、Greenhouse、Lever、Ashby、SmartRecruiters 和 Phenom 都預設將每份申請呈現給招募人員。淘汰問題可以自動拒絕，但那些是你填寫的明確是／否欄位。

迷思：「你需要特殊的對 ATS 友善的履歷格式。」

現實：一份乾淨的、單欄式的履歷，使用正常文字（沒有圖片、沒有圖片中的文字、沒有奇特字體），在每個主要 ATS 中都能正確解析。有兩欄、側邊欄或以圖片形式呈現文字的高度設計履歷可能解析不良，如果招募人員依賴解析後的視圖而非原始 PDF，這可能會傷害你。使用單欄設計，儲存為 PDF，就沒問題了。

迷思：「ATS 無法讀取 PDF。」

現實：每個主要的現代 ATS 都能讀取 PDF。有些仍然略微偏好 Word 文件，但差異很小。

現實：與職位描述的關鍵字重疊確實有幫助，但是為了招募人員，而非 ATS。

招募人員在 20 分鐘內瀏覽 50 份履歷。如果職位描述中的關鍵字在你履歷的上三分之一處可見，你在 5 秒內就被認為「明顯適合」。如果相同的內容被埋在底部的長篇散文段落中，你被認為「也許適合，我回頭再看」，而通常不會有第二次機會。

這對你的投遞策略意味著什麼

實際的含義：

1. 透過公司自己的 ATS 投遞，而非聚合網站的包裝。LinkedIn 上的「輕鬆投遞」提交在大多數公司會進入一個單獨的、較低優先級的堆疊。直接 ATS 提交進入主要隊列。我們對 LinkedIn、Indeed 和直接 ATS 的比較涵蓋了摩擦的權衡。
2. 不要害怕繁重的 ATS（Workday、Taleo、SuccessFactors）。是的，表單很長。申請仍然會到達一位真人招募人員，他會閱讀它。完成一次表單，儲存你的帳戶，然後在同一家公司的未來申請中重複使用。
3. 事先用 URL 辨識 ATS。如果你投遞很多職缺，知道你即將填寫 5 個欄位的 Greenhouse 表單還是 40 個欄位的 Workday 表單，讓你可以把後者批次處理到一個工作階段中。
4. 直接監控權威 ATS 上的新職缺。直接職涯頁面監控在即時性上勝過聚合網站提醒；對於早期新創和 YC 公司，我們關於早期新創工作的文章涵蓋了更快浮出職缺的管道。

重點總結

ATS 作為把關者的作用比圍繞它的副業產業所暗示的要小。它很少自動拒絕，它能正常讀取 PDF，而你的申請幾乎總是會到達一位在不到 30 秒內瀏覽它的真人。重要的是那 30 秒的瀏覽是否落在你履歷中匹配職缺要求的部分——這是一個人類問題，不是演算法問題。

從這篇文章中更有用的收穫是 URL 辨識技巧。一旦你知道 Workday 意味著繁重的表單、Greenhouse 意味著輕量的表單，Ashby 結構良好、Taleo 是另一個時代的產物，你就可以相應地規劃你的投遞工作階段——而且你可以透過 ATS 直接監控特定雇主，而非等待 LinkedIn 跟上。我們的早期投遞完整指南涵蓋了其餘的流程。

---

← 返回部落格  ·  免費開始 →