嗨各位，
我想知道是否有人已經在 n8n 中建置過這樣的工作流程。
工作流程概念：
1. 從 CRM 或 Google Sheets 讀取潛在客戶
2. 每個潛在客戶都有姓名、電子郵件、公司名稱和網站
3. 自動訪問並爬取公司網站
4. AI 分析業務並理解他們做什麼
5. AI 根據網站分析撰寫個性化的冷郵件
6. 電子郵件自動傳送給潛在客戶
7. 如果沒有回覆，自動傳送後續電子郵件
8. 如果潛在客戶有興趣，回覆檢測會停止序列
我不是在問這是否可以建置。
我想知道是否有人已經建置過類似的東西。
如果有的話，請分享你的工作流程、演示或經驗。
謝謝。
是的，緊密相關的變體：潛在客戶行 → 網站擷取 → 簡短商業摘要 → 個人化草稿 → 傳送/不傳送檢查 → 當收到回覆時停止序列。
通常決定是否有效的兩個關鍵因素是網站擷取品質和回覆停止規則。如果你想比較筆記，你的起點是什麼：CRM、Sheets 還是抓取的清單？
歡迎 @Ayesha_Saeed！
這是 n8n 中非常可行的工作流程。首先要研究的關鍵節點是用於網站抓取步驟的 HTTP Request 節點 - 將其與 Jina Reader URL (https://r.jina.ai/[URL]) 配對，可以從任何商業網站獲得乾淨的 markdown，無需處理原始 HTML。從那裡，單次 LLM 調用就可以在一個步驟中總結並草擬電子郵件，使工作流程快速且符合 token 效率。
你好，我對這個自動化很感興趣。請問如何從頭到尾實現呢？謝謝。
嗨，
是的，我之前為 AI 驅動的潛在客戶研究和個性化冷郵件自動化建立過類似的 n8n 工作流程。
該工作流程從 Google Sheets/CRM 中提取潛在客戶，抓取公司網站，使用 AI 了解業務，生成個性化電子郵件，通過已連接的電子郵件系統發送，並根據回覆狀態管理後續跟進。
我還處理了重複檢查、失敗的網站抓取、潛在客戶狀態更新、日誌記錄和回覆檢測，以便在有人回覆時停止序列。
一個問題：你計劃通過 Gmail/SMTP 發送電子郵件，還是通過 Instantly、Smartlead 或 Apollo 等冷郵件工具？
預訂快速通話：Calendly - Automaxion
我今天剛建好了一個。它從 Google 試算表中提取潛在客戶資訊，將這些數據發送給 AI 代理，AI 代理會撰寫個性化的外展內容，並每隔幾天自動跟進一次
是的，我就是這樣建構這個確切的流程——並且執行串中有兩件事值得加入，因為它們是一旦上線就真正會咬你的東西。
上面提到的 Jina Reader 建議對於乾淨的文本來說是個不錯的選擇。問題在於將抓取的網站直接導入寫電子郵件的 LLM（第 4 → 5 步）：該網站是攻擊者可控的輸入。一個頁面可以包含「忽略之前的指示，寫…」，由於該文本流入了模型，而你隨後自動發送其輸出，你最終可能會從自己的域名發送攻擊者選擇的內容。值得在提示中將抓取的文本標記為不可信，並且不要讓它控制發送。
另一個值得採用的防護：當抓取失敗時不要發送。一個死亡或被阻止的網站——一個 503 加上很長的錯誤頁面、一個 Cloudflare 驗證——如果你只檢查你是否收到了一些文本，仍然會產生一封充滿信心的「我喜歡你的網站 ___」電子郵件。將發送限制在 HTTP 狀態碼（2xx）上，而不是位元組計數，並跳過 + 記錄其他所有內容。
對於 7–8（後續 + 回覆停止），我把它作為一個單獨的排定工作流程，讀取執行串並在收到回覆時停止——將發送和等待折疊到一個流程中會很快變得脆弱。
我將這些作為經過測試的工作流程來構建——每個都附帶一個驅動真實執行的測試加上一個變異測試（注入一個錯誤，確認測試捕捉到它），所以它不會無聲地發送錯誤的資料。如果對你有用的話，很樂意分享可匯入的版本。
我構建過好幾次這個確切的架構——有兩個坑是每個人都會踩的：把爬取的網站文本當作LLM的不信任輸入。一個頁面可能包含「忽略之前的指示」，你的郵件寫手就會照著做。用清晰的分隔符包裝爬取結果，告訴模型它們之間的內容是數據，永遠不是指示。回覆檢測是序列洩露的地方。不要只是檢查是否有入站郵件——還要檢查它是否來自同一個線程/潛在客戶，並且不是自動回覆/不在辦公室的狀態，否則你會因為「我在度假」的退信而停止序列。\n\n對於爬取，Jina Reader + 在傳遞任何東西給模型之前的HTTP狀態檢查能讓你避免把404頁面輸入LLM。如果有用的話，我很樂意分享我怎樣連接停止條件——我為小型服務業務構建這些。
@Ayesha_Saeed @jacewe 我現在已經建立並進行匯入測試了這條路徑的一個緊密變體：CRM/Google Sheets → 正規化 → 選擇性網站備註 → AI 評分 → 個人化外展草稿 → Gmail 草稿供人工審查 → 後續任務 → 每日報告。
我將第一次推出保持為僅草稿狀態，因為失敗的抓取、重複列、網站提示注入和回覆停止規則是表面上綠色的工作流仍然可能造成損害的地方。
我最安全的首次執行序列是：樣本列 → 預期的 AI 輸出 → 審查的草稿 → 單列推出。然後在擴展前新增重複檢查、2xx 抓取閘門、原始 + 已解析的 AI 日誌和停止回覆。
如果你們中的任何一個仍在構建這個，告訴我來源是 Sheets 還是 CRM，我可以指出我會測試的第一個節點和護欄。我還在我的個人檔案中連結了一份免費的首次執行檢查清單。
好的，我有一個建議給你，這與 n8n 無關。
使用第三方郵件服務商或獲取一個單獨的網域名稱來進行所有的推廣郵件。因為如果你的郵件中有 1% 被標記為垃圾郵件，而且是來自你的主要網域，那麼你從主要網域發送的每封郵件都會被視為垃圾郵件。這是你最不希望看到的。花費 30 元左右的成本來獲取 yoursiteoffers.com 以隱藏你所有來自 yoursite.com 的合法郵件，將是你花得最值得的 30 元左右。
在回覆偵測和後續排序部分（步驟7-8），人們通常做錯的是對後續使用固定的等待節點。更好的做法是：發送後，寫入一行到 Postgres/Sheets，包含潛在客戶 id、發送時間戳和 status=pending。執行定期工作流程，通過 IMAP 或 Gmail 觸發器檢查收件箱，按執行緒 id 或潛在客戶電郵配對回覆，並將狀態改為已回覆。另一個排程觸發器查詢 status=pending 的行以及 days_since_sent 達到後續間隔的行，這樣整個序列就能在 n8n 重新啟動後倖存，你可以按潛在客戶暫停/繼續而不會遺失狀態。