自动关联目录：UGC1.0经验补全：实战、项目参与与源码复盘

这篇不是简历，也不是背诵稿，而是 UGC1.0 的完整技术底座。目标是把个人交付、项目内协作和团队源码复盘统一到一张图里：面试时能讲出平台全景，也能准确落回自己真正负责的部分。

一、先把边界说清楚

1.1 经验来源分层

X1-X4 描述经验来源，不等同于事实证据等级。源码能证明系统存在和当前理解深度，但不能把同事的历史交付转成个人成果。

1.2 时间来源也要分层

当前工作区保存的是持续演进后的源码，不是 2025 年 3 月的静态快照。因此再增加一组时间标签：

按路径级 Git 历史核对，撤销框架、编辑操作状态机、AIGC、UI 编辑器、社区资源、自定义建模、玩家存档、质量检测、脚本框架和多层地图在 T1 已有落点；当前 Coding 服务体系、多人共创和完整编辑历史主要属于 T2。一个模块可能 T1 已有雏形、T2 才形成当前架构，回答时应明确所讲的是哪一版。

1.3 两种问题必须使用两套主语

• 面试官问“UGC 架构是什么”：主语用“系统、平台、团队”，可以覆盖完整架构。
• 面试官问“你做了什么”：主语切回“我”，只展开 X1，再补充明确的 X2 协作边界。
• 面试官追问“是谁设计的、谁负责事故”：继续按事实回答，不用架构理解代替 ownership。

一句话口径：

我直接负责的是地图数据与交付、编辑交互与部分元件、AI 辅助创作、ASTC、四足生物和工程工具；平台其余能力不是都由我实现，但我已经沿着源码和全员提交把对象模型、事务历史、脚本运行时、多人共创、资源发布和质量门禁补成了完整认知。

二、UGC1.0 到底是什么系统

它不是一个“摆放物件的页面”，而是把游戏引擎能力产品化给普通创作者的内容生产平台。客户端同时承担五种角色：

1. 创作工具：让用户选择、摆放、配置、编排和调试内容。
2. 内容编译器：把编辑态对象、属性、逻辑和资源转成稳定、可版本化的数据。
3. 运行时宿主：把创作数据恢复为可游玩的场景、规则、角色和 UI。
4. 交付终端：负责保存、预检、压缩、上传、审核、发布、下载和缓存。
5. 平台治理节点：执行权限、容量、性能、安全、兼容和线上可观测性约束。

完整业务闭环是：

进入创作大厅
  -> 选择模板 / 创建地图
  -> 场景编辑 + 属性配置 + 逻辑编排 + 资源引用
  -> 本地保存 / 云存档 / 历史快照
  -> 试玩与性能检查
  -> 发布预检 / 打包 / 上传 / 审核
  -> 广场分发 / 多人游玩
  -> 数据反馈 / 修复 / 再发布

架构设计不能只解释“编辑器怎么写”，还必须回答内容如何从编辑态安全、稳定地流到运行时和线上生态。

三、客户端总体架构

最重要的四条主链：

• 操作链：输入 -> 操作状态 -> 领域命令 -> 内容模型 -> 脏标记/自动保存。
• 内容链：对象/逻辑/资源 -> 快照 -> 序列化 -> 制品 -> 上传 -> 发布版本。
• 运行链：发布版本 -> 下载/校验 -> 反序列化 -> 实例化 -> 服务注册 -> 联机游玩。
• 治理链：编辑预检 -> 试玩采样 -> 内容审核 -> 运行时校验 -> 指标与故障回收。

四、完整模块图谱

下面把当前源码中的团队能力全部纳入。X3 条目是为了形成架构深度，不代表个人历史交付；表中也包含 T2 后续演进，不能把整张表原样描述为 2023–2025 的系统快照。

4.1 创作入口与编辑内核

4.2 对象、元件与创作表达

4.3 运行时与玩法能力

4.4 数据、资源、发布与治理

4.5 工具、质量与线上治理

五、十二个必须能讲深的技术专题

5.1 编辑操作状态机

源码中移动、旋转、缩放、镜像、绑定、模板编辑、选择等操作被拆成独立状态，通过统一入口切换，并明确执行退出和进入逻辑。

• 业务问题：移动端输入有限，多种编辑模式若同时响应，会出现 Gizmo、选择和面板互相抢状态。
• 实现核心：状态机只维护当前操作域；具体状态管理输入订阅、临时对象和退出清理；切换后再通知 UI。
• 最难问题：弹窗、切后台、对象被删、切层、进入试玩都可能造成“未正常退出”。
• 反思：不能把模式散落成页面布尔值。应让状态拥有资源，退出必须幂等，并提供强制回到安全态的恢复入口。

5.2 撤销重做、自动保存和编辑历史不是一回事

撤销框架属于 T1，当前看到的完整编辑历史模块主要属于 T2。比较它们是为了理解系统演进，不是说当期已经具备今天的全部恢复能力。

