現代鋼鐵具有微弱的放射性。我們在 40 和 50 年代進行了大量的原子彈試驗，現在我們的大氣中含有一定數量的放射性粒子，這些粒子在生產過程中會進入鋼鐵中。這在大多數情況下沒問題，但某些科學儀器需要不具放射性的鋼鐵。為了獲得這種鋼鐵，人們通常會搜尋 1950 年代以前的鋼鐵（例如沉沒的德意志帝國海軍艦隊）。這是一張 SMS Hindenburg 號被打撈時的照片。

你可能會在戰前鋼鐵與 LLM 出現前的數據之間看到類比。事實上，這個想法去年已在多處被討論：在一篇 LinkedIn 貼文、一篇 Ars Technica 文章、一篇 Business Insider 文章，以及一篇 Harvard JOLT 文章 中。這是一個很好的類比，但不是我們想表達的那個。我們不談論數據，讓我們來談談人類。

現代軟體工程師是具有「放射性」的。

從歷史上看，如果你想估計一項軟體任務需要多長時間，你會要求一名軟體工程師「赤手空拳」^([1]) 地完成它，並記錄他們花費的時間。現在這幾乎是不可能的，因為幾乎所有軟體工程師都高度依賴 LLM。今天的一名工程師如果嘗試在沒有 AI 輔助的情況下執行特定任務，其速度會明顯慢於完成同一任務的「LLM 時代前」工程師。如果你試圖使用 LLM 時代後的工程師數據來估計 LLM 的時間跨度，你會得到有偏差的結果。^([2])

假設我們想透過增加更多 8-30 小時範圍內的任務來擴展 METR 基準測試。但當我們給人類一項他們在 2024 年能在 8 小時內完成的 METR 任務時，現在卻需要花費他們 20 小時。因此，我們不能僅以天真的方式擴展 METR 基準測試。順便提一下，METR 最近寫到了他們與受污染開發者打交道的經驗。在他們 2026 年 2 月的「提升更新」中，他們表示：「在受訪時，30% 到 50% 的開發者告訴我們，他們選擇不提交某些任務，因為他們不想在沒有 AI 的情況下完成這些任務。」^([3])

在獲取長跨度軟體/代理任務的人類數據方面，我們正面臨一個全新且根本性的問題。人類已經習慣了與 AI 一起進行工程開發。我們無法將 2026 年人類在軟體任務上的表現與 2024 年進行比較。

半人半機評測 (Cyborg evals)

我們該如何解決這個問題？我們提議進行「半人半機評測」：研究當前一代 AI 輔助的人類與下一代 AI 輔助的人類之間的評測表現差異。也就是說，我們正在比較：

<mjx-container jax="CHTML" display="true"><mjx-math><mjx-mi><mjx-c class="mjx-c1D438 TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D463 TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D44E TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D459 TEX-I"></mjx-c></mjx-mi><mjx-mo><mjx-c class="mjx-c28"></mjx-c></mjx-mo><mjx-mi><mjx-c class="mjx-c1D43B TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D462 TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D45A TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D45B TEX-I"></mjx-c></mjx-mi><mjx-mo space="3"><mjx-c class="mjx-c2B"></mjx-c></mjx-mo><mjx-mi space="3"><mjx-c class="mjx-c1D434 TEX-I"></mjx-c></mjx-mi><mjx-mi><mjx-c class="mjx-c1D43C TEX-I"></mjx-c></mjx-mi><mjx-msub><mjx-TeXAtom><mjx-mi size="s"><mjx-c class="mjx-c1D460 TEX-I"></mjx-c></mjx-mi></mjx-TeXAtom><mjx-mn size="s"><mjx-c class="mjx-c31"></mjx-c></mjx-mn></mjx-msub><mjx-mo><mjx-c class="mjx-c29"></mjx-c></mjx-mo></mjx-math></mjx-container>

因此，半人半機評測是一種提升研究（uplift study）。這些研究幫助我們了解新模型提供的實際改進，即使 AI 在進步且人類能力在改變。它們做起來也相對簡單且便宜。

我們可以想像這種研究的一些變體。例如，我們可以進行比較。考慮到如果模型 N 能夠完成「N + 人類」100% 的工作，那麼人類就徹底出局了。^([4])。如果你隨時間繪製這個圖表，你就走在了預測評測領域全面自動化的道路上。

這是一個由半人半機評測所啟發的預測可能呈現的樣子。（領域為軟體工程。）

半人半機評測還可以告訴我們 AI 勞動力與人類勞動力之間的關係。從雇主的角度來看，AI 勞動力和人類勞動力既是經濟替代品（AI 可以用來替代網頁開發人員），又是互補品（AI 提高了資深工程師的生產力和需求）。那麼「匯率」是多少？

假設你想估計 2026 年完成一項軟體任務的成本。你可能想查看在不同的人類勞動力和 AI 勞動力配置下完成任務的成本。在研究本文時，我們發現了最近關於製作（優質）編譯器這一困難任務的一些數據點。Anthropic「指派 Opus 4.6 使用代理團隊來構建一個 C 編譯器，然後（基本上）就放手不管了」。擁有編譯器設計博士學位的 Paul Biggar 使用 Claude Code 在 1-2 週內構建了一個 Darklang 編譯器，他說這項任務在沒有輔助的情況下「至少需要 2 年才能完成」。^([5]) 這是這些專案成本的圖表；請注意協同效應。

