2026-01-21 Anthropic Engineering

设计抗 AI 的技术评估

原文：Designing AI-resistant technical evaluations

导读

本文复盘 Anthropic 性能工程团队如何迭代 take-home 技术评估：当 Claude Code 不断击穿旧题，评估设计必须从“测人是否会写代码”转向“测人在 AI 协作环境中的判断、建模和工具构造能力”。

说明：本文按 Agent Learning 的中文阅读页格式，对原文结构与关键技术细节做逐节中文转述与解读；为避免整篇镜像转载，正文保留原文章节脉络、关键数字和术语，但不做逐字复刻。

核心观点

正文

原始 take-home 的目标

Anthropic 性能工程团队在 2023 年末需要快速筛选更多候选人。标准面试流程耗费大量工程师和候选人时间，而团队又正面临 TPU、GPU、Trainium 集群扩张带来的性能工程需求。

作者设计了一个模拟加速器任务：候选人需要优化运行在一台类 TPU 机器上的 Python 程序，通过热加载的 Perfetto trace 观察每条指令。题目覆盖 scratchpad memory、VLIW、SIMD、multicore 等性能优化核心概念，但不要求深度学习背景。

这个题目一开始表现很好：大约 1,000 名候选人完成过它，帮助团队招到多位表现优秀的工程师。强候选人会构建调试工具、发现意外优化路径，甚至提交小型优化编译器。

Claude Opus 4 击穿第一版

到 2025 年 5 月，Claude 3.7 Sonnet 已经让相当一部分候选人“完全交给 Claude Code”更划算。预发布的 Claude Opus 4 则在 4 小时限制内给出了超过几乎所有人类候选人的方案。

作者没有简单废弃题目，而是用 Claude Opus 4 找出它开始吃力的位置，把那里改成第二版起点：更干净的 starter code、更深的机器特性、更短的开发循环，并移除已经被模型轻松解决的 multicore 部分。

时间限制也从 4 小时缩短到 2 小时。这样安排更利于候选人排期，同时让题目更强调关键优化洞察，而不是大段代码量和调试消耗。

Claude Opus 4.5 再次击穿第二版

预发布 Claude Opus 4.5 在 2 小时内逐步优化方案，不到 1 小时就达到通过线。它一度认为自己遇到无法突破的 memory bandwidth 瓶颈，这和多数人类的判断类似；但当作者提示可能达到的 cycle count 后，模型继续思考并找到了绕开瓶颈的 trick。

更严格的 test-time compute harness 也确认了这个结论：Claude 不仅能在 2 小时内击败多数人，还能随着时间继续提升。此时，take-home 的最佳策略已经接近“让 Claude Code 代做”。

为什么不直接禁用 AI

团队讨论过禁止 AI，但作者认为这不合适：执行层面难验证，工作场景中也不真实。性能工程师实际会使用 AI，因此评估更应该衡量候选人能否在有 AI 的环境中展示自己的判断力。

另一个选项是要求候选人显著超过 Claude Code 单独完成的结果，但这也有问题。模型执行太快，人类可能花一半时间理解上下文，随后只能被动追赶模型已经做过的修改。

这暴露出技术招聘的新难题：真实工作中的困难越来越多来自调试、系统设计、性能分析、正确性验证和代码简化，但这些能力很难在短时间内客观评分。

第一次新尝试：换一个优化问题

作者尝试设计一个来自实际工作的更难 kernel 优化题：在 2D TPU register 上做高效 data transposition，并避免 bank conflicts。Claude 很快帮他实现了新题，但 Claude Opus 4.5 又发现了一个作者没想到的优化路径：直接转置整个计算，而不是转置数据。

作者补丁移除了这条捷径后，Claude 暂时卡住；但当使用更长思考预算的 ultrathink 后，它仍然解出了关键 trick。原因并不神秘：data transposition 和 bank conflict 是许多平台上反复出现的问题，模型训练中很可能包含大量相似经验。

第二次新尝试：更异常的问题空间

于是作者转向更 out-of-distribution 的问题：受 Zachtronics 编程谜题启发，用一个极小、强约束的 instruction set 设计多道优化 puzzle，目标是最小化 instruction count。

这类题不再高度模拟真实加速器工作，但更能逼出候选人的新问题建模能力。题目没有提供 visualization 或 debugger，只给验证器；候选人可以自己加 print，也可以让 coding model 快速生成调试器。是否值得投资工具，本身就是评估信号。

早期结果显示，新 take-home 的分数和候选人过往工作质量相关。作者承认它牺牲了原题的 realism，但也指出：原题能工作，是因为它像真实工作；新题能工作，是因为它模拟了一种新颖工作。

开放挑战与 benchmark 数字

Anthropic 同时开放了原始 take-home，让外部开发者在无限时间下挑战。原文列出了若干 clock cycle 结果：Claude Opus 4 长时间 test-time compute 为 2164 cycles；Claude Opus 4.5 的普通 Claude Code session 约为 1790 cycles；2 小时 harness 为 1579 cycles；更长 harness 可到 1487 和 1363 cycles。

如果有人能低于 1487 cycles，就能超过 Claude Opus 4.5 发布时的最好表现。这个开放挑战强调了一个细节：在人类拥有足够长时间、能积累工具和洞察时，顶尖专家仍可能超过当前模型；但短时招聘评估已经被彻底改写。

深度解读

这篇文章真正有价值的地方，不只是“Claude 又打败了一道面试题”，而是把 AI 时代的评估困境讲得很具体。过去我们默认面试题的难点在候选人的知识、编码速度和调试熟练度；现在模型可以快速吃掉大量显性技巧，评估设计就必须寻找更深层的信号：候选人如何识别问题结构、如何判断模型输出是否走偏、如何决定何时造工具、如何在陌生规则中形成压缩表示。对工程团队来说，这也不只是招聘问题。内部 eval、agent benchmark、产品验收都会遇到类似张力：任务越真实，模型越可能从既有经验中泛化；任务越抗 AI，又越可能偏离实际价值。成熟做法不是追求永远无法被模型解决的题，而是持续更新评估，让它测出人类在当前模型边界外还能贡献什么。

落地启示