Grok 4.7 評測：定價、效能測試、API 存取，以及有哪些變更

快速回答

Grok 4.7 是 xAI 於 2026 年 9 月 21 日推出的升級版本，專為程式設計及高難度的知識型工作任務而設計。 xAI 表示，該版本在處理困難問題時會投入更多時間、更仔細地檢查其工作成果，並新增了一套安全防護機制，同時維持與 Grok 4.6 相同的價格與運算速度。其發布頁面還宣稱，該版本的運算速度是同類模型的兩倍，價格卻僅為其一半；但這類廠商比較需配合其底層任務與運作路徑一併解讀。 根據 Independent Artificial Analysis 的數據，該模型相較於 Grok 4.6 整體表現略有提升，並支援 50 萬字元的上下文視窗。 在我們的三項任務 API 測試中，Grok 4.7 在除錯和源碼邊界規範方面表現最為出色；其專案計畫雖能妥善保留不確定性，但可操作性未達要求。這雖是實用的實證，卻不能證明它能勝過所有競爭模型。.

什麼是 Grok 4.7？

Grok 4.7 是 xAI 旗下 Grok 系列的最新機型，於 2026 年 9 月 21 日正式發表。該 xAI 官方公告 將其定位為該公司最擅長程式設計與知識工作的模型。這項實質性的改變並非在於新增了面向消費者的功能清單，而是在於模型預期應如何分配精力：花更多時間處理困難任務、進行更多自我檢查，並建立一層安全機制，旨在讓這項額外的能力更易於掌控。.

這種定位之所以重要，是因為它描述的是一種工作流程模型，而非聊天機器人的個性。Grok 4.7 被定位為適用於能從持續分析中獲益的任務的模型，例如：除錯、規劃、技術撰寫、研究綜述，以及需要模型同時考量多項限制條件的長提示。.

這項界限同樣至關重要。xAI 的公告僅是供應商針對預期行為所發表的聲明，並非獨立證明 Grok 4.7 能勝過所有競爭模型、所有提示詞或所有程式碼儲存庫。 請將發布頁面視為 xAI 主張的來源，然後透過獨立的測試結果以及您自己的任務來判斷這些主張是否具有實質意義。.

Grok 4.7 與 Grok 4.6：實際上有哪些變化？

最站得住腳的總結是：這是一次在努力程度與可靠性上的升級，而非一款截然不同的產品。.

對買家而言，這是一項有用的區別。如果 Grok 4.6 已經符合您的工作流程，那麼 4.7 就是一項值得評估的無障礙升級。如果 4.6 因生態系統、延遲、可靠性或存取限制等原因而無法符合需求，單憑更高的基準數值並不能解決這些問題。.

若要建立更廣泛的模型購買框架，則 GPT-5.6 定價指南 和 GPT-5.6 比較 這些是有用的提醒，有助於將模型品質與計畫的經濟效益及工作流程的契合度區分開來。.

功能：Grok 4.7 應能發揮作用之處

編碼與除錯

xAI 最有力的推出定位在於程式設計。其承諾不僅在於 Grok 4.7 能編寫更多程式碼；更在於它能更長時間地專注於解決棘手的工程問題、檢視自身的解答，並回傳經過更周全考量後的修正程式碼或解釋。 這正是我們在真實儲存庫中應關注的行為：它是否能保留現有設計、找出根本原因、新增有用的測試，並明確指出其目前仍無法掌握的部分？

請勿使用「從零開始開發一個待辦事項應用程式」這類全新情境的提示來評估模型。應提供一個包含失敗測試、少量檔案以及明確限制條件的有限範圍錯誤。在要求提供修補程式之前，先請模型進行診斷。這樣一來，便更容易判斷：較長的推理過程究竟是能減少審查工作量，還是僅僅讓說明文字變得更冗長罷了。.

對於比較不同編碼方案的團隊而言，同樣的規則也適用。A DeepSeek V4 Pro 評測 和 GLM 編碼計畫審查 雖然這些資訊能提供有用的比較參考，但兩者都不應被視為替代實際測試您所使用的儲存庫和工具鏈的手段。.

需要長期背景知識的工作

《Artificial Analysis》指出，Grok 4.7 版本的上下文視窗大小為 50 萬個標記。這足以改變您處理大量原始資料的方式：無論是冗長的技術規格書、一組會議記錄、程式碼庫的片段，還是研究資料包，都能在同一個對話中完整呈現，而無需反覆進行摘要。.

語境容量不等同於語境品質。 模型即使能處理大量輸入資料，仍可能忽略中間部分的限制條件、過度重視最後一段內容，或是產出看似自信但需核對來源的摘要。實際的測試在於「高壓下的檢索能力」：將幾個關鍵事實分散置於長篇文件的不同部分，要求模型做出受限的決策，並檢查其答案是否正確引用了相關段落。.

SpaceXAI 的官方 X 帳號於 9 月 22 日再次強調了此次推出的定位，稱 Grok 4.7 在價格與速度相同的情況下，相較於 Grok 4.6 有了顯著提升，並分享了型號比較圖表。 該貼文是該公司公開定位的有力證據，但並非獨立驗證或社群共識。.

