工具链岗

编辑器扩展和自动化流程是重点

面试回答：

NOTE

编辑器扩展和自动化流程是重点，因为游戏项目不是一个人手写功能就结束了，真正团队开发里有大量资源检查、配置生成、批量处理、自动打包、版本发布和质量拦截。

编辑器扩展解决“人怎么高效生产内容”，比如 EditorWindow、MenuItem、CustomEditor、PropertyDrawer、AssetPostprocessor。自动化流程解决“机器怎么稳定重复执行”，比如资源规范检查、配置表导出、代码生成、AssetBundle/Addressables 打包、CI 构建、出包报告。

加分说法：

“我理解工具链不是炫技，而是把重复劳动和容易出错的流程自动化。比如资源导入时自动设置压缩格式，构建前检查命名和依赖，打包后生成报告。这样能减少人为失误，提高团队交付效率。”

简单编辑器工具示例：

#if UNITY_EDITOR // 只在 Unity 编辑器环境下编译，避免进入运行时包
using UnityEditor; // 引入 Unity 编辑器 API，用来创建菜单和窗口
using UnityEngine; // 引入 Unity 引擎 API，用来使用 Debug 和 GUI

public class AssetCheckWindow : EditorWindow // 定义一个资源检查窗口，继承 EditorWindow
{ // AssetCheckWindow 类开始
    [MenuItem("Tools/Asset Check")] // 在 Unity 顶部菜单添加一个工具入口
    private static void Open() // 定义打开窗口的静态方法
    { // Open 方法开始
        GetWindow<AssetCheckWindow>("Asset Check"); // 创建或显示资源检查窗口
    } // Open 方法结束

    private void OnGUI() // 绘制编辑器窗口界面
    { // OnGUI 方法开始
        GUILayout.Label("Asset Check Tool"); // 显示工具标题
        if (GUILayout.Button("Run Check")) // 绘制检查按钮，并判断是否被点击
        { // if 判断开始
            RunCheck(); // 点击按钮后执行资源检查
        } // if 判断结束
    } // OnGUI 方法结束

    private void RunCheck() // 定义资源检查逻辑
    { // RunCheck 方法开始
        string[] guids = AssetDatabase.FindAssets("t:Texture"); // 查找项目中所有 Texture 资源
        foreach (string guid in guids) // 遍历每一个资源 GUID
        { // foreach 循环开始
            string path = AssetDatabase.GUIDToAssetPath(guid); // 把 GUID 转换成资源路径
            TextureImporter importer = AssetImporter.GetAtPath(path) as TextureImporter; // 获取贴图导入器
            if (importer != null && importer.maxTextureSize > 1024) // 判断贴图是否存在且尺寸限制过大
            { // if 判断开始
                Debug.LogWarning("Texture too large: " + path); // 输出警告，提示这个贴图需要检查
            } // if 判断结束
        } // foreach 循环结束
    } // RunCheck 方法结束
} // AssetCheckWindow 类结束
#endif // 结束编辑器条件编译

资源导入、检查、打包、发布会常问

面试回答：

TIP

资源导入、检查、打包、发布会常问，因为这是一条完整资源管线，决定项目能不能稳定交付、能不能热更新、能不能回滚。

资源导入：重点是命名规范、平台压缩格式、贴图尺寸、模型导入参数、音频加载方式。最好能用 AssetPostprocessor 把规则自动化。

资源检查：重点是构建前拦截问题，比如重复资源、空引用、Missing Reference、依赖丢失、平台格式错误、资源过大。

资源打包：重点是首包、分包、热更包怎么拆，如何分析依赖，如何避免重复打包，如何生成 Manifest、Hash 和版本文件。

资源发布：重点是上传 CDN、版本对比、灰度发布、失败重试、回滚旧版本，以及客户端如何校验资源完整性。

加分说法：

“我会把资源流程拆成导入规范、自动检查、依赖分包、版本发布和线上回滚。重点不是能不能打包，而是结果可追踪、错误可拦截、线上可回滚。”

简单资源检查代码：

#if UNITY_EDITOR // 只在 Unity 编辑器环境编译，避免检查工具进入正式包
using UnityEditor; // 引入 Unity 编辑器 API，用来查找资源和读取导入设置
using UnityEngine; // 引入 Unity 引擎 API，用来输出日志

