设计抗 AI 的技术评估设计抗 AI 的技术评估我们从三次迭代的性能工程 take-home 测试中学到了什么——Cl

设计抗 AI 的技术评估

原文链接: www.anthropic.com/engineering…

发布日期: 2026年1月21日

我们从三次迭代的性能工程 take-home 测试中学到了什么——Claude 一直在击败它。

作者：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 测试的约束条件下，我们已经无法区分顶尖候选人的产出和我们最强模型的输出。

我现在已经迭代了三个版本的 take-home 测试，试图确保它仍然能提供有效信号。每次我都学到了一些关于什么能使评估对 AI 辅助具有鲁棒性、什么不能的新东西。

这篇文章描述了最初的 take-home 设计、每个 Claude 模型如何击败了它，以及我不得不采取越来越不寻常的方法来确保我们的测试保持在顶级模型能力之前。虽然我们所做的工作随着模型的发展而演变，但我们仍然需要更多优秀的工程师——只是需要越来越有创意的方式来找到他们。

为此，我们将原始的 take-home 测试作为公开挑战发布，因为在不限时间的情况下，最佳人类表现仍然超过 Claude 所能达到的水平。如果你能超越 Opus 4.5，我们很想听到你的消息——详情在本文末尾。

💡 文章核心叙事线

graph TD
    A[2024年初: 设计原始 take-home 测试] --> B[版本1: 模拟加速器优化]
    B --> C[Claude Opus 4 击败版本1]
    C --> D[版本2: 提高起点, 缩短时间]
    D --> E[Claude Opus 4.5 击败版本2]
    E --> F{考虑应对方案}
    F --> G[尝试1: 数据转置问题]
    G --> H[Claude 仍能解决]
    F --> I[尝试2: 类Zachtronics谜题]
    I --> J[版本3: Claude 失败, 人类成功]
    J --> K[发布原始版本作为公开挑战]

Take-home 测试的起源

2023 年 11 月，我们正准备训练和发布 Claude Opus 3。我们已经获得了新的 TPU 和 GPU 集群，大型 Trainium 集群即将到来，我们在加速器上的投入远超以往，但我们没有足够的性能工程师来应对新的规模。我在 Twitter 上发帖邀请人们给我们发邮件，这带来了比我们通过标准面试流程能评估的更多有前途的候选人——而标准流程需要消耗员工和候选人大量的时间。

我们需要一种更高效的方式来评估候选人。因此，我花了两周时间设计了一项 take-home 测试，能够充分捕捉该职位的需求并识别最有能力的申请者。

设计目标

Take-home 测试名声不好。通常它们充满了工程师觉得无聊的通用问题，作为筛选工具效果很差。我的目标不同：创造一些真正有吸引力的东西，让候选人兴奋地参与，并允许我们以高分辨率捕捉他们的技术技能。

这种形式相比现场面试在评估性能工程技能方面也有优势：

更长的时间跨度： 工程师在编码时很少面临不到一小时的截止期限。4 小时的窗口（后来缩减为 2 小时）更好地反映了工作的实际性质。它仍然比大多数真实任务短，但我们需要在此与繁重程度之间取得平衡。

真实环境： 没有人在旁边观看或期望叙述。候选人在自己的编辑器中不受干扰地工作。

理解和工具构建的时间： 性能优化需要理解现有系统，有时还需要构建调试工具。两者都很难在正常的 50 分钟面试中进行真实评估。

与 AI 辅助的兼容性： Anthropic 的通用候选人指南要求候选人在未另行说明的情况下不使用 AI 完成 take-home 测试。对于这项 take-home 测试，我们明确表示可以使用 AI。

更长时间跨度的问题对于 AI 来说更难完全解决，因此候选人可以使用 AI 工具（就像在工作中一样），同时仍然需要展示自己的技能。

💡 take-home 测试 vs 现场面试优势对比

