图片里夹着文字这件事放在几年前还不太折腾人大不了照着键盘一个字母一个字母敲。可现在谁手机里没有几十张截图、合同照片、PPT翻拍尤其做外贸、读论文、追外漫、玩外服游戏的时候满屏蝌蚪文真是让人头大。你去搜“图片翻译”弹出来的全是“十大方法”“七种神器”“五个在线工具”这种文章看着资源满满实际上一滑到底看完还是不知道先干哪一步。我做了好几年的跨语言内容处理接手的“图内文字翻译”项目没有一百也有八十个我的个人感受非常明确方法多是好事但前提是你心里得有底。所以我特别认同这个标题——先把六步跑完十条方法只是分叉。你不需要一开始就掌握十种工具你只需要先跑通一条完整流程拿到图、认出字、翻成话、放回去、查一遍。这条主路走顺了再去看那些所谓的方法分叉你自然知道每条岔路是通向哪里的也自然能判断什么时候该拐弯。这篇文章我就把这套东西从头到尾拆开讲先给你主流程再给你分叉地图。1. 核心思路拆解为什么“先跑通主路”比“集齐十种方法”重要1.1 方法越多新手越容易在半路迷路我见过太多人被教程带偏的案例。某次我让一个刚入行的朋友处理一批日文产品说明书图片他兴冲冲搜了一晚上工具收藏了十来个网站第二天见面跟我抱怨“不知道从哪个开始用”。原因很简单这些方法之间不是并列关系而是存在明显的前后依赖。举个生活化的例子。你要从北京去广州方式有飞机、高铁、自驾、长途大巴。每一个都能到但如果你连“先买票、再过安检、再找登机口”这个基本顺序都没搞明白给你列出四家航司的机票比价表有什么用图片翻译也是同一个道理——不管你后续用在线OCR、离线识别、浏览器插件、还是手机自带相机翻译你都必须先完成“提取文字”这步前置工作后面才有东西可翻。所谓“十条方法只是分叉”本质上是说所有方法共享同一条主干道这个主干道就是我在标题里强调的“六步”。六步跑完了你对整条链路有了体感再看那些方法时你会自动给它们贴上“这一步的加速器”或“那一步的替代品”这样的标签而不至于被花哨的名头绕晕。1.2 图片翻译这件事的完整链路到底是什么把图片翻译拆到最底实际上是一条信息流转管线图像输入 — 文字定位 — 字符识别 — 文本清洗 — 语言转换 — 结果回填 — 质量校验。市面上任何一个工具、任何一种技巧做的事情都逃不出这个链路它们之间的差别只是某些步骤被合并了、被跳过了、或者被处理得更漂亮了。但链路完整不代表着每一步都必须亲力亲为。以最常见的“手机拍菜单翻译”为例你举起手机对着菜单一拍系统自动完成了文字定位和字符识别然后给你叠一层译文在画面上最后你肉眼检查一下价格有没有离谱——这里其实已经走完了全部六个环节只是你的手只介入了“拍”和“看”而已。理解这条链路有一个实打实的好处你知道中间任何一步坏了该怎么抢救。识别坏了就换识别方式翻译坏了就换翻译引擎回填坏了就手动排版。不会说“这工具咋全废了”而是能准确定位“哦是第二步出了岔子”这个能力在你需要处理大量图片的时候尤其值钱。1.3 分叉到底是怎么来的场景驱动的方法分化为什么市场上会冒出这么多方法因为它们各自针对不同的输入场景做了优化。我把常见场景粗分成三类你在跑主流程之前先想清楚自己属于哪一类。第一类是“单张快翻”典型如手机拍路牌、菜单、聊天截图特点是文字量小、即时性强、对排版要求不高你追求的是“马上知道大概意思”。第二类是“批量文档”典型如几十页PDF扫描件、合同照片、论文文献特点是量大、可能有复杂版式、需要连续处理并保持术语统一。第三类是“版式保留”典型如做双语PPT、翻译海报、给漫画嵌字特点是文字与图像强耦合你不仅要翻对话还得把译文装回原来的气泡里。同一张图不同场景下的最优做法截然不同。所以网络上总结出来的“十条方法”其实是分属不同场景的答案你硬把适用于第三类场景的“PS换字大法”套在第一类“我就想知道这牌子上写的啥”上纯属杀鸡用牛刀。但只要你先把六步跑通了这些分叉对你来说就变成了各种“随时可切换的配置方案”而不是一团乱麻。2. 六步主干道详解每条线该做什么、为什么这么做2.1 第一步图像预处理——决定后续所有工作的天花板很多人觉得这步可以跳过图像拍下来是什么样就直接丢给工具这是大忌。图片翻译这个过程中识别引擎的人与照片之间的关系就像一个听力一般的人听一段带浓重口音的录音——信息丢失不是发生在你听不懂的那一瞬间而是从录音音质变差的那一刻就已经注定了。预处理的核心动作有三个校正角度、增强对比、裁掉干扰。你拿手机对着文档拍的时候只要不是完全平视拍出来的文字必然带透视畸变有些识别引擎对倾斜文字的鲁棒性很差于是漏识别、错识别全来了。校正角度可以用图片查看器的旋转功能或者专业一点的工具有透视矫正手指点两下就能把倾斜的页面拉正。增强对比是为了让笔画更锐利尤其针对那种白底灰字的扫描件提拉一下对比度之后识别率能提升几个档次。裁掉干扰就更好理解了图片边缘的手指、桌面纹理、水印、页码阴影全部裁干净再进识别。我个人的习惯是不管原图看起来多清晰都至少做一次“角度检查”。有个很典型的案例某次处理一张拍糊了的英语菜单原样丢进OCR识别结果里把“Grilled Chicken”认成了“Grlled Chlcken”后来我把图片旋转了2度再稍微拉高锐化同一个引擎一句错都没出。图像质量对识别的影响就是这么直接。2.2 第二步文字识别OCR——从像素里“抠”出文本预处理做完下一步就是OCR全称是光学字符识别干的事情是让机器看图识字把图片里的字形转换成可编辑的字符文本。这一步是整个过程中的技术核心也是翻车高发区。OCR工具有付费有免费有能力强的有能力差的但我的建议是在你没有特殊需求的时候先别急着搞那些重型商业方案直接用主流的免费开源引擎就能处理日常八成需求。开源OCR引擎的优点是本地离线运行、不传图保隐私、支持多语言、定制空间大缺点是命令行操作对小白不太友好但好在有很多封装好的图形界面程序可以套在它外面。选识别引擎前先确认两件事它支不支持你的源语言以及它支不支持竖排文字。前者不用多说后者是很多人踩的坑。处理日文、中文古籍、或者某些老式招牌图时文字是竖排的如果你用的引擎不支持竖排识别结果就是整段文本顺序错乱——它会把右边第一列的每个字认完再跳去右边第二列最后给你一段上下颠倒、左右错乱的字符集合。别问我怎么知道的都是泪。另一个实用技巧是分层识别。如果图片里既有大标题又有正文小字识别引擎的置信度是不同的大号字通常更容易认准。有条件的话先把图片放大到合适尺寸再喂给OCR尺寸太小是识别错误的常见来源。经验阈值是正文文字在屏幕上至少占到30像素高。低于这个值再好的引擎也容易翻车。2.3 第三步文本清洗——把机器识别的“毛坯房”装成“可住人”OCR的输出绝对不能直接拿去翻译你和识别结果之间必须有一道“人工拧干”的工序。为什么因为机器识别出来的文本跟人眼读出来的文本有很大差距不清理直接翻译等于让翻译引擎去翻一堆SOS。清洗主要对付三类问题。第一类是错别字——OCR经常把“0”和“O”、“1”和“l”、“rn”和“m”搞混这在中英文混排的情况下尤其严重你肉眼一看就知道原文是“lOGIN”但机器可能输出“1OG1N”这种错误直接进翻译引擎出来的东西自然莫名其妙。第二类是多余符号——识别引擎偶尔会在行首行尾多带出一些噪声符号比如方括号残留、页码数字、页眉页脚信息这些不该出现在译文里的东西必须先删掉。第三类是排版崩塌——原本两栏的文档被识别成一股脑的长文本句子的顺序全乱这种时候就需要手动分段和排序。清洗工序还有一个高级玩法模糊匹配纠错。如果你识别的是固定格式的文本比如发票、报关单、产品规格表你可以写一个简单的文本比对脚本把OCR结果和标准字段库做模糊匹配自动把疑似错字标出来。对付批量处理场景这招省下的时间是以小时计的。2.4 第四步文本翻译——最省心也最有讲究的一步清洗完之后你手里是一份干净的待翻译文本这时候才轮到“翻译”登场。翻译这一步现在基本靠机器翻译引擎解决但我得把丑话说在前面机器翻译的质量取决于你要翻的是什么内容以及你翻完之后的用途。如果是日常理解用——我只要知道这个路牌说的什么意思、这个商品说明大概讲了啥——那么通用的免费翻译引擎完全够用甚至手机自带的翻译App都行。如果是对外发布用——比如要把菜单翻译成英文拿给外国客人看、把产品介绍翻译成目标语言挂到官网上——那你必须在机器翻译的结果上再做一轮人工润色或者在流程里加入术语表、历史翻译记忆等约束。这里要特意提一句“专有名词”这类的坑。机器翻译最怕的是品牌名、人名、地名、专业术语因为它不知道哪些词该保留原文、哪些词该意译。比如某个产品的型号“A-100X”机翻可能会自作聪明给你译成“一个-100X”这种鬼东西。对策很简单翻译之前先守着专有名词列表把需要保留原文的词替换成占位符比如“A-100X”统一替换成“MODEL”翻译完成后再换回来——机器见到一个无意义占位符反而会老老实实原样搬运。还有一个容易被忽略的点语言方向要设对。这听上去是句废话但自动检测语言方向的引擎经常在短文本上出错。一张图里就四个法语单词引擎可能给你“检测”成英语然后原样输出或者翻成完全不对路的语言。手动指定“源语言→目标语言”这个动作能排除掉这一类低级错误。2.5 第五步结果回填——把译文放回图片原来的位置前面四步都在处理文字第五步开始重新处理图像。结果回填的意思是你翻译出来的文本要把它们放回到原图对应的位置上去形成一张“看起来像原图、但文字已换语言”的新图片。为什么不能直接把译文贴在图片底下当字幕因为很多场景下你需要的不是“注释”而是“替代”——双语菜单上你希望译文出现在每道菜的原名旁边翻译漫画时你希望中文对话出现在对话气泡的内部而非下方一排小字处理表格截图时你希望译文严格填进对应的单元格。这些需求都要求译文与原始版面保持空间同步。人工回填的土办法是把原图丢进任意的图像编辑软件然后用文本框工具逐个覆盖原文字区域。这个方法胜在精确可控缺点嘛——极其费手如果图片里有三十行文字你就要摆三十遍位置、调三十遍字体。所以更常见的操作是借助带“OCR翻译回填”一体化的工具它们先自动识别出每个文字框的坐标翻译完再自动把译文填入对应的坐标框。这也是为什么很多在线图片翻译工具看着“一键出图”其实背后的原理就是六步的工程化封装只是把它们包成了黑盒。如果目标场景不强制要求“译入图中”我建议用最简单的叠加方案原图垫底译文放在图片下方的段落区或者侧边注释区用序号一一对应。这招处理学术论文插图、数据图表时效率高得惊人因为图表里的文本往往又短又多塞回原位置反而看不清。2.6 第六步质量校验——没有这步前面全是白干最后一步最容易被跳过但也最能体现一个处理者的专业水准。质量校验不是“看一眼有没有翻译”这么简单而是从三个维度对产出做检查。第一维是“漏翻检测”。机器翻译有一条铁律翻不出来的东西它不会告诉你“我翻不了”而是直接留空、复制原文、或者打一个无意义的句号。你需要对着原图逐段核对确认每一段原文都产生了对应译文。漏翻的重灾区是小号字体、水印文字、以及嵌在图形内部的文字——OCR经常把它们识别成噪声丢弃你自然也就无译可翻。第二维是“术语统一”。批量化处理图片的时候同一张图里可能多次出现同一个专业词如果每次翻译时机器给出了不同译文就会让成品显得很不专业。检查方法是做一次反向查找在译文里搜索某个核心词确认全文始终使用同一个对应的译词不一致就手动统一。第三维是“版面核验”。文字回填之后可能发生溢出——译文比原文长文本框装不下结果文字压扁、超出边界或者被截断。英文翻中文通常没问题中文译词更短但中文翻英文或者德文、俄文翻中文词长变化剧烈版面溢出几乎是必然事件。你需要把成品和原图对照着看一遍逐块确认没有文字压线、错位、超出边界。这六步跑完之后你手上拿到的就已经是一份能交付的成品了。你会发现这里面的每一步你都有参与感你清楚每一处译文来自哪个引擎、哪一步做过人工修正、版面是怎么调整的。这种掌控感是用“在线一键翻译”直接导出完全给不了的。3. 实操对照两条最常见的场景路线把六步各跑一遍3.1 路线A手机”即拍即译”一条轻量版的六步流水线日常频率最高的是这种场景饭桌上拿手机拍一张外文菜单随即想知道每一道菜是什么。这种需求的优先级是“快”排第一“版式完美”排最后所以六步可以被折叠成一套轻量操作。第一步图像预处理对应的是“拿稳手机、把菜单拍平”——物理上找好角度让镜头尽可能正对文字面比事后任何软件校正都管用。第二步OCR在手机上一体化翻译App内部就已经完成了。第三步文本清洗这部分被砍掉了你不需要关心机器的中间输出只要关心译文结果。第四步翻译内置引擎自动完成。第五步回填系统给你的是一张带着译文浮层的预览图译文直接叠在原文字上。第六步校验对应你快速滑看一遍预览图重点看价格数字、菜品主料这些不能翻错的关键信息。这条路线里你真正介入的只有“拍得正不正”和“看得细不细”两个动作其余环节都是黑盒。但跑了这条轻量流程你的收获是建立了对整套系统的直觉知道在光线不足时应该开闪光灯补光预处理知道菜名识别错时应该切到“手动选择区域翻译”OCR修正知道译文语序怪时大概是因为源语言被自动检测错了翻译引擎参数。这份直觉正是后续使用重流程的基础。3.2 路线BPC端批量文档处理全流程手动控制再来看另一条极端路线手头有三十张产品说明书翻拍照需要翻译成另一种语言并整理成双语对照文档。这种场景不允许“大概看看”每一步都要受控。第一步预处理我通常用图片处理软件写一个批量动作自动旋转矫正、自动裁剪白边、统一输出成1200像素宽的白底图片。第二步OCR我用开源引擎做本地批量识别输出为带坐标信息的文档格式——这个格式很关键它同时记录了每个文字框的内容和它在图中的坐标位置为后面的回填做准备。第三步清洗写正则表达式批量去掉页眉页码跑一遍错字检查脚本标记出疑似识别错误的词。第四步翻译用支持术语表的专业翻译工具导入预先整理好的产品术语清单确保“阀体”“密封圈”“扭力”这些词每一次翻译都保持一致。第五步回填利用带坐标信息的数据以半自动方式生成双语对照PDF——原文在上、译文在下逐条对齐。第六步校准随机抽三张图做全字段核对再整体抽查一遍术语统一性。这条路线的成本高不少但产出的质量完全不在一个层级。更关键的是当你走完这条完整路线之后你才算真正拥有了“流程思维”——你再也不会问“这个在线工具怎么不能翻译我的PDF”这种问题了而是会条件反射地拆解你的输入文件自己规划从图到文、从文到译的每一站。3.3 两条路线的岔路口如何判断该走哪条到底什么时候走A路线、什么时候走B路线、什么时候可以走中间路线我给一个简单的判断依据按“单图文字量”和“交付要求”两个维度打分。文字量在五十词以内只求看懂不求外发走A路线。文字量在五十到两百词之间比如一份两页的合同扫描件、几张实验数据图建议走中间路线——OCR照跑但清洗和校验可以放宽翻译直接用通用引擎回填省掉、改用对照排版。文字量超过两百词或者成片出现、术语重复、交付要求高必须走B路线。我的经验是大多数人栽跟头并不是因为选了错误的路线而是高估了自己的需求。明明就想知道个大概非要去研究专业软件结果被复杂的参数劝退最后连大概都没知道。反过来明明是要交付给客户用的正式文件为了省事一键生成结果被对方指出术语错误返工成本远高于老老实实多花两小时做人工校验。先认清自己的位置比到处找“更好的工具”重要得多。4. 十条方法的分叉地图六步跑通后你在每个岔口该怎么选4.1 按功能拆解的分叉每一步都有“专用快车道”六步跑通之后你已经有了一套“默认配置”。接下来的十条方法分叉其实是从各个步骤延伸出去的备选路径。我按步骤归属帮你把主流方法分了个类每条都标明了适用条件。在OCR这一步你会在“通用识别法”“专业识别法”和“场景识别法”之间做选择。通用识别法就是前面路线B用的开源引擎日常够用、免费、可定制。专业识别法指那些面向文档扫描优化的商业OCR它的优势在于对复杂版面——多栏、表格、页眉页脚的交错——有更好的结构化输出能力适合处理设计精美的杂志页面或扫描书籍。场景识别法就是手机相机里的“实时取景翻译”模式优势是所见即所得弱点是对精细版面无能为力。在翻译这一步你又会在“通用机翻”“术语约束机翻”和“人工翻译”之间做选择。通用机翻适合即时理解术语约束机翻适合垂直领域文档——通过术语表强制指定某些词的译法人工翻译适合少量、高价值、需要文字风格考究的内容比如广告文案、品牌故事这类文本机翻会丢掉神韵只有人才能翻出味道。在回填这一步你有“坐标映射回填”“图层叠加回填”和“手动排版回填”三条路。坐标映射回填是最高效的方式但前提是你的OCR工具输出了带坐标的文本。图层叠加回填适合快速出预览版、临时沟通用。手动排版回填适合那种文字量极少但版面特别讲究的图——比如海报、封面——不放心机器的自动排版宁可自己动手放每个字。4.2 按场景选型的决策表什么时候切到哪条分叉为了让你更好做判断我把常见场景和推荐组合做成了一张表。注意这不是让你十条方法同时上而是帮你快速锁定“当前这个任务应该开启哪些分叉”。场景推荐OCR路径推荐翻译路径推荐回填方式校验重点手机拍菜单、路牌、即时理解场景识别法通用机翻预览图层叠加价格数字、菜名主料论文截图、PDF页面翻译通用识别法通用机翻或术语约束坐标映射或对照排版公式、术语、引文产品说明书批量翻译通用识别法或专业识别法术语约束机翻坐标映射回填术语一致性、规格参数漫画、海报嵌字翻译场景识别法手动修正人工翻译为主手动排版回填语气风格、气泡边界合同、证件扫描翻译专业识别法术语约束人工润色对照排版输出姓名、日期、金额、条款这张表其实揭示了一个规律方法之间不是优劣关系而是适切关系。合同扫描件用实时取景翻译当然没人拦你但你得到的会是满屏错位的识别文本还不如老老实实扫描进电脑让专业识别法逐行吃透版面。漫画嵌字用批量翻译引擎也能出字但翻出来的语气干巴巴嵌进气泡后十有八九超框倒不如花时间逐个人工润色。4.3 一个容易忽略的分叉维隐私与数据合规还有一个分叉不在“方法”里但越来越值得考虑——你的图片文字内容能不能传到在线平台很多人处理合同、身份证、内部文件时从没想过这个问题直接往在线翻译工具里一贴事后才意识到敏感信息已经出了自己可控的范围。针对这种情况分叉的选择就多了一个维度本地离线处理 vs 云端在线处理。开源OCR引擎是本地跑的你甚至可以完全断网使用翻译这块也有本地部署的支持离线翻译的开源模型虽然体量比在线大模型轻但翻一些日常文本完全够用。我的建议是只要图片里涉个人身份、商业机密、内部信息整个六步流程全部走本地方案宁可多花点时间也不要把敏感数据交出去。这是一个值得养成的习惯跟技术能力无关。5. 六步实战中的常见翻车时刻与排查方法5.1 OCR识别率突然暴跌先别急着换引擎遇到过太多次这种情况同一批图片前面几张识别得好好的突然有一张输出结果满屏乱码。新手的第一反应是“这个OCR不行得换一个”但根据我的经验异常往往出在输入而不是引擎上。先检查图片本身。有时候只是一张图的光线不均半张亮半张暗识别引擎对阴影特别敏感。把那张图单独拉出来做局部提亮、增强对比再喂一次。其次检查文字方向——某些图片是竖构图但OCR引擎默认横排输出顺序就会错乱。把图片旋转成横排再识别问题当场消失。最后检查分辨率——如果你用微信传图被压缩过长边的像素可能只够预览用放大到原始尺寸再识别准确率往往立刻回升。记住一个顺序怀疑引擎之前先怀疑图像。八成以上的识别问题都出在图像质量这个源头换引擎只是把低质量问题换成了另一个低质量结果。那种“换个引擎立刻变好”的体验通常只是因为两个引擎对图像预处理的默认参数不同本质上还是在图像环节兜圈子。5.2 翻译结果读不通问题可能根本不在翻译引擎另一种高频困惑是OCR输出的文字看着没问题但翻译出来就是不像人话。这种时候很多人会去换翻译引擎但真相往往是——你喂给翻译引擎的源文本本身就是坏的。最常见的是语言混排导致的语序错乱。比如一张图片里同时有英文和中文OCR按行输出后翻译引擎接收到的是一段跳跃于两种语言之间的文本流它的模型会被搞糊涂。对策是在清洗环节做“语言分流”把中文行和英文行拆开分别翻译后再按原顺序拼合。还有一种情况是OCR把同一句话的行顺序颠倒了。英文跨行断句很常见比如“This is a / very long sentence”被OCR识别成两行后有些引擎会按行拆成两个独立片段翻译出来就是“这是一个/非常长的句子”这种读着通但结构松散的结果。遇到这种情况人工合并断行是最快的解法识别引擎的自动段落重组功能在这些场景里帮不上什么忙。5.3 回填后图文错位、文字溢出该做哪些补救回填环节的翻车最直观——翻译后的图片一眼看上去就不对劲。常见的两种翻车位置错位和文字溢出。位置错位通常源自OCR坐标输出混乱。某些引擎在识别多栏版面时坐标是按“识别到的顺序”而不是“视觉的位置顺序”排的结果导致右栏的译文被填进了左栏的位置。最简单的排查方法是看原图是否分栏遇到分栏图我一般会先把栏目区域裁开分别处理宁可多跑一次OCR也不要赌引擎的版面顺序判断。文字溢出的根源是译文字符数量与原文不匹配。中文翻译成英文时平均长度会膨胀30%-50%文本框还是原来的大小文字自然挤出来。对策要么在回填工具里开启“自动缩小字体以适应文本框”的功能要么在预处理阶段把文字区域预留得大一些。如果工具两种都不支持那就走对照排版路线把译文放到图片外面虽然观感次一点但至少不会出现半个字被截断的惨剧。5.4 备份意识六步流程里最容易省略的关键动作最后提醒一个长期经验攒出来的教训每一步的中间结果都要保留。OCR识别出来的原文文本、清洗后的干净文本、翻译引擎的初稿译文、人工修正后的最终译文这些中间产物最好都单独存一份。不要只保留一张最终成品图。原因有两层。第一层是返工效率问题——客户说“某个术语统一改成另一个说法”如果你手里有最终文本文件全局替换三分钟完事然后重新走回填就行但如果你只有一张成品图意味着得从OCR重新开始整套流程再跑一遍。第二层是过程可追溯——当你在回填阶段发现某个词的翻译不对你可以顺着中间产物往前查确认是OCR错了、清洗错了还是翻译错了。没有中间文件这个追责过程就无从谈起。6. 写完这篇我再掏几个压箱底的经验流程讲完了分叉也理清了最后我想说几句实操中攒下的私房话这些零碎经验在教科书和工具说明里都找不到。第一关于工具链的选择我最终淘汰了那些“一站式全家桶”方案。第一年我图省事试图找一个能同时完成OCR、翻译、回填的工具结果发现这类工具的每一环都是及格水准但没有一项能达到专业水平。后来我学乖了每个环节各用各的专项工具自己用脚本把中间产物串起来。表面上多做了几步实际上每一环的质量都上去了整体效果反而提升了一个档次。你不要被“一个工具搞定所有事”这句话诱惑尤其在图片翻译这个领域专业化分工带来的收益是肉眼可见的。第二关于语言对。如果你只需要处理“英文图片→中文译文”那随便选什么工具都行通用引擎的英中翻译已经打磨了很多年质量足够好。但如果你要处理的是日文、韩文、德文、法文、西班牙文这些二线语言就要小心了——通用引擎在这些语言上的表现落差极大有些语言对的质量甚至只有英中的六成。遇到这些语言更稳妥的做法是找专门针对该语言对优化的翻译工具或者在人工润色环节多投入一倍的时间。这是一条买来的教训。第三关于“持续改进”这件事。我始终觉得图片翻译的终极意义不在于把图片上的文字变成另一种语言而在于跨越语言的障碍把信息真正送到需要它的人面前。做到这一步需要的是对流程有敬畏心——你愿意多花三分钟预处理一张图愿意在翻译前清理掉每一个错别字愿意在校验环节逐条对照原文与译文。这些动作每一个单独看都很微小但整条链路走下来你交付的作品与随便一键生成的成品之间就会拉开明显的距离。这是我的切身体会任何工具都替代不了流程感而流程感恰恰是从“先把六步跑完”这件事开始的。
