认知图谱

游戏与视觉 · 模块

M06美术与视觉资产

美术讨论最后收敛为一条工程化原则：先用分用途的参考锁定风格与角色身份，再把每类资产写成可检查的规格，让生成、后处理、引擎接入和人审各自出证据。画面负责让规则看得清，可走性、范围、血条和文字交给配置与程序。

核心流程

从风格探索到资产入库

上排定方向与规格，下排处理与验收，从右往左走；中间的修订节点只改指定项，不推倒重来。所有图片按用户要求暂缓审读，本页只依据文字材料，不评价任何生成效果。

美术资产从风格探索到入库的流程 先比较多个风格方向并锁定风格与身份，再写资产规格、分批生成，经后处理、机器检查和人审读图后接入引擎入库；机器或人审发现局部缺陷时只改指定项重新生成，身份或风格漂移时回到参考。 定方向与规格 处理、验收与接入（自右向左） 保留源图 漂移·补参考 局部缺陷 不合规 仅改指定项 多方向探索 同一战场比较候选 锁定风格与身份 分用途参考·共享约束 写资产规格 用途→尺寸·视角·锚点 分批生成 共同风格＋主体＋禁止项 局部修订 保留项＋仅改项 后处理 键色→真 Alpha·切片·量化 机器检查 尺寸·色表·alpha·接缝 人审与游戏内读图 身份·小尺寸·整屏状态 接入引擎并入库 实际导入·不覆盖旧版 画出来的棋盘格不是透明；写了“透明背景”也要查 alpha 通道
每一步各自留证据：规格写清用途，生成留源图，机器查格式，人看身份与读图，接入以真实导入为准。　依据：C002-035-01、C002-062-16、C002-073-03、C001-086-01、C001-052-02、C002-046-05、C002-046-04、C001-086-02、C002-001-02

核心逻辑

七条可复用的美术工程判断

风格靠分用途的参考与可审查约束锁定

角色设定图管身份与装备，整体风格图管画法与光照，局部风格板管材质细节。跨批共享的约束写成调色板、像素密度、光源方向和描边，而不是“商业级”“game-ready”这类形容词；“完整入画”“飞剑恰为三柄”“遮挡不穿体”这样的条目才能逐项审查。

参考图要有效并定好优先级；文字列得再细也不保证模型遵守，最终仍要看图。

题材、表现方式与镜头投影分开选

中国风是题材语言，像素、手绘、风格化三维是表现方案，俯视、等距、正交方格是投影，三者可以自由组合；选了中国风并不意味着必须水墨。比较候选时用同一张小地图、同样单位数和 UI 占位，同时看完整战斗画面、地图局部和素材拆分；替换画风时回查画幅、阵营色、限色、光照这些共同约束有没有被连带改掉。

25 份同战场 brief 同时改了头身比、密度和光照，不是只改画风的公平对照，也没有选出胜者。

角色身份锁锚点，修订只动表演

同一设计版本先锁脸型、毛发、体型、服饰家族、配色和画法，再只改动作或表情；每个角色有自己的面形、眉眼、发须与剪影组合，绑定角色 ID，同族同姓也不共用一张脸。动作写成左右手、承重腿、视线和道具各自的任务，定格在一个能实现的瞬间。

历史人物的史实、文学叙事、神化版本和新增美术设计要分字段；面貌、身高和服制是设计，不是史实复原。

画面让规则可读，但不替规则做决定

地形图像与可通行性、移动消耗分开存放；移动和攻击范围、生命条由程序按规则绘制，文字由引擎渲染，规则一变不必重画。塔防地图只生成纯地形和连续路线，塔位平台单独生成，便于运行时放置；高低差用轮廓、立面厚度和投影表达，是否影响射程由规则决定。

美术形状不能自行设定战斗加成；配置里的 move_cost、passable 等字段要有唯一维护源，避免和资源清单重复漂移。

透明、尺寸和接缝交给机器，身份与观感交给人

画出来的棋盘格不是透明，提示词写了“透明背景”也不证明有 alpha 通道；键色原稿、去背过程和真 Alpha 成品是不同工序。色表量化覆盖 alpha 会出黑底，应把 RGB 量化和 alpha 分开处理再合并。调色板、精确尺寸、alpha、瓦片接缝和图集边界交给机器检查，人物身份、小尺寸辨识和整图观感交给人审。

机器检查通过不证明画面可读、接缝语义完整或进引擎正确；指标命中不等于美术完成。

读图要在真实游戏状态下验

