教程)
1. 為什么是 Coze Kimi而不是其他方案1.1 微信客服這件事到底難在哪做微信客服這事我前后折騰了差不多兩個星期才跑通第一版能用的。先說說大家都會遇到的痛點微信號和公眾號的自動回復(fù)能力非常有限公眾號后臺自帶的歡迎語、關(guān)鍵詞回復(fù)本質(zhì)上就是一套死板的規(guī)則引擎。用戶問“你們家產(chǎn)品多少錢”你得先設(shè)好“價格”這個詞用戶恰好發(fā)了包含這個詞的消息才可能觸發(fā)一句預(yù)設(shè)文案。稍微繞一點的問法比如“你家那款新出的適合干皮的洗面奶還有貨嗎”規(guī)則引擎基本就廢了。最要命的是規(guī)則是靜態(tài)的沒法記憶上下文。用戶說“那幫我下單一支”系統(tǒng)根本不知道“那”指的是哪支。這些問題不是靠多寫幾條規(guī)則能解決的需要的是真正的自然語言理解能力。我自己也考慮過從零訓(xùn)練一個模型不說算力成本光是數(shù)據(jù)標注這一關(guān)就夠喝一壺的。后來換了個思路用成熟的大模型平臺做應(yīng)用編排把模型的智商拿過來自己只負責(zé)業(yè)務(wù)邏輯。1.2 方案選型踩過的坑在確定 Coze Kimi 之前我試過好幾條路。先是拿開源模型私有化部署機器配置要求高效果還飄經(jīng)常答非所問。然后試過直接用某大廠平臺自帶的模型智商是夠了但它的默認模型在中文長文本理解上總差一點意思尤其是你喂給它一份幾十頁的產(chǎn)品手冊時它經(jīng)常把關(guān)鍵參數(shù)記串了。最后朋友跟我說你試試在 Coze 上接 Kimi我才開始摸這個組合。這里得先說清楚Coze 和 Kimi 是兩樣?xùn)|西分工不同。Coze 是一個 AI Bot 搭建平臺你可以在里面創(chuàng)建機器人、配置模型、接知識庫、設(shè)置工作流最后發(fā)布到各個渠道包括微信公眾號。Kimi 是另一個團隊做的國產(chǎn)大模型主打超長上下文和中文理解能力。Coze 本身也提供模型但你可以接入第三方模型Kimi 就是其中一個選擇。兩個拼在一起的意思是Coze 負責(zé)“骨架”比如日志、渠道、回話邏輯Kimi 負責(zé)“腦子”也就是實際生成回答的語言模型。1.3 這套組合解決了什么核心問題第一是自然語言理解。用戶說的話不需要嚴格匹配關(guān)鍵詞Kimi 能理解近似表達。第二是長上下文。Kimi 在處理長文本上有優(yōu)勢這意味著你可以把你的產(chǎn)品手冊、售后政策直接丟給它當“參考資料”不用像傳統(tǒng)方案那樣把內(nèi)容拆得稀碎。第三是可維護性。Coze 上改一個 Prompt、換一份知識庫不用改代碼運營同學(xué)也能上手。提示如果把整個 AI 聊天機器人比作一家餐廳Coze 是前廳和收銀臺Kimi 是大廚。前廳負責(zé)接待、傳菜、結(jié)賬大廚負責(zé)把原料做成菜。別指望收銀員能把菜炒好也別讓大廚去管顧客排隊。2. 搭建前的準備清單2.1 三個賬號一個都不能少動手之前先把賬號備齊。第一個是 Coze 平臺的賬號用手機號就能注冊建議注冊后立刻實名認證不然發(fā)布渠道的時候可能會卡住。第二個是 Kimi 開放平臺的賬號需要拿到一個 API Key這個 Key 就是 Coze 調(diào) Kimi 的憑證。第三個是最容易忽略的一個微信服務(wù)號或者具備相應(yīng)能力的公眾號。這里要重點提醒微信訂閱號和服務(wù)號權(quán)限差異非常大。服務(wù)號有開發(fā)者接口權(quán)限AI 客服的自動回復(fù)、消息事件推送都依賴這些接口。訂閱號的接口權(quán)限少很多個人訂閱號想接 AI 客服非常費勁不推薦。如果你只是個人玩一玩可以先用測試號但正式商用必須認證的服務(wù)號這一步得提前準備好。2.2 微信側(cè)權(quán)限自查公眾號后臺你能收到用戶的普通消息這是前提。AI 客服要正常工作需要公眾號開啟“服務(wù)器配置”并且具備消息加解密能力。你不需要提前懂怎么填代碼因為 Coze 會給你一串 URL 和 Token你只需要把這些值填到公眾號后臺的對接頁面里即可。但是注意一旦你開啟了“服務(wù)器配置”公眾號后臺自帶的那些自動回復(fù)規(guī)則就會失效。也就是說必須讓 Coze 完全接管會話不存在“AI 管一部分、規(guī)則管一部分”的平滑切換。2.3 需要理解的三組基礎(chǔ)概念在配置之前先花三分鐘理解幾組概念不然后面你會看得一頭霧水。第一個概念是“Bot”就是你在 Coze 里創(chuàng)建的機器人。每個 Bot 有自己的人設(shè)、知識庫、技能和工作流。第二個是“工作流”可以理解為一種流程編排比如“先判斷用戶問的是售前還是售后如果是售后再查知識庫里的退換貨條款”。第三個是“知識庫”就是把你的業(yè)務(wù)資料以文檔形式導(dǎo)入機器人回答時會先檢索相關(guān)知識再結(jié)合模型生成內(nèi)容。理解這三個概念之后整個系統(tǒng)在你腦子里的畫像就清晰了用戶在公眾號發(fā)消息 → 消息被推到 Coze → Coze 根據(jù) Bot 設(shè)置決定調(diào)用 Kimi 還是先走工作流 → Kimi 生成回答 → Coze 把回答發(fā)回公眾號。3. Coze 里完成一個能聊天的機器人3.1 創(chuàng)建 Bot 和選擇模型登錄 Coze 平臺后在“工作臺”里找到“創(chuàng)建 Bot”按鈕選一個空模板開始。名字隨意但推薦直接叫“XX客服”方便后期在發(fā)布渠道里識別。創(chuàng)建完成后進入編排頁面這時候最關(guān)鍵的一步就來了配置模型。Coze 默認用的是平臺自帶的模型你需要在模型的設(shè)置區(qū)域找到“自定義模型接入”之類的入口把 Kimi 的 API 信息填認進去。按我實際填充的經(jīng)驗一般需要填這幾項API Base URL: https://api.moonshot.cn/v1 API Key: sk-**************** Model Name: moonshot-v1-32k 或 kimi-latest不同版本界面文字可能不完全一樣但核心邏輯是在 Coze 的“模型配置”里改接你 Kimi 的接口地址和密鑰。填完可以先發(fā)一條測試消息如果回話正常說明 Kimi 已經(jīng)通了。實操心得建議 API Key 單獨建一個不要用復(fù)用那個有最高權(quán)限的賬號秘鑰。這樣就算 Key 有一天被誤發(fā)到群里你也能快速吊銷重換。3.2 人設(shè) Prompt 的寫法決定回答質(zhì)量模型選好了接下來就是給 Bot 立規(guī)矩。這個環(huán)節(jié)在 Coze 里叫“人設(shè)與回復(fù)邏輯”本質(zhì)上你是在寫一段 Prompt。我踩過的坑是一開始人設(shè)寫太短就一句“你是一個客服”結(jié)果 Kimi 什么都說經(jīng)常自我發(fā)揮。后來按照一個模板重寫效果一下子穩(wěn)了。我的模板大概是這樣的思路先定義角色身份和任務(wù)邊界再給回答格式和語氣要求最后把禁忌寫清楚。你是一家園藝用品店鋪的客服“小花老師”。 用戶可能詢問產(chǎn)品、物流、售后等問題。 回答問題前先看知識庫里是否有關(guān)鍵詞不要憑記憶編造。 回答控制在 100 字以內(nèi)語氣親切不加表情符號。 遇到不懂的問題回復(fù)“這個我還不確定已經(jīng)幫你記下來了稍后有專人回你?!?絕對不要討論政治、不要給出與商品無關(guān)的建議。Prompt 不是越復(fù)雜越好但邊界越清晰越好。尤其是“不要編造知識庫外的內(nèi)容”這句話一定要寫否則大模型會在不知道答案的時候一本正經(jīng)胡說八道。還要注意回答長度客服場景不適合長篇大論用戶在微信上等回復(fù)不耐煩看大段文字。3.3 知識庫的正確打開方式知識庫是這套方案里性價比最高的一環(huán)。你有兩種方式導(dǎo)入一種是直接上傳文檔比如 PDF 產(chǎn)品手冊、Word 售后政策Coze 會自動切片并向量化。另一種是使用“在線數(shù)據(jù)”比如你店鋪里的商品列表每隔一段時間同步一次適合商品經(jīng)常變化的場景。我第一次導(dǎo)入時犯了一個錯誤一份產(chǎn)品手冊 80 多頁我全部傳上去了結(jié)果回答問題時知識庫命中老是跑題。后來把手冊按產(chǎn)品線拆成五六個文件每個文件前面加一句“本文件包含以下產(chǎn)品的規(guī)格……”這樣的導(dǎo)航性描述命中率立刻上來了。注意知識庫不是一次性建好就完事的。商品價格變動、促銷活動上線、退換貨政策更新都需要同步維護。建議每周更新一次并在更新完成后實測三個典型提問確認沒有檢索亂掉。3.4 參數(shù)調(diào)節(jié)那些事Coze 的模型參數(shù)里有幾個值得調(diào)一下。溫度Temperature默認是 0.7這個值控制的是回答的隨機性??头鼍拔医ㄗh調(diào)低到 0.3 左右你會發(fā)現(xiàn)回答更穩(wěn)定不太會跑出一個驚悚的冷笑話。如果品牌性格比較俏皮可以維持在 0.5但別超過 0.8再高就不像客服了。另外還有一個容易被忽略的選項叫“歷史對話輪數(shù)”或者叫“上下文輪數(shù)”。這個數(shù)字決定了模型最多記住多少輪聊天記錄。微信客服場景用戶往往會連續(xù)追問“那有紅色的嗎”“什么材質(zhì)”這些都要參考前文所以建議至少設(shè)置 10 輪以上。但也不要太大上下文輪數(shù)越多消耗的 tokens 越多響應(yīng)速度也會變慢。4. 打通微信的完整流程4.1 渠道選擇直連還是轉(zhuǎn)接Coze 里發(fā)布渠道列表會看到微信公眾號、企業(yè)微信、飛書、Discord 等一堆選項。微信公眾號是我們要的但這里有一個容易混淆的點Coze 支持直接發(fā)布到微信公眾號前提是你已經(jīng)在公眾號后臺開啟了服務(wù)器配置并且拿到了相關(guān)的令牌。實際配置時Coze 會要求你填公眾號的開發(fā)者 IDAppID和密鑰AppSecret然后它會生成一個回調(diào)地址。你需要把這個地址和 Token 填到公眾號后臺的服務(wù)器配置頁面里。填完還要在公眾號后臺啟用“消息加解密方式”建議選“安全模式”雖然解密多一步但別人沒法輕易偽造你的接口回調(diào)。如果嫌麻煩也可以用網(wǎng)頁端客服組件嵌入但體驗完全不一樣。微信號直接聊天的自然感是任何網(wǎng)頁對話框都給不了的。4.2 發(fā)布驗證的完整流程發(fā)布過程看似簡單但有幾個環(huán)節(jié)容易卡住。我先給一個完整流程在 Coze 中找到“發(fā)布”按鈕選擇渠道“微信公眾號”。按頁面指引填寫公眾號 AppID 與 AppSecret。復(fù)制 Coze 提供的回調(diào) URL 和 Token。登錄微信公眾平臺打開“設(shè)置與開發(fā)”里的“基本配置”。選擇“服務(wù)器配置”把剛才復(fù)制的 URL 和 Token 填進去加密方式選安全模式。點擊提交此時微信會對 URL 發(fā)一個校驗請求。如果 Coze 端已準備好校驗會通過并顯示“配置成功”?;氐?Coze 平臺點擊“發(fā)布”。發(fā)布成功后你可以先用另一個微信號關(guān)注這個公眾號發(fā)一條“你好”試試。如果收到的回復(fù)是 Kimi 生成的說明鏈路通了。危險操作提醒公眾號后臺開啟服務(wù)器配置后原來的“關(guān)鍵詞自動回復(fù)”“收到消息回復(fù)”全部失效。如果 AI 服務(wù)中途宕機用戶會一直收不到回復(fù)。上線前請務(wù)必在 Coze 那邊把“未命中兜底回復(fù)”配置好至少給用戶一個“稍后有人工處理”的安慰。4.3 多輪會話與臨時工的問題跑通之后第一次真實運營你會遇到一個啼笑皆非的問題用戶的對話經(jīng)常毫無上下文地開啟新話題。比如用戶上一秒問“你們幾點發(fā)貨”下一秒問“哦對了你們家在哪”這是人類正常的跳躍式聊天。Kimi 因為有上下文大概率能接住。但如果用戶在晚上八點半等你回復(fù)等了二十分鐘沒回應(yīng)又重新發(fā)了一條“還在嗎”這兩輪間隔太久上下文可能已經(jīng)過期了。Coze 的會話默認是有保存機制的但如果你設(shè)置的上下文輪數(shù)太少或者會話超時時間太短用戶會覺得客服記性不好。合理做法是對“Bot 設(shè)置”里的會話時長配置按自己業(yè)務(wù)節(jié)奏來如果你通常是秒回設(shè)短一點沒問題如果你是隔一段時間才處理消息建議把會話保持時間調(diào)到一天。5. 上線后必看的調(diào)優(yōu)與避坑5.1 常見問題速查表我整理了一份自己真實碰到過的問題排查記錄直接貼出來大家遇到同款問題可以對照著看?,F(xiàn)象常見原因排查與解決公眾號發(fā)消息沒任何回復(fù)服務(wù)器配置未生效或加密方式不匹配檢查公眾號后臺“服務(wù)器配置”是否顯示成功換“安全模式”再試回復(fù)極慢超過 10 秒Kimi API 超時或知識庫切片太多導(dǎo)致檢索慢在 Coze 知識庫設(shè)置里減少單次檢索的文檔片段數(shù)把溫度調(diào)低回答偶爾完全跑題Prompt 里沒有寫明邊界在“人設(shè)”里補充“如果不確定請回答不知道”知識庫命中不準確文檔格式混亂、切片不合理按章節(jié)拆文檔保留小標題不要直接傳整個幾十頁 PDF出現(xiàn)敏感或違規(guī)內(nèi)容沒有設(shè)置拒答示例在人設(shè)中加入明確拒答話術(shù)并且用“我不了解”代替自由發(fā)揮上下文記不住輪數(shù)配置太少調(diào)到至少 10 輪或檢查是否誤開了“無狀態(tài)模式”5.2 讓回答少踩邊界的辦法做客服機器人和閑聊機器人不一樣客服背后是商業(yè)主體說話必須謹慎。有幾次 Kimi 回答“這款護膚品適合所有膚質(zhì)”這其實是不嚴謹?shù)囊驗槟愕纳唐讽撋蠈懥恕懊舾屑∩饔谩薄_@種問題不是靠加 Prompt 能完全堵住的更好的辦法是產(chǎn)品信息不要寫在 Prompt 里統(tǒng)一放在知識庫里讓模型回答問題時必須先去檢索知識庫而不是憑自己的知識背景回答。另一個務(wù)實的技巧在知識庫里專門建一個“禁忌清單”文檔里面寫清楚什么類型的回復(fù)絕對不許出現(xiàn)。包括不準評價競品、不準承諾治療效果、不準給出醫(yī)療建議。把這份清單也納入知識庫模型檢索時偶爾會讀到自身禁忌效果比我試過的傳統(tǒng)關(guān)鍵詞過濾強很多。5.3 成本控制與配額監(jiān)控Kimi API 是按 token 計費的日常運營中主要消耗來自兩方面一是用戶每次提問的輸入長度二是模型生成回復(fù)的長度。如果遇到用戶把一個 2000 字的長文截圖復(fù)制過來問那次請求的 token 消耗會把你的單條成本一下子拉高。我實際控制成本的方法有兩個。第一個是限制輸入長度。在 Coze 的模型設(shè)置里對輸入文本做一個截斷上限比如超過 2000 字只保留前 1500 字。第二個是設(shè)置單輪回復(fù)的最大 token 數(shù)客服場景設(shè) 200 到 300 就夠用別讓模型長篇大論。每天定時看一下后臺的調(diào)用記錄如果某個時段消耗異常通常有人在用長文本測試你這時候需要回去調(diào)整截斷參數(shù)。5.4 超出客服范圍后的擴展方向這套成型之后不止可以做客服。把 Bot 的人設(shè)換一下上傳不同的知識庫同一個 Coze 工程可以變成售前咨詢助手、商品推薦顧問、甚至是內(nèi)部員工 FAQ 機器人。我自己實際擴展的一個方向是“智能導(dǎo)購”。在原有知識庫里加了一份商品分類表再在 Prompt 里讓模型先問用戶預(yù)算和使用場景再推薦三款合適的產(chǎn)品。本來覺得會很復(fù)雜但 Coze 的工作流功能直接拖節(jié)點就能拼出來。雖然從客服到導(dǎo)購只是變了個“人設(shè)”但用戶數(shù)據(jù)顯示多輪交互后的下單轉(zhuǎn)化率提升了不少。這個案例只是個人測試不代表普遍結(jié)論但至少說明這條路的擴展成本比重新開發(fā)低一個量級。5.5 最后的一些細碎提醒把整套方案落地之后你會發(fā)現(xiàn)后面真正花時間的不是 AI 本身而是維護知識庫和打磨話術(shù)。每次客服遇上一個新問題我都習(xí)慣把當時的對話記錄導(dǎo)出來整理成一條問答放進知識庫。兩三個星期下來機器人能覆蓋的問題越來越多人工客服的工作量明顯的降下來了。還有一個很小的細節(jié)上線前記得把“用戶發(fā)送圖片或語音”的情況考慮進去。微信里發(fā)語音很常見Coze 默認不一定能處理。你可以在公眾號后臺把語音識別打開讓語音先轉(zhuǎn)成文字再傳給機器人不然用戶發(fā)一句 60 秒語音等于石沉大海。最后再分享一個小技巧別在生產(chǎn)環(huán)境直接調(diào)參數(shù)。在 Coze 里復(fù)制一個 Bot 作為測試分身所有 Prompt 改動先在分身里試清楚再同步到主 Bot。這個習(xí)慣讓我避開了好幾次把線上客服改傻的尷尬。AI 客服這東西跑起來不難真正決定體驗的是你能不能細致地維護它。