public static class TextureBuildChecker // 定义一个贴图构建前检查工具类
{ // TextureBuildChecker 类开始
    [MenuItem("Tools/Check Textures Before Build")] // 在 Unity 菜单栏添加一个检查入口
    public static void CheckTextures() // 定义检查贴图资源的方法
    { // CheckTextures 方法开始
        string[] guids = AssetDatabase.FindAssets("t:Texture"); // 查找项目中所有贴图资源的 GUID
        foreach (string guid in guids) // 遍历每一个贴图资源 GUID
        { // foreach 循环开始
            string path = AssetDatabase.GUIDToAssetPath(guid); // 把 GUID 转换成资源路径
            TextureImporter importer = AssetImporter.GetAtPath(path) as TextureImporter; // 获取该资源的贴图导入器
            if (importer == null) // 判断导入器是否为空
            { // if 判断开始
                continue; // 如果不是有效贴图导入器，就跳过
            } // if 判断结束
            if (importer.maxTextureSize > 1024) // 判断贴图最大尺寸是否超过项目规则
            { // if 判断开始
                Debug.LogWarning("Texture size too large: " + path); // 输出警告，提示贴图尺寸过大
            } // if 判断结束
            if (importer.textureCompression == TextureImporterCompression.Uncompressed) // 判断贴图是否没有压缩
            { // if 判断开始
                Debug.LogWarning("Texture is uncompressed: " + path); // 输出警告，提示贴图未压缩
            } // if 判断结束
        } // foreach 循环结束
    } // CheckTextures 方法结束
} // TextureBuildChecker 类结束
#endif // 结束编辑器条件编译

Python/C#/C++ 脚本能力加分

面试回答：

IMPORTANT

Python / C# / C++ 脚本能力是加分项，因为它说明你不只是会写游戏逻辑，还能把重复劳动、资源检查、配置生成、自动打包、日志分析这些工程流程自动化。

Python 适合做批处理，比如配置表导出、日志分析、资源扫描、包体分析、CI 脚本。

C# 适合做 Unity 编辑器扩展，比如 EditorWindow、MenuItem、资源检查、Prefab 批量处理、自动构建。

C++ 适合做底层工具，比如资源格式转换、压缩工具、导入器、引擎插件、性能敏感模块。

加分说法：

“我会根据任务选工具：Python 处理文件和流水线，C# 做 Unity 编辑器工具，C++ 做底层或性能敏感工具。脚本能力的价值不是会几门语言，而是能把团队重复劳动变成稳定、可追踪的自动化流程。”

简单 Python 资源扫描脚本：

import os  # 引入 os 模块，用来遍历文件夹和处理路径

root_dir = "Assets"  # 设置要扫描的资源根目录

for current_dir, sub_dirs, files in os.walk(root_dir):  # 递归遍历资源目录
    for file_name in files:  # 遍历当前目录下的每个文件
        if file_name.endswith(".png"):  # 判断文件是否是 png 贴图
            full_path = os.path.join(current_dir, file_name)  # 拼接完整资源路径
            file_size = os.path.getsize(full_path)  # 获取文件大小，单位是字节
            if file_size > 1024 * 1024:  # 判断贴图是否超过 1MB
                print("Large texture:", full_path, file_size)  # 输出过大的贴图路径和大小

CI/CD、自动构建、版本管理会问

面试回答：

IMPORTANT

CI/CD、自动构建、版本管理会问，因为这代表你有没有工程化意识。游戏项目不是本地点一下 Build 就结束，而是要做到自动检查、稳定构建、产物可追溯、发布可灰度、失败可回滚。

CI 主要是持续集成：提交代码后自动拉取、编译、跑测试、检查资源规则，尽早发现问题。

自动构建主要是命令行打包：自动构建客户端包、资源包、热更包，保存构建日志和报告。

版本管理主要是记录：代码提交号、客户端版本、资源版本、Manifest、Hash、依赖关系，保证线上问题能定位到具体版本。

CD 主要是发布交付：上传资源到 CDN，灰度发布，监控失败率，出问题能回滚旧版本。

加分说法：

“我会把 CI/CD 拆成提交触发、自动检查、客户端构建、资源构建、版本记录、发布和回滚。重点是产物可追溯、流程可重复、失败可定位、线上可回滚。”

简单 Unity 自动构建脚本：

#if UNITY_EDITOR // 只在 Unity 编辑器环境下编译，避免构建脚本进入运行时包
using System; // 引入异常类型，用来在构建失败时抛出错误
using UnityEditor; // 引入 Unity 编辑器 API，用来调用 BuildPipeline
using UnityEditor.Build.Reporting; // 引入构建报告类型，用来读取构建结果

