截至 2026 年 4 月，GitHub 上搜尋「linkedin scraper」大約會出現 。但大多數只會浪費你的時間。 很毒舌？也許吧。但這是我審核了 8 個最顯眼的 repo、閱讀數十串 GitHub issue 討論，並交叉比對 Reddit 與爬蟲論壇社群回報後得出的結論。模式一再重演：高星 repo 吸引注意力，LinkedIn 的反機器人團隊研究程式碼，偵測機制被修補，最後使用者只剩壞掉的 selector、CAPTCHA 迴圈，或直接帳號被封。某位 Reddit 使用者很直接地描述現況——LinkedIn 已加入「更嚴格的速率限制、更好的機器人偵測、工作階段追蹤，以及頻繁變動」，而舊工具現在不是「很快失效」，就是「帳號／IP 被標記」。如果你是業務、招募或營運管理者，只是想把 LinkedIn 資料放進試算表裡，那你上個月 clone 的 repo 可能早就不能用了。這份指南的目的，是幫你判斷哪些 GitHub 專案真的值得花時間、如何避免把帳號燒掉，以及什麼時候乾脆跳過程式碼最划算。
GitHub 上的 LinkedIn 爬蟲是什麼？
GitHub 上的 LinkedIn 爬蟲專案，通常是開源腳本——多半是 Python，有時候是 Node.js——用來自動化擷取 LinkedIn 頁面上的結構化資料。常見目標包括：
- 個人檔案：姓名、職稱、公司、地點、技能、經歷
- 職缺列表：標題、公司、地點、發佈日期、職缺網址
- 公司頁面：簡介、人數規模、產業、追蹤者數
- 貼文與互動：內容文字、按讚、留言、分享
在底層，大多數 repo 會採用兩種方法之一。瀏覽器驅動型爬蟲依賴 Selenium、Playwright 或 Puppeteer 來渲染頁面、模擬點擊流程，並透過 CSS selector 或 XPath 擷取資料。另一小部分則嘗試直接呼叫 LinkedIn 內部未公開的 API 端點。還有一波較新的做法——GitHub 上仍不算常見，但正在增加——會把瀏覽器自動化和像 GPT-4o mini 這類 LLM 搭配，直接將頁面文字解析成結構化欄位，而不用脆弱的 selectors。
這裡有個根本性的受眾錯配。這些工具是給熟悉虛擬環境、瀏覽器依賴與 proxy 設定的開發者設計的。但搜尋「linkedin scraper github」的人裡，有很大一部分其實是招募人員、SDR、RevOps 經理和創辦人，他們只想要試算表中的幾列資料。
這個落差，也解釋了 issue 討論串裡大多數的挫折感。
為什麼大家會轉向 GitHub 來做 LinkedIn 爬取
吸引力很明顯。免費、可自訂、沒有供應商綁定、對資料管線有完整控制權。如果 SaaS 工具改了價格或停服，你的程式碼還在。
| 使用情境 | 需要的人 | 常見擷取資料 |
|---|---|---|
| 潛在客戶開發 | 業務團隊 | 姓名、職稱、公司、個人檔案網址、Email 線索 |
| 人才搜尋 | 招募人員 | 個人檔案、技能、經歷、地點 |
| 市場研究 | 營運與策略團隊 | 公司資料、人數規模、職缺 |
| 競爭情報 | 行銷團隊 | 貼文、互動、公司動態、招募訊號 |
但「免費」只是授權標籤，不是營運成本。真正的成本是：
- 設定時間：即使是友善的 repo，環境設定、瀏覽器依賴、Cookie 擷取與 proxy 設定，通常也要 30 分鐘到 2 小時以上
- 維護成本：LinkedIn 會定期調整 DOM 與反機器人防禦——今天能用的爬蟲，下週就可能壞掉
- Proxy 費用：住宅 proxy 頻寬依供應商與方案不同，大約是
- 帳號風險：LinkedIn 帳號是你賭上最昂貴的資產，而且不像 proxy IP 那樣能隨便替換
Repo 健康度評分卡：如何評估任何 LinkedIn 爬蟲 GitHub 專案
多數「最佳 LinkedIn 爬蟲」清單都是照星數排行。星星只代表歷史關注度，不代表現在還能用。一個有 3,000 顆星、最後一次 commit 停在 2022 年的 repo，不是生產工具，而是博物館展品。
在你 git clone 之前，先套用這套框架：
| 評估標準 | 為什麼重要 | 警訊 |
|---|---|---|
| 最後一次 commit 日期 | LinkedIn 經常變更 DOM | 若是瀏覽器驅動型 repo，超過 6 個月沒更新就要小心 |
| 未解決／已關閉 issue 比例 | 維護者回應速度 | 未解決與已關閉比超過 3:1，尤其最近還有「blocked」或「CAPTCHA」回報 |
| 反偵測功能 | LinkedIn 封鎖很積極 | README 完全沒提 cookies、sessions、節流或 proxies |
| 驗證方式 | 2FA 和 CAPTCHA 會打斷登入流程 | 只支援密碼式無頭登入 |
| 授權類型 | 商業使用的法律風險 | 沒有 license 或條款含糊不清 |
| 支援的資料類型 | 不同用途需要不同 repo | 你需要多種資料時，它卻只支援一種 |
最省時間的一招：在決定用某個 repo 前，先去它的 Issues 分頁搜尋「blocked」、「banned」、「CAPTCHA」或「not working」。如果最近 issue 裡滿是這些字，卻沒有維護者回應，那就直接跳過。那個 repo 其實已經輸了。
2026 年審核實際發現了什麼
我把這套評分卡套用到 GitHub 上 8 個最顯眼的 LinkedIn 爬蟲 repo。結果並不樂觀。
| Repo | 星數 | 最後更新 | 2026 年還能用嗎？ | 主要範圍 | 重點備註 |
|---|---|---|---|---|---|
| joeyism/linkedin_scraper | 約 3,983 | 2026 年 4 月 | ✅ 但有前提 | 個人檔案、公司、貼文、職缺 | 以 Playwright 重寫、可重用 session——但最近 issue 顯示有安全封鎖與職缺搜尋損壞 |
| python-scrapy-playbook/linkedin-python-scrapy-scraper | 約 111 | 2026 年 1 月 | ✅ 適合教學／公開資料 | 個人、公司、職缺 | 整合 ScrapeOps proxy；免費方案每月 1,000 次請求、1 個 thread |
| spinlud/py-linkedin-jobs-scraper | 約 472 | 2025 年 3 月 | ⚠️ 只限職缺 | 職缺 | 支援 Cookie、實驗性 proxy 模式——如果你只需要公開職缺列表，還算有用 |
| madingess/EasyApplyBot | 約 170 | 2025 年 3 月 | ⚠️ 用錯工具 | Easy Apply 自動化 | 這不是資料爬蟲——它是自動投遞職缺 |
| linkedtales/scrapedin | 約 611 | 2021 年 5 月 | ❌ | 個人檔案 | README 還寫著「working in 2020」；issue 顯示 pin 驗證與 HTML 變動問題 |
| austinoboyle/scrape-linkedin-selenium | 約 526 | 2022 年 10 月 | ❌ | 個人檔案、公司 | 曾經有用，但到 2026 年已經太舊 |
| eilonmore/linkedin-private-api | 約 291 | 2022 年 7 月 | ❌ | 個人檔案、職缺、公司、貼文 | Private API wrapper；未公開端點變動很不穩定 |
| nsandman/linkedin-api | 約 154 | 2019 年 7 月 | ❌ | 個人檔案、訊息、搜尋 | 歷史上有意思；文件記錄在每小時約 900 次請求後會遇到速率限制 |
在沒有大量提醒前提的情況下，真正能讓 2026 年讀者實際使用的 repo，8 個裡只有 2 個。這在 GitHub 的 LinkedIn 爬取世界裡並不罕見——這就是常態。
防封鎖作戰手冊：Proxy、速率限制與帳號安全
帳號被封是最大營運風險。就算技術上很會寫爬蟲，也常常倒在這一關。程式碼能跑，帳號不能。使用者回報即使有 proxy 和長延遲，還是可能在只抓 後就被標記。
速率限制：社群回報了什麼
沒有絕對安全的數字。LinkedIn 評估的是 session 年齡、點擊節奏、爆量模式、IP 信譽與帳號行為，而不只是總量。社群資料大致集中在這些區間：
- 有人回報使用 proxy 並以每 33 秒一筆的節奏，在 40–80 個個人檔案 後就被偵測
- 另一位建議控制在 每帳號每天約 30 個個人檔案
- 更激進的操作者宣稱每天可抓 ，而且分散在整天執行
- 記錄到約 每小時 900 次請求 後會出現內部速率限制警告
實務上可這樣總結：每天每帳號少於 50 個個人檔案 屬於較低風險區。每天 50–100 個 是中風險區，session 品質非常重要。超過 每天每帳號 100 個，就屬於越來越激進的操作。
Proxy 策略：住宅型 vs 資料中心型
對 LinkedIn 來說，住宅 proxy 仍是標準做法，因為它看起來比較像一般使用者流量。資料中心 IP 雖然便宜，但在防禦較成熟的網站上更容易被標記——而 LinkedIn 正是那種便宜流量很容易被注意到的網站。
目前的價格概況：
- ：依方案約 每 GB 3.00–4.00 美元
- ：依方案約 每 GB 4.00–6.00 美元
請以 session 為單位輪換，不要每個請求都換 IP。逐請求輪換會留下「這是 proxy 基礎設施」的指紋，比任何單一 IP 都更明顯。
小號帳號操作守則
社群在這點上講得很直白：不要把你的主要 LinkedIn 帳號當成可丟棄的爬蟲基礎設施。
如果你堅持使用帳號式爬取：
- 使用和主要職業身份不同的獨立帳號
- 把個人資料完整填好，先讓它像真人一樣活動幾天，再開始爬取
- 絕對不要把你的真實手機號碼連到爬取帳號
- 爬取 session 要和真正的外聯與訊息互動完全分開
值得注意的是：LinkedIn 的 （2025 年 11 月 3 日生效）明確禁止使用虛假身份與帳號共享。小號策略在實務上很常見，但在合約層面相當麻煩。
如何處理 CAPTCHA
CAPTCHA 不只是麻煩，它代表你的 session 已經被特別關注。可行選項包括：
- 手動完成 CAPTCHA 以繼續 session
- 重用 cookies，而不是每次都重新登入
- 使用像 這類解題服務（圖片 CAPTCHA 約每 1,000 題 0.50–1.00 美元，reCAPTCHA v2 約每 1,000 題 1.00–2.99 美元）
但如果你的工作流程經常觸發 CAPTCHA，那你真正的問題不是解題服務有多貴，而是你的整個流程已經輸了隱蔽性之戰。
風險光譜
| 量級 | 風險等級 | 建議做法 |
|---|---|---|
| < 每天 50 個個人檔案 | 較低 | 瀏覽器 session 或 cookie 重用、慢速節奏、不做激進自動化 |
| 每天 50–500 個個人檔案 | 中到高 | 住宅 proxy、暖機過的帳號、session 重用、隨機延遲 |
| 每天 500+ 個 | 非常高 | 使用商業 API 或內建反偵測的成熟工具；單靠公開 GitHub repo 通常不夠 |
開源悖論：為什麼熱門 LinkedIn 爬蟲 GitHub repo 壞得更快
使用者提出一個合理的擔心：「把它做成開源，LinkedIn 不就能直接看你怎麼做，然後反制嗎？」這不是多慮，而是結構上正確。
可見度問題
高星數會同時帶來兩個訊號：使用者的信任，以及 LinkedIn 安全團隊的目標。repo 越熱門，LinkedIn 越可能專門針對它的手法下手。
你可以在這次審核資料裡看到這個生命週期。linkedtales/scrapedin 曾經夠有名，能宣稱自己可配合 2020 年的 LinkedIn「新網站」運作。但 repo 沒有跟上後來的驗證與版面變動。nsandman/linkedin-api 曾經記錄過有用的技巧，但最後一次 commit 距離現在的反機器人環境已經好多年。
社群修補優勢
開源還是有一個實際優點：當 LinkedIn 改變防禦時，活躍的維護者與貢獻者能更快修補。joeyism/linkedin_scraper 是這次審核中的主要例子——它仍會冒出 blocked auth 和 broken search 這些問題，但至少還在更新。fork 版本通常比原始 repo 更快實作新的繞過技巧。
你可以怎麼做
- 不要把單一公開 repo 當成永久基礎設施
- 留意有沒有活躍 fork 採用了更新的繞過技巧
- 如果用於正式環境，考慮維護一個私有 fork（避免你的客製調整公開）
- 預期 LinkedIn 改變偵測方式或 UI 行為時，你也得跟著改方法
- 採取多元策略，不要把所有賭注壓在單一工具上
AI 擷取 vs. CSS Selector：實務比較
2026 年更值得討論的技術分歧，不是 GitHub 還是無程式碼，而是 基於 selector 的擷取 跟 語意擷取 的差別——而這個差別，比多數總整理文章承認的還重要。
CSS Selector 怎麼運作（以及怎麼壞掉）
傳統爬蟲會檢查 LinkedIn 的 DOM，並把每個欄位對應到 CSS selector 或 XPath 表達式。當頁面結構穩定時，這種方法非常好：精準度高、邊際成本低、解析速度快。
但失敗方式也同樣明顯。LinkedIn 只要改 class 名稱、巢狀結構、lazy-loading 行為，或把內容藏進不同的 auth wall，爬蟲就會立刻壞掉。這次 repo 審核中的 issue 標題已經把故事說完了：「changed HTML」、「broken job search」、「missing values」、「authwall blocks」。
AI／LLM 擷取怎麼運作
較新的模式概念很簡單：渲染頁面、收集可見文字，然後請模型輸出結構化欄位。這就是許多無程式碼 AI 爬蟲，以及部分較新的自訂流程的核心邏輯。
以目前 （輸入每 100 萬 token 0.15 美元、輸出每 100 萬 token 0.60 美元）來算，單次純文字擷取一個個人檔案通常只要 每個檔案 0.0006–0.0018 美元。對中量級工作流程來說，這幾乎可以忽略不計。
正面對比
| 面向 | CSS Selector / XPath | AI／LLM 擷取 |
|---|---|---|
| 設定成本 | 高——要檢查 DOM，針對每個欄位寫 selector | 低——用自然語言描述想要的輸出即可 |
| 版面變動時的破壞性 | 立刻失效 | 自動適應（以語意方式閱讀） |
| 結構化欄位準確率 | selector 正確時約 99% | 約 95–98%（偶爾會有 LLM 解讀誤差） |
| 處理非結構化／變動資料 | 若無自訂邏輯則較弱 | 很強——AI 會理解上下文 |
| 每個檔案成本 | 幾乎為零（只算運算） | 約 0.001–0.002 美元（API token 成本） |
| 標記／分類 | 需要另外做後處理 | 可一次完成分類、翻譯與標記 |
| 維護負擔 | 持續修 selector | 幾乎為零 |
你該怎麼選？
如果是超高量、結構穩定、由工程團隊擁有的管線，selector 解析在成本上仍可能勝出。對大多數小型與中型用戶來說，抓幾百個而不是幾百萬個個人檔案時，AI 擷取是更好的長期投資，因為 LinkedIn 版面變動造成的開發時間成本，往往比你省下來的模型 token 還高。
什麼情況下 GitHub repo 太大材小用：無程式碼路線
大多數搜尋「linkedin scraper github」的人，其實不是想變成瀏覽器自動化維護者。
他們只是想在表格裡看到幾列資料。
使用者在 issue 串裡也明白抱怨 GitHub 爬蟲的可用性：「它不支援 2FA，而且沒有 UI，很難用。」這些受眾包括招募、SDR 和營運團隊，而不只是 Python 開發者。
自建 vs 購買 的決策
| 因素 | GitHub repo | 無程式碼工具（例如 Thunderbit） |
|---|---|---|
| 設定時間 | 30 分鐘–2 小時以上（Python、依賴、proxy） | 2 分鐘內（安裝擴充功能，點一下即可） |
| 維護 | LinkedIn 變動時你自己修 | 由工具供應商負責更新 |
| 反偵測 | 你自己設定 proxy、延遲、session | 內建於工具中 |
| 資料結構化 | 你自己寫解析邏輯 | AI 自動建議欄位 |
| 匯出選項 | 你自己建匯出管線 | 一鍵匯出到 Excel、Google Sheets、Airtable、Notion |
| 成本 | 免費 repo + proxy 成本 + 你的時間 | 有免費方案；大量使用採點數制 |
Thunderbit 如何無程式碼處理 LinkedIn 爬取
處理這個問題的方式，和 GitHub repo 不太一樣。你不需要寫 selector，也不需要配置瀏覽器自動化，而是：
- 安裝
- 前往任何 LinkedIn 頁面（搜尋結果、個人檔案、公司頁面）
- 點擊「AI 建議欄位」——Thunderbit 的 AI 會讀取頁面並提議結構化欄位（姓名、職稱、公司、地點等）
- 視需要調整欄位，然後按一下開始擷取
- 直接匯出到 Excel、Google Sheets、 或 Notion
因為 Thunderbit 每次都用 AI 以語意方式讀頁面，所以 LinkedIn 改 DOM 時它不會壞掉。這和自訂 Python 腳本裡整合 GPT 的方法一樣有優勢，只是被包裝在無程式碼擴充功能裡，而不是你要自己維護的程式碼庫。
如果你要做 ——例如從搜尋結果列表點進單一個人檔案，來補強你的資料表——Thunderbit 會自動處理。瀏覽器模式也能對需要登入的頁面運作，不需要另外設定 proxy。
什麼人還是該用 GitHub repo？
GitHub repo 仍然適合：
- 需要深度客製化或特殊資料類型的開發者
- 每天抓取量非常高、每筆點數成本很在意的團隊
- 需要把爬取流程跑在 CI/CD 管線或伺服器上的使用者
- 要把 LinkedIn 資料整合進更大型自動化流程的人
對其他人——尤其是業務、招募與營運團隊—— 可以直接省掉整套設定與維護循環。
步驟教學：如何評估並使用 GitHub 上的 LinkedIn 爬蟲
如果你已決定 GitHub 才是對的路，下面是一個分階段流程，可以把浪費時間與帳號風險降到最低。
第 1 步：搜尋並縮小 repo 範圍
在 GitHub 搜尋「linkedin scraper」，然後依以下條件篩選：
- 最近有更新（過去 6 個月內）
- 語言符合你的技術棧（Python 最常見）
- 範圍符合你的實際需求（個人檔案 vs. 職缺 vs. 公司）
先挑出 3–5 個看起來還活著的 repo。
第 2 步：套用 Repo 健康度評分卡
把每個 repo 都跑一遍前面的評分卡。凡是有以下情況的，一律淘汰：
- 過去一年沒有 commit
- 有未解決的「blocked」或「CAPTCHA」issue
- 只支援密碼驗證
- 完全沒提到 sessions、cookies 或 proxies
第 3 步：設定你的環境
這次審核中常見的安裝指令包括：
1pip install linkedin-scraper
2playwright install chromium
3pip install linkedin-jobs-scraper
4LI_AT_COOKIE=<cookie> python your_app.py
5scrapy crawl linkedin_people_profile反覆出現的卡點：
- 缺少
session.json檔案 - 瀏覽器 driver 版本不相容（Chromium／Playwright）
- 從瀏覽器 DevTools 擷取 Cookie
- Proxy 驗證逾時
第 4 步：先跑小規模測試爬取
先從 10–20 個個人檔案開始。檢查：
- 欄位是否正確解析？
- 資料是否完整？
- 有沒有碰到任何安全檢查？
- 輸出格式是好用的，還是只有一堆原始 JSON 噪音？
第 5 步：小心擴量
加入隨機延遲（每次請求間 5–15 秒）、降低併發、重用 session，以及使用住宅 proxy。不要在新帳號上一下子就衝到每天幾百個個人檔案。
第 6 步：匯出並整理資料
大多數 GitHub repo 會輸出原始 JSON 或 CSV。你仍然需要：
- 去重資料
- 標準化職稱與公司名稱
- 把欄位對應進你的 CRM 或 ATS
- 為合規性記錄資料來源
（如果你想跳過這一步，Thunderbit 會自動處理結構化與匯出。）
LinkedIn 爬蟲 GitHub vs. 無程式碼工具：完整比較
| 面向 | GitHub Repo（CSS Selector） | GitHub Repo（AI／LLM） | 無程式碼工具（Thunderbit） |
|---|---|---|---|
| 設定時間 | 1–2 小時以上 | 1–3 小時以上（+ API key） | 2 分鐘內 |
| 技術門檻 | 高（Python、CLI） | 高（Python + LLM API） | 無 |
| 維護 | 高（selector 會壞） | 中（LLM 會適應，但程式仍需更新） | 無（由供應商維護） |
| 反偵測 | 自行處理（proxies、延遲） | 自行處理 | 內建 |
| 準確度 | 運作時很高 | 很高，但偶有 LLM 錯誤 | 很高（AI 驅動） |
| 成本 | 免費 + proxy 成本 + 你的時間 | 免費 + LLM API 成本 + proxy 成本 | 免費方案；大量使用採點數制 |
| 匯出 | 自己做（JSON、CSV） | 自己做 | Excel、Sheets、Airtable、Notion |
| 最適合 | 開發者、自訂管線 | 想降低維護成本的開發者 | 業務、招募、營運團隊 |
法律與倫理考量
這段我會寫短一點，但不能略過。
LinkedIn 的 （2025 年 11 月 3 日生效）明確禁止使用軟體、腳本、機器人、爬蟲或瀏覽器外掛來抓取服務內容。LinkedIn 也有實際執法：
- ：LinkedIn 宣布對 Proxycurl 採取法律行動
- ：LinkedIn 表示該案已解決
- ：Law360 報導 LinkedIn 因大規模資料抓取而起訴其他被告
hiQ v. LinkedIn 這類案件，曾在公開資料存取上建立一些細微差異，但 在違約主張上更偏向 LinkedIn。"公開可見" 不等於 "可以放心大規模爬取並用於商業再利用"。
如果是涉及歐盟的工作流程，。法國資料主管機關對 就是一個具體例子，顯示監管機關把被抓取的 LinkedIn 資料視為受資料保護法規約束的個人資料。
使用像 Thunderbit 這樣的維護型工具，不會改變你的法律義務。但它確實能降低你不小心觸發安全回應，或違反速率限制而引起 LinkedIn 注意的風險。
2026 年哪些可行、哪些不可行
可行的做法
- 在決定採用任何 repo 前，先跑 Repo 健康度評分卡
- 使用 Cookie／session 重用，而不是反覆自動登入
- 必要時使用住宅 proxy 來執行帳號式爬取
- 採用更小、更慢、更像真人的爬取流程
- 當你重視適應性勝過少量 token 成本時，使用 AI 輔助擷取
- 當真正需求是輸出到試算表，而不是擁有爬蟲本身時，採用
- 多元化策略，不要把賭注壓在單一公開 repo 上
不可行的做法
- 不看維護狀態或最近 issue，就直接 clone 高星 repo
- 為 LinkedIn 使用資料中心 proxy 或免費 proxy 清單
- 在沒有速率限制或反偵測機制下，把量直接拉到每天幾百個個人檔案
- 長期依賴 CSS selector，卻沒有維護計畫
- 把你真實的 LinkedIn 帳號當成可丟棄的基礎設施
- 把「公開可存取」和「在合約或法律上沒問題」混為一談
常見問題
LinkedIn 爬蟲 GitHub repo 在 2026 年還能用嗎？
有些可以，但只有少數。在這次對 8 個顯眼 repo 的審核中，只有 2 個在沒有大量前提說明的情況下，對 2026 年讀者來說算是實際可用。關鍵不是星數，而是維護活動與 issue 健康度。投資設定時間前，先用 Repo 健康度評分卡檢查任何專案。
我每天可以爬多少 LinkedIn 個人檔案才不會被封？
沒有保證安全的數字，因為 LinkedIn 看的是 session 行為，不只是數量。社群回報顯示：每天每帳號少於 50 個屬於較低風險；50–100 個是中風險，基礎設施品質很重要；超過 100 個就越來越激進。隨機 5–15 秒延遲與住宅 proxy 有幫助，但無法完全消除風險。
有沒有不用寫程式的 LinkedIn 爬蟲 GitHub 替代方案？
有。 讓你用幾次點擊，就能以 AI 欄位偵測來爬取 LinkedIn 頁面，透過瀏覽器登入（不需要 proxy 設定），並一鍵匯出到 Excel、Google Sheets、Airtable 或 Notion。它是為想要資料、但不想維護程式碼的業務、招募與營運團隊設計的。你也可以透過 試用。
抓取 LinkedIn 資料合法嗎？
這是個灰色地帶，而且界線愈來愈清楚。LinkedIn 的 User Agreement 明確禁止抓取，且 LinkedIn 已在 對爬蟲採取法律行動。hiQ v. LinkedIn 對公開資料存取的先例，已被較新的判決限縮。GDPR 適用於歐盟居民的個人資料，不論資料是怎麼收集的。任何商業用途，都應針對你的具體情況諮詢法律意見。
AI 擷取還是 CSS selector——LinkedIn 爬取我該用哪個？
CSS selector 在正常運作時，每筆資料的成本更低、速度更快，但因為 LinkedIn 會定期改動 DOM，所以維護成本像跑步機一樣停不下來。AI／LLM 擷取每個個人檔案的成本略高一些（依目前 約每個檔案 0.001–0.002 美元），但能自動適應版面變動。對大多數不是企業級、而是抓幾百個而非幾百萬個個人檔案的使用者來說，AI 擷取是更好的長期投資。Thunderbit 內建的 AI 引擎提供了這個優勢，而且你不需要寫或維護任何程式碼。
了解更多