多模态工作流 · 截图、日志、追踪与场景证据

多模态虚幻调试与 Gemini 3.6 Flash —— 全球首个在线原生虚幻工作流

截图可以显示症状，而日志或追踪能解释产生该症状的系统。Gemini 3.6 Flash 可以帮助将这些证据类型关联起来，但结果必须保持为按优先级排序的诊断并附带可复现检查，而不是宣称 Unreal 的 bug 已修复。

直接回答

将一个故障打包为证据包：项目和引擎版本、复现步骤、预期和实际结果、带注释的捕获、相关日志或追踪、近期变更、目标硬件和隐私审查。要求输出按优先级排序的假设、支持与反对每个假设的证据、下一个区分性测试及可回滚修复计划。

选择一个边界明确且可回滚、且有明确正确结果的任务：解释编译错误、提出小幅C++修改、映射Blueprint职责、分析截图回归，或起草自动化检查。对每个测试的模型记录相同的输入、预期结果、时间、Token使用、修改、失败和回滚成本。阅读 Google 的发布说明

支持Unreal Engine规划的Gemini模型评估工作流编辑概念艺术 — 独立的编辑概念。它不是Gemini输出、Unreal Editor采集、原生集成或打包游戏结果。

这对Unreal团队意味着什么

最佳输入包

将带注释的截图或短截图与相关日志窗口、Insights 跟踪、控制台变量、资产或蓝图上下文、复现步骤和预期行为配对。

最佳输出格式

要求将观察到的事实、不确定推断、按优先级排序的假设、区分性测试、拟议责任人、风险和回滚作为独立字段。

常见故障

模型往往过度关注可见症状、猜测一个熟悉的引擎设置，或忽略编辑器、PIE、独立运行和打包行为存在差异。

验收证据

相同输入必须在变更前复现问题，并且在目标模式与硬件上变更后通过，且保留日志、追踪和回归检查。

创建可评审的证据包

先给出一句故障描述：操作、预期结果、实际结果、模式、引擎版本、平台和复现频率。仅添加能揭示症状或状态的捕获内容。标注相关的帧、时间戳、Actor、视图、材质、UI 元素或网络角色。单独保留原始文件，以免压缩和标记抹掉证据。

附上最小相关日志窗口，并在适当情况下附加 Unreal Insights 时序、GPU 捕获、Visual Logger 输出、网络追踪、自动化结果、崩溃调用栈、资产审计、Blueprint 编译消息或烹饪报告。包含近期变更和干净基线对比。向外部模型发送任何内容前，移除 API 密钥、账户数据、私有仓库 URL、用户标识符、授权源资产和无关项目材料。

提示进行诊断而非表达置信度

先要求模型列出直接观察结果。然后请求三个或更少的假设，每个假设都要对应具体证据、反向证据和一个低成本测试，以便将其与其他假设区分。要求给出最可能的 Unreal 子系统及负责的文件、资产、图表、设置或运行时状态。若证据不足，正确输出应是请求一个缺失的证据项，而不是编造根因。

对于渲染问题，区分相机曝光、材质、照明、后期处理、纹理流式传输、着色器编译、LOD、Nanite、Lumen、上采样、驱动与抓帧伪影。对于玩法问题，区分输入、authority、状态机转移、动画、碰撞、导航、存档状态和 UI 呈现。对于性能问题，在建议优化前先区分 CPU、GPU、内存、I/O、着色器、流式传输、网络和内容规模信号。