NewBie-image-Exp0.1提示词怎么写？XML结构化标签使用指南

NewBie-image-Exp0.1提示词怎么写？XML结构化标签使用指南

你是不是也遇到过这样的问题：明明写了很详细的描述，生成的动漫图里角色却“串了设定”——说好是蓝发双马尾，结果头发颜色不对、发型跑偏、甚至两个角色的脸混在一起？或者想同时控制三个人物的服装、表情、站位，但普通提示词一长就失效，模型干脆“自由发挥”？

NewBie-image-Exp0.1 就是为解决这类痛点而生的。它不是又一个泛用型文生图模型，而是一个专为精准动漫创作打磨过的轻量级专家模型。3.5B参数听起来不大，但它把算力全花在了刀刃上：角色解耦、属性绑定、风格一致性——这些才是画好一张合格动漫图的关键。

更重要的是，它不靠堆提示词长度取胜，而是用一套清晰、可读、易调试的 XML 结构化语法，把“谁、长什么样、穿什么、在哪、什么风格”这些信息一层层拆开、标清楚、喂给模型。就像给画师递一份带编号的分镜脚本，而不是一句模糊的“画个好看的二次元女孩”。

这篇文章不讲安装、不跑环境、不列参数——这些镜像已经替你做好了。我们直接切入最实用的部分：怎么写出真正管用的提示词。你会看到真实可用的 XML 写法、常见翻车场景的避坑方法、以及几个从零到成品的完整示例。哪怕你昨天才第一次听说“提示词”，今天也能调出符合预期的角色图。

1. 为什么普通提示词在动漫生成里容易失效？

先说结论：不是你写得不够细，而是模型“听不懂”你的逻辑。

传统提示词（比如1girl, blue hair, twin tails, teal eyes, school uniform, smiling, anime style）本质上是一串关键词拼接。模型要靠统计规律去猜它们之间的关系——“blue hair”大概率和“1girl”有关，“school uniform”可能和“smiling”共现较多……但这种关联是模糊的、概率性的。

当画面中出现多个角色时，问题立刻放大。比如你写2girls, blue_hair, pink_hair, sailor_uniform, maid_dress，模型无法确定：

• 是左边女孩蓝发水手服、右边粉发女仆装？
• 还是两人都是蓝发+粉发混合？
• 或者干脆把“sailor_uniform”和“maid_dress”当成同一人的叠加穿搭？

NewBie-image-Exp0.1 的 XML 提示词，就是为终结这种混乱而设计的。它强制你把每个角色的属性单独封装、命名明确、层级分明。模型不再需要“猜关系”，而是按结构“取数据”。这就像把Excel表格换成数据库——字段名、主键、外键都清清楚楚，自然不会张冠李戴。

1.1 XML 不是炫技，是降低试错成本

有人觉得写 XML 很麻烦，不如打字快。但实际用过就会发现：

• 改起来快：想把角色A的发型从“twintails”改成“bob_cut”，只改<appearance>里那一行，不用通篇找关键词；
• 查错快：生成图不对？直接对照 XML 检查是<n>写错了名字，还是<gender>标签漏写了；
• 复用快：一套<character_1>配置可以复制粘贴到不同场景里，换<general_tags>就能出新风格。

它不是增加复杂度，而是把隐性的“脑内逻辑”显性化、标准化。对新手来说，这是少走弯路的捷径；对老手来说，这是批量生产的基石。

2. XML提示词核心结构与语法规则

NewBie-image-Exp0.1 的 XML 并非全功能 XML，而是一套精简、安全、面向动漫生成的专用语法。它只保留最必要的标签，所有标签名都小写、无空格、含义直白。你不需要懂 XML 规范，只要会看懂“这个标签管什么”就行。

2.1 必须掌握的三大基础标签块

整个提示词由三个核心部分组成，顺序固定，缺一不可：

<character_1> <n>miku</n> <gender>1girl</gender> <appearance>blue_hair, long_twintails, teal_eyes, white_blouse, red_skirt</appearance> </character_1> <character_2> <n>rin</n> <gender>1girl</gender> <appearance>yellow_hair, short_hair, orange_eyes, yellow_dress</appearance> </character_2> <general_tags> <style>anime_style, high_quality, clean_lines</style> <composition>full_body, front_view, studio_background</composition> <quality>masterpiece, best_quality</quality> </general_tags>