若將此模型用於研究，請確保「證據循環」始終清晰可見。我們的 Gemini 與 Perplexity 的比較 和 Perplexity 替代方案指南 都提出了同樣的實務觀點：一個措辭精煉的回答並不等同於來源審核。.

自我檢查與安全

xAI 表示，Grok 4.7 版本會更仔細地檢查其工作成果，並引入了一套新的安全防護機制。這些都是極具價值的目標，特別是在要求模型進行一連串決策時。然而，這並不能保證輸出結果是正確的，或適合自動執行。.

在實際生產環境中，應在模型周圍設置常規控制措施：測試、權限管理、人工審查、引用檢查，以及明確的停止條件。模型的自我檢查僅是另一項需檢視的訊號，而非取代其周圍的控制措施。.

Grok 4.7 效能測試：數據所揭示的真相

請將這些卡片視為方向性參考。資料集的組成、工具的可用性、抽樣方式以及模型設定都可能影響排名。.

目前最有用的獨立快照來自 《Artificial Analysis》雜誌關於 Grok 4.7 的基準測試文章, ，日期為 2026 年 9 月 21 日。.

這個趨勢令人鼓舞：獨立指標顯示相較於前一版本有所改善，而 AA-Briefcase 中更大的 Elo 分差，則暗示在該項評估中取得了更顯著的進步。但該表格仍僅描述了兩個資料集，並非普適性的排名。基準測試的組成、工具存取權限、取樣方式及模型設定都可能影響結果。.

xAI 的官方發布頁面顯示 Grok 4.7 位於 在 CursorBench 4.0 上的 46.3% 在其比較表中，與 Grok 4.6（40.4%）、GPT-5.6 Sol（41.7%）以及 Fable 5.1（51.8%）並列。 該頁面還顯示：在 DeepSWE v1.1 的高難度模式下達 71.0%，在 EEBench 上達 64.0%，以及在 AA-Briefcase v1.1 上達 1,657。 這些是供應商提供的比較數據，因此應將其視為官方報告結果，而非獨立驗證的替代品。較穩妥的結論是，xAI 瞄準的是嚴謹的程式設計與專業知識工作；而獨立測量則顯示，在某些任務上有所顯著提升，但在其他任務上的表現則較為平淡。.

Grok 4.7 實作測驗：三項實作任務

我們針對該模型執行了三組固定提示詞， grok-4.7 於 2026 年 9 月 23 日透過相容於 OpenAI 的測試 API 進行模型識別。此為單一路徑評估，並非直接透過 xAI API 進行，亦非針對特定競爭對手的對比測試。每次執行結果中可見的答案如下所示；私有推理軌跡已排除在外。.

這些延遲數值僅描述此路徑及這些提示。編碼任務首先遇到非串流閘道超時，隨後在啟用串流後完成。這是一項關於傳輸與超時處理的實際部署警示，而非 Grok 4.7 速度評分的通用指標。.

測試 1：TypeScript 並行程式設計除錯

任務 1 — TypeScript API 處理程式的並行性除錯

當兩個請求在短時間內接連送達時，一個小型 TypeScript 處理程式會間歇性地傳回 HTTP 200 狀態碼，且內容為空。

提供的檔案：

src/cache.ts
```ts
let current: Promise | null = null;

export async function getPayload(load: () => Promise): Promise {
  if (!current) {
    current = load();
  }
  const value = await current;
  current = null;
  return value;
}
```

src/handler.ts
```ts
import { getPayload } from './cache';

export async function handler(load: () => Promise) {
  const payload = await getPayload(load);
  return { status: 200, body: payload };
}
```

此問題在生產環境中僅於兩個請求重疊時才會間歇性發生。載入器本身可安全地並行呼叫，且會針對每個請求返回不同的有效載荷。目前沒有其他相關檔案可供參考。

請精確回報以下內容：
1. 根本原因
2. 最小的安全修補程式（顯示統一的 diff）
3. 兩項回歸測試（TypeScript 或 Jest 風格的程式碼）
4. 假設與限制
請勿聲稱已執行過該程式碼。.

1. 根本原因

`current` 是每個呼叫皆共享的模組層級狀態。在單一 JavaScript 執行週期中，空值檢查與賦值操作是原子性的，因此兩個重疊的呼叫不會同時執行 `load()`。第一個呼叫會儲存其 Promise；若第二個呼叫在該 Promise 解決之前抵達，則會跳過自身的 `load()`，並等待同一個 Promise。 隨後 `handler` 會傳回 HTTP 200 狀態碼，其 `body` 內容為首次呼叫的字串，而非第二次請求的載荷。此狀況僅在呼叫進行期間存在，因此僅當請求重疊時才會出現此錯誤。

`current = null` 會在 `await` 已擷取該承諾後的每個延續中執行。這並不會讓其他等待者重新讀取該變數，因此僅憑這些檔案並不會將該等待者解析為 `null` 或 `""`。它們在重疊時所產生的結果，是共享的解析結果以及跳過每次請求的載入。 此設計也使得該槽位成為一個不理想的單次執行快取：第一個恢復執行的延續會釋放 `current`，而後續的呼叫者可能在另一個呼叫者仍在捲回時，就啟動了不同的 `load()`。

