Amp 把預設模型從 Claude 換成 GPT，沒有一個人抱怨——這件事對你怎麼用 coding agent 的意義

瀏覽次數: 1

本文大綱

一次「應該要出事」的預設變更

2026 年 7 月 9 日，Amp 上線了 the Dial：把原本的 agent 模式 smart / deep / rush / large 換成 low / medium / high / ultra 四檔難度。同一次發版，他們順手做了一件照理說會引發暴動的事——換掉預設模型。

7 月 29 日，Amp 團隊在 changelog 上交代了結果，第一句話是：「Two weeks ago we shipped the Dial and quietly did something that is supposed to be traumatic: we changed the default model.」原本的預設 smart 跑的是 Claude Opus 4.8，新的預設 medium 跑的是 GPT-5.6 Sol，reasoning effort 還是 medium 這一檔。用他們自己的話：大多數 Amp 使用者一夜之間從 Anthropic 換到了 OpenAI。

接著是「We braced for the outcry.」——他們準備好了要被罵。結果：「Nothing happened. Not a single complaint.」

這件事值得你花十分鐘讀完，不是因為它是產業八卦，而是因為它直接指向一個很多工程師每天在浪費時間的地方：你花在「挑哪個模型」上的力氣，可能是整條 agent 工作流裡槓桿最低的一環。下面我會先把 Dial 的機制講清楚，再誠實拆一下這組數據能證明什麼、不能證明什麼，最後給你在 Claude Code 上照做的具體設定、subagent 檔案和 prompt。

數據長什麼樣

Amp 公布的是自家 production 使用數據（注意：這是他們單方回報的內部數字，沒有第三方驗證）：

Dial 上線前一天，smart 模式承載 55% 的新 thread。一週後：零。
一週後，四個 Dial 檔位合計承載 93% 的新 thread，其中 medium 一檔就吃掉 三分之二。
在使用 Dial 的人裡，69% 從來沒有把它調離 medium。
Amp 有留逃生門：舊模式可以用 plugin 裝回來（amp plugins add --auto-update @amp/<mode>-classic）。他們的說法是「Almost nobody installed them」——幾乎沒人裝。

最後一項其實比「沒人抱怨」更有說服力。抱怨要打字、要有情緒、要相信有人會看；裝一個 plugin 只要一行指令。連一行指令都懶得打，代表的不是「懶」，是真的沒有感覺到差異。

運作原理：Dial 換掉的是那道選擇題

Dial 的機制本身很簡單，但設計上有一個關鍵決定值得偷。

第一，它問的問題換了。舊模式 smart / deep / rush / large 是在描述「agent 用什麼姿態工作」，你得先自己翻譯成「所以我這個任務該用哪個」。Dial 只問一件事：這個任務多難？Amp 官方對四檔的定義是：

low——你完全知道你要什麼。bug fix、寫測試、你能精確描述的 refactor。
medium——你大概知道你要什麼。**這一檔應該是你的預設。**它負責處理雜亂的多段任務、模糊需求、你沒講明的步驟。
high——你知道改哪裡，但要改對很難。跨模組改動、並發問題、漏一個細節就很貴的 bug。
ultra——結果清楚，但路徑全是未知。遷移、架構改動、跨很多檔案與系統、模型得邊做邊發現的決策。

這個換法的精髓在於：它把 UI 綁在使用者手上真的有的資訊。你當然知道自己這個任務多難——那是你的 repo、你的 ticket。但你不知道 GPT-5.6 Sol 在 xhigh reasoning 下跟 Claude Fable 5 差在哪，那需要跑 benchmark、需要追每週的 model release。要求使用者提供他沒有的資訊，就是把系統的不確定性外包給使用者。

第二，每一檔背後是「模型 + reasoning effort」的組合，而不只是模型。根據 Amp 的 the Dial 公告，四檔的配置是：

檔位	主模型	oracle（第二意見）
`low`	GLM-5.2（Z.ai 的開源權重模型）	GPT-5.6 Sol
`medium`	GPT-5.6 Sol，medium reasoning	GPT-5.6 Sol，high effort
`high`	GPT-5.6 Sol，xhigh reasoning	Claude Fable 5
`ultra`	Claude Fable 5（配專用 system prompt）	GPT-5.6 Sol

