写代码该用哪个模型：按子任务选，用同一题对照

不存在一个永远最适合写代码的模型。改一个边界条件、读懂三四个文件、补测试、给中文注释，考察的不是同一件事。公开榜单更难代表你的仓库约定、语言版本和「改完能不能合并」的标准。

所以本页不排名，只做两件事：按子任务给一个可以先试的家族起点；给一道能粘贴的题和明确的验收方式。倾向来自通用经验/社区共识，你要用自己的仓库重跑。本文没有在 Trymodel 上对真实项目做「已实测」对照，因此文中也不会出现已实测结论。

在 https://trymodel.chat/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/chat。

中文注释谁更稳？

没有免测答案。DeepSeek 值得作为中文对照的起点，Claude 值得作为「少写错保证」的对照，但这是方法，不是排名。用带术语表的那道题看：译名是否受控、有没有把「线程安全」之类写进没做这些事的函数。谁在你的仓库里少改、少误导，谁就当这类任务的默认。细节也可参考 Claude vs DeepSeek。

要不要为每个模型再写一篇编程文？

不要。站内已经出现过高度同质的「某型号用于编程开发」页。以后模型更新，只更新本篇的起点表和提示词，并用同一套题重跑。不要再按 DeepSeek、Grok、Claude、GPT 各写一篇四步工作流几乎相同的模板。

我听说 Claude 写代码最好，还用对照吗？

社区确有这样的说法，例如 V2EX t/1179389 里的原话，但它同时混杂了官网风控等体验，也不是针对你的语言和仓库。把它当作改 bug、读仓库的第一候选即可。若 Claude 在你的题目上发明 API、或中文术语更乱，就应当改默认。本页存在的目的，就是避免把一句社区原话升级成全站口号。

上下文更大的模型，是不是更适合读整个项目？

不一定。能放进更多文件，不等于已经抓住约定和冲突。读仓库那道题专门要求把「能确认的」和「必须另开文件的」分开。与其追求一次塞进整个项目，不如先贴入口和关键路径，确认地图没错再扩大范围。