一、速览

入门

NextAI Translator 是一个基于 ChatGPT API 的翻译工具，形态上同时覆盖浏览器插件和跨平台桌面应用。项目最初从 Chrome 扩展起步，如今已扩展为支持 Windows、macOS、Linux 的桌面端，核心思路是用大语言模型替代传统机器翻译引擎。

与 DeepL、Google Translate 这类传统翻译工具的本质区别在于：它不依赖专门的翻译模型，而是通过 prompt 工程让 ChatGPT 完成翻译任务。这意味着你可以自定义翻译风格、术语表，甚至让 AI 在翻译的同时做润色或解释。

项目当前约 25k Star，使用 TypeScript 编写，浏览器端与桌面端共用核心逻辑，同时用 Rust 处理桌面端的系统级能力。如果你已经在使用 ChatGPT API，或者对翻译质量有更高要求，这个项目值得尝试。

注意：由于 OpenAI 的商标警告，原项目名 "openai-translator" 已更名为 NextAI Translator，使用时注意区分。

二、设计理念

进阶 · 推荐细读

理解这个项目的心智模型，核心是抓住一个关键词：LLM 即翻译引擎。传统翻译工具把翻译当成一个封闭的黑盒，而 NextAI Translator 把翻译当成一次对话生成任务。

这个设计带来三个直接后果：

Prompt 即配置。 翻译行为完全由 prompt 模板驱动——你可以定义系统提示词来决定 AI 的角色、语气、术语偏好。项目内置了多种场景模板（学术、口语、代码注释等），本质上都是不同的 prompt 字符串。

多 Provider 抽象。 项目抽象了统一的 API 接口层，底层可以接 OpenAI、Azure OpenAI、以及各类代理服务。这意味着 API Key 的配置方式、请求的鉴权逻辑都集中在这一层，上层翻译逻辑完全无感知。

流式响应优先。 桌面端和浏览器端都优先采用 SSE 流式输出，翻译结果逐字呈现。这不仅是体验问题，也决定了项目的状态管理设计——需要处理流的中断、重试、部分结果缓存。

项目中值得留意的约定是：翻译历史、配置项、自定义 prompt 都存放在用户的本地存储中，没有服务端同步。这保证了隐私，但也意味着多设备之间需要手动迁移配置。

三、快速开始

入门

浏览器插件（最简路径）

如果你只是想先用起来，直接去 Chrome Web Store 或 Firefox Add-ons 搜索 "NextAI Translator" 安装即可。安装后需要做两步配置：

1. 点击浏览器工具栏的插件图标，打开配置面板
2. 粘贴你的 OpenAI API Key（或选择 Azure / 代理服务商并填入对应配置）

刷新页面后，选中任意文本即可看到翻译按钮。默认的触发方式是选中文本后点击悬浮球，也可以在设置中改为快捷键触发。

桌面端

从 GitHub Releases 页面下载对应系统的安装包（Windows 为 .exe，macOS 为 .dmg，Linux 为 .AppImage 或 .deb）。安装后首次启动会引导你完成 API Key 配置，流程与浏览器插件一致。

从源码构建

如果你需要自定义行为或贡献代码，可以本地构建：

git clone https://github.com/nextai-translator/nextai-translator.git
cd nextai-translator

# 安装依赖
pnpm install

# 构建浏览器插件
pnpm run build:extension

# 构建桌面端
pnpm run build:desktop

构建产物分别在 dist/（浏览器插件）和 release/（桌面端）目录下。浏览器插件需要在 Chrome 的扩展管理页面开启「开发者模式」，然后选择「加载已解压的扩展程序」指向 dist/ 目录。

四、核心概念

进阶 · 推荐细读

Provider 配置层

项目在设置中提供多个 Provider 选项：OpenAI、Azure OpenAI、以及第三方代理服务。配置的核心是 API Key 和自定义 API 地址。对于 Azure 用户，需要额外配置资源名称、部署名称和 API 版本：

const API_URL = `https://${resourceName}.openai.azure.com`
const API_URL_PATH = `/openai/deployments/${deployName}/chat/completions?api-version=${apiVersion}`

如果你无法直接访问 OpenAI，可以在设置中选用代理服务，只需填入代理提供的 API Key 即可，无需额外配置转发规则。

代理服务通常比官方 API 便宜（项目内嵌的 TeamoRouter 号称可节省 90% 费用），但注意第三方服务的安全性——建议使用独立的 API Key 并设置消费上限。

翻译流程的生命周期

一次完整的翻译请求大致经过以下阶段：

1. 触发：用户选中文本，插件或桌面端捕获选区
2. Prompt 组装：根据当前选中的场景模板，将原文嵌入 prompt 模板
3. 请求发送：通过 Provider 层向 LLM 发送请求（支持流式）
4. 流式渲染：逐 token 渲染翻译结果，用户可随时中断
5. 历史记录：翻译结果写入本地历史存储

其中第 2 步是最值得自定义的部分。项目允许你在设置中编写自定义 prompt 模板，例如让 AI 在翻译代码注释时保留术语原文，或在翻译论文摘要时采用学术语气。

桌面端与浏览器端的边界

两个端共用翻译核心逻辑，但桌面端额外支持系统级划词（任意应用中选中文本即可翻译），浏览器端则专注于网页场景。如果你主要阅读英文技术文档，浏览器插件足够；如果日常工作涉及 PDF、桌面应用等场景，桌面端更合适。

五、生态与扩展

进阶 · 推荐细读

项目的扩展性主要体现在两个维度：场景模板和自定义 Prompt。

场景模板是内置的 prompt 预设，覆盖翻译、润色、总结、解释代码等常见需求。你可以在设置中查看每个模板的实际 prompt 内容，作为编写自定义模板的参考。社区中也有人分享自己的模板配置，可以在 GitHub Discussions 中搜索。

自定义 Prompt 的语法遵循 OpenAI 的 Chat Completions 格式，支持 system、user、assistant 三种角色。一个典型的自定义模板：

system: 你是一位专业的技术文档翻译专家。将用户输入的英文技术文档翻译为简体中文。
要求：
1. 保留代码块、命令、文件路径的原文
2. 术语遵循国内技术社区常用译法
3. 保持 Markdown 格式不变

user: {原文}

需要注意的是，项目本身没有插件市场或主题系统，扩展能力完全依赖 prompt 层面的灵活性。如果你有更复杂的需求（比如接入自建模型服务），需要修改源码中的 Provider 层。

六、常见问题与建议

入门

API Key 安全。 插件和桌面端的 API Key 都存储在本地，不会上传到项目方服务器。但要注意：使用第三方代理时，你的请求内容会经过代理服务器，敏感文本慎用。

翻译质量调优。 如果觉得默认翻译结果太生硬，优先调整 prompt 而不是换模型。在自定义 prompt 中明确指定翻译风格（如「意译优先，不要逐字直译」），效果提升比更换模型更明显。

流式中断问题。 使用代理服务时可能遇到流式中断，常见原因是代理的超时设置过短。建议在 Provider 配置中适当调大超时时间，或选择响应速度更稳定的代理。

多设备配置同步。 项目没有云同步功能，换设备后需要手动迁移配置。可以在设置中导出配置文件，在新设备上导入。

项目信息

参考链接

• GitHub 仓库