在數(shù)字化轉(zhuǎn)型的浪潮中，智能客服已成為企業(yè)提升服務(wù)效率和客戶滿意度的關(guān)鍵工具。然而，許多企業(yè)在搭建智能客服系統(tǒng)時，往往忽視了運營分析這一重要環(huán)節(jié)。本文將從實戰(zhàn)經(jīng)驗出發(fā)，深入探討智能客服搭建的第一步——運營分析，供大家參考。

從業(yè)務(wù)上看，對于大多數(shù)企業(yè)來說，原來都設(shè)置了客服部門，所以企業(yè)構(gòu)建智能客服，并不是完全“從0到1”的過程。并且在短期內(nèi)AI智能客服并不能100%替代人工客服，很長一段時間可能是AI智能客服和人工客服交互協(xié)作，來支持企業(yè)與客戶/經(jīng)銷商/相關(guān)合作方的溝通。

從技術(shù)趨勢上看，在人工智能時代，由于智能客服能在一定程度上降本增效，且不受時間限制提供服務(wù)，對客服部門的工作方式產(chǎn)生了沖擊，現(xiàn)階段的主流是人工智能客服+人工客服協(xié)作為客戶提供服務(wù)的模式，即一種“錦上添花“的模式。

那么基于這種條件假設(shè)，如何更加有效的搭建智能客服，我想不能僅僅從設(shè)計一款A(yù)I智能客服產(chǎn)品來思考，第一步甚至應(yīng)該從AI智能客服運營出發(fā)來思考。運用好企業(yè)過往歷史的人工客服階段的運營數(shù)據(jù)，以此來定位客服業(yè)務(wù)的核心場景痛點，并識別出哪些場景適合人工客服，哪些場景適合AI智能客服，原來的人工客服的問題解決率、平均通話/回復(fù)時長等核心數(shù)據(jù)是多少，在同類場景下AI智能客服的指標(biāo)KPI需要是多少，能否達到，并根據(jù)運營數(shù)據(jù)，不斷調(diào)整人工客服和AI智能客服的場景分工和KPI目標(biāo)。

主流的ai客服產(chǎn)品好比菜譜，菜譜大同小異，但是結(jié)合行業(yè)和公司特點的ai智能客服和運營好比炒菜的火候。

01 智能客服上線前的核心工作內(nèi)容

下面推測一下，智能客服運營相關(guān)的重要工作，可能包括但不限于場景識別、考核指標(biāo)設(shè)計、投資回報復(fù)盤、持續(xù)參與會話、FQA、TASK、知識庫語料等相關(guān)工作，下面選取部分內(nèi)容進行詳細方向說明。

1.1 定位現(xiàn)狀+場景識別

定位現(xiàn)狀：我們可以采用定量和定性結(jié)合的方式來確定，對于大部分企業(yè)來說，以往會有一定的人工客服的管理統(tǒng)計數(shù)據(jù)，那么我們可以根據(jù)過往的管理數(shù)據(jù)進行分析，并從外部市場進行對比分析，以明確客服管理的總體現(xiàn)狀。例如：

場景識別：進行場景識別，厘清業(yè)務(wù)痛點，根據(jù)過往客服運營數(shù)據(jù)識別適用的場景。接下來，我們可以根據(jù)更詳細的客服運營數(shù)據(jù)，擬定我們的業(yè)務(wù)運營指標(biāo)，這里的出發(fā)點，就是厘清在業(yè)務(wù)場景中，哪些場景是可以使用智能客服的，這些適合智能客服場景中，適用人工客服和智能客戶的目標(biāo)比例分別是多少，考核指標(biāo)分別是多少。我們可以結(jié)合自己的客服運營管理方式進行痛點分析、場景識別數(shù)據(jù)分析。這里我們以呼入/呼出場景舉例（以下僅提供分析思路，需結(jié)合各自行業(yè)和業(yè)務(wù)進行分析，切勿盲目套用）。