注意 reasoning effort 被折進檔位裡了。舊設計是你先挑模式、再另外循環 effort 等級，兩個旋鈕要各轉一次；新設計一次轉完。這是把兩個維度壓成一個使用者能回答的維度。

第三，每一檔都配 oracle，而且頂上兩檔是交叉的。high 是 Sol 寫、Fable 審；ultra 是 Fable 寫、Sol 審。這招我認為是整個 Dial 裡最可移植的一塊：不是「選一個最強的模型」，而是讓寫的人和審的人不是同一個模型。同一個模型審自己的產出，會系統性地錯過同一批盲點。

第四，這才是 Amp 敢換預設的真正理由。當使用者選的是難度而不是模型，模型就變成 Amp 這一側的實作細節。他們可以隨時換掉背後的模型，只要同一檔位的行為體感不變。Amp 在文中也明講了：他們會繼續 benchmark、繼續換模型，因為「across every thread on every tier, small differences compound」。個人層級感覺不到的差異，在平台層級會累積成真的差異。

那篇 changelog 的收尾我覺得寫得很好：「The default is good because someone is paid to care about it, and it does not have to be you.」預設值好，是因為有人被付錢在乎它——那個人不必是你。

這組數據能證明什麼，不能證明什麼

這裡要誠實一點，因為這篇 changelog 很容易被過度引用成「模型不重要了」。它不是這個意思，而且它的證據強度有明確的邊界：

這是 adoption 數據，不是品質數據。零抱怨不等於品質沒掉。Amp 沒有公布任何換模型前後的品質對照——沒有 A/B、沒有 SWE-bench 之類的公開分數、沒有任務完成率。它證明的是「使用者感知不到差異」，這跟「客觀上沒有差異」是兩件事。感知本身是有門檻的：agent 任務的變異度本來就很高，同一個 prompt 跑兩次結果都不一樣，這種噪音會蓋掉相當大的真實差異。

69% 沒調過，一部分就是預設效應的定義。medium 是預設值，「大多數人不動預設值」在任何產品上都成立。這個數字真正說明的是「預設值沒有難用到讓人想去動它」，不是「medium 對每個人都是最佳解」。

抱怨的 base rate 本來就很低。會主動寫 feedback 的使用者永遠是少數。「一則抱怨都沒有」很強，但「沒有抱怨」跟「沒有人不爽」之間還是有距離。

「frontier 模型差異已經很小」是在 Amp 自家 harness 裡的觀察。同一個模型換到不同的 harness、不同的 system prompt、不同的工具集，表現差距會被放大或縮小。這個結論不能直接搬到你的自製 agent 上——你得在自己的 harness 裡驗。

Amp 自己並不相信模型不重要。他們持續 benchmark 換模型這件事本身，就說明模型選擇的重要性沒有消失，只是責任位置移動了：從每個使用者身上，移到了設計預設值的那個人身上。

所以正確的讀法是：選模型不是使用者的槓桿，是平台方的槓桿。如果你是團隊裡幫大家決定 agent 設定的人，你就是那個平台方。

那你的槓桿在哪？三個旋鈕

Amp 在文中點名了三件比「用哪個 frontier 模型」影響更大的事：任務難度、你放進去的 context、你多仔細看它輸出的東西。下面把這三件事翻成 Claude Code 上可以直接照做的操作。

旋鈕一：在 Claude Code 上蓋自己的 Dial

Claude Code 目前把「模型」和「effort」拆成兩個旋鈕，所以你要自己把它們綁成檔位。先確認可用範圍（以官方 model configuration 文件為準）：

effort 等級：Fable 5、Opus 5、Sonnet 5、Opus 4.8、Opus 4.7 支援 low / medium / high / xhigh / max；Opus 4.6 與 Sonnet 4.6 只有 low / medium / high / max。
預設 effort 在所有支援的模型上都是 high，只有 Opus 4.7 例外（預設 xhigh）。
如果你設了當前模型不支援的等級，Claude Code 會退到它支援的最高等級（例如 xhigh 在 Opus 4.6 上會以 high 執行）。

第一步：把模型決定一次，寫進設定，之後不要再動它。