2. 最小安全修補程式（顯示統一差異）

每個請求都必須自行呼叫 `load()`。允許並行呼叫 `load()`，且每個呼叫都會返回不同的載入內容，因此基於單一共用 Promise 進行去重是不安全的。`handler.ts` 無需修改。

```diff
--- a/src/cache.ts
+++ b/src/cache.ts
@@ -1,10 +1,3 @@
-let current: Promise | null = null;
-
 export async function getPayload(load: () => Promise): Promise {
-  if (!current) {
-    current = load();
-  }
-  const value = await current;
-  current = null;
-  return value;
+  return await load();
 }
```

3. 兩項回歸測試（TypeScript 或 Jest 風格的程式碼）

```ts
import { handler } from '../src/handler';

function deferred() {
  let resolve!: (value: T) => void;
  let reject!: (reason: unknown) => void;
  const promise = new Promise((res, rej) => {
    resolve = res;
    reject = rej;
  });
  return { promise, resolve, reject };
}

test('重疊的請求各自執行 load 並保留各自的主體內容', async () => {
  const first = deferred();
  const second = deferred();
  const started: string[] = [];

  const p1 = handler(() => {
    started.push('a');
    return first.promise;
  });
  const p2 = handler(() => {
    started.push('b');
    return second.promise;
  });

  expect(started).toEqual(['a', 'b']);

  second.resolve('payload-b');
  first.resolve('payload-a');

  await expect(p1).resolves.toEqual({ status: 200, body: 'payload-a' });
  await expect(p2).resolves.toEqual({ status: 200, body: 'payload-b' });
});

test('被拒絕的重疊負載不會改變另一則回應', async () => {
  const failed = deferred();
  const ok = deferred();
  let started = 0;

  const p1 = handler(() => {
    started += 1;
    return failed.promise;
  });
  const p2 = handler(() => {
    started += 1;
    return ok.promise;
  });

  expect(started).toBe(2);

  failed.reject(new Error('上游失敗'));
  ok.resolve('payload-b');

  await expect(p1).rejects.toThrow('上游失敗');
  await expect(p2).resolves.toEqual({ status: 200, body: 'payload-b' });
});
```

4. 假設與限制

我並未實際執行這段程式碼或相關測試。 這些測試假設使用 Jest 風格的執行器，且測試檔案位於 `src/` 的同級目錄下（例如 `test/cache.test.ts`）。

我將「每個請求的載入內容不同」視為一項要求，即重疊的 `getPayload` 呼叫不得共用同一個 `load()` 結果。 正確的單次執行重寫（`load().finally(() => { current = null; }); return current`）仍會將這些請求耦合在一起，因此我並未採用此方式。程式中未定義快取金鑰，亦未明定去重要求。

若 `load` 傳回非空字串，所示的語句並不會寫入字面意義上的空 HTTP 正文。若此現象源自這些檔案之外的轉接器，則在此處無法察覺。此修補程式僅移除這些檔案實際實現的重疊耦合，並未新增鎖定機制、重試機制或基於金鑰的快取。.

Grok 4.7 正確地發現了模組層級的 目前 promise 會導致重疊的請求共用同一個載入器結果，儘管每個請求都需要各自的資料包。該提案提出了一項最小的安全變更：移除共用 promise 並呼叫 load() 應要求。這兩項回歸測試涵蓋了不同的並發有效載荷，以及當其中一個載入器拒絕時的情境。該回答最精彩之處在於其謹慎態度：它明確指出，所示程式碼雖證明了跨請求耦合，但若載入器總是返回非空字串，則僅憑此程式碼本身並無法解釋為何會出現字面意義上的空正文。.

判決： 在根本原因準確度、修補程式範圍、回歸測試覆蓋率及不確定性處理方面均通過嚴格測試。.

測驗 2：來源相互矛盾的研究備忘錄

任務 2 — 將相互矛盾的研究筆記整合成一份決策備忘錄。

僅使用以下六則筆記，並在每項事實陳述旁註明來源名稱：

- 供應商 A，定價頁面，2026-09-20： 團隊方案為每席位每月 $40，並包含 100,000 次操作。
- 供應商 B，比較貼文，2026-09-21：供應商 A 的團隊方案包含每席位每月 120,000 次操作。
- 客戶訪談，2026-09-18：我們的團隊有 8 個席位，上個月使用了 710,000 次操作。
- 財務試算表，2026-09-19：目前的預算上限為每月 $360。
- 供應商 A，限額頁面，2026 年 9 月 20 日：超出包含配額的部分，將按每項操作 $0.004 計費。
- 採購備註，2026-09-22：僅當每月總額維持在預算範圍內且配額已獲核實時，方可接受供應商更換。

