AI全流程创游丨网易Y3编辑器Full Mode与Patch Mode双模式架构深度解析

一、2026 年 AI 创游进入"全流程编排"竞赛阶段

2026 年 2 月，Unity CEO 在 GDC 前宣布将推出 Unity AI Beta，声称"用自然语言 Prompt 出完整休闲游戏"，底层接入 OpenAI GPT 与 Meta Llama。Google Cloud 的 Jack Buser 在 GDC 2026 上给出了一个颇具争议的预判："3-5 年内每个主要游戏品类将被 AI 彻底改变。"

然而，现实层面仍然存在明显的裂缝：Game Developer 调研显示，36% 的从业者使用生成式 AI，但 50% 认为它有害。Godot 社区的维护者则表示 AI 生成的 PR 已经让他们不堪重负------AI 代码质量问题是真实存在的。

在这个背景下，网易 Y3 编辑器的 CodeMaker Agent 提出了一套不同的路径：与其用通用大模型直接操控引擎，不如构建一套引擎专属的 AI 编排器，通过 MCP 协议与编辑器深度绑定，把 AI 的生成能力嵌进工程流程而非悬浮在工具链之外。

y3-game-spec 就是这套体系的核心调度器。它内置了两个完全不同的工作模式：Full Mode 和 Patch Mode，分别面向从零原创与增量迭代两种开发场景。

二、架构概述：y3-game-spec 是什么

y3-game-spec 是 Y3 编辑器 CodeMaker Agent 中的全流程编排模块，负责把用户的自然语言需求翻译为可执行的工程指令序列，并通过 MCP 协议驱动编辑器和游戏运行时。

其核心依赖链如下：

用户自然语言输入
    ↓
y3-game-spec（模式判断 + 流程编排）
    ↓
MCP 工具链（y3editor / y3-helper / y3runtime）
    ↓
网易 Y3 编辑器进程 + 游戏运行时

50+ 个 MCP 工具分布在三个层级：

• y3editor：编辑器控制层（40+ 工具），覆盖地形、物编、UI、资源管理
• y3-helper：游戏进程控制（8 工具），负责启停游戏、执行 Lua、截图
• y3runtime：运行时交互（2 工具），支持 UI 事件触发，不依赖屏幕坐标

整套架构的设计原则是：AI 生成内容不直接注入引擎，而是经过合规校验和门禁机制后才执行写入。这与目前大多数通用 AI 编码工具（Cursor、GitHub Copilot 等）的最大区别在于------后者只负责生成代码，不负责保证代码在特定引擎环境中的可执行性。

三、Full Mode：端到端全链路无人化编排

3.1 适用场景定义

Full Mode 适用于从零开始制作一款游戏的场景，其完整流水线为：

策划案 → 执行案 → 物编 → UI → Lua → 审查 → 自动测试 → 迭代

每个环节都有对应的子模块负责执行，且环节之间有明确的文档一致性校验（策划案 ↔ 执行案 ↔ 测试案 ↔ 测试报告，四方可追溯）。

3.2 各环节技术实现

① 策划案 → 执行案（需求分解）

AI 接收用户的自然语言描述（如"做一个 5 关塔防，每关难度递增，第 3 关有 Boss"），生成结构化策划案，再拆解为可执行任务清单。

② 物编阶段（y3-obj-edit）

物编模块封装了 Y3 特有的 Tuple 嵌套 JSON 格式，支持批量 CRUD 操作：

-- 伪代码示例：批量创建敌人单位
for i = 1, 5 do
    create_unit({
        type = "enemy_" .. i,
        hp = 100 * i,
        speed = 200,
        model = "enemy_basic_" .. i
    })
end

Y3 的物编数据格式相对特殊（嵌套层级深、字段名非标准化），人工填写容易出错，AI 批量处理在准确率上有实际优势。

③ UI 生成（y3-ui-pipeline + y3-ui-generator）

流程为：HTML 布局预览 → Y3 UI JSON 转换 → 节点树生成。

