今天因為周末的緣故沒怎么上班，于是今天一整天都在折騰如何將 AI 的翻譯能力引入到 WordPress 電商網站中。

其實這個話題在前面有篇文章中聊過，當時使用的方案是仿照 DeepL 的開發文檔開發一款 API 服務，然后直接修改 TranslatePress 插件的遠程請求地址。

可能是因為當時那個版本做得比較糙的緣故，效果一直都不怎么好，甚至有些語種的翻譯根本就不成功。

后面文章發布之后，在一位朋友的幫助下順利將 Worker 的緩存機制使用了起來，今天折騰了一上午算是將翻譯這個流程全部走通了，實現從零到一的突破。

原本以為后面可以一勞永逸的將這個方案遷移到另外幾個電商站點上，從此順利在 WP 網站上實現絲滑的內容 AI 翻譯。

誰承想等真正應用到生產環境上之后，問題立馬就出來了。

主要的點有兩個，其一是速度跟不上，其二是內容量多起來后，AI 的能力跟不上。

比如上圖便是 API 的處理日志，會發現當翻譯請求的內容量上來之后，AI 根本處理不過來。

即便我將 Worker 服務升級到付費版本，所有限制都去掉之后，還是處理不過來。

尤其是對于文章之類的場景，隨隨便便一篇文章可能有一兩千字，突然大量的翻譯請求進來之后，AI 需要消耗很多資源去消化，過程中自然需要更多的時間。

而一旦超時，你會發現在網站前端根本就沒有相應的翻譯效果，而相應的 Token 卻實實在在被浪費掉了，屬于是“人財兩失”。

過程中，我分別去調整了 Prompt 的要求，以及格式處理的要求。

但不管怎么調整，對于大內容量（文章、長頁面）的翻譯，其功能依舊不能實現。

所以后面這種直接翻譯方案，我可能需要謹慎使用了。

可能針對這種翻譯場景，我后面會更傾向于將網頁上的文本詞條全部下載下來，本地處理好之后再進行上傳。

過程中的技術方案有兩種，一是使用 RPA 代替人工去手動翻譯，二是直接在數據庫里更新數據。

RPA 這種方案我很早之前就做出來了，但是處理起來比較耗時，且因為頁面元素不規則的緣故，比較容易出錯。

所以我現在更傾向于直接去更新數據表，但困難也比較大，就是需要后面專門抽一塊時間去學習 TranslatePress 的代碼結構。

后面碰到某個假期再去處理吧，現在先用 RPA 方案過渡一下。