把一個網頁上的「加入購物車」按鈕從綠色改成藍色，在人類工程師眼裡不過是修改一行 CSS 的舉動，但在當前的大型語言模型邏輯裡，這往往演變成一場拆掉整棟房子只為換一顆螺絲釘的工程災難。用戶在 Hacker News 上嘲諷 Claude 的行為藝術並非空穴來風，當你要求它微調一個元件時，它極大機率會慷慨地附贈一套重新編排過的佈局、幾個莫名其妙消失的異步請求邏輯，以及一段自以為優雅實則冗餘的重構代碼。這種「過度服務」的傾向，正暴露了 Anthropic 在模型對齊過程中的某種補償心理。Claude 似乎生怕漏掉任何上下文細節，於是選擇將整段代碼重新噴塗一遍，卻忘了代碼庫的穩定性往往建立在「非必要不變動」的古老教條之上。
這種現象在 Claude 3.5 Sonnet 處理 React 組件或複雜的 Tailwind CSS 佈局時尤為顯著。技術層面上，這涉及到模型在 Attention 機制中對「局部變更」與「全局一致性」的權重分配失衡。當輸入的 Context Window 達到數十萬 token 時，模型傾向於在生成過程中維持整體的語法連貫，而非精確定位到那行 color: #00ff00 並將其替換。結果就是，它在輸出區塊中重寫了整個 render 函數。對於資深開發者而言，這簡直是災難，因為你必須在 Git diff 中像大海撈針一樣，去確認它除了改了顏色，有沒有順便把你的 API endpoint 也給「優化」掉了。這種行為模式與其說是智能，倒不如說是一種帶著強迫症色彩的臨摹。
在同樣的工程場景下，ChatGPT 展現出的則是另一種極端。OpenAI 的模型在處理這類指令時，通常表現得更像一個疲憊的接案工程師，它會精準地給你那行修改後的代碼片段，甚至只是一個 diff 區塊，但也常因為缺乏全局視野而導致變量命名衝突。Gemini 則更喜歡在代碼旁邊加上一長串關於「為什麼藍色比綠色更能激發購物慾」的心理學分析，然後在代碼結尾處遺漏一個閉合括號。相較於 DeepSeek v4.1 flash 或 DeepSeek v4 pro，Claude 在代碼生成的結構嚴整性上確實維持了極高的水準，但這種水準往往伴隨著沈重的溝通成本。當我們在談論 AI 輔助編程時，我們追求的是外科手術式的精準，而不是推土機式的重建。
這引出了一個更深層次的技術拷問：為什麼擁有強大 Reasoning 能力的模型，在處理極簡指令時反而顯得笨拙？Grok 在這方面嘗試引入更具「侵略性」的邏輯判斷，試圖過濾掉那些無意義的重複輸出，但在面對高度抽象的封裝邏輯時，依然難免陷入幻覺。我們目前所處的階段極其尷尬，模型具備了寫出幾千行代碼的能力，卻還沒學會如何閉嘴並只交出那關鍵的一行。當開發者需要的是一個能幫忙遞扳手的助手，AI 卻總想直接幫你把整座工廠重新設計一遍。
這種代碼重寫的惡癖，究竟是來自預訓練語料中代碼樣本的完整性要求，還是模型在 RLHF 階段被過度訓練成了「完美主義者」？如果一個模型無法理解「最小變動原則」在工程實踐中的神聖地位，那麼它生成的代碼量越多，給系統維護者帶來的熵增就越恐怖。我們是否真的需要一個能通讀萬卷書、卻連換個顏色都要翻新地基的博學者？當下一次你對著對話框輸入修改指令時，你期待的是那行乾淨的藍色代碼，還是又一段長達五百行、充滿未知風險的「完美代碼」？