跑從來
不是問題，
看才是

00 · 出發點

Anthropic 工程主管 Felix Rieseberg 在十月寫了一篇〈How to be more ambitious〉，把用 AI 的野心拆成四種：速度、高度、深度、廣度。他自己的例子是：去年初還在請 Claude 修某一次 crash，後來直接請 Claude 讓 app 保持不會 crash。

那篇文章真正有用的一句話，他順口帶過：為了讓 Claude 做到這件事，他先讓它能抓 crash report、對得出版本跟 commit、還給了它 Windows、macOS、Linux 三台機器去重現和驗證。

野心沒有變大。變大的是 Claude 能看到的東西。

這份報告是把那一句話拿來做實驗。三題單檔 Three.js，固定 prompt，在四個 surface 上各跑一次，記錄每一輪誰在看、看到了什麼、花了多少。Felix 說人被自己相信的可能性限制住，所以要更有野心；這份報告想問的是：如果差距根本不在信念呢？

01 · 自我效能

Felix 用的詞是 self-efficacy，Bandura 1977 年的概念：一個人對「自己能不能執行某個行為」的信念。他舉了三個例子——Dantzig 把未解難題當作業寫出來、Bannister 破四分鐘一英里之後 46 天就有人跟進、《網球內心遊戲》說太用力反而打不好——然後收尾：自我效能不是新問題，但現在是更強的問題。

把 Bandura 的理論攤開，會發現他的三個例子對應到理論裡的三個來源，而且剛好漏掉最強的那個。Bandura 說自我效能有四個來源：親身成功經驗、看到相似的人做到、別人口頭告訴你可以、以及你自己的生理與情緒狀態。四個裡面，親身成功經驗最強，口頭說服最弱。

「我們不夠有野心」這句口號本身，是四個來源裡最弱的那一種：口頭說服。轉貼別人的成果是第二種：替代經驗。真正最強的那一種——你自己從第 1 版走到第 6 版——他的文章前半段其實在做（季度業務檢討的例子從基本開始、每一步多一點），但沒有把這件事說出來。

而且 Bandura 區分了兩種期望：我做得出這個行為（efficacy），和這個行為會帶來那個結果（outcome）。他的例子全是「我自己跑得進四分鐘」；用 AI 的情境不一樣，你不需要相信自己跑得進，你需要相信的是「我能把這件事交代清楚、給它條件、驗證它」。信念的對象換了，例子沒換。

02 · 替代經驗的工業化

Bannister 現在是誰？Google 在 10 月 23 日發了一篇〈看看五位 builder 用 Gemini 4 Argon 做了什麼〉：水上飛機 3D 模擬、野火加地震的 3D 地球儀、互動渦輪引擎、一張圖變 3D 馬車、多人奪旗遊戲。五位都是 X 上的帳號，不是隨機社群使用者；Argon 10 月 13 日才正式開放，十天內做出來、被 Google 看到、被選進官方文章。

這是替代經驗被工業化：示範者由發表模型的公司挑選，示範者的條件不公開，迭代了幾輪不公開。文章給了「做出來的結果」，給不出任何一個「怎麼做出來」的欄位——用了哪個 surface、幾回合、多少 token、有沒有外部資產。

我們把文章裡的兩段影片逐格看了一遍（在自己的實驗凍結之後才看，時間戳記在 repo 裡）。水上飛機的 67 秒裡，飛機從頭到尾在水面上，HUD 顯示 27 節、怠速滑行，沒有起飛、爬升、轉彎。馬車的畫面右下角自己的規格面板寫著 POLYGONS 1,284,560 · TEXTURES 4K PBR；如果數字是真的，那是匯入的資產，不是「從一張圖做出來」的程序式幾何；就算數字是模型自己編的裝飾，它也是那個頁面對自己的宣稱。

03 · 光譜

Felix 說有人在飛、有人翅膀還沒張開。差距有多大、往哪個方向走，公開數據是這樣的。

兩件事看得出來。第一，光譜是巢狀的，分水嶺已經從「用不用」移到「用多深」：全人口尺度上會用 agent 寫 code 的是極少數，開發者尺度上三分之二天天在用。第二，差距在拉大，不在收斂——企業之間的倍數八個月翻了三倍。這就是 Felix 那句「自我效能以週為單位過期」的結構版本：先接上回圈的人每個月都在往前跑。