請精確回報以下部分：
1. 經核實的事實
2. 歸因的主張
3. 衝突對照表
4. 獨立計算（分別計算 8 × 100,000 與 8 × 120,000 兩種情境，並加上任何超額部分）
5. 建議
6. 僅當利益衝突導致建議變更時，方可提出一個澄清問題
請勿對 100,000 與 120,000 之間的衝突默不作聲地處理。.

1. 經核實的事實
- 「團隊方案」的月費為每席位 $40（供應商 A，定價頁面，2026-09-20）。
- 該團隊共有 8 個席位，上個月共使用了 710,000 次操作（客戶訪談，2026-09-18）。
- 目前的預算上限為每月 $360（財務試算表，2026-09-19）。
- 超出包含的配額後，超額部分將按每項操作 $0.004 計費（供應商 A，限額頁面，2026-09-20）。
- 僅當每月總量維持在預算範圍內且已核實包含配額時，方可進行更換（採購備註，2026-09-22）。

2. 歸因索賠
- 該方案包含 100,000 次包含操作（供應商 A，定價頁面，2026-09-20）。該說明並未明確標註「每席位」。
- 供應商 A 的方案包含每月每席位 120,000 次操作（供應商 B，比較貼文，2026-09-21）。

3. 衝突對照表
| 項目 | 主張 | 來源 | 狀態 |
| --- | --- | --- | --- |
| 包含的操作次數 | 100,000 次包含操作；未註明「每席位」 | 供應商 A，定價頁面，2026-09-20 | 未解決 |
| 包含的操作次數 | 每月每席位 120,000 次操作 | 供應商 B，比較貼文，2026-09-21 | 未解決 |

100,000 與 120,000 之間的矛盾尚未解決。這些註記並未顯示哪個數字正確。

4. 獨立計算
基礎席位成本，兩種情境均相同：8 個席位（客戶訪談，2026-09-18）× 每席位每月 $40 （供應商 A，定價頁面，2026-09-20）= 每月 $320。

以下兩個乘數均按要求計算得出。這並不意味著供應商 A 曾明確提出每席位的津貼金額。

- 8 × 100,000 = 800,000 次包含操作，採用 100,000 這個數字（供應商 A，定價頁面，2026-09-20）。
- 使用量 710,000（客戶訪談，2026-09-18）比 800,000 少 90,000，因此超額操作次數 = 0。
- 超額費用 = 0 × $0.004 = $0（供應商 A，限額頁面，2026-09-20）。
- 月總量 = $320 + $0 = $320，此數值在 $360 的上限範圍內（財務試算表，2026-09-19）。

- 採用 120,000 這個數字計算，8 × 120,000 = 960,000 項包含在內的操作（供應商 B，比較貼文，2026-09-21）。
- 使用量 710,000（客戶訪談，2026-09-18）比 960,000 少 250,000，因此超額操作次數 = 0。
- 超額費用 = 0 × $0.004 = $0（供應商 A，限額頁面，2026-09-20）。
- 月總計 = $320 + $0 = $320，此數值在 $360 的上限範圍內（財務試算表，2026-09-19）。

5. 建議
目前暫不批准此項變更。根據兩種計算方式的限額，上個月的 710,000 次操作 （客戶訪談，2026年9月18日）並未產生超額，且月總量為 $320，此數值仍在 $360 的上限範圍內（財務試算表，2026年9月19日）。 該成本結果不取決於選擇 100,000 或 120,000。此轉換仍不符合第二項條件：配額必須經過驗證（採購備註，2026-09-22），且這些備註中 100,000 （供應商 A，報價頁面，2026-09-20）與 120,000（供應商 B，比較貼文，2026-09-21）之間仍存在衝突。

6. 僅當衝突影響建議時才提出一個澄清問題
無需提出澄清問題。100,000 與 120,000 之間的數值衝突並未影響建議。.

該研究資料包在「每座位配額為 100,000 次還是 120,000 次」這一點上，刻意呈現相互矛盾的說法。 Grok 4.7 將這兩份資料來源區分開來，注意到第一份來源並未明確提及「每座」，因此分別計算了兩種八座的情境，並顯示兩者均維持在 $320，且在所提供的使用量下並無超額情況。 該報告仍建議暫緩批准，因為採購部門要求須先核實此配額。這正是數值上穩定之建議與尚未釐清之合約事實之間的正確區別。.

判決： 在歸因、算術、衝突處理及決策紀律方面表現優異。.

測試 3：將雜亂的筆記轉為執行計畫

任務 3 — 將這些雜亂無章的專案筆記整理成一份不超過 700 字、為期一週的執行計畫。

備註：
- 著陸頁將於週五 17:00 上線；產品負責人在後續筆記中表示為週四上午。
- Mina：撰寫標題與定價表。Mina 另表示她只能在週三下午審閱文案。
- Arjun：分析事件；其中一則重複的筆記指出分析負責人尚未確定。
- 設計部門有兩項重複的任務：「行動版首圖裁切」與「行動版首圖裁切最終版」。
- 任何公開上線前都必須完成法律審查。
- 分析事件資料可用後，品質保證（QA）需要一整天的測試時間。
- 奧馬爾將於週二下午外出。
- 上線通知電子郵件預定於週五 16:00 發送。
- 未知：誰負責最終的上線與否決策。

