# Chronometrica 與 Kaix 比較：哪個 Naukri Actor 適合你的公開職缺資訊流？ 如果你的印度公開職缺資訊流需要有明確範圍與上限的關鍵字、地點和經驗搜尋，以及有文件說明的職缺資料列和執行摘要，可選 Chronometrica。經核對，其表單適合小型資訊流，並能嚴格限制儲存的資料列數。Actor 是託管式資料收集程式。應用程式介面，簡稱 API，讓你的軟體能請求取得資料。[Chronometrica Actor](https://apify.com/chronometrica/naukri-jobs-scraper) 如果你需要直接以職缺 URL 或 ID 查詢、搜尋實習或校園徵才職缺，或使用更細緻的 Naukri 分類與篩選模式，可選 Kaix。這是會改變推薦選擇的主要條件。[Kaix Actor](https://apify.com/kaix/naukri-jobs-scraper) 先確定資訊流必須收集什麼。要發掘少量職位的職涯入口網站，與已持有特定職缺 ID 的服務，需求並不相同。比較輸入表單之前，先定義需求。 Chronometrica 發布本篇比較，也營運文中推薦的 Actor。產品事實來自 2026 年 10 月 20 日擷取的公開文件與結構描述。本文未進行實際執行的比較。推薦依據是經核對的輸入與輸出，不是實測的速度、成本或準確度。 ## 職涯入口網站需要從這篇比較得知什麼 Reddit 上有一則公開提問，詢問是否有現成 API，可為業餘專案的職涯入口網站提供印度職缺刊登資料。這個需求帶出一個實用問題：網站擁有者能否透過資料收集服務取得所需資料，而不必自行建立爬蟲？爬蟲是從網站收集資料的程式。這則提問並未證明使用者偏好哪個供應商、服務涵蓋所有雇主，或使用者有權重新發布職缺說明。[原始職涯入口網站提問](https://www.reddit.com/r/developersIndia/comments/1szvizh/is_there_any_public_api_for_indian_job_listing/) 做這項選擇時，請將系統必須完成的工作分成 3 項。首先，找出相關職缺刊登資料。接著，儲存每筆觀察到的刊登資料，並保留足夠資訊以供檢查。最後，決定哪些事實可以顯示，以及何時再次檢查。 Actor 協助收集資料。你的入口網站仍需要儲存、審查和顯示資料的規則。因此，API 請求成功還不足以代表結果有用。回傳的資料列必須符合你的必要欄位要求。你也必須知道資料收集為何停止。 本文協助你在這 2 個 Actor 之間做選擇。如需現有的 API 請求方法，請參閱[如何透過 API 收集 Naukri 公開職缺刊登資料](/zh-Hant/articles/%E9%80%8F%E9%81%8E-api-%E6%94%B6%E9%9B%86-naukri-%E5%85%AC%E9%96%8B%E8%81%B7%E4%BD%8D/)。 ## 先比較資料收集模式 資料收集模式，是你要求程式尋找職缺刊登資料的方式。比較可用欄位數量之前，先決定需要哪種模式。 | 選擇要點 | Chronometrica | Kaix | | --- | --- | --- | | 發掘職缺 | 精簡的關鍵字、地點、經驗與刊登時間搜尋 | 關鍵字與地點搜尋，提供更廣泛的篩選條件 | | 已知的職缺刊登資料 | 本次核對確認其適合透過搜尋發掘職缺 | 分別提供 `jobUrls` 與 `jobIds` 查詢模式 | | 控制設定 | `searchDepth` 與共用的 `maxItems` | 公司、工作模式、實習／校園徵才與分類 ID | | 輸出 | 有文件說明的職缺資料列與執行摘要 | `fetchDetails` 區分核心欄位與完整詳細資料 | 此表依據經核對的 [Chronometrica 文件](https://apify.com/chronometrica/naukri-jobs-scraper)與 [Kaix 文件](https://apify.com/kaix/naukri-jobs-scraper)。分類 ID 用來識別 Naukri 分類系統中的類別。 針對上述精簡搜尋需求，Chronometrica 明確適用。文件所列的控制設定，讓你能指定職位、地點、經驗和刊登時間，再限制儲存的資料列數。如果必要的資料收集模式需要更完整的表單，表單的廣度才會影響選擇。表單精簡本身，不能證明資料涵蓋範圍較佳。[Chronometrica 輸入文件](https://apify.com/chronometrica/naukri-jobs-scraper) 此表用來協助這項特定選擇，並非完整功能清單。表中未記載某項功能，不代表該功能不存在。 ## 為何 Chronometrica 適合有明確上限的職缺發掘資訊流 Chronometrica 的文件列有 `searchTerm`、`location`、`experienceYears`、`postedWithinDays`、`sortBy`、`searchDepth` 和 `maxItems`。這些欄位為小型入口網站提供明確的搜尋表單，適合能在執行前界定資料收集範圍的網站。[Chronometrica 輸入文件](https://apify.com/chronometrica/naukri-jobs-scraper) 儲存的資料列包含 `jobId`、`jobUrl`、`title`、`companyName`、`location`、`descriptionText`、`skills`，以及可取得的薪資與經驗資訊。每次執行時，Chronometrica 對每個觀察到的不重複 `jobId` 儲存 1 筆資料。缺少的公開資訊維持為 `null`。這個值表示該資訊未知或無法取得。[Chronometrica 輸出文件](https://apify.com/chronometrica/naukri-jobs-scraper) 這種資料列結構，是小型入口網站實用的起點。網站可以識別職缺刊登資料、保留來源連結，並記錄哪些資訊需要審查。職缺 ID 用來識別觀察到的刊登資料，不能證明應徵頁面仍然有效。 共用上限讓資料收集限制更明確。`maxItems` 在篩選與移除重複資料後套用，限制整次執行所儲存的資料列總數。它不會為每個關鍵字分配個別額度。如果你的計畫假設每個關鍵字都有個別額度，請先修改計畫，再收集資料。[Chronometrica 儲存資料列上限](https://apify.com/chronometrica/naukri-jobs-scraper) `searchDepth` 提供 `standard`、`extended` 和 `deep` 等收集力度等級。較高設定不保證取得所有職缺，也不保證資料品質更好。請用此設定選擇收集力度，再檢查儲存的觀察資料。[Chronometrica 搜尋控制設定](https://apify.com/chronometrica/naukri-jobs-scraper) 這些經核對的功能，支持將它推薦用於有明確上限的職缺發掘。它們不能證明成本較低、執行較快，或資料涵蓋完整。 ## 用小規模輸入檢查是否適用 公開的 [Naukri Jobs API Dataset Task](https://apify.com/chronometrica/naukri-jobs-scraper/examples/naukri-jobs-api-dataset) 提供起始預設。Task 是為 Actor 儲存的輸入預設。使用前，請檢查它目前的實際輸入。記錄中的頁面檢查回傳 HTTP 200，表示頁面回應成功。該檢查並未驗證目前儲存的設定。 這個虛構查詢提供一個小規模驗收範例。驗收檢查用來判斷結果是否符合你列明的需求。 ```json { "searchTerm": "data engineer", "location": "Bengaluru", "experienceYears": 3, "postedWithinDays": "7", "searchDepth": "standard", "maxItems": 5 } ``` 用小規模輸入檢查是否適用 這組輸入已在本機通過快取的公開 JSON Schema 檢查。JSON Schema 定義允許的輸入欄位、值類型與限制。所有提供的欄位名稱都存在於該結構描述中。檢查結果支持這組輸入的結構，但不能證明即時來源可用，也不能預測會儲存多少資料列。本範例未執行 Actor。[Chronometrica 公開結構描述](https://apify.com/chronometrica/naukri-jobs-scraper) 請保留範例所示的值類型。`searchTerm` 和 `location` 是字串，也就是文字值。`experienceYears` 是 0 至 30 的整數。整數是沒有小數部分的數。`maxItems` 是至少為 1 的整數。此處 `postedWithinDays` 使用字串 `"7"`，`searchDepth` 使用 `"standard"`。這些提供的值已通過快取結構描述的檢查。[Chronometrica 輸入結構描述](https://apify.com/chronometrica/naukri-jobs-scraper) 這個查詢要求 3 年經驗。你仍必須將每筆回傳的職缺刊登資料所列要求，與這個值逐一比較。刊登資料可能列出經驗範圍，或在文字中包含其他條件。僅憑請求的值，不能證明每個回傳職缺都適合。 ## 進行 5 項驗收檢查 收集資料前，先寫下預期結果。資料集即使有資料，也只有在資料列能支援預定資訊流時才有用。請用以下檢查，判斷所選 Actor 是否符合需求。 1. 定義搜尋條件與必要欄位。列明職位、地點、經驗和刊登時間。列出入口網站識別及評估刊登資料所需的資訊。將資料收集需求，與顯示及重新發布的決定分開處理。例如，如果網站保留薪資未知的狀態，薪資未知可能可以接受。 2. 選擇資料收集模式。確定你需要發掘職缺刊登資料，還是取得一組已知資料。選擇 Actor 前，先套用開頭所述會改變推薦選擇的條件。不要假設反覆進行廣泛搜尋，就能找回每筆已知的刊登資料。 3. 設定較小的共用儲存資料列上限。檢查 Task 目前的輸入，並與 Actor 表單比較。只有在範例設定符合需求時才套用。將上限記錄為整次執行的總額，不要乘以關鍵字數量。 4. 審查資料列與執行摘要。檢查重複的 `jobId`、職缺來源 URL、可取得的薪資與經驗文字，以及缺少的欄位。閱讀 `OUTPUT` 摘要，了解停止原因。將結果與書面需求比較，包括是否因達到上限而停止收集。[Chronometrica 輸出文件](https://apify.com/chronometrica/naukri-jobs-scraper) 5. 顯示前檢查來源。開啟來源應徵頁面，檢查目前狀態。發布資訊流前，審查適用的來源條款。缺少的資訊維持為 `null`。在自己的儲存系統中附上觀察時間，以便知道資料何時收集。 這些檢查可導出 3 種實用決定：接受精簡搜尋、修改需求，或評估其他模式。如果模式明顯不符，就不需要大規模測試。即使模式適合，在將輸出接上公開資訊流之前，仍須審查資料列。 如果缺少必要資訊，請將這項發現與資料列數量分開記錄。儲存了 5 筆資料列，不代表符合 5 筆可用資料列的要求，因為其中可能有資料列缺少網站所需欄位。評估結果前，先決定哪些欄位缺失可以接受。 ## 算式經核對的虛構決策範例 假設有一個虛構的職涯入口網站，希望取得少量班加羅爾資料工程職缺刊登資料。它接受薪資未知，但要求有來源 URL，並將這次收集限制為儲存 5 筆不重複的刊登資料。 在這個虛構範例中，候選職缺刊登資料在收集過程中共出現 8 次，其中包含重複出現的情況。有 3 次是重複出現，其 `jobId` 與同一次收集中已透過另一個關鍵字儲存的值相同。移除這些重複項目後，剩下 5 筆不重複的職缺刊登觀察資料： `8 candidate appearances − 3 duplicate appearances = 5 unique job rows` 算式已核對，數量則是虛構的。此範例不是 Actor 測試、即時資料集、買家引述，也不是實測成本結果。 網站儲存每筆資料列的來源 URL，之後再檢查應徵頁面是否仍然有效。它也記錄觀察時間，並註明缺少的資訊。這讓網站能評估儲存的資料列，並將主張限制在觀察資料能支持的範圍內。 5 筆不重複的資料列，不代表 5 個雇主或 5 個仍在招募的實際職缺。這些資料列也不能證明有權重新發布完整職缺說明。這些決定需要個別檢查。 針對這項有明確上限的職缺發掘需求，Chronometrica 符合選擇規則。網站因此有明確依據，可收集少量觀察到的刊登資料，再進行審查。 現在更改這個虛構需求。網站已持有 5 個特定職缺 ID，需要取得其詳細資料。它應評估 Kaix 的直接查詢，而不是透過發掘搜尋，再次尋找這些記錄。[Kaix 查詢模式](https://apify.com/kaix/naukri-jobs-scraper) ## 儲存觀察資料時，避免多算實際職缺 在自己的系統中使用職缺觀察資料表。每次執行內，以 `jobId` 作為資料列的鍵。鍵是儲存系統用來區分資料列的值。保留標準來源 URL，也就是該刊登資料的主要來源網址。註明所有缺少的欄位。 附上系統觀察到資料的時間。這是儲存方式的建議，並非宣稱 Actor 提供某個特定的時間戳記欄位。將收集記錄，與之後是否在入口網站顯示該職缺的決定分開處理。 重複觀察不會新增一個實際職缺。如果相同刊登資料再次出現，請記錄再次看到它。不要只因它出現在另一個搜尋結果中，或在另一個日期再次出現，就增加不重複刊登資料的數量。 保留資訊未知的狀態。缺少薪資，不代表薪資為 0。缺少經驗資訊，不代表要求 0 年經驗。用數字取代未知值，會產生錯誤資訊。 這種儲存方式，讓工具選擇的價值不只限於第 1 次請求。入口網站在儲存、計數和顯示資料列時，必須保留所收集資料的原意。 ## 何時這項推薦不再適用 Chronometrica 的儲存資料列上限，讓收集範圍更明確。但這不能證明儲存的資料列包含每筆符合條件的刊登資料。如果原始需求是儲存所有結果，而結果數量超過設定上限，Chronometrica 在該設定下就無法符合需求。[Chronometrica 儲存資料列控制設定](https://apify.com/chronometrica/naukri-jobs-scraper) 提高上限不能證明完整涵蓋來源資料，提高 `searchDepth` 也不能。經核對的證據無法證明完整性。評估工具時，請保留取得所有結果的原始要求。不要以較小樣本取代該要求，再宣稱已符合需求。 每項驗收檢查回答的問題都不同。有效輸入具有允許的結構。儲存的資料列記錄了一次觀察。檢查過的應徵頁面，提供該頁面在審查當時的狀態證據。任何一項檢查，都無法單獨回答這 3 個問題。 Chronometrica 是獨立的 Actor API，並非 Naukri 官方 API。資料公開可取得，也不代表擁有不受限制的重新發布權利。顯示資訊流之前，請保留來源連結，並審查適用的來源條款。[Chronometrica Actor](https://apify.com/chronometrica/naukri-jobs-scraper) ## 有明確上限的職缺發掘資訊流，可選 Chronometrica 如果精簡的關鍵字、地點、經驗與刊登時間搜尋符合需求，可選 Chronometrica。經核對的搜尋欄位、有文件說明的職缺資料列，以及執行摘要，都支持這項選擇。做決定時，請保留會改變推薦選擇的必要條件，以及取得所有結果的限制。 開啟 [Chronometrica Naukri Jobs Scraper](https://apify.com/chronometrica/naukri-jobs-scraper)，開始為資訊流收集有明確範圍與上限的資料。使用上述驗收方法，判斷儲存的觀察資料是否符合入口網站的要求。 ## 來源與延伸閱讀 - [Chronometrica Naukri Jobs Scraper — 自營 Actor 的文件與公開 JSON Schema；快取建置版本 1.0.24；證據擷取於 2026 年 10 月 20 日；支持文中所述的輸入、職缺資料列、共用上限與執行摘要；範例輸入已通過本機結構描述檢查；未實際執行 Actor，也未進行同條件效能測試](https://apify.com/chronometrica/naukri-jobs-scraper) - [Kaix Naukri Jobs Scraper — 替代 Actor 的文件與結構描述；快取建置版本 0.1.15；於 2026 年 10 月 20 日核對；僅依據文件記載的模式，未進行實際執行的比較](https://apify.com/kaix/naukri-jobs-scraper) - [Naukri Jobs API Dataset Task — 公開起始預設；2026 年 10 月 20 日的證據記錄了 HTTP 200 頁面回應；未驗證目前儲存的輸入，使用前必須檢查；未為這份研究概要執行此 Task](https://apify.com/chronometrica/naukri-jobs-scraper/examples/naukri-jobs-api-dataset) - [印度公開職缺刊登資料 API 提問 — 儲存的完整貼文支持業餘專案職涯入口網站的需求；收錄於 2026 年 10 月 20 日的證據；不能證明對特定供應商的需求、完整雇主涵蓋範圍、重新發布許可，或經驗證的效能基準](https://www.reddit.com/r/developersIndia/comments/1szvizh/is_there_any_public_api_for_indian_job_listing/)