宣传图好看不能证明长时间操作可读，要加上格子、血条、移动范围和选中状态再评清晰。职业由服装和武器轮廓承担，阵营由独立的脚圈或徽标承担，不让服装颜色独自区分敌我。静态截图只能判断当前展示状态，看不到动画和悬停不等于功能缺失；运行 UI 用主题、组件与状态组织，整页效果图只作参考。

最终缩放、色觉差异和连续操作都要用实际输入与玩家旅程测试；本模块涉及的截图全部暂缓审读。

资产是带身份和版本的工程对象

可编辑源文件、运行资源和规格配置分开维护；草稿、原图、清洗、验证、引擎就绪和入库分状态，已批准的资源不原地覆盖，改动另建版本。命名用主题、类别、对象、变体、状态、编号等稳定字段，避免“最终版”；生成时记录工具、模型、风格 ID、seed 和提示词哈希，保留源图再派生。

这些记录只帮助追溯，不构成版权或许可结论；把文件复制进引擎目录也不等于导入成功。

结构

战场画面分层与提示词约束

上图按屏幕叠放顺序列出战棋战场的六层：每层由谁产出、规则真相放在哪里；下图是一份视觉 brief 从项目共享约束到本轮修订的嵌套关系。规则核心与表现层怎样分工，见 M05 游戏设计与研发架构。

战棋战场画面的六层与规则归属 从上到下为界面控件、状态信息、战术叠层、单位精灵、物件与平台、地形底图，标出每层由引擎组件、程序绘制还是生成图产出，右栏写规则真相所在；战术叠层是焦点。 画面层（自上而下叠放） 规则真相放在哪里 L1 界面控件 引擎组件 主题、组件、布局与状态；整页效果图只作参考 可编辑控件与真实输入行为 按钮各状态、九宫拉伸按需验证 L2 状态信息 程序绘制 生命条、阵营脚圈、已行动去饱和、状态图标 阵营靠独立脚圈或徽标，不只靠服装颜色 行动耗尽、受伤、异常放在不同位置编码 L3 战术叠层 程序绘制 移动与攻击范围、路径箭头、敌方意图、网格 按规则实时计算，画面不自行设定范围 静态示意证明不了寻路或威胁预览正确 L4 单位精灵 生成＋后处理 同源派生方向、阵营色与表情；中心锚定、脚底基线一致 逻辑占格与图像轮廓分开记录 大型特效留给引擎，不画进精灵 L5 物件与平台 生成·独立放置 建筑按完整、受损、开启等状态准备；塔位平台单独生成 遮挡、掩体、通行与交互语义随状态交付 状态变化后画面与规则是否一致，要进引擎验 L6 地形底图 生成 纯地形与连续路线，不烘焙塔位和游戏标记 terrain_type、move_cost、passable 写在配置 高地是否加成由规则决定，不由画面决定 随规则变化的层交给程序，规则改动时不必重画美术
随规则变化的层交给程序与配置，生成图只负责让规则看得清。　依据：C002-046-02、C001-089-01、C002-063-09、C002-063-10、C002-059-01、C002-073-04、C002-062-07、C002-062-08、C002-001-03

一份视觉 brief 的四层约束

25 份同战场 brief 与各类素材提示词共享同一种结构：越外层越稳定、越跨资产；越内层越具体、越常改。局部修订只动最内层，换画风只换第二层。

视觉 brief 从共享约束到本轮修订的嵌套 最外层是项目共享约束，其内依次是每个画风方向的参数、单个资产的主体规格和本轮修订的保留项与仅改项；本轮修订是焦点。 项目共享约束 画幅与逻辑分辨率 · 阵营色 · 网格与镜头投影 · 职业道具词表 · 题材与时代范围 跨所有资产与候选方向 方向参数 画风媒材 · 头身比 · 限色 · 光照与天气 · 描边与抗锯齿 换画风时整组替换 资产主体 主体 · 视角 · 尺寸与留边 · 构图 · 动作瞬间 · 道具数量与朝向 每类资产不同：角色、tile、UI、图标 本轮修订 保留项 ＋ 仅改项：一次只动表演或局部缺陷 局部迭代，不推倒重来 例：保留脸型、发须、服饰家族与画法，只改眉眼、手势和重心 替换任何一层的参数，都要回查外层约束是否被连带改动
外层越稳定，内层的局部修订越可控；改动外层时要回查所有内层。　依据：C002-063-02、C001-052-02、C002-063-28、C001-086-01、C002-074-01、C001-086-02、C002-091-02

