解语为啥使用纯AI方案？

我做的浏览器插件叫解语。它没接任何传统翻译接口，所有请求都发给大模型。为什么？

先说个场景。

你读到一句话，每个词都认识，连起来就是不知道它在说什么。这种时候把它翻成中文也未必管用——你缺的不是冰冷的翻译，是有人用地道自然的说法告诉你：这句话在这个语境、在这个上下文里，是什么意思。

传统翻译其实很强

同样一段英文，谷歌的免费接口 0.2 秒上下就返回了，我的方案第一个字要等 1.3 秒，长段落也是这个量级。慢六倍以上。

谷歌翻译并不弱：大型神经机器翻译模型，在它擅长的范围里做得相当好。

微软这一列是它现在免鉴权的 Edge 翻译通道：2,454 字符的长文一次发完，0.9 秒拿回全文，比我们的完整返回还快。

快，这两家都当得起，单论翻译本身，它们挑不出毛病。

那差别到底在哪？

差别在于上下文理解和指令化结构输出

谷歌没输在语言能力上，输在出身——它打出生起就只干翻译这一件事。

解语的核心功能是划词解释。解释对模型的要求是这样的：

• 看清选中的是普通句子、标题、术语还是代码——四种讲法完全不同
• 把上下文整段读进去，判断一个词在这句话里取哪个义项
• 按固定章节输出：核心含义、用法与搭配、一句话总结

这些都是「请模型照着做」的指令，而翻译接口的输入输出都是裸文本，没地方塞。

解释必须用大模型，这好理解。可翻译呢？谷歌又快又免费，两个引擎各干各的，听着挺美？可惜行不通。

• 论地道：治不了机翻的毛病，译文常常翻对了，但不像人话
• 论上下文：一句话在这段里是什么意思，它管不着
• 论指令：风格化、格式化（比如保留 link 样式），没地方下

翻译要地道、要带上下文、要听语体指令、要保留结构，这几条免费翻译接口一条都做不到。 能同时满足的只有大模型。

AI大模型，可以替换一整条工具链

划词解释、对照翻译、整页翻译、日语假名标注、图片识别，解语这五个功能共用同一条链路。走传统路线，就是机器翻译、词典、术语识别、摘要各接一套——四套接口、四套错误处理、四套账单。

识图的例子最直观。用户丢一张截图，要的是「这张图在说什么」。不用大模型就得自己搭 OCR：几兆的引擎包，每种语言还各配一份数据，认完字还得再接一道理解和翻译；手写体、花背景，识别率还会往下掉。

用大模型，就一次调用：图进去，解释出来。它不是在「认字」，是在「看图」。

砍掉不必要的依赖，安装包只有 300 多 KB。同类双语翻译扩展普遍十几 MB，我们不到三十分之一——扩展常驻浏览器，装它不该是个需要犹豫的决定。

AI 这么好，那么代价是什么？

四个：慢、不免费、输出不稳定、并发受限。都有对应的办法。

1. 慢。谷歌 0.2 秒上下出结果，解语首字要等 1.3 秒，六倍以上。办法：用流式传输缓解，首字一到就上屏；再用 flash 档模型并关闭思考模式，把等待压到最低。
2. 不免费。烧 token 要花钱，但开源模型越来越便宜，尤其是性价比之王 DeepSeek。
3. 输出不稳定。大模型本质上是概率性输出，会漏条目、偶尔不按格式来，还可能被安全过滤器拦下来。办法：提示词约束格式，代码兜底校验，漏的自动重试补齐，拦截有专门的提示文案。
4. 并发受限。上游对并发和速率都有配额，用谁都一样。办法还是流式那套：整篇文章一个请求翻完，把并发占用压到最低；超出的排队冷却，别让「被限流，马上重试，被限得更狠」滚成雪崩。

收个尾

总结一下：传统翻译接口把「翻译」这一件事做得很好，但解语要的上下文理解、指令化输出和结构保留，在它那儿没地方放；这些大模型全都接得住，代价——慢、不免费、偶尔不靠谱、并发受限——每一条都有办法压着。