最近我有一个很直观的感受：
这一波图像生成模型，很多已经不再只是“能画出像字的东西”，而是真的开始把字写对了。

这件事其实挺值得停下来想一下。

因为如果你回头看前两年的生图效果，会发现一个很稳定的槽点：
画面氛围、构图、光影都已经很强了，但只要图里出现招牌、海报标题、包装文案、UI 文本，基本就会露馅。英文会串字母，中文会缺部件，小字更是一塌糊涂。这个问题当时严重到什么程度？严重到不少关于视觉文本生成的论文，开头第一段就在说：现在的文生图虽然整体 fidelity 很高，但只要把视线移到 text area，破绽就非常明显。 oai_citation:0‡arXiv

但最近不太一样了。

我自己看到的一些新结果，已经不只是“偶尔能写对几个字”，而是明显能感觉到：模型在处理标题、标语、场景里的招牌文字时，稳定性比以前高了一大截。于是我就有点好奇：这事到底是怎么被解决的？
难道真的是模型大了、数据多了，所以顺手把文字问题也学会了？还是说，研究界其实已经悄悄换了一套解题思路？

我去翻了一圈近两三年的论文之后，得到的结论还挺明确的：

文字问题不是靠 prompt engineering 慢慢磨出来的，也不是模型“顺便学会”的。它本质上是被单独拿出来，当成一个专门问题重新建模了。 oai_citation:1‡arXiv

这篇文章就想顺着这个好奇心，聊清楚三件事：

1. 为什么图像生成一碰到文字就特别容易翻车；
2. 最近这些方法到底是怎么解决的；
3. 为什么我越来越觉得，这条路线最后会走向一种 glyph-first 的系统，而不是继续指望 prompt 自己长出排版能力。

先说最核心的一点：文字不是普通图像内容

我觉得理解这个问题，第一步不是去看 attention，也不是去看 OCR loss，而是先承认一件事：

文字和“云、树、衣服、墙面纹理”不是同一类对象。

普通图像内容大多是连续的。
云稍微糊一点，还是云；木纹稍微歪一点，也还是木纹。
但文字不是这样。文字是低容错的离散符号系统，一个字少一笔、错一个结构，可能立刻就不可读了。

这也是为什么早期很多模型会给人一种很微妙的感觉：
远看挺像，近看不对。
你会觉得“这里好像应该有字”，但认真一看，其实只是某种很像文字的纹理，不是可读的文字。

GlyphControl 在 2023 年就把这个问题讲得很直白：视觉文本生成不是普通 T2I 任务的自然延伸，必须引入额外的 glyph 条件信息，才能稳定生成准确文本。AnyText 也有类似判断：即便图像整体质量已经很高，一旦聚焦到文本区域，问题就会立刻暴露出来。 oai_citation:2‡arXiv

为什么以前的模型总是“像有字”，但又写不对？

如果只从模型结构上看，这个问题其实挺自然的。

传统文生图做条件注入，基本是这条路：

• 图像 latent / patch token 当 Query
• 文本 token 当 Key / Value
• 让图像在生成过程中不断去“读”文本条件

这个机制对普通语义对齐非常有效。
比如 prompt 里有 red car on snow，模型很容易学会：

• 哪些区域该看 car
• 哪些区域该看 snow
• 哪些局部更多受到 red 的影响

但问题在于，文本 token 提供的是语义，不是字形。

token “A” 并不是字母 A 的视觉结构，
token “春” 也不是“春”字的具体笔画排列。
所以如果系统只吃语义 token，它更容易学会的是：

这里应该有一段“文字感”

而不是：

这里必须是这个字符，而且要笔画对、边界清楚、相邻字符别打架

这也是为什么过去两三年的论文，几乎都在朝一个方向收敛：

别再只靠 semantic conditioning 了，要把文字从“语言提示”升级成“显式字形条件”。
GlyphControl 是这样，AnyText 是这样，FLUX-Text 是这样，TextPixs 也是这样。 oai_citation:3‡arXiv

研究界是怎么一步步把这个问题拆开的？

如果把近几年的工作串起来看，我觉得它不是“某篇论文突然发明了一个神奇模块”，而是经历了一个挺清楚的演化过程。

第一阶段：先承认“文字生成”是一个独立问题

这一阶段最重要的，不是技术细节，而是问题被重新命名了。