内置 13 套官方组件模板（技能栏、血条、物品栏、Buff 栏等），对于标准 HUD 结构，基本可以做到零手动搭建。

④ Lua 代码生成与审查（y3-lua-pipeline + y3-lua-review）

这是 Full Mode 中技术密度最高的环节。生成后经过：

• 静态语法检查

• Y3 官方 API 白名单比对（防止 API 臆造）

• 已知问题匹配（错题本机制）

• 不合规自动修复并记录

  -- 伪代码：Lua 审查流程
  function review_lua(code)
  local syntax_ok = check_syntax(code)
  local api_ok = check_against_whitelist(code, Y3_API_LIST)
  local known_issues = match_error_book(code)

    if not api_ok then
        code = auto_fix(code)
        log_to_api_issues(code)
    end
    return code

  end

⑤ 自动化测试（y3-auto-test）

通过 y3runtime 的 trigger_ui_touch_event_by_path 工具，AI 可以在不依赖屏幕坐标的情况下触发 UI 事件，实现：启动游戏 → 定位 UI 节点 → 模拟点击 → 截图验证 → 输出结构化测试报告。

3.3 效率数据参考

场景	Y3 Full Mode	Y3 原生（无 AI）	Unity + 商店模板
5 关塔防 Demo	3-6 小时，1 人	5-10 天，1 人	3-5 天，1-2 人
手绘图转地形	30 分钟内，内置支持	数小时至 1 天，手刷	1-3 小时，需第三方插件
AI 自动化覆盖率	80-90%	0%	30-50%（仅代码辅助）

数据来源：Y3 CodeMaker Agent 内部基准测试，基于标准场景估算，实际情况因项目复杂度有差异。

3.4 Full Mode 的核心工程纪律

Full Mode 不是"放飞式"生成，内置了几个关键约束机制：

机制	作用
文档一致性校验	防止策划案与执行结果偏差
MCP 熔断机制	超时不重试、连续失败 2 次即停
热更 → 等待 → 保存三步流程	物编/UI 修改防数据丢失

四、Patch Mode：增量修改的精准外科手术

4.1 适用场景定义

Patch Mode 适用于在现有工程上局部修改或优化的场景：

需求理解 → 方案输出 → 用户确认 → 执行 → 验证

关键设计：方案先行。AI 不会在用户未确认的情况下直接执行写入操作。这个设计看似保守，但对于已有工程而言是必要的------局部修改的破坏性风险远高于从零生成。

4.2 与 Full Mode 的核心技术差异

维度	Full Mode	Patch Mode
工程状态	空白工程	现有工程
执行策略	全链路顺序执行	定点注入，最小化影响范围
用户介入点	策划案确认后自动执行	每次执行前必须用户确认方案
合规校验	全量校验	差量校验（只检查修改涉及的模块）
风险等级	低（空白工程无历史数据）	中（需保护现有逻辑）
适用频次	项目启动期，使用频次低	迭代期，高频使用

4.3 Patch Mode 解决的真实痛点

以独立开发者最常见的"加一个新技能"需求为例，对比传统路径与 Patch Mode 路径：

传统路径（Unity/UE5）：

1. 找到现有技能脚本（可能分散在多个文件）
2. 理解现有逻辑结构和事件系统
3. 编写新技能脚本，处理与现有系统的兼容性
4. 在物编表中添加技能数据
5. 测试并修复冲突

预计耗时：1-4 小时（包含理解成本和调试时间）

Patch Mode 路径：

1. 描述新技能需求（"加一个燃烧技能，伤害持续 3 秒，触发时有粒子特效"）
2. AI 输出修改方案（涉及哪些文件、改哪些字段）
3. 用户确认
4. AI 执行写入、运行合规校验、热更验证

预计耗时：5-15 分钟，AI 占比约 90%

这个效率差距在高频迭代场景下会被急剧放大。一个 UGC 项目在测试阶段可能每天需要做 10-20 个类似的小修改，累积下来的时间成本是显著的。

4.4 错题本机制：Patch Mode 的记忆系统

Patch Mode 配有两个持久化知识库：

