Boss 直聘自動投遞擴充 boss-helper，把篩選閘門還給你

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Boss 直聘是中國主流的求職平台之一，求職者繞過履歷表關，直接跟 HR 或用人主管開聊，溝通量一大，重複勞動就長在自己身上：同樣的職缺描述看幾十遍、同樣的打招呼打幾十次。這種勞動這兩年養出了兩種開源自動化路線。一種是先前介紹過的 geekgeekrun：在本機開一個真的瀏覽器視窗，讓程式模擬你的手在頁面上點擊。另一種是這篇的主角 boss-helper：一個裝在瀏覽器裡的擴充套件，直接在你登入的直聘頁面裡工作，拿頁面上的登入憑證去呼叫平台自己的介面，就連打招呼的訊息，都是它自己跟平台的聊天頻道講協定送出去的。

先講整體判斷。這是一個機制全透明可讀的工具，每一層怎麼運作，原始碼裡都有答案；這篇的結論來自逐檔讀它的程式碼、GitHub 發布紀錄與各商店頁面，我沒有實際安裝去跑投遞，原因留到最後一節交代。它值得認識的理由有三個：批量投遞在它手上是一條你自己設定的過濾工作流，每個職缺要先過十幾道閘門；對外連線盤點起來乾淨，沒有自建遙測；專案活著，2026 年 10 月中還有提交。但它不替你付三樣成本：帳號風險作者寫在 README 第一屏、AI 與地圖服務要自己申請金鑰、裝錯頻道會拿到停在一年半前的舊版。

同一個平台，兩條自動化路線

把它跟同類放在一起，差異才立體。查核當下 geekgeekrun 在 GitHub 上有 2,744 顆星，boss-helper 有 2,352 顆，同樣針對 Boss 直聘的開源求職自動化，都站上兩千顆星的量級，工程路線卻相反。geekgeekrun 是 Python 寫的桌面程式，開瀏覽器、模擬滑鼠鍵盤，macOS 上安裝前甚至要全域關閉 Gatekeeper，它的主分支在 2026 年 5 月之後就凍結了。boss-helper 是 WXT 加 Vue3 打造的瀏覽器擴充套件，內容腳本只注入 zhipin.com，你平常怎麼用直聘的網頁版，它就在那個頁面裡做事，2026 年 10 月都還有提交紀錄。

Pin

兩條路線的取捨很實際。頁面內路線部署最輕，裝個擴充套件就能開工；它拿頁面的 cookie 與權杖呼叫平台介面，對平台來說，請求就是從你登入的頁面發出的。桌面路線把行為做得比較像真人，代價是部署重：要裝 Python 環境、要開一個看得見的瀏覽器視窗、登入狀態要自己維持。頁面內路線的軟肋在另一處：它假設平台的介面與協定不改版，直聘一改，它就得跟著修；提交紀錄裡的修修補補，可以想見有一部分就是在追這種改版。沒有哪條路線全面勝出，看你願意顧哪一端。

兩邊對 AI 的處理倒是同一個哲學：都把模型選擇權留給使用者，預設範例都指向 DeepSeek。差別在金鑰落地的地方，geekgeekrun 把金鑰寫進本機資料庫檔案，boss-helper 的設定存在瀏覽器的擴充套件儲存區，都算本機，生命週期一個跟著資料夾、一個跟著瀏覽器設定檔。

對「被平台認出來」這件事，兩條路線的姿態也不同。geekgeekrun 為了讓自動化瀏覽器看起來像真人，自製了隱身外掛去改瀏覽器的指紋特徵，工程做在躲偵測上；boss-helper 沒有對平台的偵測做任何偽裝，它就住在頁面裡，用頁面本來就有的身分說話（它倒有一個把分頁偽裝成線上計算機的外觀選項，那是躲旁人眼光的，不是躲平台的），工程做在把流程做對上。哪種活得久沒有標準答案，但理解這個差異，你才知道自己在賭哪一種假設：賭平台的偵測抓不到擬真行為，還是賭平台容得下一個登入使用者的高速操作。

批量投遞的真實形貌：十幾道閘門的工作流

「批量投遞」聽起來像無腦群發，打開它的 delivery.ts，實際是一條逐站排隊的工作流，每個職缺要通過你設定的閘門才會被投出去。前半段的判斷用職缺列表上的資訊就夠：已經溝通過的跳過、同一間公司投過的跳過、同一個 HR 跳過，接著是職稱、公司名、薪資區間、公司規模與獵頭身分，各自比對你寫的規則。這些規則不是開了就全套生效，每一站都可以單獨開關：要寫規則比對的站，職稱、公司名、薪資區間、公司規模、獵頭身分，出廠全部是關的，避免你還沒設好就投錯職缺；同 HR、活躍度、好友狀態這三個安全站則預設就開，這個配置看得出作者踩過坑。同公司與同 HR 這兩站的記憶還有保存期限可以調，是 0.5.2 版新加的設定：預設期限為零，投過的紀錄一直留著；設了期限之後，超過時間的舊紀錄會被自動清掉，同一間公司過一陣子就重新變成可投遞的對象，想隔段時間回訪同一批公司的人用得上。

