Chrome图片翻译扩展：多模态大模型API实现网页图片实时翻译回填

开发者利用多模态模型 API 开发 Chrome 图片翻译扩展，补全沉浸式翻译等工具对图片翻译的缺失，支持 Qwen、Grok、Seedream 等多模型后端，翻译效果出乎意料地好。

一个开发者用周末 vibe coding 出来的 Chrome 扩展，可能比你想象的更有用。

这款名为「图片翻译助手」的浏览器扩展近日在 Linux.do 社区发布，做的事情很直接：调用多模态大模型 API，识别网页图片中的文字，翻译后回填到原图位置。听起来不复杂，但它精准地戳中了一个长期存在的痛点——沉浸式翻译、阅读蛙这些主流翻译工具，至今搞不定图片里的文字。

一个被忽视了太久的缺口

用过沉浸式翻译的开发者都知道，它处理网页文本的能力堪称一流，双语对照的阅读体验几乎无可挑剔。但一旦遇到嵌在图片里的文字——技术博客的架构图、英文教程的截图、论文里的图表——它就直接跳过了。阅读蛙也是同样的问题。

这不是它们不想做，而是图片翻译本身就是另一个维度的问题。传统路径是 OCR 识别文字 → 翻译 → 重新排版渲染，每一步都可能出错，尤其是「回填」这一步，要处理字体、排版、背景重建，工程量不小。

但多模态大模型改变了这件事的可行性。

用牛刀杀鸡，但刀法不错

这个扩展的思路很暴力也很聪明：把整张图片丢给多模态模型，让模型理解图片内容和文字，直接生成翻译后的结果并回填。开发者自己也承认「用大模型做这事有点杀鸡用牛刀」，但效果确实好。

为什么好？因为多模态模型天然具备上下文理解能力。它不是在做孤立的 OCR + 翻译，而是「看懂」了整张图在说什么，然后基于理解去翻译。一张技术架构图里的 "Load Balancer"，传统 OCR 可能识别成 "Load Ba1ancer"，但多模态模型知道这是一张架构图，知道这个词在这个语境下是什么意思。

图片翻译助手扩展的使用效果对比，左侧为原始英文图片，右侧为翻译回填后的中文图片

开发者测试了多个模型后端，给出了一份实测可用清单：

Qwen Image 2 官方 API：通义千问的视觉模型，中文翻译质量高，毕竟是阿里的主场
xAI 官方 API（Grok）：可用，但旧版模型的文字渲染效果一般
Grok2API：第三方接口，实测能跑
Seedream 5 官方 API：字节跳动的图像生成模型，效果不错
反重力转小香蕉 2：社区模型，可用

值得注意的是，开发者提到「豆包效果不错但无法转 API」，这其实反映了一个普遍问题：很多国产模型的能力已经到位了，但 API 开放程度参差不齐，开发者想用却接不进来。

技术实现：比你想的简单，也比你想的难

从技术角度看，这个扩展的核心流程大致是：

监听页面图片元素（或用户手动选择）
将图片编码为 base64
构造多模态请求，发送给模型 API
解析模型返回的翻译结果
将翻译后的内容渲染回原图位置

其中第 3 步是关键。以 OpenAI 兼容格式为例，一个典型的图片翻译请求长这样：

import requests
import base64

# 读取图片并编码
with open("screenshot.png", "rb") as f:
    image_base64 = base64.b64encode(f.read()).decode("utf-8")

# 通过 OpenAI Hub 调用多模态模型
response = requests.post(
    "https://api.openai-hub.com/v1/chat/completions",
    headers={
        "Authorization": "Bearer YOUR_API_KEY",
        "Content-Type": "application/json"
    },
    json={
        "model": "qwen-vl-max",  # 也可以换成 gpt-4o、claude-sonnet 等
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": "请识别这张图片中的所有文字，翻译成中文，并保持原有的排版结构返回。"
                    },
                    {
                        "type": "image_url",
                        "image_url": {
                            "url": f"data:image/png;base64,{image_base64}"
                        }
                    }
                ]
            }
        ],
        "max_tokens": 2048
    }
)

print(response.json()["choices"][0]["message"]["content"])

这段代码用的是 OpenAI 兼容格式，通过 OpenAI Hub 这类聚合平台，一个 Key 就能切换 Qwen、GPT-4o、Claude 等不同模型后端，方便开发者对比不同模型在图片翻译场景下的表现。

在浏览器扩展里，对应的 JavaScript 实现也类似：

// 在 Chrome 扩展的 background script 中
async function translateImage(imageBase64) {
  const response = await fetch('https://api.openai-hub.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer YOUR_API_KEY',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      model: 'qwen-vl-max',
      messages: [{
        role: 'user',
        content: [
          { type: 'text', text: '识别图中文字并翻译为中文，保持排版结构。' },
          { type: 'image_url', image_url: { url: `data:image/png;base64,${imageBase64}` } }
        ]
      }],
      max_tokens: 2048
    })
  });
  const data = await response.json();
  return data.choices[0].message.content;
}

