DeskcommCRM 是什麼？1,973 星開源 AI 銷售 CRM，但 3 個「不會報錯的失敗」先決定你能不能用

你在 GitHub 上點了「English」。介面沒有變。沒有錯誤訊息，沒有紅字，什麼都沒有發生——它只是靜靜地把你送回葡萄牙文。

一句話結論：DeskcommCRM 是一套 1,973 星、MIT 授權的開源 AI 銷售 CRM，接 WhatsApp、可自架；但它是巴西產品，英文介面至今沒有實作，非葡語使用者要先想清楚再裝。

這篇不是要勸退。DeskcommCRM 的工程水準其實高於多數同星級專案——它自己在 README 裡承認的問題，比很多專案被人挖出來的還多。但它有三個「不會報錯的失敗」：畫面顯示成功，實際什麼都沒做成，或者做成了你不想要的事。

本文所有數字都在 2026 年 9 月 13 日從 GitHub API、官方 README 與專案 issue 直接取得，逐條標註出處。

DeskcommCRM 到底是什麼？

是一套自架的客戶關係管理系統，主打「用 AI 在 WhatsApp 上接單」。官方定位寫得很直白：Kommo、Octadesk、Intercom 的開放替代品。AI agent 負責接待、篩選客戶、推進銷售漏斗，全部跑在你自己的伺服器上。

項目	實測數值（2026-09-13）
星數 / Fork	1,973 ⭐ / 568 forks
真實訂閱者（watchers）	14
開放 issue	124
授權	MIT（無附加條款）
建立日 / 最後推送	2026-04-28 / 2026-09-12
技術堆疊	Next.js 16 + TypeScript + Supabase
介面語言	葡萄牙文、西班牙文（英文未實作）

先講它真正強的地方，因為這決定了後面三個坑值不值得你繞過去。

迭代速度是真的：2026 年 9 月 4 日到 9 月 11 日，八天內發了 10 個版本（v1.13.0 一路到 v1.19.0），9 月 12 日 v1.20.0 的 tag 已經推上去。README 裡的架構說明也不是行銷稿——196 個 REST route handler、每張多租戶資料表都有 RLS、CI 把「租戶隔離測試」設成硬性關卡。

最難得的是它的誠實。README 白紙黑字寫著：CI 跑 49 個 Playwright 測試裡的 48 個，唯一跑不到的那個叫 vps-fresh-onboarding——也就是「全新安裝」這條路。它自己加了一句：CI 綠燈不代表全新安裝走得通。會主動寫這句話的專案不多。

第一個坑：為什麼選了英文，介面還是葡萄牙文？

因為英文字典從來沒有被寫出來。這不是推測，是專案自己的 issue #755（2026-09-12 開，目前仍未關閉）寫的。

issue 描述的機制是：語言選單曾經提供過 English (US)，但 normalizarIdioma 這個函式收到 en 之後會回傳 pt-BR，畫面就繼續是葡萄牙文。提出者自己下了一句評語——這比沒有這個選項更糟，選了英文的人會以為產品壞掉。

「選單／中繼資料已經提供過 English (US)，但從來沒有過 en 字典……這比沒有這個選項更糟。」

DeskcommCRM issue #755，2026-09-12

安裝程式那一關更直接：語言只問兩個選項，葡萄牙文或西班牙文，連寫入 en 的路徑都沒有。

對華語使用者，這一條的實際意義比任何功能表都重要：你要嘛看得懂葡萄牙文，要嘛準備好自己補一套字典再維護它。中文更加不在路線圖上——連英文都還在排隊。

第二個坑：為什麼指令跑成功了，資料庫卻是空的？

因為那些 migration 檔案裡面沒有東西。這一條同樣是 README 自己寫的，而且我逐個檔案驗證過。

專案的 supabase/migrations/ 有 220 個檔案。其中編號 0001 到 0009 和 0013 這幾個，內容是一行 SELECT 1;——我直接抓了 0001、0002、0005、0009、0013 五個檔案的原始碼，五個都一樣。檔頭註解解釋了原因：這些 schema 當初是透過 Supabase MCP 直接套用到遠端的，留下空殼只是為了讓本地檔案清單對得上遠端紀錄。