呼入/在線：

呼出：

1.2 考核指標(biāo)設(shè)計

基于前文的分析，我們已經(jīng)事厘清了不同場景下，適用人工客服和智能客服的業(yè)務(wù)場景范圍，那么接下來，我們可以思考以下增加智能客服后，在客戶交互場景模式變化下，如何設(shè)計考核指標(biāo)。

假設(shè)條件，我們設(shè)置了大部分場景優(yōu)先AI智能客服解決，那么先接入AI智能客服，當(dāng)AI智能客服無法解決問題的時候，轉(zhuǎn)人工處理。這里以轉(zhuǎn)人工處理為分水嶺。即所有場景中，可能出現(xiàn)這3種模式。A類，全程由AI智能客服處理。B類，原先設(shè)定AI智能客服處理，但是AI智能客服無法滿足客戶的需求，客戶選擇轉(zhuǎn)人工，由AI智能客服和人工客服配合完成處理。C類，重大緊急的事故，重要VIP客戶，設(shè)置了專屬人工客服處理。

那么針對A類場景的指標(biāo)數(shù)據(jù)，我們可以將原有的未采用AI智能客服處理的運營數(shù)據(jù)，和采用AI智能客服的運營數(shù)據(jù)做對比。并制定AI智能客服的運營考核指標(biāo)。

A類 KPI（可考慮按呼入/呼出到場景細分的統(tǒng)計，按需）

針對B類場景，重點分析客戶為什么轉(zhuǎn)人工，進行問題分析。有針對性的提升ai智能客服?？刹捎脙煞N方式，一種的主動問詢客戶滿意度數(shù)據(jù)，另外一種是通過監(jiān)測后臺指標(biāo)數(shù)據(jù)的方式。

第一種是主動問詢客戶獲取滿意度數(shù)據(jù)，快速評估客戶對服務(wù)的感知。包括滿意度評分（csat）、凈推薦值（NPS）等，這里尤其我們要關(guān)注滿意和不滿意的部分，加強優(yōu)勢，并且分析不滿意的具體原因，并制定針對性的解決方案。

第二種是后臺監(jiān)測指標(biāo)數(shù)據(jù)，這里又可以分為兩類：第一類是可以直接反映AI智能客服的指標(biāo)，例如，首次解決率（FCR）、平均響應(yīng)時長（ART）、轉(zhuǎn)人工率、情感分析。另外一類是不能直接反映AI智能客服，但可以間接推測AI智能客服運營質(zhì)量的指標(biāo)，例如增益類指標(biāo)：消費者滿意度、用戶增長率、用戶流失率、用戶留存率、營銷推廣觸達率、獲客成本、客戶終身價值提升率。約束類指標(biāo)：消費者投訴率、消費者問題一次性解決率、消費者問題解決時長、客服響應(yīng)時長等。

針對C類場景則是一些極其特殊的場景和重點關(guān)注的場景，這里我們不做過多的贅述。

1.3 知識庫搭建

對于大多數(shù)行業(yè)來說，知識庫是智能客戶運營的重要工作事項，當(dāng)然部分行業(yè)由于行業(yè)屬性較為特殊，例如法律等行業(yè)，可能偏向采用微調(diào)的模式，也有部分行業(yè)采用微調(diào)+RAG結(jié)合的模式。但對于需要快速適應(yīng)市場、產(chǎn)品和營銷有一定的更新迭代速度，RAG模型顯然是目前較為主流且合適的模式，在RAG模式下知識庫的搭建和運營，是智能客服運營的重要工作內(nèi)容之一，包括可能會參與知識庫的期初調(diào)研和設(shè)計，以及后續(xù)知識庫的管理運營。

