寫程式碼該用哪個模型：按子任務選，用同一題對照

不存在一個永遠最適合寫程式碼的模型。改一個邊界條件、讀懂三四個檔案、補測試、給中文註釋，考察的不是同一件事。公開榜單更難代表你的倉庫約定、語言版本和「改完能不能合併」的標準。

所以本頁不排名，只做兩件事：按子任務給一個可以先試的家族起點；給一道能貼上的題和明確的驗收方式。傾向來自通用經驗/社群共識，你要用自己的倉庫重跑。本文沒有在 Trymodel 上對真實專案做「已實測」對照，因此文中也不會出現已實測結論。

在 https://trymodel.chat/zh-tw/chat 切換 ChatGPT、Claude、Gemini、Grok、DeepSeek 等模型，用同一份材料比較即可。Trymodel 不是各模型官方賬號，更不是官方 IDE 或命令列工具。如果你日常依賴 Claude Code 之類的官方原生工作流，它們通常仍更適合「在真實倉庫裡改檔案、跑測試、看 diff」這一層；聚合器裡的聊天可以幫忙讀程式碼和起草補丁，但不能把官方工作流整個換掉。

先說清楚：不要用跑分代替驗收

本頁不引用、不編造 SWE-bench 或其他排行榜分數。那些評測有自己的題目分佈和工具設定，很少等於你下午要合進去的那一個 PR。

社群裡確實有相對穩定的說法。例如 V2EX 討論「預算有限三選一」時，有人寫「純程式設計還是 Claude 比較頂」，同時也提到官方賬號風控，見 t/1179389。Reddit 等討論常把 Claude 放在程式設計和長寫作一側，把其他模型放在綜合預設或別的任務上。這隻能當作「改 bug 和讀倉庫時，很多人會先點 Claude」的起點，不能寫成「Claude 已在本站實測第一」。

中文社群在評估聚合器時，還會問程式碼能力夠不夠、積分或額度是否撐得住、效果是不是不如官網。例如 V2EX t/1100581、LINUX DO 相關討論。這些擔心的是渠道和配額，不是某一家模型在真空裡的絕對分數。所以下面每道題都要求你記錄模型顯示名和日期，並以「測試是否紅變綠、diff 是否只改了該改的檔案」為驗收，而不是看回答長不長。

子任務起點表

下表是第一輪可以先試誰，不是終局。站點模型頁的一句話定位只作入門畫像。

任何一輪都不要把金鑰、令牌、生產資料貼進對話。

改 bug：要最小補丁，不要順便重構

先試 Claude 或 ChatGPT，是因為這類任務最怕「看起來專業、其實改了無關行為」。社群把 Claude 放在程式設計一側的共識，只用來決定第一下點誰。

可複製提示詞：

現有程式碼和當前失敗表現如下。請只修這個 bug，不要做風格重構，不要升級依賴，不要改公共 API。

已知：
- 期望行為：[一句話]
- 實際行為：[一句話]
- 復現步驟：[最短步驟]
- 失敗時的報錯或日誌：[貼上，先刪掉金鑰]
- 相關程式碼：[只貼會碰到的檔案，標檔名]

輸出：
1. 對根因的判斷，分成「有程式碼證據」和「還只是假設」。
2. 最小補丁（標明檔案；用 diff 或完整替換給出，不要夾敘夾議）。
3. 一條能復現該 bug 的迴歸測試。寫明：未打補丁時應失敗，打上後應透過。
4. 你改動可能影響的邊界，以及我應該再跑的最快檢查命令（必須是本倉庫可能已有的型別，不要發明我沒提到的工具鏈）。
5. 若材料不足以定位，停止給補丁，只列出還需要的資訊。

怎麼判斷： 先在本地確認測試在補丁前失敗、補丁後透過；看 diff 是否只涉及預期檔案；檢查有沒有被順手改掉的校驗、鑑權或錯誤資訊。模型說「建議一併重構」而你沒要求，記一次扣分。不要只看它把原理講得多長。

不要期待： 它不可能在沒看到呼叫方和配置的情況下，保證修的是生產上的那個根因。也沒有模型能替你跑完真實測試套件——除非你在官方 IDE / 命令列工作流裡把倉庫和測試跑通。聊天視窗給出的「應該透過」，仍要你在本地驗證。

讀倉庫 / 解釋程式碼：先畫地圖，再談改哪裡

先試 Claude。若輸入是很長的多檔案摘錄、還配有示意圖，把 Gemini 加進同一題。Grok 更適合另開一輪「還有哪些改法」，不要讓探索汙染第一輪的結構說明，細節見 Claude vs Grok。

