设计抗 AI 的技术评测：带回家测试如何被模型追上

设计抗 AI 的技术评测

Anthropic Engineering

2026 年 1 月 21 日。

由 Tristan Hume 撰写。他是 Anthropic 性能优化团队的负责人。Tristan 设计了——并且重新设计了——这份带回家测试。它帮助 Anthropic 招到了数十名性能工程师。

随着 AI 能力提高，评估技术候选人变得更难。一份今天还能很好地区分人类技能水平的带回家测试，明天就可能被模型轻易解掉——从而使它失去评测用途。

从 2024 年初起，我们的性能工程团队使用一份带回家测试：候选人要为一台模拟加速器优化代码。已有 1000 多名候选人完成它，其中数十人现在在这里工作，包括把我们的 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（https://x.com/trishume/status/1730386529997238605?s=20）上发帖，请人们给我们发邮件。这带来的有希望的候选人，多过我们能用标准面试流水线评估的数量。这个流程会消耗员工和候选人大量时间

我们需要一种更高效地评估候选人的办法。于是我花了两周，设计一份带回家测试，使之能够充分抓住这个角色的要求，并识别出最有能力的申请者。

设计目标

带回家测试名声不好。它们通常塞满通用题目，工程师觉得无聊，而且过滤效果差。我的目标不同：做出真正吸引人的东西，让候选人愿意参加，并让我们能以高分辨率捕捉他们的技术技能。

这一形式在评估性能工程技能上，也比现场面试有优势：

更长的时间期限： 工程师写代码时很少面对不到一小时的截止。一个 4 小时的窗口（后来缩短到 2 小时）更能反映这份工作的实际性质。它仍然短于大多数真实任务，但我们需要把这一点，和它有多累人，放在一起权衡。

真实的环境： 没有人在旁观看，也没有人期待你边做边讲。候选人在自己的编辑器里工作，不受打扰。

用于理解和做工具的时间： 性能优化要求理解已有系统，有时还要自己做调试工具。这两件事都很难在一场普通的 50 分钟面试里被真实地评估。

与 AI 协助兼容： Anthropic 的一般候选人指引（https://www.anthropic.com/candidate-ai-guidance）要求候选人在没有另行说明时，不使用 AI 完成带回家测试。对这份带回家测试，我们明确另行说明。

时间期限更长的问题，AI 更难完全解掉，因此候选人可以使用 AI 工具（就像他们在工作中会做的那样），同时仍然需要展示自己的技能。

在这些与形式有关的目标之外，我还用了设计任何面试时所用的同一套原则，来做这份带回家测试：

代表真实工作： 题目应当让候选人尝到这份工作实际涉及什么。

高信号： 带回家测试应当避开那些取决于单一洞见的题目，并保证候选人有许多机会展示全部能力——把碰运气的成分留得尽可能少。它还应当有较宽的分数分布，并保证足够的深度，使即使是强候选人也不能做完一切。

不要求特定领域知识： 基础好的人可以在工作中学习具体细节。要求狭窄的专长，会不必要地限制候选人池。

有趣： 开发循环要快，问题要有趣、有深度，并且留有创造的余地。

被模拟的机器

我用 Python 做了一台假加速器的模拟器，其特征类似 TPU。候选人优化跑在这台机器上的代码，使用一份热重载的 Perfetto（https://perfetto.dev/）轨迹，它显示每一条指令，类似于我们在 Trainium 上已有的工具（https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-explorer/overview-device-profiles.html）。

这台机器包含一些让加速器优化变得有意思的特性：手工管理的暂存内存（与 CPU 不同，加速器常常要求显式的内存管理）、VLIW（每个周期有多个执行单元并行运行，因此要求高效地装填指令）、SIMD（一条指令对许多元素做向量运算），以及多核（把工作分到多个核上）。

任务是一次并行的树遍历，故意不做深度学习的味道，因为当时大多数性能工程师还没有做过深度学习，具体的领域知识可以在工作中学。这个问题的灵感来自分支无关的 SIMD 决策树推断，那是一个古典机器学习优化挑战，算是对过去的致意，只有少数候选人以前遇到过。

候选人从一份完全串行的实现开始，逐步利用这台机器的并行性。热身是多核并行，然后候选人选择去攻 SIMD 向量化，还是 VLIW 指令装填。最初的版本还包含一个必须先调试的缺陷，用来锻炼他们做工具的能力。

早期结果

最初的带回家测试效果很好。Twitter 那一批里有一个人的分数明显高于其他所有人。他在 2 月初入职，距我们通过标准流水线招到的第一批人只有两周。测试被证明有预测力：他立刻开始优化内核，并为一处会挡住发布的编译器缺陷找到了变通办法，那个缺陷涉及张量索引的数学溢出 32 位。