後果 README 講得比我還白：supabase db push 會「通過」，然後留給你一個空的資料庫。

真正的 schema 住在另一個地方——supabase/baseline.sql，單一檔案 1,261,620 bytes，大約 1.2 MB。官方安裝腳本套用的是這一份。所以正確做法是套 baseline，不要套 migration 鏈。

這個坑之所以危險，在於它的失敗長得跟成功一模一樣。指令回傳正常、沒有錯誤碼，你要等到應用程式起不來、或者更糟——起來了但資料表是空的——才會發現。

第三個坑：為什麼刪一個聯絡人，會弄丟 90 則訊息？

因為刪除動作分成三次呼叫，中間沒有交易保護。這是 issue #752，由一位自架使用者在 2026-09-12 提出，跑的是 v1.17.0。

回報者附了 PostgREST 日誌，三行請求發生在同一個零點幾秒內：

DELETE /rest/v1/messages?contact_id=eq.<contact>       -> 204
DELETE /rest/v1/conversations?contact_id=eq.<contact>  -> 204
DELETE /rest/v1/contacts?id=eq.<contact>               -> 403

前兩行成功，第三行被擋。訊息和對話已經刪掉了，聯絡人還在。畫面上只顯示一句「內部錯誤，請稍後再試」。

觸發條件很具體：只要這個聯絡人在 calendar_appointments 有任何一筆紀錄，第三步就會因為外鍵限制被擋下來。回報者說兩次嘗試、不同日期，兩次都重現；實際測到的那次毀掉 90 則訊息，後來是從備份救回來的。

同一位使用者在同一天還開了兩張：issue #753 記錄有 8 種事件類型從第一天起就沒有任何消費者，626 筆卡在 pending 永遠不會被處理；issue #754 記錄 fn_decrypt_oauth 這支 RPC 持續有 10% 到 30% 的呼叫回 500，量測基準是 24 小時的日誌。

Issue	問題	對你的影響
#752	刪聯絡人無交易保護	🔴 不可逆資料遺失
#753	8 種事件無消費者，626 筆堆積	🟠 資料表只增不減
#754	解密 RPC 失敗率 10–30%	🟠 日曆憑證間歇失效
#755	英文未實作	🔴 非葡語使用者的決定性門檻
#765	OpenRouter 預設模型選不到	🟡 有替代路徑可繞

要持平地說：這幾張 issue 品質非常高——有 SQL 查詢、有日誌、有重現次數。一個有這種回報品質的專案，通常代表使用者夠認真、維護者夠願意收。但在它們修好之前，坑就是坑。

WhatsApp 那條線安全嗎？

有兩條路，風險差很遠。

第一條是掃 QR code，走 WAHA 這個第三方引擎。這等於用非官方管道操作你的 WhatsApp 帳號。DeskcommCRM 有做防護——節流、加隨機延遲、限制發送時段，README 直接把這組措施叫做「anti-banimento」（防封號）。這個命名本身就說明了風險存在。

第二條是 Meta 官方的 Cloud API，要用審核過的訊息範本。麻煩一點，但不會賠上號碼。拿真正在用的生意號碼去走第一條路之前，先想清楚這個號碼掉了你損失多少。

還有一個設定值得自己覆核。專案的 .env.example 把 webhook 簽章驗證預設關掉（WAHA_WEBHOOK_REQUIRE_SIGNATURE=false），理由寫著「WAHA Core 不簽章，開了會讓訊息接收整個斷掉」。但 WAHA 官方文件現在首頁就寫著「我們把 WAHA 變成免費了」，付費的 Plus 層已經收掉，改成選擇性的 $5/月 社群贊助。而 DeskcommCRM 安裝腳本釘住的映像檔版本是 latest-2026.7.2。

我沒有實際測過那個版本能不能簽章，所以不下結論。但這個註解是依據一個可能已經過期的限制寫的，而它決定了一個安全開關要不要打開——自架的人值得自己驗一次。