维度	take-home 测试	现场面试
时间跨度	2-4小时，更贴近实际工作	通常50分钟，过于紧迫
环境	自己的编辑器，无干扰	有人观看，需要边做边解释
工具构建	有时间构建调试工具	时间不够，难以真实评估
AI 兼容性	可允许使用 AI（如工作中一样）	难以监控 AI 使用
候选人体验	更轻松，更能发挥真实水平	压力大，可能表现失常

除了这些格式特定的目标之外，我还应用了设计任何面试时使用的相同原则来制作 take-home 测试：

代表真实工作： 问题应该让候选人体验到工作的实际内容。

高信号： take-home 测试应避免依赖单一洞察力的问题，确保候选人有很多机会展示他们的全部能力——尽可能减少运气因素。它还应该有很宽的评分分布，并确保足够的深度，使即使是强候选人也无法完成所有内容。

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

有趣： 快速的开发循环、有深度的有趣问题，以及创造的空间。

💡 优秀面试设计的四大原则

graph TD
    Root((面试设计原则))
    Root --> A[代表真实工作]
    Root --> B[高信号]
    Root --> C[不需特定领域知识]
    Root --> D[有趣]
    A --> A1[让候选人体验实际工作内容]
    B --> B1[避免依赖单一洞察]
    B --> B2[宽评分分布]
    B --> B3[足够深度]
    C --> C1[良好基础即可]
    C --> C2[扩大候选人池]
    D --> D1[快速开发循环]
    D --> D2[有深度的问题]
    D --> D3[创造空间]

模拟机器

我构建了一个 Python 模拟器，模拟了一个具有类似 TPU 特性的虚构加速器。候选人在这台机器上优化代码，使用热重载的 Perfetto 跟踪来显示每条指令，类似于我们在 Trainium 上拥有的工具。

该机器包括使加速器优化变得有趣的特性：手动管理的暂存内存（与 CPU 不同，加速器通常需要显式内存管理）、VLIW（每个周期多个执行单元并行运行，需要高效的指令打包）、SIMD（每条指令对多个元素进行向量操作）和多核（将工作分配到多个核心）。

💡 模拟机器的关键特性

特性	说明	优化挑战
暂存内存 (Scratchpad)	手动管理的片上内存	需要显式内存管理，不同于 CPU 的缓存机制
VLIW	每周期多执行单元并行	需要高效指令打包以充分利用并行度
SIMD	每条指令操作多个元素	需要向量化思维
多核	工作分配到多个核心	需要合理划分并行任务

任务是并行树遍历，刻意不采用深度学习风格，因为大多数性能工程师之前没有从事过深度学习工作，可以在工作中学习领域知识。这个问题灵感来自无分支 SIMD 决策树推理，这是一个经典的 ML 优化挑战，作为对过去的致敬，只有少数候选人之前遇到过。

候选人从一个完全串行的实现开始，逐步利用机器的并行性。热身部分是多核并行性，然后候选人选择处理 SIMD 向量化或 VLIW 指令打包。原始版本还包含一个需要候选人调试的 bug，锻炼他们构建工具的能力。

早期成果

最初的 take-home 测试效果很好。来自 Twitter 批次的一个人得分远高于其他所有人。他在 2 月初入职，比通过标准流程招聘的第一批员工晚两周。测试证明具有预测性：他立即开始优化内核，并找到了一个阻碍发布的编译器 bug 的变通方案，该 bug 涉及张量索引数学溢出 32 位。

在接下来的一年半中，大约 1,000 名候选人完成了 take-home 测试，它帮助我们招聘了当前性能工程团队的大部分成员。它对于纸面经验有限的候选人特别有价值：我们几位表现最好的工程师直接来自本科毕业，但在 take-home 测试中展示了足够的技能，让我们能够自信地录用。

反馈是积极的。许多候选人超过 4 小时的时间限制继续工作，因为他们很享受这个过程。最强的无时限提交包括完整的优化迷你编译器和几个我没有预料到的巧妙优化。

然后 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 强调巧妙的优化洞察力，而非调试和代码量。它为我们服务得很好——持续了几个月。

💡 版本1到版本2的演进