同時對于知識庫場景是設(shè)計，我們需要明確一個整體的場景，以及一期重點搭建的場景、二期重點搭建的場景…，這里重點搭建的場景可以結(jié)合我們前面識別的重點場景，并明確不同場景下所需的知識庫素材是什么，制定相對統(tǒng)一的底層數(shù)據(jù)標(biāo)準(zhǔn)，避免出現(xiàn)由于數(shù)據(jù)標(biāo)準(zhǔn)不一致的原有，造成的召回撈起識別錯誤。

由于時間精力等原因，本次暫不給出具體示例，但對于知識庫的期初設(shè)計我們可以考慮以下內(nèi)容

• 明確知識庫使用的場景：根據(jù)前文的呼入、呼出場景，明確不同場景下需要的知識庫，進行映射關(guān)系說明
• 明確知識庫的信息來源：第一是內(nèi)部數(shù)據(jù)，公司內(nèi)部不同的部門，銷售政策、相關(guān)規(guī)則、產(chǎn)品手冊等等，第二是外部數(shù)據(jù)外部的數(shù)據(jù)來源
• 明確知識庫分類體系：按照內(nèi)容形式，分為圖片、文字、音頻、視頻；按業(yè)務(wù)類型、產(chǎn)品類別、問題類型等設(shè)置相關(guān)分類
• 明確知識庫關(guān)聯(lián)設(shè)置：第一是建立知識之間的關(guān)聯(lián)關(guān)系，如相似問題關(guān)聯(lián)、相關(guān)產(chǎn)品知識關(guān)聯(lián)、業(yè)務(wù)流程前后環(huán)節(jié)關(guān)聯(lián)等。第二是知識庫嵌入agent工作流中不同知識庫之間配合的關(guān)聯(lián)，對話管理的task
• 明確知識庫的權(quán)限：設(shè)置不同的訪問權(quán)限，限制不同人員對知識庫的查看、編輯和使用權(quán)限；例如，客服人員可以查看和使用所有知識，而普通員工可能只能查看部分公開知識
• 設(shè)計知識庫的評估和指標(biāo)：如知識檢索準(zhǔn)確率、問題解決率、客戶滿意度等，定期對知識庫的使用效果進行評估

02 智能客服上線后的核心工作內(nèi)容

2.1 業(yè)務(wù)運營數(shù)據(jù)分析與策略迭代

從AI智能客服的工作原理探究，發(fā)生BUG的原因：以最常見的客訴呼入場景為例，假設(shè)人工客服的操作SOP是根據(jù)用戶輸入問題，進行問題理解，包括但不限于定位訂單、定位業(yè)務(wù)場景、定位客戶需求等，并針對用戶輸入問題進行澄清回復(fù)。這一步人工客服已經(jīng)明白了場景和客戶訴求。接下來，人工客服會根據(jù)場景和客戶訴求，根據(jù)過往的經(jīng)驗、公司政策、查詢相關(guān)信息，給出一個方案，如可以直接判斷，則給出解決方案給客戶，如不能直接判斷，人工客服會要求轉(zhuǎn)接其他同事/稍后回電。之后人工客服可能會持續(xù)詢問客戶是否滿意此方案，滿意即結(jié)束此客戶服務(wù)，不滿意則詢問客戶不滿意的點在哪，并讓客戶給出她希望的方案，根據(jù)過往的經(jīng)驗、公司政策、查詢相關(guān)信息看能否滿足客戶訴求，直至在公司條件規(guī)則下與客戶訴求達成一致。

那么AI智能客服，實際上是在模仿人工客服的場景，根據(jù)上文的例子，我們可以簡要的總結(jié)AI智能客服必然有幾個重要的模塊節(jié)點。即對于AI智能客服發(fā)生“bug“的原因，我們大致可以從以下的維度思考：

