在 Hacker News 這種充滿工程師自尊心的地方，最近掀起了一場關於「精準度」的口水戰。大家討論的焦點與其說是誰又在跑分上贏了誰，不如說是對 OpenAI 這種越來越像「黑盒」的產品策略感到集體焦慮。當一個開發者在論壇上抱怨 GPT-5.5 Pro 會隨意在結構化輸出中增加字段、甚至任性地更改類型時，這已經不是單純的性能問題，而是對開發者信任度的毀滅性打擊。這類場景在自動化工作流中簡直是災難：你寫好了完美的 JSON Schema，規定了 API 必須返回整數，結果它給你回了一個帶逗號的字串，還附贈了一句充滿禮貌的廢話。
這種「不聽話」的傾向，在處理複雜的技術規格時尤為明顯。OpenAI 似乎越來越傾向於讓模型「顯得更聰明」，而不是「更精確」。當模型試圖理解你的意圖並進行過度優化時，它就開始破壞結構化輸出的嚴謹性。這在處理漏洞掃描基準測試或長鏈邏輯推理時非常致命。一個有趣的現象是，當你在執行高強度的程式碼掃描任務時，GPT-5.5 Pro 可能會因為過度思考某些細枝末節，導致 token 消耗量呈指數級增長，甚至在完成任務前就燒光了你設定的預算上限。這種「貴且難伺候」的特質，正讓一部分硬核技術人員開始尋求更低成本、更穩定遵循指令的替代方案。
從技術底層來看，四大平台在處理結構化任務上的哲學分歧越來越大。ChatGPT 目前顯然在追求通用型對話的流暢感，這導致它在 API 層面的行為變得難以預測。相比之下，Claude 在指令遵循（Instruction Following）的穩定性上一直保持著較高的水準。如果你讓 Claude 3.5 Sonnet 生成一段嚴格符合 TypeScript 定義的代碼，它很少會像 GPT 那樣自作聰明地添加一些它認為「對你有幫助」的冗餘字段。這種對 Schema 的敬畏心，是 Claude 目前在工程界口碑回升的核心原因。
而在另一個極端，Gemini 的問題在於它對上下文過濾的過度敏感，這常常導致它在處理某些敏感技術領域（如漏洞分析）時直接「擺爛」。雖然 Gemini 1.5 Pro 的百萬級長文本窗口在處理大型代碼庫時極具優勢，但如果你不能保證它每一行輸出的格式都是一致的，那這個巨大的窗口也只是個裝滿碎紙屑的垃圾桶。至於 Grok，目前看來它更像是一個在社交數據上狂奔的野馬，在需要極度嚴謹的邏輯閉環任務中，它的表現還不夠讓人放心。
在目前的市場環境下，DeepSeek V4 Pro 的出現確實給開發者提供了一個成本與精度對比的座標軸。相較於 DeepSeek V4 Pro，OpenAI 目前的策略是將更多資源傾斜給了多模態的感知能力，而非單純的文本邏輯穩定性。這就造成了一個尷尬的局面：你花著昂貴的訂閱費，卻發現模型在執行最基礎的腳本任務時，還不如一些輕量級的開源模型或特定市場的模型來得聽話。Qwen 在處理特定語境下的代碼生成時也展現過類似的特質，但這並沒有改變四大平台壟斷高端智力市場的事實，只是讓這層壟斷顯得有些鏽跡斑斑。
我們現在面臨的真正問題是，當 AI 的智力密度達到一個臨界點後，開發者是否還能控制它們的輸出形狀？OpenAI 試圖通過增加更多的推理步驟（Reasoning）來解決問題，但這往往伴隨著更高的延遲和更不可控的成本。如果一個模型需要消耗比以前多二十倍的資源，卻連一個簡單的 JSON 格式都守不住，那這種「進步」的意義在哪裡？我們是否已經進入了一個「過度擬合人類語氣」而忽視「機器對接邏輯」的歧途？
當 Claude Code 這樣的工具開始考慮接入更廉價的 API 接口時，OpenAI 應該感到背脊發涼。如果開發者發現自己花了大筆錢買的不是生產力，而是模型的小脾氣和冗餘的解釋，那麼遷移成本就不再是阻礙。問題在於，如果未來所有的模型都為了追求「擬人化」而犧牲了「結構化」，我們是不是得重新發明一種給機器看的機器語言？或者說，當我們在追求那個虛無縹緲的 AGI 時，是不是已經不小心把最基礎的「工具屬性」給弄丟了？