前言

在《我在用什么浏览器翻译插件？》这篇博文里我提到过我对浏览器翻译插件的体验和需求，那时候用了一阵子的 trancy，后来不知何时就弃用了，当时我就提到过，这不是我理想中的翻译插件（个人主观原因）。

在简单导航（simpleNav）基本不必再改动之后，我又萌生了改一个停更开源翻译插件的想法，虽然很早之前就有过，但 codebbudy 没能给我足够的信心。现在换上了 trae solo，我觉得效率上起码要高出不少。

选择

选择项目

停更许久的翻译插件大多是翻译接口失效或者不好用，看起来只需要替换接口就可以，所以我想找的是轻量，且使用体验比较适合我的项目。对比了一下轻氧翻译和侧边翻译，我最终选择了后者。

侧边翻译是我曾使用过很长一段时间的翻译插件，可惜已经停更很久了。加上现在各大翻译插件都有 AI 模型的加持，传统的机翻很难满足要求。

为了避免误导其他人，所以在遵循原项目的开源协议前提下，把这个新项目命名为“轻量翻译”，英文名：lightrans。

选择接口

既然不要机翻，又要考虑到公开给大众使用，就不能有高昂的开支，所以我首先想到的是用智谱清言的官方 api 调用 GLM 4.5-Flash，但是并发数限制得非常低，加上翻译速度没有达到我期望的即点即译，于是作罢。

好在我又体验了一下 trancy，发现 trancy 也没有免费提供 GLM 模型，而是改成了硅基流动。于是我注册了硅基流动的账号，发现居然有免费的模型可以使用！硅基流动真是带善人！

首先体验的是 deepseek 的一个模型，翻译速度也很慢（我猜测是因为有推理思考过程），在网上多方了解，发现Hunyuan-MT-7B倒是一个不错的专为翻译而生的小模型，腾讯混元官方的 api 依然是收费的，还好硅基流动限免提供使用。最后我选择了三个体量都不大的小模型：Hunyuan-MT-7B、Qwen2.5-7B-Instruct和GLM-4-9b-chat。

这三个模型除了混元比较新之外，另外两个都算比较老的模型了，没办法，不花钱嘛，况且效果也不是不好。

根据我的用量级别，我使用这几个模型的速率限制为：1000 RPM 和 80000 TPM。即每分钟请求数1000，每分钟处理 token 数80000。

开改

精简代码

侧边翻译不是个人开发者的作品，应该类似于一些较大的开源项目组织维护，所以侧边翻译里有非常丰富和强大的功能及代码。考虑到我只需要接入一个翻译接口，于是必应、谷歌和百度等翻译接口都删掉了。

初次以外还删掉了分析代码、隐私政策、部分设置项和个别国家的本土化适配等等，源代码从14MB缩减到4.5MB。

添加翻译器

由于我选择的三个模型都是对话模型，所以请求的 api 地址一样，于是我只创建了一个 aitrans 的翻译器，方便测试就在代码里明文写了我的私钥，经过测试，对话框（popup）翻译正常，划词翻译正常，但是网页翻译不正常。

修改

原本的侧边翻译的对话框默认是搜索的，输入文本点击翻译后即会在侧边栏显示翻译结果，但是测试了一下目前的翻译接口都已经失效了。为了获得输入和获取结果的一致性，即当前对话框不会被打断关闭而显示另一个对话框，我改了 popup 的样式，并使它能够直接在当前窗口显示结果。

除了对话框以外，侧栏显示翻译也会让人的视线离开当前关注的区域，所以我把划词翻译的结果也以浮动的卡片形式显示在了当前位置，并且和原来一样支持拖动。以下是划词翻译中三个不同模型结果的对比（发音按钮点击无效，功能删了但是还没删按钮）：

当然，用不着的设置项也可以删掉，因为我的需求没有那么丰富（不然就用 trancy了），为了追求极简但好用，所以砍掉了许多原本有的功能，也为后面的修改和维护减轻一点负担。

看起来基本可以正常使用了，但是网页全文翻译依然不行。原项目使用的是谷歌和有道，但是有道已经下线了，谷歌在国内也无法直接访问，看来要支持网页翻译需要改动的还挺多。

中间的过程就不再赘述了，除了新增代码，调试代码之外，还要测试不同的请求频次和字符数，以免触发硅基流动限频的策略。