• 輸入處理層：存在多模態(tài)輸入解析問題（語音識別歧義、圖像識別錯誤、上下文丟失）及語義理解偏差（場景混淆、意圖誤判、信息遺漏）；
• 知識處理層：知識庫存在數(shù)據(jù)更新滯后、長尾問題覆蓋不全、標(biāo)簽分類錯誤等缺陷，同時檢索匹配算法存在向量空間偏差、業(yè)務(wù)優(yōu)先級忽略及上下文融合不足；
• 對話管理層：任務(wù)調(diào)度可能出現(xiàn) API 調(diào)用異常、流程誤觸發(fā)或上下文丟失，交互策略存在澄清引導(dǎo)模糊、情緒安撫缺失及超時處理不當(dāng)；
• 輸出生成層：響應(yīng)生成可能出現(xiàn)模板匹配錯誤、邏輯漏洞或合規(guī)性疏漏，表達方式存在口語化不足、多語言支持弱及格式異常；
• 模型局限性：生成式幻覺導(dǎo)致編造答案或邏輯矛盾，小樣本場景泛化能力不足；
• 外部依賴層：調(diào)用的第三方服務(wù)異?；蚓W(wǎng)絡(luò)問題引發(fā)連鎖錯誤。

如何改進，從運營角度，非整體角度：

1. 高頻場景定制化模板：例如將物流派件投訴，拆解成派件時效延遲、未放指定地點、派件未電聯(lián)、派件服務(wù)態(tài)度問題、未經(jīng)允許放自提柜等，根據(jù)不同場景設(shè)置相應(yīng)的定制化對話模板和提示詞
2. 智能分流A/B測試：識別適用AI客服的場景，復(fù)雜的交給人工處理。定期測試高頻場景
3. 人工接管觸發(fā)規(guī)則：業(yè)務(wù)關(guān)鍵詞、情緒關(guān)鍵詞，觸發(fā)人工接管，例如，十分生氣、外部投訴
4. AI質(zhì)檢：檢驗抽查，運用模型對響應(yīng)內(nèi)容進行檢查，攔截風(fēng)險應(yīng)答
5. 數(shù)據(jù)監(jiān)控看板：針對核心指標(biāo)，例如首答解決率、平均響應(yīng)時長、人工轉(zhuǎn)接率等設(shè)置看板，進行紅黃綠燈預(yù)警
6. 人性化提示詞設(shè)置：提示詞設(shè)置人性化的性格描述，讓客服說話更“像人”。少說術(shù)語：例如，把“請在APP端提交SN碼”改成 → “您打開手機APP，點訂單詳情，找到頁面最下面那串20位的黑色數(shù)字，填進去就行”。同時，避免連環(huán)問，錯誤示范：“請問是訂單號問題？物流問題？還是售后問題？”（一次問3個選項用戶容易懵）。正確操作：先問*“您是遇到訂單問題了嗎？”* → 用戶說是 → 再問*“具體是物流沒到？還是商品有問題？”*
7. 專屬特權(quán)配置：例如，coze上可以針對具體的某個用戶回復(fù)個性化設(shè)置，適用于高價值客戶，記錄用戶偏好，實現(xiàn)千人千面的智能客服

2.2 知識庫更新的規(guī)則和政策

• 更新頻次： 明確產(chǎn)品和營銷活動更新上傳的頻次，如每周或每月。
• 內(nèi)容管理： 規(guī)定知識庫內(nèi)容的增刪改流程，確保信息的準(zhǔn)確性和時效性。
• 審核標(biāo)準(zhǔn)： 制定知識庫內(nèi)容審核的標(biāo)準(zhǔn)要求，確保內(nèi)容質(zhì)量。

知識庫數(shù)據(jù)質(zhì)檢：

• 日常質(zhì)檢： 定期質(zhì)檢一定數(shù)量的會話記錄，確認機器人回答的準(zhǔn)確性，補充知識庫中不存在的內(nèi)容。
• 模型升級質(zhì)檢： 在模型升級后進行線上質(zhì)檢，創(chuàng)建數(shù)據(jù)集，由知識庫運營人員提供問題形成數(shù)據(jù)集，進行標(biāo)注，測試新版本的準(zhǔn)確性。

根據(jù)運營數(shù)據(jù)迭代知識庫：

