LLMs Have Different Taste on Coding

在嘗試過 Cursor、WindSurf Pro、Gemini Cli、Claude Code 和其他工具後，我發現一件有趣的事情，那就是每個 LLM 在回答/建議程式碼問題時都有其獨特的「品味」。

以下是基於使用各家廠商旗艦模型的發現。

Claude Sonnet 4 – 領跑者

到目前為止，這是最受歡迎的程式碼模型。與其他模型相比，它通常會按照您的要求執行，並且或多或少會按照預期完成工作。

最適合：建立新專案和鷹架。

• 根據您的需求立即建立功能結構。
• 擅長定義路由、樣板和高階功能。
• 它通常會幫助生成一個可運作的專案或範例，並以最新的解決方案滿足您的需求。

弱點：

• 在除錯時，它經常忽略關鍵問題。例如，它曾經錯誤地識別了一個 CSS 類別選擇器，沒有檢查實際的 DOM 元素，而是根據經驗進行猜測。
• 在要求它改進時，它陷入了螺旋式上升：添加了複雜的匹配邏輯、巢狀點擊處理程序，甚至嘗試點擊每個巢狀元素——真的過度設計了。
• 如果一直要求它改進一些小事情或修改一些不符合預期的事情，它往往會使簡單的事情變得複雜。
• 它會在提供回應時產生大量的表情符號或圖示，並且產生的程式碼也會包含表情符號（如果在程式碼中添加除錯訊息），您可以要求它產生較少的表情符號，它會聽從。但過一段時間後，它又會這樣做。

一旦陷入循環，我就換掉了。擅長啟動事物——但不擅長除錯。

 Gemini 2.5 Pro – 過度重構者

這個來自 Google 的模型似乎反應非常快，可以提供細節上的建議，但似乎缺乏更大的視野。它更像是捕捉和修復模型。

最適合：修復錯誤。

如果專案的某些特定區域存在一些錯誤，它會在定位問題和提供修復方面表現良好。它曾經準確地解決了一個點擊處理問題，並提供了一個清晰的解決方案，並且在修復後立即可以運作。

但是：

• 對於下一個功能，它編寫了冗長的解釋並重寫了前面的程式碼，實際上是回滾了之前的工作。
• 它喜歡在流程中重構，有時會撤銷早期的進展。
• 奇怪的是，在我責罵它之後，它道歉並修復了問題——但精神上的負擔讓人感到疲憊。

它很精確，但使用起來在情感上很耗費精力。

GPT-4.1 – 外科手術式修復者

它也是一個或多或少可以幫助完成工作的模型，但需要更多的指導和審查。它往往非常小心，但乍看之下並不是那麼自信。

最適合：漸進式改進和精確度。

• 簡潔明瞭地回應。
• 完美地處理小的變更——一點一點地改進一個函數。
• 大約 70% 的情況下第一次嘗試就成功了；對於剩下的情況，它會冷靜而安靜地迭代。

我堅持使用它的原因：

• 沒有冗長、複雜的解釋來混淆代理視窗。
• 我發現 Gemini 2.5 用程式碼術語解釋它的偉大之處沒有幫助：
  1. 我不理解高科技的吹噓。
  2. 如果我理解，我就自己寫了。

我不需要模型來滔滔不絕——我只需要事情乾淨利落地運作。

比較品味

最終想法：選擇你的風味

歸根結底，LLM 具有不同的程式碼品味。這不是關於找到最聰明的模型——那被高估了。這是關於找到一種風格與您的工作流程相匹配的模型。那種個人的「品味」會產生很大的影響。有時，可以組合一些模型並在同一專案的不同階段使用。