一开始选中模型进行网页翻译，往往要过十来秒钟页面才会有变化。或许是内容太多了模型处理也要时间吧，于是我设定了分批次提交，最高并发三个，最多重试三次。所以在进行网页翻译的时候可以看到内容是一部分一部分出来的，但是间隔不算大（主要是网页本身的菜单栏花的时间多，正文其实很快）。这样用户能感知到翻译已经开始了，而不是像之前一样等待了十来秒都没反应，于是不断尝试，就更容易触发限频。

从翻译结果来看，不知道为什么千问模型会漏掉几个词语不翻译，也可能是我的代码有问题，相比之下，混元模型翻译得还不错，有些专有名词甚至会加括号解释说明。比如昨天在新华网英文站翻译页面时，发现它会解释“GuoChao”这一个词汇，但是我没找到那篇新闻，只能找另一个，没想到也复现了。

这是更完整的页面翻译。

最后

通过这次改写这个开源项目，我才发现原来微软的机翻 api 也是要钱的，那么多较大的翻译插件都把谷歌和微软翻译免费使用，甚至开放一些 AI 模型翻译免费使用，这样看起来他们真的是在为爱发电了。

而我能轻松改写这个项目，要感谢侧边翻译的开发者们的开源，也要感谢 trae solo 的帮助。考虑到我的 api 限频问题，所以暂时没想过上架应用商店，但是如果愿意体验并且给我提出意见的话，也欢迎下载扩展包尝试一下。

项目地址：hin/Lightrans · CNB

扩展包下载：lightrans_chrome.zip | w4j1e’s drive

前言

在此之前，我用过好几年的 weTab 插件，自定义程度很高，小组件也很丰富。这几年，我见证了 weTab 从一个简单的导航页渐渐做大做强，而我的首页超链接这几年几乎都没怎么变过，这也足以说明导航页对我而言并非刚需，也确实大多数时候我访问网站都是依赖浏览器的自动补全。话虽如此，在 weTab 每次打开浏览器就开始同步导致我的老电脑要卡死好一会开始，我就决心自己做个导航页了。

说干就干！今年七月份我在 github 上传了第一个版本——当然，是由 AI 写的。一开始想做成一个动态页面，但又不愿折腾数据库，所以干脆把我常用的链接写死成了一个完全的静态页面，仅仅壁纸由必应日图的 api 负责每天更换。

上周，我和 inkss 说了我的计划，想找一个好用又好看的开源项目改一改部署在 edgeone pages，他也有些兴致，但是我们都没有找到更好的方案。于是我提到七月份写的那个导航页项目，在他有事搁浅了之后，我每天抽闲暇时间用 AI 继续改写，本文就简要记述一下这一件事。

CodeBuddy

由于我的编程经验并不丰富，加上 VS code 上只有一个 codebuddy 插件，所以一开始的任务都是交给它的。需求是：把这个纯静态页改成 next.js 项目，使用 onedrive 登陆和同步数据，以便后续直接在前端管理，也无需后台和数据库。

codebuddy 很快就完成了项目重构，并且根据代码和实现功能写了第一版 README，网页可以正常跑起来了，但我没想到需要折腾修改的大量工作还在后面。

一开始在本地开发，测试没有发现什么问题。推送到 github 由 EO pages 拉取部署，我也在 EO 添加了对应的环境变量，而遇到的问题包括但不限于（npm run dev 和 npm run build 居然有这么大的差别）：

① TypeScript编译错误，代码中尝试直接展开（...）一个 Set 集合，但当前的TypeScript编译配置不支持这种操作；

解决方式：将编译目标设置为支持ES2015（即ES6）及以上的环境。

② Next.js 应用路由没有正确设置成动态，Next.js 14 默认会尝试静态化所有路由，包括 API 路由，这就导致无法正常登陆 onedrive 服务；

解决方式：在必要的 api 路由中添加代码强制动态渲染。

export const dynamic = 'force-dynamic';

③ 开发环境和生产环境混淆，在开发环境中使用的回调地址是 localhost，在生产环境中依然如此而不是我的域名；

解决方案：使用环境变量动态设置重定向 URI。

④ 登陆失败，在前端使用微软账户登陆，跳转回来后页面依然是未登陆状态。

解决方式：让 AI 在多个断点打 log，当然 codebuddy 也自作聪明地写了两个 debug 页面，以便输出更多调试信息。

