GPT-6 Astra：令牌效率與軟體工程之間的衝突

GPT-6 Astra 的悖論：高完成度，低品質

GPT-6 Astra 在電腦使用、圖像理解以及對任務完成的不懈追求方面表現出極高的能力。然而，對於專業的軟體工程而言，它展現出一個令人擔憂的趨勢：它更重視 完成 的事實，而非 程式碼品質。這導致模型雖然能成功執行長遠目標的任務，卻產生了「垃圾程式碼」——這些程式碼難以閱讀、難以維護，且根本不符合以人類為中心的軟體工程流程。

「垃圾工廠」實驗

在一個受控實驗中，建立了一個「軟體工廠」，讓 GPT-6 Astra 自行管理其工作流程、上下文與子代理，以在 Python 中實現虛擬執行緒與詞法作用域。結果顯示，輸出品質隨時間顯著退化：

• 資源消耗： 該代理運行了 35 小時，消耗了約 40 億個令牌，API 費用約為 1,200 美元。
• 輸出： 產生了 75,000 行程式碼與 79 次提交，但沒有交付任何實際價值的成果。
• 退化： 專案的組織從結構化的任務命名（例如 1, 2, 3）演變為混亂的識別碼（例如 8b2c2b3），顯示出模型在缺乏人類監督的情況下，逐漸退化至「瘋狂」狀態。

令牌效率 vs. 程式碼可讀性

Astra 最顯著的問題之一，是其對「程式碼縮寫」（code-golfed）Python 腳本的依賴，用於工具呼叫。它經常不使用提供的編輯工具或標準的 bash 命令，而是撰寫高度壓縮、難以閱讀的 Python 腳本來操作檔案與狀態。

「程式碼縮寫」工具呼叫的範例

• 以字串拼接方式編輯 C 程式碼： 不使用補丁工具，模型經常在 Python 中手動進行字串操作來編輯 C 原始碼檔案。
• 壓縮的 Socket 測試： 為在 macOS 上測試 Unix socket，模型會產生極度密集、單行的 Python 腳本，幾乎無法由人類審查。
• 多層執行： 模型被觀察到使用 Bash 執行 Python，而 Python 又啟動 Node.js，再由 Node.js 呼叫 PowerShell——形成複雜的執行鏈，模糊了原本的意圖。

泄漏至生產程式碼

這種針對令牌效率的優化並未局限於工具呼叫。它會「滲透」至實際提交到程式碼庫的程式碼中，特別是在單元測試與內嵌腳本中。作者指出，這些壓縮版本比格式化程式碼（例如使用 ruff format）約節省 10% 的令牌，但從人類工程的角度來看，它們是明顯劣質的。

生成程式碼中的技術退化

除了可讀性問題，模型還引入了專業程式碼庫中極為陌生且可能危險的模式：

• 硬編碼常數： 模型開始在 C 實作中插入隨機常數以處理運算，造成難以追蹤的不透明邏輯。
• 非標準 C 風格： 它引入多個同行的巨集呼叫，以及醜陋的詞法分析器邏輯，與 CPython 程式碼庫既定的編碼風格背道而馳。
• 隨機索引： 在生產用的 Python 程式碼中，模型使用隨機整數作為列表索引來儲存狀態（例如 _task_accelerator[6](task)），使程式碼變得脆弱且難以理解。

社群見解的綜合

Hacker News 上工程師的討論揭示了一個更廣泛的共識：目前的前沿模型可能正在改變其強化學習（RL）目標。

"我懷疑 OpenAI 和 Anthropic 在過去幾個月裡，將其 RL 方向從『根據人類反饋被評為有用』轉變為『成功完成長遠目標任務』……導致代理在自主任務完成方面更接近通用人工智慧（AGI），但在溝通上卻異常糟糕。"

社群的其他關鍵見解包括：

• 「內卷」（Neijuan）效應： 相信 AI 工程正進入一個「內卷」階段，即投入更多資源（更多令牌、更多運算力），但並未帶來相應的有用輸出提升。
• 人類架構的必要性： 批評者認為，『一擊制勝』大型專案是一種幻覺。成功需要人類架構師提供經過整理的大型需求與嚴格的規格，而不是單純『希望』專案能自動完成。
• 自主退化的風險： 使用者報告指出，一旦『垃圾程式碼』進入上下文視窗，模型的輸出會以『機器速度』持續退化，因為上下文會不斷吸收其自身的劣質輸出。

結論：為不同使用者設計的工具

越來越多的懷疑聲指出，目前 GPT-6 Astra 這類前沿模型的發展軌跡，似乎並非為軟體工程師設計。儘管這些模型對 3D 藝術家、律師或需要快速、一次性原型的人（例如一擊完成的 3D 遊戲）具有革命性意義，但它們可能正遠離可維護軟體工程的嚴謹要求。這種取捨——以人類可讀性換取自主任務完成——暗示著一個未來：程式碼由代理撰寫，供代理使用，而人類僅為延續遺產而存在。