如果你是一名Unity开发者，最近是否感觉工作流被各种AI工具和协议“包围”了？从Cursor的智能补全，到Claude的对话编程，再到各种宣称能连接一切的MCP（Model Context Protocol）服务器，新技术层出不穷。但你是否也遇到了这样的困扰：配置复杂、工具链断裂、不同AI助手之间切换成本高，甚至因为环境问题导致“claude命令在PowerShell中无法找到”？
本文要讨论的，正是这样一个被许多开发者忽视，但可能更简洁高效的替代方案：用统一的CLI（命令行界面）工具，来整合和管理你的AI辅助开发工作流，尤其是在Unity项目中。
一个明确的判断是：对于大多数Unity开发者而言，盲目追逐每一个新的MCP工具或AI Agent框架，其边际收益正在递减。真正的效率提升，来自于建立一个稳定、可脚本化、且深度融入现有开发环境（如Unity Editor、终端、版本控制）的自动化流程。一个设计良好的CLI，恰恰能成为这个流程的“粘合剂”和“控制器”。
读完本文，你将能清晰地理解：
- MCP的定位与局限：它解决了什么问题，又在Unity日常开发中带来了哪些新负担？
- CLI的不可替代优势：为什么在自动化、批处理和工程集成方面，CLI常常是更优解？
- 实战方案：如何为你的Unity项目构建或选用一个CLI工具，来自动化资源处理、代码生成、项目配置等高频任务。
- 避坑指南：从环境配置到生产部署，有哪些必须注意的细节？
我们不止于比较概念，更会提供可立即上手的代码示例和工程实践，帮你从“被工具折腾”转向“用工具创造”。
1. 重新审视你的工具链：MCP 与 CLI 的核心分野
在深入实操之前，我们必须先理清MCP和CLI的根本区别。这并非要否定MCP，而是为了让你根据实际场景做出更明智的选择。
MCP（Model Context Protocol）是什么？你可以把它理解为大模型（如Claude、GPT）的“外挂设备”标准接口。一个MCP服务器就像一个专门的插件，为AI助手提供访问特定工具或数据的能力，比如读取数据库、操作Figma设计稿、调用内部API。它的核心价值是为对话式AI提供动态的、结构化的上下文和能力扩展。
但在Unity开发中，MCP可能带来如下负担：
- 配置复杂度：每个MCP服务器都需要独立安装、配置和运行，可能涉及环境变量、网络端口、认证令牌等。
- 稳定性与依赖：MCP服务器的运行状态直接影响AI助手的功能。一旦服务器崩溃或更新不兼容，相关功能即刻失效。
- 上下文局限：MCP交互通常发生在AI助手的单次会话中，难以与复杂的、多步骤的Unity工程自动化流程（如完整的构建打包、资源管线）深度集成。
- 调试困难：问题可能出现在AI助手、MCP协议层或服务器实现中的任何一环，排查链条较长。
CLI（命令行界面）的不可替代性体现在哪里？CLI工具的本质是一个可执行程序，它通过标准输入输出、参数、退出码与系统交互。在Unity开发自动化中，它的优势是压倒性的：
- 无状态与可脚本化：CLI命令可以轻松写入Shell脚本（Bash、PowerShell）、Makefile、CI/CD流水线（如Jenkins、GitHub Actions）中，形成可重复、可版本控制的自动化流程。
- 深度工程集成：Unity自身就提供了强大的命令行接口（
Unity.exe -batchmode -quit -executeMethod）。你的自定义CLI可以封装Unity Editor API调用、与版本控制系统（Git）交互、调用资产管道等。 - 明确的输入输出：参数驱动，结果通过标准输出、错误流或文件明确返回，易于日志记录、监控和错误处理。
- 环境隔离简单：通常只需要确保可执行文件在
PATH中，或使用绝对路径调用，依赖管理相对清晰。
结论：如果你的需求是“让AI助手在聊天窗口中能帮我做一件特定的事”，MCP是优雅的方案。但如果你的目标是“为我的Unity项目建立一套可靠、可调度、与团队协作流程兼容的自动化体系”，那么投资一个设计良好的CLI工具，回报率会高得多。很多场景下，你甚至可以用CLI构建出功能，再通过一个简单的MCP服务器将其“暴露”给AI助手，从而兼得两者之长。
2. 环境准备：为Unity CLI开发搭建基石
在开始构建CLI之前，我们需要一个稳定、可复现的开发环境。以下方案以跨平台的.NET Core（或.NET 8+）为例，因为这与Unity的底层运行时（C#）同源，共享库和工具链最为方便。
2.1 基础环境配置
安装 .NET SDK：
- 前往 .NET 官方网站 下载并安装最新长期支持（LTS）版本的SDK。这将提供
dotnet命令行工具。 - 验证安装：
dotnet --version # 应输出类似 8.0.201 的版本号
- 前往 .NET 官方网站 下载并安装最新长期支持（LTS）版本的SDK。这将提供
安装或确认Unity环境：
- 确保你用于开发的Unity Editor已安装。记下其安装路径（如
C:\Program Files\Unity\Hub\Editor\2022.3.31f1\Editor\Unity.exe）。 - 关键步骤：将Unity Editor的安装目录（包含
Unity.exe的目录）添加到系统的PATH环境变量中。这能让你在终端中直接使用Unity命令。- Windows：在系统环境变量
PATH中添加路径。 - macOS/Linux：在
~/.bashrc或~/.zshrc中添加export PATH="$PATH:/Applications/Unity/Hub/Editor/2022.3.31f1/Unity.app/Contents/MacOS"（路径需替换）。
- Windows：在系统环境变量
- 确保你用于开发的Unity Editor已安装。记下其安装路径（如
选择代码编辑器：
- Visual Studio 2022/Code 或 JetBrains Rider 均可，它们对C#和.NET CLI项目都有优秀支持。
2.2 创建你的第一个Unity辅助CLI项目
我们从一个最简单的需求开始：创建一个CLI工具，它能接收项目路径，并输出该Unity项目的基本信息（如Unity版本、包含的场景列表）。
打开终端，执行以下命令：
# 1. 创建一个新的控制台应用项目，并命名为 UnityProjectScanner dotnet new console -n UnityProjectScanner -f net8.0 # 2. 进入项目目录 cd UnityProjectScanner # 3. 添加一个用于解析命令行参数的流行库（System.CommandLine 已集成在.NET 8+模板中，但为演示我们显式添加其增强功能包） dotnet add package System.CommandLine项目创建后，你的目录结构应类似于：
UnityProjectScanner/ ├── UnityProjectScanner.csproj ├── Program.cs └── (其他配置文件)3. 核心流程拆解：构建一个项目扫描CLI
让我们一步步实现这个UnityProjectScanner工具。
3.1 定义命令与参数
修改Program.cs文件，使用System.CommandLine来定义CLI的界面。
// Program.cs using System.CommandLine; using System.CommandLine.Invocation; using System.CommandLine.Parsing; using System.Diagnostics; class Program { static async Task<int> Main(string[] args) { // 定义根命令 var rootCommand = new RootCommand("一个用于扫描Unity项目信息的CLI工具。"); // 定义一个选项，用于指定Unity项目路径（文件夹） var projectPathOption = new Option<DirectoryInfo>( name: "--project-path", description: "Unity项目的根目录路径。", getDefaultValue: () => new DirectoryInfo(Directory.GetCurrentDirectory()) // 默认当前目录 ) { IsRequired = false }; projectPathOption.AddAlias("-p"); // 添加短别名 rootCommand.AddOption(projectPathOption); // 定义一个命令，用于扫描项目信息 var scanCommand = new Command("scan", "扫描并显示Unity项目信息"); scanCommand.AddOption(projectPathOption); rootCommand.AddCommand(scanCommand); // 为scan命令设置处理逻辑 scanCommand.SetHandler(async (projectPath, context) => { await HandleScanCommand(projectPath, context); }, projectPathOption); // 解析并执行命令行参数 return await rootCommand.InvokeAsync(args); } static async Task HandleScanCommand(DirectoryInfo projectPath, InvocationContext context) { // 验证路径是否存在且是一个Unity项目 if (!projectPath.Exists) { context.Console.Error.WriteLine($"错误：项目路径 '{projectPath.FullName}' 不存在。"); context.ExitCode = 1; return; } var projectSettingsPath = Path.Combine(projectPath.FullName, "ProjectSettings", "ProjectVersion.txt"); if (!File.Exists(projectSettingsPath)) { context.Console.Error.WriteLine($"错误：在 '{projectPath.FullName}' 中未找到ProjectSettings/ProjectVersion.txt，这可能不是一个有效的Unity项目。"); context.ExitCode = 2; return; } // 读取Unity版本 var versionText = await File.ReadAllTextAsync(projectSettingsPath); var unityVersion = versionText.Split(':')[1]?.Trim(); // 查找Assets目录下的所有场景文件 (.unity) var assetsDir = Path.Combine(projectPath.FullName, "Assets"); var sceneFiles = Directory.Exists(assetsDir) ? Directory.GetFiles(assetsDir, "*.unity", SearchOption.AllDirectories) : Array.Empty<string>(); // 输出结果 context.Console.Out.WriteLine($"=== Unity项目扫描报告 ==="); context.Console.Out.WriteLine($"项目路径: {projectPath.FullName}"); context.Console.Out.WriteLine($"Unity版本: {unityVersion}"); context.Console.Out.WriteLine($"发现场景数量: {sceneFiles.Length}"); if (sceneFiles.Length > 0) { context.Console.Out.WriteLine("场景列表:"); foreach (var scene in sceneFiles) { // 输出相对路径，更清晰 var relativePath = Path.GetRelativePath(assetsDir, scene); context.Console.Out.WriteLine($" - {relativePath}"); } } context.Console.Out.WriteLine("=== 扫描完成 ==="); } }3.2 编译与本地测试
在项目根目录执行：
# 编译项目 dotnet build # 运行测试：扫描当前目录（假设当前目录是一个Unity项目） dotnet run -- scan -p . # 或者指定路径 dotnet run -- scan --project-path "D:\MyUnityGame"如果一切正常，你将看到类似以下的输出：
=== Unity项目扫描报告 === 项目路径: D:\MyUnityGame Unity版本: 2022.3.31f1 发现场景数量: 3 场景列表: - Scenes/MainMenu.unity - Scenes/Level01.unity - Scenes/Level02.unity === 扫描完成 ===3.3 发布为独立可执行文件
为了让CLI工具便于分享和在任意目录使用，我们需要将其发布为独立应用。
# 发布为当前系统（例如win-x64）的独立可执行文件 dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -o ./publish # 其他常见运行时标识符（RID）： # - linux-x64 # - osx-arm64 (Apple Silicon Mac) # - osx-x64 (Intel Mac)发布后，在./publish目录下会生成一个独立的UnityProjectScanner.exe（Windows）文件。你可以：
- 将其复制到任何目录直接运行。
- 将其所在目录添加到系统的
PATH环境变量中，之后就可以在任意位置使用UnityProjectScanner scan -p ...命令了。
4. 进阶实战：封装Unity Editor API执行复杂任务
上面的例子仅能读取项目文件。更强大的功能需要与Unity Editor运行时交互。这可以通过Unity的批处理模式（Batchmode）和静态方法执行来实现。
假设我们需要一个CLI命令，它能一键为项目中的所有材质球批量执行一次“Apply”操作（例如，应用材质属性到所有材质变体）。这需要在Unity Editor内执行代码。
4.1 创建Editor脚本
首先，在你的Unity项目中（或在一个专门用于CLI工具集的Unity项目中），创建一个Editor脚本。
// 文件路径：Assets/Editor/BatchMaterialProcessor.cs using UnityEditor; using UnityEngine; using System.IO; using System.Collections.Generic; public static class BatchMaterialProcessor { // 这是一个可以从命令行调用的静态方法 public static void ProcessAllMaterialsInProject() { Debug.Log("[CLI] 开始批量处理材质球..."); // 查找所有材质球 string[] materialGuids = AssetDatabase.FindAssets("t:Material"); List<string> processedMaterials = new List<string>(); foreach (var guid in materialGuids) { string path = AssetDatabase.GUIDToAssetPath(guid); Material mat = AssetDatabase.LoadAssetAtPath<Material>(path); if (mat != null) { // 核心操作：强制保存材质资产，这会触发“Apply” EditorUtility.SetDirty(mat); processedMaterials.Add(path); } } // 保存所有更改 AssetDatabase.SaveAssets(); Debug.Log($"[CLI] 批量处理完成。共处理了 {processedMaterials.Count} 个材质球。"); // 可以将处理列表输出到文件，供CLI工具读取 string reportPath = Path.Combine(Application.dataPath, "../MaterialProcessReport.txt"); File.WriteAllLines(reportPath, processedMaterials); Debug.Log($"[CLI] 处理报告已保存至: {reportPath}"); } }4.2 扩展CLI工具以调用Unity Editor
现在，我们需要修改之前的CLI工具，让它能够启动Unity批处理模式并执行我们定义的静态方法。
// 在之前的 Program.cs 的 HandleScanCommand 方法后，添加一个新的命令和处理函数 // 首先，在Main函数中添加新命令 var batchProcessCommand = new Command("batch-process", "在批处理模式下执行Unity Editor任务（如处理材质）"); batchProcessCommand.AddOption(projectPathOption); rootCommand.AddCommand(batchProcessCommand); batchProcessCommand.SetHandler(async (projectPath, context) => { await HandleBatchProcessCommand(projectPath, context); }, projectPathOption); // 然后，实现处理函数 static async Task HandleBatchProcessCommand(DirectoryInfo projectPath, InvocationContext context) { // 1. 验证项目路径 var projectSettingsPath = Path.Combine(projectPath.FullName, "ProjectSettings", "ProjectVersion.txt"); if (!File.Exists(projectSettingsPath)) { context.Console.Error.WriteLine($"错误：无效的Unity项目路径。"); context.ExitCode = 1; return; } // 2. 确定Unity可执行文件路径（假设已添加到PATH） string unityExe = "Unity"; // 如果在Windows上且未在PATH中，可以尝试默认路径（需根据实际情况调整） if (Environment.OSVersion.Platform == PlatformID.Win32NT) { unityExe = "Unity.exe"; } // 3. 构建命令行参数 // -batchmode: 以批处理模式运行，不显示界面，执行完成后自动退出。 // -quit: 执行完毕后退出Unity。 // -projectPath: 指定要打开的项目。 // -executeMethod: 指定要执行的静态方法（完整类名.方法名）。 string arguments = $"-batchmode -quit -projectPath \"{projectPath.FullName}\" -executeMethod BatchMaterialProcessor.ProcessAllMaterialsInProject"; context.Console.Out.WriteLine($"正在启动Unity批处理模式执行任务..."); context.Console.Out.WriteLine($"命令: {unityExe} {arguments}"); // 4. 启动进程 using var process = new Process(); process.StartInfo.FileName = unityExe; process.StartInfo.Arguments = arguments; process.StartInfo.UseShellExecute = false; process.StartInfo.RedirectStandardOutput = true; process.StartInfo.RedirectStandardError = true; process.StartInfo.CreateNoWindow = true; var outputBuilder = new StringBuilder(); var errorBuilder = new StringBuilder(); process.OutputDataReceived += (sender, e) => { if (!string.IsNullOrEmpty(e.Data)) { outputBuilder.AppendLine(e.Data); context.Console.Out.WriteLine($"[Unity] {e.Data}"); // 实时输出日志 } }; process.ErrorDataReceived += (sender, e) => { if (!string.IsNullOrEmpty(e.Data)) { errorBuilder.AppendLine(e.Data); context.Console.Error.WriteLine($"[Unity Error] {e.Data}"); } }; process.Start(); process.BeginOutputReadLine(); process.BeginErrorReadLine(); await process.WaitForExitAsync(); context.Console.Out.WriteLine($"Unity进程已退出，代码: {process.ExitCode}"); // 5. 检查输出和结果 string reportPath = Path.Combine(projectPath.FullName, "MaterialProcessReport.txt"); if (File.Exists(reportPath)) { var lines = await File.ReadAllLinesAsync(reportPath); context.Console.Out.WriteLine($"批量处理完成。共处理 {lines.Length} 个材质。报告文件: {reportPath}"); // 可选：删除报告文件 // File.Delete(reportPath); } else if (process.ExitCode != 0) { context.Console.Error.WriteLine($"处理可能失败。Unity输出日志中可能包含错误信息。"); context.ExitCode = process.ExitCode; } }4.3 运行进阶命令
- 确保
BatchMaterialProcessor.cs脚本位于目标Unity项目的Assets/Editor/目录下。 - 编译并发布你的CLI工具。
- 在命令行中执行：
UnityProjectScanner batch-process -p "D:\MyUnityGame"你将看到Unity以无界面模式启动，执行脚本中的方法，处理所有材质球，然后自动退出。CLI工具会捕获并显示Unity的日志输出，并在最后给出处理结果的报告。
5. 运行结果与效果验证
一个健壮的CLI工具，其输出结果必须是明确且可验证的。以上述两个命令为例：
对于
scan命令：- 成功验证：控制台输出包含项目路径、正确的Unity版本号、场景数量及列表。退出码（Exit Code）为0。
- 失败验证：
- 路径不存在：输出错误信息，退出码为非0（我们设置为1）。
- 非Unity项目：输出错误信息，退出码为非0（我们设置为2）。
- 你可以将输出重定向到文件，用于生成项目文档或报告：
UnityProjectScanner scan -p . > project_info.txt
对于
batch-process命令：- 成功验证：
- 控制台输出显示Unity启动并执行了目标方法（看到
[CLI] 开始批量处理...和[CLI] 批量处理完成...的日志）。 - 在项目根目录生成了
MaterialProcessReport.txt文件，其中列出了所有被处理的材质球路径。 - Unity进程退出码为0（通常表示成功）。
- 控制台输出显示Unity启动并执行了目标方法（看到
- 失败验证：
- 如果
-executeMethod指定的方法不存在或编译错误，Unity会输出错误日志，且退出码通常为非0。CLI工具会捕获这些错误信息。 - 如果项目路径错误，CLI工具会在启动Unity前就报错。
- 通过检查报告文件是否存在以及Unity的退出码，可以明确判断任务是否成功执行。
- 如果
- 成功验证：
6. 常见问题与排查思路
在开发和运行此类CLI工具时，你可能会遇到以下典型问题：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
运行dotnet run或可执行文件时报“未找到命令” | 1. .NET SDK未安装或未在PATH中。 2. 可执行文件不在当前目录或PATH中。 | 1. 运行dotnet --version验证。2. 使用 ./UnityProjectScanner（Linux/macOS）或.\UnityProjectScanner.exe（Windows）显式指定路径。 | 1. 安装或修复.NET SDK环境变量。 2. 将工具发布为独立文件并配置PATH。 |
scan命令找不到ProjectVersion.txt | 1. 指定的路径不是Unity项目根目录。 2. 项目损坏。 | 1. 确认路径包含Assets和ProjectSettings文件夹。2. 手动检查 ProjectSettings文件夹内容。 | 确保提供正确的项目根目录路径。 |
batch-process命令启动Unity失败 | 1. Unity可执行文件未在系统PATH中。 2. Unity安装路径包含空格或特殊字符，导致命令行解析错误。 | 1. 在命令行直接输入Unity或Unity.exe看是否能启动。2. 检查CLI代码中 process.StartInfo.FileName，可尝试使用完整路径。 | 1. 将Unity安装目录添加到PATH。 2. 在CLI代码中使用 UnityEditor.的完整路径（如C:\...\Unity.exe），并用引号包裹。 |
| Unity批处理模式执行后无任何输出或报告 | 1.-executeMethod指定的方法名错误（大小写、命名空间）。2. Editor脚本有编译错误。 3. 方法不是 static和public的。 | 1. 检查Unity Editor的Console窗口（如果非批处理模式运行）是否有编译错误。 2. 在方法内增加更详细的 Debug.Log。3. 确保类和方法都是 public static。 | 1. 修正方法签名和调用名称。 2. 先在Unity Editor内手动执行该方法，确保其正常工作。 |
| 处理大量资产时CLI工具卡住或无响应 | 1. Unity批处理任务本身耗时很长。 2. 进程输出缓冲区阻塞。 | 1. 观察CPU和内存占用。 2. 在CLI代码中确保正确异步读取输出流（如示例中的 BeginOutputReadLine）。 | 1. 在Editor脚本中分帧或分批次处理资产，并输出进度日志。 2. 确保CLI工具正确处理了输出和错误流的重定向。 |
| 权限错误（如无法写入报告文件） | 1. 项目目录为只读。 2. 当前用户权限不足。 | 1. 检查目标目录的读写权限。 2. 尝试以管理员/root身份运行（不推荐，应解决根本权限问题）。 | 1. 修改项目目录权限。 2. 将输出文件改写到有权限的临时目录。 |
7. 最佳实践与工程建议
将CLI工具投入个人或团队生产环境，需要遵循一些工程最佳实践：
清晰的命令结构与帮助文档：
- 使用
System.CommandLine等库来定义具有子命令、选项、描述和示例的清晰结构。 - 务必实现
--help或-h参数，自动生成使用说明。
UnityProjectScanner --help UnityProjectScanner scan --help- 使用
完善的日志与错误处理：
- 不要仅依赖控制台输出。集成如
Serilog或Microsoft.Extensions.Logging的日志框架，支持文件、控制台等多种输出，并区分Information、Warning、Error等级别。 - 对可能失败的操作（如文件IO、网络请求、进程调用）进行
try-catch，并提供有意义的错误信息。
- 不要仅依赖控制台输出。集成如
配置化管理：
- 将可配置项（如默认Unity路径、处理规则、排除列表）提取到
appsettings.json或环境变量中。 - 使用
IConfiguration模式来管理配置，便于不同环境（开发、测试、生产）切换。
- 将可配置项（如默认Unity路径、处理规则、排除列表）提取到
单元测试与集成测试：
- 为CLI工具的核心逻辑（如路径解析、参数验证、业务逻辑）编写单元测试。
- 创建小型测试Unity项目，用于集成测试
batch-process等需要与Unity交互的命令。
与CI/CD管道集成：
- 这是CLI工具价值最大化的地方。将工具集成到GitHub Actions、GitLab CI或Jenkins中。
- 示例（GitHub Actions）：
- name: Scan Unity Project run: | dotnet tool install --global MyUnityCliTool # 或使用已发布的独立可执行文件 MyUnityCliTool scan --project-path ./MyGame --output-format json > scan_results.json - name: Batch Process Assets run: | MyUnityCliTool batch-process --project-path ./MyGame --target-textures # 注意：CI环境中通常需要无界面的Unity授权版本。安全性：
- 永远不要在生产环境中硬编码密钥或敏感信息。使用安全的秘密管理服务（如GitHub Secrets、Azure Key Vault）。
- 对用户输入（如项目路径）进行严格的验证和清理，防止路径遍历攻击。
版本化与分发：
- 使用语义化版本（SemVer）为你的CLI工具打标签。
- 通过NuGet（
dotnet tool）分发是.NET生态中的标准方式，极大简化了安装和更新。 - 也可以将独立可执行文件发布在GitHub Releases，供不同平台用户下载。
8. 总结：从CLI出发，构建你的高效自动化生态
回到最初的问题：在Unity开发中，是追逐每个新的MCP工具，还是回归CLI？答案并非二选一，而是以CLI为基石，让MCP成为可选的、轻量的交互前端。
通过本文的实践，你已经掌握了如何创建一个能深度操作Unity项目的CLI工具。它的价值远不止于扫描项目或处理材质。你可以将其扩展为：
- 资产管道工具：自动导入、优化、校验纹理和模型。
- 版本与发布工具：一键切换版本、打AssetBundle、生成不同平台的构建。
- 代码质量工具：运行单元测试、静态代码分析、生成API文档。
- 团队协作工具：检查项目设置一致性、预提交钩子（pre-commit hooks）。
当你拥有这样一套稳定可靠的CLI工具集后，如果你仍希望AI助手（如Cursor、Claude）能通过自然语言调用它们，那么为其编写一个简单的MCP服务器将变得水到渠成。这个MCP服务器只需作为“翻译官”，将AI的请求转换为对你现有CLI工具的调用。这样，你既享受了AI交互的便利，又无需将核心自动化逻辑绑定在某个不稳定的MCP生态上。
下一步学习方向：
- 深入学习
System.CommandLine库，打造更专业的命令行体验。 - 研究Unity Editor Scripting API，发掘更多可自动化的场景。
- 了解如何将你的CLI工具打包为NuGet包（
dotnet pack），方便团队共享。 - 探索在CI/CD中运行Unity和CLI工具的最佳实践，特别是处理许可证和无头模式运行。
工具的本质是延伸开发者的能力。与其被纷繁的工具定义工作流，不如用扎实的自动化脚本定义你的工具。从这个角度看，一个精心设计的CLI，可能就是你在Unity开发中最高效的“伙伴”。