但也正是因为这个调试信息，我发现 requestURL 依然是 localhost 而不是我当前使用的域名，于是围绕这个问题我和 codebuddy 改了多次。由于本地环境测试没有任何问题，所以我一度怀疑是 EO pages 的策略有问题。

腾讯云技术排查后，告诉我应该还是代码的问题，云平台是没问题的。我仔细查看更详细的 debug 页面内容和网络请求，发现登陆后确实正确回传了认证信息，而网页没有能够获取到这一点。

继续和 Codebuddy 多次斡旋，最后我终于忍受不了它时不时显示“模型参数错误”这类的提醒，修改代码时陷入死循环，决定再换回 trae 试试。

trae

trae 是字节跳动开发的一款 IDE，上一次用还是七月份，彼时的豆包大模型常常给我的代码重复写几千行相同的内容，我就卸载了它。

再次换回 trae，居然发现它比 codebuddy 好用太多，它好像更能理解我的表述，分析代码的逻辑性也更强，修改一处代码后也会记得同时修改受到影响的其它模块。一开始它在修改代码后会在本地启用 npm run dev，但是它会开多个终端，然后发现端口一直被占用，后来就不用开发模式，而是直接在本地构建 npm run build，终端有报错的话它还会再次修改代码。

在 trae 的帮助下，我不断修复遇到的各种 bug ——用 AI 写代码就会面临这样的问题，要多次调试和修复。我的 github 仓库里最近的提交几乎全是修复 bug 的。

用 trae 后，这个导航页终于基本可以正常使用了。

SimpleNav

说起来是“简单”导航，但是我挺想实现还未实现的功能又挺复杂，比如在首页增加天气、热搜和电影推荐小组件，也想像 weTab 那样可以整一个在线的 TODO 小组件之类的玩意。但是我时间有限，尤其是最近超级忙，所以只能往后面再拖延了。

项目地址：W4J1e/SimpleNav: 这是一个简洁的自用导航页。

体验地址：SimpleNav

功能特点

• 🎨 美观的界面设计：支持多种背景类型（纯色、图片、渐变、Bing每日一图、本地上传）
• 🌅 自动更新壁纸：支持自动获取并更新Bing每日一图作为背景
• 🔍 集成搜索功能：目前只支持必应
• 📱 响应式设计：适配各种设备屏幕
• 🗂️ 分类管理：支持链接分类和筛选
• 🌙 主题切换：支持明暗主题切换
• ☁️ 云同步：支持OneDrive云同步功能
• 📤 数据导入导出：支持 json 格式的数据的备份和恢复
• 🖼️ 图标选择：支持Font Awesome图标或网站favicon
• 🔥 小组件集成：目前支持知乎热榜、电影日历和待办事项
• 📌 卡片拖动排序：支持所有卡片的自由拖动排序

基本使用

1. 添加链接：点击页面中的”+”按钮，填写链接信息
2. 编辑链接：右键点击链接卡片可以编辑或删除链接
3. 分类筛选：点击顶部的分类标签进行筛选
4. 搜索功能：使用搜索框进行网络搜索
5. 设置页面：点击页脚的”设置”按钮登陆 onedrive 以同步、设置网页背景和数据导入导出
6. 卡片位置：长按卡片可以拖动调整位置

自部署

目前支持大多数无服务平台的部署，可以 folk 我的仓库，连接到 vercel 或者 EO pages 之类的平台，选择 nextJS 项目进行部署。

需要配置以下环境变量：

AZURE_CLIENT_ID=your_azure_client_id

AZURE_CLIENT_SECRET=your_azure_client_secret

AZURE_TENANT_ID=your_azure_tenant_id

AZURE_REDIRECT_URI=https://yourdomain.com/api/auth/callback

JWT_SECRET=your_jwt_secret_key

详情可以参考部署文档。

写在最后

AI 编程的兴起，让我这种基本不会编程的人也可以更高效地完成一些小打小闹的项目，这真是个伟大的时代！但是这个过程中我每一次都更清晰地意识到，打铁还需自身硬，如果完全依赖 AI 去修复 bug，自己没有技术实力，会走很多弯路。

前言

浏览器翻译插件对我来说一直是可以不常用但不能没有的东西。目前我用的 edge 浏览器，微软的翻译众所周知，所以侧边翻译插件不太更新后，我用上了腾讯的翻译插件，没想到后来也凉了。在碎月的推荐下，我用了一段时间的沉浸式翻译。

