CRM 變垃圾場？別怕！讓 AI 當你的數據清道夫，用 LLM 自動化資料清洗，根治重複與錯誤資料！
☰ 目錄 table-of-contents.md
CRM 髒數據，交給 LLM 半自動清洗
「王大明」「王 先生」「David Wang」三筆資料躺在 CRM 裡，其實是同一個人；旁邊還堆著格式錯亂的 email 和缺碼的電話。這種髒數據再寫一百條正規表示式（Regex）規則也救不回來，因為問題出在「語意」而不是格式。把語意判斷交給大型語言模型（LLM），半自動完成資料清洗，才是最省力的根治法。
本文要回答的核心問題是：怎麼用 LLM 自動化 CRM 資料清洗，根治重複與錯誤資料？結論先講——做法是把清洗任務拆成「重複合併、欄位標準化、修正補全」三類，用一個精準的 Prompt 讓 LLM 輸出結構化 JSON，再透過 n8n 這類自動化工具串接觸發、呼叫 API、寫回 CRM。但有三個前提你必須守住：成本要先小規模測試、敏感個資要脫敏、結果要有人工審核閘門。下面我以工程師的視角完整拆解。
CRM 髒數據是每個老闆、行銷和業務都頭痛的問題：想寄 EDM，一堆 email 格式錯誤；業務想打電話，發現號碼少一碼；分析報表時，同一個客戶出現三次，業績灌水、分析失準。這就是典型的「垃圾進，垃圾出（Garbage In, Garbage Out）」困境。
為什麼你的 CRM 總是亂七八糟？問題的根源
就像醫生看病得先知道病因，理解髒數據的來源，才知道 LLM 該補在哪一段。CRM 數據變髒，通常不出這幾個原因：
- 人工輸入錯誤：業務手動 Key-in 客戶資料時，打錯字、漏填欄位、格式不統一，都是家常便飯。
- 多渠道數據匯入：客戶可能來自官網表單、LINE 官方帳號、Facebook 粉絲頁、實體活動。每個來源的數據格式都不一樣，匯總進來自然就亂了——整合不同平台的用戶身分本身就是一大挑戰。
- 缺乏統一的數據標準：「公司地址」欄位，有人填「台北市信義區」，有人填「北市信義區」；「職稱」欄位，有人填「CEO」，有人填「執行長」。沒有標準，就沒有一致性。
- 系統之間同步問題：當 WordPress 網站、電商系統和 CRM 之間的 API 串接沒做好，資料同步時就可能產生重複或遺失。
這些髒數據的代價非常高昂：行銷活動精準度下降、客戶體驗變差（誰想收到稱謂錯誤的信件？）、業務團隊效率低落，最終導致錯誤的商業決策。
先分清楚：哪些問題該用 LLM，哪些不該
這點很重要，能幫你省下大筆 API 費用。並不是所有清洗都需要 LLM：
| 問題類型 | 建議工具 | 原因 |
|---|---|---|
| 去除前後空白、轉大小寫、固定格式轉換 | 傳統程式 / Regex | 規則明確、零歧義，跑 Regex 又快又免費 |
| email 語法是否合法 | 傳統驗證函式 | 有標準規格可驗，不需語意判斷 |
| 判斷兩筆資料是不是同一個人 / 同一家公司 | LLM | 需要理解別名、簡稱、語意，規則窮舉不完 |
| 把混亂的地址、公司名稱、職稱標準化 | LLM | 輸入變化太多，靠語意理解才有彈性 |
| 推測筆誤（如網域打錯） | LLM | 需要上下文與常識推理 |
原則很簡單：規則寫得出來、且不會例外爆炸的，就用傳統程式先過一輪；剩下需要「判斷」而非「比對」的，才丟給 LLM。這樣能大幅壓低 token 成本。
LLM 憑什麼解決這個陳年老問題？
傳統清洗工具（Excel 公式、基於規則的軟體）很死板：你設定一條規則，它就執行一條，無法理解「浪花科技有限公司」和「浪花科技」其實是同一家公司。LLM 的強項在於「語意理解」和「上下文推理」——它判斷的是字串背後的「實體（Entity）」是否相同，而不是字串是否完全相符。這個概念在資料工程裡叫做實體解析（Entity Resolution），過去要靠複雜的相似度演算法和大量人工調參，現在用自然語言指令就能逼近。
LLM 在資料清洗上的三種能力
- 重複資料合併（De-duplication）：LLM 可以理解「陳大文」、「David Chen」、同一網域的 email 可能指向同一個人，並給出合併建議。它看的是背後的實體是否相同，而非字串是否相符。
- 欄位標準化（Standardization）：丟給它一堆格式混亂的地址、電話、公司名稱，下指令「把地址轉成標準格式，電話統一加上國碼」，LLM 能像訓練有素的助理一樣完成。
- 數據修正與補全（Correction & Enrichment）：看到「test@gamil.com」，LLM 能推測這是「test@gmail.com」的筆誤。這類靠常識推理的修正，是規則最難涵蓋的部分。
換句話說，你不再需要寫上百條規則去應對各種狀況，只要用「人話」告訴 LLM 你想要的乾淨狀態即可。但要提醒：補全（Enrichment）若涉及「去外部找公司統編、產業類別」這類資訊，必須改用可信的官方資料源或專門的 API，不要直接相信 LLM 生成的事實型資料——這正是模型最容易產生幻覺的地方。
實戰演練：用 n8n + LLM 打造 CRM 自動清洗工作流
來點實際的。身為熱愛自動化的工程師，我最喜歡的組合拳就是用 n8n 這類自動化工具串接各種 API。下面拆解一個概念性的工作流程，自動清洗一筆新加入 CRM 的聯絡人資料。
步驟一：設定觸發器（Trigger）
工作流的起點，通常是一個 Webhook。當你的 CRM（例如 HubSpot、Salesforce）有新聯絡人建立時，就觸發 Webhook，把新聯絡人的資料送到 n8n。
步驟二：傳統規則先過一輪（前處理）
在送進 LLM 前，先用便宜的方式做掉確定性的清理：去掉前後空白、把全形符號轉半形、過濾掉明顯不需要 AI 判斷的欄位。這一步能讓 Prompt 更短、結果更穩、費用更低。
步驟三：準備 Prompt（核心關鍵）
這是整個流程最核心的部分：如何跟 LLM 溝通。一個好的 Prompt 就像一份清晰的需求規格書，要包含「角色設定、規則清單、輸出格式限制、原始資料」四個區塊。
假設我們從 CRM 拿到以下這筆有點亂的資料：
{
"name": "陳 先生",
"email": "david.c@roamertech.com",
"phone": "0912-345-678",
"company": "浪花科技股份有限公司",
"address": "110 台北市信義路5段7號"
}我們可以這樣設計 Prompt：
你是一位專業的資料分析師，你的任務是清洗並標準化以下的客戶 JSON 資料。
請遵循以下規則：
1. name: 移除稱謂（例如先生、小姐），並修正不必要的空格。
2. phone: 轉換成 E.164 格式（+886 開頭，移除所有非數字字元）。
3. company: 盡可能簡化為通用的公司簡稱。
4. address: 移除郵遞區號，並確保地址格式流暢。
5. 根據以上資料，新增一個 name_suggestion 欄位，提供一個可能的英文名（如果 email 中有的話）。
請以 JSON 格式回傳你處理完的結果，不要包含任何解釋性文字。
這是原始資料：
{DATA_FROM_CRM}幾個讓 Prompt 更可靠的小技巧：
- 明確要求只回 JSON：加上「不要包含任何解釋性文字」，避免 LLM 多嘴導致後續解析失敗。
- 規則用編號條列：一條一個指令，比一大段敘述更容易被精準執行。
- 不確定就留空：可以加一句「無法確定的欄位請維持原值或留空，不要自行編造」，降低幻覺風險。
步驟四：呼叫 LLM API
在 n8n 中，使用 OpenAI 或 Google Gemini 節點，把組合好的 Prompt 送出去。這裡要注意：你可能會遇到 API 的 Rate Limit 問題，記得設計好重試機制——例如指數退讓（Exponential Backoff）策略，第一次失敗等 1 秒、第二次等 2 秒、第三次等 4 秒這樣逐步拉長間隔，避免短時間內反覆撞牆把 API 打掛。
步驟五：解析回傳結果並更新 CRM
順利的話，LLM 會回傳一個乾淨的 JSON 物件，大概長這樣：
{
"name": "陳",
"email": "david.c@roamertech.com",
"phone": "+886912345678",
"company": "浪花科技",
"address": "台北市信義路五段七號",
"name_suggestion": "David Chen"
}資料瞬間清爽多了。接下來在 n8n 中使用 CRM 的節點，把標準化後的資料更新回對應欄位。整個過程全自動，從此告別手動複製貼上。
別忘了：在寫回前加一道驗證閘門
LLM 回傳的不一定是合法 JSON，也可能漏欄位。寫回 CRM 前，務必做兩件事：一是用程式驗證回傳內容能否成功解析成 JSON、必要欄位是否齊全；二是對關鍵欄位（如 email、電話）再跑一次傳統格式驗證。任何一關不過，就把這筆資料轉進人工審核佇列，而不是直接覆寫原始資料。
工程師的小囉嗦：注意事項與最佳實踐
用 LLM 做資料清洗雖然很香，但身為資深工程師，還是得提醒幾個「魔鬼細節」：
- 成本考量：LLM API 通常按 token 計費。資料量大時這是不小的開銷，建議先小規模測試、評估 ROI，並善用前面提到的「傳統規則先過濾」來縮短 Prompt。
- 資料隱私：千萬不要把客戶高度敏感的個資（如身分證號、信用卡號）直接傳給公開的 LLM API。送出前務必做好資料脫敏，或考慮使用企業級的私有化部署方案。
- 建立驗證機制：AI 不是萬能，也可能出錯或「產生幻覺」。對重要資料建立「待審核」機制：當 LLM 對某筆清洗結果信心不足時，先標記起來讓人做最終確認。
- 絕不直接覆寫原始資料：清洗結果建議寫進新欄位或保留版本，至少保有可回溯的原始值。萬一 LLM 判斷錯誤，你還救得回來。
- 迭代優化你的 Prompt：Prompt Engineering 既是藝術也是科學。第一版 Prompt 通常不是最好的，要根據實際回饋不斷調整。
結論：擁抱 AI，讓數據真正成為你的資產
CRM 資料清洗不再是苦差事。透過 LLM 的語意理解能力，結合 n8n 這類自動化工具，我們可以打造一個全天候運作的智慧數據清道夫。但請記得本文一再強調的紀律：確定性的清理交給傳統規則、判斷性的工作才交給 LLM、敏感資料要脫敏、結果要有人工審核閘門。守住這四點，自動化才不會反過來製造新的髒數據。
數位轉型的核心是數據驅動，而這一切的基礎，都建立在高質量的數據之上。別再讓你的 CRM 繼續當垃圾場，是時候讓 AI 來幫你大掃除了。如果你想把 AI 導入現有 CRM、或打造客製化的自動化清洗流程卻不知從何下手，歡迎與浪花科技的團隊聊聊，我們很樂意協助你把數據潛力完全釋放出來。
延伸閱讀
常見問題
用 LLM 清洗 CRM 資料時，哪些任務該交給 LLM、哪些該用傳統程式？
LLM 在 CRM 資料清洗上能做哪些事？
怎麼設計 LLM 資料清洗的 Prompt 比較可靠？
用 LLM 清洗 CRM 資料有哪些必須注意的風險與最佳實踐？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。