Chronometrica 與 Orgupdate 比較：為技術職位通知選擇 Google Jobs 收集器

先確定收集需求

一則公開的晶片設計討論詢問，有哪些爬蟲或 API 能尋找技術職位並傳送即時通知。記錄下來的需求包括設計驗證工程師職位、入門級工作，以及 SystemVerilog、UVM 和 SVA 等關鍵字。這是有用的資料收集需求，但其中包含幾項不同的工作。買家討論。

收集器負責尋找職位記錄。職位審查負責判斷每筆記錄是否符合你的規則。歷史記錄檢查會顯示你是否曾見過該職位。通知流程會傳送通過審查的結果。來源刊登時間檢查則幫助你評估雇主可能在何時刊登職位。

選擇產品時，請將這些工作分開處理。查詢中包含「entry level」，不代表每個結果都接受入門級求職者。新收集到的記錄，不代表該職缺是新刊登的。有應徵連結，也不代表雇主仍接受申請。

比較輸入表單前，先寫下簡短的需求。例如：為 1 個城市收集最多 5 個可能合適的設計驗證工程師職位，然後在傳送通知前逐一審查職位描述。這類需求可以由設有上限的收集步驟完成。

「取得多個地點中所有符合條件的職位，且不限制輸出數量」是另一種需求。經查核，Chronometrica 的 `maxItems` 範圍是每次執行儲存 1–1,000 列。如果你原本要求的全部結果超出這個上限，Chronometrica 就不符合需求。一次成功的小規模執行，無法證明收集範圍完整。Chronometrica 輸入結構定義。

比較會影響選擇的控制項

Actor 是託管的資料收集程式。經查核的 Chronometrica Actor 有 4 個輸入欄位：`market`、`queries`、`location` 和 `maxItems`。它的表單適合依職位文字搜尋、使用 1 個共用地點，並審查有限數量結果的流程。Chronometrica 輸入結構定義。

表中的產品事實來自已註明查核日期的公開行為規格證據。Chronometrica、Orgupdate。

這項比較並未證實 Orgupdate 缺少去除重複資料、輸出上限或其他有用的收集功能。它也未證實任何一個產品在速度、價格或可靠性上具有優勢。

改選的條件很簡單：如果 Orgupdate 的內建控制項是必要條件，就選擇 Orgupdate。如果 4 個欄位的表單及文件所載的資料列規格符合需求，就可以放心選擇 Chronometrica。

了解 Chronometrica 的行為規格能提供什麼

Chronometrica 的儲存資料列上限適用於總輸出量，並非每個查詢各有一份額度。Actor 文件說明，各個進行中的查詢會均衡輪流執行，而且每次執行會為每個唯一的 `jobId` 儲存 1 列。摘要包含候選結果、重複結果及停止情況的計數。Chronometrica 產品行為規格。

多個技術職位查詢可能找到同一個職缺，因此這點很重要。對你有用的輸出單位是不重複的職位記錄。候選結果的出現次數是另一種單位。評估一次執行時，請將這些數量分開計算。

均衡輪流執行也不代表保證取得相同數量的結果。某個查詢找到的有用職位可能比另一個少。儲存資料列上限會限制批次大小，但不能證明每個查詢都已完成全面搜尋。

資料列包含 `description`、`postedAtRaw`、`observedAt` 和 `applyOptions`。這些欄位可供後續審查。職位描述提供文字，讓你評估職位是否符合需求。應徵選項則提供途徑，讓你檢查來源職缺。Chronometrica 輸出規格。

這 2 個時間欄位的意義不同。`postedAtRaw` 保留來源中描述刊登多久的文字。`observedAt` 記錄收集時間。這 2 個欄位都不能證明確切的刊登時間，也不能證明傳送通知前的延遲時間。請保留兩者，讓後續步驟能區分它們。Chronometrica 輸出規格。

執行前先訂定接受規則

接受規則應以審查者能核實的條件，說明什麼是有用的職位線索。針對這項技術職位需求，請寫下職位、地點及經驗要求。然後決定哪些技術關鍵字是必要條件，哪些只是用來協助搜尋。

例如，你的規則可能要求職位是設計驗證工程師、工作地點可接受，而且職位描述表明具備你目前經驗程度的求職者可應徵。規則也可能要求具備 SystemVerilog 經驗。這是建議的審查規則，並非對任何傳回職位的事實聲明。

請區分明確不符合條件與證據不足。如果職位要求的經驗超出你設定的範圍，可以判定為不符合規則。如果職位沒有說明經驗要求，就需要進一步審查。缺少的資訊必須維持未知，不能視為通過。

對地點也應同樣仔細審查。判斷所列工作地點是否可接受，以及是否需要更多到場或遠端工作的資訊。經查核的 Chronometrica 表單沒有內建遠端工作篩選條件。此外，`market` 用來選擇 Google 網站和結果語言。它不是嚴格篩選職位所在國家或求職者資格的條件。Chronometrica 輸入規格。

這份簡短的接受規則能讓首次執行產生實際用途。你可以依明確需求計算通過審查的職位線索，而不是只用資料列數量來評斷收集器。

先小規模執行，檢查是否符合需求

Task 是儲存在 Apify 上的一組預設輸入。公開的科技職位招聘 Task可作為起點。已保存的查核記錄顯示，當時可以存取該頁面。但這不能證明它目前儲存的輸入內容。執行前請檢查實際輸入值。

