设计抗AI的技术评估
随着人工智能能力的提升，评估技术候选人变得越来越困难。今天能很好区分人类技能水平的带回家测试，明天可能被模型轻易解决——从而失去评估价值。
自2024年初以来，我们的性能工程团队一直在使用一项带回家测试，让候选人针对模拟加速器优化代码。已有超过1,000名候选人完成了该测试，其中数十人如今在这里工作，包括搭建我们Trainium集群的工程师，以及自Claude 3 Opus以来发布每一款模型的工程师。
但每一个新的Claude模型都迫使我们重新设计测试。在相同的时间限制下，Claude Opus 4的表现超过了大多数人类申请者。这仍然让我们能够区分最强的候选人——但随后Claude Opus 4.5甚至追平了这些顶尖候选人。在不限时间的情况下，人类仍然可以超越模型，但在带回家测试的限制下，我们不再有办法区分顶尖候选人的产出和我们最强大模型的产出。
我已经迭代了三个版本的带回家测试，试图确保它仍然具有区分度。每一次，我都学到了新的东西：什么能让评估对AI辅助具有鲁棒性，什么不能。
本文介绍了原始带回家测试的设计、每个Claude模型是如何击败它的，以及我不得不采取的越来越不寻常的方法，以确保我们的测试始终领先于我们最强大模型的能力。虽然我们所做的工作已经随着模型的发展而演进，但我们仍然需要更多优秀的工程师——只是需要越来越有创意的方式来找到他们。
为此，我们将原始带回家测试作为一项公开挑战发布，因为在不限时间的情况下，最优秀的人类表现仍然超过Claude所能达到的水平。如果你能超越Opus 4.5，我们很乐意收到你的消息——详情见本文底部。
带回家测试的起源
2023年11月，我们正准备训练并推出Claude Opus 3。我们已经获得了新的TPU和GPU集群，我们的大型Trainium集群即将到来，我们在加速器上的花费比过去多得多，但我们没有足够的性能工程师来匹配新的规模。我在Twitter上发帖请人们给我们发邮件，这带来了比我们通过标准面试流程能评估的更多的有潜力的候选人，而这个流程会消耗员工和候选人大量时间。
我们需要一种更高效地评估候选人的方法。因此，我花了两周时间设计了一项带回家测试，以充分捕捉该职位的要求，并识别最有能力的申请者。
设计目标
带回家测试名声不佳。通常它们充斥着工程师觉得无聊的通用问题，而且作为筛选手段效果不佳。我的目标不同：创造一些真正引人入胜的东西，让候选人兴奋地参与其中，并让我们能够以高分辨率捕捉他们的技术技能。
这种形式在评估性能工程技能方面也比现场面试具有优势：
更长的时间跨度：工程师在编码时很少面临少于一小时的截止日期。4小时的窗口（后来缩短为2小时）更好地反映了工作的实际性质。它仍然比大多数真实任务短，但我们需要平衡这一点与它带来的负担。
真实的环境：没有人旁观或要求讲解。候选人在自己的编辑器中工作，不受干扰。
理解与工具构建所需的时间：性能优化需要理解现有系统，有时还需要构建调试工具。这两点在正常的50分钟面试中都很难进行现实评估。
与AI辅助的兼容性：Anthropic的通用候选人指南要求候选人在未另行说明的情况下，不使用AI完成家庭作业。对于本次家庭作业，我们明确另行说明了。
时间跨度较长的问题更难被AI完全解决，因此候选人可以使用AI工具（就像他们在工作中会做的那样），同时仍需展示自己的能力。
除了这些特定形式的目标之外，我还应用了在设计任何面试时所使用的相同原则来设计这份家庭作业：
真实工作的代表性：该问题应让候选人体验到工作的实际内容。
高信号度：家庭作业应避免依赖单一洞察的问题，确保候选人有许多机会展示其全部能力——尽可能减少运气因素。它还应具有广泛的评分分布，并确保足够的深度，使即使是优秀的候选人也无法完成所有内容。
无需特定领域知识：基础扎实的人可以在工作中学习具体细节。要求狭窄的专业知识会不必要地限制候选人范围。
趣味性：快速的开发循环、有深度的有趣问题，以及发挥创造力的空间。
模拟机器
我构建了一个Python模拟器，用于模拟一个具有类似TPU特性的假加速器。候选人优化在这台机器上运行的代码，使用支持热重载的Perfetto跟踪来显示每条指令，类似于我们在Trainium上拥有的工具。
这台机器包含使加速器优化变得有趣的特性：手动管理的暂存内存（与CPU不同，加速器通常需要显式内存管理）、VLIW（多个执行单元每个周期并行运行，需要高效的指令打包）、SIMD（每条指令对多个元素进行向量操作）以及多核（在多个核心之间分配工作）。
该任务是并行树遍历，刻意不采用深度学习风格，因为大多数性能工程师尚未从事过深度学习工作，可以在工作中学习领域细节。该问题的灵感来自无分支SIMD决策树推理，这是一个经典的机器学习优化挑战，作为对过去的致敬，只有少数候选人之前遇到过。
候选人从完全串行的实现开始，逐步利用机器的并行性。热身阶段是多核并行，然后候选人选择是处理SIMD向量化还是VLIW指令打包。原始版本还包含一个bug，候选人需要先进行调试，从而锻炼他们构建工具的能力。
初步结果
最初的作业效果很好。Twitter批次中的一人得分明显高于其他人。他在二月初开始，比我们通过标准流程招聘的首批员工晚两周。该测试被证明具有预测性：他立即开始优化内核，并为一个涉及张量索引数学运算溢出32位的启动阻塞性编译器bug找到了变通方法。
在接下来的一年半里，大约有 1,000 名候选人完成了家庭作业，它帮助我们招聘了当前性能工程团队的大部分成员。对于履历上经验有限的候选人来说，它尤其有价值：我们一些表现最出色的工程师直接来自本科，但在家庭作业中展现了足够的技能，让我们能够放心录用。
反馈是积极的。许多候选人超过了 4 小时的限制，因为他们乐在其中。在不限时的提交中，最强的作品包括完整的优化迷你编译器和几个我未曾预料到的巧妙优化。
然后 Claude Opus 4 击败了它
到 2025 年 5 月，Claude 3.7 Sonnet 已经悄然进步到超过 50% 的候选人完全委托给 Claude Code 会更好的程度。然后我在家庭作业上测试了 Claude Opus 4 的预发布版本。它在 4 小时限制内提出了比几乎所有人类都更优化的解决方案。
这不是我第一次被 Claude 模型击败的面试。我在 2023 年专门设计了一个现场面试问题，因为当时我们的问题是基于早期 Claude 模型拥有大量知识的常见任务，因此可以轻松解决。我试图设计一个需要更多问题解决能力而非知识的问题，仍然基于我在工作中解决过的一个真实（但小众）的问题。Claude 3 Opus 击败了该问题的第 1 部分；Claude 3.5 Sonnet 击败了第 2 部分。我们仍然使用它，因为我们的其他现场问题也不具备 AI 抗性。
对于家庭作业，有一个直接的解决方案。这个问题的深度远超任何人能在 4 小时内探索的范围，所以我使用 Claude Opus 4 来识别它开始挣扎的地方。这成为了版本 2 的新起点。我编写了更简洁的起始代码，添加了新的机器特性以增加深度，并移除了多核（Claude 已经解决了它，而且它只会减慢开发循环而不会增加信号）。
我还将时间限制从 4 小时缩短到 2 小时。我最初选择 4 小时是基于候选人的反馈，他们更倾向于降低在 bug 或困惑上卡住时的风险，但调度开销导致我们的流程出现数周的延迟。两小时更容易安排在周末。
版本 2 强调巧妙的优化洞察，而非调试和代码量。它为我们服务得很好——持续了几个月。
然后 Claude Opus 4.5 击败了它
当我测试预发布的 Claude Opus 4.5 检查点时，我看着 Claude Code 在这个问题上工作了 2 小时，逐步改进其解决方案。它解决了最初的瓶颈，实现了所有常见的微优化，并在不到一小时内达到了我们的通过阈值。
然后它停止了，确信自己遇到了无法逾越的内存带宽瓶颈。大多数人类也会得出同样的结论。但有一些巧妙的技巧可以利用问题结构来绕过该瓶颈。当我告诉 Claude 可以达到的周期数时，它思考了一会儿并找到了该技巧。然后它进行了调试、调优并实现了进一步的优化。到 2 小时标记时，它的得分与该时间限制内最佳人类表现相当——而那个人类大量使用了 Claude 4 并进行了引导。
我们在内部测试时计算框架中试用了它以获得更严格的验证，并确认它既能在 2 小时内击败人类，又能随着时间继续攀升。发布后，我们甚至以通用方式改进了框架，并获得了更高的分数。
我遇到了一个问题。我们即将发布一个模型，而在我们的家庭作业测试中，最佳策略将是委托给 Claude Code。
考虑各种方案
有些同事建议禁止使用 AI 辅助。我不想这么做。除了执行上的困难之外，我有一种感觉：既然人们在我们的工作中继续扮演至关重要的角色，我就应该能够找到某种方式，让他们在有 AI 的环境中脱颖而出——就像他们在工作中会遇到的那样。我还不想屈服于这样一种想法，即人类只有在耗时超过几小时的任务上才有优势。
另一些人建议提高标准，要求“显著超越 Claude Code 单独完成的水平”。这里的顾虑是 Claude 工作速度很快。人类通常要花 2 小时中的一半时间来阅读和理解问题，然后才开始优化。试图引导 Claude 的人类很可能会一直处于落后状态，只能在事后才理解 Claude 做了什么。主导策略可能会变成坐视不管。
如今，Anthropic 的性能工程师仍然有大量的工作要做，但看起来更像是棘手的调试、系统设计、性能分析、弄清楚如何验证我们系统的正确性，以及弄清楚如何让 Claude 的代码更简单、更优雅。不幸的是，如果没有大量的时间或共同的背景，这些事情很难以客观的方式进行测试。设计出能代表实际工作的面试一直很难，但现在比以往任何时候都难。
但我也担心，如果我投入精力设计一个新的家庭作业测试，要么 Claude Opus 4.5 也能解决它，要么它会变得极具挑战性，以至于人类根本无法在两小时内完成。
尝试 1：一个不同的优化问题
我意识到 Claude 可以帮助我快速实现我设计的任何东西，这促使我尝试开发一个更难的家庭作业测试。我选择了一个基于我在 Anthropic 做过的最棘手的内核优化之一的问题：在 2D TPU 寄存器上进行高效的数据转置，同时避免bank 冲突。我将其提炼成一个在模拟机器上的更简单的问题，并让 Claude 在不到一天的时间内实现了这些改动。
Claude Opus 4.5 找到了一个我甚至没有想到的绝佳优化。通过仔细分析，它意识到它可以转置整个计算，而不是想办法转置数据，并据此重写了整个程序。
在我的真实案例中，这行不通，所以我修补了问题以排除这种方法。Claude 随后取得了一些进展，但找不到最高效的解决方案。看来我有了新问题，现在我只能寄希望于人类候选人能足够快地解决它。但我有一些挥之不去的疑虑，所以我使用 Claude Code 的“ultrathink”功能和更长的思考预算进行了双重检查……结果它解决了。它甚至知道修复 bank 冲突的技巧。
事后看来，这不是一个值得尝试的正确问题。许多平台的工程师都曾在数据转置和 bank 冲突上苦苦挣扎，因此 Claude 有大量训练数据可供借鉴。虽然我是从第一性原理出发找到解决方案的，但 Claude 可以借鉴更丰富的经验工具箱。
尝试 2：更古怪的方案
我需要一个人类推理能够战胜 Claude 更大经验基础的问题：一个足够偏离分布的问题。不幸的是，这与我希望问题能明显类似于实际工作的目标相冲突。
我回想了自己最喜欢的那些最不寻常的优化问题，最终想到了 Zachtronics 游戏。这些编程解谜游戏使用不寻常、高度受限的指令集，迫使你以非常规的方式编程。例如，在 Shenzhen I/O 中，程序被拆分到多个相互通信的芯片上，每个芯片只能容纳大约 10 条指令和一两个状态寄存器。巧妙的优化通常涉及将状态编码到指令指针或分支标志中。
我设计了一个新的家庭作业，包含使用一套极小且高度受限的指令集的谜题，要求将解决方案优化到最少指令数。我实现了一个中等难度的谜题，并在 Claude Opus 4.5 上进行了测试。它失败了。我编写了更多谜题，并让同事验证那些对该问题了解不如我的人是否仍能胜过 Claude。
与 Zachtronics 游戏不同，我有意不提供任何可视化或调试工具。起始代码只检查解决方案是否有效。构建调试工具是被测试的一部分：你可以插入精心编写的打印语句，也可以让编码模型在几分钟内生成一个交互式调试器。关于如何在工具上投入的判断力也是衡量信号的一部分。
我对新的家庭作业相当满意。它的方差可能比原始版本更低，因为它由更多独立的子问题组成。初步结果令人鼓舞：分数与候选人过往作品的水平高度相关，而且我最有能力的一位同事得分高于迄今为止的任何候选人。
我仍然为放弃原始版本的真实性和多样的深度感到遗憾。但真实性可能是一种我们不再拥有的奢侈品。原始版本之所以有效，是因为它类似于真实工作。替代方案之所以有效，是因为它模拟了新颖的工作。
公开挑战
我们发布原始家庭作业，供任何人不限时间尝试。人类专家 在足够长的时间范围内仍保持优势。有史以来最快的人类解决方案提交成绩大幅超过 Claude 即使在大量测试时计算下所取得的成绩。
发布版本从零开始（类似版本 1），但使用版本 2 的指令集和单核设计，因此周期数与版本 2 具有可比性。
性能基准（以模拟机器的时钟周期衡量）：
- 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 上下载。如果你的优化低于 1487 个周期，超越 Claude 发布时的最佳表现，请将你的代码和简历发送至 performance-recruiting@anthropic.com。
或者你也可以 通过我们的常规流程申请，该流程使用我们（现在的）抗 Claude 的家庭作业。我们很好奇它能坚持多久。