自动关联目录：四年经历时间线与年限口径

截止日期：2026 年 10 月 18 日。结论是“近四年游戏客户端相关经验，含实习”，不是“四年全职经验”。

一、完整时间线

这里描述的是“工作重心”，不是组织关系的精确切换日，也不表示表中每个模块都是本人独立主责。旧模块维护、新项目预研和版本支援长期重叠，不能把每一行的月份相加。

UGC1.0 还需要区分三种来源：当年直接交付、当年项目内参与、现在基于同项目源码进行的系统复盘。后两者可以形成完整的项目认知和可迁移能力，但不能反向改写成当年的个人交付。逐模块口径见 UGC1.0经验补全：实战、项目参与与源码复盘。

特色玩法和 UGC2.0 使用同一原则。玩法侧的完整模块图与个人主讲范围见 特色玩法与PVE经验补全：实战、项目参与与源码复盘；UGC2.0 的对象/VM 全景、跨语言通信和个人基建范围见 UGC2.0经验补全：基建、跨端、创作运行时与源码复盘。

二、提交证据对应的边界

“最早/最晚提交”只证明本地可追溯区间，不等于立项日、转组日或全部投入时间。

三、年限计算

实验室经历与实习在 2022 年重叠，实验室经历与正式工作在 2023 年 3 月至 5 月重叠。任何按项目月数相加得到的数字都会重复计算。

四、推荐口径

自我介绍开场

我有近四年游戏客户端相关经验，其中包含四个月实习；从 2023 年 3 月起一直做正式客户端开发。工作主线是 UGC 平台、复杂 Gameplay，以及 Web UI 与客户端运行时的跨端工程。

简历标题

优先写：

近四年游戏客户端经验｜UGC 平台、Gameplay、跨端工程

不要写：

• 四年全职客户端经验。
• 六年软件研发经验。
• 四年 UGC 架构经验。

前者在当前日期不准确；后两者会把学生项目、重叠时段或不同工作方向混为一谈。

五、四年叙事不是项目流水账

四年的成长主线应压缩成四次能力升级：

1. 从功能交付到完整内容链路。 在 UGC1.0 中，不只做编辑界面，还处理地图数据、上传下载、发布、安全与运行时表现。
2. 从单系统到高密度 Gameplay。 在特色玩法中，开始面对多人会话、大量交互对象、局内外状态和网络复制约束。
3. 从业务模块到平台边界。 在 Web 和 UGC2.0 中，工作重心转向协议、生命周期、语言边界、制品和自动化。
4. 从个人经验到可复用研发能力。 将缺陷处理、知识检索、规范和构建经验沉淀为工具、知识库与可执行流程。

实验室与实习不抢占这三条主线，只用于解释底层能力来源：C++/算法训练形成了数据结构、性能和验证意识，强化学习实习建立了从假设、训练到对照评估的闭环。

六、仍需本人确认的不是日期，而是职责强度

• 非对称、PVP、PVE 三段中，哪些系统是独立负责，哪些是共同开发或版本支援。
• 技能、3C、AI、局内外系统这一组简历用词过宽，需要逐项绑定代表需求和协作边界。
• 各阶段的业务结果与性能结果仍需验收材料；提交密度不能替代结果。
• Fate 定点数物理已从 D:\Fate 补齐源码和提交证据；实习、CAE 与公开组件仍按各自证据情况保留缺口，不与 Fate 合并背书。
• UGC1.0 中事后补课的模块可以用于回答架构、取舍和接手方案，但不能用“我主导/我实现”替代真实职责。