最近我有一个很直观的感受：
这一波图像生成模型，很多已经不再只是“能画出像字的东西”，而是真的开始把字写对了。
这件事其实挺值得停下来想一下。
因为如果你回头看前两年的生图效果，会发现一个很稳定的槽点：
画面氛围、构图、光影都已经很强了，但只要图里出现招牌、海报标题、包装文案、UI 文本，基本就会露馅。英文会串字母，中文会缺部件，小字更是一塌糊涂。这个问题当时严重到什么程度？严重到不少关于视觉文本生成的论文，开头第一段就在说：现在的文生图虽然整体 fidelity 很高，但只要把视线移到 text area，破绽就非常明显。 oai_citation:0‡arXiv
但最近不太一样了。
我自己看到的一些新结果，已经不只是“偶尔能写对几个字”，而是明显能感觉到：模型在处理标题、标语、场景里的招牌文字时，稳定性比以前高了一大截。于是我就有点好奇：这事到底是怎么被解决的？
难道真的是模型大了、数据多了，所以顺手把文字问题也学会了？还是说，研究界其实已经悄悄换了一套解题思路？
我去翻了一圈近两三年的论文之后，得到的结论还挺明确的：
文字问题不是靠 prompt engineering 慢慢磨出来的，也不是模型“顺便学会”的。它本质上是被单独拿出来，当成一个专门问题重新建模了。 oai_citation:1‡arXiv
这篇文章就想顺着这个好奇心，聊清楚三件事：
- 为什么图像生成一碰到文字就特别容易翻车；
- 最近这些方法到底是怎么解决的；
- 为什么我越来越觉得，这条路线最后会走向一种 glyph-first 的系统，而不是继续指望 prompt 自己长出排版能力。
先说最核心的一点：文字不是普通图像内容
我觉得理解这个问题，第一步不是去看 attention，也不是去看 OCR loss，而是先承认一件事：
文字和“云、树、衣服、墙面纹理”不是同一类对象。
普通图像内容大多是连续的。
云稍微糊一点，还是云；木纹稍微歪一点，也还是木纹。
但文字不是这样。文字是低容错的离散符号系统，一个字少一笔、错一个结构，可能立刻就不可读了。
这也是为什么早期很多模型会给人一种很微妙的感觉：
远看挺像，近看不对。
你会觉得“这里好像应该有字”，但认真一看，其实只是某种很像文字的纹理，不是可读的文字。
GlyphControl 在 2023 年就把这个问题讲得很直白：视觉文本生成不是普通 T2I 任务的自然延伸，必须引入额外的 glyph 条件信息，才能稳定生成准确文本。AnyText 也有类似判断：即便图像整体质量已经很高，一旦聚焦到文本区域，问题就会立刻暴露出来。 oai_citation:2‡arXiv
CodeBlock Loading...
为什么以前的模型总是“像有字”，但又写不对？
如果只从模型结构上看，这个问题其实挺自然的。
传统文生图做条件注入，基本是这条路：
- 图像 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
flowchart LR
A[仅有语义 token] --> B[告诉模型 这里应该有文字]
B --> C[优点: 和普通 T2I 兼容]
B --> D[缺点: 没告诉模型这个字具体长什么样]
D --> E[结果: 容易生成伪字形/串字/错字]
F[显式 glyph 条件] --> G[告诉模型 这里应该是这个字符形状]
G --> H[附带位置/大小/区域信息]
H --> I[结果: 可读性和可控性明显上升]
研究界是怎么一步步把这个问题拆开的？
如果把近几年的工作串起来看，我觉得它不是“某篇论文突然发明了一个神奇模块”，而是经历了一个挺清楚的演化过程。
第一阶段：先承认“文字生成”是一个独立问题
这一阶段最重要的，不是技术细节，而是问题被重新命名了。
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 理解”了，而是在重新定义输入空间。
flowchart TD
A[从 prompt-only 到 glyph-first] --> B[阶段 1 只给字符串语义]
A --> C[阶段 2 给 glyph + position + region]
A --> D[阶段 3 再把这些条件深入注入 backbone]
B --> B1[容易得到像文字的纹理]
C --> C1[开始能控制字符内容/位置/大小]
D --> D1[开始追求字符级稳定和场景一致性]
第三阶段：问题不只是“有没有 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
flowchart LR
A[词级/短语级条件] --> B[整体知道这里有一串文字]
B --> C[问题: 字符边界不清 相互污染]
D[字符级条件与注意力] --> E[每个字符更独立地绑定区域]
E --> F[结果: 拼写更稳定 可读性更高]
第五阶段：也许模型不该负责“从头学拼写”，而该负责“把文字融合进场景”
翻到比较新的工作时，我最感兴趣的一条思路，其实不是单纯“准确率又涨了多少”，而是问题定义开始变了。
比如 TextFlux 的意思就很明显：
它强调的是 OCR-free DiT model for high-fidelity multilingual scene text synthesis，同时把重点放在 glyph accuracy 和 scene integration 上。 oai_citation:11‡arXiv
这背后有个挺大的范式变化：
- 旧问题：怎么让模型自己从语义里学会 spelling
- 新问题：怎么把可靠的字符表示自然地融进图像场景
我越来越觉得，后者可能才是更长期的方向。
因为如果你让一个通用图像模型同时承担两件事：
- 生成复杂视觉世界
- 还得像排版引擎一样精确输出字符
那它天然就有点拧巴。
但如果你把 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
flowchart TD
A[文字问题的主线解法] --> B[glyph-first]
A --> C[region-first]
A --> D[character-first]
A --> E[integration-first]
B --> B1[不只告诉模型写什么 还告诉它长什么样]
C --> C1[文字区域单独加权优化]
D --> D1[字符级注意力与约束]
E --> E1[重点解决和背景如何自然融合]
我自己的感受：这可能是图像生成从“会画图”走向“能用”的一个拐点
我这次翻论文，最大的感受不是“原来某个模块这么 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