GlyphControl 很关键的一点，是明确提出 visual text generation 需要 glyph-conditional control，而不是继续指望 character-aware text encoder 或更大的通用模型自己学会。论文还专门构建了 LAION-Glyph 数据集，并用 OCR-based metrics、CLIP score、FID 来评估结果。这个动作很重要，因为它等于在说：文字渲染已经值得有自己的一套 benchmark 和指标。 oai_citation:4‡arXiv

AnyText 则把这件事进一步系统化了。它不只是做文字生成，还把多语言文字生成和编辑放进同一个扩散框架里，并引入 AnyWord-3M 数据集和 AnyText-benchmark。论文里说得很清楚：文字区域的问题不能再被当成普通图像 fidelity 的附属现象，它需要独立建模。 oai_citation:5‡arXiv

换句话说，第一阶段真正发生的事是：

大家不再问“为什么模型还不会写字”，
而开始问“如果把写字当成一个专门任务，我们应该怎么表示它、训练它、评估它？”

第二阶段：从 semantic-first 走向 glyph-first

这是我觉得最关键的转折。

以前的做法，本质上是 semantic-first：
先给模型一个字符串的语义表示，然后希望它在图像空间里自己把字符外形“悟出来”。

但后来大家慢慢发现，这条路上限不高。
因为语义和字形根本不是一回事。你知道一个词的 meaning，不等于你就知道它在图上该怎么写。

所以 GlyphControl 的解法很直接：
不要只告诉模型“这里写 SALE”，还要把 SALE 的 glyph instruction 明确给它。这样用户不仅能控制文本内容，还能控制位置和大小。 oai_citation:6‡arXiv

AnyText 继续沿着这个方向往前走，它的设计里有两个特别重要的模块：

• Auxiliary latent module：吃 glyph、position、masked image，生成跟文字相关的 latent feature；
• Text embedding module：借助 OCR 模型去编码 stroke 信息，再把这些 embedding 和 caption embedding 融合起来。

这其实已经很能说明问题了：
真正有效的文字生成，不是再多喂一点 prompt，而是把字形、位置、区域这些原本没被好好表示的东西，变成模型能直接消费的条件。 oai_citation:7‡arXiv

我自己看到这里的时候，感受挺强的：
这已经不是“优化 prompt 理解”了，而是在重新定义输入空间。

第三阶段：问题不只是“有没有 glyph”，而是“glyph 怎么进系统”

glyph conditioning 成为共识之后，研究重点就开始下沉。

大家不再争论“该不该给 glyph”，而是开始研究：

• glyph 是当额外输入就够了吗？
• 还是应该更深地改 backbone？
• 训练目标是不是也得跟着变？

FLUX-Text 是我觉得很典型的一篇。
它不是那种特别花哨的“新世界观”，但它很实在。它的思路是：在 FLUX-Fill 这种强 base model 上，用比较轻量的 glyph 和 text embedding 模块增强文字理解与生成，同时尽量保留原有生成能力。更重要的是，它显式提出了 Regional Text Perceptual Loss，就是告诉你：文字区域必须被单独优化。 oai_citation:8‡arXiv

这一点其实特别重要。

因为文字区域通常很小，如果训练目标还是全图统一的，那么大部分梯度都来自背景。模型当然会更优先学“把图做漂亮”，而不是“把字写对”。FLUX-Text 的意思某种程度上就是：
你不能一边说文字很重要，一边在损失函数里继续拿它当背景噪声的一小块。 oai_citation:9‡arXiv

第四阶段：从“词级条件”继续下钻到“字符级绑定”

再往后，问题就会变得更细。

即使你给了 glyph，也不代表字符之间不会互相干扰。
很多时候模型出的问题不再是“完全不知道写什么”，而是：

• 相邻字符粘连
• 一个字符的结构跑到另一个字符那边去
• 整串文本看起来有大概的样子，但局部字符不稳定

这时候 TextPixs 这种工作就很有意思了。

它做了几件非常针对性的事：

• 双流编码：语义文本流 + glyph 视觉流
• character-aware attention
• OCR-in-the-loop feedback
• attention segregation loss

这套东西的核心直觉很简单：
文字不是词级别对齐就够了，而是要字符级别地对齐。