演进

从单张提示词到资产工程

  1. 2026.04

    海报与角色阵列提示词

    旅行海报和史诗叙事海报只给分层画面规格；36 人 2D-HD 角色阵列由一张图改为每张 6 人分批，同时要求检查网格、风格统一与轮廓区分。这一段只有提示词，没有生成验收。

    代表会话：GPT-Image-2 Amalfi Coast、终极整合 Prompt v2.0、生图-01-史诗叙事海报设计

  2. 2026.05 – 2026.06

    游戏素材开始规格化

    仙侠塔防锁定 32×32 可读轮廓与限定色，先做风格参考再分批生成塔、敌人、tile、UI、VFX 和图标；地图从“含塔位”改为纯地形加独立平台。素材按用途推导视角、尺寸与构图，06-26 进一步提出资产规格、风格引用和处理状态。请求—生成—后处理—QA—批准—引擎的素材工厂方案见 M05 同期会话。

    代表会话：游戏-08-仙侠塔防素材提示词、2D Xianxia Tower-Defense Background、优化提示词生成素材、AI驱动游戏美术优化

  3. 2026.08

    战棋风格探索与像素工程

    试过 17 种战棋美术方向后，用战场背景、骑士、UI 和攻击反馈分别检验水墨方向，之后又尝试全彩青绿（请求顺序不代表已选定最终风格）；SRPG M0 像素规格用调色板、像素密度、光源与描边锁风格，范围与血条交给程序，并修正了色表量化覆盖 alpha 造成的黑底。

    代表会话：美术｜创建图片请求、生成SRPG像素美术

  4. 2026.09

    同场景比较、资源分类与人物立绘

    25 份同战场 brief 暴露出投影、限色、阵营色与天气等共同约束的冲突；美术资源被分成 12 类，并给出地图包、命名与索引；历史人物立绘确立身份锚点和史实/设计分字段；风格探索被用户纠正为保留原有完成度、只减机械重复的纹理。

    代表会话：Generate Battle Screenshot、游戏美术素材分类、美术｜诸葛亮立绘设定、美术｜Style exploration board

  5. 2026.10

    统一风格与玩家旅程

    UI 调研把共同规则扩展到信息层级、语义色与动效，要求贯通准备、战斗、掉落比较和换装的连续操作；项目审查区分成品、原型与素材实验，修问题前先核版本。人物立绘区分史实稿、神化稿与作品稿；修仙大地图强调疏密与可建设空间。

    代表会话：游戏美术｜UI与统一风格调研、美术｜创建图像阿巴亥、美术｜生成修仙大地图

边界

可复用的方法，与暂缓的画面判断

可以直接复用

  • 分用途参考（设定图、风格图、材质板）加共享风格约束；用可数、可看的条目代替形容词。
  • 修订人物时锁身份锚点只改表演；史实、文学、神化与设计分字段记录。
  • 地形图与通行配置分离；范围、血条由程序画，文字由引擎渲染；地图、平台和建筑状态分开生成。
  • 键色原稿 → 去背 → 真 Alpha 分工序；RGB 量化与 alpha 分开处理。
  • 机器检查与人审分层；候选风格放进同一战场、同样的 UI 占位里比较。
  • 源文件、导出与配置分开，状态流转不覆盖已批准版本，记录 seed 与提示词哈希。

不能据此断言

  • 图片按用户要求全部暂缓审读：本页不评价任何生成效果、风格优劣或截图缺陷。
  • 17 种、25 种战棋方向以及水墨、青绿等都是候选 brief，没有选定全局最终风格。
  • 32×32、DB32 调色板、1.2 格、头身比、114/299 项清单是具体方案参数，不是通用标准。
  • 历史人物的外貌、服制和器物是美术设计；参照作品的特征、奖项和许可都未核实。
  • “已生成”“稳定性提升 300%”、0.86 风格分等自报没有依据；game-ready、AAA 等标签不构成资产可用性证据。
  • 素材记录里的商用字段和生成来源标签不是许可证明，商业使用要逐文件核。

交互大图

单个美术资产的状态

可缩放、搜索、聚焦路径。

生成候选 → 清洗 → 隔离试导入 → 验收 → 入库；不合格回到修订，mock 不能被批准。新窗口打开

来源

本模块全部会话

点开看审读摘要和该会话的主张；数据由 tools/build_atlas.py 从审读账本生成。

主张浏览

全部审读主张

按性质筛选或搜索；点编号看条件与出处。