简历逐行追问与项目选择矩阵
本页对应 2026-10-18 高级游戏客户端工程师版简历。它不是另一份长复盘,而是“简历上的每句话怎样接住追问”的索引。
一、项目选择矩阵
先判断问题要证明什么,再选案例。不要每道题都讲同一个项目。
| 面试问题 | 首选案例 | 备选案例 | 要证明的能力 |
|---|---|---|---|
| 最复杂的系统设计 | UGC2.0 页面协议与生命周期 | 作者源到发布制品 | 跨层建模、所有权、失败语义 |
| UGC 架构 | UGC2.0 完整链路 | UGC1.0 内容生命周期 | 平台视角、边界意识 |
| 从零到一 | UGC1.0 地图与交付链路 | UGC2.0 页面基础设施 | 模糊需求落地、迭代演进 |
| 跨语言 | TS-C++-Lua 通信 | Lua-C++ Gameplay 接入 | 协议、绑定、生命周期 |
| 性能优化 | 移动端 ASTC | PixUI 高频状态链路 | 度量、定位、取舍 |
| 多人网络 | PVP 物品与交互 | PVE 重连与流程 | 权威、预测、幂等 |
| 复杂状态机 | PVE 新手流程 | 页面栈生命周期 | 恢复、超时、取消 |
| 线上疑难问题 | 偶现引导线 | 页面迟到回调 | 可观测、归因、机制化修复 |
| 工程效率 | Crash 自动分派 | 地图解析/AI 研发资产 | 自动化、团队复用 |
| 跨团队协作 | 局内外时间线联调 | 多端构建与制品 | 契约、责任边界、推进 |
| 失败与反思 | PixUI 初期只讲“封装” | UGC1.0 功能式设计 | 认知升级、行动改变 |
| 最有业务价值 | UGC 内容生产与发布闭环 | PVE 新手流程 | 用户路径、稳定交付 |
二、专业概述追问
“接近四年”怎样计算?
游戏客户端相关经历包括 2022 年约四个月实习,以及从 2023 年 3 月开始的全职工作;截至当前,全职约三年七个月。硕士阶段的 CAE 研发只算软件研发背景,不叠加成游戏客户端年限。
为什么说自己偏平台和基础设施?
因为我的工作重心从单个功能逐步走向共享边界:UGC1.0 做内容保存发布和编辑能力,UGC2.0 做页面协议、原生宿主、制品和自动化。这些能力被多个页面、内容类型或项目复用。Gameplay 是我理解运行时约束的重要经历,但我的差异化仍是 UGC 与跨端平台能力。
你是业务开发还是基础架构?
两者都做过,但不是各占一半。早期和玩法阶段偏业务闭环,后期明显偏共享客户端基础。我的优势正是能从业务问题抽出平台边界,同时能判断抽象是否真的服务交付。
三、腾讯全职经历逐行追问
简历行:参与 UGC1.0 从零到一,负责地图数据、发布交付与编辑能力
30 秒回答
我不是整个平台 owner,而是参与从零到一并负责若干关键客户端链路。地图侧覆盖本地数据组织、存储、上传下载和发布衔接;编辑侧做过模式切换、部分元件与内容能力。这个阶段最重要的产出,是把“编辑器里的对象”与“可保存、可发布、可运行的内容”串起来。
必备追问
- 地图数据的稳定身份和引用如何维护?
- 保存与发布为什么是两条链路?
- 上传失败或版本冲突怎样恢复?
- 简单模式与高级模式怎样避免状态泄漏?
事实边界
可以说“参与平台从零到一”“独立负责若干链路”;不能说“主导整个 UGC1.0 架构”。
简历行:实现 AI 配色/参考图与移动端 ASTC 链路
30 秒回答
这两项都不是单点 UI 功能。AI 配色和参考图要处理异步任务、弱网、资源落地和编辑状态回填;ASTC 要在画质、包体、加载时延、缓存和设备兼容之间取舍。我负责客户端接入和链路处理,重点是把外部能力变成可恢复、可诊断的创作流程。
必备追问
- AI 任务怎样标识、取消和防止旧结果覆盖?
- 原图、预览图和落地资源怎样区分?
- ASTC 是运行时转码、离线处理还是制品阶段处理?
- 缓存键、失败回退和低端机策略是什么?
事实边界
没有可靠数据时不说“深受创作者喜爱”或明确性能提升百分比。
简历行:承担四足生物等内容能力与长期维护
30 秒回答
四足生物是我能够主讲的具体内容案例,涉及编辑配置、运行时生成、动画与交互接口,以及内容保存后的恢复。它让我看到元件不只是一个 Actor,而是作者数据、编辑能力和运行时行为三部分的组合。NPC 和更广泛基础元件我有项目参与和源码理解,但 ownership 强度不完全相同。
必备追问
- 作者配置怎样变成运行时实例?
- 动画、移动和交互能力如何解耦?
- 删除、复制和版本升级怎样处理?
简历行:负责 PVP/PVE 的新手流程、物品交互、HUD/相机与联调
30 秒回答
玩法侧我直接负责过 PVE 新手流程、智能提示、镜头步骤、局内外时间线、任务和 UI 配置;PVP 阶段做过物品道具、交互对象和 Gameplay Ability 接入。我的工作重点是把服务端阶段、客户端表现和各系统异步事件组织成可恢复流程,而不是主导完整战斗或 AI 框架。
必备追问
- 引导步骤怎样定义完成和恢复?
- 服务端阶段变化时 UI 怎样消费?
- 交互请求怎样做服务端复核与幂等?
- Ability 取消时怎样释放 Task 和回调?
- 跨地图的时间线状态由谁保存?
事实边界
不能说“负责完整 PVE 架构、怪物 AI、地牢和战斗框架”。可以先讲完整架构,再明确个人负责的接口和模块。
简历行:建设 UGC2.0 页面协议、原生宿主与跨语言通信
30 秒回答
我把原本页面各自处理的 PixUI 接入收敛成页面基础设施:注册与路由、页面栈语义、生命周期、原生 View 所有权、TS-C++-Lua 消息和状态版本。最难的是三层对象生命周期不一致,所以用 pageId/generation 隔离旧实例,用 domain/revision 管状态顺序,并统一 dispose 清理。
必备追问
- TS 到 Lua 和 Lua 到 TS 的完整调用链是什么?
- 为什么 Lua 位于领域编排层?
- 双通道为什么不会重复消费?
- pageId 与 generation 为什么不能合成一个字段?
- 原生 host 为什么必须是 View 唯一 owner?
简历行:参与制品生成、二进制化和多端交付
30 秒回答
作者源适合编辑,不适合直接作为运行输入。我参与把冻结快照交给处理器流水线,经过依赖与结构校验后生成带 Manifest 的制品,并接入 JSON、FlatBuffers 和自定义二进制格式。工程上还要处理并发构建、临时目录、失败清理、缓存键和 Android/iOS 的差异,目标是同一输入和工具版本得到可验证结果。
必备追问
- 为什么必须冻结输入?
- Processor DAG 怎样声明依赖和缓存?
- 发布失败为何不能覆盖旧制品?
- 二进制化解决什么,又付出什么?
- 多端结果怎样验证一致性?
事实边界
可以说“参与制品体系和二进制化接入”;完整 ArtifactBuilder 与所有格式并非都由个人从头设计时,不说“独立设计整套发布系统”。
简历行:建立 UI 自动化与研发效率工具
30 秒回答
UI 自动化方面,我参与把 PixUI 页面从纯像素界面变成可被测试框架识别的语义节点,通过稳定 ID、状态和边界信息支持白盒查询与操作。工程效率方面还做过崩溃自动分派、地图解析和 AI 辅助研发资产。共同思路是把人工经验转换成有输入、规则、结果和人工兜底的工具链。
必备追问
- 为什么坐标点击不可靠?
- 稳定 ID 谁生成,怎样跨版本保持?
- Crash 怎样从调用栈映射到责任代码?
- 自动分派如何处理低置信度和误报?
事实边界
不说未经验证的覆盖率、节省工时或团队采用人数。
简历行:连续两次获得最高绩效
30 秒回答
这项结果来自两个连续考核周期。我认为它主要反映了复杂需求交付、跨模块问题处理和长期维护的综合表现。面试里我不会把绩效当成技术证明,而会用具体项目说明为什么能得到这个评价。
四、实习与研究经历追问
PPO 关卡 AI 做了什么?
我在实习中搭建了训练与评估链路,让 PPO 控制角色完成指定关卡目标,并做了 Gameplay Demo 和基线对比。重点收获是状态、动作、奖励和评估口径必须围绕真实游戏目标设计。原简历中的具体通过率和速度数字目前不作为主张,除非能补齐当时报告和口径。
可能追问:奖励稀疏、观测空间、动作离散化、训练与真实运行差异、为什么不用行为树或 EQS。
CAE 经历与游戏有什么关系?
它建立了我的 C++、几何数据结构、性能分析和大型工程基础。B-Rep 与网格工作要求处理拓扑一致性、数值鲁棒性和大数据规模,这些能力后来迁移到资源、内容模型和运行时问题上。但 CAE 年限不计入游戏客户端年限。
可能追问:半边结构、拓扑与几何分离、网格质量、空间索引、并行与内存局部性。
论文和专利为什么保留?
它们只作为算法与研究能力的辅助证明,不是当前岗位主线。简历压缩为一行,是为了把版面留给近三年的客户端系统工作。
五、行为问题的案例路由
最大的失败是什么?
一次真实教训是面试中把 UGC2.0 工作概括为“做了 PixUI 封装”。这个说法既没有业务目标,也没有架构坐标,面试官追问 TS、Lua、C++ 怎么通信时,我临场才开始拼链路,导致表达失焦。复盘后我把工作还原成页面协议、生命周期、原生所有权和状态一致性,并建立了逐层追问材料。这个问题本质上不是没做过,而是没有把经验提炼成可传递的设计判断。
与同事有不同意见怎么办?
首选案例:页面业务是否直接调用原生能力。
我会先把分歧改写成可比较的约束,例如交付速度、浏览器可测性、生命周期风险和协议成本,再做最小链路验证。短期直连可能更快,但长期会让页面持有引擎细节;最终方案可以允许少量受控原生能力,同时让多数业务经过稳定 transport。重点不是谁说服谁,而是方案与约束可追踪。
需求很急时怎样保证质量?
首选案例:地图交付或多端构建。
先定义最小可交付闭环和不能妥协的底线,例如数据不损坏、失败可回退、关键链路可观测;次要体验和自动化覆盖按风险分期。上线前准备开关、旧版本兼容和失败清单,上线后再把临时路径收敛进正式边界。急不能成为跳过所有权和恢复设计的理由。
如何证明你有 owner 意识?
owner 不等于所有代码都自己写,而是目标、依赖、风险和结果有人持续闭环。我会说明自己怎样从需求澄清推进到协议、实现、联调、构建、灰度和线上维护,并明确哪些部分由其他同事负责。最适合的案例是 UGC2.0 页面基础设施或 UGC1.0 地图交付链路。
六、面试前检查表
- 每条简历经历都有一个 30 秒回答和一个 3 分钟案例。
- 每个案例都能画出数据流、状态所有者和失败路径。
- “我负责”“我参与”“我复盘理解”三个口径没有混用。
- 所有数字都能解释基线、样本、采集方式和时间范围。
- 技术名词能落到为什么需要、如何实现、代价是什么。
- 至少准备一次失败、一次冲突、一次线上问题和一次技术取舍。