薪資區間這站有兩種匹配模式，設計得比多數同類細：嚴格模式要求你的期望範圍完全覆蓋職缺開出的範圍才放行，寬鬆模式只要有部分重疊就算命中。要寧缺勿濫還是要廣撒再挑，同一個欄位自己調。

通過前半段的職缺，工作流才去抓職缺詳情，用詳情再過第二輪：HR 的活躍度、HR 的職位、上班地址、好友狀態、工作內容關鍵字，還有一站叫金牌面試官，判斷方式很有個性，比對 HR 頭像有沒有掛特定雜湊值的金牌貼圖。最後兩個是延伸加分站：用高德地圖算你到公司的通勤距離，以及把職缺丟給你自己設定的 AI 模型評分。

全部通過，才走到投遞本體：呼叫 friend/add.json，也就是直聘網頁自己處理加好友與開啟溝通的內部介面。boss-helper 帶著你頁面上的登入權杖去叫它，失敗會重試三次，遇到限流有對應的錯誤處理。這裡要把話說明白：它以你的登入身分直接呼叫平台介面，平台看到的是一個會自動發請求的帳號，風險等級跟手動操作不同，作者警告的根源就在這裡，後面會回到這一點。

速度與總量也有節奏控制器。按下去之後先等一段起跑延遲、每投一筆之間有間隔、翻下一頁之前再停一下，三段延遲全部可以自己調；每天另有投遞上限，預設 120 筆，達到就停止並跳出通知說明原因。設定欄位的說明文字直接提醒投太快容易觸發平台風控，等於作者把配速建議寫進了介面。有個小錯位順帶記一筆：說明文字寫的預設值（起跑 10 秒、間隔 2 秒）跟程式碼的出廠值（3 秒與 5 秒）對不上，不影響使用，但說明與程式碼顯然是分頭維護的。

投遞完成後還有收尾兩站：自訂招呼語與 AI 招呼語。自訂招呼語支援模板變數，把職缺資料代進你自己寫的開場句，進階用法是排多段訊息按順序送出，文字加圖片的組合也行，只是設定介面自己標明了已知問題，多段訊息可能只有第一段發送成功；AI 招呼語則是把職缺資料交給你設的模型生成，預設提示詞對輸出格式有明確要求：要的是聊天開場白，不要書信格式、不要稱謂前綴，畢竟這句話最後會出現在直聘的聊天窗裡，寫成正式信件反而穿幫。預設提示詞還留了一塊白：職缺端的欄位都有變數自動代換，求職者自己的介紹區卻只放了幾行佔位符號，出廠狀態下模型讀得懂職缺、不認識你，想要有個人味道的開場白，這段得自己補上。

整條工作流跑起來的樣貌，介面上看得到兩個回饋：日誌頁逐條記錄每個職缺過了哪站、在哪站被跳過與原因；統計頁按日彙總投遞量，資料存在本機。0.5.2 這版的更新說明剛好就是這一帶：修復統計功能失效、完善日誌記錄、修復投遞失敗後繼續投遞的問題，修的東西也標出了這工具的日常在哪裡。招呼語送出的通道，就是下一節要講的東西。

連訊息都自己講協定：WebSocket 上的 protobuf

多數同類工具做到發出打招呼就停了，boss-helper 的聊天層挖得更深：它直接跟 wss://ws6.zhipin.com/chatws 建立連線，用頁面取得的票券走 MQTT over WebSocket，訊息本體用 protobuf 打包成直聘自家的訊息格式，protobuf 定義裡的套件名就叫 cn.techwolf.boss.chat，從語音、圖片、職缺卡片到履歷分享，各種訊息型別都定義在裡面，平台的聊話語法整套被搬進了擴充套件。

這層技術對讀者的意義可以從兩個方向看。它展示了頁面內路線能走多深：協定摸清楚之後，擴充套件能做到跟官方頁面同一層級的通訊，不用另外跑任何程式；它也同時標出了這類工具的壽命結構，協定直連的每一行都建立在平台不改的假設上，直聘哪天換了聊天頻道或訊息格式，這一層就要重寫。維護成本藏在架構選擇裡，選這條路的工具，活著與否看作者追不改版的意願。

