職缺公告能證明公司已準備好購買你的產品嗎？

蒐集職缺前，先定義公司的問題

搜尋之前，先寫下簡短的研究準則。內容應包括客戶類型、你的產品或服務所處理的問題，以及可能使該問題值得查核的職責。

將問題與產品名稱分開。維護報表的職責，可以支持你提出關於報表工作的問題。但僅憑這項職責，不能判定報表有問題，也不能判定公司需要你的產品。

請依照以下步驟：

1. 定義你想研究的公司類型。
2. 說明你的產品或服務所處理的工作問題。
3. 列出可能與該問題有關的職責。
4. 說明哪些證據會削弱兩者的關聯。
5. 寫下透過公開資料研究可以回答的下一個問題。

第四步可避免你將每個相關職缺都當成支持證據。例如，某項職責可能只是既有流程中的例行工作，而該流程本來就運作良好。在整個檢視過程中，都要保留這種解釋。

研究成果是一份公司研究摘要。這裡的「客戶帳戶」是指正在檢視的公司。摘要簡短記錄來源事實、可能的解釋、缺少的事實，以及下一項查核。它不是銷售預測。

選擇少量且固定的研究樣本

研究樣本組是依照相同搜尋準則選出的職缺集合。蒐集前，先固定職務、地點、公司篩選準則與檢視日期。樣本組要夠小，讓你能逐一閱讀職務說明，並手動查核公司背景。

記錄搜尋輸入與蒐集限制。限制會影響你能觀察到的內容。小規模搜尋可以找到供檢視的紀錄，但不能證明你已找到所有相關公司。

不要用傳回的職缺數量判定公司需求有多強。多則職缺可能重複相同資訊。一則職缺也可能包含多項職責。這兩種數量都不能衡量已聘用人數或購買決策。

如果你的問題變成職缺數量是否隨時間改變，請改用另一種方法。定期擷取職缺快照指南 說明了這項不同的工作。這份摘要應聚焦於一個公司問題，以及值得進一步查核該問題的證據。

蒐集來源紀錄，但不要把工具當成分析人員

Actor 是在代管環境執行的資料蒐集程式。Task 是為 Actor 儲存的一組輸入設定。LinkedIn Jobs Scraper Actor 的文件列有適合本方法蒐集步驟的輸入與輸出欄位。它不會替你完成公司研究摘要。

提供的查核結果顯示，公開預設建置版本 `0.2.26` 宣告了下方使用的欄位。結構定義是對可接受欄位與資料類型的規定。靜態結構檢查確認範例輸入符合該定義。這項檢查沒有執行 Actor，也沒有測試實際結果。它不能證明目前資料可用、涵蓋完整，或能成功蒐集。公開預設建置版本——查核日期為 2026 年 10 月 25 日；僅有結構定義證據；未實際執行。

可使用以下建議的小規模輸入設定：

{
  "fetchJobDetails": true,
  "location": "United States",
  "maxItems": 3,
  "maxPagesPerSearch": 1,
  "saveOnlyUniqueItems": true,
  "searchTerm": "Salesforce administrator"
}

將 `searchTerm` 改為符合研究準則的職務。將 `location` 改為你的目標市場。第一次蒐集應維持小規模。範例將項目上限設為 `3`，搜尋頁數上限設為 `1`。這些是輸入限制，不是觀察結果，也不保證會傳回三筆紀錄。

範例透過 `fetchJobDetails` 要求取得職缺詳細資料。它也將 `saveOnlyUniqueItems` 設為 `true`。將收到的紀錄視為不同證據前，請先檢視內容。這項設定不能證明紀錄代表不同的公司問題或不同的購買訊號。

公開的 LinkedIn Jobs Hiring Signals for B2B Sales Leads Task 可作為起點。其頁面於 2026 年 10 月 25 日存在，並列有 Task ID `ef48MV6KmGoveTRcE`。目前儲存的設定與執行時的行為仍未經驗證。上方輸入是建議的替代設定，不是已驗證之儲存設定的副本。本指南沒有報告任何 Actor 執行結果。

分開儲存來源欄位與研究筆記

保留蒐集紀錄的原貌。將你的解讀另寫在研究筆記中。這能讓其他讀者區分來源原文與你的結論。

已查核的建置版本宣告了以下輸出欄位。宣告欄位不代表每筆紀錄都會包含有用的值。有幾個欄位允許 `null`，表示未提供值。

這些欄位來自已查核的公開建置版本。下方的摘要欄位是手動研究筆記，並非宣稱由 Actor 輸出的內容。公開預設建置版本——查核日期為 2026 年 10 月 25 日；僅限宣告的欄位類型。

如果公司頁面沒有註明日期，請寫「未註明日期」。保留你的查核日期。最近查核過，不代表頁面內容是最近發布的。

閱讀職責並查核公司背景

對每家公司，請依照以下順序：

1. 閱讀職務說明，不要直接將職稱當作研究發現。
2. 逐字複製一項相關職責。
3. 寫下該職責能支持、範圍最小的觀察。
4. 從另一個公開來源尋找公司背景。
5. 記錄背景資料來源、註明的日期與查核日期。
6. 說明該背景資料是否改變你的研究問題。

