我們為什麼用 Claude、Instantly 和 Supabase 打造自己的冷電郵系統
每個機構都說他們討厭冷郵件。我們也是 — 直到我們意識到問題不在冷郵件本身,而在於我們嘗試用來發送冷郵件的每一個工具。通用的範本。那種「嗨 {firstName}」的感覺。那些月費 $300 的平台,仍然需要花上好幾小時的手動工作。所以我們做了開發者會做的事:我們自己建造了一個。
這不是一篇理論架構文章。我們在生產環境中運行這個系統已經有好幾個月了,發送了數千封真正能獲得回覆的個性化郵件。我會詳細帶你瞭解我們為什麼建造它、各個部分如何配合,以及我們艱難地學到的東西。
目錄
- 現成外聯工具的問題
- 我們的技術堆棧及其選擇原因
- 架構概述
- 使用 Hunter 尋找並豐富潛在客戶
- 使用 Claude 進行 AI 個性化
- Supabase 作為編排層
- 使用 Instantly 進行大規模發送
- 自動化膠水
- 結果及我們學到的東西
- 成本分解
- 常見問題

現成外聯工具的問題
我們嘗試過所有常見的嫌疑人。Lemlist。Apollo。Woodpecker。它們都是很好的工具,適用於許多用例。但作為一家無頭網頁開發機構,我們的外聯需求具有這些平台無法處理的特殊方式。
以下是不斷出現問題的地方:
通用個性化欄位不是個性化。 在 2025 年,將某人的公司名稱和職務插入範本並不能騙過任何人。我們需要參考潛在客戶實際技術堆棧、他們網站的性能問題或他們公開網站上可見的特定架構決策的郵件。
研究步驟是瓶頸。 我們表現最好的外聯總是涉及團隊中的某個人實際查看潛在客戶的網站,通過 PageSpeed Insights 運行它,檢查他們的框架,然後編寫特定的內容。這每條潛在客戶需要 10-15 分鐘。按規模計算,這是一份全職工作。
數據分散在太多地方。 潛在客戶在一個電子表格中,電子郵件序列在另一個平台中,結果在第三個儀表板中。我們無法建立反饋迴圈,因為沒有任何東西相互交流。
AI 整合是表面級的。 某些平台添加了「AI 寫作」功能,但它們基本上是生成相同乏味文案的 GPT 包裝器,就像其他人都在發送的一樣。無法提供自訂內容、無法控制提示詞、無法建立多步驟推理鏈。
我們需要一個 AI 進行研究的系統,而不僅僅是寫作。
我們的技術堆棧及其選擇原因
經過幾次迭代,我們最終得到了這個:
| 元件 | 工具 | 作用 | 月費用 |
|---|---|---|---|
| 潛在客戶尋找和電子郵件驗證 | Hunter.io | 尋找並驗證電子郵件地址 | $49(入門版) |
| AI 研究和文案 | Claude (Anthropic API) | 分析潛在客戶、生成個性化電子郵件 | ~$30-60 |
| 數據庫和編排 | Supabase | 存儲潛在客戶、管理狀態、觸發工作流程 | $25(專業版) |
| 電子郵件發送和預熱 | Instantly.ai | 可送達性、發送基礎設施、預熱 | $30(增長版) |
| 自動化膠水 | 自訂 Edge Functions + Cron | 連接所有東西 | $0(包含在 Supabase 中) |
我們評估了許多替代方案。以下是我們選擇所選擇的原因的簡短版本:
Claude 超過 GPT-4: 我們廣泛測試了兩者。Claude 3.5 Sonnet(現在 2025 年的 Claude 4 Sonnet)始終產生聽起來更自然、不那麼「AI 化」的電子郵件。它在遵循複雜系統提示而不偏移方面也更好。定價相當,但 Claude 更長的上下文窗口意味著我們可以為每個潛在客戶提供更多研究數據。
Supabase 超過 Airtable 或自訂 Postgres 設置: 我們需要一個具有行級安全性的真正數據庫,但我們不想管理基礎設施。Supabase 為我們提供了 Postgres、Edge Functions、Cron 工作和一個不錯的儀表板 — 全部在一個地方。我們在客戶專案中也大量使用 Supabase,所以團隊已經很熟悉它了。
Instantly 超過 Lemlist 或 Smartlead: Instantly 的預熱網絡確實不錯,他們的 API 很乾淨,定價適合我們的量。我們不需要 Instantly 的內置序列構建器,因為我們自己處理序列邏輯。
Hunter 超過 Apollo 或 Snov.io: Hunter 的電子郵件驗證始終是我們測試過最準確的。他們的域搜索 API 很快,數據質量很高。Apollo 有更多數據點,但我們發現他們的電子郵件準確性較低,這會扼殺可送達性。
架構概述
該系統分五個階段工作,每個階段獨立運行:
[潛在客戶來源] → [Hunter 豐富] → [Supabase 數據庫] → [Claude 研究 + 文案] → [Instantly 發送]
↑ ↑ |
| | |
+----------- 反饋迴圈 -----------+-------------------------------------------+
- 攝取:我們從各種來源(手動列表、爬蟲、推薦數據)提供潛在客戶域
- 豐富:Hunter 找到聯繫人並驗證電子郵件
- 存儲:所有內容都在 Supabase 中登錄,帶有狀態追蹤
- 研究 + 寫作:Claude 分析每個潛在客戶並生成個性化文案
- 發送:經過批准的電子郵件推送到 Instantly 活動
- 學習:回覆數據流回 Supabase,為未來的個性化提供信息
每個階段是解耦的。如果 Hunter 的 API 宕機,豐富隊列只是備份 — 它不會破壞發送。如果我們想將 Claude 換成不同的模型,我們改變一個功能。