• 撤销/重做：会话内、细粒度、低延迟，适合 Command 模型；新操作会清空 redo，历史需要有上限。
• 自动保存：持续把当前内容状态固化，解决崩溃和意外退出，不保证每一步都可读。
• 编辑历史：跨会话、粗粒度的场景/Coding 快照，支持本地、云端、手动版本和覆盖恢复。
• 设计结论：三者必须共享内容版本和脏标记，但不能共用一套数据结构。Command 解决“反操作”，Snapshot 解决“恢复到某个稳定世界”。

5.3 元件不是一个蓝图，而是一条契约

一个成熟元件至少包括：编辑器注册信息、属性 Schema、默认值、编辑面板、保存结构、运行时实现、网络策略、资源依赖、版本迁移和容量成本。

新增属性要回答四个问题：旧地图没有这个字段怎么办；修改后谁收到通知；运行时是否立即生效；它是否参与复制和保存。只做 UI 和运行时逻辑，不补 Schema 与迁移，迟早会形成坏档。

元件模式的价值是把风险封进受控能力，代价是组合自由度和系统扩展速度受注册表、属性面板与事件协议约束。

5.4 地图数据与发布事务

推荐用以下状态机理解完整链路：

Editing
  -> FreezeSnapshot
  -> Validate
  -> Serialize
  -> Package
  -> UploadArtifacts
  -> SubmitReview
  -> WaitReview
  -> Published

每一步都要记录输入版本、输出制品和可重试信息。客户端不能在上传过程中继续偷偷读取变化中的编辑态；正确做法是冻结快照，发布任务只面向不可变输入。失败后根据阶段清理临时产物或复用已上传制品，避免重复提交。

5.5 Coding 和脚本运行时

脚本框架在 T1 后期已经启动，当前完整 Coding 服务体系包含较多 T2 演进。源码显示系统不止有固定元件，还逐步形成了编辑器、变量类型、引用选择、适配层、服务层、沙箱、协程、异常收集、属性同步和 RPC 等能力。

• 编辑态负责图/代码数据、类型检查、资源引用和调试入口。
• 适配层把创作概念转换为稳定 API，隔离底层对象变化。
• 服务层按角色、相机、音频、任务、商店等领域暴露能力。
• 沙箱控制全局环境、API 和资源预算，异常不能拖垮主游戏。
• 网络层区分客户端表现和服务端权威，所有影响公共状态的输入仍需校验和限流。

技术深度不在“支持 Lua”，而在 API 治理、权限、版本、可观测和多人一致性。

5.6 多人共创

多人共创主要是 T2 能力。现有源码体现了按场景、Coding、界面等数据域切分共创模式，并通过服务端通知、权限和待同步状态组织流程。这说明这一阶段的系统更接近“按编辑域分权和同步”，不能未经核实就说早期版本已有该能力，更不能说用了 CRDT 或完整实时合并。

真正难点包括对象身份、锁粒度、离线重连、顺序冲突、撤销语义和跨域引用。若重新设计，应先确定产品需要的是轮流编辑、分区并行，还是同对象实时协作，再决定锁、操作日志、OT 或 CRDT，不能为了技术名词过度设计。

5.7 云端资源与内容依赖

资源库需要同时管理资源身份、版本、元信息、文件清单、发布状态、缓存和引用者。地图不能只保存本地路径，而应保存稳定资源引用；下载后要校验版本和完整性；发布地图前要确认资源可访问、已审核且目标平台有对应产物。

删除资源不是普通 CRUD。系统必须知道哪些地图、预制体和脚本仍在引用它，并提供阻断、替换或固定旧版本的策略。

5.8 编辑态与运行时的边界

编辑器对象强调可修改、可选中和可序列化；运行时对象强调性能、网络权威和稳定生命周期。二者可以共享 Schema 和能力标识，但不应共享所有实例状态。

试玩流程应冻结编辑数据并构建运行世界；退出试玩后销毁运行态，再恢复编辑上下文。多人玩法中的奖励、伤害、库存和胜负由服务端权威，客户端负责输入、预测和表现。这个原则也与 Roblox 官方对客户端/服务端运行时和服务端校验的划分一致。

5.9 性能质量门禁

源码存在“开始检测 -> 采样 -> 结果 -> 发布”的独立状态流程，说明性能不是最后人工看一眼，而是发布链路的一部分。

质量门禁需要区分硬阻断和软警告：非法数据、必崩和超硬上限必须阻断；设备相关的帧率波动可提示并允许优化。采样必须固定设备档位、地图阶段和统计窗口，否则数据不能比较。门禁规则还要版本化，否则旧地图可能因新阈值突然无法再发布。

5.10 自定义建模与运行时几何

参数化几何不只是生成顶点。创建前要做参数合法性和资源占用预估，创建后要处理法线、UV、材质、碰撞、导航、序列化和跨平台性能。源码中的形体预检与占用量计算说明“预算前置”比生成后报错更适合创作工具。

5.11 AI 辅助创作

AI 功能应被当作异步资产生产管线，而不是一个请求按钮：创建任务、展示进度、处理审核、生成候选、预览、确认写入、固化资产、建立引用、支持撤销，并记录失败原因和转化漏斗。

