设计抗 AI 的技术面试评估¶
原文发布于 2026 年 1 月 21 日，作者 Tristan Hume（Anthropic 性能优化团队负责人）
Take-Home 的起源¶
一次突发的招聘需求催生了这个 take-home 项目。 2023 年 11 月，Anthropic 正准备用新的 TPU/GPU 集群和大型 Trainium 集群训练 Claude Opus 3。团队需要更多性能工程师，但常规面试流程无法应对。Tristan 在 Twitter 上发帖让感兴趣的人发邮件，结果收到的简历远超常规流程所能处理的量。
他花了两周设计了一个 take-home 测试，以便更高效地筛选候选人。
设计目标¶
好的 take-home 应该既有信号量又有趣，而不是枯燥的通用题。 相比现场面试，take-home 格式在性能工程评估上具有独特优势：
| 优势维度 | 说明 |
|---|---|
| 更长的时间跨度 | 4 小时（后缩减为 2 小时）更贴近真实工程工作的节奏 |
| 真实的工作环境 | 候选人在自己的编辑器中工作，没有人盯着 |
| 理解和工具使用的空间 | 性能优化需要先理解系统并构建调试工具 |
| 兼容 AI 辅助 | 候选人可以使用 AI 工具，和真实工作中一样 |
通用面试设计原则：
| 原则 | 说明 |
|---|---|
| 贴近真实工作 | 题目应反映实际工作内容 |
| 高信号量 | 评分分布广、多次展示能力的机会、强者做不完的深度 |
| 不要求特定领域知识 | 好的基本功比狭窄的专业知识更重要 |
| 有趣 | 快速反馈循环、有深度的有趣问题、创造性发挥空间 |
模拟机器¶
核心创意：用 Python 模拟器构建一台假加速器，候选人在上面优化代码。 Tristan 构建了一台类似 TPU 的模拟加速器，候选人需要优化运行在上面的代码，同时通过热重载的 Perfetto trace 观察每条指令的执行情况。
机器包含的特性：
- 手动管理的暂存内存（显式内存管理）
- VLIW（每个周期多个执行单元并行运行）
- SIMD（对多个元素执行向量运算）
- 多核（将工作分配到多个核心）
任务是并行树遍历——故意不设计成深度学习风格，灵感来自无分支 SIMD 决策树推理。候选人从串行实现开始，逐步利用各种并行性。热身环节是多核并行，然后候选人可以选择 SIMD 向量化或 VLIW 指令打包。原始版本还包含一个需要先调试的 bug。
早期成果¶
take-home 的预测性极强——最高分的候选人入职第一天就开始优化内核了。 Twitter 那批候选人中得分最高的在 2 月初入职，"立刻就开始优化内核"，还找到了一个阻塞发布的编译器 bug 的变通方案。一年半来约 1000 名候选人完成了测试，帮助团队招到了目前大部分性能工程师。
这个 take-home 对简历经验不够丰富的候选人特别有价值——几位表现最好的工程师来自本科阶段，但在测试中展现了足够的能力。
许多候选人超时做题纯粹是因为觉得有趣。最强的无限时间提交包含了完整的优化型迷你编译器和出人意料的巧妙优化。
Claude Opus 4 击败了它¶
到 2025 年 5 月，过半候选人还不如直接把题交给 Claude Code 做。 Claude 3.7 Sonnet 达到了一个水平：超过 50% 的候选人如果把整个任务委托给 Claude Code 会得到更好的结果。预发布的 Claude Opus 4 在 4 小时限制内产出了比几乎所有人类更优化的方案。
Tristan 指出这不是他第一次面试题被 Claude 击败——2023 年他专门设计了一道强调问题解决而非知识的现场题，但 Claude 3 Opus 打败了第一部分，Claude 3.5 Sonnet 打败了第二部分。
版本 2 的修复策略： 用 Claude Opus 4 找出它开始挣扎的地方，以此作为新的起点。重写了更干净的初始代码，增加了新的机器特性，移除了多核部分，时间从 4 小时缩短到 2 小时。版本 2 强调巧妙的优化洞察，而非调试和代码量。
Claude Opus 4.5 又击败了它¶
Opus 4.5 在不到一小时内就达到了通过标准，2 小时内追平了人类最佳表现。 预发布的 Claude Opus 4.5 解决了初始瓶颈，实现了常见的微优化，不到一小时就达到了通过阈值。然后它停了下来，认为自己遇到了内存带宽瓶颈。当被告知可达到的周期数时，它找到了关键技巧。到 2 小时时，它的得分追平了该时限内的人类最佳表现。
考虑可选方案¶
Tristan 拒绝了禁止 AI、也拒绝了简单提高门槛，因为两者都不符合真实工作场景。
禁止 AI？¶
不行。执行难度大，而且从哲学上讲——人们应该能在有 AI 的环境中脱颖而出，就像在真实工作中一样。
简单提高门槛？¶
也不行。要求"显著超越 Claude Code 的独立表现"听起来合理，但 Claude 的工作速度太快——人类一半时间在阅读和理解代码，而 Claude 立刻就开始优化了。
现实中的工作方式在变¶
Anthropic 的性能工程师现在更多时间花在：调试、系统设计、性能分析、正确性验证、代码简化——这些很难在没有时间积累或共同上下文的情况下客观测试。
尝试 1：换一个优化问题¶
设计了一个基于 2D TPU 寄存器数据转置和避免 bank conflict 的问题，但 Claude 找到了人类没想到的优化方法。 Tristan 设计了一个关于高效数据转置的问题，让 Claude 不到一天就实现了各种变更。
Claude Opus 4.5 发现了 Tristan 没想到的优化——转置整个计算而非数据本身。封堵这条路后，Claude 确实挣扎了，但最终通过 "ultrathink"（更长的思考预算）解决了问题。它"甚至知道修复 bank conflict 的技巧"。
反思：这个问题方向不对，因为各平台的工程师已经大量撰写过关于转置和 bank conflict 的文章，Claude 有充足的训练数据。
尝试 2：走更怪异的路线¶
关键洞察：需要足够"分布外"的问题，让人类推理能力胜过 Claude 的庞大经验库。 Tristan 从 Zachtronics 编程解谜游戏（如 Shenzhen I/O）中获得灵感，这类游戏使用非常规的、高度受限的指令集。
他设计了一个新的 take-home，包含使用微型受限指令集的谜题，目标是最小化指令数。在 Claude Opus 4.5 上测试——它失败了。同事验证了人类确实能超越 Claude。
一个有意设计的特点： 不提供可视化或调试工具。构建调试工具本身就是被测试的能力之一——候选人可以插入 print 语句或让编程模型生成交互式调试器。
Tristan 对新的 take-home "基本满意"，但指出它可能比原版方差更低，因为它由更多独立子问题组成。早期结果显示得分与候选人过去的工作质量有良好相关性。
他反思道：
"原来的版本有效是因为它像真实工作。替代版本有效是因为它模拟了新颖的工作。"
开放挑战¶
原始 take-home 现已公开发布，作为无限时间挑战。 在足够长的时间跨度下，人类专家仍然对当前模型保持优势。
性能基准（时钟周期数，越低越好）¶
| 周期数 | 达成者 |
|---|---|
| 2164 | Claude Opus 4，在测试时计算框架中运行数小时 |
| 1790 | Claude Opus 4.5，在普通 Claude Code 会话中（约等于人类 2 小时最佳表现） |
| 1579 | Claude Opus 4.5，在测试时计算框架中运行 2 小时 |
| 1548 | Claude Sonnet 4.5，在测试时计算框架中运行远超 2 小时 |
| 1487 | Claude Opus 4.5，在框架中运行 11.5 小时 |
| 1363 | Claude Opus 4.5，在改进的测试时计算框架中运行数小时 |
GitHub 仓库：https://github.com/anthropics/original_performance_takehome
如果你能优化到 1487 周期以下（超越 Claude 发布时的最佳成绩），请将代码和简历发送至 [email protected]。
或者，你也可以通过 Anthropic 的常规流程申请——该流程使用新的抗 Claude take-home。文章最后写道：
"我们很好奇它能撑多久。"