AI 时代技术面试：性能优化跑分快了，为什么还会被追问？

“性能提升了一倍。”面试官接着问：“输出顺序变了吗？内存多用了多少？换一组输入还快吗？”Anthropic 在 2026 年 1 月的技术测评文章中介绍过随模型能力变化调整性能题的经历。这是一个团队的做法，不能推成所有公司的统一标准。本文专门练习怎样解释优化，而不是猜真实题库。

练习约束变化，而不是只背解题模式

拿一道熟悉的题，只改一个约束：内存受限、写入最终一致，或依赖服务可能超时。说明哪些假设失效、哪些部分保留、设计如何变化。难点不在记忆，而在适应约束。

用调试过程展示独立判断

把调试当成主训练。面对失败测试、日志或指标时，按窄假设循环来讲：复现、隔离、测量、修复、重跑。不要一上来就大改。即使允许使用 AI，面试官仍能观察这个过程。

说清楚性能收益的代价

好的系统设计回答必须说清楚优化什么、牺牲什么。比如队列提高韧性却增加新鲜度延迟，缓存降低延迟却让失效更复杂。真正的信号在取舍。

推演：批处理更快了，却悄悄改变了结果

假设任务是读取一批事件、标准化，再按输入顺序输出。AI 建议改成并行 worker，小样本计时明显变快。但第一个事件较慢，后面的事件先返回，结果顺序也跟着变了。问题不在代码是不是 AI 写的，而在优化改变了调用方依赖的合同。

接受补丁前，先列出必须保留的行为：输出顺序、错误呈现、内存上限，以及任务能否取消。区分硬要求和可以讨论的条件。“用并发”只是实现想法，不是验收目标。

构造三个事件，让第一个刻意处理得慢，检查输出顺序是否仍正确。再让中间事件失败，确认剩下的事件应该继续、停止，还是返回部分结果。如果只是吞掉失败换来了更低耗时，这个优化就站不住脚。

一次只验证一种性能解释

在相同输入、并发限制、依赖状态和测量方法下，对比原版与有界 worker 版本。冷启动和稳定运行要分开记录，同时观察耗时与内存：为了恢复顺序而缓存已完成结果，可能显著增加空间占用。

如果只在大批次上有收益，就把结论限定在这个负载。可以提出按批次大小切换，但新阈值又增加了待验证行为。有时更合理的结论是保留顺序处理，等真实负载足以支撑额外协调成本时再改。

把结论练成经得起条件变化的回答

可以这样说：“并行处理降低了本次大批次测试的耗时，但初版破坏了输出顺序。我用有界缓冲恢复顺序，只有内存和取消测试也通过才保留这个改动。”这句话同时包含结果、缺陷、修复和接受条件。

再改变一个前提：如果每个事件都调用限流服务呢？如果后一个事件依赖前一个呢？如果整个批次可能重试呢？答案可能变成减小 worker 数、继续串行，或者先解决幂等。不要在原前提消失后还为并发辩护。

代码练完后，再做一轮纯口头解释。让同伴听到“更快”“安全”“可扩展”就追问依据，直到每个结论都能对应负载和验证。最终方案朴素没有关系，能说清楚什么时候不用它才说明理解到位。

常见问题

这类面试一定禁止 AI 工具吗？

不一定。是否允许取决于雇主和面试阶段。准备时先确认规则，同时确保自己的推理过程能够独立展示。

不熟悉某个库的细节怎么办？

说清楚已知边界，指出需要确认的接口，并提出一个小验证。诚实核实比装作确定更可靠。

LeetCode 还有用吗？

有。先练模式，再加入新约束、测试和解释训练，避免只背模板。

参考来源

• Anthropic: Designing AI-resistant technical evaluations

下一步

接着阅读真实任务调试面试指南。练习时可以把自己的案例整理进 Interview AiBox 面试档案，但工具不会自动替你核实项目成果。

• 功能全景
• 当前版本说明
• 产品路线图
• 下载 Interview AiBox