「沒有月費」是真的嗎？

授權費是真的零，跑起來的成本不是。

MIT 授權沒有任何附加條款，也沒有企業版、沒有功能鎖——這點我查過 GitHub 授權資料，是乾淨的 MIT。跟前陣子那些掛著開源名義、權重卻禁止商用的專案比，這裡沒有陷阱。

元件	要不要付錢
DeskcommCRM 本身	免費（MIT）
VPS	要付，README 建議 4GB RAM
Supabase	有免費方案，規模大了要升級
AI API key	要付，按用量計（OpenRouter／Anthropic／OpenAI 三選一）
WAHA	官方已改為免費，$5/月 社群層可選
Upstash Redis	README 稱免費層足夠

所以真正的月成本是「一台 VPS + AI token 用量」。AI 那塊會跟著對話量走——這是 AI CRM 跟傳統 CRM 最不一樣的地方：你的成本結構跟客人講幾句話綁在一起。

另外提醒一句，README 最上方那個 HostGator 的 VPS 連結是合作夥伴連結，專案自己有標註。這不算問題，標了就好，但你知道比較好。

它的 LGPD 合規，在香港台灣有用嗎？

幫不上。LGPD 是巴西的個資法，DeskcommCRM 的合規功能——資料匯出、去識別化、同意紀錄稽核——全部是照巴西規則設計的。

香港適用的是《個人資料（私隱）條例》，台灣是《個人資料保護法》。這些機制本身（可以匯出、可以匿名化、稽核紀錄保留五年）在哪裡都有用，但「符合 LGPD」不等於「符合你當地法規」，不要直接當成合規證明。

README 的免責聲明講得很清楚，這句對自架的人特別重要：誰架設這個實例，誰就是資料控制者，法律責任跟著走。維護者不碰你的資料庫，也不對它負責。

這個專案會不會做到一半停掉？

目前看不出停掉的跡象，但集中度很高。

20 位貢獻者裡，主要作者 melgarafael 有 3,494 次提交，第二名 jmpo 是 88 次。差距接近 40 倍。這種形狀的專案，維護風險基本上綁在一個人身上。

另一個值得留意的數字：1,973 顆星，但真正訂閱通知的只有 14 個人；反過來 fork 有 568 個。星是書籤，訂閱才是持續追蹤。fork 特別多的原因大概能從官方文件看出來——專案附了一份 white-label 指南，講怎麼換品牌、怎麼幫客戶一家一個安裝、怎麼轉售。也就是說，很多 fork 是拿去開生意，不是拿去改程式碼。

README 自己那句總結最準確：沒有 SLA，沒有保證支援，靠善意維護。

誰適合用？誰應該直接跳過？

你的情況	建議
看得懂葡／西文，生意靠 WhatsApp 談	✅ 值得認真試
要自架、資料不想放別人家	✅ 架構撐得住
想學多租戶 SaaS 怎麼寫	✅ 是很好的教材
只看得懂中文或英文	❌ 等 issue #755 做完
要接上正在用的生意 WhatsApp 號碼	⚠️ 走 Meta 官方管道，不要掃 QR
公司沒有人會維運伺服器	❌ 這是自架軟體，不是 SaaS
要拿去做客戶的正式生產環境	⚠️ 先等 #752 修好

如果決定要裝，怎麼避開這三個坑？

1. 先確認語言：安裝程式只會問葡萄牙文或西班牙文。選之前先確定團隊看得懂，不要指望裝完可以切英文。
2. 用官方安裝腳本，不要自己套 migration：跑 hostgator-setup-kit/install.sh，它套的是 baseline.sql。手動裝的話也要套 baseline，不要跑 supabase db push。
3. 先在測試機跑一輪：拿一個不重要的 WhatsApp 號碼、一台乾淨的 VPS，完整走一次。官方自己說 CI 沒有涵蓋全新安裝這條路。
4. 刪聯絡人之前先備份：在 issue #752 修好之前，把刪除當成高風險操作。先確認該聯絡人沒有日曆紀錄，或者乾脆不要用介面刪。
5. 確認事件佇列有在消化：用 issue #753 附的那段 SQL 查 event_log，看有沒有大量 pending 堆著。

