我們用 Claude、Instantly 和 Supabase 打造了冷郵件系統

你打開 Instantly 儀表板，看到 200 個潛在客戶排隊、郵件範本已準備好，但心裡卻空蕩蕩的——又一批「嘿 {firstName}，我注意到你的公司...」即將發出。每個代理商都討厭冷郵件。我們也是。不是因為外展不起作用，而是因為我們付費使用的每個平台仍然需要數小時的手動研究，仍然發送看起來像機器人寫的文案，仍然每月花費 300 美元來做我們知道 Claude 可以在幾秒內做得更好的事情。所以我們停止了租賃。我們將 Claude、Hunter、Instantly 和 Supabase 連接在一起，建立了一個系統，可以從實時網頁抓取生成上下文相關的開場白、根據意圖評分回覆，並在沒有 SaaS 稅收的情況下記錄每項互動。該架構並不是火箭科學——但回覆率躍升了，無意義的工作消失了，我們擁有整個堆棧。

這不是一篇理論性的架構文章。我們已經在生產環境中運行此系統數個月，發送了數千封個性化郵件，確實收到了回覆。我將帶你瞭解我們為什麼要構建它、各個部分如何配合，以及我們在實踐中學到的教訓。

目錄

• 現成外展工具的問題
• 我們的技術堆棧及選擇原因
• 架構概覽
• 用 Hunter 查找和豐富潛在客戶
• 使用 Claude 進行 AI 個性化
• Supabase 作為編排層
• 使用 Instantly 大規模發送
• 自動化粘合劑
• 結果和我們學到的東西
• 成本明細
• 常見問題

現成外展工具的問題

我們試過了常見的工具。Lemlist。Apollo。Woodpecker。對許多用例來說，它們都是很好的工具。但作為一個無頭網頁開發代理，我們的外展需求以這些平台無法處理的特定方式存在。

以下是一直出問題的地方：

通用個性化字段不是個性化。 將某人的公司名稱和職位插入範本無法欺騙 2026 年的任何人。我們需要引用潛在客戶實際技術堆棧、他們網站的性能問題或其公開網站上可見的特定架構決策的郵件。

研究步驟是瓶頸。 我們表現最好的外展總是涉及團隊中的某人實際查看潛在客戶的網站、通過 PageSpeed Insights 運行它、檢查他們的框架，以及寫一些具體的內容。這耗時 10-15 分鐘每個潛在客戶。規模上，這是一份全職工作。

數據散落在太多地方。 潛在客戶在一個電子表格中，郵件序列在另一個平台上，結果在第三個儀表板上。我們無法建立反饋迴路，因為沒有任何東西相互連接。

AI 集成很膚淺。 某些平台添加了「AI 寫作」功能，但它們基本上是 GPT 包裝程序，生成了與其他所有人發送的相同平淡文案。無法輸入自訂上下文，無法控制提示，無法建立多步推理鏈。

我們需要一個 AI 進行研究的系統，而不僅僅是寫作。

我們的技術堆棧及選擇原因

經過幾次迭代後，我們選定了以下工具：

組件	工具	角色	月度成本
潛在客戶查找和電子郵件驗證	Hunter.io	查找和驗證電子郵件地址	$49（初級版）
AI 研究和文案撰寫	Claude（Anthropic API）	分析潛在客戶，生成個性化郵件	~$30-60
數據庫和編排	Supabase	存儲潛在客戶，管理狀態，觸發工作流	$25（專業版）
郵件發送和預熱	Instantly.ai	可送達性、發送基礎設施、預熱	$30（增長版）
自動化粘合劑	自訂邊緣函數 + Cron	連接所有內容	$0（包含在 Supabase 中）

我們評估了很多替代方案。以下是我們選擇所選工具的簡短版本：

Claude 而不是 GPT-4： 我們廣泛測試了兩者。Claude 3.5 Sonnet（現在是 2025 年的 Claude 4 Sonnet）始終產生聽起來更自然且不「像 AI」的郵件。它在不偏離的情況下遵循複雜系統提示方面也更好。定價具有可比性，但 Claude 較長的上下文窗口意味著我們可以為每個潛在客戶輸入更多研究數據。

Supabase 而不是 Airtable 或自訂 Postgres 設置： 我們需要一個真正的數據庫，具有行級安全性，但我們不想管理基礎設施。Supabase 為我們提供了 Postgres、邊緣函數、Cron 作業和一個不錯的儀表板——全部集於一處。我們在客戶項目中也大量使用 Supabase，所以團隊已經很熟悉了。

