今天因为周末的缘故没怎么上班，于是今天一整天都在折腾如何将 AI 的翻译能力引入到 WordPress 电商网站中。
其实这个话题在前面有篇文章中聊过，当时使用的方案是仿照 DeepL 的开发文档开发一款 API 服务，然后直接修改 TranslatePress 插件的远程请求地址。
可能是因为当时那个版本做得比较糙的缘故，效果一直都不怎么好，甚至有些语种的翻译根本就不成功。
后面文章发布之后，在一位朋友的帮助下顺利将 Worker 的缓存机制使用了起来，今天折腾了一上午算是将翻译这个流程全部走通了，实现从零到一的突破。
原本以为后面可以一劳永逸的将这个方案迁移到另外几个电商站点上，从此顺利在 WP 网站上实现丝滑的内容 AI 翻译。
谁承想等真正应用到生产环境上之后，问题立马就出来了。
主要的点有两个，其一是速度跟不上，其二是内容量多起来后，AI 的能力跟不上。
比如上图便是 API 的处理日志，会发现当翻译请求的内容量上来之后，AI 根本处理不过来。
即便我将 Worker 服务升级到付费版本，所有限制都去掉之后，还是处理不过来。
尤其是对于文章之类的场景，随随便便一篇文章可能有一两千字，突然大量的翻译请求进来之后，AI 需要消耗很多资源去消化，过程中自然需要更多的时间。
而一旦超时，你会发现在网站前端根本就没有相应的翻译效果，而相应的 Token 却实实在在被浪费掉了，属于是“人财两失”。
过程中，我分别去调整了 Prompt 的要求，以及格式处理的要求。
但不管怎么调整，对于大内容量（文章、长页面）的翻译，其功能依旧不能实现。
所以后面这种直接翻译方案，我可能需要谨慎使用了。
可能针对这种翻译场景，我后面会更倾向于将网页上的文本词条全部下载下来，本地处理好之后再进行上传。
过程中的技术方案有两种，一是使用 RPA 代替人工去手动翻译，二是直接在数据库里更新数据。
RPA 这种方案我很早之前就做出来了，但是处理起来比较耗时，且因为页面元素不规则的缘故，比较容易出错。
所以我现在更倾向于直接去更新数据表，但困难也比较大，就是需要后面专门抽一块时间去学习 TranslatePress 的代码结构。
后面碰到某个假期再去处理吧，现在先用 RPA 方案过渡一下。
