DMBot onepage/ Claude Code
Claude Code · effort guide · 8 min read
Claude Code 的 effort 不是越高越好：把算力花在驗證上
Thariq Shihipar 的實測把一個常見直覺翻過來：提高 effort 的主要價值，不是讓模型忽然想出不同方向，而是讓它多做判斷、測試與邊界條件檢查。方向仍要靠清楚規格與人類回饋。
Published: 2026-09-25Author: Thariq ShihiparSource: Claude Code / X
01 / effort 的意義
它是一個「投入多少」旋鈕
effort 近似你願意讓模型為任務花多少計算量。等級越高，模型會花更多時間自行做判斷、查核成果與處理例外情況。
02 / 核心發現
更強的是驗證，不是方向
提高 effort 通常能減少漏掉的 bug 與 edge case；但若一開始誤讀需求、選錯方法，單純加大 effort 並不能保證修正方向。
03 / 實務 loop
低 effort 做、high effort 驗
作者在新功能工作採取「先補規格、低 effort 實作與迭代、最後高 effort 測試驗證」的節奏，而非每一步都開最大。
Key signals
文章裡最值得記住的四個訊號
Normal work
low → high
先取得能對話的實作，再投入更高 effort 做驗證與測試。
Specification
方向優先
高度具體的規格下，不同 effort 的成果更相似，因為選擇空間已被縮小。
Edge cases
高 effort 有利
安全、硬體、複雜 bug 等隱藏條件多的任務，最能受益於更深的檢查。
Autonomy
max 有代價
max 適合難題的端到端自主交付，但也意味著更久時間、更多假設與更多 token。
Evidence
實驗到底顯示了什麼？
01
規格不足時，高 effort 會補更多「自己的答案」
在「做一個健身追蹤 app」這類開放題，低 effort 交出基本紀錄與圖表；越高的 effort 則自行補上更多功能和細節。這適合想一次交付較完整雛形的情境，也代表模型替你做了更多產品決定。
02
規格清楚時，差別會收斂
作者先讓模型訪談、整理出詳細規格，再以不同 effort 實作同一個 app。結果在結構與設計上更接近；此時比較關鍵的是規格品質，而不是每次都選最高檔。
03
困難題目會把驗證能力的差距放大
Terminal-Bench 3.0 的案例顯示，高 effort 會重現 bug、讀 parser 原始碼、跑標準測試集與 fuzzing，或用獨立參考實作交叉驗證。這些不是多寫幾行程式，而是多建立幾層反證。
Decision map
四個 effort 檔位，對應四種工作期待
Low：要快速來回與共同判斷適合腦力激盪、草圖、簡單變更與第一版。你仍在 loop 裡，目標是盡快看到方向、提供回饋，而不是一次完成。
Medium：一般日常工程預設適合常規 feature implementation。它在速度、完整度與模型自行承擔的判斷之間取得平衡。
High：先把可驗證性拉上來適合舊系統修 bug、要求嚴格的 code review、效能或有很多例外條件的工作。重點是檢查假設與測試失敗路徑。
Max：交付一個難題的自主 run適合你希望模型端到端完成建置與驗證，或在關鍵軟體中找安全漏洞。使用前要接受更高時間與成本，並設好範圍。
Practical loop
一個可直接採用的工作迴路
先讓模型問問題，補齊規格effort 不能替代需求釐清。把驗收標準、限制、例外與不該碰的範圍說清楚，能減少模型走上錯路。
用 low effort 建出可被 review 的版本快速確認模型是否抓到「gist」。若不是，就在低成本迭代中修正理解與設計，不要把 token 花在錯的方向上。
人類 review 後，再指定驗證問題把「跑測試」具體化：哪些風險不能漏、哪些資料要交叉比對、哪些相容性或失敗情境需要覆蓋。
切到 high effort 做反證與測試讓模型有足夠預算重現、比較、fuzz、量測與檢查半成品修復是否真的抓到原始問題。
Takeaways
給使用 Claude Code 的三個提醒
把 effort 當成流程設計，不是品質按鈕想要高品質，先確認需求與方法；再把高 effort 放在最需要驗證的階段，而不是用它掩蓋模糊指令。
明確區分「探索」和「交付」探索期需要速度與人類回饋；交付期需要測試與反證。兩者有不同最適 effort，切換比固定高檔更有效率。
對高風險任務，讓驗證成為成果的一部分當問題有隱藏 edge case，最後的答案之外還要看重現步驟、測試證據、失敗案例與可回退性；這正是高 effort 比較值得花的地方。
References