要求：彙整重複的工作項目，將負責人未明者標記為「待定」，保留兩項硬性截止日期，對矛盾之處應標示而非默默解決，並以五項風險清單作為結尾。

請精確保留以下段落：
1. 一週計畫
2. 矛盾與未明事項
3. 五項風險
請勿自行編造負責人或日期。.

1. 一週計畫

備註中未列出任何日曆日期，因此未新增任何日期。僅採用已明確列出的基準點與依賴關係。重複的設計工作視為一項任務。未知的負責人仍標示為「待定」。衝突的上線時間均予以保留。

- 文案：Mina 負責撰寫標題和定價表。她的文案審閱僅安排在週三下午。
- 設計：一項任務，即行動版首圖裁切，包含「最終」校對。未指定獨立負責人。
- 分析事件：必須在品質保證（QA）前建立。負責人尚未確定（某份筆記中為 Arjun；另一份則標示為待定）。
- 品質保證（QA）：需一天完整時間，且須待分析事件設定完畢後方可進行。負責人待定。此處未指定 QA 執行日期。
- 法律審查：任何公開上線前皆須完成。負責人待定。備忘錄中未排定時程。
- 是否上線（Go/no-go）：負責人待定。尚未視為已決定事項。
- 公開上線的關鍵節點均維持不變：週四上午（產品負責人）及週五 17:00（登陸頁面）。
- 上線電子郵件：週五 16:00。負責人待定。
- Omar 週二下午不在。由於這些筆記中沒有任何任務指派給 Omar，因此沒有任務被移交給他。

執行順序（不包含新日期）：Mina 的草稿必須於週三下午審查前準備就緒；設計團隊須完成單一主角圖片的裁切；分析事件由尚未確定負責人交付；品質保證團隊隨後有一整天的時間；法律審查須在任何公開上線前完成；是否上線（待定）仍無負責人。 請勿取消週四上午、週五 17:00 或週五 16:00 的安排。

2. 矛盾點與未定事項

矛盾點（尚未解決）：
- 登陸頁上線時間為週五 17:00，但產品負責人稍後的備註卻顯示為週四上午。
- 分析負責人在一則備註中是 Arjun，但在另一則重複的備註中卻標示為「待定」。

未知事項（標示為「待定」）：
- 最終「是否上線」決策負責人。
- 已確定的分析負責人。
- 法律審查負責人。
- 品質保證負責人。
- 上線電子郵件負責人。
- 除「設計」以外的指定設計負責人。
- 奧馬爾（Omar）的職責；僅提及他將於週二下午缺席。
- 哪個上線時間具有最終效力，以及週五 16:00 的電子郵件是否與上述任一時間吻合。除這些工作日時間外，未提供其他日期。

3. 五項風險

1. 週四上午與週五 17:00 無法同時作為著陸頁上線時間；若在未做決策的情況下採用其中任一時間，可能會導致過早上線或錯過另一個截止期限。
2. 上線電子郵件已固定於週五 16:00 發送，時間在週五 17:00 之前，且備註中未與週四上午的時間點對齊，因此可能在著陸頁尚未達到或已不再處於預期狀態時便發送該郵件。
3. 分析數據的負責人尚有爭議，因此相關事件可能延誤； 品質保證（QA）在活動結束後仍需一整天時間，可能無法在兩個上線時間點之前完成。
4. 任何公開上線前都必須經過法律審查，但目前既無負責人亦無安排時段，因此上線可能受阻，或未經審查便直接進行。
5. 未指定「是否上線」的決策負責人，因此這兩項硬性截止期限均無明確的人員負責批准或阻止上線。.

Grok 4.7 合併了重複的 mobile-hero 任務，保留了週四上午與週五 17:00 的發布衝突，維持了週五 16:00 的電子郵件截止時間，將未確定的負責人標記為「待定」，並最終列出確切的五項風險。它並未虛構任何日曆日期或負責人。 其弱點在於可操作性：它並未將工作分配至週一至週五的時序中，而是回傳了一份有序的依賴關係清單，並指出無法指定任何品質保證日。這種謹慎態度雖有其道理，但題目要求提供一週的執行計畫，因此該答案僅部分符合要求的格式。.

判決： 部分通過：約束條件的保留效果極佳，但在排程方面的實用性較弱。.

Grok 4.7 版本在實際工作流程中帶來了哪些變革

解讀這項發布最實用的方式，是將其視為一個工作流程問題：持續推理在哪些地方能減少審閱工作，又在哪些地方只會產生更長的答案？ 這三項 API 任務揭示了一種實用的模式。Grok 4.7 能夠輕鬆地同時呈現多項約束條件，特別是在提示要求其區分事實與假設時。然而，當任務需要具體的時程表或執行順序，而來源筆記並未完全說明時，其表現便較不令人信服。.

編碼與除錯

就儲存庫相關工作而言，此模型更適合用於範圍明確的診斷，而非開放式的「建置應用程式」請求。 請提供最小的有用檔案集，描述故障症狀，並在提供修補程式前要求找出根本原因。要求提供在變更前會失敗、變更後會通過的測試。在我們的處理器測試中，解答內容緊貼提供的程式碼，並避免為「主體為空」的症狀捏造外部原因。.