最重要的工程问题是幂等和所有权。重复回调不能生成两份资产；用户离开页面后任务仍要可恢复；预览产物和正式资产必须区分；进入发布链路前必须完成内容安全和格式处理。

5.12 工具与线上治理

地图解析和 Crash 分单不是外围杂活，它们补的是 UGC 平台最容易缺失的可观测性：当内容来自海量用户、版本横跨多年时，开发者不能只靠在客户端复现。

• 地图解析器让坏包、版本和资源问题可以离线批量定位。
• Crash 分单把调用栈、版本和代码归属映射成可处理队列，并保留人工兜底。
• 资源扫描与迁移工具把一次性修复变成可重复治理。
• 真正的结果指标应是定位时长、自动命中率、误报率、兼容覆盖率和重复事故下降，而不是工具代码量。

六、旧 UGC、绿洲启元与 Roblox 怎么比较

准确说法不是“绿洲只有元件，Roblox 只有脚本”。绿洲启元官方文档同时公开了模式编辑器、Lua、Actor 生命周期、复制/RPC 和 GamePart；它的特点是复用 UE Gameplay Framework，并在上面开放领域化工具和接口。Roblox 的特点是从 DataModel/Instance 与 Luau 出发，把对象、服务和脚本放进统一平台模型。这里比较的是公开技术模型，不从“类绿洲”一词推导连续身份、跨世界或经济系统。

绿洲启元依据：玩法开发框架介绍、网络同步系统介绍、模式编辑器、Lua 玩法功能、GamePart 模块化。Roblox 对照依据：项目与 DataModel、客户端/服务端运行时、Packages、客户端/服务端边界安全。

七、面试回答模板

7.1 “请描述 UGC 客户端架构”

我会从内容生命周期而不是目录结构回答。客户端大致分六层：最上层是大厅和编辑器 UI；下面是选择、Gizmo、属性、命令、撤销和历史组成的编辑领域层；再下面是地图 Schema、对象/元件、脚本和资源引用组成的内容模型；内容进入试玩后，由角色、规则、AI、网络和脚本沙箱组成运行时；保存发布侧负责快照、序列化、打包、上传、审核和版本；最底下还有资源检查、迁移、解析、埋点和 Crash 治理。四条主链分别是编辑操作链、内容交付链、运行时恢复链和质量治理链。架构的核心不是页面怎么拆，而是状态由谁拥有、内容如何版本化、编辑态如何安全转换成可发布和可联机运行的制品。

7.2 “你在 UGC1.0 里具体做了什么”

我的直接工作主要有四块。第一是地图数据和交付链路，包括多文件数据、压缩、上传下载、发布拆分和线上兼容问题；第二是编辑器和元件，包括模式切换、元件管理、属性交互、地图图片以及四足生物；第三是 AI 配色、参考图和 ASTC 等内容生产、处理链路；第四是地图解析和 Crash 自动分单工具。发布、资源、安全、Coding 等模块我做过接入或上下游协作，但不是整套系统的独立 owner。后来我沿源码把事务历史、脚本运行时、多人共创、资源发布和质量门禁补成了完整架构认知。

7.3 “你为什么能讲不是自己写的模块”

我不会把它说成个人交付。我讲的是同一项目的系统设计和我现在的源码复盘结论，并会明确当年自己的接口位置。高级客户端需要理解上下游，否则地图数据、编辑器和发布问题也无法真正闭环；但理解系统和历史 ownership 是两件事，我会分开回答。

八、个人核心能力收口

其他模块负责体现视野，以上六项负责承受连续追问。不能让宽度掩盖主线，也不能让主线退化为功能列表。

九、学习与验收

每个 X3 模块只有能独立回答以下问题，才算从“看过源码”升级为“具备可迁移经验”：

1. 用户为什么需要它，失败会影响谁。
2. 它处在创作、保存、发布、分发和游玩的哪个阶段。
3. 哪一层拥有权威状态，哪些只是视图、缓存或副本。
4. 核心数据结构、生命周期和跨模块协议是什么。
5. 最难的三个失败模式，如何定位、降级和恢复。
6. 旧方案为什么这样设计，替代方案会付出什么成本。
7. 能否给出 30 秒结论、90 秒回答和一张白板图。
8. 如果面试官问“这是不是你写的”，能否一句话准确交代边界。

建议学习顺序：

1. 先打通编辑状态机、对象/元件、地图 Schema、撤销历史和发布事务。
2. 再补 Coding/脚本、UI 编辑、多人共创、资源库和运行时权威。
3. 然后补质量门禁、自定义建模、存档、NPC/技能等平台能力。
4. 最后将旧 UGC、绿洲启元公开模型和 Roblox 放到同一组设计维度比较。

十、最终边界

• 可以说“我有 UGC1.0 项目经验，并对平台主要模块形成了系统理解”。
• 可以说“团队系统包含……，我的直接工作集中在……”。
• X1 用事故、权衡、代码和结果展开；X2 先说明接口位置；X3 明确是源码复盘。
• 可以把团队模块学成自己的能力，但不能把团队提交改写成自己的历史。
• 面试深度最终来自业务约束、状态与数据设计、失败模式和取舍，而不是背出类名。