前几天，沉浸式翻译被爆出泄露用户信息，加上我一直不太习惯它输入翻译要跳转网页的方式，整体稍显臃肿，于是我决定换掉它。

我期望的浏览器翻译插件是简约的，有 AI 大模型加持可以翻译得更准确的，可以在输入框输入文本便捷翻译的。

Trancy

trancy 是我在又一次体验众多翻译插件后的选择。它的定位应该倾向于外语学习，但是在网页翻译这方面又很符合我的需求。

核心优势

• AI模型：最大亮点是免费提供GLM-4 Flash模型使用权限，这是其它许多插件需付费才能享受的高级 AI 翻译能力。除此以外，它也内置了 deepseek、GPT、Claude 和 Gemini 模型，也支持自定义添加，不过后面这些是付费功能；

• 字幕翻译：在YouTube等视频平台上提供双语对照字幕支持，这个功能沉浸式翻译也有，但是我没使用过（或者是没使用成功过），trancy 可以很好地支持，并且可以选择翻译的大模型；

  

• 响应迅速：我初次体验时便遇到了输入框翻译功能无效的情况，具体表现为输入中文，在其它语言中依然显示中文，输入其它语言能正常翻译成中文。当时我通过邮件的形式反馈了“快捷翻译无效”的问题，开发者很快回信，并且当天中午就通过热补修复了该问题。

  

• 多平台支持：除了 chrome 和 firefox 这两大浏览器阵营，trancy 还支持其它平台和浏览器，比如 safari。

  

当然，学习方面的功能因为我需求不大，所以没有深入体验，但它的功能确实比较丰富。

我认为的遗憾

因为我的需求和 trancy 的定位并不十分匹配，所以现有的遗憾主要是是对我个人而言的。

一开始，我觉得其它模型和自定义模型等需要付费是遗憾，但是整体来说 GLM 4 Flash 模型的翻译准确度还可以，所以就没太在意这点。

此外，插件的布局于我而言不太高效。我非常喜欢谷歌翻译插件那种，点击图标即可直接输入要翻译的词句，trancy 点开之后的布局如图：

看起来这个布局确实更适合学习其它语言的用户，而我常用的设置和快捷翻译则在第2和第4。

对比

当然，我也深知没有最完美的产品，只有更合适的产品，所以我也曾试图想过借助 AI 自己写一款自用的翻译插件——好多方面我都想过去重复造轮子。但即便有 AI ，完成一个完整的好用的项目依然需要花费大量时间，所以我简单评测了一些翻译插件。

基于实际体验和测试，整理主要翻译插件（不完全）关键特性对比如下：

当然，除了产品对比外，我也尝试了 trancy 自带的诸多模型翻译的对比。以英文版新华网某天的一条新闻标题为例，翻译结果如下图所示：

在这些模型中，没有一个大模型能正确翻译出‘卢卓灵’这个人名，看起来都没有实时调用网络搜索，GLM 4 Flash 居然把Lu Zhuoling翻译成了鲁智玲。

在人名方面，我更认可 GPT 5 nano 的处理方式，即套用原文，而不硬要去翻译它;当然，特定的称谓翻译也有不同的表现，我们假设 A 国的领导人姓“于”，英文的新闻标题往往可能这样写：Yu says A-country will continue to promote peace talks in Ukraine crisis，一个好的模型会这样翻译：于某某表示A国将继续推动乌克兰危机的和平谈判，而有些模型可能会直接翻译成“于说……”甚至“于于说……”。

如果抛开人名翻译的问题，我个人觉得 deepseek 的翻译最符合新闻标题的特征，简洁和准确。

最后，我很讨厌必应那种自作聪明的“本土化翻译法”，比如输入youtube，它会翻译成“优酷”，我不记得是哪个模型也有莫名其妙的翻译（写本文时 bing 和 GLM 4 Flash）都没有成功复现：

写在最后

关于沉浸式翻译泄露了用户隐私信息的事我无法做专业的评价，但是我想，除了使用体验以外，用户肯定还很在意一款产品的安全性。

在翻译这方面，我期待越来越多的大厂可以做出更好的产品，尤其是在这个 AI 普惠的时代，如果依然只是依赖传统的机翻，那还能有什么竞争力呢？没错，微软，说的就是你！