• trace_issues.md：运行时报错自动归纳
• api_issues.md：API 误用自动归纳

每次执行 Lua 审查时，优先匹配这两个文件中的已知问题列表。随着项目积累，相同类型的问题会被越来越快速地识别和修复------这是一个正向飞轮，而非一次性工具。

五、双模式的协同使用模式

在实际项目中，Full Mode 和 Patch Mode 并不是非此即彼的选择，而是对应开发周期的不同阶段：

项目初期（1-3 天）
    → Full Mode：生成核心玩法骨架、基础 UI、初始物编表
    
测试迭代期（持续）
    → Patch Mode：逐项修改玩法参数、新增功能模块、修复测试报告中的问题

版本更新期
    → Patch Mode：增量内容更新，保持现有工程稳定性

这种分层体系的价值在于：新手可以用 Full Mode 完成冷启动，资深开发者可以用 Patch Mode 做精细化调优，两者不需要相互让步。

六、创作者实战案例：从效率到营收

理论说完，来看几个真实场景：

在校学生 · MOBA 竞技地图

利用课余时间，用 Full Mode 快速搭建 5v5 竞技地图基础框架，Patch Mode 持续迭代英雄技能和平衡数值。无需雇佣外包程序，整体开发成本接近零。地图上线约 2 个月后，凭借持续版本更新积累的口碑，月流水突破万元------这是他的第一个独立商业化作品。

美术转型创作者 · 剧情解谜品类

美术出身，卡在"不会写 Lua"的门槛前已久。借助图片转地形功能将手绘场景草图直接转化为可用地形，Full Mode 自动生成解谜交互逻辑代码，她只需专注于关卡叙事和视觉表达。上线后作品在平台获得大量订阅，收益超过以往接外包美术活的月均水平。

2 人小团队 · 成本结构重构

策划 + 美术组合，此前每月需花 2-3 万元外包程序开发。引入 CodeMaker Agent 后，Full Mode 承担核心玩法冷启动，Patch Mode 处理日常版本迭代，程序外包支出降至近零。节省的预算全部投入内容运营和推广，团队整体盈利周期显著缩短。

连续创作者 · 快速试错变现

用 Full Mode 快速出品多张不同玩法的地图"探路"市场，用 Patch Mode 对反馈好的地图快速跟进热更。第 3 张地图凭借精准的玩法迭代跑出爆款势头，进入稳定被动收益阶段后，该创作者已将精力集中在第 4 张地图的冷启动上。

七、与通用引擎 AI 方案的客观对比

维度	Y3 + CodeMaker Agent	Unity + Copilot/AI Beta	Cursor + 任意引擎
AI 覆盖范围	物编 +UI+Lua+ 地形 + 测试，全链路	主要覆盖代码层	代码层
引擎深度绑定	是（MCP 直驱编辑器）	否（代码辅助）	否（通用 IDE）
合规校验	引擎专属 API 白名单	通用代码检查	无引擎感知
自动化测试	内置，可触发 UI 事件	需额外配置	不内置
平台限制	仅 Y3 平台，不可导出 PC/主机	多平台	多平台
3A 画面支持	中等 3D 上限	高	取决于引擎

Y3 的 AI 方案在覆盖深度和工程纪律上建立了显著优势------MCP 协议直驱编辑器进程、引擎专属 API 白名单校验、全链路自动化测试闭环，这套组合在 UGC 平台创作和轻量化独立游戏开发场景下，是目前国内技术完整度最高的 AI 创游方案之一。

八、小结

y3-game-spec 的双模式设计，本质上是对"AI 全流程创游"这个命题给出了一个工程化的落地答案：

• Full Mode 解决的是冷启动问题------让没有工程基础的创作者也能在数小时内拿到一个可运行的游戏原型。
• Patch Mode 解决的是持续迭代问题------让有工程积累的开发者能以最低成本持续优化。

两者共同构成了一个面向轻量化 UGC 与独立游戏的垂直 AI 开发工作流。这不是通用引擎 AI 方案的平替，而是在特定赛道上的差异化工具选择。