這種行為之所以重要，是因為程式碼品質不僅僅是程式碼的產出。有用的程式碼響應應能保留局部設計、限制 diff 的範圍、釐清假設，並降低驗證成本。Grok 4.7 在一項小型任務中做到了這些，但單一任務無法建立儲存庫層級的可靠性。 團隊應在處理實際錯誤、重構、多檔案變更以及涉及安全敏感的路徑時，均採用相同的評估標準，方能將工作推入生產環境。.

研究與文獻綜述

這項研究任務凸顯了另一項優勢：來源邊界管控。Grok 4.7 並未默默地將供應商聲稱的 100,000 次操作與比較貼文中的 120,000 這個數字合併在一起。 它同時區分了在兩種情境下均保持穩定的計算結果，與仍需驗證的採購條件。.

這正是適用於研究密集型工作的正確模式。請要求模型分別標註經核實的事實、已指明來源的主張、未解決的衝突、計算結果以及建議。 即使一份措辭精煉的備忘錄，若將次要論點包裝成未註明出處的事實，仍可能有誤。Grok 4.7 的回答之所以有價值，在於它即使算術結果未變，仍讓矛盾點保持清晰可見。.

規劃與營運

在規劃階段，這些限制變得更加明顯。該模型雖然保留了所有截止日期和未知負責人，卻未能進一步制定週一至週五的排程。這雖然比隨意編造日期更為穩妥，但意味著使用者仍須將依賴關係轉換為行事曆上的任務分配。.

針對營運提示，請包含規劃時程、可用工作日、業主可配合時間，以及決策者。若這些欄位缺失，請先索取依賴關係圖，其次再索取行事曆。此兩階段工作流程能讓模型的警示發揮實用價值，而非將其視為無法果斷決策的失誤。.

長上下文檢索

500K 的語境視窗會改變單次請求所能涵蓋的範圍，但不會改變哪些內容可在未經檢查的情況下被信任。處理長語境的工作應採用檢索探針：將決定性的事實置於封包的開頭、中間和結尾；刻意加入一處衝突；然後要求做出包含來源位置的決策。同時衡量召回率與邊界紀律。.

切勿僅憑長上下文路徑是否能接受大型請求來評判其表現。應記錄模型在哪些地方遺漏了事實、是否過度重視最後一段內容、延遲隨輸入大小增加的幅度，以及服務提供者是否會截斷或轉換請求。宣傳中標示的大型視窗僅是容量聲明，並非保證在極限情況下能維持穩定的推理能力。.

如何自行評估 Grok 4.7

在變更生產環境的預設值之前，請先使用一個規模較小且可重複執行的測試資料集。目標並非重新建立排行榜，而是將模型與您已付費採用的部署流程及審核流程進行比較。.

1. 凍結輸入值。. 請保留確切的提示、檔案、原始封包、模型 ID、溫度、推理設定及工具權限。在變更提示的同時，請勿將直接路徑與服務供應商路徑進行比較。.
2. 評分應針對作品本身，而非文筆。. 在程式設計方面，應針對根本原因準確度、修補程式範圍、測試及假設進行評分。在研究方面，應針對引用範圍、算術正確性、衝突及建議品質進行評分。在規劃方面，應針對截止日期遵守情況、責任歸屬、依賴關係及可執行性進行評分。.
3. 請分別記錄運輸情況。. 請在路由日誌中記錄「取得第一個標記所需時間」、「總時間」、「串流／非串流模式」、「HTTP 狀態碼」以及「重試行為」。閘道超時並不一定代表模型層級的失敗，但仍會造成生產成本。.
4. 檢查失敗時的行為。. 請包含一個含糊不清的輸入、一個相互矛盾的來源，以及一個刻意不完整的檔案集。關鍵在於，模型是標記不確定性，還是會以一個充滿信心的推測來填補空白。.
5. 請一併檢視成本與工作量。. 追蹤輸入標記、輸出標記、快取的輸入資料、在公開時所產生的推理標記，以及人工審查所花費的分鐘數。雖然驗證時間加倍的回應看似成本較低，但在實際操作中未必更划算。.
6. 切換前請重複此步驟。. 在變更團隊預設值之前，請先針對每個任務執行至少兩次，或使用數個具代表性的範例進行測試。請保留原始的可見答案及評分註解，以便其他審閱者能夠重現該決策。.

本評測中的三組運行結果僅為初步樣本，不能取代團隊的評估資料集。這些結果展示了 Grok 4.7 在一項編碼任務、一份來源衝突備忘錄以及一套規劃資料包中的表現；但並未確立其普遍排名。.

Grok 4.7 的定價與 API 存取權限

在定價方面，模型評測往往會產生誤導。讀者可能會看到至少三種不同的價格：xAI 的直接 API 價格、聚合平台的路由價格，以及消費者訂閱價格。這些價格並不能互換使用。.

