career-ops：把“該不該投”放在“怎麼投”之前的開源本地 AI 求職代理

它是什麼：一個站在求職者一邊的開源 AI 求職代理

career-ops 是 GitHub 上的開源專案，口號是“The open-source AI job search agent”。作者是 santifer（Santiago Fernández de Valderrama Aparicio）。專案的起點很樸素：他連續數月投出簡歷，卻只換來沉默。於是他沒有繼續海投，而是給自己造了一個過濾器。README 給出的個人資料是：評估了 740 個職位，實際投遞 68 個，進入 12 輪面試，拿到 1 個 offer。作者說，他是這個工具的第一個使用者，拿到工作之後才把它開源。按 README 的說法，六個月後他離開了那份工作，現在團隊繼續做 career-ops，幫助更多人找到自己的工作。

用法被壓縮成一句話：貼上一個職位，工具在你自己的機器上告訴你兩件事，這個職位是否還開放，以及它是否適合你。隨後它會按職位定製你的簡歷，並起草申請表中的回答。最後一步由人完成：“You press Submit”，也就是你自己點提交。這個設計選擇很重要，我們在後面詳細討論。

核心設計：先篩選，再行動

大多數“AI 求職工具”解決的是產出問題：更快地生成簡歷，更快地批次投遞。career-ops 反過來，先解決判斷問題。README 的開場白是：公司用 AI 篩選候選人，而作者“給候選人 AI，讓他們去選擇公司”。工具的第一個輸出不是一份簡歷，而是一個結論。如果結論是“do not apply”（不要投），你就拿回了這個晚上。如果結論是一份計劃，你就知道下一步該做什麼。

演示動圖展示了作者自己的求職過程：一個帶評分的職位列表、一個以紅色顯示的“不要投”數量，以及一份完整的評估報告。介面是西班牙語，這也說明專案的使用場景是多語言的。README 本身提供了 17 種語言的版本，包括英語、西班牙語、德語、法語、日語、韓語、簡體與繁體中文等。

工作原理與可核實的部分

需要先說明邊界：我們引用的背景材料是 README 的開頭部分，它沒有披露內部實現細節，例如評分維度、提示詞結構、職位抓取方式或資料儲存格式。下面只討論 README 明確寫出的機制，以及可以由這些表述合理推出的工程含義。 第一，本地優先。README 寫明“Open source. Local. In the AI CLI you already use.”，即它執行在你已經在用的 AI 命令列工具裡，而不是一個託管的 SaaS。安裝入口是一條命令：npx @santifer/career-ops init。這意味著它以 npm 包的形式分發，初始化後把工作流放進你的本地環境。簡歷、投遞記錄、評估結論這類敏感的個人資料，不必交給第三方平臺。

第二，模型可替換。README 連結了一份“RUNNING_ON_A_BUDGET”文件，並寫明包含免費模型和本地模型。對於不想為每次評估付費的求職者，這降低了使用門檻。代價也很明顯：本地小模型在長文字判斷與措辭質量上通常弱於雲端旗艦模型，評估質量會隨模型而變。 第三，職位“是否仍然開放”的檢查。許多求職者的時間浪費在已經下架的職位上。把“是否還開放”與“是否匹配”放在同一次評估裡，是一個很實用的切入點。README 沒有說明檢查方式，我們不做猜測。 第四，人在迴路。工具起草回答、定製簡歷，但提交由人完成。README 的宣言把這條原則寫成了六行：Apply better to fewer（少而精地投）；Signal over volume（訊號勝過數量）；Evidence over keywords（證據勝過關鍵詞）；A human decides（由人決定）；Local-first（本地優先）；Dignity on both sides of the table（桌子兩邊都要有尊嚴）。

關鍵資料與應如何解讀

最醒目的數字是 740、68、12、1。它的漏斗很說明問題：評估量是投遞量的十倍以上，投遞量約為面試量的五到六倍。換句話說，絕大多數職位在評估階段被淘汰，真正投出的只是少數。這與“海投”策略相反。

但是讀者應當謹慎。這是一個人的求職經歷，不是對照實驗。作者沒有提供不使用工具時的轉化率，也無法排除行業、年資、地區、時機等因素的影響。因此它是有說服力的個案，不是效果證明。README 同樣沒有給出延遲或成本的基準資料，成本取決於你選用的模型。

社群訊號則更多。專案在 Trendshift 上被標註為當日 GitHub 趨勢榜第一，在 Product Hunt 上有展示，並獲得 Vercel 開源計劃的支援。README 還引用了 WIRED 和 Business Insider 的報道。專案還設有“HIRED.md”，用動態徽章統計公開的“已被錄用”故事，每張卡片對應一個可以開啟閱讀的公開 issue。這些是專案自述的採用證據，真實性可以在對應頁面核對，我們沒有逐條驗證。

對開發者與行業的影響

對開發者而言，career-ops 是一個值得研究的樣本：它把一個高度個人化的任務，做成了執行在通用 AI 命令列裡的可分發工作流，而不是一個獨立應用。這個路徑的好處是複用你已有的模型訂閱與許可權，分發成本低，也容易被社群改造。

對求職市場而言，它代表一種力量對等的嘗試。招聘端早已用演算法篩選簡歷，候選人端長期只有模板和關鍵詞堆砌。career-ops 的立場是讓候選人也擁有評估工具，並且明確反對“量大管飽”。有意思的是，它把“拒絕投遞”當作產品的核心價值之一，這與多數以投遞數量計量成功的工具不同。

侷限與風險

首先，評估質量依賴模型。評分、匹配度判斷和“不要投”的結論都是模型輸出，可能有偏差。使用者需要把它當作建議，而不是裁決。 其次，隱私與合規。雖然本地優先降低了資料外洩風險，但只要你使用雲端模型，簡歷內容仍會傳送給模型提供商。選擇本地模型可以避免，但要接受質量折中。

第三，起草內容的真實性。自動定製簡歷必須以你的真實經歷為準。README 強調“Evidence over keywords”，方向是對的，但工具無法替你核實事實，最終責任在提交的人。 第四，證據範圍有限。目前公開材料以作者自述和社群故事為主，缺少獨立的、可復現的評測。

未來演進

從 README 的結構可以看出幾個方向：更多語言的文件與介面，更豐富的“被錄用”案例庫，以及圍繞宣言形成的社群。

宣言頁面還帶有簽名計數徽章，說明專案在嘗試把一套求職實踐變成社群共識。若要走得更遠，最需要補上的是公開的評估基準：例如在固定職位集上比較不同模型的“該投/不該投”判斷，並給出與人工判斷的一致率。

結論

career-ops 的價值不在於讓你投得更多，而在於讓你投得更少、更準。

它把判斷放在行動之前，把決定權留給人，把資料留在本地。證據主要來自一位作者的個案和社群故事，需要審慎看待，但思路清晰，門檻很低：一條 npx 命令，一個你今晚本來要投的職位，就能試出它是否對你有用。