X-Hiring 是什麼？開源求職聚合器，官網掛了程式碼還活著

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

打開 X-Hiring 的官方網站 x-hiring.hehehai.cn，你只會看到 Cloudflare 的 1016 錯誤頁，告訴你來源站的 DNS 解析失敗。這個網站在 GitHub 上有 458 顆星、34 個 fork，是一個把 V2EX、電鴨社區（eleduck）與阮一峰「誰在招人」話題的徵才訊息抓進來、用 AI 生摘要的開源求職聚合器。官網連不上，大多數人到此就會關掉分頁；但如果你多留三分鐘，會發現這個專案其實分成兩半，死掉的是網站那一半，程式碼那一半不但在，我把它抓下來裝好、跑起來，前後只花了半分鐘。

Pin

三個問題可以走完它：官網掛了，這個專案還剩下什麼？想用的人要付出什麼代價？以及台灣讀者拿它到底能做什麼？

官網掛了，這個專案死了沒

先把時間線攤開。X-Hiring 由開發者 hehehai（York）在 2024 年 2 月建立，最早的形態是一個 Next.js 網站加一支獨立的抓取程式：抓取程式放在另一個儲存庫 x-hiring-grab，設定檔裡要填 Google Gemini 的 API 金鑰、連自家 PostgreSQL 資料庫，甚至留了一個本機代理的欄位給抓取用，網站本體跑在作者自己的伺服器上。那個儲存庫今天還看得到，29 顆星，停在 2024 年 5 月。這個架構活了一年多，中間生病過好幾次，2024 年 4 月有人反映伺服器掛掉，12 月又連續出現 500 錯誤與執行期錯誤，每次都是作者手動救。自己養伺服器、自己養資料庫、自己跑排程，一個人的 side project 要扛這整套，後來的故事其實從這裡就有跡可循。

接著是長達 19 個月的沉默。主分支在 2025 年 1 月更新到 Next 15 之後就停了，一直到 2026 年 8 月 20 日，一次只 commit 一筆的大重建進來，訊息寫得很直白：把 X-Hiring 整個搬到 Cloudflare Workers 上。這次搬家動的不只是網頁框架，連資料的家當都換了：原本放在自家 PostgreSQL 的職缺資料改放 Cloudflare 的 D1 資料庫，歷史資料不搬、砍掉重練，第一次採集跑完就重新長出內容；原本要自己另外跑的抓取程式收進 Worker 的排程裡，伺服器從此不用自己養。這次重建留下了完整的自述文件，裡面記錄著當天的部署狀態：生產環境的 Worker 版本號、資料庫裡 19 筆職缺與 441 個標籤、三次採集全部成功、首頁與詳情頁、搜尋、RSS、健康檢查的線上煙霧測試全數通過。也就是說，8 月 20 日那天，這個服務確實上線過。

Pin

今天再去看，它是這個樣子：網域交給 Cloudflare 代管，來源站卻解析不到，命令列連試三輪、瀏覽器打開，都是同一張 1016 錯誤頁；照著部署設定檔裡的線索去試幾個可能的 workers.dev 位址，全部 404；搜尋結果裡的幾篇介紹與工具目錄，寫的都還是那個用 Google AI 摘要的舊版，沒看到有人提它搬過家。儲存庫也沒有發過任何 release、沒有打過任何 tag，連一個可以指認「最後可用版本」的錨點都沒留。作者本人依然活躍，2026 年 9 月還在推新的專案，個人網站也正常，就只是 X-Hiring 這個網域一直沒有恢復。所以「死了沒」的答案要拆開講：當成一個線上服務，它目前不可用，而且沒有人報修；當成一份原始碼，它兩個月前才剛做完一輪現代化的大整修。網際網路檔案館的最後一張正常快照停在 2026 年 2 月 12 日，之後這個站就從公共紀錄裡消失了，確切的死亡時間點從外部證據已經無法再定位。

想自己架一份，要付出什麼

我把儲存庫抓下來實際跑了一遍。過程出乎意料地短：

git clone https://github.com/hehehai/x-hiring.git
pnpm install
pnpm run dev