保留工具、專案與職責的原始措辭。工具名稱可能出現在不同語境中。它可能描述一項要求、該職位將執行的工作，或應徵者應具備的經驗。不要將每次提及都視為已安裝該軟體的證據。

盡可能在公司官方頁面查核背景資料。確認頁面涉及同一家公司。不要只因名稱相似，就將職缺公告與頁面連結起來。如果兩者關係仍不明確，摘要就應保留為尚無定論。

來自另一個來源的背景資料，也需要查核相關性。一則註明日期的辦公室公告，可能只能證明公司曾宣布設立辦公室。它不能證明報表出現問題、公司購買軟體，或專案預算已獲批准。除非來源明確指出缺少的事實，否則應以問題形式記錄兩者的關聯。

第二個頁面可能只是重複第一個來源。請明確記錄這種關係。兩個網址不會自動成為兩項獨立佐證。請記錄每項資料增加了什麼資訊。

做決定前，先比較其他解釋

研究假設是仍須查核的可能解釋。寫法應容許它被證明有誤。例如，可以問某項明列的職責，是否與尚未解決的報表問題有關。除非有來源支持，否則不要寫成公司需要替代產品。

在假設旁列出其他合理的解釋：

這些都是需要調查的其他解釋。即使解釋合理，職缺公告也不能因此證明其中任何一項。

選擇能區分這些解釋的待驗證問題。「哪個報表問題尚未解決？由誰負責？」比購買機率評分更有用。這個問題指出缺少哪些事實，並未假裝已經衡量過它們。

不要用公司研究摘要聲稱你知道未公開的招募意圖。如果問題改為公開職缺查核能如何協助判斷可能的幽靈職缺，也就是可能沒有實際招募打算的職缺，請使用公開職缺查核指南。這與公司是否值得進行產品相關研究，是不同的問題。

完成一份虛構公司的研究摘要

原創虛構教學範例。Cedar Ops、其職務說明、公司頁面，以及本節所有研究發現均為虛構。這不是 Actor 執行結果、客戶成果，也不是對真實公司觀察所得的發現。

Cedar Ops 刊登 Salesforce 管理員職缺。虛構的職責段落寫道：「維護報表並支援使用者。」另一個註明日期的公司官方頁面，介紹了一間新的區域辦公室。研究所涉及的產品或服務與報表工作有關。

這項職責支持對日常營運工作的觀察。辦公室頁面提供公司背景。兩個來源都沒有指出報表流程存在問題，也都沒有指出有供新供應商使用的預算。

這項計算以證據項目為單位：

1 則來源職缺公告 + 1 個獨立的公司頁面 = 2 項證據。

這不等於兩個購買訊號。它不能確定預算金額，也不能預測轉換率。轉換率是特定群體達成某項結果的比率，因此必須先定義結果與計算所涵蓋的群體。這份虛構摘要兩者都未提供。

職缺公告也沒有告訴我們公司將聘用多少人。在這裡，一則職缺公告就是一項來源資料，不代表已確認聘用一人。

Cedar Ops 仍列為「需要研究」。下一步是手動搜尋有關報表問題及其負責人的公開證據。如果搜尋沒有找到有用資訊，請記錄查核過哪些內容，並將問題保留為未知。不要因為搜尋沒有結果，就斷定問題不存在。

明確記錄缺少的事實與失敗的查核

對尚未完成的工作，請留下明確註記。空白儲存格無法顯示你是已查核事實、無法存取資料，還是忘記查核。

1. 缺少職務說明：如有職缺來源參照，請保留。不要從職稱推斷職責。
2. 公司身分不明：公司之間的對應關係應保留為尚無定論。不要借用名稱相似公司的背景資料。
3. 公司頁面未註明日期：記錄「未註明日期」。不要將查核日期當成發布日期。
4. 蒐集或頁面存取失敗：記錄失敗情況。這不代表相關職缺為零，也不代表公司活動為零。
5. 蒐集結果為空：記錄這次蒐集未傳回任何資料列。這不能證明沒有符合條件的職缺公告。
6. 蒐集受輸入設定限制：將限制與紀錄放在一起。不要將結果稱為完整涵蓋。
7. 證據互相衝突：保留兩項資料並說明衝突。不要未加說明就選用較有利的主張。
8. 預算未知：請寫「未知」，不要寫零。未知的預算與明列的職責，都無法提供購買日期。

將公開證據與僅限擁有者存取的紀錄分開。本方法使用公開職缺公告與公司公開頁面。它不提供私人客戶帳戶紀錄、收件匣內容、應徵者狀態，或補充的聯絡人資料。除非另有經授權取得的證據予以確認，否則公司內部預算核准情況與購買計畫仍屬未知。

文件記載的蒐集功能，也不同於經過測試的結果。已查核的結構定義支持建議的輸入設定與保留欄位。提供的資料中，沒有實際執行測試能證明可蒐集的資料量、目前執行是否正常，或研究成果優於手動檢視。