用DeepSeek處理Freshdesk中英雙語工單

簡而言之： DeepSeek可以在Freshdesk佇列裡完成語言辨識、意圖分類、路由和回覆起草——而中英混合服務台真正崩掉的地方，不是翻譯，是分流。把模型放在佇列前面、覆核人後面，用「是否解決」而不是「譯文讀起來順不順」來衡量品質，並且弄清楚工單資料究竟流向了哪裡。

一個要處理兩種語言的支援佇列，難度不是單語言的兩倍，而是更高——原因在於差異不只是語言。一張來自深圳客戶的中文工單和一張來自新加坡客戶的英文工單，在「該帶多少脈絡」的預設習慣上不同，在回應時效的預期上不同，往往連底層產品都不同。把這個問題理解成「我們需要翻譯」的服務台，解決的是最容易的那部分，而昂貴的那部分原封不動。

這篇文章講的是佇列，不是通路。如果你的中國客戶是透過企業微信找上來的，那是另一個「前門」問題——我們在DeepSeek與企業微信雙語客服那篇裡講過。這裡的前提是：工單已經以兩種語言、成規模地落進了Freshdesk，問題是接下來怎麼辦。

混合語言工單佇列最先崩在哪裡

先崩的是路由，遠早於翻譯。 任何一張工單的第一個決策是「該歸誰」，而在雙語服務台裡，這個決策現在依賴一個沒有任何東西在可靠設定的語言屬性。客戶想用哪種語言就用哪種，有時一張工單裡兩種都有。以客戶所在國家或來信信箱建立的規則會錯得夠頻繁，以至於座席不再信任它們，開始手工分揀——而這正是你原本想避免的人工。

首次回應時間會按語言分岔。 如果能講中文的座席只有三個人、能講英文的有十二個，中文佇列的首回時間會悄悄漂移，而且會持續漂移，因為它被平均進了一個看上去沒問題的全台指標裡。這通常是「結構上出了問題」的第一份硬證據，而它通常晚了好幾個月才浮現。

知識庫只有一種語言。 用中文回覆的座席，每一次都在讀英文文章、現場翻譯，而且不留任何紀錄。同一個問題會從六個座席那裡得到六種不同的中文答案，其中沒有一個回流進知識庫。

升級過程會掉資訊。 一張以中文開始、升級給英文工程師的工單，交到對方手上的是一份在時間壓力下、由非譯者寫成的摘要。恰恰在細節最要緊的那個節點，細節掉了。

沒人能稽核它。 當品質客訴出現時，除非把一個雙語同事從佇列上抽下來讀工單，否則沒有辦法回看另一種語言裡究竟說了什麼。這在實務上意味著：沒人會去看。

DeepSeek在Freshdesk工單生命週期裡的位置

一個有用的心智模型是：模型做的是「座席打開工單之前」的工作，以及「座席正在撰寫時」的工作。它不做「判斷客戶是否滿意」的工作。

語言辨識、分流與路由——在起草任何回覆之前

先做這一部分，並且要抵抗直接跳到回覆起草的誘惑，因為大部分價值在這裡，而且這也是最安全的起點。工單建立時，把標題和內文送給模型，要求它回傳一小組嚴格受限的欄位：主要語言、是否為混合語言、產品領域、意圖類別，以及一個情緒或急迫度標記。透過Freshdesk API把這些寫回工單的自訂欄位，然後讓你現有的自動化規則像對待任何其他欄位一樣對它們生效。

有兩個設計要點，決定了這件事是好用還是添亂。第一，約束輸出——把每個欄位允許的取值清單明確給模型，並要求它在拿不準時回傳一個指定的「不明確」值，而不是自己發明一個類別。一張落進「不明確」桶、由人來分揀的工單是好結果；一張被自信地歸錯檔的工單不是。第二，別讓模型參與「指派」這個決定本身。它設定屬性，你的路由規則做指派。這種分離意味著你可以在不動模型的情況下修改路由政策，也讓稽核軌跡留在它本該在的工單系統裡。

一旦「語言」從一個猜測變成一個可靠欄位，另一件多數服務台從來做不到的事就成為可能：按語言拆分的報表。首回時間、解決時長、重開率和滿意度，全部按工單語言切片——這是讓上文那種漂移在「還便宜的時候」就變得可見的唯一辦法。

起草後覆核的回覆，以及誠實地衡量品質

回覆起草是顯眼的那一半，也應該是你建的第二件東西。奏效的模式並不炫目：模型用客戶的語言產出一份草稿，其依據是相關知識庫文章和這張工單的歷史；座席修改後送出。作者仍然是座席。什麼都不自動送出。

DeepSeek比較適合這個具體工作，因為它對中文和英文都是原生處理，而不是把其中一種當作翻譯目標——這一點對語氣很重要。一份從英文譯過來的中文回覆，讀起來像譯文；一份直接用中文寫的回覆，讀起來像客服。至於你用託管API還是在自己的基礎架構上跑開放權重模型，這會顯著改變資料治理的圖景，這個選擇下文會展開。

