一、难题候选库

ID	真实现象	可体现的判断	证据	下一步要补
`D01`	移动端封面图审核与 ASTC 压缩在部分机型超过可接受时长	把编码链拆成算法、线程、I/O 与体验预算	`A`	前后耗时、机型、线程数、质量参数
`D02`	极差网络下 AI 参考图操作无响应，服务端报错时编辑流程失去反馈	异步任务必须有状态机、超时、幂等和恢复入口	`A`	完整状态转移和失败率
`D03`	简易/专家模式切换后，元件栏、管理器和碰撞状态互相泄漏	两套 UI 不能各自持有同一业务状态	`A`	状态权威、迁移方案和回归测试
`D04`	四足对象编辑出现 Gizmo 遮挡选取、放置抖动、缩放视角异常	选择、射线、碰撞、相机和模型尺度是一个交互系统	`A`	根因链与最终统一方案
`D05`	快速连续保存触发地图上传失败	保存需要串行化、去重、事务边界和可观察结果	`A`	请求时序、锁/队列方案、失败恢复
`D06`	列表滚动后初始地图项消失，切页也无法恢复	虚拟列表、缓存 Key 与异步分页的一致性	`A`	复现条件、根因和测试
`D07`	低版本移动 WebView 使用不兼容接口	运行时能力检测优于仅按系统版本判断	`A`	兼容矩阵、polyfill/降级边界
`D08`	弱网进入配置页面后落入 502 错误页，无法退出或重连	错误页也必须属于客户端导航和会话状态机	`A`	宿主与 SSR 各自的恢复责任
`D09`	PixUI 共享 SDK 与包结构混乱，应用能单独运行却难以稳定构建发布	包边界、依赖方向、应用注册和制品身份要统一	`A`	重构前依赖图与迁移成本
`D10`	UGC2 页面重建后，旧页面消息仍可能覆盖新状态	用页面代次拒绝迟到消息，生命周期进入协议	`A`	竞态时序和故障注入测试
`D11`	TypeScript、C++、Luau 链路可能丢消息、重复处理或双方状态不一致	序号、确认、回退队列和版本化状态各解决不同问题	`A`	明确每种机制的触发条件
`D12`	页面关闭后原生回调或根引用仍存活	销毁必须解除回调、引用和状态订阅，不能只隐藏 UI	`A`	泄漏/崩溃证据和析构顺序
`D13`	制品在不同环境出现缺文件、格式回退或 Windows 发布差异	构建应是可校验的处理器流水线，而非文件复制脚本	`A`	制品清单、确定性校验和回滚
`D14`	UI 自动化找不到稳定节点，PixUI 与原生 UI 无统一可测试表面	业务 ID、DOM/树适配和驱动协议应在产品代码中设计	`A`	覆盖率、流水线结果和维护成本
`D15`	多人高密度玩法需要启用并定制复制图	相关性、更新频率、状态与事件分离决定带宽	`B`	十二人/数百对象配置、抓包与前后对比
`D16`	自动分单若只按报错标题匹配，极易把问题派给错误的人	从异常栈定位文件和行号，再结合 Git blame；同时保留文件/人员白名单与人工处理优先级	`A`	覆盖量、准确率、人工兜底率和误分案例
`D17`	地图二进制存在多种容器、压缩/加密与 Schema，线上文件难以直接诊断	把解包、解密、反序列化、业务提取和 GUI/批处理分层	`A`	典型坏包、兼容矩阵和团队使用数据
`D18`	AI 助手能生成大量知识文件，但错误也会被快速复制	规范、索引、专用技能、审计报告和源码验证必须形成闭环	`A`	采用率、命中率、返工率和人工审核成本

二、优先深挖顺序

第一梯队用于架构面试：D10、D11、D13、D15。它们分别覆盖生命周期、跨语言可靠性、交付确定性和网络规模。

第二梯队用于业务与工程判断：D01、D03、D04、D08。它们能说明如何从用户问题推导模块边界，而不是只展示修 Bug。

第三梯队用于质量体系：D05、D07、D12、D14。适合回答稳定性、兼容性、自动化和防复发。

每个案例完成前必须补齐：现象、影响面、本人角色、排除过程、根因、方案选择、结果数据、防复发。缺结果数据时可以讲判断和机制，但要主动说明验证缺口。

三、公开脱敏词典

内部信息类型	公开替代词	处理规则
具体产品名	大型跨端派对游戏	自我介绍可按公开简历决定是否保留，技术文章默认替换
旧 UGC 项目代号/赛季	UGC1.0 / 成熟 UGC 平台	删除赛季、版本包和内部缩写
新 UGC 项目代号	UGC2.0 / 新一代 UGC 平台	不暴露组织或仓库代号
特色玩法代号	非对称竞技玩法 / 搜打撤玩法	只保留公开玩法类别
内部 Web 产品名	游戏内 Web UI / 可视化编程 IDE	不暴露 appId 和运营活动名
内部服务与平台	内容服务、AI 服务、发布平台、对象存储	删除域名、账号、地域和供应商配置
仓库和磁盘路径	UGC 功能仓、原生插件、Web 多应用仓	不展示盘符、内部 Git 地址和目录全名
类名/协议名	页面宿主、消息协议、编辑服务	只有解释设计必须时才保留通用类型名
工单/分支/流水线	线上问题、稳定分支、发布流水线	删除编号、链接、参数和人员名
未公开指标	规模级别或机制性结果	只有简历已公开且能证明口径时才使用精确值
用户与日志数据	匿名样本或聚合结论	不保存账号、地图 ID、原始日志和截图中的身份信息

四、公开稿检查

发布前逐项搜索并处理：

盘符、内部域名、仓库 URL、账号和 Token。
工单号、分支名、赛季号、包版本和流水线参数。
未公开产品代号、组织名、同事姓名和群信息。
真实用户 ID、地图 ID、请求体、日志和服务错误详情。
没有基线和环境的性能数字。
把团队结果写成个人主导的动词。

源码和提交只用于证明事实，不直接复制到公开文章。需要展示代码时，改写为最小伪代码，并删除内部类名、协议字段和资源名称。

五、面试口头脱敏

面试官追问内部细节时，可以这样守住边界：

具体项目名、接口字段和线上数据不方便展开，但我可以把状态所有权、消息时序、失败模式和我们采用的验证方法讲清楚。

这不是回避问题。真正能证明架构能力的是约束、选择和证据，而不是泄露内部名词。