那模型本身呢？2026 年 10 月中的一份對照把三層拆開了。同一個 harness 裡跑 Terminal-Bench 2.1，Opus 5.5 是 87.64%、GPT-6 Astra 是 87.27%——模型平手。各自裝進自家工具跑 Terminal-Bench 4.0，Claude Code 64.85%、Codex 58.18%——harness 分高下。DeepSWE 上兩家都解 74% 的任務，Astra 每題約 4.43 美元、Opus 5 約 11.84 美元——價格決定誰用得起。三句話，剛好是這份報告的骨架。

模型平手，harness 分高下，價格決定誰用得起。

04 · 試飛協定

二手數據到這裡為止。要說「社交媒體上的 demo 當假設不當證據」，報告自己不能只靠二手。所以做了一個實驗，協定如下。

Claude Code 欄一次跑完三題，之後把 Task A 另外在三個聊天介面各跑一次：Claude web（Fable 5.1）、Claude web（Opus 5.5）、Gemini app（Gemini 4 Argon）。B、C 兩題只有 Claude Code 欄。

05 · 試飛記錄 · Claude Code 欄

十五次迭代，沒有一次花在「跑不跑得起來」。每一版第一次就零錯誤，import 和 CDN 路徑全對，五六百行單檔沒截斷。全部十五次都花在裁判看不見的地方，而且分成三類很乾淨。

關於第三題，實驗設計時擔心沒有 scaffold 的控制組會難太多、對齊失敗。結果 C 的迭代數跟 A 差不多。scaffold 改變的不是迭代次數，是錯的種類：有 Water.js 的 A 錯在畫面，沒 scaffold 的 C 錯在數字。而 Sky.js 這個 scaffold 幫了力學、扯了美術，最後被丟掉。

06 · 試飛記錄 · 四種駕駛艙

同一段 Task A 的 prompt，再在三個聊天介面各飛一次。

先講污染。兩個 Claude web 的回合是在同一個對話裡跑的，而那個對話已經讀過 Claude Code 欄的失敗清單——NearestFilter、Sky 發白、白泡沫在亮水面上看不見、低太陽影子拉長。偏差方向對那兩欄有利：失敗是強結果，成功不能下結論。Opus 那份用得最兇——它把投影光源抬到 32°、太陽留在 9°，兩個方向分開。這解決了上一輪裁判的抱怨，物理上影子跟水面反光對不上。事後知識典型的產物：解的是裁判的問題，不是場景的問題。

Gemini 那欄是整個實驗裡最乾淨的聊天介面測試，因為它沒看過任何一份 log。三回合長這樣：

三個缺陷——transmission 玻璃、貼在頂點波浪上的 180 個尾浪 quad、翼尖共面圓蓋——全部出在 prompt 沒要求的範圍。Gemini 的第 1 版是三份第 1 版裡最有野心的：自己加了小島、松樹、碼頭、三葉螺旋槳、航行燈、Catmull-Rom 閉環航線，還把 Water.js 的 vertex shader 整個改寫成真實頂點波浪。也是唯一一份跑起來有問題的。

沒有感知的野心，長出來的全是裝飾；壞掉的，也全是裝飾。

這一條不只這一家。OpenAI 自己的開發者社群九月有一串討論在抱怨 Codex 配 GPT-6 Astra：範圍失控、發明專案不需要的抽象、小 bug 變成稽核和驗證框架、明確禁止的事被當建議、缺資料就用合理的猜測填進去、一個 session 偏題跑四小時吃掉一大塊週額度、把綠色測試當完成的證據。沒有人替它辯護，有人貼了 skills 和 prompt 指引當解法。同一種失敗，跨了三家。

07 · 裁判的解析度

實驗打了自己一巴掌，值得單獨講。

協定裡「外部裁判」是 check.mjs：console error 加三張截圖。它對幾何和顏色有效，對時間上的缺陷是盲的。閃爍和卡頓是 60 fps 的現象，5 fps 的 headless 渲染加三張靜態截圖，根本看不見這一類東西。Gemini 欄的三個缺陷全是人眼用 60 fps 看出來的；Claude Code 欄的六迭代版本有沒有閃，截圖裁判沒有能力回答。

