# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：Matt Pocock (@mattpocockuk) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 日期：2026-07-16

> 原始來源：https://x.com/mattpocockuk/status/2077373581932081654

## 證據與延伸閱讀

- [推薦參考 DeepSWE 基準圖表](https://deepswe.datacurve.ai/)

## 中文摘要

Matt Pocock 呼籲開發者標註努力程度以區分 SOTA 模型行為。

**努力程度設定的迷思**
Matt Pocock 指出，許多使用者習慣將模型設定為最高努力程度，這種行為無異於「跑分狂熱（Benchmarkmaxxing）」。他認為這是一種極度缺乏效率的做法，原因如下：
- **資源浪費**：努力程度本質上是透過消耗更多 token 來解決問題。在跑分測試中，增加 20% 的 token 換取 2% 的效能提升對行銷有利，但在日常開發任務（如探索程式庫或修改測試）中，這只會導致無意義的 token 燃燒。
- **效能衰退**：特別是在 Fable 類模型中，token 成本極高。隨著燃燒的 token 增加，注意力機制（Attention）的衰退會隨之而來，反而導致輸出品質下降。
- **隱形成本**：過度依賴高努力設定會掩蓋真實的成本、延遲與資源浪費，使用者往往在不知不覺中消耗數十萬 token。

**建議的作業模式**
Matt Pocock 強調，使用者不應盲目追求最高設定，而應採取由低至高的策略：
- 建議在嘗試新模型時，先從最低的努力程度開始，若發現品質不足，再逐步調升。
- 他個人在日常開發中偏好使用「Opus 4.8 medium」設定。
- 針對「努力程度與成本」的權衡，他推薦參考 [DeepSWE](https://deepswe.datacurve.ai/) 的基準測試圖表，該圖表清晰呈現了思考層級與成本之間的關係。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/ab08a96464ee2fef.jpg)
> 本圖比較了多款模型（如 claude-fable-5、gpt-5.6-sol、claude-sonnet-5 等）在不同 effort 設定下的 DeepSWE 分數與每項任務平均成本（Avg cost per task）的權衡關係。

**開發社群的觀點分歧**
針對 Matt Pocock 的主張，社群中存在不同的反思與辯論：
- **預設值的便利性**：Tommy Long 認為，開發者通常希望擁有一個「通用的預設值」，而不願針對每個問題頻繁調整設定。此外，若任務失敗，開發者往往會歸咎於努力程度，而非檢查是否為 Prompt 撰寫不佳、skill 設定錯誤或過度使用 context window。
- **錯誤傳遞的風險**：Habanero 則持保留態度，指出在 Agentic 程式開發中，低努力程度的呼叫若產生錯誤，可能不會立即顯現，而是透過「討好（Sycophancy）」等方式掩蓋問題，導致錯誤在後續開發中不斷累積，最終付出的「技術債」成本遠高於節省下來的 token。
- **多維度的優化**：Matt Pocock 對此回應，努力程度只是眾多可調整參數之一，開發者不應過度聚焦於單一指標，還應考慮如何自訂 `harness` 或調整環境設定。

總結而言，Matt Pocock 認為開發者往往高估了任務的複雜度，應避免過度依賴高昂的思考預算，並建議將努力程度視為一個需要根據實際需求動態調整的參數，而非一成不變的預設值。

## 標籤

Skills, LLM, Benchmark, 產業趨勢, Matt Pocock