各位，

多数时候，我都埋在ML架构、局部推理优化以及与Xcode分配配置文件调试的典型iOS应用中。但这周末，我想要尝试完全不同的东西：纯粹的“感观编码”.

相反于跳上Cursor/web-app的流行之上，我想要看看是否可以使用终端命令行驱动Unity这个重型引擎。如果我能严格作为命令行工程师/架构师，让AI生成C#逻辑，那将是一个完全不同的结果。

**(技术栈 🛠️) **

  • 核心引擎: Unity (针对iOS/App Store)
  • AI助手: gemini-cli (从我自己的终端直接运行)
  • UI框架: Stitch (处理接口层)

(工作流程 💻)

我使用的工作流程简直像科幻小说。如果我在一个监视器上打开了Unity，另一个监视器上打开了终端，我会在终端输入概念性参数要求gemini-cli生成特定的单例管理器（game states）或自定义物理行为脚本。

然后Gemini会输出raw C#生成代码，我会将其粘贴到Unity中，点击运行。如果Unity中发生编译错误，我根本不阅读它。相反的，我直接将Unity控制台中的错误日志复制并粘贴到CLI，然后让Gemini自己解决问题。

使用Stitch，我专注于视觉布局，使用CLI生成数据绑定和事件侦听器脚本以桥接UI和核心Unity逻辑。

(好的 ✅)

  • 零分心率: 使用CLI而不是可集成的AI IDE确保我专注于逻辑生成，无非是输入和输出。
  • 架构优先: 因为我不被语法所困扰，我可以用大脑来理清高层架构，比如优化渲染管道或设计一个干净的事件系统。
  • Stitch集成:使用AI生成UI绑定脚本是一个巨大的时间节省。

(现实检查 ❌)

  • 语境管理窗口:当我的项目越来越大时，维持多个相互依赖的Unity C#脚本在纯CLI环境中的语境成为一个两难的选择。你必须对输入的参数有非常准确的意识。
  • App Store的最终里程碑: AI可以为你写游戏，但它无法 (至少现在还不能) 导航Apple的App Store Connect的绝对迷宫、隐私清单和审查规定。获得最后的审批仍然需要人类苦难的标准方法。

有人在这里尝试使用CLI基于AI工具驱动Unity或者Unreal这样的重型引擎吗？