我怎样用 AI 做出一款替代付费工具的轻量翻译器

当时摆在我面前的，是一笔 1599 元的翻译工具年续费。原来的工具足够成熟，能够覆盖网页、文件和其他翻译场景，对许多人来说，这些能力都有实际价值。

这笔续费促使我重新考虑一个更具体的问题：我究竟在为什么付费？

回看自己的日常使用，我高频依赖的主要只有两条路径。一条发生在网页阅读中，我希望选中一段外文后，直接在原文附近看到译文，保留双语对照。另一条发生在 macOS 的不同应用里，我希望选中文字，快速翻译，再把译文放回正在编辑的位置。

我想替代的，从来不是一款成熟翻译产品的全部能力，只是自己每天反复使用的这两条路径。这个范围需要先说清楚，否则“替代”很容易变成一个比实际结果大得多的词。

把一张功能表还原成两个动作

成熟产品需要面对许多人的需求，因此会提供 PDF 翻译、字幕翻译、术语库、整站翻译等能力。它们并不多余，只是没有进入我的高频使用过程。如果以完整产品为参照，我需要补上的功能会不断增加；如果回到自己的两个动作，项目边界就清楚了许多。

网页阅读的起点是选区，结果要回到原文附近。这样我可以继续看原始表达，也能逐段对照译文，不必在网页与另一个翻译窗口之间来回切换。

macOS 端面对的是另一种情境。翻译可能发生在邮件、文档，或其他支持标准选区和复制粘贴的应用里。这里更重要的是把当前文字转换成另一种语言，再继续原来的编辑动作，并不需要保留一份双语页面。

两条路径都很短，却发生在不同的环境，也需要不同的交互。边界确定后，我借助 AI 分别把它们落实为个人 Chrome 扩展和个人 macOS 工具。AI 协助我梳理方案、完成实现和处理问题；我持续判断每个结果是否仍贴合阅读与编辑场景，决定哪些能力要停在范围之外。两个入口没有被塞进同一个大型界面，各自只需要完成眼前的任务。

现在回看，我判断这套工具是否成立，主要看三件事：阅读时能否留在原页面，编辑时译文能否回到原位置，等待是否会打断当前动作。它们比一张不断扩大的功能清单，更贴近最初的问题。

边界清楚以后，判断标准也变得具体：Chrome 端不能只得到译文，结果还要回到原文附近；macOS 端不能只完成模型调用，译文还要回到正在编辑的位置。至于那些没有形成高频需求的外围能力，就继续留在范围之外。

个人 Chrome 扩展，让译文留在阅读现场

个人 Chrome 扩展负责网页中的选区翻译。选中一段内容后，译文会出现在原文附近，原文仍然保留。对于长文阅读，这种对应关系比单独得到一段翻译结果更重要。我可以继续沿着网页原有的顺序阅读，在需要时对照原句，也更容易知道译文对应的是哪一段内容。

从当前效果图里，可以看见英文段落和中文译文在网页中的对应关系。它呈现的是一次真实使用。对我而言，判断这条路径是否成立，看的仍然是它能否在日常阅读中稳定出现，能否让翻译结果回到当前语境。

Chrome 目前也是我使用频率稍高的入口。个人 Chrome 扩展目前固定使用 DeepSeek V4 Pro，并关闭 Thinking。减少每次使用前的选择，也让它更接近一个打开就能工作的日常工具。

个人 Chrome 扩展当前使用图中所示的模型与接口，同时关闭 Thinking。这些都是我为日常翻译作出的个人设置，不代表 GitHub 通用 Chrome 扩展的默认配置。

个人 macOS 工具，把译文送回原来的位置

网页之外，我不希望为了翻译一小段文字，先复制内容，再打开另一款应用，最后把结果复制回来。个人 macOS 工具为这条路径提供了一个更直接的入口：在当前应用里选中文字，按下 Option + T，工具完成翻译后，把译文回填并替换原选区。

这个入口服务的是正在进行的编辑。原文被译文替换以后，我可以继续处理邮件、文档或其他文字内容。它与 Chrome 扩展都在解决翻译问题，结果形态却不同：网页阅读需要保留原文与译文的对应，跨应用编辑需要让译文回到当前正在处理的内容中。

个人 macOS 工具同样固定使用 DeepSeek V4 Pro，并关闭 Thinking。API Key 保存在系统钥匙串，Option + T 是当前的快捷入口。由于译文会直接替换原选区，这种交互本身并不保留同一画面的翻译前后对照。