• <character_X>块（X=1,2,3…）：定义单个角色。必须以character_开头 + 数字编号，编号从1开始连续，不能跳（如character_1,character_2,character_3）。每个块内必须包含<n>和<gender>，<appearance>推荐填写。
• <n>标签：角色代号，纯文本，建议用英文名或缩写（如miku,k-on_band）。它不参与画面渲染，只作为你在代码里引用该角色的“ID”。生成图中不会显示这个名字。
• <gender>标签：角色性别/类型标识，必须是社区通用 tag，如1girl,1boy,2girls,group,animal_ears等。这是模型理解角色基础形态的关键信号，填错会导致身体结构异常。
• <appearance>标签：角色外观细节，用英文逗号分隔的 tag 列表。支持所有 Danbooru 风格 tag（如blue_hair,cat_ears,glasses,smiling），也支持自定义组合（如red_cheeks, blushing）。注意：这里只写“属于这个角色”的属性，不要混入场景或画风。
• <general_tags>块：全局控制项，影响整张图。包含<style>（画风）、<composition>（构图）、<quality>（质量）等子标签。所有<character_X>块里的内容，都会叠加应用到这个全局设定下。

2.2 五个关键语法规则（新手必记）

1. 标签必须闭合：每个<xxx>都要有对应的</xxx>。写成<n>miku或<n>miku</n>都不行，必须是<n>miku</n>。
2. 字符限制严格：<n>内容限15字符，<gender>限20字符，<appearance>单个 tag 限30字符，整行不超过200字符。超长会被截断，导致解析失败。
3. 禁止嵌套与属性：不支持<character_1 id="main">这类写法，也不支持<n value="miku">。所有信息都放在标签体内。
4. 空格与换行友好：XML 中的换行、缩进、多余空格均被忽略。你可以写成一行，也可以像示例那样分行缩进，效果完全一样。
5. 注释不生效：<!-- 这是注释 -->在提示词中会被当作无效字符丢弃，不要用来写说明。

2.3 一个典型错误示例与修正

❌ 错误写法（常见新手陷阱）：

<character_1> <n>miku</n> <gender>1girl</gender> <appearance>blue_hair, twintails</appearance> <style>anime_style</style> <!-- ❌ 错！style只能在<general_tags>里 --> </character_1> <general_tags> <style>high_quality</style> <!-- ❌ 错！重复定义，后一个会覆盖前一个 --> </general_tags>

正确写法：

<character_1> <n>miku</n> <gender>1girl</gender> <appearance>blue_hair, long_twintails, teal_eyes, school_uniform</appearance> </character_1> <general_tags> <style>anime_style, high_quality, clean_lines</style> <composition>medium_shot, side_by_side</composition> </general_tags>

3. 从零开始：三个实战提示词案例

光看规则不够直观。下面三个案例，全部来自真实测试，代码可直接运行。我们不只告诉你“怎么写”，更解释“为什么这么写”、“如果改一个地方会怎样”。

3.1 案例一：单角色精细控制（蓝发初音未来）

目标：生成一张正面全身像，突出初音标志性的蓝发双马尾、电子感服饰和活力表情。

prompt = """ <character_1> <n>miku</n> <gender>1girl</gender> <appearance>blue_hair, long_twintails, teal_eyes, futuristic_outfit, glowing_accessories, smiling, energetic_pose</appearance> </character_1> <general_tags> <style>anime_style, official_art, sharp_lines, vibrant_colors</style> <composition>full_body, front_view, studio_background</composition> <quality>masterpiece, best_quality, 4k</quality> </general_tags> """

关键点解析：

• <appearance>里futuristic_outfit和glowing_accessories是初音的核心特征，比泛泛的dress更精准；
• <composition>明确full_body, front_view，避免模型默认画半身或侧脸；
• studio_background强制纯色背景，让焦点100%集中在角色上，方便后续抠图或合成。

效果对比：如果删掉studio_background，模型大概率生成带复杂室内场景的图，人物反而被弱化。

3.2 案例二：双角色互动构图（双子姐妹）

目标：生成一对蓝发与粉发双胞胎姐妹，面对面站立，穿着同款但配色相反的制服，有自然互动感。

prompt = """ <character_1> <n>blue_sis</n> <gender>1girl</gender> <appearance>blue_hair, long_hair, blue_eyes, blue_school_uniform, holding_hand</appearance> </character_1> <character_2> <n>pink_sis</n> <gender>1girl</gender> <appearance>pink_hair, long_hair, pink_eyes, pink_school_uniform, holding_hand</appearance> </character_2> <general_tags> <style>anime_style, gentle_lighting, soft_shadows</style> <composition>medium_shot, facing_each_other, symmetrical_pose</composition> <quality>masterpiece, best_quality</quality> </general_tags> """

关键点解析：

• 两个角色<n>分别叫blue_sis和pink_sis，清晰区分，避免混淆；
• <appearance>中都加了holding_hand，这是模型理解“互动”的强信号，比写together或side_by_side更可靠；
• <composition>用facing_each_other, symmetrical_pose直接指定构图逻辑，模型会自动调整站位和朝向。