• 轉(zhuǎn)人工問題分析： 分析轉(zhuǎn)人工最多的問題，找出知識庫的不足。
• 用戶不滿意場景分析： 從用戶不滿意的場景中分析知識庫的缺陷。
• 精準(zhǔn)度和召回率分析： 從精準(zhǔn)度和召回率低的對話場景中分析問題。
• 客戶反饋問題分析： 針對客戶主動反饋的不滿意問題，分析知識庫中沒有答案、答案不一致、算法提煉不準(zhǔn)確或回復(fù)不符合預(yù)期等問題，并進行相應(yīng)的迭代。

2.3成本收益核算

以下是簡要的智能客服下面成本收益分析，該成本收益分析并不完善和專業(yè)，僅提供一些分析思路給大家。

分析的大類包括但不限于：

1. 初期搭建成本和年運維成本。
2. 年節(jié)省的人力成本。
3. 計算回本期，判斷項目的經(jīng)濟可行性。
4. 綜合評估其他潛在收益和風(fēng)險因素，使用高級財務(wù)工具：使用凈現(xiàn)值（NPV）、內(nèi)部收益率（IRR）等方法，將未來收益折現(xiàn)到當(dāng)前價值來評估項目的財務(wù)可行性。

那么按照成本和收益分析，則可以歸納為下述內(nèi)容：

總成本=系統(tǒng)建設(shè)成本+運營維護成本+人力轉(zhuǎn)移成本：

• 系統(tǒng)建設(shè)成本（NLP 引擎 / 知識庫 / 算力資源）
• 運營維護成本（數(shù)據(jù)標(biāo)注 / 模型迭代 / 系統(tǒng)監(jiān)控）
• 人力轉(zhuǎn)移成本（坐席再培訓(xùn) / 管理重構(gòu)）

總收益=直接收益+戰(zhàn)略收益：（由于戰(zhàn)略收益難以量化，本次暫只計算直接收益）

• 直接收益：人力成本節(jié)約 + 服務(wù)效率提升
• 戰(zhàn)略收益：數(shù)據(jù)資產(chǎn)積累 + 服務(wù)品牌溢價

計算回本期：（示例計算）

假設(shè)：

初期搭建成本 (Cinitial) = 180萬

年運維成本 (Coperation) = 45萬/年

人力轉(zhuǎn)移成本=10萬/年（前2年）

每年節(jié)省的人力成本 (Slabor) = 100萬/年

結(jié)論：當(dāng)收益總計大于成本總計，即回本了，這里我們的收益不考慮難以量化的戰(zhàn)略收益，進考慮人力成本節(jié)約。約3.6年可以回本。

番外篇：一個基于coze的智能客服實戰(zhàn)示例

下面以一個企業(yè)數(shù)字化服務(wù)的咨詢公司的智能客服為例，介紹To B智能客服如何搭建。

廣義上來說，To C企業(yè)的智能客服應(yīng)用更廣，尤其是在售前咨詢和售后爭議解決方面，在數(shù)量級、AI場景豐富程度、SOP流程上都有更廣的空間，但由于過往經(jīng)驗的限制（主要是知識庫數(shù)據(jù)隱私限制），目前僅以To B企業(yè)數(shù)字化服務(wù)的咨詢公司的智能客服來舉例說明。

除了COZE外，Dify也是一個很好的低代碼的智能客服搭建工具，?另外，?LangChain?和Ollama也是非常主流的應(yīng)用開發(fā)框架或本地化LLM部署工具，并且可以搭配使用，Dify和Ollama的集成可以實現(xiàn)本地化部署與隱私保護，本次不做過多的技術(shù)選型討論，下面是基于COZE的搭建流程說明（由于本人最近有點忙，這個智能客服的工作流和知識庫還在迭代中，雖然已經(jīng)接入本微信公眾號示例，但是精細化程度估計不足，大家圖個樂子，別當(dāng)真，本人也沒有公司提供相關(guān)產(chǎn)品，哈哈哈）。