根據 xAI 的公告，Grok 4.7 的定價與 Grok 4.6 相同，運算速度也與後者一致。產品介紹頁面指出，標準版定價自 每 100 萬個輸入代幣為 $2 和 每 100 萬個發行代幣為 $6; 《人工分析》一書中獨立列出了相同的直線路徑數據，並 每 100 萬個快取輸入標記為 $0.50. xAI 還表示，高速版本的輸出速度是標準版的兩倍，但價格也是標準版的兩倍。使用 官方開發者文件 在傳送正式環境流量之前，請先確認當前 API 合約及該帳戶的可用性。.

OpenRouter 的 Grok 第 4.7 頁 顯示 每 100 萬個輸入代幣為 $1.60 和 每 100 萬個產出代幣為 $4.80 針對其路由。這屬於 OpenRouter／服務供應商的定價，並非對 xAI 直接定價的修正。路由、加價幅度、快取、限制及可用性可能因服務供應商而異。.

若不說明具體路線，對於「Grok 4.7 的價格是多少？」這個問題，無法給出一個確切的答案。對於 API 買家而言，請比較：

• 輸入與輸出的標記速率；;
• 快取輸入處理；;
• 上下文與輸出限制；;
• 速率限制與區域可用性；;
• 該服務提供者是否提供推理控制功能；;
• 記錄、保存及資料處理相關條款。.

就使用者存取而言，請勿假設 API 價格即代表 X 或 Grok 訂閱的價格。使用者方案、API 路徑及第三方聚合平台可能各有不同的存取規則。.

您應該選擇哪個 API 路徑？

實作環節所使用的相容路徑返回 grok-4.7 並支援串流功能。其非串流編碼請求在串流重試完成之前，已超過閘道器的等待時窗。這項觀察結果在設計客戶端時頗具參考價值，但不應直接套用至 DirectX AI 的延遲主張中。.

如何存取 Grok 4.7

最簡潔的做法是從 xAI 公告 和 xAI 開發者頁面, 接著請確認您需要的是 Grok Build、Cursor、直接 API 還是聚合器。 xAI 表示，Grok 4.7 可透過 Cursor 和 Grok Build 取得，亦可透過 Grok API，以及第三方程式設計工具、模型路由器和雲端平台取得。此區別將決定計費方式、模型控制權、隱私條款以及可用工具。.

若您使用聚合服務，請在建構時，先開啟其模型頁面，並確認服務提供者的路由、代幣價格、上下文限制及模型識別碼。OpenRouter 是一個已記錄的路由，但其定價不應複製到 xAI 的計費表中。.

對於希望在同一個工作區中比較幾個模型系列的讀者來說，, GlobalGPT 的多模型工作區 對於並行提示評估可能有所助益。本文確實 不是 聲稱該處已有 Grok 4.7 路線可供使用。經核實的目錄路線是否可用是另一個問題，應在購買前於產品使用者介面中進行確認。.

Grok 4.7 對比 ChatGPT、Claude 及 Gemini

這份評測包含三項 Grok 4.7 任務的結果，但並未與 ChatGPT、Claude 或 Gemini 進行對比測試。若就此得出「Grok 4.7 勝出」的普世結論，仍屬行銷話術，而非分析。 更佳的判斷取決於該模型相關的研究成果：

的 “《哪些人工智慧值得付費？》指南 提出正確的採購問題：哪項重複性任務的效益提升程度足以抵銷訂閱費或 API 費用？這比一味追逐排行榜上的最新項目，更是一項持久的決策準則。.

限制與未解問題

Grok 4.7 問世時間尚短，目前尚無廣泛的獨立共識。現有證據留下了幾個未解之謎：

1. 在編碼、研究、寫作及多模態任務方面，進步的程度有多一致？
2. 在接近極限時，500K 的情境仍能保持可靠性，還是檢索效能會更早開始下降？
3. 最高程度的推理努力會造成多少額外的延遲？
4. 哪些消費者方案、地區、工具及速率限制會使該模型暴露在外？
5. 這些新的保障措施在處理合法但敏感的技術工作時，會產生什麼樣的影響？
6. Direct xAI、OpenRouter 及其他服務供應商所回傳的輸出結果或限制是否存在實質上的差異？

這些問題並非否定該模型的理由。正因如此，在遷移工作流程或承諾節省成本之前，才更應先進行一項規模較小但具代表性的評估。.

哪些人適合使用 Grok 4.7？

若您符合以下情況，建議優先測試 Grok 4.7：

• 長時間進行程式除錯或分析技術資料；;
• 處理長度超過一般聊天視窗的原始封包；;
• 重視那種願意在困難的提示詞上投入更多心力的模型；;
• 可以先審閱產出結果，而不是直接將其送入生產環境；;
• 正在比較直接 API 與聚合平台的經濟效益。.

若您需要成熟的整合方案、文件詳盡的用戶方案，或是相較於您現有技術堆疊中的模型在執行相同任務時具備經實證的優勢，那麼此方案的適用性便較低。在這些情況下，存取與工作流程層的重要性可能比兩點的索引提升更為關鍵。.

常見問題

什麼是 Grok 4.7？