在接下来的一年半里，大约 1000 名候选人完成了带回家测试，它帮助我们招到了当前性能工程团队的大部分人。它对纸面上经验有限的候选人尤其有价值：我们若干表现最高的工程师直接来自本科，但在带回家测试上表现出足够的技能，使我们能有把握地雇用。

反馈是正面的。许多候选人超过了 4 小时的限制，因为他们做得高兴。最强的、不限时的提交里，包括完整的优化型迷你编译器，以及若干我没有预料到的巧妙优化。

然后 Claude Opus 4 击败了它

到 2025 年 5 月，Claude 3.7 Sonnet 已经悄悄涨到这个程度：超过 50% 的候选人，如果把事情整个委托给 Claude Code，会做得更好。随后我在带回家测试上试了一个预发布版本的 Claude Opus 4。它给出的优化解，比几乎所有人类在 4 小时限制内给出的都更好。

这不是我第一份被某个 Claude 模型击败的面试。我在 2023 年专门设计过一道现场面试题，因为我们当时的题目围绕着常见任务，早期 Claude 模型对此有大量知识，因此容易解掉。我试图设计一道更要求解题技能、而不是知识的题目，仍然基于我在工作中解过的一个真实（但小众）的问题。Claude 3 Opus 击败了那道题的第一部分；Claude 3.5 Sonnet 击败了第二部分。我们仍在用它，因为我们其他的现场题同样不抗 AI。

对带回家测试，有一个直截了当的修法。这个问题的深度远超过任何人能在 4 小时里探索的，于是我用 Claude Opus 4 找出它从哪里开始吃力。那成了第 2 版的新起点。我写了更干净的起始代码，为了更多深度加入了新的机器特性，并去掉了多核（Claude 已经解掉了它，而且它只拖慢开发循环，不增加信号）。

我还把时间限制从 4 小时缩短到 2 小时。我原先选 4 小时，是基于候选人的反馈：他们更希望，如果在某个缺陷或困惑上卡住一会儿，不至于整个沉掉；但排期开销正在使我们的流水线延误数周。两小时更容易塞进一个周末。

第 2 版强调巧妙的优化洞见，而不是调试和代码量。它为我们服务得很好——有好几个月。

然后 Claude Opus 4.5 击败了那个

当我测试一个预发布的 Claude Opus 4.5 检查点时，我看着 Claude Code 在这个问题上工作了 2 小时，逐步改进它的解。它解决了最初的瓶颈，实现了所有常见的微优化，并在不到一小时内达到了我们的通过阈值。

然后它停了下来，确信自己撞上了一个无法克服的内存带宽瓶颈。大多数人类会得到同样的结论。但有一些巧妙的技巧，利用问题结构绕过那个瓶颈。当我告诉 Claude 有可能达到的周期数时，它想了一会儿，找到了那个技巧。随后它调试、调参，并实现了进一步的优化。到 2 小时的刻度，它的分数追上了该时间限制内最好的人类表现——而那个人类大量使用了 Claude 4，并加以引导。

我们在内部的测试时计算 harness 里更严格地试了一次，确认它既能在 2 小时内击败人类，也能随时间继续往上爬。发布之后，我们甚至以一种通用方式改进了 harness，并得到了更高的分数。

我有了一个问题。我们即将发布一个模型，而在我们的带回家测试上，最好的策略将是委托给 Claude Code。

考虑各种选项

有些同事建议禁止 AI 协助。我不想这么做。除了执行上的困难，我有一种感觉：既然人在我们的工作里继续扮演关键角色，我就应当能找出某种方式，让他们在有 AI 的环境里把自己区分出来——就像他们在工作中会面对的那样。我还不想向这个想法让步（https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/）：人类只在长于几小时的任务上才有优势。

另一些人建议把门槛提高到「大幅超过 Claude Code 独自能达到的」。这里的担心是 Claude 工作得很快。人类通常把 2 小时里的一半用来阅读和理解问题，然后才开始优化。一个试图引导 Claude 的人，很可能一直落在后面，只在事后才理解 Claude 做了什么。占优策略可能变成坐在那里看。

如今 Anthropic 的性能工程师仍然有大量工作要做，但它看起来更像艰难的调试、系统设计、性能分析、弄清楚如何验证我们系统的正确性，以及弄清楚如何让 Claude 的代码更简单、更优雅。不幸的是，这些事情很难在没有大量时间或共同上下文的情况下，以客观方式测试。设计能代表这份工作的面试从来就难，现在比以往更难。

但我也担心，如果我投入去设计一份新的带回家测试，要么 Claude Opus 4.5 也会把它解掉，要么它会变得太难，人类不可能在两小时内完成。

尝试 1：一个不同的优化问题