避坑提醒：不要在<appearance>里写blue_sis_and_pink_sis_together——这是把两个角色当成了一个整体，模型反而会融合特征。

3.3 案例三：多角色+动态场景（乐队演出）

目标：生成四人女子乐队现场演出图，主唱（蓝发）、吉他手（金发）、贝斯手（绿发）、鼓手（黑发），舞台灯光，动感氛围。

prompt = """ <character_1> <n>vocalist</n> <gender>1girl</gender> <appearance>blue_hair, microphone_in_hand, singing, stage_light_on_face</appearance> </character_1> <character_2> <n>guitarist</n> <gender>1girl</gender> <appearance>blonde_hair, electric_guitar, playing_guitar, dynamic_pose</appearance> </character_2> <character_3> <n>bassist</n> <gender>1girl</gender> <appearance>green_hair, bass_guitar, cool_expression, stage_left</appearance> </character_3> <character_4> <n>drummer</n> <gender>1girl</gender> <appearance>black_hair, drum_kit, hitting_cymbal, energetic</appearance> </character_4> <general_tags> <style>anime_style, concert_photo, dramatic_lighting, motion_blur</style> <composition>wide_shot, stage_background, audience_blurred</composition> <quality>masterpiece, best_quality, detailed_instruments</quality> </general_tags> """

关键点解析：

• 四个角色<n>使用功能名（vocalist,guitarist）而非人名，更契合场景需求；
• <appearance>中加入动作动词（singing,playing_guitar,hitting_cymbal），这是触发动态姿势的关键；
• <composition>用wide-shot和audience_blurred营造真实演唱会纵深感，比单纯写concert更有效。

性能提示：四角色图显存占用接近上限，建议首次运行时先用--lowvram参数（见后文）。

4. 进阶技巧与高频问题解答

掌握了基础结构，下一步是让提示词更稳定、更可控、更高效。这些技巧来自大量实测，不是理论推测。

4.1 三招提升生成稳定性

1. 用<composition>锁定构图，比堆外观tag更有效
   想要半身像？写<composition>upper_body, front_view。想要仰视角度？写<composition>low_angle, looking_up。模型对构图指令的响应远高于外观描述，优先用它框定大框架。

2. <quality>标签里，masterpiece和best_quality必须同时出现
   单独写其中一个，效果提升有限；两者并列，会显著增强线条锐度和色彩饱和度。这是模型训练时的硬编码偏好。

3. 避免在<appearance>里混用矛盾tag
   比如smiling, crying或standing, sitting。模型会强行融合，导致表情扭曲或姿势诡异。不确定时，选一个最核心的状态。

4.2 常见问题与解决方案

Q：生成图里角色数量对不上，少画了一个人？
A：检查<character_X>块是否完整闭合，且编号连续。漏掉</character_2>或写成<character_1><character_3>，都会导致解析中断，后续角色被忽略。

Q：两个角色的发型/衣服颜色混在一起了？
A：确认<appearance>里没有跨角色的通用描述（如blue_and_pink_hair）。每个角色的外观必须独立、完整。必要时，在<n>里加入颜色前缀（<n>blue_miku</n>）强化区分。

Q：想让角色做特定手势（比如比耶、握拳），但没效果？
A：直接写victory_sign,fist,pointing等 Danbooru 标准手势tag。避免描述性语言如hand_up或making_a_gesture。

Q：生成速度慢，显存爆了？
A：在test.py或create.py的pipe()调用里，添加参数：

pipe(..., enable_sequential_cpu_offload=True) # 启用CPU卸载 # 或 pipe(..., torch_dtype=torch.bfloat16) # 确保dtype一致

5. 总结：把XML提示词变成你的创作习惯

NewBie-image-Exp0.1 的 XML 提示词，本质是一种创作思维的转变：从“尽可能多说”转向“精准定义”。它不追求提示词的长度，而追求信息的密度与结构的清晰。

你会发现，一旦习惯了用<character_1>块管理角色、用<general_tags>控制全局，你的创作流程会变得异常干净：

• 构思阶段，直接在脑中划分“角色属性”和“画面属性”；
• 写作阶段，像填表格一样逐项填写，几乎没有歧义；
• 调试阶段，哪里不对就改哪一块，不用重写整段。

这正是专业工具该有的样子——不增加认知负担，而是把复杂性封装起来，把确定性交还给你。

现在，打开你的test.py，选一个案例，把 prompt 替换进去，敲下回车。几秒钟后，那张属于你定义的动漫图，就会出现在success_output.png里。这不是魔法，是结构化表达的力量。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。