你可以直接这样回答
我会先说明场景、平台和瓶颈，再讲我负责的一个关键动作，最后给出在固定设备和镜头下的前后指标。除了 FPS/GPU/内存，我也会说画质和副作用；没有原始数据时，我会明确这是验证计划而不是已发生的结果。
这道题真正想听什么？
先确认比较对象和回答边界，再决定要不要展开公式、工程实现或性能取舍。
它考的是你能不能把“我优化过”变成一条可复盘的 STAR 证据链：Situation/Task 说清场景和目标，Action 说清你亲自做的判断，Result 说清基线、条件、量化结果和副作用。大厂面试官还会追问为什么不选另一条路、谁验收、怎么回滚；只有一个漂亮百分比而没有实验条件，不能证明优化有效。
把答案讲到 2 分钟面试必答 · 约 2 分钟 · 补足因果、输入和取舍
我会用 STAR 讲一个最小闭环：当时目标是把代表性场景稳定在目标帧时间，任务是找出真正瓶颈；我先采集 baseline，再只改提交/过绘/采样中的一项，比较 GPU、CPU、带宽、内存和画质。最终选方案不是看单个最大数字，而是结合交付期限、维护成本和低端 fallback。结果会写出测试条件和失败边界，并保留回滚点。
面试官可能继续追问什么？补充自测 · 约 3 分钟 · 检查自己是不是真的懂了
- 问：FPS 提升 20% 就够了吗？ 答：不够。要说设备、分辨率、镜头、采样方式和 p95/p99；平均值可能掩盖尖峰、温度降频或画质损失。
- 问：怎样证明结果来自我的方案？ 答：保留基线，固定镜头和设备，只改关键变量；必要时做回退对照或 A/B，并说明团队成员负责的其他改动。
- 问：优化和质量冲突时怎么讲？ 答：先说产品要保留的视觉重点，再公开质量、性能、制作效率和风险权重，最后给出可以回滚的档位，而不是声称“全都要”。
- 因果链： 基线 → 假设 → 单变量实验 → 指标/画面对照 → 取舍 → 目标设备复测与回滚。
如果概念还是悬空，就去做实验关键证据 · 约 5–15 分钟 · 预测 → 单变量 → 观察
实验不是第二份答案，它只负责证明答案
如果上面的解释已经听懂，可以直接跳过。卡住时，再沿着这三步把抽象词变成画面证据。
- 先猜 目标和约束是什么？你亲自做了哪个判断？哪条证据能证明结果不是团队叙事？
- 去取证 固定其他条件，只改一个参数。先写下变化，不用“更真实”“更高级”这种空词代替证据。
- 再追问为什么 是哪一步造成这个结果？如果结果相反，先检查输入、空间、算法，还是显示输出？
我完全没头绪，给我一个起点
先截下默认状态，只动页面当前开放的那个参数。你只需要说清楚“原来怎样 → 改了什么 → 现在怎样”。
1. 先预测
打开 Production Case Lab，先用 caseId=mobile-pbr、platform=mobile、targetMs=16.7、deadlineWeeks=2、teamSize=2、view=decision。预测把 view 切到 tradeoffs、priority=performance 后，推荐方案可能变化；把 evidenceLevel 从 1 调到 3，回答会从“方向”变成“可验证计划”。再在 Interview Defense Lab 选 scene=star、debugMode=evidence。输入 → 变化 → 输出： 场景基线/目标 → 一个优化动作 → GPU ms、FPS、内存、画质和风险的前后证据。
老师追问
先别急着查答案： 先把回答当成一个可验证的决策：目标、约束、职责和证据分别在哪里？
为什么： 你刚才的预测依赖哪个前提？如果把“TA 优化 STAR”里最关键的变量或约束关掉，回答或决策会先坏在哪里？
如果结果相反： 先排除哪一层，再谈结论？这个规则的边界是什么？
2. 再动手
在 Production Case 里固定 caseId=mobile-pbr，依次只改 strategy=builtin-first/hybrid-prototype/custom-pipeline；记录 selected/recommended、target ms、evidence level、risk flag 和 answer。再把 platform 切到 desktop，观察同一个方案为什么不一定仍然合理。Interview Defense 里只改 metricClarity 和 failureDepth，把缺少的条件补回 30 秒回答。最后用真实或练习项目写一张表：基线、改动、FPS/GPU/内存、画质验收、失败边界、回滚 token。
3. 最后对证据
Production Case 的策略分数会随平台、优先级、工期和风险变化；它不是实际 Unity Profiler，而是帮你练习把权重说出来的教学模型。证据等级提高后，回答会要求 baseline、debug view、目标设备和 fallback。Interview Defense 会把“结果没有条件”标成追问风险。最终量化数字必须来自你的日志、capture 或目标设备；Lab 的数字只能用来练习表达结构。
答案在代码哪里发生？实现定位 · 约 3 分钟 · 变量、函数和关键行
- Frame constraints：项目目标、平台、预算和期限的入口。
- Trade-offs：质量、性能、交付和风险如何公开取舍。
- Evidence plan：baseline、单变量、目标设备和失败边界。
- Interview rubric：STAR 的 context/action/result/failure/ownership。
- Risk：用代价和 fallback 防止“只有成功没有边界”。
完整 5 分钟版本面试扩展 · 约 5 分钟 · 项目边界、验证与降级
完整复盘还要交代资产规模、版本、设备矩阵、p95 长帧、温度和验收人。我会列出尝试过但放弃的方案，说明它为什么在另一个指标上变差；把工具/规则/材质变体怎样进入团队流水线说清楚。若项目经历还不够，我会用本 Lab 做一份实验报告，标注“教学估算”和“待真机复测”，不把推演包装成线上收益。
哪些说法最容易答歪？必看陷阱 · 约 1 分钟 · 面试前最后检查
- 只报优化百分比，不报基线、设备、分辨率和镜头。
- 把教学 Lab 的估算当作真实 GPU capture。
- 把团队结果全部归给自己，或说不清谁负责验收和回滚。
- 只讲成功路径，不讲画质损失、热降频、内存峰值和 fallback。
- 用“我会优化 shader”代替具体可验证的假设和单变量实验。
先分清事实和推演
这是一道经历题，范文不能替你作证
只写亲自参与且能被追问的事实。没有经历，可以写“待验证计划”，但不要把教程示例说成自己的项目。