clone 下來、依賴安裝 24.9 秒完成，開發伺服器直接起動，本機 3002 埠連上首頁是正常的職缺列表頁，頁面標題開頭就是 X-Hiring，列表上每筆職缺都掛著 V2EX 或電鴨的來源標籤，健康檢查端點乖乖吐出 {"ok":true,"service":"x-hiring","healthyJobs":0}，RSS 位址 /feed.xml 也給出格式正常的 XML。儲存庫附的測試套件九項全過。職缺是零筆，因為採集排程還沒跑、AI 摘要還沒生成，這是乾淨安裝該有的樣子。這份程式碼是完整、能跑的，沒有「README 寫得很滿、原始碼缺一角」的展示品問題。

Pin

讀原始碼還能看出一件文件沒寫的事：儲存庫內部的套件全名是 @actnow，root 專案名就叫 actnow，重建文件裡引用的路徑也指向一個 actnow-react 目錄。合理的是，這次重建是在作者自己的另一個專案樣板上長出來的，履歷表、郵件模板、頭像上傳這些跟求職聚合無關的模組都還留在程式碼裡。這不是缺點，一個人維護多個專案本就會這樣拆裝重組，但它解釋了為什麼文件會跟不上：樣板搬過來，文件沒有同步搬。

不過「本機跑得起來」跟「架上線」中間隔著一整套 Cloudflare。重建後的 X-Hiring 把所有基礎設施都搬進 Workers 生態：資料放在 D1（Cloudflare 的 SQLite 雲端資料庫）、頁面快取用 KV、採集任務丟進 Queues 佇列照序消化、定時觸發靠 Cron Triggers、AI 摘要呼叫 Workers AI，再掛一層 AI Gateway 做快取與監看。要上架到自己的帳號，你得自己建好這些資源，把設定檔裡作者本人的資料庫識別碼、KV 命名空間換成自己的，再補上幾把鑰匙：登入簽章用的密鑰是必填，GitHub 或 Google 登入、電子郵件、頭像儲存都是選配，採集觸發的保護密碼沒設就永遠打不開，這點設計是鎖死的，安全上算加分。沒有 release 安裝包，起點就是原始碼，這對寫過一點前端的人不算難，對沒碰過 Cloudflare 的人是一個下午的學費。

還有兩個現實要先記在帳上。零 release 也代表零版本錨點：上游哪天又推了新 commit，你沒有版號可比對，只能自己看提交紀錄，fork 之後怎麼追上游是自架者自己的功課。另外 AI 摘要走的是 Cloudflare 帳號內的 Workers AI 額度，抓多少、摘要多少，成本上限跟著你的採集頻率走，官方排程一天七輪是作者試過的節奏，要加密集度前先看一眼帳單頁。

有一個細節我特別確認過：採集的觸發端點是關著的。本機起好服務後直接去敲它，拿到的永遠是 401 未授權，原始碼裡寫得很明白，保護密碼沒有設定的話，這個端點對誰都不開門，包括管理者自己。要嘛等排程時間到自動跑，要嘛把密碼設好再帶著憑證去敲。這種預設關閉的設計在個人專案裡並不常見，看得出重建那次是有把安全當一回事的。

文件有兩處已經跟事實脫節，先知道可以少走冤枉路。README 的安裝第二步要你複製 .dev.vars.example 這個檔，儲存庫裡其實不存在這個檔案，只有另一個 .env.example；我實際跳過這一步也能正常開機，文件明顯落後於程式碼。另外儲存庫的自我描述到今天還寫著「使用 Google AI 提取摘要」，那是舊版的事實，現在的摘要引擎在設定檔裡寫死為 Workers AI 的 gpt-oss-120b，找 Gemini 的 API 金鑰是白忙一場。

還有一件事比文件老舊更值得介意：授權。README 頂端掛著 Apache-2.0 的徽章，徽章連去 opensource.org 的條文頁，看起來一切正常；但這個儲存庫裡沒有 LICENSE 檔案，GitHub 的授權偵測顯示 None，package.json 的授權欄也是空的，README 結尾甚至還留著一個連結，指向的正是這個不存在的檔案。徽章是一種宣稱，授權檔才是法律文件，兩者現在對不上。個人研究、自己架著玩，風險很低；想拿它改作、整合進商業專案，建議先請作者把正式的授權檔補上再動手。判斷方法很簡單：打開儲存庫首頁看檔案清單有沒有 LICENSE 或 COPYING 這個檔，有，徽章說的才算數；沒有，別人只是把條文的名字借來掛在門口。