public static class CIBuildScript // 定义 CI 构建脚本类，供命令行调用
{ // CIBuildScript 类开始
    public static void BuildAndroid() // 定义 Android 自动构建入口方法
    { // BuildAndroid 方法开始
        string[] scenes = new[] { "Assets/Scenes/Main.unity" }; // 指定要打进包里的场景列表
        BuildPlayerOptions options = new BuildPlayerOptions(); // 创建 Unity 构建参数对象
        options.scenes = scenes; // 设置构建场景列表
        options.locationPathName = "Builds/Android/Game.apk"; // 设置输出 APK 路径
        options.target = BuildTarget.Android; // 设置构建目标平台为 Android
        options.options = BuildOptions.None; // 设置普通构建模式
        BuildReport report = BuildPipeline.BuildPlayer(options); // 调用 Unity 构建管线开始打包
        if (report.summary.result != BuildResult.Succeeded) // 判断构建结果是否失败
        { // if 判断开始
            throw new Exception("Android build failed"); // 抛出异常，让 CI 任务标记为失败
        } // if 判断结束
    } // BuildAndroid 方法结束
} // CIBuildScript 类结束
#endif // 结束编辑器条件编译

要理解策划、美术、程序协作流程

面试回答：

WARNING

要理解策划、美术、程序协作流程，因为游戏开发不是程序一个人把功能写完，而是需求、资源、实现、联调、验收不断闭环。

策划主要负责玩法规则、数值、流程、配置表和验收标准。美术主要负责模型、贴图、动画、特效、UI 图和资源规范。程序主要负责系统实现、资源接入、工具支持、日志定位和性能保障。

加分说法：

“我会先和策划对齐需求输入、输出、边界和验收标准，再和美术确认资源命名、尺寸、格式、Prefab 层级和动画事件。程序侧会尽量提供编辑器工具、配置检查、预览入口和报错日志，减少反复沟通成本。”

简单配置结构示例：

using UnityEngine; // 引入 Unity 引擎命名空间，用来创建 ScriptableObject 配置资源

[CreateAssetMenu(menuName = "Config/SkillConfig")] // 允许策划在 Unity 菜单中创建技能配置资源
public class SkillConfig : ScriptableObject // 定义技能配置类，用来承接策划、美术、程序协作数据
{ // SkillConfig 类开始
    public int skillId; // 策划填写技能 ID，用来唯一标识一个技能
    public string skillName; // 策划填写技能名称，用来在工具和日志中识别
    public float cooldown; // 策划填写冷却时间，用来驱动技能逻辑
    public GameObject effectPrefab; // 美术提供特效 Prefab，程序在释放技能时实例化或从对象池取出
    public AudioClip castSound; // 美术或音频同学提供释放音效，程序在技能触发时播放
    public string animationTrigger; // 程序和动画约定 Animator 参数名，用来触发技能动画
} // SkillConfig 类结束

要能设计数据表、资源规范、检查规则

面试回答：

要能设计数据表、资源规范、检查规则，因为这是游戏项目内容生产的基础。数据表负责驱动玩法，资源规范负责保证内容稳定接入，检查规则负责把错误提前拦截在构建前。

怎么讲：

数据表设计要关注：ID 唯一、字段语义清晰、类型明确、默认值合理、引用关系可校验、版本兼容。配置表只放数据，不要把复杂业务逻辑塞进表里。

资源规范要关注：命名、目录、尺寸、格式、压缩、平台差异、Prefab 层级、动画事件、资源引用路径。规范不是为了好看，而是为了能批量处理、自动检查、稳定打包。

检查规则要关注：空字段、重复 ID、类型错误、资源不存在、Missing Reference、贴图过大、未压缩、循环依赖、重复打包。严重错误要阻断构建，普通问题输出 Warning 和报告。

加分说法：

“我会先和策划确认表字段语义，再和美术确认资源命名和导入规范，最后把 ID、类型、引用、尺寸、压缩、依赖这些规则做成自动检查，并接入编辑器工具和 CI。”

简单检查代码：

#if UNITY_EDITOR // 只在 Unity 编辑器环境下编译，避免检查工具进入运行时包
using UnityEditor; // 引入 Unity 编辑器 API，用来查找和读取资源
using UnityEngine; // 引入 Unity 引擎 API，用来输出日志