可複製提示詞：

下面是同一倉庫裡的幾個檔案摘錄（可能不完整）。請只根據這些材料解釋，不要假裝你讀過整個倉庫。

任務：
1. 用自己的話說明這些檔案如何協作：入口在哪、資料怎麼走、關鍵抽象叫什麼。
2. 如果我要加一個功能：[用一句話描述真實需求]，指出最可能改的位置，以及不該改的位置。
3. 「材料裡能確認的」和「必須開啟其他檔案才能確認的」要分成兩節。後一節列出具體檔名或符號名（僅限材料中出現過的線索）。
4. 不要給出完整實現。不要發明材料裡沒有的模組、配置項或框架約定。
5. 若摘錄互相沖突，寫明衝突，不要自行選邊。

檔案摘錄：
[貼上 2–4 個檔案的關鍵部分，保留檔名和重要註釋]

怎麼判斷： 它對入口和資料流的描述，是否和你已經知道的結構一致；「必須另開的檔案」是否真的是下一步該看的地方；有沒有編出一個不存在的工具函式。把「寫得完整」和「沒有發明模組」分開打分。

不要期待： 聊天模型看不到你沒貼的目錄，也不會自動克隆倉庫。所謂巨大上下文，只說明一次能塞進更多摘錄，不說明它已經理解隱藏約定。需要在完整倉庫裡連續改檔案時，優先考慮官方或本地 IDE 工作流。

測試生成：先要會失敗的用例，再要覆蓋面

先試 Claude 或 ChatGPT。若測試邏輯本身像在推導規則，可加 DeepSeek，看步驟能不能複查。

可複製提示詞：

請只為下面這個函式（或模組）補充測試，不要改被測實現，除非你發現測試無法編寫的 API 問題——若如此，先停下來說明，不要擅自改實現。

要求：
1. 使用我指定的測試框架：[例如 pytest / Jest / JUnit，按倉庫實際情況填寫]。若材料不足以判斷框架，先問我，不要換成你喜歡的框架。
2. 至少包含：正常路徑、空輸入或零值、重複呼叫、失敗/異常路徑、以及一個迴歸用例對應已知缺陷：[描述]。
3. 每個用例寫清：準備、呼叫、斷言。斷言必須針對可觀察行為，不要只斷言「被呼叫過」。
4. 明確寫出：哪些邊界你無法從當前程式碼判斷，因此沒有編造用例。
5. 給出我本地最快的執行命令，且必須符合我提到的工具鏈。

被測程式碼：
[貼上]
已知缺陷（如有）：
[貼上]

怎麼判斷： 先跑這些測試，看它們是否真能失敗、是否依賴了並不存在的 API；有沒有為了「看起來覆蓋全面」而斷言內部實現細節，導致一次無害重構就要改光測試。用例少但能抓住真實缺陷，優於二十個空洞的 toBeDefined()。

不要期待： 模型不會知道生產上最容易炸的那條資料，除非你把形狀和失敗例子給它。也不要指望它替你維護整倉的測試策略。

中文註釋 / 文件：對照的是準確和剋制，不是誰更像母語者

這一項不要預設「中文模型一定更穩」。把 DeepSeek 和 Claude 放在同一題裡，必要時再加 ChatGPT。測法與 Claude vs DeepSeek 一致：自然只是維度之一，能不能少寫錯承諾更重要。

可複製提示詞：

請為下面的函式補充中文文件：一段模組/函式說明，以及必要的引數和返回值註釋。語言必須是自然的簡體中文。

硬性要求：
1. 術語必須遵守對照表。對照表沒有的詞，不要擅自翻譯成另一個常見譯名；應保持原文並在首次出現時用括號給一個建議譯名，標成「待確認」。
2. 不要把假設寫成已實現能力。程式碼裡沒有做併發控制，就不要寫「執行緒安全」。
3. 不要在註釋裡教人複製金鑰，或把示例寫成真實地址和令牌。
4. 註釋只解釋「為什麼」和「呼叫約定」，不要複述每一行在幹什麼。
5. 最後列「我故意沒寫的內容」，例如你無法從程式碼確認的效能、相容性或錯誤碼。

術語對照表：
[例如：idempotent = 冪等；tenant = 租戶；不要寫成「使用者」]
程式碼：
[貼上]

怎麼判斷： 術語有沒有按表走；有沒有把沒做的保證寫進去；中文是否通順但不過度口語；一個不熟悉該模組的同事，能不能只靠註釋知道該傳什麼、不能傳什麼。把「流暢」和「沒有多寫保證」分開打。

不要期待： 沒有術語表時，任何模型都可能把同一個詞譯亂。註釋也不能替代真實的架構決策記錄。

