如何開發一個微信AI滿足客戶營銷的需求？
我來分享一個完整的營銷 AI 項目。
這個營銷 AI 項目的起點是什么呢？我們團隊原來是做廣告營銷平臺的，有一套基于用戶、產品、標簽庫的多平臺廣告投放和多平臺自動化客戶營銷系統。
這是我們團隊原來提供的廣告平臺，營銷平臺的核心業務流程，你可以看看，理解項目背景。
圖片
當時我們想，至少有兩個產品方向可以借助微信 AI 這種模式。一個是企業營銷知識服務，以企業自身的知識庫為基礎，營銷平臺或廣告平臺可以通過微信 AI 的形式高效地觸達用戶。另外一個方向是潛在客戶的營銷，基于平臺現有客戶庫、潛在客戶庫，結合微信 AI 做老客戶運營和新客戶拓展。這個兩個方向的核心，都是 AI+ 微信的結合。
傳統營銷的痛點
一、優化客戶營銷服務
傳統服務難滿足即時性與個性化需求，AI 通過智能聊天機器人突破局限：7×24 小時響應減少用戶流失，結合用戶數據生成專屬消息（如優惠提醒、產品推薦），提升互動體驗。
二、革新營銷內容生產
傳統內容生成耗力、周期長，生成式 AI 可基于品牌、人群與場景，快速生成廣告文案、短視頻腳本等素材，并優化內容細節，兼顧生產效率與質量。
三、升級數據分析與投放
傳統數據分析低效、精準度低，AI 能快速處理海量數據，構建多維度用戶畫像，據此制定投放策略，實現廣告與用戶精準匹配，提升轉化率與資源利用率。
微信 AI 的設計
顯然，這些痛點不能一次解決。其實我們的整個項目經歷了微信群 AI 開發，多模態 AI 開發，基于 Agent 的營銷 AI 和營銷 Agent 平臺開發這 4 個階段。具體過程會在接下來文章里展開介紹，這節課我們先從基礎的 AI 結合微信交互開始。
先看看原有的廣告營銷系統的交互，我摘取了部分功能，比如營銷文章生成，多平臺廣告，數據分析，郵件營銷工具等等。
圖片
我們想的是這些功能都可以在微信的聊天界面中完成，下面是基于微信的 AI 界面交互設計。用微信 AI 聊天的形式實現這些功能，本質上是通過大模型的上下文識別能力獲得用戶的輸入，再調用后端能力實現具體功能。從設計角度看，前端微信結合 AI 的交互更加靈活高效，后端接入 AI 則增強了營銷系統的內核能力，整體上可以提升人機交互效率和系統運行效率。
圖片
到這一步，只能算有了一個設計藍圖。
微信 AI 的實現
在設計上，我們考慮了未來的營銷 AI 能力，具體實現上則開發了基礎的文本聊天功能。這個基礎版本的微信 AI 文本聊天功能是怎么實現的呢？
架構選型
要實現微信 AI 聊天功能需要解決兩個問題。首先需要一個支持 RPA 架構的微信機器人，實現微信消息的代理收發，以及一些微信界面的自動化操作。其次，AI 軟件需要對接大模型，實現對用戶聊天的代理。
比如上述交互中的 @AI廣告 這個消息前綴，目的就是讓 RPA 機器人在群聊中識別到用戶想調用 AI 能力，從而路由到對應的 AI 廣告機器人，讓機器人處理、回復這條消息。
圖片
我們選用了支持微信 RPA 的Python 庫 WXAuto。這個 Python 庫支持所有的微信代理操作，比如搜索群名搜索、讀取群列表、讀取群消息列表、模擬按鍵操作等。
假設我們要 hook 的微信群名稱是 “AI 營銷體驗群”，那只要組合這些微信代理操作就可以實現 RPA 的代理邏輯。
至于實現最終 AI 聊天的大模型，我們選擇的是 GPT 接口，經過一定的完善，搭建了一個 AI 微信機器人架構。具體實現思路，就是當程序接收到新的 @AI 廣告的消息內容后，AI 廣告機器人程序調用 GPT 的接口獲得回復，最后調用 RPA 把內容回復到群里并 @用戶。
圖片
GPT 開發對接
OpenAI 的對接開發相對容易，具體對接的時候需要先安裝相應的 Python 庫，并且在環境變量中設置你的 OPENAI_API_KEY。參考下面的代碼：
pip install openai requests
export OPENAI_API_KEY=your_openai_api_key假設用戶在群里 @AI廣告 機器人的消息是“請你寫一則廣告，主題是推廣一款新的 AI 軟件”，那么微信機器人實際上只是代理用戶的這條消息發送給 GPT，等待 GPT 回復消息，再將其轉發到群里。
也就是說，這里的一次 GPT 操作就是一個標準的 GPT 大模型接口調用。
import os
import requests
def get_chatgpt_response(prompt: str) -> str:
api_key = os.getenv('OPENAI_API_KEY') # 從環境變量中獲取 API 密鑰
url = 'https://api.openai.com/v1/completions' # OpenAI API 的端點
headers = {
'Authorization': f'Bearer {api_key}', # 設置授權頭
'Content-Type': 'application/json' # 設置內容類型
}
data = {
'model': 'text-davinci-003', # 使用 text-davinci-003 模型
'prompt': prompt, # 提供給模型的提示
'max_tokens': 1500, # 設置生成的最大 tokens 數
'temperature': 0.7, # 控制輸出的隨機性
'n': 1, # 返回一個結果
'stop': None # 可以設置停止標志
}
response = requests.post(url, headers=headers, jsnotallow=data) # 發送 POST 請求
result = response.json() # 獲取 JSON 響應
return result['choices'][0]['text'].strip() # 提取并返回生成的文本
# 示例對話
prompt = """
請你寫一則廣告，主題是推廣一款新的AI軟件
"""
# 調用函數
response = get_chatgpt_response(prompt)
print(response) # 打印響應GPT 接口調用的過程中有兩個核心參數。一個是 model：text-davinci-003，它代表標準的 GPT3 大語言模型。另一個是 prompt，也就是本次大模型調用的提示詞，在我們的場景里就是用戶像機器人的提問 請你寫一則廣告，主題是推廣一款新的AI軟件。
這里注意，如果是單次操作這段代碼并沒有問題，但是要支持用戶帶歷史消息的會話功能，則需要保存歷史會話內容，并且每次的 prompt 提示詞都要帶上整個歷史消息。
具體邏輯是每當用戶給 @AI廣告 機器人發送消息 message 時，都需要將這個消息增加到歷史會話列表上，再對 GPT 發起請求，而從 GPT 得到的 response 也要立即加入歷史會話列表。參考下面的示例：
...
# 示例對話
conversation_history = """
User: 請你寫一則廣告，主題是推廣一款新的AI軟件
AI: 這是一款全新的AI操作軟件
"""
#新增用戶提問
add_user_message(message="注意軟件的名字叫 智者AI")
conversation_history = """
User: 請你寫一則廣告，主題是推廣一款新的AI軟件
AI: 這是一款全新的AI操作軟件
User: 注意軟件的名字叫 智者AI
AI：
"""
# 調用函數
response = get_chatgpt_response(conversation_history)
print(response) # 打印響應
#新增歷史消息
add_response_to_history(response)我們注意到代碼中的 conversation_history 用 User 表示用戶的消息，用 AI 表示 GPT 回復的消息。其實這個格式你可以自己定義，只要能表示出兩個角色，GPT 就可以在它的引導下輸出適合這個角色的消息。
真實的微信 AI 要實現一套用戶消息存儲系統，每次用戶會話時只要重新組織這個 conversation_history 即可。參考下面一條新用戶消息的流程示意圖，會更好理解一些。
圖片
難點與挑戰
看起來似乎一切很順利，不過，在微信 AI 項目里，更多的難點和挑戰其實在 RPA 操作的部分，下面重點說幾個核心的經驗。
一、核心挑戰：RPA 輪詢效率瓶頸
RPA 基于界面操作模擬原理，為及時處理消息，需定時輪詢群消息 —— 即便群內無新消息，仍需執行輪詢動作。但隨著群數量增加，這種模式的效率會顯著下降，因此如何提升輪詢效率、減少無效輪詢次數，成為關鍵問題。若將 “挨個搜索群名稱檢查消息” 定義為基礎的 V1 版本，后續針對消息輪詢還迭代了兩個優化版本。
二、V2 版本優化：利用消息列表特性減少操作
為降低不必要的群搜索與界面操作，V2 版本核心邏輯是借力微信消息列表的固有特點：當群內有新消息時，該群會自動置頂至消息列表頂部?；诖?，RPA 無需遍歷所有群，只需讀取消息列表并從上到下檢查，直至遇到無新消息的群即可停止，大幅減少了無效操作。
三、V3 版本優化：置頂目標群實現效率最大化
V3 版本在 V2 基礎上進一步升級：先將所有 AI 相關的群設置為置頂狀態。這樣一來，RPA 僅需讀取置頂區域內 “有新消息的 AI 群” 即可 —— 若輪詢時段內無新消息，只需檢查第一個置頂群便停止；若有新消息，也能精準讀完所有有消息的置頂群后終止。該邏輯實現了輪詢性能與效率的最大化，徹底規避了對無關聯群的無效檢查。
圖片
下面是 V3 版本的消息輪詢機制核心代碼。
for who in new_list:
if new_msg_stop >= 1: #msg_stop數越大 漏消息越少
_debug("msg stop", flush=True)
break
#init
if who not in _old_list.keys():
init2(who)
#開始
wx_cli.ChatWith(who)
##嘗試獲取消息
try:
messages = wx_cli.GetAllMessage[-last_count:]
except Exception as e:
continue
...
##過濾消息
messages = wxmsg.filter(messages,filter_users)
md5 = wxmsg.md5(messages)
if md5 == _old_list_md5[who]:
_debug("no msg", flush=True)
#確認沒有消息
new_msg_stop = new_msg_stop + 1
continue
....挑戰 2，消息可靠性問題
一、核心訴求：消息系統的可靠性與完整性
對消息系統而言，可靠性是核心 —— 本質是確保消息收發的完整性，既要避免漏讀消息，也要防止重復發送。在微信 AI 項目中，RPA 通過讀取群消息列表實現消息獲取，但過程中面臨一個關鍵障礙：微信消息列表不提供消息 ID 與單條消息時間戳，這使得精準識別并提取最新消息變得極具挑戰。
二、痛點與折中方案：利用時間戳消息簡化處理
若直接存儲并比對整個消息列表，會對計算資源與數據存儲產生過高要求。為此，我們采用了折中方案：觀察到微信消息列表中，某一時段內的消息會附帶一條 “總時間戳消息”，以此為關鍵節點，僅存儲該時間戳之后新增的消息，并通過逐個比對的方式，精準篩選出最新消息，既降低了資源消耗，又保障了消息的可靠性。
三、結合 V3 輪詢：保障程序重啟后的消息完整
該方案進一步與 V3 版本的群輪詢機制結合：當程序重啟后，無需遍歷所有群，僅需關注有新消息的群。一旦某群出現新消息，立即將此刻的消息列表作為 “初始版本” 存儲，后續基于該版本與時間戳消息進行比對更新，從流程上確保了消息不會漏讀或重復處理，徹底閉環消息可靠性問題。（可參考示意圖輔助理解這一流程）
圖片
下面是用于消息排重的核心代碼邏輯。
##過濾消息
messages = wxmsg.filter(messages,filter_users)
md5 = wxmsg.md5(messages)
if md5 == _old_list_md5[who]:
_debug("no msg", flush=True)
continue
##有新消息
new_messages = wxmsg.find_new(_his_list[who], messages)
_debug(new_messages, flush=True)
if False == new_messages:
_debug("no new msg", flush=True)
continue
#更新歷史消息
_user_list = wxmsg.find_user(new_messages, _user_list, who)
_old_list[who] = messages
_old_list_count[who] = len(_old_list[who])
md5 = wxmsg.md5(_old_list[who])
_debug(md5, flush=True)
_old_list_md5[who] = md5挑戰 3，微信 RPA 穩定性問題
基于 RPA 的微信操作需要定期登錄，這對運營來說是一定的挑戰。我們的微信 AI 一直是企業內部試用和測試，所以問題不大。如果正式對外，應該用微信官方推薦的企業微信的接口。
自有模型訓練
一、新挑戰：消息量暴增與成本壓力
在前述三大挑戰（輪詢效率、消息可靠性）解決后，微信 AI 項目迎來新問題：產品推出后消息量迅速暴增，若持續使用 GPT 付費版本大模型，成本會大幅攀升。基于成本控制考量，我們決定放棄 GPT 付費模型，轉而搭建私有大模型，最終選定開源的 ChatGLM-6B 模型作為基礎版本。
二、模型效果爭議：參數量差距與場景適配
不少人會質疑：ChatGLM-6B 參數量僅 60 億，遠低于 GPT-3 的 1750 億，效果能否達標？答案需結合項目的營銷場景來看：普通營銷內容場景對輸出內容的復雜度、深度無過高要求，更側重響應速度與內容適配性。因此，小參數量模型在匹配場景需求的前提下，效果并不遜色于大參數量模型，完全能滿足營銷類客戶問答、互動的基礎需求。
三、商用優化：從微調至知識庫融合的工程實踐
為讓 ChatGLM-6B 達到商用標準，我們開展了多階段優化：初期，利用現有產品庫信息對模型進行微調，使其初步具備產品相關的問答能力；后期，將完整的產品知識庫數據接入大模型，讓模型在與用戶的實時會話中動態學習知識庫內容，進一步提升回答的準確性與針對性。最終，基于該模型搭建的 “AI 營銷客戶問答互動自動化系統”，完全滿足了項目的商用需求。
這是一個典型的在大模型會話中嵌入知識庫的方法。很多企業知識庫場景下，模型微調訓練的效果往往不如在會話中嵌入知識庫的方案。
小結
我希望你能記住兩點。一是對大模型能力的評估和掌握方面。從起初的 GPT 接口調用到后來的自有大模型訓練和使用，至少在目前營銷場景下，自研的小模型也有出色的表現，你在選擇模型的時候，也需要根據具體場景來考慮。
回應用戶的使用需求，在 RPA 基礎上做了很多優化工作，包括輪詢效率的提升、消息穩定性的改進等。這是這個案例里的技術價值，為后續開發繼續使用微信 AI 交互提供了基礎。
圖片