我意识到 Claude 可以帮我很快实现我所设计的任何东西，这促使我去试着开发一份更难的带回家测试。我选了一个问题，基于我在 Anthropic 做过的更棘手的内核优化之一：在二维 TPU 寄存器上做高效的数据转置（https://en.wikipedia.org/wiki/Transpose），同时避开存储体冲突（https://feldmann.nyc/blog/smem-microbenchmarks）。我把它提炼成模拟机器上一个更简单的问题，并让 Claude 在不到一天里实现了这些改动。

Claude Opus 4.5 找到了一个我甚至没想到的很好的优化。通过仔细分析，它意识到可以把整个计算转置，而不是去弄清楚如何转置数据，并据此重写了整个程序。

在我的真实情形里，这本来行不通，于是我给问题打了补丁，去掉那条路。Claude 随后有了进展，但找不到最高效的解。看起来我有了新问题，现在只需要希望人类候选人能足够快地做出来。但我有些挥之不去的怀疑，于是我用 Claude Code 的「ultrathink」功能、以更长的思考预算复核了一次……它解掉了。它甚至知道修复存储体冲突的技巧。

事后看，这不是该去试的正确问题。许多平台上的工程师都和数据转置、存储体冲突搏斗过，因此 Claude 有大量训练数据可以调用。虽然我的解来自第一性原理，Claude 可以调用一个更大的经验工具箱。

尝试 2：变得更怪

我需要一个问题，使人的推理能够赢过 Claude 更大的经验基础：某种充分偏离分布的东西。不幸的是，这和我「要能认得出像这份工作」的目标冲突。

我想起自己喜欢过的最不寻常的优化问题，落到了 Zachtronics 的游戏（https://www.zachtronics.com/）上。这些编程解谜游戏使用不寻常的、高度受限的指令集，迫使你以非常规方式编程。例如，在 Shenzhen I/O（https://www.zachtronics.com/shenzhen-io/）里，程序被拆到多个互相通信的芯片上，每块芯片只容纳大约 10 条指令，以及一两个状态寄存器。巧妙的优化常常涉及把状态编码进指令指针或分支标志。

我设计了一份新的带回家测试，由使用一套极小、高度受限指令集的谜题组成，按最少指令数来优化解。我实现了一道中等偏难的谜题，并在 Claude Opus 4.5 上测试。它失败了。我补上更多谜题，并让同事核实：那些对这个问题浸淫不如我深的人，仍然可以超过 Claude。

与 Zachtronics 的游戏不同，我有意不提供可视化或调试工具。起始代码只检查解是否合法。做调试工具是被测试内容的一部分：你可以插入精心写的打印语句，或者让一个编码模型在几分钟内生成一个交互式调试器。关于如何把力气投到工具上的判断，是信号的一部分。

我对新的带回家测试还算满意。它的方差可能低于原先那份，因为它由更多相互独立的子问题组成。早期结果令人鼓舞：分数与候选人过往工作的水准相关得很好，而且我最有能力的同事之一，得分高于迄今任何候选人。

放弃原先那份的真实感和多样的深度，我仍然觉得可惜。但真实感也许是我们不再拥有的奢侈。原先那份能用，是因为它像真实工作。替代品能用，是因为它模拟的是新颖的工作。

一项公开挑战

我们把原先的带回家测试发布出来，供任何人在不限时间的条件下尝试。在足够长的时间期限上，人类专家相对当前模型仍保有优势（https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/）。有史以来提交过的最快人类解，大幅超过 Claude 即使在大量测试时计算下所达到的。

发布的版本从零开始（像第 1 版），但使用第 2 版的指令集和单核设计，因此周期数可以和第 2 版比较。

性能基准（以模拟机器的时钟周期衡量）：

• 2164 个周期：Claude Opus 4 在测试时计算 harness 里经过许多小时
• 1790 个周期：Claude Opus 4.5 在一次随意的 Claude Code 会话里，大约追上 2 小时内最好的人类表现
• 1579 个周期：Claude Opus 4.5 在我们的测试时计算 harness 里经过 2 小时
• 1548 个周期：Claude Sonnet 4.5 在远多于 2 小时的测试时计算之后
• 1487 个周期：Claude Opus 4.5 在 harness 里经过 11.5 小时
• 1363 个周期：Claude Opus 4.5 在改进后的测试时计算 harness 里经过许多小时

在 GitHub 上下载（https://github.com/anthropics/original_performance_takehome）。如果你把周期优化到 1487 以下，超过 Claude 在发布时的最佳表现，请把你的代码和一份简历发邮件到 performance-recruiting@anthropic.com（mailto:performance-recruiting@anthropic.com）。

或者你可以通过我们通常的流程申请（https://www.anthropic.com/careers/jobs），该流程使用我们（现在）能抗住 Claude 的带回家测试。我们很想知道它能撑多久。