The Dial：Amp 把「選模型」變成「選難度」的四檔轉盤，怎麼用、怎麼搬到你的 agent

瀏覽次數: 1

你每天打開 coding agent，第一件事常常是選模型：要用最強的還是最快的？要不要開 extended thinking？這個選擇看似小，但選錯的成本很真實——用太弱，agent 反覆試錯、把 context 燒光還沒改對；用太強，一個改 typo 的任務等它「深思」三分鐘。

2026 年 7 月 9 日，Sourcegraph 的 Amp 團隊在 changelog 發了一篇叫〈The Dial〉的更新，把這件事重新設計。他們把原本的 smart / deep / rush / large 四個名字，換成一個轉盤：low / medium / high / ultra。這篇拆解它的機制、背後的模型配置，以及——更重要的——不管你用的是 Claude Code、Codex 還是 Cursor，怎麼把這套「難度轉盤」的心法搬過去用。

先講清楚：以下內容我是從 Amp 官方 changelog 與 Owner's Manual 讀來的，不是實測跑分。模型配置那段是 Amp 官方寫在文章裡的，我照實轉述並標註來源。

本文大綱

舊模式錯在哪：名字描述的是「模型」，不是「任務」

smart / deep / rush 這些名字，描述的是 agent 用什麼「姿態」工作：用最強模型、深度思考、還是快速低 token。問題是，使用者得先在腦內把「我手上的任務」翻譯成「該用哪種姿態」——而這個翻譯，其實很容易翻錯。

The Dial 的核心洞察是：這個翻譯應該由系統做，使用者只需要回答一個問題——

「這個任務有多難？」（原文：The dial asks one question: how hard is this task?）

過猶不及都有代價。低估難度，agent 一直失敗重試、燒 token、成本反而更高；高估難度，簡單任務浪費算力和你的時間，還常常回你一份過度工程的 diff。轉盤的設計就是逼你先誠實評估難度，再讓系統決定要配哪個模型、開多少推理強度。

四檔怎麼分：不是「多強」，是「難在哪」

四檔對應的不是一條「模型強度階梯」，而是四種「難度的形狀」：

low — 你完全知道要什麼。 Bug 修正、補測試、規格明確的 refactor。模型幾乎不用探索，照著做就好。依 changelog，背後跑的是 Z.ai 的開源權重模型 GLM-5.2，配 GPT-5.5 當 oracle。
medium — 你大概知道要什麼，這該是你的預設。 髒亂的多步驟任務、需求還很模糊、需要邊做邊修正方向。背後是 GPT-5.5 中等推理強度。Amp 明說這是 recommended default。
high — 你知道改哪裡，但改對很難。 跨檔案的 cross-cutting 改動、微妙的 bug，精準度是關鍵。背後是 GPT-5.5 開到 xhigh 推理，配 Fable 5 當 oracle。代價：Amp 說它產出的 diff「更接近 reviewer-ready」，但要「about twice the wait」——大約兩倍等待時間。
ultra — 結果清楚，但路徑充滿未知。 大型遷移、架構改動、多檔案牽一髮動全身、路徑上全是未知數。背後用 Claude Fable 5 負責寫，配 GPT-5.5 當 oracle。

一個關鍵設計：每一檔背後幾乎都配了一個 oracle（第二意見模型）。依 Owner's Manual，oracle 是「一個更適合複雜推理／分析、但比較慢、比較貴、比較不適合日常改 code 的第二意見模型」，目前用 GPT-5.5、推理 high。轉盤越往上轉，主力寫 code 的模型和 oracle 的搭配就越重——low 用便宜的開源模型打底、貴模型當顧問；high 與 ultra 則把最強模型直接放到主力寫作的位置。

怎麼轉、舊模式怎麼辦

操作很簡單：在 CLI 裡按 Ctrl+S 轉動轉盤；web app 有 mode picker 可選。值得注意的是，推理強度（reasoning effort）不再是另一個要單獨調的旋鈕，而是被折進檔位裡——你選難度，強度跟著走。這正是這次改版最實用的地方：少一個要糾結的維度。

如果你原本依賴舊模式，Amp 把它們做成 plugin 保留下來：

amp plugins add --auto-update @amp/smart-classic
amp plugins add --auto-update @amp/deep-classic

大致的對應方向是 smart / deep 收斂到 medium、rush 收斂到 low、舊的 deep 系往 high 或 ultra 走。這個對應是從 changelog 讀到的方向，實際請以你安裝後 agent 裡顯示的為準。

數據與限制：誠實版

我要老實標註幾件事，免得你把定性描述當成硬數據。

第一，「high 大約兩倍等待」「medium 是預設」這些是 Amp 官方在文章裡的定性描述，不是我實測的 benchmark，changelog 也沒給出 token 數、通過率或延遲的硬數字。想知道實際差多少，得自己在專案上開來比。

第二，背後的模型配置（GLM-5.2 / GPT-5.5 / Fable 5、哪一檔配哪個 oracle）是 changelog 當下寫的。這種 routing 幾乎一定會隨版本調整，你讀到時很可能已經換了——以你自己 agent 裡實際顯示的為準，別把這篇的對照表當成永久事實。

