過去三週，是我在 AI 輔助軟體開發領域中，收穫最豐碩的一段時間。
Claude Fable 重新回到舞台，與此同時，OpenAI 也發布了搭載 Sol、Terra 和 Luna 的 GPT‑5.6。市場訊號很明確：前沿實驗室不再只是推出孤立的技術突破，而是正在壓縮能力、價格層級與部署節奏之間的差距。Anthropic 現在將 Fable 5 作為其頂級長程模型銷售，價格大約是 Opus 5 表定價格的兩倍；而 OpenAI 則將 GPT‑5.6 定位為一個從旗艦級能力到更具成本效益工作都能涵蓋的模型家族。與此同時，xAI 對 Grok 4.5 的定價極具侵略性，在任何成本效益的討論中都必須被認真對待。
然而，這幾週我所學到最重要的事，與發布頁面或基準測試的數據幾乎沒有關係。
我環境中真正的突破，在於準備工作。
我們準備好了故事。我們將工作拆分成了可被智能編碼系統實際執行的單元。一旦這個任務佇列建立起來，工作效率就變得驚人。在 Codex、Claude、Cursor、Grok 以及工作流程中的其他工具之間，大約在十天內寫下了超過 200 萬行程式碼。這個數字聽起來像誇大宣傳，直到你看到是什麼讓它成真：不是魔法，不是抽象的自主性，而是一連串有邊界的工作，並具備足夠的結構讓模型得以持續運作。
這就是太多人仍然錯過的第一件事。輸出量的爆炸式增長，並不是因為模型突然變成了能自我引導的工程師。而是因為人類準備好了戰場。
我學到的第二件事是，大規模運作時，錯誤出現的速度比行銷宣傳中承認的要快得多。
Codex 就是一個很好的例子。OpenAI 自己關於長時間運作工作的資料表明，持久的執行緒（thread）伴隨著一個權衡：連續性很有用，但長時間運作的執行緒也可能變得比重新開始更昂貴且更難管理。「目標（Goals）」功能正是為了讓執行緒始終附著於一個有邊界的目標，而不是將每個困難任務都變成一個不斷增長的提示詞。在實務上，這與我所見相符。如果一個流程執行時間過長，更好的做法通常是停止它，要求一個乾淨的交接，重新啟動對話，然後用一個新的目標繼續。這不僅是為了方便，更是操作上的衛生習慣。
還有一個更具體的 Codex 問題，現在已經有了可見的公開記錄：子代理（subagent）與本地狀態（local-state）的爆炸性增長。
Open issue #34061 記錄了一個案例，其中一個恢復的父執行緒產生了數千個子 JSONL 日誌和數百 GB 的持久化對話歷史。另一個問題明確警告，fork_context=true 可能會導致大型父歷史被快照到子代理中，從而放大正確性風險和 Token 消耗。還有另一份公開報告顯示，一旦 ~/.codex 累積了大型 SQLite 日誌和對話狀態，Codex 的冷啟動就會退化為 1 到 5 分鐘的等待。總而言之，這些報告描述了一種許多重度用戶會立即認出的失敗模式：一旦本地元數據層變得足夠大，對話持久化就會成為產品體驗中一個嚴重的部分。
這之所以重要，是因為多代理（Multi-Agent）編碼在展示中看起來總是比在壓力下的開發機器上好得多。
前景是明確的。OpenAI 的多代理文件描述了為什麼並行子代理可以加速獨立的工作流程，這個前景是真實的。但同樣的文件也警告說，子代理會增加 Token 用量，並且可能不適合涉及頻繁寫入共享可變狀態的任務。ChatGPT Learn 上的並行代理指南更為明確：從讀取密集型工作開始，例如探索、測試、分類和總結；對寫入密集型流程要更加謹慎，因為衝突和協調開銷會迅速增加。這個警告並非理論上的。任何看過一群代理同時衝向完整測試套件的人，都確切知道這意味著什麼。
在我的設定中，這現在已成為整個類別中最具定義性的操作問題之一。
問題不在於模型是否足夠聰明來進行平行化。它們顯然可以。問題在於它們仍然需要更好的編排界線，因為「足夠聰明來委派」並不等於「足夠聰明來在爭用情況下維護機器健康、本地優先級和成本紀律。」
同樣的錯配也出現在定價上。
Cursor 清楚地說明了這個問題。它目前的定價是透明的：有兩個每月使用量池，一個用於 Cursor 自己的模型，一個用於第三方的「其他模型」。這也顯示出「自動（Auto）」並非單一概念。Auto Cost 使用固定的 Token 定價，但 Balance 和 Intelligence 則按路由模型的費率計費，而路由器可能會在 Composer、GPT‑5.6、Claude 或 Grok 等模型中進行選擇。對於偶爾進行互動工作的人來說，這種靈活性很有吸引力。但對於爆發式、工業級的工作負載來說，它可能變成一個陷阱。一個月的高級預算可能在幾個非常高效的生產日內就消耗殆盡。
我在一個審查密集型場景中，親身測試了這種失敗模式。
一個專案增加了大約 50 萬行新程式碼。我們的審查系統在這些新增程式碼中標記了約 1500 個問題，包括重複項和誤報。Cursor CLI 被指派去處理這些問題。原始 Token 數量巨大。輸出很有用。但對我來說，成本效益不對。當密集的審查和修正工作可以在一個星期內消耗掉一個月的配額時，這個工具可能仍然很好，但訂閱就變得沒有意義了。
這種緊張關係現在無所不在。
Claude 仍然是我最喜歡使用的系統。但它也是最讓我意識到成本的系統。Codex，特別是在更廣泛的 GPT‑5.6 生態系統中，通常能承載遠比批評者所承認的更高的吞吐量。Grok 4.5 不是開玩笑的；它公開的定價和定位使其成為一個合法的競爭者。Anthropic 自己的定價使得 Fable 與 Opus 之間的權衡變得如此明顯，幾乎是為你寫好了評論：前沿能力就在那裡，但帳單也同時存在。
然後還有最困難的問題，一個沒有任何發布活動能真正解決的問題。
在我使用的幾乎每個前沿編碼模型中，仍然存在著一個令人沮喪的鴻溝，介於「能力不足」與「過度設計」之間。
選擇往往是在一個思考不夠深入的模型和一個對當前任務思考過頭的模型之間。Anthropic 為 Fable 5 提供的指南實際上承認了這一點。它說，較高的努力程度可能會導致過度規劃，例行性工作可能受益於較低的努力程度，而簡潔的指令通常勝過臃腫的框架。OpenAI 在其 GPT‑5.6 指南中也說了類似的話：從較早的模型遷移時，從相同的推理層級開始，然後測試低一層級，因為較新的模型通常能用更少的 Token 保持或改善品質。這是一種技術性的說法，表達了我們許多人在實證中發現的相同情況：努力程度的旋鈕仍然太容易調過頭。
也許部分問題仍在我們身上。
也許指令檔案太長了。也許某些框架現在反而在與模型對抗，而不是幫助它們。這個理論至少與 Anthropic 自己的上下文工程指南一致，該指南說上下文應該資訊豐富但又精簡。確實存在一種可能性，即我們歸咎於模型的一些過度複雜化，實際上是被過度生長的提示詞基礎設施放大了。
但即使在考慮到這點之後，更廣泛的結論仍然不變。
模型犯的明顯錯誤比以往少了。但它們仍然會犯的錯誤，往往更加危險，因為它們更難被發現。它們隱藏在那些看起來很精緻、深思熟慮且專業的程式碼中。實作從遠處看越完美，我就越學會保持懷疑。
這就是為什麼我對當前這波 AI 編碼勝利論仍然持懷疑態度。
我理解這種炒作從何而來。如果你沒有每天都在這些系統中工作，單單是吞吐量本身就足以讓人覺得像奇蹟。而且其中一部分確實是奇蹟。但日常的親身實踐也暴露了另一面：帳單的不確定性、編排的失敗、長時間對話的脆弱性、要麼過度簡化要麼過度設計的傾向，以及持續需要人類進行包裝、審查和判斷。
我們距離理想的 LLM 編碼世界還非常遙遠。
炒作並非完全錯誤。但它仍然遠不如操作現實來得誠實。
