將微信接入 Claude Code：WeChat Bot 設定實戰，讓訊息自動變成工作流程

¶ 微信不缺訊息，缺的是訊息之後的自動處理

不少團隊每天都在微信裡處理工作：客戶問產品怎麼設定，需要重新解釋一遍；使用者在群組裡回報問題，需要複製到工單系統；服務出現異常，需要找到負責人並通知；一天聊了很多，最後還要手動整理問題和待辦。

真正耗時的，往往不是「收到了訊息」，而是收到訊息之後的重複勞動。

如果微信訊息能夠直接進入 AI 和業務系統，聊天視窗就不只是溝通工具，也可以成為工作入口。

AceDataCloud WeChat Bot 提供了這樣的接入基礎：為使用者部署獨立雲端主機，執行真實微信桌面用戶端，再透過 HTTP 和 WebSocket 對外提供訊息能力；需要 AI 自動回覆時，可以進一步透過 WisdomChannel 連接 Claude Code。[1]

但要用好它，需要先分清三個層次：

WeChat Bot 解決微信接入，WisdomChannel 解決 AI 連接，業務系統解決具體業務動作。

本文依據產品頁面及 WisdomChannel 公開文件整理，設定範例未經過本文作者的實際部署測試。圖片為 AI 生成的架構與場景示意，不是產品控制台截圖；實際功能、版本和收費以目前服務頁面及文件為準。

¶ 一、技術特徵：不僅能回覆訊息，還能讓微信成為系統介面

WeChat Bot 技術架構：微信桌面用戶端、訊息介面、Claude Code 與業務系統

圖 1：技術架構示意，展示微信、訊息介面、AI 與業務系統之間的關係。

¶ 1. 獨立雲端主機承載真實微信桌面用戶端

根據產品介紹，每個使用者對應一台獨立雲端主機，透過手機微信掃碼登入；底層由 Wisdom 驅動真實微信桌面用戶端完成訊息收發，而不是採用第三方 Web 協議接入。[1]

這種設計把微信執行環境從日常辦公環境中分離出來：業務程式透過介面存取執行個體，不必直接操作桌面；微信登入狀態可以獨立檢查；出現異常時，有專門的執行個體環境可供排查。

需要注意，這不是微信公眾號或企業微信官方機器人介面的同義替代品。它依賴桌面用戶端及其執行環境，不能據此推導出「永不掉線」「不受版本變化影響」或「沒有帳號風險」。

¶ 2. HTTP 負責操作，WebSocket 負責即時事件

產品頁面列出的核心能力包括：[1]

能力	頁面明確提供的入口或說明	可以解決的問題
訊息發送	`/api/messages/send`，支援文字、圖片、檔案、影片	通知、回覆、資料發送
即時訊息監聽	WebSocket `/ws`	新訊息觸發處理流程
歷史訊息與搜尋	取得、重新整理會話歷史，依關鍵字搜尋	回溯溝通、質檢、分析
聯絡人與會話同步	同步聯絡人、會話清單	維護業務端會話資訊
狀態檢查	`/api/status`、`/ping`	檢查線上狀態與服務可用性
維運與驗證	獨立 `API_TOKEN`、掃碼登入、VNC 入口	存取控制與故障排查

可以把兩種介面簡單理解為：HTTP 是「請發送這則訊息」或「請查詢目前狀態」；WebSocket 是「有新訊息了，請開始處理」。

收到微信消息
    ↓
检查会话、发送者与访问权限
    ↓
AI 生成回答，或业务程序处理请求
    ↓
通过发送接口返回结果

如果接入生產業務，建議另外實作訊息去重、斷線重連、重試和頻率控制。不要在未核實協議細節前，假設訊息一定不會重複，也不要把介面請求成功直接等同於使用者已讀。

¶ 3. WisdomChannel 把訊息通道連接到 Claude Code

WisdomChannel 是面向 Claude Code 的微信 Channel 外掛。它透過 HTTP/WebSocket 連接遠端 Wisdom 服務，因此無需與微信桌面用戶端執行在同一台機器上。[2]

模式	工作方式	適合用途
互動式 MCP Channel	將微信訊息推送到正在執行的 Claude Code 工作階段	開發除錯、有人值守的輔助工作
`wisdom-channel bridge`	接收允許的訊息，呼叫 `claude -p`，再把回覆發回微信	無需互動式終端的自動回覆

背景自動回覆更適合從 bridge 模式開始。 它不需要持續附著的互動式 Claude Code 終端，但 bridge 程序本身仍然需要持續執行。[2]

¶ 4. 自動回覆有上下文，也有觸發邊界