資料往哪送：三條對外線與兩把自己的金鑰

把原始碼裡的對外連線逐一盤點，主要清單比想像中短：zhipin.com 的各個介面、高德地圖的地理編碼與距離計算、你在設定裡自己填的 AI 端點、jsdelivr 上作者放的遠端設定檔，加上幾張直聘網域的靜態圖；零星還有兩張外站圖片，一張是關於頁掛的作者打賞收款圖，放在作者的阿里雲儲存空間上，另一張要等你主動開啟更換圖示功能才會去抓。沒有自建的遙測或分析端點，投遞統計按日記錄在瀏覽器本機儲存區，介面上就能看每天投了幾筆。對比 geekgeekrun 內建了 GA4 流量分析，這個取捨對在意隱私的人友善一些。

方向反過來的通道倒有一個：擴充套件會去 jsdelivr 抓作者維護的遠端設定檔，裡面目前放的是各商店安裝連結與回饋問卷，另有一個通知欄位，等於作者對所有使用者廣播訊息的管道，目前是空的。你的資料沒有往外送的痕跡，但作者的訊息有往你這邊送的能力，兩件事分開看。

AI 功能全走 BYOK（自帶金鑰）：模型端點、API 金鑰、模型名稱全部自己填，設定介面給的範例端點包含 DeepSeek、OpenAI、OpenRouter、月之暗面、火山引擎與小米，預設模型是 deepseek-chat。AI 打招呼的預設提示詞會把職缺名稱、薪資、學歷要求、技能要求、職務標籤與完整職務描述送進你設定的端點；AI 篩選送得更多，還包含經驗要求與福利清單。這些欄位會離開瀏覽器，去你選擇的模型服務，流向自己決定。兩個 AI 功能出廠都是關閉的，要用自己開。

AI 篩選的機制值得一提：模型被要求扮演評審，對每個職缺回傳 JSON 格式的加分項與扣分項，每項附理由與分數，工具把正負分加總後跟門檻比對，門檻預設 10 分。預設範例的評分標準，加分側是雙休、朝九晚五、新技術、機會多、年輕人多，每項十分；扣分側是需要上門、福利少、需要和客戶交流、需要推銷，每項也是十分。這些標準就寫在提示詞裡，你可以整組換成自己的價值觀，這是它跟固定規則篩選器差最多的地方。

通勤篩選是第二把要自帶的金鑰：地址地理編碼與距離計算都呼叫高德開放平台，地址會送高德；README 寫目前只有駕車與步行兩種距離，程式碼裡其實還多算了直線距離。

權限面要分兩層看。擴充套件向瀏覽器要的能力只有本機儲存與桌面通知，內容腳本也只注入 zhipin.com；但 manifest 對網站的存取權請求的是所有網域，原因不難理解，BYOK 讓你把 AI 端點填在任何位址，它得先有全域權限才連得到。所以安裝時 Chrome 會警示「讀取及變更您在所有網站上的資料」，這是申請面；從程式碼看，實際發請求的對象只有上面盤點出的那串清單，這是行為面。兩個面積之間的落差，信不信由自己衡量。

從哪裡裝：油猴頻道停在一年半前

這是安裝前最實用的一段。boss-helper 現在的主頻道是各瀏覽器的擴充套件商店與 GitHub Releases：Chrome 商店上架 0.5.2.2 版，超過一萬名使用者，14 則評分平均約 4.3 顆星，安裝包約 600KB，商店頁標的更新日期是 2026 年 8 月 11 日；GitHub 最新版是 2026 年 8 月的 0.5.2。Edge 與 Firefox 商店也有上架，Firefox 的頁面這邊連不上，版本細節無法親自核對，這點照實說。作者自己對各頻道的註記很直白：Chrome 商店審核慢、Edge 最慢、Firefox 最快、GitHub 沒有審核隨時更新，急著用新版的人看著選。

Pin

實際連上 Chrome 商店頁時，還遇到一個值得記下的現象：用這邊的網路開啟頁面，版本、使用者人數、評分都正常顯示，安裝鈕一帶卻掛著「目前無法取得這項產品」的提示，換語系重連兩次都一樣；但直接向 Google 的擴充套件更新伺服器要檔案，0.5.2.2 的安裝包完整下載成功，清單本身還活著。如果你的商店頁也卡在同樣提示，先別繞去第三方下載點，改走 Edge、Firefox 商店或 GitHub Releases 都是正門。商店詳情頁另外掛了一個提供應用內購的標記，原始碼對外連線盤點裡找不到任何付費端點，標記與程式碼對不上，原因不明，先記在這裡。

