核验日期：2026-07-08
内容来源：Anthropic Engineering 官方技术博客。本文先作为 Claude Code 专区后台草稿入库，发布前应由内容人员复核标题、摘要、图片、来源链接与是否需要补充本站实践说明。
设计能抵抗 AI 的技术评估
Claude 不断攻克我们的一道性能工程 take-home 技术题；我们从三轮迭代中学到了什么。
来源：https://www.anthropic.com/engineering/AI-resistant-technical-evaluations
发布日期：2026-01-21
作者 Tristan Hume 是 Anthropic 性能优化团队负责人之一。Tristan 设计并重新设计了这道 take-home 技术题，它帮助 Anthropic 招聘了数十位性能工程师。
随着 AI 能力提升，评估技术候选人变得更难。今天能够很好区分人类技能水平的 take-home 技术题，明天可能就会被模型轻松解决，从而失去评估价值。
自 2024 年初以来，我们的性能工程团队一直使用一道 take-home 技术题，让候选人为一个模拟加速器优化代码。已有超过 1,000 名候选人完成了这项测试，其中数十人如今在这里工作，包括搭建我们 Trainium 集群、并发布自 Claude 3 Opus 以来每一个模型的工程师。
但每个新的 Claude 模型都迫使我们重新设计这项测试。在相同时间限制下，Claude Opus 4 的表现超过了大多数人类申请者。这仍然让我们能够区分最强候选人，但随后 Claude Opus 4.5 甚至追平了这些候选人。若给予无限时间，人类仍然可以超过模型；但在 take-home 技术题的约束下，我们已经无法区分顶尖候选人的输出和我们最强模型的输出。
为了确保这项测试仍然携带信号，我已经迭代了三个版本。每一次，我都学到了一些新东西：什么能让评估对 AI 辅助保持稳健，什么不能。
本文描述了最初的 take-home 技术题设计、每个 Claude 模型如何攻克它，以及为了确保测试保持领先于我们顶尖模型能力，我不得不采用的越来越不寻常的方法。虽然我们的工作也随着模型一起演进，但我们仍然需要更多强大的工程师，只是需要越来越有创意的方法来找到他们。
为此，我们将最初的 take-home 技术题作为开放挑战发布出来，因为在无限时间下，最好的人类表现仍然超过 Claude 能达到的水平。如果你能胜过 Opus 4.5，我们很想听到你的消息，详情在本文底部。
Take-home 技术题的起源
2023 年 11 月，我们正准备训练和发布 Claude Opus 3。我们已经获得新的 TPU 和 GPU 集群，庞大的 Trainium 集群也即将到来，我们在加速器上的支出显著高于过去，但性能工程师数量不足，无法支撑新的规模。我在 Twitter 上发帖，请大家给我们发邮件，这带来了比标准面试流程所能评估更多的有潜力候选人，而标准流程会消耗员工和候选人大量时间。
我们需要一种更高效评估候选人的方法。因此，我花了两周时间设计一道 take-home 技术题，希望它能充分捕捉岗位要求，并识别最有能力的申请者。
设计目标
Take-home 技术题名声不佳。通常它们充满泛泛的问题，工程师觉得无聊，也无法成为好的筛选器。我的目标不同：创造一些真正引人入胜的东西，让候选人愿意参与，并让我们以高分辨率捕捉他们的技术技能。
相较于现场面试，这种形式在评估性能工程技能上也有优势：
更长的时间跨度： 工程师写代码时很少面对少于一小时的截止期限。4 小时窗口（后来缩短到 2 小时）更能反映真实工作的性质。它仍然比大多数真实任务短，但我们需要在真实性和负担之间取得平衡。
真实环境： 没有人盯着或期待你边做边讲。候选人可以在自己的编辑器中不受干扰地工作。
理解和构建工具的时间： 性能优化需要理解已有系统，有时还需要构建调试工具。这两点都很难在常规 50 分钟面试中真实评估。
兼容 AI 辅助： Anthropic 的通用候选人指南要求候选人在未另行说明时，不使用 AI 完成 take-home 技术题。对于这道测试，我们明确说明可以使用 AI。
更长周期的问题更难被 AI 完全解决，因此候选人可以像在工作中一样使用 AI 工具，同时仍需要展示自己的技能。
除了这些与形式相关的目标，我还应用了自己设计任何面试时都会使用的原则来制作这道 take-home 技术题：
代表真实工作： 问题应该让候选人感受到这份工作实际涉及什么。
高信号： Take-home 技术题应避免依赖单一洞见的问题，并确保候选人有许多机会展示完整能力，尽量减少偶然性。它也应具有宽广的评分分布，并有足够深度，让强候选人也无法完成所有内容。
不需要特定领域知识： 基础好的人可以在工作中学习具体知识。要求狭窄专业知识会不必要地限制候选人池。
有趣： 快速开发循环、有深度的有趣问题，以及发挥创造力的空间。
模拟机器
我为一台具备类似 TPU 特征的虚拟加速器构建了 Python 模拟器。候选人需要优化在这台机器上运行的代码，并使用一个热重载 Perfetto trace 查看每条指令，类似于我们在 Trainium 上拥有的工具。
这台机器包含让加速器优化变得有趣的特性：手动管理 scratchpad 内存（不同于 CPU，加速器通常需要显式内存管理）、VLIW（多个执行单元在每个周期并行运行，需要高效打包指令）、SIMD（每条指令对许多元素进行向量操作）以及多核（将工作分布到多个核心）。
任务是并行树遍历，并且刻意不带深度学习色彩，因为大多数性能工程师当时还没有做过深度学习，可以在工作中学习领域细节。这个问题受到无分支 SIMD 决策树推理的启发，这是一个经典 ML 优化挑战，也算是向过去致意；只有少数候选人以前遇到过。
候选人从一个完全串行实现开始，逐步利用机器的并行性。热身部分是多核并行，然后候选人选择攻克 SIMD 向量化或 VLIW 指令打包。最初版本还包含一个候选人需要先调试的 bug，用于考察他们构建工具的能力。
早期结果
最初的 take-home 技术题效果很好。Twitter 那批候选人中有一人的分数显著高于其他所有人。他在二月初入职，比我们通过标准流程招到的第一批人晚两周。测试证明具有预测性：他很快开始优化 kernel，并为一个会阻塞发布的编译器 bug 找到了绕过方案，该 bug 涉及张量索引数学溢出 32 位。
接下来一年半，大约 1,000 名候选人完成了这道 take-home 技术题，它帮助我们招聘了当前性能工程团队的大部分成员。它对纸面经验有限的候选人尤其有价值：我们表现最好的几位工程师直接来自本科，但在 take-home 技术题中展示了足够技能，让我们可以有信心聘用。
反馈也很积极。许多候选人因为觉得有趣而超过 4 小时限制继续做下去。最强的不限时提交包含完整的优化 mini-compiler，以及几种我没有预料到的巧妙优化。
然后 Claude Opus 4 攻克了它
到 2025 年 5 月，Claude 3.7 Sonnet 已经逐渐达到这样一个程度：超过 50% 的候选人如果完全委托给 Claude Code，结果会更好。随后我在 take-home 技术题上测试了 Claude Opus 4 的预发布版本。它在 4 小时时限内提出的优化方案超过了几乎所有人类。
这不是我的面试题第一次被 Claude 模型攻克。2023 年我设计过一道现场面试题，专门因为当时我们的问题基于常见任务，早期 Claude 模型了解很多，因此很容易解决。我试图设计一道更依赖问题解决能力而非知识的问题，它仍基于我在工作中解决过的一个真实但小众的问题。Claude 3 Opus 攻克了该题第 1 部分；Claude 3.5 Sonnet 攻克了第 2 部分。我们仍在使用它，因为其他现场题也并不抗 AI。
对于 take-home 技术题，有一个直接修复方法。这个问题的深度远超任何人 4 小时内能探索的范围，因此我用 Claude Opus 4 找出它开始吃力的位置。这个位置就成了第 2 版的新起点。我写了更干净的起始代码，加入新的机器特性以增加深度，并移除了多核（Claude 已经解决了它，而且它只会拖慢开发循环，却不增加信号）。
我还把时间限制从 4 小时缩短到 2 小时。最初选择 4 小时，是因为候选人反馈说这样即使在 bug 或困惑上卡一会儿，也不太容易彻底失败；但排期成本导致我们的流程出现数周延迟。2 小时更容易安排在周末。
第 2 版强调巧妙的优化洞见，而不是调试和代码量。它很好地服务了我们数月。
然后 Claude Opus 4.5 攻克了那个版本
当我测试一个预发布 Claude Opus 4.5 checkpoint 时，我看着 Claude Code 在问题上工作了 2 小时，逐步改进方案。它解决了初始瓶颈，实现了所有常见微优化，并在不到一小时内达到了我们的通过门槛。
然后它停了下来，确信自己遇到了无法逾越的内存带宽瓶颈。大多数人类也会得出同样结论。但有一些巧妙技巧可以利用问题结构绕过这个瓶颈。当我告诉 Claude 可以达到的周期数时，它思考了一会儿并找到了这个技巧。随后它调试、调优并实现了进一步优化。到 2 小时时，它的分数已经追平了该时限内最好的人类表现，而那位人类还大量使用了 Claude 4 并进行了引导。
为了更严谨，我们把它放进内部 test-time compute 运行框架中测试，并确认它既能在 2 小时内击败人类，也能随着时间继续爬升。发布后，我们甚至以通用方式改进了运行框架，并得到了更高分。
我遇到了问题。我们即将发布一个模型，而在我们的 take-home 技术题上，最佳策略会变成委托给 Claude Code。
考虑选项
一些同事建议禁止 AI 辅助。我不想这么做。除了执行上的挑战，我也隐约觉得，既然人在我们的工作中仍然扮演关键角色，我应该能找到某种方式，让他们在一个有 AI 的场景中区分出自己，就像他们在工作中会面对的那样。我还不想屈服于这个想法：人类只有在超过几小时的任务上才有优势。
其他人建议把标准提高到“显著超过 Claude Code 单独完成的结果”。这里的问题是 Claude 工作很快。人类通常会花 2 小时中的一半来阅读并理解问题，然后才开始优化。试图引导 Claude 的人类很可能一直落后，只能事后理解 Claude 做了什么。主导策略可能会变成坐在一旁观看。
如今，Anthropic 的性能工程师仍有大量工作要做，但这些工作更像是困难调试、系统设计、性能分析、弄清楚如何验证系统正确性，以及弄清楚如何让 Claude 的代码更简单、更优雅。不幸的是，如果没有大量时间或共同上下文，这些事情很难以客观方式测试。设计能代表工作的面试一直很难，但现在比以往更难。
但我也担心，如果我投入设计一道新的 take-home 技术题，要么 Claude Opus 4.5 也能解决它，要么它会变得过于困难，人类无法在两小时内完成。
尝试 1：一个不同的优化问题
我意识到 Claude 可以快速帮助我实现任何设计，这激励我尝试开发一道更难的 take-home 技术题。我选择了一个基于我在 Anthropic 做过的较棘手 kernel 优化的问题：在 2D TPU 寄存器上进行高效数据转置，同时避免 bank conflict。我把它提炼成一个模拟机器上的更简单问题，并让 Claude 在不到一天内实现了这些改动。
Claude Opus 4.5 找到了一个我甚至没想到的优秀优化。通过仔细分析，它意识到可以转置整个计算，而不是弄清楚如何转置数据，并相应地重写了整个程序。
在我的真实案例中，这行不通，所以我修补了问题以移除这种方法。随后 Claude 有所进展，但找不到最高效方案。看起来我找到了新问题，现在只需要希望人类候选人能足够快地做出来。但我仍有一些挥之不去的疑虑，于是使用 Claude Code 的 “ultrathink” 功能和更长思考预算再次确认……它解决了。它甚至知道修复 bank conflict 的技巧。
事后看来，这不是合适的问题。许多平台上的工程师都曾为数据转置和 bank conflict 苦恼，因此 Claude 有大量训练数据可以借鉴。虽然我是从第一性原理找到解决方案的，但 Claude 可以利用更大的经验工具箱。
尝试 2：变得更奇特
我需要一个人类推理能够胜过 Claude 更大经验库的问题：某种足够分布外的东西。不幸的是，这与我希望它明显像真实工作的目标相冲突。
我想到自己最喜欢的一些不寻常优化问题，最终落到了 Zachtronics 游戏上。这些编程解谜游戏使用不寻常、约束极强的指令集，迫使你以非常规方式编程。例如，在 Shenzhen I/O 中，程序被拆分到多个相互通信的芯片上，每个芯片只有大约 10 条指令和一两个状态寄存器。巧妙优化经常涉及把状态编码进指令指针或分支标志。
我设计了一道新的 take-home 技术题，由使用极小且约束很强的指令集的谜题组成，目标是优化方案以最小化指令数量。我实现了一个中高难度谜题，并用 Claude Opus 4.5 测试。它失败了。我补充了更多谜题，并让同事验证，即使不如我熟悉这个问题的人，也仍然可以超过 Claude。
不同于 Zachtronics 游戏，我刻意不提供可视化或调试工具。起始代码只检查方案是否有效。构建调试工具是被测试内容的一部分：你可以插入精心设计的 print 语句，也可以让编码模型在几分钟内生成交互式调试器。关于如何投入工具建设的判断，也是信号的一部分。
我对新的 take-home 技术题还算满意。它可能比原题方差更低，因为它包含更多独立子问题。早期结果很有希望：分数与候选人过去工作的水准相关性很好，而且我最有能力的同事之一得分高于目前任何候选人。
我仍然为放弃原题的真实性和层次丰富的深度感到遗憾。但真实性可能已经成了我们不再拥有的奢侈品。原题有效，是因为它类似真实工作。替代题有效，是因为它模拟了新颖工作。
一个开放挑战
我们发布了最初的 take-home 技术题，供任何人不限时间尝试。在足够长的时间跨度上，人类专家相较当前模型仍保有优势。有史以来最快的人类提交，显著超过了 Claude 即使使用大量 test-time compute 所能达到的结果。
发布版本从零开始（像第 1 版一样），但使用第 2 版的指令集和单核设计，因此周期数与第 2 版可比。
性能基准（以模拟机器的时钟周期衡量）：
- 2164 cycles：Claude Opus 4 在 test-time compute 运行框架中运行许多小时后取得
- 1790 cycles：Claude Opus 4.5 在一次随意的 Claude Code 会话中取得，大致追平人类 2 小时内的最佳表现
- 1579 cycles：Claude Opus 4.5 在我们的 test-time compute 运行框架中运行 2 小时后取得
- 1548 cycles：Claude Sonnet 4.5 在远超 2 小时的 test-time compute 后取得
- 1487 cycles：Claude Opus 4.5 在运行框架中运行 11.5 小时后取得
- 1363 cycles：Claude Opus 4.5 在改进后的 test-time compute 运行框架中运行许多小时后取得
在 GitHub 下载。如果你能优化到低于 1487 cycles，击败 Claude 发布时的最佳表现，请将你的代码和简历发送到 performance-recruiting@anthropic.com。
或者你也可以通过我们的常规流程申请，该流程使用我们现在的 Claude-resistant take-home 技术题。我们很好奇它能坚持多久。
