一句“开门大吉”怎样变成画面说明？CogView4 把改写材料也公开了

“红色海报，中间写开门大吉”，已经讲清了主题，却还没有说明背景、装饰和文字载体。CogView4 的官方提示增强脚本保留了一组这样的短需求与扩写示例：红金配色、居中匾额、灯笼、中式建筑和底部祥云被逐项补进描述。值得看的是这些细节从哪里来，哪些可以删改，而不只是最后一张图是否漂亮。

先改说明，再交给生成模型

脚本中的中文示例说明了两步流程：语言模型先把短提示扩成具体画面描述，CogView4 再根据这段描述出图。官方要求扩写关注主体、媒介、风格、颜色和光线等可见内容；对于 CogView4，中文输入保持中文，不强制转成英文。CogView3 使用另一套规则，不能混在一起。

这个过程带来一个实用的修改位置。你可以在生成前就读出新增的灯笼、匾额和建筑是否符合任务；若只想要现代极简红色海报，就应删掉传统装饰，而不是等生成后才与多余元素较劲。扩写增加的是视觉解释，也会加入原来没有指定的细节。因此，提示增强值得保留，但不宜被当成对原意完全无损的“润色”。这组材料是官方脚本内的示范，并非本文执行后取得的海报。

脚本里还有一个更值得留意的细节：用户只说“动漫女孩站在花丛中”，示范扩写却加入了具体游戏角色及相应外观。这不是原需求提供的信息。它提醒我们，扩写模型会主动填空，甚至替你决定角色身份；如果任务要求原创角色或固定设计，应该把这些新增设定删掉，改回自己已有的资料。看得见扩写文本，才有机会在出图前拦住这种偏移。

因此，创作时值得保留短需求、扩写稿和最终采用稿三份材料。要调整一处配色或文字载体，就在采用稿中明确改那一项，不必每次重新让语言模型自由发挥。这样即使还没开始生成，也能说清这次画面方向为什么变化。

真正画图的，是哪一个模型

本篇对应 CogView4-6B，是支持中英文本提示的文生图模型。官方同时公开 CogView3 系列，版本之间的编码器、提示长度和规则有所不同。CogView4 的长提示上限列为 1024 token，这给详细描述留出了空间，却不意味着每个词都会得到正确表现。

模型卡还列出容易影响实际使用的条件：宽高在 512—2048 之间、为 32 的倍数，总像素不超过2²¹（约210万）；精度支持 BF16/FP32，FP16 可能溢出变成黑图。想直接套用别的绘图模型配置的人，需要先改这些地方。官方显存表采用 batch size 4，不能把表里数字当成任何单张任务的固定需求。

权重卡采用 Apache 2.0，项目提供 Diffusers、网页演示和量化参考代码。提示增强脚本则调用另一个语言模型服务，需要相应 API 权限与用量；本地出图不等于前面的改写也完全离线。对创作者，这个项目最值得带走的是可检查的两段分工：先决定“说明里加了什么”，再看“图里画出了什么”。