总图

mindmap
  root((客户端工程复盘))
    UGC 内容系统
      内容对象模型
      序列化与兼容
      多关卡与大世界
      创作者脚本
    创作工具
      编辑器事务
      自定义 UI
      NPC 与剧情工具
      导入与发布制品
    资产与渲染
      身份与依赖
      构建与平台产物
      缓存与流式加载
      网格纹理材质
      Shader 与特效
    角色与动画
      角色装配
      骨架契约
      状态与动作混合
      同步与动画预算
    物理与运动
      碰撞与物理材质
      角色运动
      约束与附着
      模拟所有权
      快照与纠偏
    交互与呈现
      多端输入
      相机
      UI 运行时
      音频与反馈
    多人玩法
      交互框架
      DS 权威逻辑
      网络同步
      PVE AI
    工程质量
      性能与伸缩
      跨平台降级
      自动化验证
      诊断与恢复
    AI 研发管线
      结构化变更
      最小权限工具
      确定性验证
      评测与反馈闭环

为什么要这样拆

客户端问题经常被按功能拆分：编辑器做编辑、加载器做加载、动画系统播动画、物理系统做碰撞。功能少时，这种拆法很直接；规模上来以后，真正的故障却发生在功能之间：

编辑数据能保存，但发布制品不能被旧客户端读取。
资产下载成功，但依赖未就绪，玩家仍然看不到内容。
动画命令已经到达，但角色骨架尚未装配，晚到回调又覆盖了新状态。
单个刚体同步正确，但约束组被分帧更新后整体解体。
UI、相机和角色控制都监听同一输入，焦点切换后出现重复响应。
DS 为了权威性保留了完整对象，却承担了本不需要的渲染和高频 Tick 成本。

因此这里同时使用两种切法：

按领域拆所有权：资产、动画、物理、呈现、玩法各自明确自己的真相和生命周期。
按链路看结果：从创作意图一直追踪到玩家看到、听到并能交互的最终状态。

九条技术主线

主线	首要业务问题	最容易被低估的技术问题
UGC 内容与运行时	怎样低门槛表达复杂玩法	编辑数据、运行时实体和发布数据不是一种模型
客户端内容工具链	怎样稳定保存、预览、构建和恢复	草稿、快照、制品、缓存和当前版本需要不同身份
资产与渲染	怎样让内容快速、正确、低成本地可见	下载完成不等于依赖、解码、材质化和首帧呈现完成
角色与动画	怎样兼顾响应、扩展和多人一致性	角色身份、动作意图、动画资源和姿态实例生命周期不同
物理与运动	怎样兼顾手感、权威和稳定性	约束拓扑、所有权和状态必须按同一模拟单元处理
交互与呈现	怎样让控制和反馈跨设备保持一致	输入焦点、相机所有权、UI 命中和音频生命周期会互相影响
多人玩法与 PVE	怎样支持多玩法而不把所有逻辑塞进一个框架	客户端即时反馈与 DS 权威状态需要不同的数据路径
性能与跨平台	怎样在不同负载和设备上守住体验	优化不是少做工作，而是按重要性选择何时、在哪、以何种精度做
AI 辅助研发	怎样提高产出而不放弃工程责任	模型生成必须进入结构化、可验证、可回滚的确定性管线

两条阅读路径

按业务链路

适合复盘一个内容从创作到运行的全过程：

创作意图
  -> 可编辑内容
  -> 校验与冻结快照
  -> 资产和运行时制品
  -> 获取、安装与缓存
  -> 世界和实体装配
  -> DS 模拟与同步
  -> 客户端动画、物理和呈现
  -> 诊断、反馈与下一轮改进

按架构问题

适合遇到具体故障时反查：

现象	优先阅读
保存后打不开、跨版本不兼容	内容模型、序列化、导入迁移
发布慢、制品不稳定、恢复失败	内容工具链、质量门禁、模块边界
内容缺失、加载慢、内存下不来	资产全生命周期、流式加载、加载关键路径
角色动作错乱、晚到资源覆盖新状态	角色装配、动画异步生命周期、同步恢复
穿透、抖动、多人物理分歧	碰撞、模拟所有权、物理快照与纠偏
输入冲突、相机状态残留、UI 重复响应	输入路由、相机生命周期、UI 运行时
交互物或 AI 数量上来后性能失控	交互框架、PVE 分级、海量对象、DS 性能
AI 生成结果能看但不可用	结构化变更、确定性验证、生成资产生命周期

当前已写

文章	解决的问题
如何复盘复杂客户端系统	如何从功能总结上升到业务约束、架构演进和决策质量
资产全生命周期：从创作数据到可见结果	如何统一资产身份、构建、交付、缓存、异步加载和可见就绪

后续文章按“资产与渲染 -> 角色与动画 -> 物理与运动 -> 交互与呈现 -> 多人玩法 -> 总体架构”的依赖顺序推进。

通用术语

术语	含义
可编辑源数据	为创作、检查、撤销和迁移优化的数据
内容对象	在编辑数据或发布内容中具有稳定身份的逻辑对象
资产引用	不绑定物理路径的、有类型的逻辑身份
制品	针对明确目标和格式版本生成的不可变处理结果
交付单元	可独立获取、校验、安装和淘汰的一组制品
运行时实体	已实体化并参与模拟或呈现的对象
Generation	用于拒绝过期异步结果的单调生命周期令牌
快照	某个版本或模拟时刻的不可变状态观察
呈现状态	用于客户端反馈的状态，不是权威玩法真相

文章如何表达“做过”和“建议做”

正文使用三种知识状态：

工程原则：可跨项目成立的机制和约束。
复盘推论：从实际反复出现的问题中抽象出的判断。
目标设计：面向下一阶段的推荐方案，必须说明假设和代价。

三者不会混写成“历史事实”。一篇文章可以讨论早期方案和后续演进，但只使用“阶段 A / 平台化阶段”这样的通用描述，不复原产品版本、组织分工或实施时间线。

核心复盘框架

每个专题都按同一条因果链展开：

业务问题
  -> 早期方案为何合理
  -> 哪个规模变化击穿了假设
  -> 后续架构怎样迁移边界
  -> 新方案付出了什么代价
  -> 哪些问题仍未解决
  -> 目标架构如何定义契约
  -> 用什么指标和测试证明有效
  -> 下一次应更早问什么问题

详细方法见如何复盘复杂客户端系统。上层分类说明见 Work Experience。