WisdomChannel 支援私聊與群聊；群聊只在被 @ 時觸發，並結合存取策略決定是否處理訊息。bridge 建構回覆時還會使用發送者、群聊、引用訊息和最近的會話上下文。WECHAT_CONTEXT_MESSAGES 預設值為 8，設為 0 可以關閉最近訊息上下文。[2]

例如，使用者先問「Windows 上應該怎麼設定」，隨後追問「那 Token 填在哪裡」，第二句話就需要結合前文理解。最近訊息上下文有助於處理這種追問，但不代表系統天然擁有完整、永久的聊天記憶。

¶ 5. 權限控制不是附加項，而是核心能力

當微信連接到能夠呼叫工具的 AI 時，最重要的問題不只是「能不能回答」，還有：誰可以讓 AI 做什麼？ WisdomChannel 使用 access.json 管理使用者角色、私訊預設策略和群組聊天白名單。使用者權限採用穩定微信 ID，而不是僅依賴顯示暱稱；未列出的群組聊天會被忽略。對於 allow_tools=false 的角色，bridge 會透過 claude -p --tools "" 停用工具。互動式 Channel 模式則將權限資訊交給正在執行的 Claude Code 工作階段處理。[2]

部署建議從最保守的策略開始：預設不回應陌生私訊，只開放一個測試群組，一般使用者只能聊天，不在試行階段授予管理員工具權限。

先證明它能安全地回答，再考慮讓它執行操作。

¶ 二、設定指南：從掃碼登入到第一則 AI 回覆

WeChat Bot 設定路線：建立應用程式、掃碼、取得憑據、安裝、白名單和驗證

圖 2：建議設定路線，先驗證訊息鏈路，再開啟 AI 自動回覆。

以下採用 Windows PowerShell + bridge 的範例路徑。所有預留位置都需要替換為自己的實際資訊。

¶ 第一步：建立應用程式並掃碼登入

在 WeChat Bot 服務頁面建立應用程式，等待平台部署獨立執行個體，然後使用手機微信掃描控制台中的 QR Code 登入。

根據產品頁面，控制台會提供執行個體 API 位址、API_TOKEN 和 VNC 介面入口；Viewer 使用個別憑據，僅應用程式擁有者和平台管理員可見。[1]

實例 API 地址：以控制台實際顯示為準
API_TOKEN：實例訪問令牌
VNC 入口：出現桌面或登錄異常時排查使用

不要把 Token 放進公開儲存庫、部落格截圖或前端頁面。

¶ 第二步：先驗證介面，不急著接 AI

在 PowerShell 中設定測試變數：

$ApiUrl = "http://<你的实例地址>:8000"
$ApiToken = "<你的 API_TOKEN>"

$Headers = @{
    Authorization = "Bearer $ApiToken"
}

檢查服務狀態：

Invoke-RestMethod `
    -Uri "$ApiUrl/api/status" `
    -Headers $Headers `
    -Method Get

再向一位明確同意接收測試訊息的聯絡人傳送文字：

$Body = @{
    target = "<测试联系人>"
    type   = "text"
    text   = "你好，这是一条 WeChat Bot 连通性测试消息。"
} | ConvertTo-Json

Invoke-RestMethod `
    -Uri "$ApiUrl/api/messages/send" `
    -Headers $Headers `
    -Method Post `
    -ContentType "application/json; charset=utf-8" `
    -Body ([System.Text.Encoding]::UTF8.GetBytes($Body))

以上傳送欄位依據產品頁的文字訊息範例改寫；/api/status 是頁面公開列出的狀態檢查介面。[1]

如果傳送沒有達到預期，先檢查 API 位址和網路、Token、微信登入狀態、目標聯絡人比對情況，以及 VNC 中是否存在提示或異常視窗。

只有基礎訊息鏈路通了，才繼續接入 AI。

安全建議：範例沿用頁面展示的 HTTP 位址格式。生產環境不要把「帶 Bearer Token」理解為「傳輸已加密」；應結合執行個體部署條件設定 HTTPS、安全通道或網路存取限制。

¶ 第三步：準備 Python 和 Claude Code

WisdomChannel 文件要求 Python 3.10+、已登入的 Wisdom 服務，以及 Claude Code CLI v2.1.80+；bridge 還要求 claude 命令位於 PATH 中。[2]

python --version
claude --version

pip install wisdom-channel

接著在準備執行 bridge 的機器上完成 Claude Code 的登入或憑據設定，確認它能夠正常呼叫所選模型。

微信執行個體的 API_TOKEN 用於存取訊息服務，不是 Claude Code 的模型憑據。

¶ 第四步：設定執行個體連線資訊

建立設定目錄和 .env 檔案：

$ChannelDir = Join-Path $env:USERPROFILE ".claude\channels\wechat"

