開發者最佳AI工具：出手寫程式碼前先比較模型

聊天模型和寫程式代理是不同的工具

值得先分清楚，因為這兩者常被混為一談。代理式寫程式工具住在你的編輯器或終端機裡，讀取你的儲存庫，直接寫檔案。聊天工作區則是你思考的地方：貼上錯誤堆疊、討論做法、審查差異、看懂沒用過的程式庫，或起草設計文件。

大多數開發者最後兩種都會用，而在聊天這一邊，選對模型最重要，因為你看的是推理過程而不是差異本身。這也是為什麼訂三套服務只為了比較三個模型不再合理。

你在做什麼	模型傾向	備註
困難的推理：並行處理、細微的競態、架構取捨	Claude和GPT差異明顯	兩個都問。這正是第二個意見值回票價的情況
常見情境下的實作速度	GPT	快、道地，擅長樣板程式碼和轉換
讀懂龐大陌生的程式庫或長篇規格	Gemini	內容視窗最大，能一次容納系統的更多部分
解釋錯誤或概念	哪個說法講得通就用哪個	不同模型的解釋方式不同，這正是重點
嚴格的結構化輸出：設定檔、JSON、schema	GPT	最能確實遵守格式

比貼錯誤堆疊更好用的除錯提示語

貼上錯誤然後問哪裡出錯，得到的只是一個猜測。這個猜測常常是對的，錯的時候你會浪費二十分鐘去追一個看似合理、但你根本沒有的問題。這些提示語能改變答案的樣貌。

提示語：先列假設再給修正

這是錯誤、程式碼，和我已經排除的可能。先別給我修正方法。列出四個最可能的原因，按機率排序，每個都給出最便宜的驗證方式，能確認或排除它。錯誤：[貼上]。程式碼：[貼上]。已排除：[清單]。

提示語：只有時偶爾發生的問題

這個問題間歇性發生，大約[頻率]，在[條件]下。這是相關的程式碼，以及我對環境的了解。列出可能造成這個特定症狀的間歇性錯誤類型（時序、順序、資源耗盡、外部依賴、執行間的狀態外洩、時區或時鐘、快取）。針對每一個，說明我給的資料裡有什麼證據支持或反駁它，以及我該記錄什麼來區分它們。

提示語：在我採用之前先解釋這個修正

解釋這個修正為什麼有效、它沒修到什麼，還有它可能會弄壞什麼。如果真正的原因在別處，這只是治標的貼布，請直接說出來。

最後這個提示語能抓到AI協助裡代價最高的一種情況：讓症狀消失,但真正的缺陷還留在程式庫裡的修正。

兩個模型看同一個問題,這不是花招

答案很明顯的時候,一個模型就夠了。這個技巧在你不確定的問題上才真正值回票價,因為模型出錯的方式不一樣,不是一致的。

有用的做法不是兩個都問然後挑喜歡的那個答案,而是先問一個,再把它的答案交給另一個:

提示語：對答案做對抗式審查

另一位工程師針對這個問題提出了這個解決方案。找出它有什麼問題：邊界情況下的正確性、並行處理、錯誤處理、在[規模]下的效能,或是被忽略的更簡單做法。如果它真的站得住腳,就直說,不要硬找問題。問題：[貼上]。提議的解決方案：[貼上]。

兩種結果都有用。要嘛第二個模型找到真正的漏洞,你在合併之前就知道了；要嘛它同意這個做法,考慮到它有充分動機唱反調卻沒有,這就是真正的證據。相較之下,拿同一個模型反覆問,它往往會同意自己。

同樣的做法也適用於設計決策：

提示語：替另一邊辯護

在[脈絡和限制]下,我選擇[做法A]而不是[做法B]。請盡力替B辯護。要讓B成為正確選擇,我們的限制條件必須是什麼？這裡的情況符合嗎？

Whizi的並排比較功能就是為此而生,詳情記載於並排比較模型。

程式碼審查與讀懂陌生程式碼

提示語：像嚴格的審查者一樣看差異

審查這份差異。分類依序是：正確性錯誤、安全性問題、未處理的失敗情況、競態條件,然後才是風格。每個發現都給出嚴重程度、具體的行數,以及為什麼這在這裡很重要,而不是泛泛而談。不要評論格式。如果這份差異沒問題,就直說。背景：這個程式庫用[技術棧和慣例]。差異：[貼上]。

提示語：看懂剛接手的程式庫

這是主要的原始碼檔案。請整理出：進入點、從請求到回應的資料流、共用的狀態以及在哪裡被修改、外部依賴以及每個依賴無法使用時會發生什麼,還有根據複雜度和耦合度,最可能藏有錯誤的三個部分。對於你無法從我給的資料判斷的部分,請明確說出來。

最後那句指示比看起來重要得多。模型會很樂意根據檔名推測,描述一份你根本沒貼的檔案的行為。強迫它明確列出未知項目,能告訴你該去讀哪裡。

提示語：寫出你沒想到的測試

為這個函式寫測試案例,聚焦在我可能沒考慮到的輸入：邊界值、空值和null、萬國碼、極大值、並行呼叫,以及實作裡任何隱含的假設。每個測試都要說明它在檢查哪個假設。函式：[貼上]。

真正浪費時間的出錯模式

捏造的API。模型會很有自信地生出根本不存在的方法名稱、參數,和設定鍵值,尤其是最近改版或比較冷門的程式庫。簽名看起來會很像真的。在用陌生的東西之前,先查真正的文件。

自信滿滿的錯誤修正。語氣裡沒有任何線索。一個能解決你問題的修正,和一個引入新的細微問題的修正,交出來的自信程度一模一樣。永遠要問這個改動可能弄壞什麼。

過時的寫法。訓練資料偏向針對某個框架寫出的程式碼量,而那往往是上一個主要版本。如果答案感覺像是好幾年前的,那大概就是。在提示語裡說明你用的是哪個版本。

悄悄擴大的範圍。你要的是修正,結果常常拿到一次重構。加上「盡量少改動,並列出你改的每一行和原因」,讓差異保持可審查。

安全劇場。模型能講出你程式碼裡的漏洞類型,這對初步檢查確實有用,但這不是稽核。它不知道你的威脅模型、你的部署方式,或你的資料敏感度。

這在你既有的工具鏈裡的定位

它不會取代你的編輯器整合或代理式寫程式工具。它取代的是你原本用來比較答案的三個瀏覽器分頁,以及為了同時開著那些分頁所需要的兩份訂閱。

大多數開發者最後採用的實務配置是：一個預設模型處理快速問題,第二個模型在第一個答案不夠有說服力時切換過去,以及需要一次把大量程式碼或長篇規格放到模型面前時用Gemini。全部在同一個對話串裡進行,這樣你已經建立好的脈絡會延續下去,不用切換時重貼一次。

更深入的內容請見AI寫程式、聚焦寫程式的替代方案比較,和Claude寫程式提示語包。在Whizi裡執行這套配置的細節則在用多個模型撰寫與除錯程式碼。