所以不能說「機器裁判比人眼強」。這把「看才是問題」推到第二層：不只是有沒有眼睛，是眼睛的時間解析度、空間解析度、能不能把珠子的位置印出來。Claude Code 欄之所以能收斂，不是因為 check.mjs，是因為每一題臨時寫的探針——那 250 行才是裁判。

Felix 在深度那一節堅持「別讓模型自己當裁判」，這一點對。但他沒說的是：外部裁判不是免費的，而且裁判至少要跟被裁判的東西一樣有能力，否則它只會告訴你「沒報錯」——而「沒報錯」正是聊天介面的第 1 版讓人覺得「看起來沒錯」的原因，因為人眼跟 check.mjs 一樣，看不到第 40 秒的事。

目標設定理論這裡有一條值得帶：Locke 與 Latham 三十五年的研究說具體困難的目標優於「盡力就好」，前提是承諾和回饋；2009 年〈Goals Gone Wild〉反過來列了副作用：視野窄化、指標作弊、看起來做到。對模型設高目標，承諾不是問題，回饋才是。沒有回饋的高目標，效果就是「看起來做到」。

08 · 公式

成果不是加法，是乘法：專業 × 工具 × 配額，任何一項是零，乘積就是 slop。這次三項都量到了。

工具那一項是 15 次迭代和 250 行探針。專業那一項體現在「知道要把珠子位置隨時間印出來」而不是看截圖——那是人的除錯直覺被 agent 複製了。配額那一項是 15 萬 token 買一個 50 分鐘的下午；對一個 Max 帳號來說，這不是每週能燒很多次的量。

還有一個不在公式裡、但從四欄對照裡冒出來的東西。Opus 一回合（帶事後知識）的版本，跟 Claude Code 六迭代的版本，對人眼來說差距不大。Claude Code 那 15 萬 token 買到的東西，有一大半是「知道哪裡會壞」，而那個知識一旦寫成 notes，只要幾百個 token 就能帶給下一個模型。

harness 的產出不只是成品，是失敗清單。失敗清單比成品值錢。

這就是 Felix 那句「先接好 crash report」的另一種說法。crash report 不是工具，是前一次失敗的記錄。接好它，等於讓下一次迭代從第 1 版之後開始。

09 · 三種屋子

鏡子篇說過兩種人、兩套用法。這次改成三隻小豬，因為大野狼是真的：鋸齒邊界每幾週就移動一次，撞到了才知道屋子夠不夠。

Felix 的「要更有野心」是對住磚屋的人講的。對住稻草屋、試過而且不滿意的人，那句話是 Bandura 四個來源裡最弱的那一種，開給一個缺的是條件的人。誠實的建議不是「想大一點」，是「先接好眼睛」。

鏡子篇結尾那段「別信這份報告，帶回去自己驗一次」，這篇等於把它做了一遍。要驗，協定在 repo 裡：三段 prompt 一字不改、裁判先於題目、人只准貼症狀。跑完把每一輪卡在哪寫下來——那份清單，會比你做出來的飛機值錢。

帶回去驗的最小版本：
1. 拿 prompts/A.md 原文，貼進你平常用的介面，一次生成。
2. 真的瀏覽器打開，看滿 60 秒。只記症狀，不記解法。
3. 把症狀原話貼回去，最多八回合。
4. 每一回合記：行數、能不能跑、你看到什麼、它改了什麼、改的是不是你沒要求的東西。
5. 跟 runs/ 裡的四欄對照。差的那一欄，就是你的屋子。

附 · 名詞

附 · 限制與污染聲明

• Claude Code 欄的功能清單是模型自評，人工判定欄在 RESULTS.md 裡刻意留白。
• token 全是估計：harness 沒有 /cost，用 session 預算計數器的差值加「字元數 ÷ 3.5」，一律 ±30%。Gemini 的 thinking token 未知。
• 兩個 Claude web 回合有污染，方向對該欄有利；Opus 欄同時混了模型大小與污染兩個變因，分不開。
• B、C 兩題只有 Claude Code 欄；四欄對照只在 Task A。
• 截圖裁判的時間解析度 5 fps；Claude Code 欄的成品是否閃爍未經人眼 60 fps 檢查。
• Google 影片的畫面是錄影，可能經過後製；我們的截圖是 headless SwiftShader。
• 作者立場：報告由 Claude 協助撰寫，Claude 是被比較的產品之一；所有數字附來源，請自行核對。