public static class AssetRuleChecker // 定义资源规则检查工具类
{ // AssetRuleChecker 类开始
    [MenuItem("Tools/Check Asset Rules")] // 在 Unity 菜单栏添加资源规则检查入口
    public static void Check() // 定义执行检查的方法
    { // Check 方法开始
        string[] textureGuids = AssetDatabase.FindAssets("t:Texture"); // 查找项目中所有贴图资源
        foreach (string guid in textureGuids) // 遍历每一个贴图 GUID
        { // foreach 循环开始
            string path = AssetDatabase.GUIDToAssetPath(guid); // 把 GUID 转换成资源路径
            TextureImporter importer = AssetImporter.GetAtPath(path) as TextureImporter; // 获取贴图导入设置
            if (importer == null) // 判断导入器是否为空
            { // if 判断开始
                continue; // 如果不是有效贴图导入器，就跳过
            } // if 判断结束
            if (!path.StartsWith("Assets/Art/")) // 判断贴图是否放在规定目录下
            { // if 判断开始
                Debug.LogWarning("Texture path is not standard: " + path); // 输出目录不规范警告
            } // if 判断结束
            if (importer.maxTextureSize > 1024) // 判断贴图尺寸上限是否超过规范
            { // if 判断开始
                Debug.LogWarning("Texture size is too large: " + path); // 输出贴图过大警告
            } // if 判断结束
        } // foreach 循环结束
    } // Check 方法结束
} // AssetRuleChecker 类结束
#endif // 结束编辑器条件编译

要能减少重复劳动和人为错误

面试回答：

CAUTION

要能减少重复劳动和人为错误，因为这体现的是工程化能力。真正有价值的工具不是“写起来很酷”，而是能让团队少点重复按钮、少手动改配置、少因为忘步骤导致出包失败。

常见做法是：把重复流程自动化，把容易填错的地方规则化，把检查结果报告化，把严重问题构建前阻断。

加分说法：

“我会先找团队里重复发生的痛点，比如资源命名不规范、配置表引用错误、打包步骤容易漏、版本号忘记更新。然后把这些规则做成编辑器工具或 CI 检查，让错误提前暴露，而不是等到运行时或上线后才发现。”

简单示例：检查配置 ID 是否重复

using System.Collections.Generic; // 引入 HashSet，用来记录已经出现过的 ID
using UnityEngine; // 引入 Unity 引擎命名空间，用来输出日志

public static class ConfigIdChecker // 定义配置 ID 检查工具类
{ // ConfigIdChecker 类开始
    public static void CheckIds(List<int> ids) // 定义检查 ID 是否重复的方法
    { // CheckIds 方法开始
        HashSet<int> visited = new HashSet<int>(); // 创建集合，用来保存已经检查过的 ID
        foreach (int id in ids) // 遍历配置表中的每一个 ID
        { // foreach 循环开始
            if (visited.Contains(id)) // 判断当前 ID 是否已经出现过
            { // if 判断开始
                Debug.LogError("Duplicate config id: " + id); // 输出错误，提示配置 ID 重复
                continue; // 跳过当前重复 ID，继续检查后面的数据
            } // if 判断结束
            visited.Add(id); // 把当前 ID 记录下来，供后续检查使用
        } // foreach 循环结束
    } // CheckIds 方法结束
} // ConfigIdChecker 类结束

要讲清楚工具如何服务生产效率

面试回答：

TIP

工具要讲清楚如何服务生产效率。不要只说“我做了一个工具”，而要说它解决了谁的问题、缩短了哪条流程、减少了哪些错误、最终带来了什么收益。

比如给策划用的工具，可以做配置表校验、效果预览、自动导出，减少找程序反复确认。给美术用的工具，可以做资源命名检查、贴图尺寸检查、导入参数自动设置。给程序用的工具，可以做代码生成、资源依赖分析、自动打包和错误报告。

加分说法：

“我做工具时会先找团队痛点，比如重复导表、资源命名错误、构建前才发现引用丢失。然后把流程标准化、工具化，并接入编辑器或 CI。最后用数据证明收益，比如原来手动检查 30 分钟，现在一键 1 分钟完成，还能提前拦截错误。”

简单示例：统计工具节省时间

using UnityEngine; // 引入 Unity 引擎命名空间，用来输出日志
using System.Diagnostics; // 引入 Stopwatch，用来统计工具执行耗时

public static class ToolEfficiencyDemo // 定义工具效率统计示例类
{ // ToolEfficiencyDemo 类开始
    public static void RunTool() // 定义工具执行入口
    { // RunTool 方法开始
        Stopwatch watch = Stopwatch.StartNew(); // 启动计时器，用来记录工具执行时间
        CheckAssets(); // 执行资源检查逻辑
        watch.Stop(); // 停止计时器
        UnityEngine.Debug.Log("Tool cost ms: " + watch.ElapsedMilliseconds); // 输出工具耗时，方便对比人工流程
    } // RunTool 方法结束

