用途：在编写浏览器游戏代码前先建立不可妥协的架构。资料指出，当模拟、渲染、UI、资产加载与输入处理混在一起时，浏览器游戏会迅速劣化。适用于尚未确定引擎或渲染器、任务涉及模块边界、状态归属或资产策略，以及多个专项技能需要共享同一架构框架时。若运行时已明确为 Phaser、原生 Three.js 或 React Three Fiber，或任务纯粹关于交付的 3D 资产，则应转交给对应的运行时或资产专项技能。
主要能力与规则：模拟与渲染分离，模拟负责实体、回合、计时器、碰撞、进度与可存档状态，渲染器负责场景组合、动画播放、相机、粒子与输入管线；输入映射显式化，定义 move、confirm、cancel、ability-1、pause 等动作并集中映射物理输入；资产加载作为一等系统，使用稳定清单键，按角色、环境、UI、音频、特效分组，3D 内容默认采用 GLB 或 glTF 2.0；提前定义存档、调试与性能边界，只序列化模拟状态；默认用 DOM 覆盖层承载菜单与 HUD，Canvas 或 WebGL 负责游戏区域；3D 运行时约定（单位、原点、枢轴、命名）要早锁定。
引擎选择：2D 精灵、瓦片地图、俯视或横版动作、回合制网格及经典街机流程默认 Phaser；需要直接控制场景、相机、渲染器与循环的显式 3D 场景默认原生 Three.js；3D 场景位于 React 应用中并需声明式组合时默认 React Three Fiber；着色器密集或渲染器优先项目才用原生 WebGL；Babylon.js 与 PlayCanvas 作为备选路径而非默认代码生成目标。
实现清单：写核心代码前先定义玩家幻想与主要动词、核心循环与失败重置状态、相机模型、输入动作映射、模拟模块、渲染模块、资产清单布局、3D 资产格式与优化规则、HUD 与菜单界面、存档数据边界、调试与性能界面。
反模式：将玩法规则直接混入场景回调；把渲染器当作游戏状态的事实来源；默认把所有 HUD 与菜单放进画布；让资产文件名而非清单键成为公共 API；把未优化的 3D 资产直接从 DCC 工具发布到浏览器；在没有明确输入边界时混合相机控制状态与菜单或模态状态；每次游戏类型变化都重建架构。