用途
本技能用于把 Unity 和 Unreal 的日志（编辑器、构建、打包、Cook、编译、CI）转化为简短、按优先级排序的调试简报。目标不是解释每一行日志，而是找到第一个非级联故障、识别最可能的子系统，并告诉用户下一步应检查什么。
在归类不熟悉的引擎特有错误前，先阅读 references/engine-patterns.md。若用户询问的不是单个失败日志，而是反复出现的 CI 不稳定、缓存策略、打包工作流形态或 Unity/Unreal 项目的发布自动化，应将这类更宽泛的工作流设计转交给 game-ci-cd-pipeline。
何时使用
- Unity 构建、导入、编译、打包或播放模式启动失败
- Unreal 构建、UBT/UHT、Cook、打包、Shader、插件或模块失败
- 来自游戏项目、原始输出冗长嘈杂的 CI 日志
- 资产移动、重定向器、缺失引用、.meta/GUID、模块或插件损坏
- 用户提供 Editor.log、打包输出、BuildCookRun 日志、堆栈跟踪或控制台片段，并希望获得下一步调试步骤
使用方式
第 1 步：确认引擎与日志范围
检测材料主要是 Unity、Unreal，还是混合/未知。在可见时记录日志来源：
- Unity：Editor.log、Console 输出、包管理器输出、播放器构建输出、CI 转写
- Unreal：UBT/UHT 输出、Cook/打包日志、Output Log、Message Log、崩溃日志、CI 转写
识别时间窗口或失败命令（如存在）。若日志很大，优先关注：包含 error、exception、fatal、failed、UHT、UBT、NullReferenceException、MissingReferenceException、Cook failed、AutomationTool exiting、Script compilation error 的行，以及大量重复后续错误之前的第一个错误簇。
第 2 步：找到第一个可操作故障
自上而下，将根因候选与级联噪音分开。使用以下判断顺序：
- 硬停止/致命行——第一行明确中止运行的内容
- 配置或依赖阻塞——缺失模块、SDK、包、插件、目标或程序集定义
- 编译/反射阻塞——C# 编译器错误、UHT/UBT 错误、宏/反射问题、缺失符号、重复类、循环依赖
- 资产/引用阻塞——缺失资产、重定向器余波、GUID/meta 不匹配、导入错误、损坏的 prefab/Blueprint 引用
- 环境/平台阻塞——Android/iOS/主机 SDK 问题、签名/配置、工具链路径、不支持的目标
- 次要噪音——重复异常、重试或下游“无法完成”消息
不要把 20 个症状总结成 20 个原因。
第 3 步：归类失败桶
将日志映射到一个主桶和可选次桶。主桶包括：compile-code、compile-reflection、asset-reference、package-plugin-config、platform-sdk、build-pipeline-state、runtime-startup、unknown-needs-more-context。
典型 Unity 映射：
- CS0246、CS0103、Assembly has reference to non-existent assembly → compile-code 或 package-plugin-config
- 导入/构建期间 MissingReferenceException、NullReferenceException、GUID/meta 缺失 → asset-reference
- 包管理器解析失败、无效 asmdef 引用、脚本定义不匹配 → package-plugin-config
- Android SDK/JDK/Gradle/Xcode 签名失败 → platform-sdk
典型 Unreal 映射：
- Unable to instantiate module、缺失插件/模块、错误 .Build.cs、目标规则失败 → package-plugin-config
- UHT/UObject/反射宏错误、生成代码问题 → compile-reflection
- Cook failed、缺失内容、重定向器/移动资产余波 → asset-reference 或 build-pipeline-state
- Visual Studio/工具链/SDK/平台打包阻塞 → platform-sdk
第 4 步：产出分诊简报
按以下结构返回简明报告：# Game Log Triage，包含 Engine（Unity | Unreal | Mixed/Unknown）、Log scope（Source、Failing command/stage、Confidence: high | medium | low）、First actionable failure（Line or excerpt、Why it matters、Why later errors look secondary）、Classification（Primary bucket、Secondary bucket）、Most likely root cause（1-3 句基于日志的解释）、Next checks（编号列表）、Files / settings to inspect、Safe follow-up commands（仅可选只读检查命令）。
暂不要做的事：在主阻塞被验证前，避免散弹式清理或大范围删除资产。
第 5 步：按引擎定制下一步检查
Unity 优先检查：
- Packages/manifest.json、Packages/packages-lock.json
- .asmdef 引用与脚本定义符号
- ProjectSettings/、平台构建设置、签名/工具链路径
- 近期资产移动、.meta 文件、GUID 稳定性、prefab/场景引用
- 任何 NullReferenceException 洪流之前的第一个编译器错误
Unreal 优先检查：
- .uproject、插件启用状态、Source//.Build.cs、目标文件
- 打包/Cook 余波之前的第一个 UBT/UHT 错误
- 重定向器、缺失资产、移动的内容、生成代码不匹配
- 平台 SDK/工具链前置条件与 AutomationTool 阶段
- 故障是否始于重命名类/资产或更改模块/插件之后
第 6 步：证据薄弱时谨慎升级
若日志片段太短或从级联中段开始：1) 说明置信度低；2) 请求最早的错误簇或失败命令部分；3) 列出所需的最小额外上下文，包括首个错误前后 50-150 行、引擎版本、目标平台、故障是否紧随代码/包/资产/插件变更。不要凭截断片段假装确定。
输出格式
始终返回简短的调试简报，而非意识流分析。要求：优先定位首个可操作阻塞；区分根因与级联噪音；除用户要求外，报告控制在约 250-400 词；在引擎提示时包含需检查的文件路径/设置；除非用户明确要求修复，shell 建议保持只读。
示例
示例 1：Unity 编译 + 包漂移。输入：更新包后 Unity 构建失败，日志显示 CS0246 找不到 InputSystem，随后数十行 NullReferenceException。输出要点：引擎 Unity；首个可操作故障为 InputSystem 的 CS0246；分类 package-plugin-config；根因是包或 asmdef 引用漂移阻塞编译，后续 null ref 多半是编译/导入失败状态的余波；下一步：确认 Packages/manifest.json 仍包含 Input System 包，检查受影响程序集的 asmdef 引用，验证脚本定义符号或包迁移说明。
示例 2：Unreal 资产移动后 Cook 失败。输入：重命名文件夹后 Cook 开始失败，日志显示 Cook failed 和多个缺失资产警告。输出要点：引擎 Unreal；首个可操作故障为 Cook failed 之前最早缺失资产/重定向器相关行；分类 asset-reference；根因是移动内容可能遗留未修复的损坏引用或重定向器；下一步：检查移动资产路径与重定向器，对日志中引用的缺失资产做只读审计，确认插件/内容路径是否随重命名改变。
示例 3：Unreal UHT 阻塞。输入：重构后 CI 报 UnrealHeaderTool failed。输出要点：引擎 Unreal；首个可操作故障为第一个 UHT 反射/宏错误，而非后续 AutomationTool 退出行；分类 compile-reflection；根因是生成代码阶段的头文件/反射元数据不匹配；下一步：检查所引用头文件与宏用法，对比近期重命名的类或移动的模块，验证所属模块中生成代码的依赖。
最佳实践
- 以最早阻塞点开头——游戏引擎日志级联严重。
- 点明子系统——编译、反射、资产/引用、插件/配置或平台 SDK。
- 优先给出具体检查目标，而非“全部重建”之类泛泛建议。
- 修复以安全为先——先只读命令与定向检查，再考虑破坏性清理。
- 在两种引擎中，资产移动都视为高嫌疑事件。
- 片段不完整或嘈杂时说明置信度。
- 使用团队已有的引擎术语：asmdef、GUID/meta、UBT/UHT、重定向器、BuildCookRun 等。
限制
资料未提供收费、价格、平台支持范围或可用性等信息。该技能依赖用户提供的日志片段；片段过短或从级联中段开始时，无法给出高置信度结论。