第一步：點擊官網(wǎng)，并進行注冊

第二步：選擇模式（單/多agent）

第三步：配置對話流

這一步是智能客服智能體里面的重要設(shè)置環(huán)節(jié)，通俗的來說，你可以配置流程，設(shè)置提示詞，配置角色名稱、角色設(shè)置、開場白。也可以設(shè)置調(diào)用的組件，其中知識庫中，除了可以根據(jù)行業(yè)、產(chǎn)品、用戶、業(yè)務(wù)場景、客服場景設(shè)計相應(yīng)的內(nèi)容，也可以設(shè)置召回量，最小匹配度等。

對于目前agent模式尚未實現(xiàn)，更多是是LLM的工作流形式，主流的workflow有以下幾種形式，供大家參考，根據(jù)需要選擇。 個人覺得路由器在智能客服分流上可能較為匹配，有較強的適用性。

1、鏈?zhǔn)焦ぷ髁鳎–hain Workflow）模式：

第一，每個大語言模型的調(diào)用順序是固定的。

第二，鏈?zhǔn)焦ぷ髁魃弦粋€步驟的輸出結(jié)果，作為下一個步驟的輸入。

2、并行化工作流（Parallelization Workflow）模式：

第一，同時調(diào)用多個大語言模型，并行處理，這些調(diào)用可以同時進行，無需等待其他大語言模型調(diào)用完成。

第二，輸出結(jié)果前，采用聚合器，整合之前調(diào)用多個大語言模型。

3、路由工作流（Routing Workflow）模式：

第一，先由路由器判斷任務(wù)分配給哪個大語言模型，路由器根據(jù)輸入數(shù)據(jù)的特征、內(nèi)容或其他相關(guān)因素，決定將數(shù)據(jù)發(fā)送到哪個大語言模型。

第二，大語言模型根據(jù)路由器分配，處理相關(guān)任務(wù)。

4、編排器-工作者（Orchestrator-Worker）模式：

并行化工作流和路由工作流的結(jié)合。

第一，編排器分配任務(wù)給不同的大語言模型。

第二，合成器將不同LLM調(diào)用的結(jié)果進行綜合處理，生成輸出。

5、評估器-優(yōu)化器（Evaluator-Optimizer）模式：

第一，生成器生成結(jié)果，評估器給出迭代優(yōu)化策略。

第二，生成器和評估器互相配合，持續(xù)優(yōu)化，輸出最優(yōu)結(jié)果。

提示詞工程這里說人話就是幫助機器更好的理解你的問題你的情景你要解決的問題你要了解的信息，你可以通過提示詞，決定你的客服是活潑的、理性的，回復(fù)是簡潔高效還是全面嚴謹，設(shè)置她的回復(fù)偏好等等。下面是現(xiàn)在較為主流的提示詞工程模型：

1. ICIO 框架

Intruction（任務(wù)）：明確指出希望 AI 執(zhí)行的具體任務(wù)。

示例：

“分析某新能源汽車論壇的用戶評論，提取關(guān)于電池續(xù)航的關(guān)鍵詞。”

適用場景：市場調(diào)研、用戶需求挖掘。

Context（背景）：提供任務(wù)的背景信息，幫助 AI 理解任務(wù)的上下文。

示例：

“公司計劃推出長續(xù)航版電動車，需了解用戶對現(xiàn)有車型的不滿點。”

適用場景：產(chǎn)品迭代前的數(shù)據(jù)支持。

Input Data（輸入數(shù)據(jù)）：指定 AI 需要處理的具體數(shù)據(jù)。

示例：

“附上 50,000 條論壇評論的 CSV 文件（字段：用戶 ID、評論內(nèi)容、發(fā)布時間）?！?/p>

適用場景：數(shù)據(jù)驅(qū)動的分析任務(wù)。