不想踩坑，有什麼替代方案？

要自架又要 WhatsApp，Chatwoot 是成熟度更高的選擇，英文支援完整，社群大很多，缺點是 AI 功能要自己接。純粹想做流程自動化不一定需要完整 CRM，n8n 這類工作流工具接 WhatsApp API 也能做到類似效果，彈性更大。

如果你真正想要的是「AI 幫我處理重複工作」，而不是特定要一套 CRM，可以先看看 開源個人 AI agent 這個方向，或是 用 agent skill 把流程拆成可重用的模組。而在挑任何開源專案之前，先看清楚授權到底寫了什麼——掛 MIT 徽章但實際不是 MIT 的案例，今年已經出現過。

常見問題

DeskcommCRM 有中文介面嗎？

沒有。目前只有葡萄牙文和西班牙文真正可用，英文都還在 issue #755 排隊，中文沒有出現在任何規劃裡。

它是完全免費的嗎？

軟體本身是 MIT 授權，沒有付費版也沒有鎖功能。但要跑起來需要一台 VPS（官方建議 4GB RAM）和一支 AI API key，這兩項是實際支出，AI 費用會跟著對話量走。

用它接 WhatsApp 會被封號嗎？

掃 QR code 那條路走的是非官方管道，有風險，專案本身也內建了節流和發送時段限制這類防護措施。想避開風險就走 Meta 官方 Cloud API，設定麻煩一點但不會賠上號碼。

為什麼 supabase db push 之後資料庫是空的？

因為 migration 0001 到 0009 和 0013 的內容是 SELECT 1; 空殼，整條 migration 鏈無法從零建起。真正的 schema 在 supabase/baseline.sql，官方安裝腳本套用的是那一份。

現在適合拿來做正式生意嗎？

看語言和風險承受度。如果團隊看得懂葡萄牙文、又能接受 issue #752 這類資料遺失風險存在，可以先小規模試。要上正式環境，建議等 #752 修好，並且完整走過一次全新安裝測試。

結論：問題不在它爛，在它不是寫給你的

DeskcommCRM 是一個工程品質不錯、迭代很快、而且對自己的缺陷相當誠實的專案。它的 README 會主動告訴你 CI 涵蓋不到哪裡，它的 issue 區有品質很高的 bug 回報，它的授權乾淨。這些都不是隨便一個 1,973 星專案做得到的。

但它是為巴西市場寫的：介面是葡萄牙文，合規照 LGPD，電商整合接的是 Nuvemshop，連 commit 訊息都是葡萄牙文。這不是缺點，這是定位。

真正值得帶走的不是這套工具，而是那三個坑共同的形狀：它們都不報錯。選英文回傳成功，資料庫指令回傳成功，刪除失敗前那兩步也回傳成功。開源軟體最貴的從來不是壞掉的功能——是那些看起來運作正常、其實什麼都沒做成的功能。

下次評估任何開源工具，比起數星星，更該問一句：它失敗的時候，會不會告訴我？

資料來源

• melgarafael/DeskcommCRM — GitHub 倉庫與 README（星數、fork、授權、堆疊、免責聲明，2026-09-13 讀取）
• Issue #755 — 英文作為第一級語言（2026-09-12）
• Issue #752 — 刪除聯絡人無交易保護（2026-09-12）
• Issue #753 — 事件累積於 event_log（2026-09-12）
• Issue #754 — fn_decrypt_oauth 失敗率（2026-09-12）
• WAHA 官方安裝文件（免費化與 $5/月社群層，2026-09-13 讀取）

本文所有數據於 2026 年 9 月 13 日取自 GitHub API、專案 README 與公開 issue，開源專案迭代快速，實際情況請以官方倉庫最新狀態為準。本文不構成任何商業或技術採購建議，自架軟體的資料安全與法規遵循責任由架設者自行承擔。文中未收取任何形式的報酬或贊助。