衡量這件事，是多數團隊騙自己的地方。翻譯品質分數告訴你的是文字是否流暢，不是客戶的問題有沒有被解決——而一份答非所問的流暢回覆，在這兩項上都得分不低。去衡量那些反映結果的東西：草稿與座席實際送出內容之間的編輯距離、一次解決率、七天內重開率，以及按語言拆分的滿意度。如果草稿被大幅重寫，問題通常出在知識庫而不是模型。如果草稿被原樣送出、同時重開率上升，那說明你的覆核流程已經悄悄變成了一枚橡皮圖章。

一條務實的推進路徑：試點佇列、品質關卡，然後擴大

先只做分類，跑在真實流量上，但結果對座席隱藏。 讓模型跑兩週進站工單，把輸出寫進沒有任何路由依賴的欄位。然後把它給出的語言和類別判斷，與服務台實際的處理做對比。你會得到「你自己的工單上的真實準確率」，這是任何基準測試都告訴不了你的，而且就算它判斷錯了，也不會有任何代價。

只為一個產品領域開啟路由。 挑一個量足夠看出規律、但風險低到能吸收失誤的佇列。讓人工改派這個動作顯眼且順手，然後觀察座席用它的頻率——這個數字才是你真正的準確率訊號，比你自己跑的任何評測都更誠實。

為一小群自願的座席加上起草功能。 主動願意試的人會告訴你草稿哪裡不對；被強加的人只會繞開它。給這組志願者一個一鍵標記壞草稿的通道，並在第一個月裡讀完每一條標記。

在擴大之前建術語表，而不是之後。 到這一步，你已經累積了反覆出現的翻譯問題——不該被翻譯的產品名、有官方中文寫法的功能名，以及你們公司用法與業界通行用法不同的詞。那份清單是整個專案裡槓桿率最高的一份產物。

按量擴大，不要按雄心擴大。 只有當上一個佇列的重開率穩定之後，才推進到下一個。這裡的失效模式不是一次戲劇性事故，而是回覆品質的緩慢下滑——因為發生得很漸進，沒有人會把它歸因到這次推廣上。

AI輔助雙語分流 vs 招雙語座席 vs 外包整個服務台

低量級下的成本 — 招人勝出。每月幾百張工單以下，兩個真正雙語的座席就能徹底解決問題，而且比建任何東西所需的工程時間都便宜。
高量級下的成本 — AI輔助分流明顯勝出。多分類一千張工單的邊際成本很小；多招一個雙語座席的邊際成本不小，而且在多數市場，雙語技術支援人員是真的稀缺。
複雜工單上的品質 — 招人勝出，而且差距不小。一個熟練的雙語座席處理微妙、沮喪和歧義的方式，是任何起草流程都做不到的。這正是「應該讓你的雙語同事去處理難工單而不是例行工單」的論據。
跨時區覆蓋 — 外包勝出。一個在合適時區有人力的供應商，能給你一個小型內部團隊給不了的夜間覆蓋，而這往往才是公司選擇外包的真實原因。
產品知識 — 內部勝出，無論有沒有AI輔助。外包服務台要好幾個月才能建立產品深度，而且人員一流動就歸零，這也是關於這種模式最常見的抱怨。
對客戶資料的控制 — 自架模型的內部方案最強，其次是使用託管API的內部方案，外包墊底。每一份外包安排都是一份資料處理安排，也應當照此簽成合約。
改進速度 — AI輔助勝出。修一個系統性問題，意味著改一段提示詞和一份術語表，並且從那一刻起對每一張工單生效。在一個團隊裡修同一個問題，意味著重新訓練人。

多數把這件事做對的服務台，最後落在一個組合而不是一個贏家上：AI負責例行流量的語言辨識、路由和初稿，一支小型雙語團隊負責升級和品質覆核，而外包涵蓋那些沒人願意排班的時段。

真正立得住的品質控制

一份被強制執行、而非「建議參考」的術語表。 產品名、功能名、錯誤碼和法律用語，都屬於一份進入每一次提示詞的術語庫。每月和產品命名的負責人一起覆核它，因為這是最常見的尷尬輸出來源。

每種語言各有一份語氣規範。 客服中文和客服英文的差別不止於詞彙——還在於直接程度、多少道歉才算得體，以及「拒絕」該怎麼措辭。把你們服務台在每種語言裡的聲音寫下來，放進提示詞。不要把英文語氣指南翻譯一遍就以為能通用。

明確的升級門檻。 提前定義模型絕不能起草的內容：一切涉及退款、合約承諾、資安事件、法律威脅，或點名某個主管機關的工單。這些應當立即路由給人，且不附帶任何草稿——因為草稿是錨，時間緊張的覆核者會去改它，而不是從頭寫。

一個你真的能堅持下去的抽查率。 選一個AI輔助工單的比例——百分之五是個合理起點——讓一位雙語覆核者每週讀完整的雙語往來。把他們發現的問題當趨勢追蹤，而不是當孤立事件。一個跑三週就停掉的抽查計畫比沒有更糟，因為它帶來了信心卻沒留下證據。

一個顯眼的關閉開關。 服務台上每個人都該知道怎麼關掉某個佇列的起草功能，並且被允許不用請示就去關。如果模型在凌晨三點開始產出糟糕內容，發現的那個人應該有權把它停掉。

