Context 越大不代表能做更複雜的事 — 而是能把每一件簡單的事做得更好

當 Anthropic 宣布 Opus 4.6 支援 1M token context window 時，開發者社群沸騰了。「終於可以把整個 codebase 餵進去了！」「大規模重構不再是問題！」「這改變了一切！」

但在日常使用大 context 模型數月後，我得出了一個反直覺的結論：

更大的 context 不是讓你做更難的事。而是讓你把簡單的事做得更好。

這個區別比你想像的重要得多。

迷思

有一個普遍的信念，認為 context window 大小直接對應任務複雜度：

8K context → 簡單腳本
32K context → 中等功能
200K context → 大型模組
1M context → 整個系統重寫

這個心智模型是錯的。

擁有 1M token context 的模型並不能比 32K token 的模型「想得更深」。推理引擎是一樣的。智慧是一樣的。改變的是模型在工作時能記住多少東西。

這樣想：給木匠一張更大的工作台，不會讓他們突然能製作以前做不出來的東西。只是工具不會在工作時掉到地上。

Context 到底在做什麼

Context 不是算力。Context 是記憶。

當你用 AI 助手寫程式時，context window 裝著：

對話歷史 — 你們討論過什麼、決定了什麼、否決了什麼
分享的程式碼 — 檔案、函式、型別、介面
你陳述的限制 — 「用這個 library」、「遵循這個 pattern」、「不要破壞那個 API」
中間狀態 — 做到一半的實作、部分完成的重構

Context 小的時候，模型在要實作的時候已經忘記你的限制了。Context 大的時候，它記得住。

這不是能力的差異。這是一致性的差異。

「複雜」任務的解剖

很多人忽略了一件事：根本沒有複雜的任務。只有一長串簡單任務，而每一步都必須與前面的每一步保持一致。

想想「重構認證系統」。聽起來很複雜。但拆開看：

讀取現有的認證實作 (簡單)
理解 token 刷新流程 (簡單)
找出所有呼叫點 (簡單)
設計新的介面 (簡單)
更新認證模組 (簡單)
更新每個呼叫點使用新介面 (簡單)
更新測試 (簡單)
驗證沒有東西壞掉 (簡單)

每個單獨的步驟都很直接。「複雜度」來自於第 6 步必須完全符合第 4 步的設計決策，而第 4 步必須遵守第 2 步發現的限制，而第 2 步又取決於第 1 步讀到的內容。

複雜度不在於單一步驟的難度。而在於跨多個簡單步驟維持連貫性。

而這正是 context 提供的東西。

一個具體的例子

假設你要求 AI 在資料庫 model 新增一個欄位，並讓它貫穿整個技術堆疊。

小 context（對話不斷被截斷）：

在 model 新增欄位 ✓
更新 API endpoint ✓
忘記這個欄位是 nullable 的（20 條訊息前決定的）✗
在 TypeScript type 用 string 而不是 string | null ✗
寫的 migration 和 model 定義不一致 ✗
測試沒有覆蓋 null 的情況 ✗

大 context（一切都在記憶中）：

在 model 新增欄位 ✓
更新 API endpoint ✓
記得欄位是 nullable 的 ✓
到處一致使用 string | null ✓
Migration 和 model 完全一致 ✓
測試覆蓋了有值和 null 兩種情況 ✓

每個步驟都是簡單的。大 context 的模型並沒有做任何「更難」的事。它只是把每一件簡單的事做對了，因為它記得自己已經做了什麼決定。

為什麼這對你的工作流程很重要

這個洞見有實際的工作流程啟示：

1. 不要用大 context 來嘗試更大的任務

誘惑是把你整個 50,000 行的 codebase 丟進 context，然後說「全部重構」。這會失敗 — 不是因為 context 不夠大，而是因為所需的推理超出了任何當前模型在單次對話中能做到的。

相反，用大 context 來讓更多相關資訊保持可見，同時做專注的工作。

2. Context 是為了一致性，不是為了複雜度

正確的心智模型：大 context 就像一個擁有完美短期記憶的開發者。他們不會突然變成更好的架構師。但他們永遠不會忘記變數名稱、永遠不會搞丟型別約束、永遠不會意外地與五分鐘前做的決定矛盾。

3. 先拆解，然後為每個部分提供 context

致勝策略：

你把複雜任務拆解成步驟（這需要人類判斷力）
模型帶著所有相關決策的完整 context 執行每個步驟
你驗證整體的連貫性

這就是為什麼 Claude Code 的 sub-agent 架構這麼有效。每個 agent 處理一個專注的任務，但攜帶足夠的 context 來保持一致。

4. Context 的品質 > Context 的數量

餵 1M token 不相關的程式碼進去沒有幫助。餵 50K token 精準相關的程式碼、決策和約束進去，幫助巨大。

我見過最厲害的 AI 使用者不是那些把所有東西都丟進去的人。而是那些策展模型看到什麼的人 — 給它恰好需要的 context，讓每一件簡單的事都做得完美。

更深層的原則

這裡有一個更深層的原則，適用於 AI 之外的領域：

精通不是做困難的事。而是以非凡的一致性做簡單的事。

偉大的廚師不會烹飪不可能複雜的菜餚。他們把基本功 — 火候控制、調味、時機 — 在每一盤菜上都執行得完美一致。

偉大的軟體工程師不會寫出深不可測的聰明程式碼。他們在數千個小決策中做出正確、一致的選擇 — 命名、錯誤處理、邊界案例、測試覆蓋。

偉大的作家不會使用華麗的詞藻。他們每次都選對那個詞，連續數千個詞。

更大 context 的 AI 也是如此。它不會解鎖更高層次的智慧。它解鎖的是更高層次的可靠性 — 一次又一次做出正確的小決定，而不會忘記為什麼。

這對未來意味著什麼

隨著 context window 持續增長 — 1M、2M，最終無限 — 不要期待 AI 突然解決它今天解決不了的問題。期待它以更少的錯誤、更少的不一致、更少的人工修正來解決同樣的問題。

這聽起來可能不夠令人興奮。但其實不是。

「偶爾有不一致的好程式碼」和「整個系統一致正確的程式碼」之間的差距，就是原型和生產系統的差距。週末專案和服務百萬用戶的產品的差距。能跑的程式碼和你可以信任的程式碼的差距。

更大的 context 縮小這個差距。不是靠讓 AI 更聰明，而是靠讓它更可靠。

而可靠性，最終，才是工程的本質。

重點摘要

Context window ≠ 智慧上限。 更大的 context 不會讓模型想得更深。
Context window = 一致性半徑。 更大的 context 意味著模型能在更多決策間保持一致。
「複雜」任務其實是一連串簡單任務，步驟間的連貫性才是難點。
用大 context 追求精準，不是追求野心。 餵入相關 context，讓專注的工作做到完美。
策展你的 context。 資訊的品質比數量重要。
真正的突破是可靠性。 每次都把簡單的事做對，才是從「夠好」到「卓越」的分水嶺。