200K Tokens 夠用！ @AmpCode 博客，針對Claude Opus 4.5 模型“僅有” 200k Token 上下文窗口的“短板”提出了反直覺但深刻的見解，團隊認為：對於高質量的編碼和任務執行，200k Token 不僅夠用，而且往往優於超長上下文。 “醉酒”理論：上下文並非越多越好作者提出了一個生動的比喻：“如果餵給Agent 太多的Token，它們會像'喝醉'了一樣。” · 訊號雜訊比問題：過長的對話歷史會填充大量與當前微小任務無關的訊息，導致模型注意力分散，容易出錯甚至產生幻覺。 · 效能下降：為了讓Agent 表現最佳，關鍵在於「只提供完成目前任務所需的上下文，且不多一分」。 「短線程」工作流程哲學作者反對將所有工作堆在一個百萬級Token 的超長對話中，而是主張使用互相關聯的短線程集群： · 任務拆解：一個複雜的開發功能應該被拆解為多個離散的小任務。 · 執行緒即任務：每一個執行緒對應一個小任務。例如，一個執行緒負責基礎實現，另一個執行緒負責重構，再開一個執行緒負責程式碼審查或編寫測試腳本。 · 上下文傳遞：透過提及或工具在線程間傳遞必要的上下文，而不是一直累積歷史。 成本與效率的雙重考慮· 經濟性：長對話不僅意味著每次請求都要發送海量Token，而且容易錯過緩存窗口，進一步推高費用。 · 可控性：短線程更容易管理和追踪，每一次交互都有明確的目標，這種工作方式實際上回歸了“大任務拆解為小任務”這一經典的工程學原則。 總結文章其實是在倡導一種從「大鍋飯」到「精細化管理」的AI 互動範式轉變。作者認為，與其追求用一個無限長的上下文視窗來容納混亂，不如透過良好的工程習慣，將複雜問題拆解為多個精簡、高效的200k 上下文單元來解決。 換句話說：200k 的限制反而是一種強制使用者進行良好任務拆解的“特性”，而非缺陷。 部落格地址