它每天抓什麼：三個社群的徵才訊息

資料來源直接讀原始碼最準。採集模組 sources.ts 裡寫得很明白，一共三個入口：V2EX 的 jobs 討論區、電鴨的遠端工作分類，以及阮一峰科技愛好者週刊儲存庫裡每期固定開的「誰在招人」話題，前兩者用網頁解析抓取，請求帶著一般瀏覽器的識別字串，逾時 20 秒就放棄；第三者走 GitHub API 抓該話題下的留言，可以選擇性填一組權杖提高限額。排程每天跑七個時間點，六個給高頻的 V2EX 與電鴨，一個給每天整理一次的週刊。失敗的抓取不會直接消失，會進佇列重試幾輪，真的救不動才落進死信佇列等人工看。我今天逐一造訪這三個來源，全部正常運作，也就是說自架之後水管接的是活水，不會裝好才發現上游乾了。

抓到原文之後是摘要產線。每篇文章丟給 Workers AI 的 gpt-oss-120b，用結構化輸出抽出職稱、摘要、地點、職務類型、薪資這些欄位，模型答得不像話時會換一次快取繞行重試，答案通過欄位驗證才寫進資料庫；同一批請求在 AI Gateway 上有 24 小時快取，重複內容不會一直燒額度。前台就能按關鍵字、日期、欄位做篩選與趨勢觀察，訂閱則有 RSS。這裡要提醒一件事：AI 摘要是再製品，不是原文。薪資範圍、工作條件、公司名稱這類會影響投遞決定的細節，永遠以原始貼文為準，X-Hiring 的每一筆資料都附著原站連結，投遞與應徵都在原平台完成，它自己是聚合與摘要層，職缺的媒合留給原平台。這個定位跟 Readdig 把 V2EX 與 Hacker News 討論串收進閱讀器的思路很像，價值在整理，不生產職缺。

台灣讀者圖什麼：兩個成立的用途

最後一個問題最實際：對台灣的讀者，這東西圖什麼。先把期待校正掉：三個資料源都是中國大陸開發者社群的生態，徵才方以對岸的公司與團隊為主，內容是簡體中文，薪資以人民幣計價為主，也看得到美元計價的海外遠端職。想找台灣本地職缺，這裡幫不上忙，遠程島那類中文遠端工作聚合站或 Boss 直聘自動化求職工具的路線都比它更符合需求。

拿掉「求職工具」的期待後，剩下兩個用途是成立的。一方面，它是觀察華語開發者職缺市場的即時窗。徵才貼文是市場最誠實的訊號之一：哪些技術組合正在大量徵人、哪類職務開放遠端、薪資區間怎麼分佈，這些問題靠每日七輪的採集加欄位化篩選，比自己手動翻三個社群快得多，對於研究中國大陸開發者就業市場、或評估對岸團隊協作機會的人，是一個成本極低的雷達。另一方面，對寫程式的讀者，它是一份難得的現成教材：D1、KV、Queues、Cron、Workers AI、AI Gateway 在一個真實專案裡怎麼接起來，程式碼不到半年新、規模又不大，比官方範例有血肉得多。想深入遠端工作這個主題，awesome-remote-job 遠端工作資源清單照顧的是國際面向，X-Hiring 補的則是中文圈這一側。

所以適合的人很清楚：想練 Cloudflare 整套服務、想觀察對岸徵才市場的開發者，這個儲存庫值得 fork 一份，半年的新鮮度在開源 side project 裡已經難得；想要一個穩定可用的求職網站、或者要找台灣職缺的人，現在不適合，等網域哪天接好了再說也行，儲存庫的 issue 頁與提交紀錄是最快的復活訊號。把 X-Hiring 當網站看，它已經關門；把它當教材與起點看，這份程式碼還能跑很久。真要動手，順序建議是：先看一眼 LICENSE 補上了沒，fork 一份到自己帳號下，再用自己的 Cloudflare 資源把它跑起來，職缺自然會每天進來。