生成完就直接拖进下游软件，是这类问题最常见的起点：比例不对、朝向歪、贴图变灰，往往要等到渲染或实时场景里才暴露，此时已经很难判断问题出在生成端、导出端还是导入端。比较稳妥的做法是把检查前移到交接环节——在资产交给下游之前，用一组可记录的对比项把“应该是什么样”固定下来，下游只负责核对“是否一致”。资产本身好不好看属于审美问题，交接检查只关心尺寸、朝向、原点、贴图路径这些能被读取和比对的事实。

适用场景：AI 生成的三维资产（模型、材质、贴图包）交给渲染器、实时引擎或第三方工具之前。操作动作：记录导出端的包围盒尺寸、坐标轴与 forward 方向、原点位置、贴图清单，导入后逐项比对并留痕。验证方式：三向尺寸比值、节点变换值、贴图加载计数、最小场景目视。风险边界：不同格式与软件的单位、轴向约定不同，下面的参数只是通用核对思路，具体取值需要结合下游软件版本和导入设置确认。

确认模型单位与比例在导入后未变

单位错乱的典型表现是“所有东西都差一个固定倍数”，例如人物高出一百倍或缩成 0.01 倍，而不是个别部件错位；如果只有单个部件大小不对，更可能是建模时的非等比缩放没有应用。所以第一步不是看模型好不好看，而是在导出前把包围盒尺寸记下来，落到文件里而不是留在脑子里。

1. 导出端记录三向尺寸、当前单位设置、缩放是否已应用（scale 是否为 1）。
2. 把记录写进资产清单文件，与资产文件一起走下游流程。
3. 导入后立刻读一次包围盒，和记录逐向比对，再看三个方向的比值是否一致。

{
  "asset": "chair_A",
  "version": "v3",
  "export": {"format": "glb", "unit": "m", "scale_applied": true},
  "bbox_export": {"x": 0.62, "y": 0.58, "z": 0.95}
}

import json
rec = json.load(open("asset_manifest.json"))
now = {"x": 0.62, "y": 0.58, "z": 0.95}  # 替换为导入后实际读到的尺寸
for k in ("x", "y", "z"):
    print(k, "ratio=", round(now[k] / rec["bbox_export"][k], 4))

判读方式很直接：三向比值都接近 1，说明尺度正常；三向一致但整体是 100 或 0.01 这类整齐倍数，通常是对单位约定理解不一致（常见于厘米与米的换算）；只有单轴偏离，优先怀疑导出时没有应用变换，或某个子节点带了缩放。确认是单位问题后，建议改导出设置重新导出，而不是在导入端手动缩放“修好”——手动缩放会被写进场景文件，换个工具再导入又会错一次，而且后面接手的人看不出这里被改过。

核对坐标朝向与原点位置

朝向异常最容易被当成“摆一下就好”，结果每次导入都要手动转九十度。观察方式：在导出端和下游各放一个带标识面的参照物（比如立方体正面写一个字），或者直接看资产正面是否朝相机；常见现象是模型整体躺倒（Y 轴向上与 Z 轴向上的差异）、正面朝向与下游约定相反、以及旋转了整九十度。

比目视更可靠的判断是读节点变换值。导入后如果节点 rotation 不为零、scale 出现负值，基本可以确认导出端没有应用变换，或者沿某轴做了镜像。负缩放还会连带影响法线方向和背面剔除，比单纯朝向歪更难排查。

# 读取导入后的节点基础变换，确认没有隐藏旋转或负缩放
node = scene_node("chair_A")
print("rotation:", node.rotation)   # 期望接近单位旋转
print("scale:", node.scale)         # 期望接近 (1, 1, 1)，且不为负
print("bbox_center:", node.bbox_center)

调整手段分两段：导出端应用旋转与缩放，把原点统一放到约定位置（脚底中心或几何中心，二选一并写进备注）；导入端只做参数级的轴向转换和单位缩放，不要靠拖拽手柄把模型“摆正”。原点位置也要单独看一眼，如果包围盒中心离原点很远，下游做对齐、吸附、绕轴旋转时会绕着远处那个点转，表现得很别扭，这类偏移量明显大于资产自身尺寸时就应视为可疑。