版本節奏可以看出這專案的體質。倉庫 2024 年 2 月建立，到現在兩年多，開發清單上最早完成的是 UI 優化與去廣告，那個年代它的定位偏向把直聘網頁版改清爽的助手，批量投遞與 AI 是後來長出來的主幹。2026 年 7 月底到 8 月初接連出了 0.5.0 到 0.5.2 三個版，商店版現在是 0.5.2.2，更新日期 8 月 11 日，比 GitHub 發 0.5.2 晚四天，中間就是商店審核走的時間，對一個靠個人維護的專案來說，這個密度不算冷淡。更新說明的內容也對得上主線：0.5.1 修儲存無提示的問題、加分隔符與卡片篩選；0.5.2 修統計失效、補日誌上下文，作者放在遠端設定檔裡的版本說明還多列一條修復，投遞失敗後能繼續投遞，修來修去都圍著投遞在轉。倉庫本身也還活著：8 月中有外部貢獻者的合併請求修好了 README 的星數趨勢圖，10 月 13 日最新一筆提交把高德地理編碼失敗寫進日誌，讓通勤篩選出錯時看得到原因，維護顆粒度已經細到錯誤回報這一層。

陷阱在油猴頻道。greasyfork 上那份腳本有 5,452 次安裝，最後更新停在 2025 年 3 月，README 自己標明那是 0.2 舊版本。從那裡裝，拿到的是停在一年半前的版本，後來的功能與修補全都不在裡面。頻道演進還留下痕跡：作者放在 jsdelivr 的遠端設定檔，GitHub 連結仍寫著 boos-helper 這個拼字，好在 GitHub 會自動轉址到現在的 boss-helper，不影響使用，但看得出這個專案改過名、搬過家。

網路上流傳的舊介紹也一起過期了。有的文章還寫它是 element-plus 技術棧的油猴腳本、有多帳號管理功能；現在的原始碼是 WXT 加 Vue3 加 NuxtUI，多帳號管理在開發清單上已標註廢棄，改成多份設定檔切換，不同求職情境配不同的篩選與招呼設定。看這類工具的介紹文，先檢查它講的版本與時間，再對一次 repo 現況，差距通常比你想的大。

風險、授權與這篇沒有驗證的事

作者在 README 第一屏放了醒目警告，這裡照實轉述，但要標明這是作者宣稱，沒有量化資料背書：使用有風險，帳號可能被標記、被封停或搜尋權重降低，專案不承擔責任，且僅供學習交流，禁止商業用途。平台態度可以對照直聘自己的用戶協議，我在 geekgeekrun 那篇查過，協議對使用自動程式寫的是從強制登出、限制功能到封停帳號。實際被抓的機率多高，沒有公開資料，我也不替你猜。

授權狀態有個並存現象：程式碼掛 MIT 授權，README 又寫禁止商業用途，兩份文件對「能不能拿它做生意」說法不同。開源授權與附加宣告的法律關係，這裡不給意見，只指出矛盾存在，真要計較請找專業意見。功能面也對齊一下期待：自動回覆聊天、黑名單、公司風險評控在開發清單上還沒實作，多模型管理與 AI 篩選已經有，UI 優化去廣告與批量投遞是 2024 年就完成的老功能。

最後交代我停在哪裡。這篇每個機制描述都來自讀原始碼與商店頁面，我沒有安裝它、沒有實際投遞，原因跟風險同源：自動化投遞正是那種後果自負的操作，拿一個求職帳號去驗證封號機率，成本不對稱。所以投遞成功率、對方回應率、長期穩定度，這篇沒有數字，也不該有。

誰該裝它，誰該繞開

什麼人適合裝它？你已經在 Boss 直聘手動大量投遞、清楚自己的篩選條件、願意自己申請 AI 與地圖金鑰，而且這個帳號就算出事也承受得起，幾項都符合再考慮。帳號是唯一依靠、或期待裝了就保證有效果的人，它不適合你。決定要裝的話，走瀏覽器商店或 GitHub Releases，跳過油猴那份；裝完先把篩選閘門一項一項設好、金鑰設好，先跑一小批看日誌與統計，確認行為符合預期再放量，別第一次就全速開。

往求職這件事的外圍走，還有幾條不動直聘帳號的路。履歷本身要先打磨的，開源的 ResumeMatcher 會對著職缺描述比對履歷覆蓋率；要快速客製不同職位的履歷，Resume To Job 走產生器路線；想先擴大機會來源再考慮要不要自動化，遠程島 整理的是海外遠端職缺。篩選交給工具，判斷留給自己，這個順序對了，自動化才是幫忙。