1. 分离着色器编译、烘焙、staging 与打包
着色器编译、内容烘焙、staging 与打包是独立阶段。着色器阶段将材质和全局着色器的置换项转换为目标着色器格式。烘焙会把可用于目标平台的资源序列化。staging 会组装已烘焙内容及前置依赖。打包会生成可分发容器或安装包。在更改设置或缓存前先明确失败阶段。
为一份构建日志标注阶段开始和结束时间、目标平台、配置、引擎修订版、着色器格式、Cook 模式和输出路径。首次着色器编译较慢可能是预期的缓存填充；若某个资产在多次构建中反复失败，则属于确定性内容缺陷；若构建包已阶段化却无法启动，则属于不同的验收问题。
分离着色器编译、Cooking、Staging 与打包清单
- 用一句话说明“Separate shader compilation cooking staging and packaging”的决策。
- 记录着色器置换项如何被归属、版本化和校验。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
2. 保留首个可执行日志证据
在清理之前保留完整日志。优先从顶部查找与某资产、插件、模块、序列化器、SDK、着色器编译器或平台规则相关的首个错误；最终的“Unknown Error”通常只是早期原因的汇总。保存命令行、环境、源码修订、已启用插件、目标 RHI 以及本次运行是清洁构建还是增量构建。
通过移除一个可疑的地图、资产、插件或配置更改来建立邻近成功案例，并保持其他条件不变。如果错误消失，再恢复该项并复现。这个双向测试可区分真实依赖与瞬态 Worker/缓存症状，并为 CI 提供更集中的回归样例。
保留首个可执行的日志证据清单
- 对“保留首个可执行日志证据”给出一句话决策。
- 记录 Cook 阶段和目标平台内容的归属、版本管理和验证方式。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
3. 诊断着色器排列与派生数据
着色器置换项增长来源于材质特性、静态开关、质量等级、平台、顶点工厂和全局着色器条件。在强制编译之前，先盘点发布版本实际需要的组合。材质实例可以廉价地更改运行时参数，而静态开关会创建一条必须编译并存储的独立编译路径。
派生数据缓存（Derived Data Cache）会存储可复现的派生产物并减少重复工作，但它并非事实真相来源。比较冷启动本地、温启动本地与共享缓存构建；记录命中行为、并发工作线程、网络吞吐量，以及引擎或源码变更后的失效情况。清理 DDC 仅应作为在证据保存后的诊断实验。
诊断着色器变体与衍生数据检查清单
- 用一句话说明“Diagnose shader permutations and derived data”的决策。
- 记录最早可执行构建日志证据的归属、版本管理和验证方式。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
4. 按资产和依赖关系诊断 Cooking 失败
Cook 失败通常暴露缺失引用、重定向器、不受支持的资产格式、仅编辑器依赖项、序列化变更、插件内容规则、未配置的地图或目标平台限制。请使用最早错误中的资产路径，在自动化所用的同一引擎修订版中检查引用并加载该资产。
先在最小化烘焙中测试修复后的资源，再在完整项目中测试。有目的地修复重定向器，仅重新保存受影响的包，核验插件描述符和运行时模块，并确认软引用与资源管理器规则包含所需内容。编辑器成功加载并不证明目标烘焙包已包含该资源或能够反序列化。
按资源与依赖清单诊断烘焙失败
- 用一句话说明“Diagnose cooking failures by asset and dependency”的决策。
- 记录干净构建时长与缓存边界如何归属、版本化和验证。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
5. 缩短构建时间，但不掩盖缺陷
通过移除未使用的变体、稳定共享缓存访问、提高安全并行工作线程数、拆分独立目标，以及避免不必要的完整失效，来缩短时间。每次改动都要与同一次干净构建和增量构建对照测量。不要用重试循环掩盖确定性故障，也不要把本地更快的热启动构建当作发布版本改进。
跟踪着色器编译时间、按包统计的烘焙时间、缓存传输、CPU 利用率、峰值内存、磁盘吞吐、产物体积和最长串行段。有效的优化报告应包含源代码修订版本、硬件、目标、缓存状态，以及多次运行间的方差，以便在其他构建机上复现结果。
缩短构建时间但不隐藏缺陷清单
- 对“缩短构建时间，但不掩盖缺陷”给出一句话决策。
- 记录着色器置换项如何被归属、版本化和校验。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
6. 在自动化环境和另一台机器上复现
自动化验证项目状态是否可移植。从第二台机器或工作节点的干净检出开始，仅恢复已批准的缓存，安装记录的SDK和引擎，并运行完全相同的命令。如果仅在某一工作站成功，请比较环境变量、插件、生成的游戏文件、权限和本地修改的资产。
将源控件管理的输入与 Intermediate、Saved、DerivedDataCache、staged 输出和生成的二进制文件分离。发布构建时长和缓存诊断作为产物。回归测试应包含先前失败的包和启动冒烟测试，而不应只看一个绿色 cook 退出码。
在自动化环境和另一台机器上复现清单
- 对“在自动化环境和另一台机器上复现”给出一句话决策。
- 记录 Cook 阶段和目标平台内容的归属、版本管理和验证方式。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
7. 定义打包验收与回滚门禁
打包门禁要求：清洁构建或按策略定义的构建、完整日志、时长在预算内、产物哈希与体积、成功安装或解包、编辑器外启动、必需地图加载、存档或网络冒烟测试，以及无新增高严重性警告。例外情况必须明确责任人、到期日期并给出回滚决策。
保留最后一个已知良好的产物及其工具链元数据。当一次变更跨越构建时长阈值或未通过启动测试时，应对源代码或内容修订版本进行二分排查，而不是清空所有缓存。最终证据应是目标平台上的可复现产物，而不是偶然可用的编辑器会话。
定义一份打包验收与回滚门禁清单
- 对“定义打包验收与回滚门禁”给出一句话决策。
- 记录最早可执行构建日志证据的归属、版本管理和验证方式。
- 对相关查询“unreal engine cooking failed”应用相同的验收标准。
- 捕获帧百分位数、通道毫秒数、卡顿（hitches）、峰值与常驻内存、负载、带宽以及回归阈值。
- 保留可回退的可工作修订版，并写明会迫使回滚的限制条件。
SEELE AI Unreal 5 工作流：生成、预览、优化、打包和发布
当团队需要比较镜头方向、玩家循环、相机手感、内容简报或测试计划时，SEELE AI 可在 Unreal 生产前或并行阶段提供帮助。打开官方 Unreal 着陆页，选择一个真实的 workspace card，并将该提示词带入浏览器生成工作区，保留其来源归属。
SEELE AI可以生成原生虚幻5游戏，在浏览器中预览，优化并打包，并提供可下载的游戏或打包构建，用于外部发布或付费的Seele游戏。不保证销售。
官方来源和相关 Unreal 指南
本页是独立的工作流指南。不同发行版本、插件、平台和项目设置会导致引擎行为变化，请在Epic文档中确认版本特定细节，并保留用于决策的证据。
Unreal Engine 是 Epic Games 的商标。SEELE AI 为独立产品，且本指南未获得 Epic 的背书。
- 内容烘焙 — 只针对产品范围、工作流、版本或政策核验的第一方材料；仅使用来源实际声明的内容。
- Unreal Engine 着色器开发（2026 年 7月更新） — 只针对产品范围、工作流、版本或政策核验的第一方材料；仅使用来源实际声明的内容。
- Unreal Engine 中的衍生数据缓存（2026 年 7月更新） — 只针对产品范围、工作流、版本或政策核验的第一方材料；仅使用来源实际声明的内容。
- 测试和优化内容 — 只针对产品范围、工作流、版本或政策核验的第一方材料；仅使用来源实际声明的内容。
常见问题
着色器编译是否等同于 Cooking？
不是。着色器编译会生成着色器排列（permutation），而 Cooking 则是在打包前将项目内容转换为目标平台格式。
我应该从哪里开始处理 Cook 失败？
保留完整日志并修复最早出现的确定性资源、插件、配置或工具链错误。
是否应先删除衍生数据缓存？
不是第一步。先保留证据并复现，再清空缓存，否则可能掩盖确定性项目缺陷。
为什么干净构建耗时更长？
干净构建会重新创建衍生数据和可供增量构建复用的已烘焙输出。应分别测量两者。
一个损坏的资源能否阻止烘焙？
是的。不受支持的格式、损坏引用、序列化错误或平台规则都可能导致 Cook 停止。
什么能证明修复有效？
一份清洁的自动化 Cook 加上在目标平台上可启动的打包产物，能比“重启编辑器”提供更强的证明力。
