游戏的迭代速度，最终由一个循环的周长决定：从改动一行代码，到在真机上看到这行改动的后果。中间隔着构建、签名、部署、复现、抓帧与归因，每一环换一个工具，每一次换手都在消耗工程师的一天。这篇文章讲我们如何把这个循环本身做成基础设施，以及当 AI 接管循环时，它凭什么被信任。
循环有多长，游戏就有多难改
一个多端游戏团队的普通下午大概是这样的：改一行 C++，等一次几十分钟的构建；打包、签名，装到 iOS 真机上；手工把问题场景走一遍，确认帧率确实掉了；换到另一台机器抓一帧 GPU，把截图发给图形程序员；对方看完给出一个猜测，于是再来一轮。循环以小时计，一天转不了几圈。
通用 AI 编码工具解决不了这个问题，因为它们与工程系统脱节：不了解构建系统、摸不到真机、看不见 GPU，无法对「为什么这帧掉到 22ms」给出有证据的回答——而游戏工业最贵的问题恰恰都在这一侧。
所以自动化的游戏开发 Loop，不是给编辑器加一个聊天框。它要求循环的每一环——构建、部署、运行、观测、归因——都能被程序驱动，并且留下可核查的数据。这是基础设施问题，不是模型问题。
把循环做成基础设施
Mix Studio 的做法分两层。
IrisBuild 是分布式构建引擎，负责把循环里最贵的一环压下来：构建时间应该随集群规模下降，而不是随工程规模上涨。Ycode 是 Windows 原生的游戏开发工作台（没有 Electron），把编辑、构建、签名、真机、GPU 抓帧、自动化测试放进同一个工作区，再把这些能力整理成 AI Agent 可以调用的工具表。
闭环的形状是固定的（图 1）。下面按环节拆开讲。
构建：先把最贵的一环压下来
IrisBuild 的接入方式刻意保守：不改你的构建系统。它兼容 IncrediBuild 的 XGE 命令行与任务协议，UnrealBuildTool、UE 编辑器的 Shader 编译、MSBuild、CMake/Ninja、Cargo、Unity IL2CPP 原本怎么发任务，现在还怎么发——只是任务从一台机器摊到整个集群。编辑器批量拉起的 ShaderCompileWorker 走拦截模式透明分发；Cargo 调起的 rustc 被截获远送，jobserver 并发语义原样保留。
worker 不需要预装 Visual Studio 或 Windows SDK：编译器与头文件由发起方按内容寻址分发，沙箱把远端进程的文件视图虚拟化成发起方的样子，被调用工具的命令行一个字节都不改写。给集群加一台机器的成本是装一个常驻服务，而不是复刻一套开发环境；构建进行到一半才开机的机器，也会被拉进当前这次构建。
调度是资源感知的：每台 worker 实时上报 CPU、内存与 GPU 遥测，按余量评分派活，压力上来时收缩槽位、但不中断已经在跑的任务。集群控制台上的那句话概括得很准：「让每一颗核心，在正确的时刻工作。」
几组内部工程的实测记录：
| 场景 | 实测 |
|---|---|
| 同一工程干净构建，本机 24 线程 MSBuild（基线） | 686 秒 |
| 同一工程干净构建，两台 worker 分布式 | 436 秒，快 36.5% |
| Unity IL2CPP 编译阶段，接入集群前后 | 236 秒 → 129 秒 |
| UE 编辑器 Shader 编译退回本地的次数，修复前后 | 518 次 → 1 次 |
同一轮优化里，网络传输字节相对基线减少了 80.5%。这引出比「更快」更重要的一条设计纪律：越构建越聪明。每类编译动作的耗时、每台机器的速度系数，都会做成跨构建持久化的调度历史，新一轮构建从第一个任务起就按机器能力分派；Action Cache 让重复出现的编译单元直接跳过执行；产物字节在 worker 之间点对点扩散。仓库里的原则写得更直白：任何新增的运行时观测，设计时都要回答「下一次构建如何用它」。
编译只是第一类负载。同一套引擎的定位还覆盖游戏开发里那些长而重的计算——光照烘焙、自动 LOD 减面。减面这一步的组件我们已经写好：一个属性感知的 QEM 边折叠减面器，保边界、保蒙皮，按目标面数比例出结果；把这类任务搬上同一个集群，是路线图的下一步。
整套系统按无人值守设计：worker 是常驻系统服务；任务租约靠心跳续期，超时自动重排；基础设施失败与真实编译错误被严格区分，远端取文件失败不会伪装成一条 C1083；引擎自身的更新走签名通道，金丝雀先行、逐台滚动。当前的内部北极星目标是：4 台机器，17 分钟完成 Unreal Engine 的 clean build。状态口径也如实写在计划里：已落地，打磨中。
让循环穿过真机
构建压下来之后，瓶颈移到设备侧。Ycode 把设备侧做成与构建同级的基础设施：
- 在一台 Windows 工作站上完成 iOS 应用的编译、链接、签名、打包，不需要 Mac；设备接入不依赖 iTunes，也不需要手工装 ADB。
- 真机发现、安装启动、投屏串流、输入注入、可按进程与 tag 过滤的设备控制台，都在同一个工作区里。
- UI 自动化把真人操作录制成结构化脚本：回放、断言，失败时自动收集截图、控件路径与日志切片。游戏的自绘 UI 没有控件树，就把 GPU 纹理直送本地视觉模型做识别，不回读整帧。
- GPU 抓帧把 Metal、Vulkan、RenderDoc 的帧统一到 frame / pass / resource 一张图上；Unreal Insights 的 trace 直接打开；分布式构建的实时 trace 也回流到同一个可视化面板（这个面板同时支持 Epic 的 UBA）。
到这一步，循环的每一环都有了 API 和数据。这正是让 AI 介入的前提。
AI 归因：循环的大脑，不握方向盘
Ycode 的 Agent 跑的是一个显式状态机：Plan → Tool → Observe → Reflect → Diff → Verify，可中断、可恢复、可回滚。它的工具表不止读写文件：build.run 发起真实构建并读取诊断，debug.evaluate 在断点帧上求值，device 系列工具操作真机，抓帧与 trace 数据可以直接查询。在 Unreal Insights 里选中一段掉帧的时间范围，点 AI Explain，Agent 拿到的是聚合后的 top timer 与设备采样，而不是一段被复制粘贴的日志；对 GPU 帧的解释会落到具体 pass 的瓶颈类型和具体的修复建议。
自动化不等于放权。这套 Agent 的护栏是结构性的：
- 所有写入必须经过 Diff 审批，自动应用需要策略显式打开。
- Agent 的构建只发生在隔离的 Git worktree 里，主工作区拒绝执行。
- 单次运行有硬上限：40 次工具调用、200k token、15 分钟，任一触发即停。
- 每条结论带 evidence id，可以反查到产生它的那次工具调用与原始数据。
模型侧不锁定：Anthropic、OpenAI、DeepSeek、Kimi 或本地 Ollama，用你自己的 key；MCP 双向打通，外部工具接得进来，Ycode 的构建、调试、设备能力也能作为 MCP server 暴露给 Claude Code 这样的外部 agent。
把视角拉远一点，这也是我们对当下的判断。AI infra 的建设如火如荼，token 正在变快、变便宜；但 agent 终究要执行 action——对游戏开发来说，是一次构建、一轮部署、一场真机回归。模型半秒钟给出的修复，要等四十分钟的构建才能被验证：循环的墙钟时间由最慢的 action 决定。所以 gamedev infra 本质上是 agent 的 action infra——构建被集群加速，验证被设备矩阵加速，归因被统一的观测数据加速；action 每快一步，同样的模型就多转几圈循环。AI infra 决定 agent 想得多快，gamedev infra 决定它做得多快——天下武功，唯快不破。
我们自己先住进这个循环
IrisBuild 仓库里有一条写给 agent 的常驻指令，原文是：「启动审计和修复循环，直到分布式编译的测试项目能通过再停止，中间不要停下来询问，全程自主决策，自主运行。」配套的纪律同样白纸黑字：远程执行累计超过 10 个错误任务立即停止；不许为了通过测试去 hack 被测的工具；每次事故写进 postmortem，每个决策留档可查。
这套构建引擎本身，就是在这样的无人值守循环里被开发和验证的。我们对「自动化的游戏开发 Loop」有信心，是因为先把自己的工程放了进去。
闭环的度量
衡量这类基础设施的标准只有一个：循环转一圈要多久。我们写在商业计划里的愿景是——任何平台的游戏，从一行代码改动到真机帧数据，闭环不超过一分钟；任何一次性能回归、崩溃、签名失败，都能在发生当天被 AI 归因到具体提交。
Ycode 的每个定价方案都包含完整工作区，档位只区分容量：主机数、同时连接的设备数、分布式构建节点数。构建、调试与性能能力不按档位阉割。
留给下一篇的问题
这篇讲的都是循环怎么转得快。结尾我们想留一个还没展开的问题：一款 AAA 游戏要进入移动设备，到底还差哪些？
差距不在「能不能跑起来」。移植的真正工作量，藏在两张清单里。
**美术资源规格。**桌面 GPU 和移动 GPU 是两种物种：一边是 immediate-mode 架构加 GDDR 的带宽自由，一边是 tile-based 架构加功耗墙。同一套资产直接下放，等于把桌面的带宽账单原样寄给手机。纹理压缩从 BCn 换到 ASTC 之后，尺寸上限、mip 链、通道打包怎么重定？面数预算、LOD 链、shader 变体怎么按设备档位分级？而「设备档位」本身以什么为依据——一张机型表，还是真机上抓回来的帧时间与带宽数据？
**代码结构路径。**知道了目标设备与运行平台，工程该怎么组织：平台抽象层切在哪里，平台相关代码放进哪些目录与模块，编译路径与 feature 开关怎么设计，才能让同一套代码在桌面与移动之间持续演进，而不是活在 #ifdef 森林里？
我们倾向的方向是：这两张清单都不该停在文档里，应该变成流水线中可执行的约束——资产导入时校验规格，构建时按平台分发与裁剪，真机抓帧验证预算有没有守住。换句话说，AAA 下移动的问题，最终仍会落回这篇文章讲的循环。续篇已经写好：《AAA 与小团队之间，隔着三张表》。
把完整游戏开发闭环，交给一套 AI 驱动的基础设施。
产品页 mixstudio.tech/product/ycode · 社区 Discord · 商务 [email protected]