普通 T2I 里，token 级控制通常已经足够。
但文字渲染不一样，字符是最终可读性的最小单位。如果字符之间的 attention 没有被稳定地分开，系统就很容易得到“这是一串字”的整体感觉，却写不对具体每个字。TextPixs 也直接把目标写得很清楚：解决 readable、meaningful、correctly spelled text 的问题。 oai_citation:10‡arXiv

第五阶段：也许模型不该负责“从头学拼写”，而该负责“把文字融合进场景”

翻到比较新的工作时，我最感兴趣的一条思路，其实不是单纯“准确率又涨了多少”，而是问题定义开始变了。

比如 TextFlux 的意思就很明显：
它强调的是 OCR-free DiT model for high-fidelity multilingual scene text synthesis，同时把重点放在 glyph accuracy 和 scene integration 上。 oai_citation:11‡arXiv

这背后有个挺大的范式变化：

• 旧问题：怎么让模型自己从语义里学会 spelling
• 新问题：怎么把可靠的字符表示自然地融进图像场景

我越来越觉得，后者可能才是更长期的方向。

因为如果你让一个通用图像模型同时承担两件事：

1. 生成复杂视觉世界
2. 还得像排版引擎一样精确输出字符

那它天然就有点拧巴。
但如果你把 spelling 这件事尽量结构化、显式化，让模型把重心放在融合——也就是风格、材质、光照、透视、边缘过渡——这条路反而更合理。

这也是为什么我现在会更愿意把这条研究线理解成：

不是“模型终于学会写字了”，
而是“系统终于不再把文字当普通纹理处理了”。

把这些方案压成一句话，其实就是三步

如果不展开细节，把这几年的路线浓缩一下，我觉得就是下面三步：

第一步：把文字从语义提示升级成字形条件

也就是从 prompt-only 走向 glyph-first。
这是 GlyphControl 和 AnyText 这类方法最早讲清楚的事。 oai_citation:12‡arXiv

第二步：把文字区域从整图里单独拎出来优化

也就是别让全图损失继续淹没文字区域。
FLUX-Text 这种 regional text loss 的思路很典型。 oai_citation:13‡arXiv

第三步：把控制粒度从词级推进到字符级，再进一步推进到场景融合级

TextPixs 代表字符级绑定这一步，后续一些工作则更强调 scene integration。 oai_citation:14‡arXiv

我自己的感受：这可能是图像生成从“会画图”走向“能用”的一个拐点

我这次翻论文，最大的感受不是“原来某个模块这么 clever”，而是：

文字问题其实特别像一个分水岭。

过去很多视觉生成模型，主要解决的是“生成一张看起来不错的图”。
但只要场景变成海报、包装、UI、招牌、广告、知识卡片，评价标准就会立刻变化：

• 画面再美，字错了就没法用；
• 氛围再好，标题糊了就不能进生产流程；
• 文字编辑不稳定，就很难真正接入设计工作流。

所以文字渲染这件事，表面上看像个细节，实际上逼着整个系统往更工程化、更结构化的方向走。
它迫使模型回答一个过去可以回避的问题：

你到底是在生成“好看的视觉纹理”，
还是在生成“可被人类读懂和使用的信息”？

而最近这些论文给出的共同答案大概是：

如果你想生成的是后者，那就别再把文字当普通图像内容。

参考论文

[1] Yukang Yang et al., GlyphControl: Glyph Conditional Control for Visual Text Generation, NeurIPS 2023. 提出 glyph-conditional control，并构建 LAION-Glyph 与 OCR-based 评测。 oai_citation:15‡arXiv

[2] Yuxiang Tuo et al., AnyText: Multilingual Visual Text Generation and Editing, 2023/2024. 提出 auxiliary latent module、text embedding module，以及 AnyWord-3M / AnyText-benchmark。 oai_citation:16‡arXiv

[3] Rui Lan et al., FLUX-Text: A Simple and Advanced Diffusion Transformer Baseline for Scene Text Editing, 2025. 强调轻量 glyph/text embedding 与 text fidelity，并引入文字区域感知的优化思路。 oai_citation:17‡arXiv

[4] TextPixs: Glyph-Conditioned Diffusion with Character-Aware Attention and OCR-in-the-Loop Feedback for Accurate Text Rendering, 2025. 强调 dual-stream、character-aware attention、OCR-in-the-loop，以及字符级准确性。 oai_citation:18‡arXiv