Grok 4.7 是 xAI 於 2026 年 9 月 21 日推出的，專為程式設計與知識工作而設計的模型版本。xAI 表示，該版本在處理困難任務時能持續運作更久、對工作成果進行更仔細的檢查，並新增了一套安全防護機制，同時維持與 Grok 4.6 相同的價格與執行速度。.

Grok 4.7 是何時發行的？

xAI 於 2026 年 9 月 21 日宣布推出 Grok 4.7 版本。官方發布頁面與開發者文件是了解發布狀態、模型可用性及 API 變更的最佳資訊來源。.

Grok 4.7 是否比 Grok 4.6 更好？

Artificial Analysis 報告指出，其智慧指數為 46，比 Grok 4.6 高出 2 點；而 AA-Briefcase Elo 分數為 1,657，比 4.6 高出 111 點。這些是實用的指標，但並非適用於所有工作流程的通用結果。.

Grok 4.7 的上下文視窗是什麼？

《Artificial Analysis》針對 Grok 4.7 列出了 50 萬個令牌的上下文視窗。較大的視窗並不能保證能完美檢索，因此在將該模型應用於涉及大量來源資料的工作之前，請先將事實置於長篇文件中的不同位置來測試模型。.

Grok 4.7 API 的價格是多少？

Artificial Analysis 列出直接 API 路徑的效能為：每 100 萬個輸入代幣需 $2，每 100 萬個輸出代幣需 $6；若使用快取輸入，則每 100 萬個代幣需 $0.50。在正式投入生產使用前，請務必確認最新的 xAI 文件。.

OpenRouter 的 Grok 4.7 價格是否與 xAI 的相同？

不。OpenRouter 列出的路由價格為：每 100 萬個輸入代幣為 $1.60，每 100 萬個輸出代幣為 $4.80。 這是供應商專屬的價格，應與 xAI 的直接 API 定價分開比較。OpenRouter 還會顯示供應商專屬的快取、延遲、吞吐量及隱私相關欄位，這些因素可能會影響路線的實際成本。.

我該如何存取 Grok 4.7？

請先參閱 xAI 的官方公告與開發者文件，接著選擇消費者版 Grok 產品、xAI 直接 API，或是像 OpenRouter 這樣的聚合服務。請確認您實際計畫使用的路徑所對應的模型 ID、區域、速率限制、上下文以及計費方式。.

Grok 4.7 是否可在 GlobalGPT 上使用？

本評測並未聲稱已在 GlobalGPT 上驗證 Grok 4.7 路線。GlobalGPT 可用於比較現有的機型系列，但在購買前，應於產品使用者介面中確認其最新型號清單及確切的機型供應狀況。.

Grok 4.7 是否適合用作編碼劑？

這項測試對於「有限範圍除錯」、「程式碼審查」以及「多檔案推理」等情境頗具價值，在這些情境中，代理程式必須闡明假設並生成測試用例。實作編碼任務雖具挑戰性，但並未測試工具執行、儲存庫編輯、權限設定，或是完整的代理程式迴圈。.

為什麼編程測驗需要直播？

第一個非串流請求超出了測試路由的閘道等待時限。而在啟用串流功能後，相同的提示已成功完成。這說明了為何生產環境的客戶端應支援串流功能及明確定義的超時設定；但這並不能證明每個 Grok 4.7 路由都具有相同的延遲行為。.

我該如何測試 500K 的上下文視窗？

使用一個固定的資料包，在開頭、中間和結尾分別放置關鍵事實，並加入一個刻意設置的衝突點。應要求提供來源位置，並針對多種輸入規模，評估記憶回憶能力、衝突處理能力及延遲表現，而非僅依賴宣傳的最高數值。.

Grok 4.7 是否值得從 Grok 4.6 升級？

初步證據顯示，此次升級雖具實質意義，但屬漸進式：獨立測量結果有所改善，且實際操作測試在除錯與源碼合成方面表現出色。請僅在您的實際任務中，於可接受的佈線特定成本下，確實呈現審查工作量降低或準確性提升的情況時，才進行升級。.

最終裁決

Grok 4.7 似乎是一次嚴肅且漸進的模型升級，且目標明確：針對能讓持續投入獲得回報的編碼與知識型工作。 官方發布聲明對此次變更提供了令人信服的解釋；Artificial Analysis 的初步數據顯示，相較於 Grok 4.6 版本，新版表現有所提升而非退步；而我們透過 API 執行測試所獲得的結果，則提供了較為微弱但實用的佐證。該模型在處理並發性錯誤與來源衝突備忘錄方面表現尤為出色；其規劃結果雖謹慎周全，但操作性尚未達到要求水準。.

坦率地說，這個結論目前仍屬初步。這僅是針對同一條測試路線進行的三次單次運行，其中最慢的任務是在非串流閘道超時後才開始串流，且目前既無相應的競爭對手運行數據，也缺乏廣泛的獨立共識。 不妨從您實際工作流程中挑選一項困難的任務開始，將其輸出結果與審閱時間與您現有的模型進行比較，然後再決定這項升級是否值得為該特定路線所付出的成本。.