一、业务冲突

生成图片、模型或动画的速度越来越快，但客户端真正消费的是带引用、平台制品和运行时预算的资产。预览图能显示，不能证明纹理色彩与压缩正确；模型文件能下载，不能证明拓扑、材质、骨架、碰撞和 LOD 可用；视频动画更不等于可混合、可同步的骨骼动画。

二、实际实现

实际图片流程已经采用两阶段：生成工具返回 Base64、建议名称、模型、尺寸、宽高比、Prompt 和来源元数据，前端先预览，用户确认后由服务端生成受管路径并写入资产索引。文件系统决定资产是否存在，索引保存标题、来源和生成信息，并可从磁盘扫描恢复缺失记录。

但 3D 与动画工具仍直接把下载结果写入资产目录；图片保存也只验证 Base64 非空，就把字节标记为 PNG。索引写入和容器同步失败被视为非致命，接口仍可返回成功。

三、值得保留

“生成候选 -> 预览 -> 用户保存”的图片流程明显优于生成即入库。服务端生成路径避免模型控制目标文件名，来源元数据和可恢复索引也为后续追溯提供了起点。

四、结构性缺陷

三种生成工具的准入语义不一致：图片需要确认，模型和动画直接写入。非空字节不证明魔数、解码、分辨率或格式；元数据缺少输入摘要、服务请求身份、生成参数版本和后续处理链。成功写文件但索引失败会产生降级记录，容器同步失败又可能造成宿主与预览环境看到不同资产。更关键的是，当前生成结果尚未进入 UE 导入、Cook、Skeleton、Physics Asset、材质槽和平台预算验证。

五、目标设计

所有模态统一进入隔离候选区：

struct CandidateAsset {
    CandidateId id;
    GenerationReceipt generation; // provider, model revision, params, input digest
    BlobRef source;
    DetectedFormat format;
    ValidationReport report;
    vector<ArtifactRef> platformArtifacts;
};

Promote(candidate) {
    VerifyBytesAndSchema(candidate);
    ImportInIsolatedEditor(candidate);
    ValidateReferencesAndBudgets(candidate);
    BuildRequiredPlatforms(candidate);
    VerifyRuntimePreview(candidate);
    CommitAssetAndIndexAtomically(candidate);
}

图片检查色彩、Alpha、Mip 与平台压缩；模型检查拓扑、材质、LOD、碰撞和缩放；骨骼动画检查 Skeleton、参考姿势、Root Motion、事件和压缩。任何失败都只淘汰候选，不污染正式引用。

六、取舍与验证

隔离导入和多平台构建会削弱“立即生成”的即时感，因此 UI 可以快速展示原始预览，同时明确它尚未被接受。生成能力会快速变化，准入契约则应稳定；截至 2026-10-14，NIST 的生成式 AI 风险框架仍建议按具体使用场景和完整生命周期管理生成内容风险，而不是只评价单次输出质量。NIST AI RMF Generative AI Profile

测试要使用伪装扩展名、损坏字节、超预算纹理、异常网格、错误骨架、无碰撞模型、索引写失败、容器同步失败和相同输入不可复现等样本。验收结果必须是结构化报告和可定位制品，不是“预览看起来不错”。