New-Item `
    -ItemType Directory `
    -Path $ChannelDir `
    -Force | Out-Null

@"
WISDOM_API_URL=http://<你的实例地址>:8000
WISDOM_API_TOKEN=<你的 API_TOKEN>
WECHAT_BOT_NAME=
WECHAT_CONTEXT_MESSAGES=8
"@ | Set-Content `
    -Path (Join-Path $ChannelDir ".env") `
    -Encoding utf8

上述路徑和環境變數來自 WisdomChannel 的設定慣例。WECHAT_BOT_NAME 留空時會自動偵測名稱，WECHAT_CONTEXT_MESSAGES 控制每次回覆擷取的最近訊息數量。[2]

建議先保留預設上下文數量，跑通流程後再根據回答品質、延遲和資料最小化要求調整。

¶ 第五步：先設白名單，再啟動自動回覆

在相同目錄下建立 access.json：

~/.claude/channels/wechat/access.json

以下是一個僅允許測試使用者和測試群組、不開啟工具權限的範例：

{
  "version": 3,
  "enabled": true,
  "roles": {
    "normal": {
      "allow_tools": false,
      "contexts": ["group", "private"],
      "prompt": "只回答公开、基础和一般性问题。不查看或修改内部项目、文件、日志、服务器或数据库。"
    }
  },
  "users": {
    "<测试用户的稳定微信ID>": {
      "role": "normal"
    }
  },
  "private": {
    "enabled": true,
    "default_role": "deny",
    "prompt": ""
  },
  "groups": {
    "<测试群的准确名称>": {
      "enabled": true,
      "default_role": "normal",
      "prompt": "",
      "members": {}
    }
  }
}

關鍵點是：users 中填寫穩定微信 ID，不要只填暱稱；未比對的私訊預設拒絕；群組名稱需要準確比對；一般使用者不開啟工具權限；群組聊天仍需符合 @ 觸發條件。

這些欄位及比對規則遵循 WisdomChannel 的存取控制文件；上面的範例主動移除了高權限管理員角色。[2]

¶ 第六步：測試連線並啟動 bridge

先執行不啟動 Claude Code 的獨立連線測試：

python -m wisdom_channel --test

然後啟動自動回覆：

wisdom-channel bridge --model sonnet

文件說明，前一個命令用於測試 REST 與 WebSocket；後一個命令執行自動回覆迴圈，並使用相同的存取策略和群組聊天 @ 規則。[2]

測試動作	預期結果
白名單使用者傳送私訊	正常回覆
白名單群內 `@` 機器人	正常回覆
白名單群內一般閒聊	不觸發回覆
非白名單使用者私訊	不回覆
一般使用者要求讀取伺服器檔案	不具備工具執行能力
使用者連續追問	檢查回答能否合理利用最近上下文

執行日誌位置為 ~/.claude/channels/wechat/mcp.log。[2]

¶ 第七步：把「能跑」變成「可維護」

bridge 不依賴互動式終端，不代表它會自動安裝成系統服務。正式使用時，建議補上：

程序託管： 異常結束後重新啟動，保留執行日誌。
狀態監控： 檢查執行個體、微信登入狀態和模型呼叫。
人工接管： 無法回答或需要承諾的事情轉交負責人。
回覆邊界： 不自動承諾退款、賠償、價格或交付時間。
資料保護： 明確哪些對話可以傳送給模型處理。
成本監控： 分別核實執行個體費用與模型呼叫費用。

這些屬於上線建議，不應誤認為產品已經內建完整的工單、監控或人工客服系統。

¶ 三、應用情境：從一個小流程開始，逐步放大價值

WeChat Bot 六類應用方向：客服、群組助手、告警、工單、品檢與個人助理

圖 3：六類應用方向。知識庫、工單和定時任務需要依業務需求另行整合。

下面是基於訊息收發、即時事件和 AI 連線能力設計的落地方向，不是開通後自動擁有的完整業務系統。

¶ 情境 1：客服問答，先處理重複問題

適合產品諮詢、使用說明、常見設定問題較多的團隊。

客戶提問 → 檢索經過審核的產品資料 → AI 組織回答
→ 傳送到微信 → 不確定時轉人工

例如，「API Token 在哪裡建立」「如何排查驗證失敗」這類標準問題，可以優先自動處理。

需要補齊： 產品知識庫、資料更新機制、人工接管流程。價值不在於讓 AI 回答一切，而是減少客服反覆輸入同一段說明的時間。

¶ 情境 2：群內助手，被叫到才回答

適合產品支援群、培訓群和開發者社群。使用者可以在群裡提問：「@助手，第一次接入需要準備哪些資訊？」

藉助白名單與 @ 觸發機制，可以把助手限制在指定群組內，避免它參與所有閒聊。

需要補齊： 群組用途說明、可回答範圍，以及需要引用的知識內容。建議先從「設定說明助手」這類邊界明確的角色開始，而不是一開始就承擔銷售、客服和維運所有職責。

¶ 情境 3：維運告警，把異常推送到常用溝通管道

適合已有監控平台的小團隊。

監控系統發現異常 → 告警服務分級、去重
→ 呼叫訊息傳送介面 → 通知指定聯絡人或群組

還可以進一步設計「回覆告警編號，查詢最近狀態」的互動，但這需要接入監控查詢介面。

需要補齊： 告警規則、限頻、去重和備用通知管道。微信可以是方便的通知入口，不宜成為關鍵故障的唯一觸達方式。

¶ 情境 4：工單流轉，減少複製貼上

適合大量問題從微信進入、又需要在工單平台追蹤的團隊。

使用者回報問題 → AI 擷取產品、現象和報錯資訊
→ 提醒使用者補充缺失欄位 → 呼叫工單系統 → 回傳工單編號

需要補齊： 工單 API、欄位對應、使用者身分關聯和重複工單判斷。

自動建立工單前，可以先讓使用者確認摘要：「我理解的問題是介面呼叫回傳驗證錯誤，是否依這個描述提交？」這樣能減少理解偏差帶來的錯誤紀錄。

¶ 情境 5：對話品檢，找到反覆出現的問題

適合希望從客服對話中改進產品的團隊。可以圍繞已授權、可取得的對話資料，設計每日或每週分析：哪些問題出現頻率最高？哪些設定步驟最容易卡住？哪些回答沒有解決使用者問題？哪些內容應該補進說明文件？

需要補齊： 定時任務、儲存、去識別化、分析規則和報告輸出。目標不是「收集越多越好」，而是在明確授權與保留期限的前提下，用必要的資料改進服務。

¶ 情境 6：個人助理，把零碎訊息整理成行動項目

適合希望統一記錄和整理入口的個人使用者。例如：「把我剛才傳的幾條內容整理成行動清單，標出需要補充的資訊。」

如果還想建立真實待辦、寫入行事曆或到時間提醒，就需要繼續接入相應系統。

需要補齊： 待辦或行事曆介面、排程機制、操作確認。「幫我整理一下」和「替我執行一下」是不同等級的權限。涉及外部寫入時，最好先展示結果，再由使用者確認。

¶ 四、使用前必須了解的邊界

¶ 1. 桌面自動化不等於微信官方介面

產品頁面要求遵守微信平台使用規範、合理控制傳送頻率和內容。[1] 真實桌面用戶端方案也不能保證不存在帳號或執行風險。不建議把它用於陌生人批量觸達、未授權群發或其他騷擾性自動化。

¶ 2. 接入 AI 不等於自動獲得業務知識

Claude Code 能生成回答，但你的產品政策、訂單、庫存、客戶權限和內部流程，都需要明確提供或透過受控介面查詢。涉及事實和承諾時，應優先依賴可信資料，而不是讓模型猜測。

¶ 3. 聊天內容不能直接成為系統授權

即使訊息來自白名單，也不應因為一句「忽略之前的規則」就擴大權限。建議把一般聊天與高權限操作隔離，對刪除資料、修改設定、付款和大量發送等操作設定獨立審核。

¶ 4. 不要把預期收益寫成效能承諾

公開介紹不足以確認具體部署耗時、吞吐量、回覆延遲、服務等級或全部費用。選型時應實際驗證這些指標，並以控制台方案和目前文件為準。

¶ 結語：先接通一個流程，再讓微信承擔更多工作

WeChat Bot 值得關注的地方，不只是「微信裡多了一個會聊天的機器人」。更有價值的是，它提供了一種將聊天與系統連接起來的方法：

微信負責接收需求，AI 負責理解和組織資訊，業務系統負責完成可驗證的動作。

如果準備開始，建議先做一個最小試點：

建立執行個體並掃碼登入。
驗證一則文字訊息的發送。
安裝 WisdomChannel。
只開放一個測試使用者或群組。
用 bridge 跑通自動回覆。
再接入一個真正有價值的業務流程。

不必第一天就做一個「萬能助手」。先讓它替你回答一類重複問題、轉發一類重要通知，或者整理一類客戶回饋，就已經是值得驗證的起點。

開始了解與設定 AceDataCloud WeChat Bot →

¶ 參考資料

AceDataCloud WeChat Bot 產品頁面：產品架構、介面能力、部署流程與使用注意事項。
WisdomChannel 設定與執行文件：環境需求、設定變數、存取控制、bridge 模式與日誌。
WisdomChannel 專案 README：開源用戶端說明與後續更新。

封面及三張正文示意圖使用 OpenAI gpt-image-2 生成。