// ~/.claude/settings.json
{
  "model": "claude-opus-5",
  "effortLevel": "medium",
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

effortLevel 接受 low / medium / high / xhigh。fallbackModel 是主模型過載時的備援鏈，上限 3 個，而且不會跨設定檔合併——優先權最高的那個檔案提供整條鏈，所以別指望 user settings 跟 project settings 各寫一半。

注意 model 只在 session 啟動時讀一次，session 中要換得用 /model。從 v2.1.153 起 /model 會把你的選擇寫回 user settings 當新預設——這其實有點反 Dial 精神，如果你想維持「模型固定、只動 effort」的紀律，把 model 寫在 project settings 或 managed settings 裡會比較穩，因為它們的優先權高於 user settings，下次啟動會蓋回來。

第二步：把難度分檔做成 session 內的一個動作。

/effort low       # 你完全知道要什麼：改一行、補一個測試
/effort medium    # 預設檔：多段任務、需求還有點模糊
/effort xhigh     # 改對很難：跨模組、並發、資料一致性
/effort max       # 路徑全是未知：遷移、架構改動

幾個實務細節：low / medium / high / xhigh 在互動 session 裡設定會跨 session 記住，max 只作用於當前 session（除非用 CLAUDE_CODE_EFFORT_LEVEL 環境變數設）。/effort 選單裡還有一個 ultracode——它不是模型的 effort 等級，而是 Claude Code 的設定：送 xhigh 給模型，並額外讓 Claude 對較重的任務去編排 dynamic workflow，只作用於當前 session。

第三步：如果你習慣一個任務開一個終端機，把四檔做成 shell alias。

alias cc-low='claude --model claude-sonnet-5 --effort low'
alias cc-med='claude --effort medium'
alias cc-high='claude --effort xhigh'
alias cc-ultra='claude --model fable --effort max'

--model 和 --effort 只作用於你啟動的那個 session，所以不同終端機可以同時跑不同檔位——這比用 /model 切來切去乾淨。model alias 可用 default / best / fable / sonnet / opus / haiku / sonnet[1m] / opus[1m] / opusplan。

順便說 opusplan：plan mode 用 Opus、進執行階段切 Sonnet。這其實就是 Amp 那套「不同階段用不同模型」的縮小版，而且是官方內建的，不需要你自己 orchestrate。想試「規劃要貴、執行可以便宜」這個假設，這是成本最低的入口。

第四步（團隊）：把檔位鎖起來。availableModels 可以限制使用者能選的模型（主 session、subagent、skill、advisor 都吃這個設定），例如 ["sonnet", "haiku"]。要連 Default 選項也一起限制，得再加 enforceAvailableModels——這個只能在 managed settings 裡設。

旋鈕二：每個檔位配一個 oracle

Amp 每一檔都有 oracle，頂上兩檔還刻意用另一家的模型。這招在 Claude Code 上可以直接複製，因為 subagent 的 frontmatter 能獨立指定 model 和 effort。

建立 .claude/agents/oracle.md（專案層）或 ~/.claude/agents/oracle.md（個人層）：

---
name: oracle
description: 第二意見審查者。當改動跨多個檔案、涉及並發、交易邊界、資料一致性、或牽動公開 API 時，用它審。不要用它寫程式。
tools: Read, Grep, Glob, Bash
model: fable
effort: xhigh
---

你是第二意見審查者，不是實作者。你不修改任何檔案。

收到任務時：
1. 先讀 diff（git diff 或指定範圍），再讀被改動檔案的完整上下文，不要只看 diff 的那幾行。
2. 列出這次改動的「隱含假設」——作者以為成立、但程式沒有保證的事。每一條標明在哪個檔案哪一行會爆。
3. 針對每個問題給：觸發條件（具體輸入或狀態）→ 實際會發生什麼。給不出觸發條件的疑慮，標成「未確認」而不是「問題」。
4. 最後給一個判斷：可以合 / 要改 / 方向錯。方向錯的話講清楚錯在哪一層。

不要複述程式在做什麼。不要提風格問題。不要為了湊數量而列問題——沒問題就說沒問題。

frontmatter 只有 name 和 description 是必填；model 預設是 inherit（跟主 session 同一個模型），所以你必須明確寫 model，否則就退化成同一個模型審自己，那就失去 oracle 的意義了。effort 會覆蓋 session 的 effort 等級。

呼叫方式就是在 prompt 裡明講——Amp 那邊也一樣，他們的 manual 寫的是在 prompt 裡寫「Use the oracle to review…」或「Ask the oracle whether…」：

用 oracle 審這次 diff。重點看 payment 那三個 handler 的重試邏輯：
如果 webhook 重複送同一個 event id，會不會重複扣款？

兩個進階選項：isolation: worktree 讓 subagent 在獨立的 git worktree 跑，不會跟主線搶檔案（沒有改動的話 worktree 會自動清掉）；maxTurns 可以限制它的回合數，避免一個審查 agent 自己跑成一場冒險。另外 settings 裡有 advisorModel（server-side advisor 用的模型，接受 opus / sonnet 這類 alias），也可以一起設。

旋鈕三：context——Amp 官方點名「最常被忽略的建議」

Amp 有一頁 notes 叫 Frequently Ignored Feedback，專門講使用者最常忽略的建議。裡面有三條特別反直覺，我認為值得逐條抄下來：

一、不要把檔案藏起來。很多人第一反應是限制 agent 能看到的檔案範圍，怕它亂改。Amp 的立場是反的：藏資訊會鼓勵它去找「有創意的繞路方式」（creative workarounds）。正確的方向是寫更詳細的 prompt、把規則寫進文件檔，而不是縮小它的視野。

二、不要每一筆編輯都要求核准。Amp 的原話是這會「traps you in a local maximum by impeding the agentic feedback loop」——逐條核准會打斷 agentic 迭代循環，把你鎖在局部最佳解。要給它機會靠 review、diagnostics、compiler output、測試執行去改自己的第一版。這條跟很多人的直覺完全相反，但邏輯是通的：你在第一版就介入，它永遠沒機會用工具發現自己錯了。

三、不要叫模型自報身份。問「你是哪個模型」會花掉 system prompt token，同時吃掉你本來可以用的 context。有趣的是，這條也順帶回答了本文的主題：在 Dial 的設計裡，「我現在跑的是哪個模型」這個問題本身就是浪費。

具體怎麼把 context 做好：

專案文件只放事實，不放個性。Amp 讀 AGENTS.md，搜尋範圍是當前目錄往上到 $HOME、加上 agent 讀到的子目錄裡的 AGENTS.md、加上系統層（如 /etc/ampcode/AGENTS.md）和使用者層（$HOME/.config/amp/AGENTS.md）；找不到 AGENTS.md 時會 fallback 讀 AGENT.md 或 CLAUDE.md——所以你的 CLAUDE.md 在 Amp 裡也是有效的。Amp 的 AGENTS.md 還支援兩個很實用的功能：用 @ 引其他檔案（例如 See @doc/style.md and @specs/**/*.md），以及在 YAML frontmatter 用 globs 做條件載入——只有當 agent 讀到符合 glob 的檔案時，那段指示才會載入。這比把所有規則一次塞進主檔省 context 得多。

任務描述用固定模板。這是我自己在用的骨架，五個欄位，缺一個就會被 agent 用猜的補上：

目標：<一句話，講結果不講做法>
動這裡：<檔案 / 模組>
不要動：<明確列出，尤其是 schema、公開 API、既有測試>
完成的定義：<可執行的指令，例如 pnpm test payments 全綠、且 tsc 無錯>
自我驗證：先跑上面的指令，失敗就自己修，修不了才回來問我。
未知的部分：<你自己也不確定的地方，直接說「這裡我不確定，先給我兩個方案再動手」>

最後一欄是關鍵。agent 最容易出事的地方不是它不會寫，是它不知道你其實也不知道。你把不確定標出來，它就會停下來問；你不標，它就會挑一個方向直接做完 800 行。

旋鈕四（Amp 沒單獨列但同樣重要）：review 怎麼做

**讀 diff，不讀它的敘述。**agent 的總結是它「以為」自己做了什麼，diff 是它真的做了什麼。這兩者的落差正是 bug 的產地。
把完成定義寫成指令。「跑 pnpm test payments 要全綠」跟「確保功能正常」對 agent 是完全不同等級的訊號。前者它能自己驗證並迭代，後者它只能自我宣告成功。
**reviewer 只給 diff + spec，不給實作過程的對話。**如果 reviewer 看得到「為什麼這樣寫」的推理過程，它會被說服。把上面那個 oracle subagent 拉出來獨立跑，就是為了這個。
**不要讓 review 只在最後做一次。**跨檔案的大改動在 ultra 級任務裡，中間審一次比最後審一次便宜太多。

什麼時候「選模型」還是重要的

這篇文章的結論不是「隨便用哪個模型都一樣」。有幾種情況模型選擇仍然是主要變數：

你的任務剛好落在模型差異最大的那條軸上。超長 context 的整檔重構、冷門語言或框架、工具呼叫的穩定度、前端視覺品質——這幾條軸上不同模型的差距還是明顯的。判斷方法很土但有效：拿你 repo 裡三個真實任務，兩個模型各跑三次，看的不是平均值而是最差那次。agent 工作流的痛苦來自尾端，不是平均。

成本壓力大的時候。Amp 的 low 檔用的是 GLM-5.2 這種開源權重模型，這是明確的模型選擇而不是 effort 選擇。如果你有大量「你完全知道要什麼」的機械性任務，換小模型省下來的錢是實的。

你在做 harness 或平台。Amp 自己說 small differences compound，所以他們不停 benchmark。如果你是幫團隊 100 個人決定預設值的那個人，你就是那個「被付錢在乎它」的人，你不能把這件事外包給 changelog。

合規與資料落地。這時候模型選擇是政策問題，不是品質問題，本文的邏輯完全不適用。

對工程團隊的意義：一份 30 分鐘的動手清單

**把模型從個人選擇變成團隊預設值。**在 repo 的 .claude/settings.json 寫定 model 與 effortLevel，讓大家啟動就在同一個基準上。要更硬一點就用 managed settings 加 availableModels + enforceAvailableModels。
**指定一個人負責這個預設值。**季度性重測一次，用你自己 repo 的真實任務，不是用 benchmark 排行榜。這個人是唯一該關心模型排名的人。
**把難度分檔寫進團隊文件。**四句話就夠：「你完全知道要什麼 → low；大概知道 → medium；改對很難 → xhigh；路徑未知 → max」。貼在 onboarding 文件裡，比任何模型比較表有用。
**建一個 oracle subagent 進 repo。**明確寫 model（不要 inherit），讓寫的人和審的人不同源。
**檢查你的 CLAUDE.md 有沒有在浪費 context。**只留事實：架構、指令、禁區、慣例。長篇的流程文件抽成 skill 或用條件載入，用到才進 context。
**停掉逐條核准的習慣，改成用測試當閘門。**這是 Amp 官方點名最常被忽略的一條，也是最容易立刻見效的一條。
**在 Slack 裡把「哪個模型比較強」的討論改成一個 issue。**內容是：這三個真實任務，這兩個設定，各跑三次，貼結果。吵不出答案的問題，跑三次就有答案。

Amp 這篇 changelog 真正的貢獻不是「模型不重要」這個聳動的結論，而是把責任放回正確的位置：模型選擇是一個需要持續投入的工程問題，只是那個投入不該發生在每個工程師每次開 session 的時候。你該投入的地方是難度分檔、context、review——那三件事沒有人能幫你做。

來源

Amp Changelog, 〈Who Cares About the Model?〉, 2026-07-29（無署名，Amp 團隊）：https://ampcode.com/news/who-cares-about-the-model
Amp Changelog, 〈The Dial〉, 2026-07-09（四檔定義與各檔模型／oracle 配置）：https://ampcode.com/news/the-dial
Amp Notes, 〈Frequently Ignored Feedback (FIF)〉（不要藏檔案、不要逐條核准、不要問模型身份）：https://ampcode.com/notes/fif
Amp Manual（AGENTS.md 搜尋順序、globs 條件載入、oracle 呼叫方式、settings keys）：https://ampcode.com/manual
Amp Frontier Corporation 成立公告, 2025-12-02（Amp 自 Sourcegraph 獨立，20 位共同創辦人共同署名，含 Thorsten Ball、Quinn Slack、Beyang Liu 等）：https://ampcode.com/news/amp-inc
Claude Code Docs, Model configuration（model alias、effort 等級與各模型支援範圍、/effort、ultracode、opusplan）：https://code.claude.com/docs/en/model-config
Claude Code Docs, Settings（model、effortLevel、fallbackModel、availableModels、enforceAvailableModels、advisorModel）：https://code.claude.com/docs/en/settings
Claude Code Docs, Subagents（frontmatter 欄位含 model、effort、isolation、maxTurns；model 預設 inherit）：https://code.claude.com/docs/en/sub-agents