請使用以下簡單方法：

1. 寫下職位、地點及經驗的接受規則。
2. 檢查 Task 的 `market`、`queries`、`location` 和 `maxItems` 值。
3. 執行一個設有上限的小批次，並檢查其 `OUTPUT` 摘要。
4. 審查職位描述及來源應徵連結。
5. 傳送通知前，將通過審查的職位與已儲存的歷史記錄比對。

以下設定是虛構範例。它已根據保存的公開結構定義通過輸入格式檢查。本次比較並未執行這組設定，因此它不能證明目前確實有相關職缺。

{
  "market": "US-en",
  "queries": [
    "design verification engineer SystemVerilog"
  ],
  "location": "Austin, Texas, United States",
  "maxItems": 5
}

經查核的結構定義允許 `market` 使用 `US-en`、查詢項目數量為 1–100、`location` 使用字串，以及 `maxItems` 使用 1 至 1,000 的整數。範例使用完全一致的受支援欄位名稱。Chronometrica 輸入結構定義。

5 列資料可讓首次人工審查維持小規模，但不能構成涵蓋範圍測試。請檢查記錄是否包含足夠證據，讓你套用接受規則。也請檢查應徵選項是否能連到你可評估的職缺。

查詢中的技術關鍵字用來引導搜尋。它們不會強制套用資歷條件，也不保證每個結果都符合你的技能規則。增加關鍵字不能取代審查職位描述。

一併查看資料列與摘要

先查看已儲存的職位，再透過 `OUTPUT` 了解收集數量及停止位置。將儲存資料列總數與你要求的上限比對。分別檢查候選結果和重複結果的計數。Chronometrica 摘要規格。

不要將重複結果數量當成失敗次數。多個查詢可能遇到同一個職位。重點是已儲存的資料列及後續檢查，是否保留正確的職位識別資訊。

在同一次執行中，使用 `jobId` 識別每個已儲存的職位。逐筆審查職位描述、地點證據及目前的應徵選項。需要確認職位細節或是否仍開放應徵時，請開啟來源應徵頁面。將審查結果與收集到的文字分開記錄。

有用的審查可分為 3 種結果：接受、拒絕或尚未確定。請附上簡短理由。尚未確定的職位可能缺少足夠的地點或經驗資訊。在有人完成查核前，請明確保留這項不確定性。

如果來源欄位缺失，就保留缺失狀態。如果不知道職位已刊登多久，不要將它記為 0 天。不要因為缺少應徵資訊，就認定職位已關閉。收集器的資料列是決策證據，本身並不是決策。

用虛構範例檢查各項數量

這個範例是虛構的。它不是 Actor 測試、實際收集的資料集或客戶成果。

一次虛構執行使用多個技術職位查詢，並將儲存輸出上限設為 6 列。收集期間，候選結果共出現 10 次。其中 4 次的 `jobId` 與該次執行已觀察到的結果相同。最後剩下 6 個不重複的職位，並予以儲存。

計算如下：

`10 candidate appearances − 4 duplicate appearances = 6 unique saved jobs`

接著，審查者檢查職位描述及地點。2 個職位不符合書面接受規則。其餘 4 個成為通過審查的職位線索。

`6 unique saved jobs − 2 rejected jobs = 4 accepted leads`

因此，在這次虛構審查中，該次執行產生了 4 個通過審查的職位線索。這不能證明有 6 個新職缺，也不能證明全部 6 個職位都適合入門級求職者。它也未顯示有多少通過審查的職位已存在於儲存的歷史記錄中。

這些區別會影響是否傳送通知的決定。候選結果出現次數，衡量收集期間遇到結果的次數。不重複的儲存資料列數量，衡量同一次執行中不同職位的數量。通過審查的職位線索數量，衡量符合規則的記錄。首次觀察數量，衡量你自己的歷史記錄尚未出現過的職位。

請分別計算這些不同單位的數量。如果後續歷史記錄檢查發現某個通過審查的職位已經儲存，就必須先依歷史記錄作出判斷，才能再次傳送通知。單憑收集總數，無法回答這個問題。

歷史記錄與通知傳送須與收集器選擇分開處理

使用 `jobId` 和 `observedAt` 儲存觀察記錄。每筆觀察記錄都應保留 `postedAtRaw` 及當時的 `applyOptions`。這樣可為歷史記錄步驟提供審查所需的識別資訊、觀察時間、來源中描述職位已刊登多久的文字及應徵途徑。

傳送通知前，將通過審查的記錄與先前的觀察記錄比對。首次觀察表示你的流程從未記錄過該職位。這不能確定雇主首次刊登職缺的時間。

也請訂定流程如何處理有變更的職位記錄。決定哪些變更需要審查，以及哪些變更足以再次傳送通知。請明確寫下規則，避免後續收集在沒有理由的情況下重複傳送通知。

通知傳送需要獨立的成功檢查。儲存了職位，不代表訊息已送達。請分開追蹤傳送狀態，並透過已授權的工作流程傳送通知。現有的最新職位通知指南更詳細說明歷史記錄及重複刊登的處理方法。相關流程檢查可參閱職位資料流程檢查指南。

這項比較涵蓋收集器的選擇。它並未證實來源會即時更新，也未確定通知延遲的最長時間。這些聲明需要完整流程的證據，包括收集時機、審查及傳送。