Instantly 而不是 Lemlist 或 Smartlead： Instantly 的預熱網絡確實很好，他們的 API 很乾淨，定價對我們的規模很有意義。我們不需要 Instantly 的內置序列生成器，因為我們自己處理序列邏輯。

Hunter 而不是 Apollo 或 Snov.io： Hunter 的電子郵件驗證始終是我們測試過的最準確的。他們的域搜索 API 很快，數據質量很高。Apollo 有更多數據點，但我們發現他們的電子郵件準確性更低，這會破壞可送達性。

架構概覽

該系統分五個階段運行，每個階段獨立運行：

[潛在客戶來源] → [Hunter 豐富] → [Supabase 數據庫] → [Claude 研究 + 文案] → [Instantly 發送]
     ↑                                       ↑                                           |
     |                                       |                                           |
     +----------- 反饋迴路 -----------+-------------------------------------------+

1. 攝取：我們從各種來源（手動列表、抓取工具、推薦數據）輸入潛在客戶域
2. 豐富：Hunter 查找聯繫人並驗證電子郵件
3. 存儲：所有內容都進入 Supabase，進行狀態跟蹤
4. 研究 + 寫作：Claude 分析每個潛在客戶並生成個性化文案
5. 發送：批准的郵件推送到 Instantly 活動
6. 學習：回覆數據流回 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 秒，你仍然在 React 旁邊運行 jQuery，這將 90KB 添加到你的初始包中。」

第 2 步：Claude 研究提示

我們使用 Claude 的 API 和精心設計的系統提示。以下是簡化版本：

const researchPrompt = `You are a senior web developer analyzing a prospect's website for a headless development agency. Given the following technical data about their site, identify:

1. Their current tech stack (be specific)
2. 2-3 concrete performance or architecture issues
3. What a migration to a modern headless architecture could improve
4. A specific, non-obvious observation that shows genuine analysis

Do NOT be generic. If you can't find something specific, say so.
Do NOT mention "in today's digital landscape" or similar filler.
Be direct and technical.

Site data:
${JSON.stringify(siteAnalysis, null, 2)}

Prospect: ${lead.first_name} ${lead.last_name}, ${lead.position} at ${lead.domain}`;

const research = await anthropic.messages.create({
  model: 'claude-sonnet-4-20250514',
  max_tokens: 1000,
  messages: [{ role: 'user', content: researchPrompt }]
});

第 3 步：郵件生成

研究輸出進入第二個 Claude 調用，該調用寫實際郵件。分離研究與寫作是一個關鍵洞察——當我們試圖在一個提示中做兩者時，郵件品質較差。Claude 會跳過研究以更快地進行寫作。

const emailPrompt = `Write a cold email from a senior developer at a headless web agency.

Research notes:
${research.content[0].text}

Rules:
- 4-6 sentences max. Every sentence must earn its place.
- Lead with the most specific technical observation.
- No flattery. No "I love what you're doing."
- One clear CTA: ask if they'd want to see a performance audit.
- Sound like a developer, not a salesperson.
- Use their first name. No last name in greeting.
- Subject line: short, specific to their tech issue, lowercase.`;

結果呢？郵件以「你的 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 生成的主題和正文。該活動本身只是一個 shell——所有的智能都存在於我們的系統中。

我們通過 Instantly 的預熱運行 3 個發送帳戶至少 2 週，然後才發送任何外展。域預熱不是可選的。我們第一個域在一周內被標記為「垃圾」，以此吸取了教訓。

可送達性設置

我們的發送基礎設施：

• 3 個域（我們品牌的變體，不是我們的主要域）
• 所有域上都配置了 SPF、DKIM 和 DMARC
• Google Workspace 帳戶（不是 Outlook——Google 在我們的測試中處理冷郵件的效果更好）
• Instantly 預熱連續運行，即使在活躍發送日
• 每個帳戶每天最多 35 封郵件
• 隨機發送間隔 3-7 分鐘

自動化粘合劑

Supabase 邊緣函數連接了所有內容。以下是流程的偽代碼：

Every 15 minutes:
  1. Pick up leads with status='new', run Hunter enrichment → status='enriched'
  2. Pick up leads with status='enriched', run site analysis → status='analyzed'
  3. Pick up leads with status='analyzed', run Claude research + email gen → status='drafted'
  4. (Human reviews drafted emails in Supabase dashboard)
  5. Pick up leads with status='approved', push to Instantly → status='sent'
  6. Pull engagement data from Instantly API → update opened_at, replied_at