把這件事做對：工單資料、跨境傳輸，以及何時該讓IT介入

支援工單是中小企業日常處理的資料裡最敏感的一類，也是治理最薄弱的一類。一張工單裡可能同時有客戶姓名、聯絡方式、訂單歷史、一張露出工作階段權杖的截圖，以及一句順口提到的同事病假。把這些內容送給模型端點是一次處理活動；如果客戶在中國大陸，它還可能構成《個人信息保護法》下的跨境傳輸，其義務取決於資料量和資料類型。香港《個人資料（私隱）條例》和新加坡PDPA則對你如何告知、如何與受託處理方簽約各有要求。這些都不會讓專案做不成，只是讓它變成一件需要設計、而不是事後才發現的事。

實務上的控制措施就是那些常規做法，只是要做到位。送出前做去識別化——剝掉附件、用確定性規則遮蔽卡號和身分識別碼，絕不要在不知道圖裡有什麼的情況下把截圖送給視覺端點。有意識地選擇部署方式：託管API上手更快，但把你的資料放在別人的基礎架構上、按對方的條款處理；在你控制的地域裡跑開放權重模型，能把工單內容留在你的邊界內，代價是你得自己維運它。兩者都是正當選擇，只是其中一種不該是「不小心選中的」。把API金鑰從工單系統本身的設定裡挪出來、放進金鑰管理服務，並配上費用告警，因為一個在畸形工單上陷入迴圈的整合，會心安理得地迴圈整個週末。

這一層，正是一個支援專案變成IT專案的地方。Brocent的亞太IT支援解決方案正是圍繞這種形狀的問題建構的——跨層級的多語言支援，加上一個橫跨香港、中國大陸和新加坡的服務台真正需要的區域法規意識。我們的AI+支援服務幫你設計分類模式、提示詞和覆核關卡，讓輸出可稽核而不只是快；託管IT支援則在它開始承載真實流量之後，負責整合、憑證和監控。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

怎麼判斷AI翻譯夠不夠好？

別用翻譯指標。去衡量結果：七天內重開率、一次解決率，以及按工單語言拆分的滿意度。再加上「產生的草稿與實際送出回覆之間的編輯距離」作為領先指標——如果它在下降而重開率在上升，說明座席已經不再認真讀了。每週對固定樣本做一次雙語抽查，並把發現當趨勢追蹤。

AI可以不經覆核直接回覆中文工單嗎？

凡是涉及金錢、合約、資安或主管機關的，不行；而對多數中小企業服務台來說，誠實的答案是：其他類型目前也還不行。行得通的中間狀態是：只自動送出不含實質內容的確認和狀態更新，而每一份真正的答覆都過人一遍。等你在自己的工單上累積了六個月的品質資料之後再重新評估，而不是依據供應商的基準測試。

工單內容跨境會觸發《個人信息保護法》義務嗎？

可能會，具體取決於個人在哪裡、涉及什麼資料、以及資料量有多大。工單內文經常包含個人資訊，所以請把「把它們送到境外模型端點」當作一次需要合法性基礎的傳輸，而不是一個技術細節。如果你有相當比例的客戶在中國大陸，請在擴大規模之前而不是之後把部署方案過一遍審查，因為在一個已經跑起來的整合上補資料落地要求，代價很高。

到什麼量級，這比招雙語座席更划算？

沒有一個通用數字，但形狀是一致的：每月幾百張工單以下，招人就是更好。從那裡到幾千張之間，AI輔助方案開始在路由和起草上勝出，而你仍然需要雙語的人處理升級。再往上，約束就不再是成本而是招聘——真正雙語的技術支援人員在多數市場都很難找，而正是這種稀缺、而非薪資那一欄，最終推動了決策。

一張工單裡兩種語言都有，怎麼辦？

把「混合語言」當作一個獨立的分類取值，而不是強行判定一個主要語言，因為強行判定正是路由錯誤集中的地方。有雙語座席有空時，把這類工單路由給他；並讓模型用客戶最近一則訊息所用的語言起草——那通常就是他們希望收到答覆的語言，不過值得確認一下，而不是想當然。

這套做法能用在Freshdesk以外的系統上嗎？

可以。這裡沒有任何東西專門依賴Freshdesk——這套模式需要的是一個工單建立的webhook或觸發器、一個能把自訂欄位寫回去的API，以及一個讓座席在送出前看到草稿的位置。Zendesk、ServiceDesk Plus和多數現代平台都提供這三樣。在擴大規模之前先查一下寫入路徑的速率限制，因為那是大家最先撞上的約束。

從哪裡開始

匯出一個月的工單，數一數每種語言各有多少，然後分別看它們的首次回應時間。如果這兩個數字有明顯差異，你已經有了本文描述的問題，而單是分類這一步就足以回本。先把它建起來，隱藏運行兩週，在用它做任何路由之前，把它的判斷和座席的實際行為做對比。回覆起草留到術語表建好之後再說。如果你更希望把分類模式、資料處理設計和工單系統整合一起做好，歡迎與我們聯絡。