验证材质与贴图路径是否可解析

贴图丢失后通常表现为灰模或纯白，容易和“材质本来就没做好”混淆。检查思路是先确认贴图在不在，再确认引用路径能不能被目标环境解析，而不是打开下游软件逐个材质手动重连。

1. 导出前生成贴图清单：文件名、尺寸、被哪个材质引用。
2. 贴图与模型放同一目录，引用写成相对路径，避免盘符或用户目录这类绝对路径。
3. 文件名避免中文、空格和大小写混用——部分导入器在区分大小写的文件系统上会找不到贴图。
4. 能内嵌就内嵌（例如把贴图打进 glb），不能内嵌就把素材目录整体打包，别只发一个模型文件。
5. 导入后统计材质数量与成功加载的贴图数量，两者对不上就继续查路径。

# 在资产目录里找写死的绝对路径引用
grep -RInE '([A-Za-z]:\\\\|/Users/|/home/)' ./materials `--include`=*.mtl `--include`=*.json

import os
missing = []
for line in open("chair_A.mtl", encoding="utf-8"):
    if line.startswith("map_"):
        path = line.split(maxsplit=1)[1].strip()
        if not os.path.exists(path):
            missing.append(path)
print("缺失贴图:", missing)

缺失时的处理顺序：先改路径为相对路径并重新打包，再回到生成端重新导出一次完整包；如果时间不允许，至少把缺失清单写进资产备注，让下游知道哪几张图需要手动补。只在下游手动重新指定贴图、却不更新资产包，是这类问题反复出现的主要原因。

在下游场景里做一次最小可用验证

最小可用验证的目的不是看效果，而是确认资产在真实环境里“成立”。场景尽量简单：一个已知尺寸的参照物（一米立方体或已知身高的胶囊体）、一块地面或网格、一盏默认灯、一个默认相机。不要一开始就套复杂的环境光照，那会把材质问题盖住。

• 尺寸：资产与参照物并排，高度、坐高、跨度是否合理。
• 朝向：资产正面是否朝相机，和参照物标识面方向是否一致。
• 落地：脚底是否贴合地面，不悬空也不陷进去。
• 材质：贴图有颜色、不灰不白，透明与双面是否符合预期。
• 动画（如有）：只播首帧与末帧，看是否穿模或错位。
• 层级与命名：节点名是否可读，导入后有没有多余的空节点。

观察结果建议截图或记录视口参数，包括下游软件名称与版本、导入选项、参照物尺寸，否则下次复现时说不清当时的环境。这一步发现的问题，优先回到导出端修，修完重新走一遍最小场景。

把本次导入问题写回资产备注

同一类导入问题重复出现，多半是因为处理过程只留在当次聊天或某个人的记忆里。解决办法是把结论写回资产备注，用固定字段和固定分类词表，让后面的人能搜到。

建议字段：资产名与版本、导出格式与单位、向上轴与 forward 方向、原点位置、贴图模式（内嵌/外链/相对路径）、下游软件与版本、问题分类、现象描述、原因判断、处理方式、当前状态。

{
  "asset": "chair_A@v3",
  "handoff": {
    "format": "glb",
    "unit": "m",
    "up_axis": "Y",
    "forward": "+Z",
    "origin": "bbox_bottom_center",
    "textures": "embedded"
  },
  "import_issues": [
    {
      "type": "scale",
      "env": "下游软件名 + 版本",
      "symptom": "导入后整体尺寸明显偏大",
      "cause_guess": "导出单位与导入解析单位不一致",
      "fix": "改为米后重新导出",
      "status": "已修复"
    }
  ]
}

问题分类建议用固定词表，例如：尺度、朝向、原点、材质、贴图路径、动画、命名与层级、面数与性能。固定词表的价值在于可检索——下次遇到“导入后变灰”，直接按“贴图路径”翻历史备注，比重新试一遍导出参数快得多。备注和资产文件放在一起走流程，不要只写在工单里。