2023 年 11 月，Anthropic 的效能優化團隊負責人 Tristan Hume 遇到了一個幸福的煩惱: Claude 3 Opus 即將發佈，公司剛拿下大量 TPU 和 GPU 叢集，Trainium 叢集也在路上——但效能工程師嚴重不足。他在 Twitter 上發了一則徵才文，結果湧進來的優秀候選人多到既有面試流程根本消化不了。

他需要一個更有效率的篩選方式。於是花了兩週，設計了一個 take-home test。

原文: Designing AI-resistant technical evaluations

一個讓人做到欲罷不能的面試題

一般 take-home test 名聲不太好——無聊的題目、廉價的篩選。Tristan 想做的完全不一樣。他用 Python 寫了一個模擬加速器，有 scratchpad memory、VLIW、SIMD、multicore，特性跟真實 TPU 很像。候選人要在這台虛擬機器上優化一段 tree traversal 的程式碼，同時還能用 Perfetto 即時看到每一條指令的執行情況。

題目刻意避開深度學習——因為大部分效能工程師當時還沒碰過 DL，基礎好的人上了工作自然會學。候選人從一個完全串行的實作開始，逐步利用機器的各種平行能力去壓低 cycle 數。

結果呢? 很多候選人做超過 4 小時時限還不想停，因為太好玩了。最強的提交甚至寫出了完整的 mini compiler。而那個在 Twitter 批次中分數遙遙領先的人，入職兩週就開始優化 kernel，還找到一個會 block 產品發佈的 compiler bug——tensor indexing 的 32-bit 溢位問題。

一年半下來，超過 1,000 人做了這個測驗，團隊大部分成員都是靠它招進來的。好幾個最厲害的工程師是應屆畢業生，紙上經歷不起眼，但分數說明了一切。

第一次淪陷: Claude Opus 4

故事如果就停在這裡，那就只是一個「好面試題的設計心得」。但 Anthropic 是做 AI 的公司啊。

2025 年 5 月，Claude 3.7 Sonnet 已經強到超過一半的候選人其實不如直接把題目丟給 Claude Code。然後 Tristan 拿到了 Claude Opus 4 的內部預覽版來測——它在 4 小時內跑出的分數，比幾乎所有人類都高。

這不是 Tristan 第一次被自家模型打臉。他 2023 年設計的現場面試題，Claude 3 Opus 破了第一部分，Claude 3.5 Sonnet 破了第二部分。他們到現在還在用那題，因為其他題也一樣不防 AI。

不過這次還好修。題目本身的深度遠超 4 小時能探索的範圍，所以他找出 Claude Opus 4 開始卡住的地方，把那裡當成 Version 2 的起點。時限也從 4 小時縮到 2 小時——省掉排程的麻煩，也更容易塞進候選人的週末。

第二次淪陷: Claude Opus 4.5

Version 2 撐了幾個月。然後 Claude Opus 4.5 的預覽版來了。

Tristan 看著 Claude Code 花 2 小時慢慢做這份題目。它解掉了初始瓶頸、做完所有常見的 micro-optimization，不到一小時就過了及格線。然後它停了下來，說自己碰到了無法突破的 memory bandwidth 瓶頸。

大部分人類也會做出同樣的判斷。但確實存在一些利用問題結構的巧妙手法可以繞過去。Tristan 告訴 Claude 理論上可以達到的 cycle 數——Claude 想了一會兒，找到了那個 trick。接著它繼續除錯、調校、實作進階優化。2 小時結束時，它的分數追平了人類最佳成績——而那個人類還是重度使用 Claude 4 輔助的。

Tristan 面對的現實是: 他們即將發佈一個模型，而他的面試題的最佳策略變成了「把題目丟給 Claude Code 然後去泡咖啡」。

怎麼辦?

同事們提了幾個方案:

禁用 AI? Tristan 不想這樣做。除了難以執行，他直覺認為既然人類在工作中依然扮演關鍵角色，就應該能設計出一個在有 AI 輔助的情境下、人類仍能展現優勢的測驗。

拉高門檻到「大幅超越 Claude」? 問題是 Claude 太快了。人類通常前半段時間都在讀題和理解問題，一個試圖引導 Claude 的人可能永遠在追著 AI 的進度跑，最佳策略反而變成坐在旁邊看。

設計全新的題目? 他擔心兩種結果: Opus 4.5 照樣秒殺，或者題目難到人類也做不完。

嘗試一: 換題目，失敗

他選了一個自己在 Anthropic 做過的高難度優化問題——在 2D TPU register 上做 data transposition 並避開 bank conflict。用 Claude 幫忙，一天不到就實作完成。

但 Claude Opus 4.5 想出了一個連 Tristan 本人都沒想到的優化: 它分析後決定直接 transpose 整個計算流程而不是搬移資料。Tristan 把這條路堵住之後，Claude 還是有進展但找不到最佳解。看起來有戲?

他有點不放心，用了 Claude Code 的 ultrathink 模式跑了更長的 thinking budget……解出來了。它甚至知道處理 bank conflict 的那些 trick。

事後回想，這題不對。太多工程師在不同平台上跟 data transposition 和 bank conflict 搏鬥過，Claude 的訓練資料裡這類經驗太豐富了。

嘗試二: 走奇怪路線，成功了

Tristan 意識到他需要的是「夠 out of distribution」的問題——人類的推理能力能勝過 Claude 龐大經驗庫的領域。他想到了 Zachtronics 的程式解謎遊戲。

這類遊戲用極度受限的指令集強迫你用非常規方式寫程式。比如 Shenzhen I/O 裡，程式被拆分到多個只能放約 10 條指令、只有一兩個暫存器的晶片上，巧妙的優化往往涉及把狀態編碼進 instruction pointer 或 branch flag。

於是他設計了一組使用極小、高度受限指令集的 puzzle，目標是最小化指令數。測試 Claude Opus 4.5——失敗了。讓同事驗證人類確實能贏過 Claude。

一個關鍵設計: 他故意不提供視覺化或除錯工具。你可以自己插 print 語句，或者花幾分鐘叫 coding model 幫你生成一個互動式 debugger。怎麼投資工具建設本身就是考核的一部分。

故事的啟示

Tristan 坦承他對新版測驗有點遺憾——失去了原版那種貼近真實工作的感覺。但他說了一句很有意思的話:

原版之所以有效，是因為它「像真實工作」。新版之所以有效，是因為它模擬的是「新穎的工作」。

這整個故事其實折射出一個更大的趨勢: 當 AI 能快速解決「已知類型」的問題時，人類的價值越來越集中在「面對從未見過的東西時的推理能力」。不只是面試設計的問題，也是每個工程師該思考自己競爭力的方向。

最後，Anthropic 把原版 take-home 開源了，當作 open challenge。目前人類在不限時間的情況下，最佳成績仍然大幅超越 Claude。如果你能跑進 1487 cycles 以內（打敗 Claude Opus 4.5 發佈時的最佳成績），可以直接寄信到 performance-recruiting@anthropic.com。GitHub 連結在這。