这种跨应用方式仍然有边界。它依赖标准选区与复制粘贴，复杂的富文本结构、焦点变化或特殊编辑器都可能带来限制。AI Translator 首先是一件围绕我自己常用场景形成的工具，不需要因为已经进入日常，就把它描述成能够覆盖所有 macOS 应用的通用产品。

两个入口，不必长成同一种工具

个人 Chrome 扩展与 macOS 工具共享同一个目标，却没有使用同一种界面。Chrome 扩展需要理解当前页面里的选区，把译文放回原文附近；macOS 工具需要从系统选区取得文字，再把结果送回原来的位置。把它们分开，反而让每个入口只承担一种清楚的任务。

这里的“轻量”，不只是删减功能和缩小界面，更重要的是让一段操作尽量留在它原本发生的环境里。阅读时不离开网页，编辑时不离开正在使用的应用，工具只在需要的那一刻出现。

如果为了形式上的统一，把所有翻译都集中进一个独立窗口，我仍然要承担复制、切换和寻找上下文的成本。两个入口看起来没有那么整齐，却更贴近两条真实路径各自的起点和终点。

高频工具，等待时间也属于功能

工具能够完成翻译以后，模型选择并没有就此结束。我曾尝试过自己当时认为能力更强的模型方案。它们可以得到翻译结果，但在我的实际使用里，等待时间更长。对于偶尔发生的任务，这段等待也许可以接受，放进每天反复出现的阅读和写作动作后，它会不断打断当前节奏。

翻译是一条很短的操作。选中文字之后，我期待的是尽快拿到足够可靠的结果，再继续眼前的事情。如果每一次调用都要等待更久，即使模型在纸面上拥有更强的能力，我也可能越来越不愿使用它。这个问题只有在工具进入日常以后才会显现。

最后，我把个人 Chrome 扩展与 macOS 工具重新固定为 DeepSeek V4 Pro，并关闭 Thinking，以减少高频翻译中的额外等待。这个选择只针对 AI Translator 的个人使用场景。我没有据此判断某个模型在所有任务中更好，也不认为所有翻译产品都应该关闭思考模式。它解决的是一个具体取舍：日常中英翻译需要的质量、速度和稳定性，怎样落在更合适的位置。

这段调整让我确认，对高频工具来说，响应速度并非完成核心功能之后才考虑的附加体验。等待会直接决定一次操作能不能自然接进阅读和写作，因此速度本身就是功能的一部分。

个人版与开源版，服务不同目标

AI Translator 当前有三个需要分清的形态：个人 Chrome 扩展、个人 macOS 工具，以及 GitHub 通用 Chrome 扩展。前两者是我仍在使用的个人入口。后来，我另外整理出通用 Chrome 扩展，让使用者可以自行配置兼容接口、模型和 API Key。

这个 GitHub 公开仓库 只包含通用 Chrome 扩展，不包含个人 macOS 工具。它也没有固定绑定我个人使用的 DeepSeek V4 Pro 配置。个人版追求减少变量，让已经验证过的路径保持稳定，通用版则需要给使用者保留服务与模型选择。两者从同一个网页翻译需求出发，承担的目标并不相同。

代码已经公开，可以被查看和使用，但这不能证明它已经获得社区、用户或市场验证。就目前而言，AI Translator 首先仍是一套长期自用的个人工具，公开仓库只是其中通用 Chrome 版本的整理结果。

它替我接住了什么

现在，Chrome 与 macOS 两个入口仍在我的日常里。网页中的双语阅读由 Chrome 承担，跨应用的选区翻译与回填由 macOS 端承担。对我来说，原先依赖付费工具完成的两条路径已经被接住，这就是“替代”在这篇文章里的完整范围。

PDF、字幕、术语库和整站翻译仍在这套工具之外。它是否适合其他人，取决于各自的工作流和维护意愿；我的结果只说明个人使用中的两条路径已经成立。

这次实践改变了我判断个人工具价值的方式。一张完整的功能表并不等于我的真实需求。只有把每天反复发生的动作单独拿出来，我才知道什么必须留下，什么可以暂时不做，以及一个更小的方案怎样才算完整。

功能更少并不会自动带来克制。真正重要的是先看清边界，再决定什么值得留下。AI Translator 没有复刻一款成熟产品，也没有替所有人提供答案；它只是把我真正离不开的两条路径，做成了能够长期进入日常的个人方案。对我来说，这已经是一次成立的替代。