图片翻译不是一句话的事
朋友问：有没有办法把一张图片里的中文直接改成英文，版式尽量不变。我第一反应是用 OpenAI 的 image2，一句提示词就能跑出不错的结果。
原图
openai image2产物
但这个方案只存活了半秒。原因很硬：不能碰海外模型，必须换成千问系列。
上手看结果
在百炼上拉了几个模型测试，包括 qwen-image、wanx2.7，以及专门为图片翻译做的 qwen-mt-image。结果不出意外的话，全是意外…
前两个模型更偏向图像生成和编辑。让它们把中文换成英文，很容易出现：
乱码：生成类似英文但并非任何单词的字符序列
伪英文：看起来像英文但毫无意义
漏翻：部分中文被直接保留
位置错乱：英文跑到原中文区域外，覆盖图标或其他元素
qwen-mt-image 名字最对路，但它是去年发布的上古模型，在换行、排版、文字边界控制上完全无法稳定处理稍微复杂一点的图片。
这时候我发现，这个任务没那么简单。图片翻译不是“把中文变成英文”，它同时包含六件事：
识别图片里的文字
理解文字的位置、层级和阅读顺序
把中文翻译成适合放回原位的英文
擦掉原图中的中文
将英文放回原来的视觉位置
保持背景、边框、图标、颜色和整体版式不受破坏
如果只当成一个图像编辑问题扔给模型，每一步都可能失控。模型没有显式获得 OCR 清单，不知道文字之间的排版约束，也不会主动控制英文长度。它只被要求“把中文改成英文”，就会自由发挥，而自由发挥的结果就是乱码和错位。
这意味着，非要用千问模型来做这件事，就不能再把整张图直接丢给图像编辑模型，而需要一套工程化的设计去拆分任务。
尝试期间还发现，千问官方 App 可以稳定做到这件事，效果相当不错。
这说明在千问模型体系内，这块流程设计完全可行，只是 App 没有对外暴露这套流程。
图片翻译流水线应该长什么样
如果图片翻译必须拆开，那么它应该是一条四段式流水线：
OCR 与结构识别：从图片里找出所有中文，记录位置和层级
翻译计划：将中文转为适合原位放回的英文，整理成结构化指令
图像编辑：调用万相执行视觉替换，只做修改，不做理解
评估与兜底：判断编辑结果是否可用，不可用则切换为重绘策略
每一段只完成一件事，上一段的输出是下一段的输入。理解与决策放在前面，生成模型只负责确定性高的视觉修改。
演示：三栏信息图的完整流转
拿一张典型的三栏信息图做主线案例。原图里有标题、品牌 Logo、三个卡片栏目，以及大量项目符号文本。
对比：一步到位 vs 分段流水线
| 维度 | 传统方案（一句 prompt） | 当前方案（四段流水线） |
|---|---|---|
| 触发条件 | 直接把图丢给图像编辑模型 | 先 OCR，再翻译计划，最后编辑 |
| 操作方式 | 模型自行理解、翻译、排版、修改 | 每步由独立模块处理，编辑模型只做视觉替换 |
| 失败表现 | 乱码、伪英文、漏翻、位置错乱 | 少量重叠或漏翻可重试，复杂场景转重绘 |
| 适用边界 | 极简图片，文字少且排版宽松 | 多栏、密集文本、图标混排的复杂图片 |
分层拆解：Skills 内部的四层
第一层：图像读取与 OCR
这一层只做一件事：把图片里所有中文找出来，形成结构化清单。
触发条件：有图片输入即执行，不管复杂度。
对于三栏信息图，OCR 会输出类似：
标题：产品功能对比
左栏卡片标题：基础版
左栏说明项：7×24小时在线客服 / 10GB 存储 / 基础报表
中栏卡片标题：进阶版
中栏说明项：专家支持 / 100GB 存储 / 高级报表 / API 接口
右栏卡片标题：企业版
右栏说明项：专属架构师 / 1TB 存储 / 自定义报表 / 完整 API 及 SLA
每项附上大致位置或 bbox 坐标。此时还没有任何英文介入。
第二层：翻译计划
把 OCR 清单里的每一项翻译成适合原位放回的英文，归拢成一份 JSON。
触发条件：OCR 返回非空清单。
这部分有一个关键操作：长度控制。中文信息密度高，相同语义下英文往往更长。不控制的话，原卡片宽度很容易撑破。
以三栏图为例：
“基础版” → “Basic”（不用 “Basic Edition”，标题栏宽度不够）
“7×24小时在线客服” → “24/7 support”（逐字译 “7x24 online customer service” 会覆盖多个图标）
“专属架构师” → “Dedicated architect”（可排版，不再缩短）
翻译结果被整理成带位置信息的编辑指令。
中间产物
{
"regions": [
{
"text_cn": "基础版",
"text_en": "Basic",
"bbox": [50, 120, 200, 160]
},
{
"text_cn": "7×24小时在线客服",
"text_en": "24/7 support",
"bbox": [70, 200, 220, 240]
}
]
}
第三层：图像编辑
调用 wan2.7-image-pro，带上严格的提示词和翻译计划，执行视觉替换。
触发条件：翻译计划就绪。
提示词明确写出边界规则：
将清单中的所有中文替换为对应的英文
英文字号、颜色、对齐方式与原文保持一致
保持背景、图标、边框、分割线不变
不生成伪英文
不保留任何中文字符
不修改已有的非中文文字
万相在这一层只负责执行修改，不负责任何理解。
第四层：评估与兜底
每次图像编辑后都会触发一次判断：
中文残留低于 5%，英文无乱码，排版无明显破坏 → 直接交付
少量文字重叠或漏翻 → 补充精确坐标、缩短译文，重跑一次
遇到密集多栏、长段落、大量图标文字混排 → 图像编辑稳定性不够，不再硬改，转确定性重绘
确定性重绘放弃像素级原图还原，转而用代码重新绘制一张英文图。保留原图尺寸、背景、三栏结构、颜色和图标位置，将英文内容按排版规则重新放置。可读性优于像素保真。
这次的三栏信息图，第一次编辑后即触发了重绘策略，最终交付的是一张结构完整、文本清晰、可读的英文版本。
规则与约束
这条流水线运行中执行以下硬规则：
OCR 清单不完整，不允许进入翻译阶段
翻译必须控制长度，超出原始区域宽度的文本必须裁剪或缩写
图像编辑提示词中必须显式写入“不保留中文”和“不生成伪英文”
同一图片的图像编辑最多重试两次，超出即切换为重绘
确定性重绘只保证信息可读性与结构，不追求像素级还原
最终输出
最后
图片翻译看起来一步就能完成，实际上同时要求模型做四件互不相关的事：理解、翻译、排版、视觉替换。把所有不确定性压进一句 prompt，等于把每个环节的风险都押在模型上。
我们做的拆解，本质是用流程补模型能力的缺口——把可以确定的部分提前用规则固定，只把必须由模型完成的那一小步交给模型。如果有一天模型能稳定地一次处理好全部环节，这条流水线就是多余的。
这个思路不只适用于图片翻译。碰到任何一个看起来能靠生成模型一步到位、实际运行却频繁失控的场景，都值得停下来想一想：任务里是不是悄悄混进了几个完全不同的问题。
工程化本身是模型能力不足期间的补丁。如果模型能力足够强大，工程化这个命题可能就纯粹多余了。
