一個技術問題,三層答案
前陣子在社群滑到一個提問,我盯著看了很久 ── 不是因為它有多難,而是因為它太典型了,典型到值得拆開來看。 事情是這樣的:有位朋友想用 n8n 打造一個半自動化的 AI 招募 Agent,幫 HR 在 104 跟 Threads 上掃描、分級候選人,確認後再自動產出個人化訊息發出去。聽起來蠻潮的對吧? 問題卡在第一步 ── 104 沒有開放 API,他想用 Playwright 搭配登入 Session 抓資料,結果一跑就報錯:「無法開啟 Chrome」。於是他丟出問題:「改用 Firecrawl 可以搭配嗎?」 我覺得這個提問漂亮的地方,在於它精準示範了大家面對自動化卡關時最常見的反應 ── 把問題定義成「工具選錯了,換一個就好」。但這題如果真的拆開看,你會發現它其實有三層 ── 而「換哪個工具」,八成是這三層裡最淺、也最不影響成敗的那一層。我們一層一層剝。
第一層:工具到底做不做得到?
先回答最表面的問題 ── 因為大家最想聽這個。Firecrawl 能不能做登入後抓取?能。而且可能比朋友現在的方案省事。 兩種玩法。第一種土砲但可靠:你手動登入 104,從瀏覽器 DevTools 把 session cookie 撈出來塞進 headers,Firecrawl 就會「假裝成已經登入的你」去抓。第二種是 Firecrawl 在 2026 年推出的 /interact 端點 ── 用自然語言或直接寫 Playwright 操控瀏覽器,而且 named profiles 會幫你跨次保存登入狀態,不用每次重登。它甚至有 live view,真人可以在過程中接手。這個「人類隨時可以插手」的設計,跟朋友想要的「人工審查後再發送」架構意外地對味。 所以技術上,答案是 yes。但先別急著開心 ── 這裡藏了一個關鍵的認知差。朋友報的那個錯,跟 Playwright 好不好其實沒什麼關係。 「無法開啟 Chrome」這個症狀,絕大多數時候是環境問題,不是工具問題。n8n 通常跑在 Docker 容器裡,而容器映像檔可能根本沒裝瀏覽器,或缺了 Chromium 依賴的一堆系統函式庫(libnss3、libatk 那一票看了會頭痛的東西)。Playwright 在你電腦上裝得好好的,但在容器裡找不到 Chrome 可開,於是翻臉。 這代表什麼?代表 Firecrawl 之所以能解決問題,不是因為它比 Playwright 聰明,而是因為它把整顆瀏覽器搬到別人雲端去跑了。你本機開不開得了 Chrome,從此跟你無關 ── 因為瀏覽器不在你家。這個區別蠻重要的,因為它其實是兩條完全不同的路:「我不想自己養瀏覽器」就用 Firecrawl 這類把瀏覽器基礎設施外包的服務,花錢買省心;「我想把本地環境修好」就去研究怎麼在 Docker 裡正確安裝 Chromium 跟依賴。兩條路都通。但常常會發生的是:有人以為自己在「升級工具」,其實只是「換了一台車,但路還是同一條」。 第一層講完了。如果這篇文章在這裡結束,它就是一篇合格的技術教學文。但我覺得真正有趣的還在後面。
第二層:你以為的瓶頸,是真的瓶頸嗎?
退一步,把鏡頭拉遠一點。這個招募 Agent 真正的瓶頸,是「抓不到資料」嗎? 來想想 HR 的實際工作流。HR 在 104 上找人,本來就有付費企業帳號、本來就看得到履歷、本來就有搜尋跟篩選。資料對他們來說,常常不是「拿不到」,而是「太多、看不完、不知道誰值得花時間」。真正讓 HR 痛的,通常是這兩件事:第一,判斷 ── 這一百份履歷裡,哪二十個真的適合?第二,個人化溝通 ── 找到對的人之後,怎麼寫一封不像罐頭、能讓對方願意回的訊息? 你有發現什麼嗎?朋友想自動化的「抓資料」,在這整條鏈裡常常是最容易做、但價值最低的一段。而真正有價值、HR 真正願意付錢解決的「判斷」跟「溝通」,反而被推到後面變成配角。 這是 AI 自動化常常會踩的陷阱,我自己給它取了個名字叫「[撿軟柿子陷阱](/articles/ai-自動化流程為什麼一接到真實世界就開始出包)」── 我們會不自覺地去自動化那個「技術上最好實現」的步驟,而不是「商業上最該解決」的步驟。因為爬蟲很酷、寫起來有成就感、跑起來會動,看著資料嘩啦啦流進來的感覺很爽。我自己也踩過幾次,不騙妳。但「爽」跟「有用」是兩回事。 如果換做我,我會問自己一個煞風景的問題:「假設今天有人把 104 的資料用銀盤端到我面前,我的 Agent 還剩下什麼?」如果答案是「剩下分級跟寫訊息」,那恭喜 ── 這就是這個產品真正的核心。而它根本不需要爬蟲。讓 HR 自己用 104 介面匯出名單,或乾脆手動貼幾個,把火力集中在「AI 幫你判斷 + 寫個人化訊息」這個值錢的部分,可能比花一週搞爬蟲還快上線。 把最難的工程力氣花在最不值錢的環節上,常常是一種很安靜的浪費。安靜到你會以為自己很有生產力。
第三層:就算做得到,該不該做?
來談房間裡的大象。繞了一大圈在討論「怎麼抓 104 的資料」,但有一個更根本的問題一直沒被問出口:這件事,在法律上站得住腳嗎? 有趣的是 ── Firecrawl 自己的官方文件,在教你做登入抓取的同一個頁面,開頭就先放了警告。大意是:只在你對「雙方」(你自己和平台方)都擁有明確授權的系統上做這種認證後抓取;不確定符不符合服務條款的時候,先取得書面同意。一家賣爬蟲服務的公司,為什麼要在教學文裡自己踩煞車?因為他們很清楚這條線在哪。 兩個現實問題。第一,服務條款。104 的使用條款幾乎可以確定禁止自動化抓取 ── 這不是 104 特別嚴格,大部分人力銀行、大部分平台都這樣寫。用瀏覽器自動化登入、模擬點擊、批次撈資料,通常是明確踩線的。第二,個資法。候選人的履歷是貨真價實的「個人資料」。HR 在 104 後台看履歷,是平台在特定授權範圍內允許的用途;但你把這些資料「搬出平台」、用 AI 分級、存進自己的資料庫、再拿來自動發送行銷式訊息 ── 這在個資的蒐集、處理、利用上,是完全不同的一件事。涉及到你有沒有合法蒐集事由、有沒有符合當初的特定目的、當事人有沒有同意。 我不是律師,這段不構成法律意見。但風險是實實在在的,真心建議任何要碰這類專案的人,找一個懂個資法的專業人士看過再動手。 這裡還有一個很多人會用來自我安慰的點,值得拆開來看:朋友的設計裡有「人工審查確認後才發送」這一步,聽起來很負責任對吧?好像有人把關就沒事了。但冷靜想一下:這個人工審查,審的是發送的內容,擋的是「會不會發錯訊息」。它救得了「訊息發得對不對」,卻救不了「資料一開始是怎麼來的」。如果上游那個「自動掃描、抓取候選人個資」的動作本身就有問題,那中間那道人工確認擋住的是下游失誤,擋不住上游的事情。合規很少是流程末端的一個檢查點,通常是整條鏈從頭到尾都要成立的前提。
真正稀缺的,不是會接節點的人
講到這裡可能有人開始皺眉:「那這也不能做、那也有風險,乾脆別碰算了?」不是這個意思。這三層不是用來嚇退妳,是用來陪妳走的。技術做不做得到、瓶頸找不找得準、合規站不站得穩,拆開來看每件都有解:104 不給爬?那就先問清楚它有沒有官方的徵才資料介面、能不能合法匯出。個資有疑慮?那就在蒐集之前把同意跟目的設計好。真瓶頸是判斷跟溝通?那就把 AI 火力集中在那裡。每一個「不能這樣做」的背後,通常都藏著一個「可以那樣做」的合規路徑 ── 只是它需要有人在你興沖沖打開 n8n 之前,先陪你把這三層走過一遍。 把三層攤開來之後,有件有點諷刺的事:這位朋友花最多力氣鑽研的「Playwright 還是 Firecrawl」,在這三層裡常常是最不需要煩惱的一層。換工具五分鐘就有答案,但「是不是真瓶頸」跟「該不該做」這兩層,可能會直接決定整個專案存不存在。 在這個「人人都能讓 AI 幫忙接幾個節點」的時代,會操作工具的人,大概率會愈來愈不稀缺。今天你不會,問一下 AI、看兩篇教學,週末就學會了。工具的門檻正在以肉眼可見的速度崩塌。那什麼才稀缺?會問「該不該做」的人。能在所有人都興奮討論「怎麼做」的時候,踩一下煞車,問一句「等等,這個瓶頸是真的嗎」「這件事合法嗎」「我們是不是在自動化一個根本不該存在的流程」── 這種人,在團隊裡的價值會慢慢長出來。因為他守住的不只是技術,是判斷。 工具會一直換,Playwright 換 Firecrawl,Firecrawl 換下一個更潮的。但「先想清楚再動手」這件事,通常會比工具活得久。所以下次妳冒出「我想用 AI 自動化某件事」的念頭時,試試先別急著打開 n8n,先問自己三個問題:這件事,工具做得到嗎?(技術層)這件事,是我真正的瓶頸嗎?(策略層)這件事,我該做嗎?(合規與倫理層)能把這三題都想清楚再動手 ── 大概就是在用 AI,而不是被「我會用 AI」這件事用了。
