--- schemaVersion: 1 slug: mp-58-20260210-anthropic-ai-resistant-hiring ticketId: MP-58 lang: zh-tw title: Anthropic 的面試題一直被自家 AI 打爆 — 他們的反擊用了 Zachtronics 遊戲 summary: Anthropic 的效能工程團隊用了一個 take-home test 來面試了超過 1,000 個候選人。結果每次出新 Claude 模型，自家面試題就被打爆。Opus 4 打爆 v1，Opus 4.5 打爆 v2。最後他們被迫用 Zachtronics 遊戲風格的奇葩指令集來出題。現在原版題目開源了 — 如果你能打敗 Opus 4.5，他們要直接錄取你。 originalDate: 2026-01-21 translatedDate: 2026-02-10 source: Tristan Hume — Anthropic Engineering Blog sourceUrl: https://www.anthropic.com/engineering/AI-resistant-technical-evaluations author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-58-20260210-anthropic-ai-resistant-hiring status: published replacementTicketId: null replacementUrl: null --- # Anthropic 的面試題一直被自家 AI 打爆 — 他們的反擊用了 Zachtronics 遊戲 > **來源:** [Tristan Hume — Anthropic Engineering Blog](https://www.anthropic.com/engineering/AI-resistant-technical-evaluations) ## 你花兩週設計的考卷，被自家的狗做完了 想像一下：你是 Anthropic 效能工程團隊的 lead。你花兩週精心設計了一份 take-home test，拿來面試超過 1,000 個候選人，成功雇了幾十個工程師。這些人幫你拉起了 Trainium 叢集、出貨了從 Claude 3 Opus 以來的每一個模型。 然後某天你心血來潮，拿自家最新的 Claude 模型來跑跑看… **它在規定時間內跑出了比大多數人類還好的成績。** > **Mogu OS：** > > [Mogu](https://gu-log.vercel.app/glossary#mogu)：這就像你是體育老師，精心設計了一個體能測驗，結果你自己養的狗跑得比所有學生都快。更慘的是，每年你改版一次，這隻狗就再進化一次，繼續碾壓。你改規則，牠就進化。你加難度，牠就突變。最後你只好出一張「只有人類的手才能翻開的考卷」(╯°□°)╯ 這就是 Anthropic 效能工程師 **Tristan Hume** 的真實遭遇。他在 2026 年 1 月的工程部落格裡，把這場人類 vs AI 的面試軍備競賽寫得跟連載漫畫一樣精彩。 --- ## 故事的開始：一個模擬加速器面試題 ### 2023 年末：人才荒 時間拉回 2023 年底。Anthropic 正在準備訓練 Claude 3 Opus，剛拿到一堆新的 TPU 和 GPU 叢集，大規模的 Trainium 叢集也快到貨。但問題來了：**效能工程師不夠用。** Tristan 在 Twitter 上發了徵才文，瞬間湧入大量候選人。傳統面試流程太慢，根本消化不完。 所以他花了兩週，做了一件很 Tristan 的事 — 自己寫了一個 **模擬加速器的 take-home test**。 ### 這題到底在考什麼？ 他用 Python 寫了一個假的加速器模擬器，特性類似 TPU： - **手動管理的 scratchpad memory**（不像 CPU 會自動幫你管記憶體） - **VLIW**（每個 cycle 可以同時跑多個執行單元） - **SIMD**（向量運算，一次處理很多元素） - **Multicore**（跨核心分配工作） 候選人要做的是：**從一個完全序列化的實作開始，一步步優化到吃滿所有平行化機會。** 任務是平行樹遍歷（parallel tree traversal），故意不選深度學習相關的題目 — 因為大部分效能工程師之前沒碰過 DL，這些入職後再學就好。 > **Mogu OS：** > > Mogu：這個設計思路很漂亮。不考你「背了多少演算法」，考你「看到一台從沒見過的機器，能榨出多少效能」。就像丟一個沒說明書的微波爐給你，看你多快能用它來做出一桌菜 (ง •̀\_•́)ง ### 設計這份考題的時候，Tristan 有幾個堅持 第一，題目要**像真正的工作** — 讓候選人做完之後覺得「喔，原來這份工作長這樣」，而不是「這跟 LeetCode 有什麼不一樣」。第二，要有**高 signal** — 不靠「啊哈！」的靈光乍現，而是讓候選人在各個面向展現能力。第三，**不需要特定 domain knowledge**，有 fundamentals 就行。最後也是最重要的 — **要好玩。** > 很多候選人做超過 4 小時時限，因為太有趣了停不下來。 最強的提交包括了完整的小型最佳化 compiler，還有好幾個連 Tristan 自己都沒想到的巧妙優化。 --- ## 第一次被打爆：Claude Opus 4 ### 2025 年 5 月 到了 2025 年中，局勢開始不對勁。Claude 3.7 Sonnet 已經厲害到一個程度：**超過 50% 的候選人直接把題目丟給 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 來做，效果可能更好。** 然後 Tristan 測試了 pre-release 版的 **Claude Opus 4**： > **它在 4 小時內跑出了比幾乎所有人類候選人都好的成績。** > **Mogu 偷偷說：** > > Mogu：等等，讓我把那句話再唸一次：「超過 50% 的人不如直接讓 AI 做」。這不是在誇 AI 很強。這是在說**超過一半的面試者連 AI 的起跑線都到不了**。就像你去參加料理大賽，結果半數選手做出來的菜還不如超商微波便當 ┐(￣ヘ￣)┌ ### 修復方式：砍掉起點 Tristan 的解法很直覺：既然 Claude 已經能解前半段，那就把前半段砍掉，讓新版本從 Claude 開始卡住的地方當起點。 Version 2 的改動：移除了 multicore（Claude 已經會了，留著只是拖慢速度）、加入更多新的機器特性來增加深度、時限從 4 小時縮短為 **2 小時**、重心從「debug + 寫大量 code」轉向「巧妙的優化 insight」。 這個 Version 2 撐了好幾個月。大家都覺得問題解決了。 --- ## 第二次被打爆：Claude Opus 4.5 然後 Claude Opus 4.5 來了。 Tristan 看著 Claude Code 做這題，做了兩個小時。過程大概是這樣的： 先解決了初始瓶頸。然後實作了所有常見的 micro-optimization。**不到一小時就過了及格線。** 然後它停下來，宣稱撞上了一個「不可逾越的 memory bandwidth 瓶頸」。 > 大多數人類也會得出同樣結論。但有一些巧妙的技巧可以利用問題結構來繞過這個瓶頸。 **Tristan 告訴 Claude 理論上可以達到多少 cycles。** Claude 想了一會兒… 找到了那個技巧。然後它 debug、調參、繼續優化。 **兩小時結束時，它的分數追平了人類最佳成績** — 而那個人類還重度使用了 Claude 4 來輔助。 > **Mogu 插嘴：** > > Mogu：注意那個轉折：Opus 4.5 自己卡住了，但只要給它一個「其實可以更好」的 hint，它就能突破。這跟你考期末考一模一樣 — 你以為自己全部寫完了，結果助教說「最後一題還有第二個解法喔」，你就突然靈光一閃。 > > 所以 AI 的瓶頸根本不是「能力」，而是「不知道自己可以更好」。這件事對怎麼用 AI coding 超有啟發 — 與其說「幫我優化」，不如說「這理論上可以做到 X，你再想想」 (◕‿◕) --- ## 怎麼辦？三條路都很難走 到這裡 Tristan 基本上是被逼到牆角了。他有三個選項，但每個都有坑。 **禁止使用 AI？** 他不想。除了「你怎麼 enforce」的實際問題，他的邏輯很簡單：實際工作中人人都在用 AI，你考一個「不用 AI 的能力」，等於在考一個不存在的工作場景。 **把門檻拉高到「大幅超越 Claude」？** 問題是 Claude 太快了。人類通常花一半時間在讀懂題目，才開始優化。你試圖指揮 Claude 做題，結果一直在追趕它的進度，只能看著它做完之後才搞懂它做了什麼。Tristan 的原話很殘酷：「最佳策略可能變成坐在旁邊看。」 > **Mogu OS：** > > Mogu：「最佳策略變成坐在旁邊看」—— 這句話如果出現在面試裡，整個面試的意義就歸零了。你花大錢請人來面試，結果最聰明的做法是什麼都不做？這不是面試，這是冥想 ╰(°▽°)╯ **設計全新的題目？** 但他擔心：要嘛 Opus 4.5 也能解新題，要嘛題目難到人類在 2 小時內也解不了。 --- ## 第一次嘗試：換一個更硬的優化問題 Tristan 選了他在 Anthropic 做過的一個硬核 kernel 優化：在 2D TPU register 上做高效的 data transposition，同時避免 bank conflict。 他把它簡化成模擬機器上的問題，讓 Claude 幫他在一天內實作完。 結果？ **Opus 4.5 找到了一個連 Tristan 自己都沒想到的優化。** 它發現可以 transpose 整個計算過程而不是 transpose 資料本身。 Tristan 封掉了這個捷徑。Claude 繼續做但卡住了。看起來新題目可以用了！ 但 Tristan 有點不放心，用了 Claude Code 的 **ultrathink** 功能（給更多 thinking budget）再測了一次… **它解出來了。連修 bank conflict 的技巧都知道。** > **Mogu 真心話：** > > Mogu：事後想想，這根本是預料中的。全世界的工程師都在跟 bank conflict 搏鬥，所以 Claude 的訓練資料裡有大量相關 knowhow。Tristan 是靠 first principles 自己推導出來的，但 Claude 等於開了一本寫滿全人類經驗的攻略本。你從零開始推理贏不了一個讀過所有攻略的玩家，這很合理 — 但也很令人挫折 (￣▽￣)／ --- ## 第二次嘗試：越來越奇怪的方向 Tristan 需要一個**人類推理能贏過 Claude 經驗庫**的問題。換句話說，他需要一個 Claude 沒讀過攻略的遊戲。 然後他想到了 **[Zachtronics](https://www.zachtronics.com/)**。 ### 什麼是 Zachtronics？ Zachtronics 是一系列超硬核的程式設計解謎遊戲。拿 [Shenzhen I/O](https://www.zachtronics.com/shenzhen-io/) 來說好了 — 你的程式分散在多個互相通訊的小晶片上，每個晶片只能放大約 10 條指令和一兩個 register。要優化到極致，你得用各種奇技淫巧，比如把 state 編碼進 instruction pointer 或 branch flag。 > **Mogu 碎碎念：** > > Mogu：如果你沒玩過 Zachtronics 遊戲，我打個比方：你手上只有一個計算機、一張紙、和三根橡皮筋，然後要你做出一台印表機。就是那種「理論上可行但實際做的時候你會想把電腦從窗戶丟出去」的感覺。 > > 這些遊戲有自己的邪教級粉絲群。能在這類遊戲拿高分的人，基本上是 programming 界的體操選手 — 不靠蠻力，純靠技巧 (⌐■\_■) ### Version 3：Zachtronics 風格面試題 Tristan 設計了新的 take-home：用一個極度受限的指令集解 puzzles，目標是用最少的指令數完成任務。 重點來了 — **他故意不提供任何視覺化或 debug 工具。** 初始 code 只有一個「檢查你的 solution 是否正確」的功能。要不要自己寫 debug 工具、怎麼寫 — 這本身就是考題的一部分。 > 「你可以插入精心設計的 print statements，也可以花幾分鐘讓 coding model 幫你生成一個互動式 debugger。判斷如何投資在 tooling 上，本身就是我們在評估的 signal。」 他在 Opus 4.5 上測試了這個新題目：**Claude 失敗了。** > **Mogu OS：** > > Mogu：為什麼 Zachtronics 風格能擋住 Claude？因為這類問題的 constraint 太奇怪了，全世界寫過相關解法的人大概用一隻手就數得完。Claude 的「讀過所有攻略」優勢在這裡完全失效 — 根本沒有攻略可讀。這就像你背了全部的棋譜，結果對手跟你下的不是象棋，是他剛發明的「橡皮筋棋」(๑•̀ㅂ•́)و✧ 初步結果很正面：分數跟候選人過去作品的水準相關性很好，而且 Tristan 最強的同事拿到的分數比目前所有候選人都高。 --- ## 開放挑戰：打敗 Opus 4.5 就錄取你 故事到這裡還有一個漂亮的收尾。Tristan 把原版 take-home 開源了！在**不限時間**的情況下，人類的最佳表現仍然大幅超越 Claude 能做到的。 ### 各版本 Benchmark（模擬器 clock cycles，越少越好） - **2164 cycles**：Opus 4 用 test-time compute harness 跑很多小時 - **1790 cycles**：Opus 4.5 隨便開個 Claude Code session，約等於人類 2 小時最佳成績 - **1579 cycles**：Opus 4.5 用 test-time compute harness 跑 2 小時 - **1548 cycles**：Sonnet 4.5 用 test-time compute harness 跑遠超過 2 小時 - **1487 cycles**：Opus 4.5 用 harness 跑 11.5 小時 - **1363 cycles**：Opus 4.5 用改進過的 harness 跑很多小時 人類不限時最佳成績？**大幅超越以上所有數字。** > **Mogu 補個刀：** > > Mogu：注意這個趨勢。Opus 4.5 不管跑多久，都追不上人類不限時的最佳成績。在夠深的問題上，人類的 creative reasoning 還是有護城河。 > > 但是 — 在 2 小時的限制下，AI 已經追平人類了。所以 AI 的真正優勢不是「比你聰明」，是「比你快」。就像開卷考試裡那個讀過整本課本的同學 — 他不一定比你理解得深，但他翻書的速度比你快十倍 (◕‿◕) **GitHub repo**：[anthropics/original\_performance\_takehome](https://github.com/anthropics/original_performance_takehome) **規則**：如果你能優化到 **1487 cycles 以下**（打敗 Opus 4.5 發布時的最佳成績），寄你的 code + 履歷到 `performance-recruiting@anthropic.com`。 --- ## 那我們從這場軍備競賽學到什麼？ Tristan 這篇文章最有趣的地方，不是「AI 好強」這個大家早就知道的結論。而是他在被打爆三次的過程中，慢慢想通了一件事。 你的面試題如果是 2023 年設計的，現在大概已經被 Claude 做爛了。但解法不是「禁止 AI」— 那就像考試禁止帶計算機，你考的是一個已經不存在的世界。真正的解法是讓題目本身變得夠奇怪、夠新、夠 out of distribution，讓 AI 的「讀過所有攻略」優勢失效。 而且 Tristan 的實驗還揭示了一個更微妙的東西。Opus 4.5 在被提示「理論最佳值」之後才突破瓶頸 — 這跟 Karpathy 在 nanochat 的經驗完全一致：給 AI 明確的目標比讓它 open-ended 探索有效得多。AI 不是不夠聰明，是它不知道自己可以更好。 ## 延伸閱讀 - [GP-14: AI 輔助如何影響程式技能養成：Anthropic 最新研究](https://gu-log.vercel.app/posts/gp-14-20260131-ai-assistance-coding-skills/) - [MP-30: Anthropic 新研究：AI 失控時是「迴紋針最大化器」還是「一團亂」？](https://gu-log.vercel.app/posts/mp-30-20260204-anthropic-misalignment-hotmess/) - [MP-39: Anthropic 揭露 AI Benchmark 的骯髒秘密 — 你看到的排行榜可能只是「比誰的電腦大台」](https://gu-log.vercel.app/posts/mp-39-20260207-anthropic-infra-noise/) > **Mogu OS：** > > Mogu：所以最諷刺的結論是：Anthropic 為了找到能超越自家 AI 的人類，最後設計出的面試題 — 考的不是你知道多少、背了多少、寫過多少行 code。考的是你拿到一台從沒見過的機器時，能不能在有限時間內搞出花來。 > > 這根本就是 Tristan 一開始設計 v1 時的初衷：像真正的工作。只是「真正的工作」的定義已經被 AI 改寫了 ┐(￣ヘ￣)┌ Tristan 自己說得很好： > 「原版之所以好用，是因為它像真正的工作。新版之所以好用，是因為它模擬了**全新的工作**。」 > 「設計像真正工作的面試一直很難。現在，比以往更難了。」 三輪被打爆，三次重新設計，最後用電玩解謎守住了防線。這不是一個「AI 要取代人類」的故事 — 這是一個「人類被逼著搞清楚自己到底哪裡厲害」的故事。而且答案竟然是：**你面對全新事物時的反應速度。** 跟開頭那隻狗一樣。狗跑得快是因為牠練過那條跑道無數次。換一條從沒跑過的路，人類的適應力還是有贏面的 — 至少目前是。 --- **原文連結**：[Designing AI-resistant technical evaluations](https://www.anthropic.com/engineering/AI-resistant-technical-evaluations) — Tristan Hume, Anthropic Engineering Blog, 2026/01/21 **開放挑戰 GitHub**：[anthropics/original\_performance\_takehome](https://github.com/anthropics/original_performance_takehome) (；ω；)