graph TD
    V1[版本1: 原始 take-home] --> P1[问题: Claude Opus 4 击败了它]
    P1 --> S1[分析: 找到 Claude 开始挣扎的点]
    S1 --> V2[版本2: 新起点 + 新特性]
    V2 --> C1[更清晰的初始代码]
    V2 --> C2[添加新机器特性增加深度]
    V2 --> C3[移除多核 - Claude已解决]
    V2 --> C4[时间从4小时缩短到2小时]
    V2 --> C5[强调优化洞察力而非代码量]

然后 Claude Opus 4.5 又击败了它

当我测试 Claude Opus 4.5 的预发布检查点时，我观看 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 也会解决它，要么它会变得如此具有挑战性，以至于人类不可能在两小时内完成。

💡 三种应对方案的权衡

方案	优点	缺点
禁止 AI 辅助	简单直接	执行困难，不代表实际工作环境
提高标准（大幅超越 Claude）	保留 AI 使用	人类可能只是在旁观看 Claude 工作
设计全新测试	可能找到 AI 盲点	Claude 可能也能解决；可能对人类太难

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

我意识到 Claude 可以帮我快速实现我设计的任何东西，这激励我尝试开发一个更难的 take-home 测试。我选择了一个基于我在 Anthropic 做过的更棘手的内核优化之一的问题：在 2D TPU 寄存器上进行高效数据转置，同时避免bank 冲突。我将其提炼为一个更简单的模拟机器上的问题，并让 Claude 在不到一天内实现了这些更改。

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

在我的真实案例中，这不会奏效，所以我修补了问题以移除该方法。Claude 随后取得了进展但无法找到最高效的解决方案。看起来我有了我的新问题，现在只需要希望人类候选人能够足够快地解决它。但我有一些挥之不去的疑虑，所以我使用 Claude Code 的 "ultrathink" 功能和更长的思考预算进行了二次检查……它解决了。它甚至知道修复 bank 冲突的技巧。

回顾来看，这不是正确的尝试问题。许多平台上的工程师都在数据转置和 bank 冲突上苦苦挣扎，因此 Claude 有大量的训练数据可以借鉴。虽然我是从第一性原理找到我的解决方案的，但 Claude 可以利用更大的经验工具箱。

💡 为什么数据转置问题失败了

graph TD
    A[设计: 2D TPU寄存器数据转置] --> B[Claude Opus 4.5 测试]
    B --> C[发现创新方法: 转置计算而非数据]
    C --> D[修补问题移除该方法]
    D --> E[Claude 再次测试]
    E --> F[常规模式下无法解决]
    F --> G[使用 ultrathink 模式]
    G --> H[解决了! 知道 bank 冲突技巧]
    H --> I[结论: 训练数据中有太多相关经验]
    I --> J[需要更 out-of-distribution 的问题]

尝试 2：走向更怪异

我需要一个人类推理能够胜过 Claude 更大经验库的问题：一些足够偏离分布的东西。不幸的是，这与我"可识别地类似于工作"的目标相冲突。

我思考了我最享受的最不寻常的优化问题，最终选择了 Zachtronics 游戏。这些编程解谜游戏使用不寻常的、高度受限的指令集，迫使你以非传统方式编程。例如，在 Shenzhen I/O 中，程序被分割到多个通信的芯片上，每个芯片只能容纳大约 10 条指令和一到两个状态寄存器。巧妙的优化通常涉及将状态编码到指令指针或分支标志中。

我设计了一个新的 take-home 测试，由使用微小、高度受限指令集的谜题组成，优化解决方案以达到最小指令数。我实现了一个中等难度的谜题并在 Claude Opus 4.5 上测试。它失败了。我补充了更多谜题，并让同事验证比我更不熟悉问题的人仍然可以超越 Claude。

与 Zachtronics 游戏不同，我故意不提供可视化或调试工具。初始代码只检查解决方案是否有效。构建调试工具是测试的一部分：你可以插入精心设计的 print 语句，或者让编码模型在几分钟内生成一个交互式调试器。关于如何投资工具的判断力也是信号的一部分。