使用 Hunter 尋找並豐富潛在客戶
Hunter.io 處理兩項關鍵工作:在公司中找到正確的人並驗證他們的電子郵件確實有效。
以下是我們豐富功能的簡化版本:
import { createClient } from '@supabase/supabase-js';
const HUNTER_API_KEY = Deno.env.get('HUNTER_API_KEY');
async function enrichLead(domain: string) {
// 域搜索以找到決策者
const searchRes = await fetch(
`https://api.hunter.io/v2/domain-search?domain=${domain}&department=executive,it&api_key=${HUNTER_API_KEY}`
);
const searchData = await searchRes.json();
const contacts = searchData.data.emails
.filter((e: any) => e.confidence > 70)
.slice(0, 3); // 每個域的前 3 個聯繫人
// 驗證每個電子郵件
for (const contact of contacts) {
const verifyRes = await fetch(
`https://api.hunter.io/v2/email-verifier?email=${contact.value}&api_key=${HUNTER_API_KEY}`
);
const verifyData = await verifyRes.json();
if (verifyData.data.status === 'valid') {
await supabase.from('leads').insert({
domain,
email: contact.value,
first_name: contact.first_name,
last_name: contact.last_name,
position: contact.position,
confidence: contact.confidence,
status: 'enriched',
enriched_at: new Date().toISOString()
});
}
}
}
我們篩選 executive 和 it 部門,因為這些是我們的買家 — CTO、工程副總裁、技術創始人。Hunter 的部門篩選並不完美,但它排除了大量噪聲。
我們學到的一件事:永遠不要跳過電子郵件驗證。 即使有 Hunter 的信心分數,我們仍然驗證每個地址。反彈率高於 3% 將摧毀你的發送域的聲譽。我們見過域從 95% 收件箱位置掉到 40% 垃圾箱,只因為一批不良的數據。
我們每週運行大約 500 個 Hunter 搜索信用額,這舒適地符合他們的入門計劃。
使用 Claude 進行 AI 個性化
這是事情變得有趣的地方。Claude 整合不僅僅是「為我寫一封冷郵件」。這是一個多步驟研究和寫作管道。
步驟 1:網站分析
在 Claude 寫任何東西之前,我們向它提供關於潛在客戶網站的數據。我們使用輕量級功能進行爬蟲:
async function analyzeProspectSite(domain: string) {
// 獲取主頁和關鍵頁面
const homepage = await fetch(`https://${domain}`);
const html = await homepage.text();
// 從 HTML 中提取技術信號
const signals = {
hasNextJs: html.includes('__next') || html.includes('_next/static'),
hasReact: html.includes('react') || html.includes('__REACT'),
hasWordPress: html.includes('wp-content') || html.includes('wp-includes'),
hasShopify: html.includes('shopify') || html.includes('cdn.shopify'),
hasGatsby: html.includes('gatsby'),
usesJQuery: html.includes('jquery'),
metaGenerator: extractMeta(html, 'generator'),
pageSize: html.length,
// ... 更多信號
};
// 通過 API 運行 PageSpeed 檢查
const psiData = await fetchPageSpeedInsights(domain);
return {
...signals,
performanceScore: psiData.lighthouseResult.categories.performance.score * 100,
lcp: psiData.lighthouseResult.audits['largest-contentful-paint'].numericValue,
cls: psiData.lighthouseResult.audits['cumulative-layout-shift'].numericValue,
fid: psiData.lighthouseResult.audits['max-potential-fid'].numericValue
};
}
這給了 Claude 真實的數據可以使用。不是「嗨,我注意到你的公司做 X」— 更多的是「你的主頁 LCP 是 4.2 秒,你仍然在運行 jQuery 以及 React,這為你的初始包添加了 90KB。」
步驟 2:Claude 研究提示詞
我們使用 Claude 的 API,附帶精心製作的系統提示詞。以下是簡化版本:
const researchPrompt = `你是一名高級網頁開發人員,正在為一家無頭開發機構分析潛在客戶的網站。根據以下關於他們網站的技術數據,確定:
1. 他們當前的技術堆棧(要具體)
2. 2-3 個具體的性能或架構問題
3. 遷移到現代無頭架構可能改進什麼
4. 一個特定的、不明顯的觀察,展示真正的分析
不要通用。如果你找不到具體的內容,說出來。
不要提及「在當今的數字景觀中」或類似的填充詞。
直接且技術性。
網站數據:
${JSON.stringify(siteAnalysis, null, 2)}
潛在客戶:${lead.first_name} ${lead.last_name},${lead.domain} 的 ${lead.position}`;
const research = await anthropic.messages.create({
model: 'claude-sonnet-4-20250514',
max_tokens: 1000,
messages: [{ role: 'user', content: researchPrompt }]
});
步驟 3:電子郵件生成
研究輸出進入第二個 Claude 調用,該調用編寫實際的電子郵件。分離研究和寫作是一個關鍵洞察 — 當我們嘗試在一個提示詞中做兩者時,郵件會更差。Claude 會跳過研究來更快地進行寫作。
const emailPrompt = `從無頭網頁機構的高級開發人員撰寫冷郵件。
研究筆記:
${research.content[0].text}
規則:
- 最多 4-6 句話。每句話都必須有價值。
- 以最具體的技術觀察開頭。
- 沒有奉承。沒有「我喜歡你正在做的事情」。
- 一個明確的行動召喚:詢問他們是否想看到性能審計。
- 聽起來像開發人員,而不是推銷員。
- 使用他們的名字。問候中沒有姓氏。
- 主題行:簡短、具體到他們的技術問題、小寫。`;
結果是什麼?以「你的 Shopify Plus 商店正在服務器端呈現產品頁面,這些頁面可能是靜態生成的 — 這為每個產品視圖增加了 2+ 秒」而不是「我注意到你的令人印象深刻的公司,想達成聯繫」開頭的郵件。
Supabase 作為編排層
Supabase 是操作的大腦。以下是我們的核心架構:
create table leads (
id uuid primary key default gen_random_uuid(),
domain text not null,
email text,
first_name text,
last_name text,
position text,
confidence int,
status text default 'new', -- new, enriched, researched, drafted, approved, sent, replied, bounced
site_analysis jsonb,
research_notes text,
email_subject text,
email_body text,
instantly_campaign_id text,
sent_at timestamptz,
opened_at timestamptz,
replied_at timestamptz,
created_at timestamptz default now(),
updated_at timestamptz default now()
);
create index idx_leads_status on leads(status);
create index idx_leads_domain on leads(domain);
status 欄位驅動一切。Supabase Cron 工作每 15 分鐘運行一次,在每個階段選擇潛在客戶並將他們推進到下一個階段:
-- Cron:通過 Claude 研究處理豐富的潛在客戶
select cron.schedule(
'process-research',
'*/15 * * * *',
$$select net.http_post(
'https://your-project.supabase.co/functions/v1/process-research',
'{}',
'{"Authorization": "Bearer your-service-key"}'::jsonb
)$$
);
我們每次運行批處理 20 個潛在客戶,以保持在 Claude 的速率限制內並保持成本可預測。
site_analysis JSONB 欄位非常有用。我們可以跨所有潛在客戶查詢以找到模式 — 比如「顯示所有運行 WordPress 且性能分數低於 50 的潛在客戶」— 並從這些分段構建有針對性的活動。
使用 Instantly 進行大規模發送
Instantly 處理實際的電子郵件傳遞。我們通過他們的 API 推送經過批准的電子郵件:
async function pushToInstantly(lead: Lead) {
const response = await fetch('https://api.instantly.ai/api/v1/lead/add', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
api_key: INSTANTLY_API_KEY,
campaign_id: lead.instantly_campaign_id,
skip_if_in_workspace: true,
leads: [{
email: lead.email,
first_name: lead.first_name,
last_name: lead.last_name,
company_name: lead.domain,
personalization_1: lead.email_subject,
personalization_2: lead.email_body
}]
})
});
if (response.ok) {
await supabase
.from('leads')
.update({ status: 'sent', sent_at: new Date().toISOString() })
.eq('id', lead.id);
}
}
Instantly 的活動範本使用 {{personalization_1}} 和 {{personalization_2}} 變數,這些對應我們的 Claude 生成的主題和正文。活動本身只是一個外殼 — 所有的智能都存在於我們的系統中。
在發送任何外聯之前,我們通過 Instantly 的預熱至少運行 3 個發送帳戶 2 週。域預熱不是可選的。我們在第一個域在一週內被標記時以艱難的方式學到了這一點。
可送達性設置
我們的發送基礎設施:
- 3 個域(我們品牌的變化,不是我們的主域)
- 在所有文件上配置的 SPF、DKIM 和 DMARC
- Google Workspace 帳戶(不是 Outlook — Google 在我們的測試中處理冷郵件的能力更好)
- Instantly 預熱連續運行,即使在活躍發送日
- 每個帳戶每天最多 35 封電子郵件
- 發送時間間隔隨機為 3-7 分鐘
自動化膠水
Supabase Edge Functions 連接所有東西。以下是流程的偽代碼:
每 15 分鐘:
1. 選擇狀態為 'new' 的潛在客戶,運行 Hunter 豐富 → 狀態 = 'enriched'
2. 選擇狀態為 'enriched' 的潛在客戶,運行網站分析 → 狀態 = 'analyzed'
3. 選擇狀態為 'analyzed' 的潛在客戶,運行 Claude 研究 + 電子郵件生成 → 狀態 = 'drafted'
4. (人類在 Supabase 儀表板中審查草稿郵件)
5. 選擇狀態為 'approved' 的潛在客戶,推送到 Instantly → 狀態 = 'sent'
6. 從 Instantly API 拉取參與數據 → 更新 opened_at、replied_at
第 4 步很重要。我們不完全自動化發送。每封電子郵件都在發送前要經過人工審查。這可以捕捉偶爾的幻覺(Claude 曾聲稱一個網站是用 Remix 構建的,而它顯然是 Next.js)並讓我們添加個人風格。
由於 Claude 正確處理 95% 的工作,審查步驟大約每封郵件需要 2-3 秒。我們使用簡單的 Supabase 儀表板視圖批量批准。
結果及我們學到的東西
我們自 2025 年第一季度以來一直在運行這個系統。以下是真實數字:
| 指標 | 我們的系統 | 行業平均值(2025 年) |
|---|---|---|
| 打開率 | 62% | 24% |
| 回覆率 | 8.4% | 1-3% |
| 正面回覆率 | 4.1% | 0.5-1% |
| 反彈率 | 0.8% | 3-5% |
| 每個聯繫的潛在客戶成本 | $0.18 | $0.50-2.00 |
| 每個潛在客戶的時間(人工) | ~5 秒(審查) | 10-15 分鐘 |
打開率很高,因為主題行是具體的。「你的 shopify lcp 是 4.2s」會被打開。「快速提問」不會。
回覆率很高,因為郵件展示了真正的技術知識。當 CTO 讀到一封正確識別他們的技術堆棧和真實性能問題的郵件時,他們更有可能參與 — 即使他們知道這是外聯。
什麼不起作用
完全自動化發送(無人工審查): 我們試過這個兩週。Claude 幻覺了大約 5% 的技術堆棧細節。這是 LLM 的低錯誤率,但向運行 Vue 的人發送說「你的 React 應用」的電子郵件比發送通用郵件更糟。信任損害是真實的。
長郵件: 我們的第一個 Claude 提示詞生成了 8-10 句電子郵件。回覆率是我們現在用 4-6 句看到的一半。短總是更好。總是。
每個帳戶每天發送超過 40 封電子郵件: 可送達性直線下降。30-35 在 2025 年是甜蜜點。
使用 Claude 為基於打開的後續電子郵件生成: 我們嘗試生成由打開觸發的後續電子郵件。後續感到咄咄逼人,轉換不值得成本。我們現在三天後發送一個簡單的非 AI 後續。
成本分解
以下是這個系統每月的成本,處理大約 2,000 個潛在客戶:
| 服務 | 月費用 | 筆記 |
|---|---|---|
| Hunter.io(入門版) | $49 | 500 次搜索 + 驗證 |
| Anthropic API (Claude) | $45 | ~2,000 次研究 + 電子郵件生成 |
| Supabase(專業版) | $25 | 數據庫、Edge Functions、Cron |
| Instantly(增長版) | $30 | 發送、預熱、分析 |
| Google Workspace(3 個帳戶) | $21 | 發送基礎設施 |
| 域(3 個) | $10 | 攤銷年費用 |
| 總計 | ~$180 | 每個處理的潛在客戶 $0.09 |
將其與 Apollo 的 $79/月計劃(有限豐富、基本序列)或 Lemlist 的 $69/月每座進行比較。我們花費更少,獲得戲劇性更好的結果,因為個性化是真實的,不是基於範本的。
作為背景,這個系統已經直接生成了潛在客戶,轉化為Next.js 開發和 Astro 開發項目,價值是月費用的 50-100 倍。ROI 是荒謬的。
常見問題
構建這個系統花了多長時間? 第一個有效的版本花了大約兩週的兼職工作 — 可能總共 40 小時。我們自那以後一直在對其進行迭代,主要是調整 Claude 提示詞和添加邊界情況處理。如果你對 Supabase Edge Functions 和 REST API 感到滿意,你可以在一個週末內獲得一個基本版本運行。
這不過是冷郵件的多步驟垃圾郵件嗎? 公平的問題。區別在於每封郵件都包含對收件人網站的真實技術觀察。我們不是向 10,000 人發送「讓我們進行通話」。我們向實際上有我們解決的問題的有針對性的人清單發送特定、有用的見解。我們的取消訂閱率低於 0.5%,這表明收件人也不認為這是垃圾郵件。
為什麼選擇 Claude 而不是 GPT-4 或 Gemini? 我們測試了所有三個。Claude 更可靠地遵循了我們的系統提示詞 — 尤其是「不要通用」和「不要使用填充詞」的約束。GPT-4 會漂向推銷語言,即使有明確的指示不要這樣做。Gemini 很快,但輸出質量不一致。隨著模型的發展,這可能會改變,我們的系統設計為可輕鬆交換模型。
你如何處理 GDPR 和 CAN-SPAM 合規性? 所有我們的外聯都針對商業電子郵件(不是個人),包括我們的物理地址,並且每封郵件中都有清晰的退出選項。對於 GDPR,我們在 B2B 外聯的合法利益下處理數據,維護處理活動的記錄,並立即通過自動化 webhook 處理移除請求。我們也自動清除超過 90 天的潛在客戶數據。為你的具體情況與律師交談 — 這不是法律建議。
當潛在客戶回覆時會發生什麼? 回覆從 Instantly 的 API 流回 Supabase。我們為每個回覆獲得 Slack 通知,人類會立即接手對話。我們永遠不為回覆處理使用 AI。一旦某人參與,他們值得真正的人。感興趣的潛在客戶被指向我們的聯繫頁面或直接指向通話預訂鏈接。
這種方法能否適用於非技術服務? 網站分析部分對網頁開發是特定的,但架構模式 — 豐富潛在客戶、使用 AI 研究和個性化、通過專用工具發送 — 適用於任何 B2B 外聯。你只需要不同的研究輸入。設計機構可能會分析視覺設計和 UX 模式。行銷機構可能會拉取 SEO 指標。關鍵是向 Claude 提供真實數據,而不是要求它編造東西。
維護這個系統最難的部分是什麼? 提示詞維護。隨著 Claude 模型更新,曾經完美工作的提示詞有時需要調整。我們也花時間監控電子郵件可送達性 — 檢查 Google Postmaster Tools、監控垃圾郵件率飆升、輪換發送帳戶。這大約是每週 2-3 小時的維護工作。
你會將其作為產品出售嗎? 我們考慮過,但老實說競爭優勢太有價值了。如果每個機構都運行這個確切的系統,有效性會下降,因為收件人會開始在各處看到 AI 研究的郵件。就目前而言,我們將其作為內部工具保留。如果你想幫助為你的業務構建類似的東西,聯繫我們 — 我們已幫助幾個客戶設置類似的系統,作為我們無頭 CMS 開發工作的一部分。