    private static void CheckAssets() // 定义资源检查方法
    { // CheckAssets 方法开始
        UnityEngine.Debug.Log("Check asset naming, size and references."); // 模拟检查资源命名、尺寸和引用
    } // CheckAssets 方法结束
} // ToolEfficiencyDemo 类结束

要关注错误提示、可视化、可维护性

面试回答：

IMPORTANT

要关注错误提示、可视化、可维护性，因为工具不是“能跑就行”，而是要让使用者知道哪里错、怎么看、怎么修，以后别人接手也能改得动。

错误提示要清楚：最好包含文件路径、字段名、错误原因、修复建议和错误等级。比如不要只提示 Build Failed，而要提示 SkillConfig.xlsx 第 12 行 skillId 重复，建议检查 ID 分配。

可视化要直观：比如进度条、错误列表、资源预览、依赖图、点击跳转、错误高亮。这样策划和美术也能自己定位问题，不必所有事情都找程序。

可维护性要考虑：规则模块化、界面和逻辑分离、配置可扩展、日志清晰、文档简单。否则工具一开始很好用，后面需求一变就没人敢改。

加分说法：

“我做工具时不会只关注功能能不能跑，还会关注使用者体验和长期维护。错误提示要能定位问题，可视化要降低理解成本，规则设计要方便扩展，这样工具才能真正服务团队效率。”

简单错误结果结构：

public enum CheckLevel // 定义检查结果等级，用来区分错误严重程度
{ // CheckLevel 枚举开始
    Warning, // Warning 表示警告，可以提示但不一定阻断构建
    Error // Error 表示严重错误，通常需要阻断构建
} // CheckLevel 枚举结束

public class CheckResult // 定义检查结果类，用来保存一条工具检查信息
{ // CheckResult 类开始
    public CheckLevel Level; // 保存错误等级，方便界面用不同颜色显示
    public string FilePath; // 保存出错文件路径，方便用户定位资源或表格
    public string FieldName; // 保存出错字段名，方便用户知道具体哪里有问题
    public string Reason; // 保存错误原因，告诉用户为什么错
    public string FixSuggestion; // 保存修复建议，告诉用户下一步应该怎么改
} // CheckResult 类结束

项目里有实际工具最加分

面试回答：

NOTE

项目里有实际工具最加分，因为它证明你真的解决过团队效率问题，而不是只会讲编辑器扩展概念。

最好准备这类工具：资源检查工具、配置表导出工具、自动打包工具、Prefab 批处理工具、日志分析工具、运行时调试面板。面试时不要只说“我写了一个按钮”，而要讲清楚：为什么做、谁在用、流程怎么变短、错误怎么提前暴露、最后带来了什么收益。

加分说法：

“我项目里做过一个资源检查工具，用来在构建前检查贴图尺寸、压缩格式、命名规范和丢失引用。它不是单纯一个菜单按钮，而是能输出报告、定位到具体资源，并接入打包前流程。这样美术和程序都能更早发现问题，减少出包失败。”

简单工具代码示例：

#if UNITY_EDITOR // 只在 Unity 编辑器环境编译，避免工具代码进入运行时包
using UnityEditor; // 引入 Unity 编辑器 API，用来查找资源和创建菜单
using UnityEngine; // 引入 Unity 引擎 API，用来输出检查日志

public static class ProjectAssetTool // 定义项目资源工具类
{ // ProjectAssetTool 类开始
    [MenuItem("Tools/Project/Check Large Textures")] // 在 Unity 菜单栏添加检查大贴图的工具入口
    public static void CheckLargeTextures() // 定义检查大贴图的方法
    { // CheckLargeTextures 方法开始
        string[] guids = AssetDatabase.FindAssets("t:Texture"); // 查找项目中所有贴图资源的 GUID
        foreach (string guid in guids) // 遍历每一个贴图 GUID
        { // foreach 循环开始
            string path = AssetDatabase.GUIDToAssetPath(guid); // 把 GUID 转换成资源路径
            TextureImporter importer = AssetImporter.GetAtPath(path) as TextureImporter; // 获取贴图导入器
            if (importer == null) // 判断导入器是否为空
            { // if 判断开始
                continue; // 如果不是有效贴图导入器，就跳过
            } // if 判断结束
            if (importer.maxTextureSize > 1024) // 判断贴图最大尺寸是否超过规范
            { // if 判断开始
                Debug.LogWarning("Large texture: " + path); // 输出警告，并显示具体资源路径
            } // if 判断结束
        } // foreach 循环结束
    } // CheckLargeTextures 方法结束
} // ProjectAssetTool 类结束
#endif // 结束编辑器条件编译