你可以直接这样回答
我会先把美术目标和目标设备写成共同约束，再用固定镜头的前后对照和 profiler 数据说明成本，最后给出保留关键视觉点的分阶段方案。沟通时我会分别说玩家感知、工程指标和制作成本，确认 owner、验收条件和回滚点，而不是用一句“性能不够”结束讨论。
这道题真正想听什么？
先确认比较对象和回答边界，再决定要不要展开公式、工程实现或性能取舍。
它考你能不能把争论从“我觉得好看/我觉得会卡”变成共享证据。优秀的 TA 不替任何一方简单站队，而是先把玩家目标、画面重点、目标设备、帧/内存/带宽预算、制作期限和回滚成本说清楚，再给出多个可比较方案。题目要求“成功说服”时，成功不一定是坚持原方案，也可能是让团队接受一个更稳的降级或分阶段交付。
把答案讲到 2 分钟面试必答 · 约 2 分钟 · 补足因果、输入和取舍
我会准备至少两个可交付方案：质量更高的方案和成本更稳的方案。固定基线，只改一个变量，比较画面辨识度、GPU/CPU、带宽、内存、制作时间和维护风险；把权重公开给程序、策划和美术。最后选择当前版本最适合的点，保留关键轮廓/节奏，其他部分进质量档位或后续迭代。真实案例要说清我负责的证据、团队如何决策，以及结果如何验收。
面试官可能继续追问什么？补充自测 · 约 3 分钟 · 检查自己是不是真的懂了
- 问：程序说“太贵”，我是不是直接砍效果？ 答：先问贵在哪：提交、过绘、采样、带宽、内存、CPU 更新还是制作维护。不同成本对应不同替代，不能用一个“关掉”解决所有问题。
- 问：策划只关心画面，怎么沟通？ 答：用代表性镜头、前后对照、目标设备和玩家感知指标说话，把“辨识度/节奏/可读性”与成本放到同一张表，不让对方读 profiler 原始日志。
- 问：成功说服团队必须是我赢吗？ 答：不必。能让团队根据证据选择分阶段方案、保留关键视觉点并接受明确成本，就是成熟的沟通结果。
- 因果链： 玩家/美术目标 → 约束和预算 → 方案对照 → 可读证据 → 共同取舍 → owner、时间点与回滚。
如果概念还是悬空，就去做实验关键证据 · 约 5–15 分钟 · 预测 → 单变量 → 观察
实验不是第二份答案，它只负责证明答案
如果上面的解释已经听懂，可以直接跳过。卡住时，再沿着这三步把抽象词变成画面证据。
- 先猜 目标和约束是什么？你亲自做了哪个判断？哪条证据能证明结果不是团队叙事？
- 去取证 固定其他条件，只改一个参数。先写下变化，不用“更真实”“更高级”这种空词代替证据。
- 再追问为什么 是哪一步造成这个结果？如果结果相反，先检查输入、空间、算法，还是显示输出？
我完全没头绪，给我一个起点
先截下默认状态，只动页面当前开放的那个参数。你只需要说清楚“原来怎样 → 改了什么 → 现在怎样”。
1. 先预测
打开 Production Case Lab，先选 caseId=screen-space-feature、view=tradeoffs、platform=cross-platform、priority=balanced、riskTolerance=medium。预测只把 priority=quality 或 priority=performance 改变，就会改变推荐策略；再只把 deadlineWeeks 从 4 调到 2，观察 delivery penalty 和分数变化。teamSize 在这个教学 math 里只是答案上下文，不会单独改变 risk/score，务必把它标成待真实项目补证的变量。Interview Defense 里设 scene=tradeoff、debugMode=tradeoff。输入 → 变化 → 输出： 视觉目标/设备/工期 → 公开权重和方案 → 共同接受的指标、边界和下一步。
老师追问
先别急着查答案： 先把回答当成一个可验证的决策：目标、约束、职责和证据分别在哪里？
为什么： 你刚才的预测依赖哪个前提？如果把“美术与性能取舍”里最关键的变量或约束关掉，回答或决策会先坏在哪里？
如果结果相反： 先排除哪一层，再谈结论？这个规则的边界是什么？
2. 再动手
在 Production Case 固定 caseId=screen-space-feature，只切换 priority，记录三个策略的质量/性能/交付/风险分数；然后只改 deadlineWeeks，确认只有期限约束改变分数，再把 teamSize 当作沟通上下文写进案例而不是伪造的数学因果。Interview Defense 里固定 scene=tradeoff，只降低 stakeholderAlignment 或 tradeoffClarity，观察追问；再恢复并写一段“我如何用 A/B 说服团队”的答案。把最终选择写成：保留什么、牺牲什么、谁验收、什么时候回滚。
3. 最后对证据
Production Case 会把“最漂亮”的方案和“当前最可交付”的方案区分开；权重和风险不同，推荐结果不同。Interview Defense 会把只讲技术、没有协作对象或没有取舍边界的回答暴露为追问。所有数字和分数都是教学模型；真实沟通要带项目基线、设备 capture、画面录屏和团队决策记录。
答案在代码哪里发生？实现定位 · 约 3 分钟 · 变量、函数和关键行
- Trade-off score：公开质量、性能、交付和风险权重。
- Frame constraints：先把平台、预算、期限和成功指标放到共同语境。
- Evidence plan：用 baseline、单变量和目标设备证据代替立场。
- Interview follow-ups：把协作中没有回答的问题变成下一步。
- Interview risk：主动说代价和 fallback，减少“只会推销”的风险。
完整 5 分钟版本面试扩展 · 约 5 分钟 · 项目边界、验证与降级
完整案例还要讲冲突发生在哪里、我先听懂了谁的成功标准、如何做小实验和可视化、谁参与 review、哪条方案失败以及为什么。成功说服可能是把一个全量高成本效果改成近景高档/远景低档，或者把风险拆成先做 vertical slice、再进量产。最后交付的不是一张 PPT，而是配置、预算、验收报告和回滚版本。如果没有亲身项目，我会把 Lab 练习明确写成推演，不冒充团队经历。
哪些说法最容易答歪？必看陷阱 · 约 1 分钟 · 面试前最后检查
- 把沟通描述成“我说服了大家”，却没有证据和对方的成功标准。
- 只报 GPU 数字，不说画面辨识度、制作时间和维护风险。
- 直接砍效果，不拆成本来源，也不给替代方案。
- 把团队共同决策说成个人英雄故事。
- 没有验收 owner、截止时间和回滚条件。
先分清事实和推演
这是一道经历题，范文不能替你作证
只写亲自参与且能被追问的事实。没有经历，可以写“待验证计划”，但不要把教程示例说成自己的项目。