简单直接。但真正的难点在第 5 步——回填。

模型返回的是文本，怎么把它「贴」回图片上，还要看起来自然？这涉及到字体匹配、文字区域定位、背景重建等一系列图像处理问题。从开发者发布的效果来看，对于结构清晰的图片（技术文档、UI 截图、信息图表），回填效果相当不错；但对于漫画这种复杂排版，开发者自己也说「还没试过效果满意的，都是直译」。

这其实是意料之中的。漫画的气泡文字、拟声词、手写体，对模型的理解和生成能力都是更高维度的挑战。

多模态模型的「意外」应用场景

这个扩展有意思的地方在于，它展示了多模态模型一个被低估的应用方向：不是生成图片，而是「理解并改写」图片。

过去一年，多模态模型的注意力大多集中在图像生成（文生图）和图像理解（看图说话）上。但「看懂图片里的文字 → 翻译 → 回填」这个流程，本质上是一种图像编辑能力，而且是带语义理解的编辑。

这个方向的想象空间不小：

技术文档本地化：把英文技术博客的截图、架构图批量翻译成中文
产品国际化：App 截图、营销素材的多语言版本生成
学术阅读：论文中图表的实时翻译
无障碍辅助：为视觉内容提供多语言文字描述

当然，目前这个扩展还处于非常早期的阶段——以 zip 包形式发布，需要手动加载未打包扩展，没有上架 Chrome Web Store。但它验证了一个方向的可行性。

模型选择：一道性价比的算术题

对于想尝试或者二次开发的开发者来说，模型选择是个实际问题。

不同模型在图片翻译这个场景下的表现差异不小。从开发者的反馈和社区讨论来看，大致可以这样排：

维度	推荐模型	说明
中文翻译质量	Qwen-VL-Max	中文语料优势明显
综合理解能力	GPT-4o / Claude Sonnet	复杂图片的语义理解更准
性价比	Qwen-VL-Plus	便宜够用
图像回填质量	Seedream 5	字节的图像生成能力在这里有优势

一个实际的考量是成本。每翻译一张图片就要调一次多模态 API，图片 token 消耗不低。以 GPT-4o 为例，一张中等分辨率的截图大概消耗 1000-2000 token 的图像输入，加上文本输出，单次调用成本在 0.01-0.03 美元之间。如果你浏览的页面图片很多，成本会快速累积。

所以实际使用中，更合理的策略可能是：默认不翻译，用户点击或悬停时才触发翻译。这也是这个扩展目前的做法。

Chrome 原生翻译 API 的对比

值得一提的是，Chrome 自身也在推进浏览器内置的翻译能力。Google 已经在 Chrome 中内置了 Translator API，基于专门训练的翻译模型，支持多种语言互译，模型在首次使用时下载到本地。

但 Chrome 原生的 Translator API 目前只处理文本，不涉及图片内容。而且它走的是传统的翻译模型路线，不具备多模态理解能力。两者解决的是不同层面的问题，反而形成了互补：Chrome 原生 API 处理页面文本，多模态模型扩展处理图片文字。

另外，Google 也在 Chrome Canary 上实验 Gemini Nano 的本地运行，未来如果浏览器能本地跑多模态模型，图片翻译的延迟和成本问题都能大幅改善。但那是更远的事了。

对开发者的启示

这个项目虽小，但有几点值得关注：

第一，多模态 API 的应用场景远比我们想象的多。大家都在卷 Agent、卷 RAG，但一个简单的「图片翻译」需求，用多模态模型来解决，体验提升是肉眼可见的。有时候最好的产品创意不在前沿论文里，在你每天被卡住的那个瞬间。

第二，API 兼容性和聚合的价值在这类场景下特别突出。开发者需要测试多个模型才能找到最适合的，如果每个模型都要单独注册、单独接入，开发效率会大打折扣。OpenAI Hub 这类兼容 OpenAI 格式的聚合平台，让开发者只需要改一个 model 参数就能切换后端，在快速原型验证阶段尤其有用。

第三，国产模型在垂直场景的竞争力已经很强了。Qwen 的视觉模型在中文图片翻译上的表现不输 GPT-4o，Seedream 在图像回填上有独特优势。但「能力强」和「好接入」之间还有一道鸿沟——开发者提到豆包效果好但无法转 API，这种情况在国产模型生态里并不少见。

写在最后

一个周末 vibe 出来的扩展，解决了一个存在已久的真实痛点。它不完美——漫画翻译还不行，回填排版偶尔会错位，成本也不算低。但它证明了多模态模型在浏览器场景下的实用价值，也给沉浸式翻译这类成熟产品指了一个值得跟进的方向。

如果你经常阅读英文技术内容，被图片里的文字卡住过，不妨试试。代码已开源，解压加载即可。

参考来源

图片翻译助手发布帖 - Linux.do：扩展原始发布帖，含下载链接和使用说明

图片翻译的最后一块拼图，被多模态大模型补上了