Output Indicator（輸出格式）：設(shè)定期望的輸出格式和風(fēng)格。

示例：

“輸出 Excel 表格，按關(guān)鍵詞出現(xiàn)頻率排序，并標(biāo)注負面評論占比。”

適用場景：需標(biāo)準(zhǔn)化匯報的企業(yè)級需求。

2. BROKE 框架

Background（背景）：提供任務(wù)的背景信息，幫助 AI 理解任務(wù)的上下文。

示例：

“某國產(chǎn)美妝品牌計劃進軍東南亞市場，需制定 TikTok 推廣策略?！?/p>

Role（角色）：指定 AI 作為，以便它能夠以專業(yè)的角度回答問題。

示例：

“跨境營銷專家，熟悉東南亞文化差異和社媒平臺算法?！?/p>

Objectives（目標(biāo)/任務(wù)）：給出任務(wù)描述。

示例：

“設(shè)計 3 套 TikTok 內(nèi)容方案，突出產(chǎn)品成分天然性?！?/p>

Key Result（關(guān)鍵結(jié)果）：設(shè)定回答的關(guān)鍵結(jié)果。

示例：

“每套方案需包含：10 秒短視頻腳本、話題標(biāo)簽、與本地 KOL 的合作建議?！?/p>

Evolve（改進）：在 AI 給出回答后，提供三種改進方法。

示例：

“增加穆斯林用戶適配性” / “強化價格對比優(yōu)勢” / “添加用戶證言剪輯模板”。

適用場景：跨境營銷策劃、動態(tài)優(yōu)化方案。

3. CRISPE 框架

Capacity and Role（角色）：明確 AI 在交互中應(yīng)扮演的角色。

示例：

“區(qū)塊鏈技術(shù)律師，擅長智能合約合規(guī)審查?！?/p>

Insight（背景）：提供角色扮演的背景信息，幫助 AI 理解其在特定情境下的作用。

示例：

“某 DeFi 平臺需確保新合約符合歐盟《數(shù)字資產(chǎn)法案》（MiCA）?！?/p>

Statement（任務(wù)）：直接說明 AI 需要執(zhí)行的任務(wù)，確保其理解并執(zhí)行用戶的請求。

示例：

“審查以下智能合約代碼，標(biāo)注可能違反 MiCA 的條款（第 12-15 條）?！?/p>

Personality（格式）：設(shè)定 AI 回復(fù)的風(fēng)格和格式，使其更符合用戶的期望和場景需求。

示例：

“以法律意見書格式輸出，用紅黃綠三色標(biāo)注風(fēng)險等級，引用具體法條。”

Experiment（實驗）：如果需要，可以要求 AI 提供多個示例，以供用戶選擇最佳回復(fù)。

示例：

“提供 3 種合規(guī)修改方案：激進型（完全重構(gòu)）、平衡型（局部調(diào)整）、保守型（補充免責(zé)聲明）?！?/p>

適用場景：法律合規(guī)、技術(shù)方案多路徑驗證。

另外，召回量和調(diào)用的模型組件也可以根據(jù)自己的需求設(shè)置，說人話就是在召回量設(shè)置上越大，客服回復(fù)的字數(shù)通常會更多。調(diào)用模型組件越多并不是最好的，可能出現(xiàn)精準(zhǔn)度不足的問題，帶來幻覺問題，并且影響檢索效率，出現(xiàn)回復(fù)時效較慢的情況。這里值得注意且深度探索的還有業(yè)務(wù)邏輯、會話管理、知識庫等設(shè)置和配置，即積木組件有了，搭成什么樣的城堡，完全由我們自主決定。

第四步： 設(shè)置記憶 你可以設(shè)置變量，讓回復(fù)基于用戶特征，更加個性化；設(shè)置數(shù)據(jù)庫；選擇是否采用長期記憶

第五步：測試調(diào)優(yōu)，與發(fā)布

第六步：和微信公眾號等外部應(yīng)用鏈接API（可選）