这篇论文有意思的地方在于：它从零训练了两个生成模型（30 亿和 60 亿参数），但真正的主角不是模型，而是喂给模型的数据。它把「通用图像生成」这道题的胜负手，从模型架构挪到了数据的组织方式上。
一个模型全包，卡在哪
现在的图像生成产品几乎都在往「一个模型全包」走：能按一句话画图，能按一句话改图，最好还认得照片里的人是谁、地标是哪座。常见做法是统一架构——把看图的模型和画图的模型接在一起——再把文生图数据、编辑数据、实体知识数据混进一个训练池。
混池子有混池子的问题。编辑数据喂多了，文生图会跟着跑偏；画「人脸」很漂亮，长尾概念——出现频率低的冷门事物，比如某种地方乐器——就画不像；改图指令和文生图描述各说各话，模型学不到它们背后其实是同一种「看图能力」。更麻烦的是反馈缺失：模型哪里弱，靠人工翻失败案例；找到了，也只能把整个数据集原样再喂一遍。
把「数据集」升级成「监督系统」
阿里巴巴团队的这篇论文，给了这个问题一个数据侧的答案，分四步。
第一，按能力拆数据引擎，而不是按任务堆数据。文生图一个引擎：4.4 亿张图，刻意去补长尾概念，甚至保留少量带缺陷的图、在描述里写明缺陷在哪。图像编辑一个引擎：1.2 亿对「改前—改后」样本，来源分三层——用视觉模型拆解场景后反向构造增、删、换；从同一网页的共现图、相邻视频帧里挖自然配对；虚拟试穿这类几乎没有现成数据的稀缺任务，就先微调一个「任务专家」生成模型去造。世界知识一个引擎：从维基数据的实体表里筛出高知名度条目，配出 2700 多万对「图像—实体」。
第二，让所有描述说同一种语言。图上的文字说明不是拿现成的，而是两个专门训练的打标模型现场写的（先监督微调，再用强化学习罚它编造画面里不存在的东西）；编辑指令和文生图描述共用一套词汇结构。这一步最容易被忽视，却是能力之间能互相迁移的关键——模型在文生图里学的「往画面里加一把椅子」，和在编辑里学的「把椅子换成沙发」，被写成了同一种表达。
第三，像排课表一样调度训练：五个阶段，分辨率从 256 像素一路升到 1024 像素，任务配比、概念分布、数据质量、分辨率四个轴同步演化。
第四，也是最值得抄的一招：能力感知的评估闭环。每个中间检查点按能力分卷考试，错题被标注「错在哪个任务、哪类语义、哪个维度」，然后拿错题当检索种子，去数据池里找、或专门构造相邻的新样本；反复错的题型加权多来，已经解决的降权。数据集从一份静态库存，变成了跟着模型短板走的活系统。
它会先落在哪里
对做修图、电商图、相册产品的团队，这几乎是一份数据工程清单：稀缺编辑任务可以用专家模型造数据再人工抽检；实体接地的质量决定相册搜索和品牌图生成的下限；海报上的文字渲染得单独喂。「错题本」机制同样适用于视频和 3D 的生成流水线——上线后持续用失败样本驱动数据补采，等于把「数据飞轮」从口号变成一条可执行的工程路径。反过来说，当数据组织本身成为壁垒，小团队要拼的就不是算力，而是评估闭环的自动化程度。
局限与存疑
结果表里只有自家两个模型互相比，按视觉大模型 1–5 分打，60 亿参数版总评 3.94、30 亿参数版 3.93——规模翻倍几乎不动成绩，这既支持了作者「下一根 scaling 轴在数据」的主张，也暴露了评测的软肋：没有和外部模型在同一把尺子下的对比，「数据设计带来了多少提升」缺一个参照系。而且打分靠视觉大模型、打标也靠视觉大模型，评价器和被评价的数据同源，存在循环论证的风险。数据和代码没有放出，论文也没有局限性章节——这套体系在别人手里能不能复现，目前只能存疑。