同一題對照時的公共規則

1. 只比較第一輪。不要先和模型 A 聊到補丁能用，再把修改後的提示詞拿去考模型 B。
2. 記錄日期、介面上的模型顯示名、語言和框架。新版本釋出後重跑同一份材料，不要再新開一篇「某型號用於程式設計開發」。
3. 驗收寫在提示詞之前：構建或型別檢查、聚焦測試、diff 範圍。流暢的解釋不能覆蓋紅測試。
4. 計算的是「得到可合併結果」的時間，含你的返工，而不是誰先開始說話。
5. 需要最新文件時，把官方文件片段一併貼進材料，或先自行核對後再提問；不要讓模型憑記憶發明 API。

家族層面的選擇方法可先看現已上線的對照頁：ChatGPT vs Claude、ChatGPT vs Gemini 和 Claude vs Gemini。

國內訪問、支付，以及官方工具仍可能更合適

若你主要卡在「官方 Claude / ChatGPT 怎麼付」，這是帳戶和支付問題，不是哪家更會寫迴圈。公開綜述裡寫過部分國際產品在中國大陸的消費者訂閱和國內卡支付限制，見 Check.AI，以各官網當天為準。更完整的正規入口說明見 國內怎麼用 Claude、ChatGPT 和 Grok。不要用代充、合租或交出官方密碼的方式獲取官方 IDE / 官方會員，本文不提供這類步驟。

在 Trymodel 裡做聊天對照，套餐與支付方式以 定價頁 當天公示為準。一次性購買支援信用卡／扣帳卡與支付寶（使用簡體中文以人民幣結帳時可使用微信支付），到期不自動扣費；若在月卡或年卡下選擇「自動續訂（僅銀行卡）」，會按週期扣款，直到取消。詳細見 定價與計費說明。當天能選哪些型號，以 新模型核對指南 為準。

再次強調分工：聚合器適合用同一題比較補丁質量和中文文件；官方 Claude Code 或其它 IDE 原生工具適合在完整倉庫裡連續修改和執行測試。兩者可以並存，不要互相冒充。

常見問題

聚合器裡寫程式碼夠不夠？

夠不夠取決於任務，而不是品牌承諾。若你的工作是貼出最小復現、比較幾份補丁和測試，然後自己在本地跑，聚合器通常夠做決策。若你需要代理自動改多檔案、跑完整測試、對接官方工具鏈，應評估官方原生工作流。社群質疑聚合器時，經常提到額度、上下文和是否與官網一致，見 LINUX DO 討論 與 V2EX t/1100581。用本頁的驗收標準自測，比追問「某聚合器能不能替代 Claude 官方」更具體。不要上傳金鑰和生產資料。

同一題怎麼對比才公平？

固定材料、固定約束、只看第一輪，再用預先寫好的標準打分：測試紅變綠、diff 範圍、有沒有發明 API、你的修改時間。不要拿一家的第 5 輪結果去比另一家的第 1 輪。把記錄留在一份筆記裡，換版本時重跑。入口：https://trymodel.chat/zh-tw/chat。

中文註釋誰更穩？

沒有免測答案。DeepSeek 值得作為中文對照的起點，Claude 值得作為「少寫錯保證」的對照，但這是方法，不是排名。用帶術語表的那道題看：譯名是否受控、有沒有把「執行緒安全」之類寫進沒做這些事的函式。誰在你的倉庫裡少改、少誤導，誰就當這類任務的預設。細節也可參考 Claude vs DeepSeek。

要不要為每個模型再寫一篇程式設計文？

不要。站內已經出現過高度同質的「某型號用於程式設計開發」頁。以後模型更新，只更新本篇的起點表和提示詞，並用同一套題重跑。不要再按 DeepSeek、Grok、Claude、GPT 各寫一篇四步工作流幾乎相同的模板。

我聽說 Claude 寫程式碼最好，還用對照嗎？

社群確有這樣的說法，例如 V2EX t/1179389 裡的原話，但它同時混雜了官網風控等體驗，也不是針對你的語言和倉庫。把它當作改 bug、讀倉庫的第一候選即可。若 Claude 在你的題目上發明 API、或中文術語更亂，就應當改預設。本頁存在的目的，就是避免把一句社群原話升級成全站口號。

上下文更大的模型，是不是更適合讀整個專案？

不一定。能放進更多檔案，不等於已經抓住約定和衝突。讀倉庫那道題專門要求把「能確認的」和「必須另開檔案的」分開。與其追求一次塞進整個專案，不如先貼入口和關鍵路徑，確認地圖沒錯再擴大範圍。