OpenOutreach：把「找名單、寫理由、寄信」打包成一條命令的開源 CLI

它解決的不是「寄信」，而是「名單從哪來」

多數 B2B 開發信工具假設你已經有一份名單，它們負責的是寄送與追蹤。OpenOutreach 反過來，它假設你只有一句產品描述。你告訴它你的產品與目標市場，它從一個授權的資料供應商找出匹配的人，然後對每個人給出一段白話文的入選理由。這個理由不是標籤或分數，而是你可以讀、可以不同意、可以回頭修改產品描述來修正判斷的文字。對照之下，傳統的潛在客戶資料庫輸出的是列與欄，你得自己決定哪一列值得寄信。OpenOutreach 把這個決定變成代理的任務，而且它把決定過程攤開給你看。這對一人公司或早期新創特別有用，因為他們通常沒有業務開發人員可以花時間篩選名單。

三套件、一條管線：OpenOutFind 與 OpenOutSend 的公開契約

OpenOutreach 本身不是一個單體程式，而是編排者。它管理兩個獨立套件：OpenOutFind 負責發現、資格審核、資料豐富化與客戶關係管理，OpenOutSend 負責寄信與寄送防護。兩者都可以獨立執行，例如用 uvx --from openoutfind outfind find 10 或 uvx --from openoutsend outsend send。兩者之間的契約是一條公開的管線：outfind find 50 --json | outsend。這個設計的關鍵在於，即使透過 openoutreach run 在同一個程序內執行，JSON Lines 資料仍然會跨越邊界，只是改在緩衝區內傳遞。README 明確說，這是為了避免讓公開的管線變成謊言，因為如果存在第二條特權的記憶體傳遞路徑，那條未經測試的路徑就會破壞公開介面的可信度。對開發者而言，這代表你可以只取用其中一半，例如用自己的寄信工具接收 outfind 的 JSON 輸出，而不必被綁在 OpenOutreach 的寄信邏輯上。

一條指令完成 onboarding、找名單與寄信

安裝方式只有兩步：uv tool install openoutreach，然後執行 openoutreach。第一次執行會進入 onboarding 流程，之後每次執行 openoutreach run 5 就會找五個附帶工作信箱的潛在客戶並寄信，最多花費五個 credit。這個 CLI 提供多個動詞：init 只做 onboarding 不花任何費用，find 10 找十個名額並輸出 CSV 到 stdout，完全免費且不能花錢，find 10 emails 則要求附帶工作信箱，每個算一個 credit。send 會寄出已儲存的名單，status 顯示目前的設定、被封鎖的項目與計數。所有狀態都存放在 ~/.openoutreach，因此中斷後重新執行會從上次進度繼續，因為你要求的數量是「比現有再多幾個」。這個設計讓 CLI 適合被腳本或代理程式驅動，因為它沒有常駐程序、沒有瀏覽器、也不需要容器。

CSV 輸出是設計核心，不是附帶功能

find 指令的輸出格式是 CSV，欄位名稱包括 email, first_name, last_name, company, title, website, linkedin_url, reason, lead_id, qualified_at。README 特別強調，find 10 emails 會執行到找到十個附帶地址的潛在客戶為止，然後印出你「所有」的潛在客戶，而不只是新找到的。這表示輸出檔案永遠是當前狀態的完整快照，不是增量結果。退出碼 0 表示成功取得要求的數量，若中途停止則會印出已找到的列並說明原因。這種設計對接其他工具非常友善，因為你可以直接寫 openoutreach find 10 emails > leads.csv，然後交給任何你喜歡的寄信軟體。reason 欄位是這整個工具的價值所在，它讓每一列名單都附帶一段可讀的判斷依據，而不是只有一個分數或標籤。

成本模型與免費界線：find 不花錢，emails 才花錢