第三，這是 Amp 一家的產品決策，不是業界標準。它證明的是「用難度、而不是用模型來抽象」這個介面方向可行，不代表每家 agent 都會、都該這樣配。

什麼時候該往上轉、什麼時候別

轉盤真正的價值，是給你一套選擇的紀律。實戰上可以這樣判斷：

預設停在 medium。 大多數「我大概知道要幹嘛、但要摸索一下」的任務，medium 的能力和速度足以讓你邊做邊 steer。往上轉之前，先問自己一次：真的更難嗎？
往下轉到 low 的時機： 任務已經被你切到很小、規格白紙黑字寫死（「把這個函式的 for loop 換成 map，行為不變」）。這時候你要的是快和便宜，不是深思。
往上轉到 high 的時機： 你知道要改哪個檔案，但邏輯很微妙、一步錯全錯（併發、邊界條件、跨模組契約）。願意用兩倍時間，換一份接近可直接 review 的 diff。
只在真的未知時才開 ultra： 「把整個 auth 從 session 換成 JWT」這種牽一髮動全身、你自己都還沒想清楚路徑的任務。開 ultra 是拿時間和成本換探索能力，別拿它改 typo。

反過來的 trade-off 也要記得：轉太高不只是慢和貴，它還會給你過度工程的 diff——你只想改一行，它幫你重構了三個檔案。難度低卻硬開高檔，產出常常比開低檔更難 review。

一個實例：同一段 code，四種難度四種下法

抽象講完，看一個具體的。假設你面對一支「結帳金額算錯」的函式。注意：同一個檔案，難度可以天差地遠，檔位也跟著不同——

如果你已經定位到是「稅率四捨五入用錯 API」，這是 low。prompt 直接寫死：「把 calcTax 裡的 Math.round 換成 banker's rounding，只改這一行，補一個對應的單元測試。」你不需要它思考，只需要它照做，快而準。
如果你只知道「某些訂單金額對不上、但不確定哪裡錯」，這是 medium 或 high。要它先讀相關檔案、列出可疑點、給假設再動手；一旦金額牽扯併發或跨幣別，就往 high 轉，因為一步錯就是真金白銀。
如果問題其實是「整套金額計算散在五個檔案、該收斂成一個 service」，這已經是 ultra：結果清楚（統一計價），但路徑未知（要動哪些呼叫端、會不會踩到別的邏輯，你自己都還沒盤清）。

看到重點了嗎——同一份 code，難度不在 code 本身，而在「你對它了解多少」。這正是為什麼 The Dial 問的是你、不是問模型。你越把任務想清楚、切乾淨，就越能往下轉、換到更快更省的檔位；反過來，越模糊未知的任務，才值得往上轉。

對工程團隊的意義：把「難度轉盤」搬進你自己的 agent

就算你不用 Amp，這個抽象也是可以直接借用的招式，因為幾乎每個主流 coding agent 都有等價的旋鈕：

1. 先分類任務，再選檔，而不是先選模型。 養成習慣：每次下 prompt 前先問「這任務難在探索，還是難在執行，還是根本不難？」——這正是 low / medium / high / ultra 的分界。難在執行就拉高推理；難在探索就用最強模型並放它多跑幾步；不難就用最快最省的。

2. 把 reasoning effort 綁在難度上，不要每次手調。 Claude Code 用的 Claude 模型有 low / medium / high / xhigh / max 的 effort 分級（Opus 4.8 就是這樣），Codex、Cursor 也各有 thinking 檔位。你可以在心裡建一張跟 The Dial 一樣的對照表，固定「這類任務→這個 effort」，省掉每次糾結。

3. 自己搭一個 oracle。 oracle 的概念不專屬 Amp：在 Claude Code 裡，你可以在寫完之後開一個 sub-agent、或換一個模型，專門做「第二意見複審」。例如剛改完一段併發邏輯，開一個 sub-agent 下這種 prompt：「你是資深 reviewer，只找這份 diff 的正確性問題（race condition、邊界條件、回歸），不要改 code，列出你最不放心的三點。」尤其是 high / ultra 等級的改動，讓寫的模型和審的模型分開，能抓到不少單一模型自己看不到的問題。

4. 給團隊一條共同的分類語言。 「這個 PR 是 low 還是 high？」比「你用哪個模型？」更能對齊。當團隊用難度、而非用工具在溝通，新人也更快知道什麼任務該多花算力、什麼該快速帶過。

The Dial 表面上只是把四個下拉選項換了名字，但它其實在推一個更好的心智模型：你不需要懂每個模型多強，你只需要誠實面對「這件事有多難」。 把選擇的維度從「工具」換成「任務」——這一步，你在任何 coding agent 上，今天就能開始做。

來源

Amp Changelog，〈The Dial〉，2026-07-09：https://ampcode.com/news/the-dial（Sourcegraph 的 Amp 團隊）
Amp Owner's Manual（agent modes / oracle 章節）：https://ampcode.com/manual