图片翻译的一次工程化拆分
这个需求听起来像是一个看一眼就能关掉的 case
朋友问：有没有办法把一张图片里的中文，直接改成英文，版式尽量不变
我第一反应：用 OpenAI 的 image2 不就完了
确实是当时最简单、直接、效果也最稳的方案。模型能理解图片内容，也能处理文字替换和图像编辑，很多时候一句提示词就能跑出不错的结果。实际效果也确实很顶
但这个方案只存活了半秒
原因很硬：不能碰海外模型，需要换成千问系列
抓头发...
上手看看
我去百炼上拉了几个模型试试，包括 qwen-image、wanx2.7，以及专门为图片翻译做的 qwen-mt-image
嗯, 结果不出意外的话，那就全是意外...
前两个模型更偏图像生成和图像编辑。让它们把图片里的中文换成英文，很容易出现几种问题：
- 乱码：生成类似于英文但不是任何单词的字符序列
- 伪英文：看起来像英文但实际无意义
- 漏翻：部分中文被忽略，直接保留
- 位置错乱：英文跑到了原中文区域外，覆盖图标或其他元素
qwen-mt-image 名字听起来最对路，但确实是一个去年发布的上古模型，实际效果不敢恭维。在换行、排版、文字边界控制上，它完全没办法稳定处理稍微复杂一点的图片
这时候我发现，这个任务好像没我想的那么简单
图片翻译不是“把中文变成英文”，它其实同时包含了六件事：
- 识别图片里的文字
- 理解文字的位置、层级和阅读顺序
- 把中文翻译成适合放回原位的英文
- 擦掉原图中的中文
- 将英文放回原来的视觉位置
- 保持背景、边框、图标、颜色和整体版式不受破坏
如果只把它当成一个图像编辑问题扔给模型，每一步都可能失控。模型没有显式获得 OCR 清单，也不知道这些文字之间的排版约束，更不会主动控制英文长度。它只被要求“把中文改成英文”，那它就会自由发挥，而自由发挥的结果就是乱码和错位
这意味着，如果非要用千问模型来做，那就不能再把整张图直接丢给图像编辑模型，而是需要一套工程化的设计去拆分任务实现
尝试期间还发现，千问官方 App 其实可以稳定做到这件事，而且效果还挺不错
这也说明了在千问模型体系内，这块流程设计是完全可行的, 只是APP没有对外暴露这块的流程设计
图片翻译流水线应该长什么样
如果图片翻译必须拆开，那么它应该是一条四段式流水线：
- OCR 与结构识别：从图片里找出所有中文，并记录位置、层级
- 翻译计划：将中文转为适合原位放回的英文，并组织成结构化指令
- 图像编辑：调用万相执行视觉替换，只做修改，不做理解
- 评估与兜底：判断编辑结果是否可用，不可用则切换为重绘策略
每一段只完成一件事，上一段的输出是下一段的输入。理解与决策放在前面，生成模型只负责确定性高的视觉修改
演示：三栏信息图的完整流转
拿一张典型的三栏信息图做主线案例。原图里有标题、品牌 Logo、三个卡片栏目，以及大量项目符号文本
分层拆解：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，等于把每一个环节的不确定性都押在模型上。
我们做的拆解，本质是用流程补模型能力的缺口——把可以确定的部分提前用规则固定，只把必须由模型完成的那一小步交给模型。如果有一天模型能稳定地一次处理好全部环节，这条流水线就是多余的。
这个思路不只适用于图片翻译。碰到任何一个看起来能靠生成模型一步到位、实际运行却频繁失控的场景，都值得停下来想一想：任务里是不是悄悄混进了几个完全不同的问题
当然, 工程化本身就是在模型能力不足期间的补丁，正如我一贯理解的，如果模型能力足够强大，也许工程化这个命题可能就是纯粹多余的了