OpenOutreach 的成本模型非常明確，但也很容易誤解。find 10 不帶 emails 參數時完全免費，它只會找出潛在客戶並輸出 CSV，不會購買任何地址。加上 emails 參數後，每個附帶的工作信箱算一個 credit，而 run 指令則會直接進入寄信流程，因此會消耗對應數量的 credit。README 警告說，find 永遠不會花錢，但 run 會。這個界線對使用者很重要，因為如果你只想測試名單品質，你應該用 find 而不是 run。另一個隱藏成本是 onboarding 與「法律通知」的接受與否，README 在描述 Claude Code 外掛時提到，外掛「永遠不會替你接受法律通知」，這暗示 openoutreach 本身在寄信前可能需要使用者接受某種法律條款。這代表即使 CLI 自動化程度很高，法律責任仍然在使用者身上。

Claude Code 外掛與通用 skill：代理程式是目標使用者

這個專案明顯把代理程式視為第一等公民。它提供一個 Claude Code 外掛，安裝指令是 /plugin marketplace add eracle/OpenOutreach 與 /plugin install openoutreach@openoutreach。外掛內含一個 skill 檔 skills/find-leads/SKILL.md，教導 Claude 何時執行 find、哪些指令會花費 credit、哪些不會、如何讀取 stdout 的 CSV，以及每個 error: <type> 的意義。這個 skill 的設計刻意不綁定 Claude，README 說你可以把 skills/find-leads/ 複製到 ~/.claude/skills/，或讓 Codex、Cursor 等其他代理讀取同一個檔案。對人類使用者來說，這代表 CLI 的說明文件其實是寫給機器讀的，而不是寫給人看的。這是一個有趣的取捨：指令介面非常簡潔，但 onboarding 的精細控制（例如從檔案讀取產品描述與目標市場）是透過 init --product-docs 與 --target 參數達成，而不是互動式問答。

真正的限制：資料來源單一、寄信時序依賴外部時鐘

OpenOutreach 的發現與資格審核完全依賴單一「授權資料提供者」，README 沒有透露是哪一家，也沒有提供更換提供者的介面。如果你的目標市場不在那個資料庫裡，工具就等於沒用。此外，寄信部分 outsend send 的 README 描述是「在信箱的時鐘上」運作，這暗示寄信時序是由外部信箱服務控制，而不是由 OpenOutreach 排程。這代表如果你需要精確控制寄信頻率或避開特定時段，你必須依賴信箱服務的規則，而不是這個工具。最後，GPL-3.0 授權對商業使用有傳染性，如果你打算把 OpenOutreach 整合進自己的付費產品，你必須開源衍生作品。對內部使用或個人專案沒問題，但對軟體公司這是一個需要法律諮詢的決定。

替代方案：從名單上傳到名單生成的兩條路

最直接的替代方案是傳統的 cold-email sequencer，例如 Lemlist 或 Instantly。它們的運作方式完全相反：你上傳一份名單，工具負責驗證信箱、排程寄信與追蹤回覆。OpenOutreach 的 README 明確指出，它不像 sequencer 那樣需要你帶著名單來，也不像 lead database 那樣輸出純資料列。另一條路線是自行組合開源工具，例如用 Apollo.io 之類的資料庫匯出名單，再用 Python 腳本套用你自己的 ICP 規則，最後交給任何 SMTP 服務。這種做法的差異在於，你必須自己寫資格審核邏輯，而且不會有 OpenOutreach 的 reason 欄位自動產生。若你需要的只是名單產生，OpenOutFind 本身可以獨立使用，輸出 JSON 給任何下游工具。所以真正的替代不是另一個「代理」，而是你自己拼裝的管線，差別在於 OpenOutreach 把中間的判斷步驟自動化，但你也因此失去了對判斷規則的直接控制。

編輯結論

OpenOutreach 適合想跳過名單整理與草稿撰寫、又不想把客戶資料交給第三方 SaaS 的個人或小團隊，尤其是已經習慣 CLI 與 CSV 流程的工程師。它不適合需要自訂資料來源、想完全掌控寄信排程、或無法接受「每個有效工作信箱算一 credit」這種計價模型的人。採用前應先確認你對資料提供者的授權範圍與隱私條款沒有疑慮，並實際用 openoutreach find 10（不帶 emails 參數，免費）跑一輪，確認輸出的 reason 欄位品質是否符合你的判斷標準。若你已有自己的寄信工具，跳過 openoutreach run，直接使用 outfind find 與 outsend send 的管線，會是更透明且成本更可控的整合方式。

官方來源

1. eracle/OpenOutreach on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README