AI 勞動力與工程師勞動力之間的權衡取決於 AI 能力和任務本身。半人半機評測將為我們提供這種權衡的定量視角。

什麼樣的任務適合半人半機評測？

我們希望從半人半機評測的任務中得到什麼？一個重要的屬性是類似於「難度 + 辨別力」。我們希望評測是困難的，即它們不會輕易達到飽和。這裡的一個標準方法是讓評測包含不同難度級別的任務。如果你的任務是「通過/失敗」制的，這基本上是你必須做的。或者，你可以選擇具有廣泛序數結果的任務。例如，Vending-Bench 測試模型在模擬商業場景中能賺多少錢。理想情況下，任務即使在遙遠的未來也能區分表現。

另一個理想的屬性是類似於「經濟實用性」。我們希望評測結果能對應到實際完成的工作；經濟實用性與實際用途和價值非常吻合。它為我們提供了一個思考能力的良好方式。因此，任務應該類似於現實世界中專業人類（或人類+AI）團隊獲得報酬所做的工作。我們認為好的任務將是那些人類+AI 共同解決起來既簡單又有趣，但 AI 獨自解決卻很困難的任務。這些任務構成了當今軟體工程的前沿；這正是人們獲得報酬所做的事情！

以下是一些適合半人半機評測的具體任務想法。我們所有的建議在「難度 + 辨別力」軸上都表現良好，儘管它們在經濟實用性方面有所不同。

• 軟體複製： 給定一段現有的軟體，對其進行複製。這最適合具有良好現有測試和規格的軟體，以便我們可以自動驗證。這種方法已被 mechanize.work 提出並進行了更詳細的描述。單個任務對難度+辨別力不利，但可以透過評測中足夠多的任務來彌補。
• 開源複製： 使用開源專案來獲取這些任務。從開源專案中獲取最近的更改（最好帶有單元測試），並將其指派給代理。如果沒有單元測試，由於存在地面實況（ground truth），你可能可以使用 LLM 評判方法。這方面的一個例子是 SWE-smith。
• 優化： 最大化或最小化某些東西。這方面的例子有 Anthropic 的面試問題、Karpathy 的 autoresearch 以及 Vending-Bench。
• 遊戲： 遊戲！例子包括 Antim Lab 的評測 和 AI 玩神奇寶貝。
• 對抗性： 在任務本身中與另一個模型或人類競爭。我們喜歡將其視為「機器人大戰」方法。這方面的一個例子是 CodeClash 的評測。這裡的另一個任務想法是對抗性編碼：一個代理編寫代碼，然後另一個代理閱讀代碼並對規格進行更改，這對第一個代理來說處理起來將是極其困難的。
• 預測： 做出可以被評估的預測。在 Metaculus 的 FutureEval、ForecastBench 和 Prophet Arena 中可以找到一些不同的方法。你也可以稱之為「建模」或「數據分析」。

值得注意的是，上述連結的評測都沒有發布半人半機的分數。

半人半機差距 (The Cyborg Gap)

西洋棋是一個很好的半人半機差距的歷史說明。1997 年，最強的 AI 和最強的人類在西洋棋技能上旗鼓相當。2005 年，AI 優於最強的人類。從 2005 年到 2007 年，半人半機（或稱「半人馬」）優於 AI。從 2010 年到 2017 年，半人半機是否具有優勢尚存爭議。從 2017 年（AlphaZero）開始，半人半機相對於 AI 已無優勢。

如今，人類在現實世界中工作時，不再是純粹的、無 AI 輔助的人類。我們以半人半機的方式工作。在軟體工程領域尤其如此。目前，人類工程師（半人半機）比 Claude Code 強多少？這種能力差距是在縮小還是在擴大？這種差距何時會消失？這些都是我們可以透過半人半機評測來回答的問題。

• ^(^) 我發誓這是我聽過一位真正的軟體工程師說過的話。

• ^(^) 解決這個問題的一種方法是尋找「未受 AI 影響」的開發者。這已經非常困難了，特別是如果你在尋找專業級別的軟體工程師，而且只會變得越來越難。此外，「未受影響的開發者」並不能很好地代表平均具有經濟生產力的開發者。

• ^(^) 擴展 METR 基準測試的另一個困難在於，我們現在需要的任務持續時間比一年前長得多。以 METR 的術語來說，我們需要 8 小時到 30 小時的任務。即使拋開對工程師受污染的擔憂，尋找願意承擔這些任務的人本身就很困難且昂貴。這在 METR 2 月的貼文中有所討論。

• ^(^) 假設評測尚未飽和，並且納入了我們關心的每個領域。這第二個假設很大，所以我們可能想去掉它，轉而僅以特定領域的方式來思考。另一方面，你可以爭辯說，由於遞歸自我改進，軟體領域的全面自動化很快就會變成所有領域的全面自動化。

• ^(^) 一項任務被定義為「僅限 AI」是模糊的。必須有人來提示 AI、構建其框架、（在某些情況下）迭代其框架等等。Anthropic 專案中的工程師為其構建了一個自定義框架。

討論