第 4 步很重要。我們不完全自動化發送。每封郵件在發出前都要經過人工審查。這會捕捉偶爾的幻覺（Claude 曾聲稱一個網站是用 Remix 構建的，當它顯然是 Next.js 時）並讓我們添加個人風格。

審查步驟每封郵件大約需要 2-3 秒，因為 Claude 95% 的時間都做得正確。我們使用簡單的 Supabase 儀表板視圖批量批准。

結果和我們學到的東西

我們自 Q1 2025 以來一直在運行此系統。以下是真實數字：

指標	我們的系統	行業平均值（2026）
打開率	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.2 秒」會被打開。「快速問題」不會。

回覆率很高，因為郵件展示了真正的技術知識。當 CTO 讀到一封郵件，正確識別他們的技術堆棧和真實性能問題時，他們更可能參與——即使他們知道這是外展。

什麼不起作用

完全自動化發送（無人工審查）： 我們試過這個兩週。Claude 大約 5% 的時間幻覺了技術堆棧細節。對於 LLM 來說，這是一個低錯誤率，但發送一封說「你的 React 應用」給某人運行 Vue 的郵件比發送通用郵件更糟。信任損害是真實的。

長郵件： 我們的第一個 Claude 提示生成了 8-10 句郵件。回覆率是我們現在用 4-6 句看到的一半。更短總是更好。

每天每個帳戶發送超過 40 封郵件： 可送達性下降到懸崖。30-35 是 2026 年的最佳點。

使用 Claude 為基於打開的後續操作生成： 我們試圖生成由打開觸發的後續郵件。後續操作感到咄咄逼人，轉換不值得成本。我們現在發送一個簡單的、非 AI 後續操作三天後。

成本明細

以下是此成本我們月度支出，處理大約 2,000 個潛在客戶：

服務	月度成本	說明
Hunter.io（初級版）	$49	500 次搜索 + 驗證
Anthropic API (Claude)	$45	~2,000 次研究 + 郵件生成
Supabase（專業版）	$25	數據庫、邊緣函數、Cron
Instantly（增長版）	$30	發送、預熱、分析
Google Workspace（3 個帳戶）	$21	發送基礎設施
域（3 個）	$10	攤銷年度成本
總計	~$180	$0.09 每個潛在客戶

與 Apollo 的 $79/月計劃（有限豐富、基本序列）或 Lemlist 的 $69/月每座位相比較。我們支出更少，得到的結果更好，因為個性化是真實的，不是基於範本。

就背景而言，此系統直接生成了潛在客戶，這些潛在客戶轉變為Next.js 開發和Astro 開發項目，價值為月度成本的 50-100 倍。ROI 是荒謬的。

常見問題

構建這個系統花了多長時間？ Firsting working version 大約花了兩週的部分時間工作——總共大約 40 小時。從那時起，我們一直在持續迭代，主要是微調 Claude 提示和添加邊界情況處理。如果你對 Supabase 邊緣函數和 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。一旦有人參與，他們應該得到真實的人。感興趣的潛在客戶被引導到我們的聯繫頁面或直接到通話預訂鏈接。

這種方法對非技術服務有效嗎？ Site analysis 部分是特定於網頁開發的，但架構模式——豐富潛在客戶、使用 AI 進行研究和個性化、通過專用工具發送——對任何 B2B 外展都有效。你只需不同的研究輸入。設計代理可能分析視覺設計和 UX 模式。營銷代理可能提取 SEO 指標。關鍵是為 Claude 輸入真實數據，而不是要求它編造東西。

維護這個系統最難的部分是什麼？ Prompt maintenance。當 Claude 模型更新時，工作完美的提示有時需要調整。我們也花時間監控電子郵件可送達性——檢查 Google Postmaster Tools、監視垃圾率飆升、輪換發送帳戶。總體上每週大約 2-3 小時的維護。

你會將此作為產品出售嗎？ 我們一直在考慮，但老實說，競爭優勢太寶貴了。如果每個代理商都運行這個確切的系統，有效性會下降，因為收件人會開始在任何地方看到 AI 研究的郵件。現在，我們將其保留為內部工具。如果你想幫助為你的業務構建類似的東西，聯繫我們——我們已經幫助一些客戶設置了類似的系統，作為我們無頭 CMS 開發工作的一部分。