我对新的 take-home 测试相当满意。它可能比原始版本有更低的方差，因为它由更多独立的子问题组成。早期结果令人鼓舞：分数与候选人过去工作的水平相关性良好，我最有能力的一位同事得分高于迄今为止的任何候选人。

我仍然对放弃原始版本的真实性和多样化深度感到遗憾。但真实性可能是我们不再拥有的奢侈品。原始版本之所以有效，是因为它类似于真实工作。替代版本之所以有效，是因为它模拟了新颖的工作。

💡 三个版本 take-home 测试的演进

版本	核心设计	AI 表现	结果
版本1	模拟加速器优化（含多核、调试）	Claude Opus 4 超越大多数人类	需要改版
版本2	更高起点、2小时、强调优化洞察	Claude Opus 4.5 匹配最佳人类	需要改版
版本3	类Zachtronics受限指令集谜题	Claude Opus 4.5 失败	目前有效

💡 什么使评估能抵抗 AI

graph TD
    Root((抗AI评估的关键要素))
    Root --> A[偏离分布]
    Root --> B[受限指令集]
    Root --> C[需要创造性推理]
    Root --> D[工具构建判断力]
    A --> A1[训练数据中少见的问题类型]
    A --> A2[传统问题 AI 有大量经验]
    B --> B1[微小受限的指令集]
    B --> B2[非传统编程方式]
    C --> C1[人类推理优势]
    C --> C2[不依赖知识库]
    D --> D1[是否构建调试工具的判断]
    D --> D2[如何投资时间的决策]

公开挑战

我们将原始的 take-home 测试发布给任何人以不限时间方式尝试。人类专家在足够长的时间跨度上相对于当前模型仍然保持优势。有史以来提交的最快人类解决方案大幅超过了 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 在改进的测试时计算框架中运行数小时后

💡 性能基准对比

模型/方式	周期数	耗时	备注
Claude Opus 4	2164	数小时	测试时计算框架
Claude Opus 4.5	1790	~2小时	随意 Claude Code 会话，≈人类2小时最佳
Claude Opus 4.5	1579	2小时	测试时计算框架
Claude Sonnet 4.5	1548	>>2小时	测试时计算
Claude Opus 4.5	1487	11.5小时	测试时计算框架
Claude Opus 4.5	1363	数小时	改进的测试时计算框架
人类最佳（无限时间）	< 1363	不限时	仍然超越所有 AI 表现

在 GitHub 上下载。如果你优化到低于 1487 周期，击败 Claude 在发布时的最佳表现，请将你的代码和简历发送到 performance-recruiting@anthropic.com。

或者你可以通过我们的常规流程申请，该流程使用我们（现在的）抗 Claude take-home 测试。我们很好奇它能坚持多久。

📝 总结

核心要点

AI 能力持续提升，技术评估必须不断迭代：每次新的 Claude 模型发布，都迫使 Anthropic 重新设计他们的性能工程 take-home 测试，从版本 1 到版本 3。
传统优化问题难以抵抗 AI：基于常见工程挑战（如数据转置、bank 冲突）的问题，Claude 可以从大量训练数据中借鉴经验来解决。
偏离分布的问题是关键：最终成功抵抗 AI 的版本 3 使用了类似 Zachtronics 游戏的受限指令集谜题——足够新颖，超出了 AI 的训练分布。
真实性 vs 抗 AI 性的权衡：原始 take-home 测试因类似真实工作而有效；替代版本因模拟新颖工作而有效。真实性可能成为一种"奢侈品"。
人类在长时间跨度上仍有优势：在不限时间的情况下，人类专家的最佳表现仍然超过 Claude 的最佳成绩，但这个优势窗口正在缩小。
工具构建判断力是重要信号：版本 3 刻意不提供调试工具，测试候选人是否以及如何投资构建自己的工具——这种判断力是 AI 难以替代的。
公开挑战：Anthropic 已将原始 take-home 测试开源到 GitHub，邀请任何人尝试超越 Claude Opus 4.5 的 1487 周期成绩。

原文作者: Tristan Hume