作为一个常年在 Hacker News 上潜水、靠 AI 模型吃饭的开发者，每次刷到 "Which model do you use for work?" 这种帖子，我都会停下来认真翻一遍评论。这问题看似简单，背后却是过去两年里所有工程师都在经历的焦虑：模型迭代太快，今天刚上手一个，明天就有新版本号称性能翻倍；昨天还在用 A 模型写代码，今天 B 模型已经能把 A 的活全包了。选型这件事，已经从“看看哪个跑分高”变成了“真正影响工作流效率和代码质量”的决策。

这篇文章不聊跑分榜单，不聊参数规模。我想结合自己实际工作中用过的模型、踩过的坑，以及从 HN 讨论串里看到的全球开发者共识，聊聊“工作中到底该用哪个模型”这个话题。如果你是刚接触 AI 编程工具的新手，这里有从零开始的模型选型思路；如果你已经在用 Claude、GPT、DeepSeek 这些模型写生产代码，后面关于上下文窗口、报错排查、模型切换策略的章节，应该能帮你省下不少折腾时间。

1. 工作场景下的模型选型，到底在选什么

先别急着看型号，想清楚一个问题：你让模型干活，干的是什么活？同样是“用模型”，写一封邮件和重构一个微服务，对模型的要求完全是两码事。

1.1 三类核心工作负载，对应三种选型逻辑

我把日常工作中模型承担的任务分成三类，每一类的选型逻辑都不一样：

第一类：纯对话与内容生成。包括写周报、捋需求、做会议纪要、生成 PRD 草稿。这类任务对代码能力没有要求，但对语言组织、逻辑连贯性、指令跟随能力要求高。选型逻辑是：上下文窗口大不大，单次能塞多少材料；输出稳定不稳定，会不会写着写着开始胡编；成本低不低，毕竟这类任务量大，没必要用最贵的模型。

第二类：代码生成与理解。写函数、补测试、解释老代码、做 code review。这是目前竞争最激烈、也是大家最关心的场景。选型逻辑是：代码能力是否足够强，能不能理解复杂业务逻辑；是否擅长工具调用，能自动读文件、改文件、跑命令；对主流语言和框架的掌握程度，比如 Go、Rust、TypeScript 的支持质量。

第三类：复杂推理与架构设计。拆解大型需求、设计系统方案、排查疑难 bug。这类任务对模型的上限要求最高，选型逻辑只有一条：推理能力是不是第一梯队。

你会发现，HN 帖子下面大家吵来吵去，其实吵的不是“哪个模型更好”，而是“哪个模型更适合我的工作负载”。有人天天写 CRUD，用轻量模型就够；有人做大规模重构，就得用最强推理模型。选型的第一步，是搞清楚自己的需求，而不是跟着别人的推荐走。

1.2 从 HN 讨论里看出的选型共识

这几年的 HN 帖子我看下来，有个很有意思的现象：早期大家推荐的模型五花八门，现在越来越趋同。倒不是因为大家的想法变统一了，而是模型市场经过洗牌后，各价位段的头部产品逐渐清晰了。

评论区里最常被提到的几个模型，基本覆盖了不同需求段位：像 Claude 的旗舰模型，是“预算充足、对代码质量要求高”的团队首选；GPT 系列是“全家桶生态、重度使用 OpenAI 工具链”的用户首选；而 DeepSeek 这类高性价比模型，则成了“想省钱但又不愿牺牲太多质量”的开发者的共识选择。还有个有意思的现象，很多人会同时订阅两到三个模型，按任务类型分开用，而不是把所有鸡蛋放一个篮子里。

这个现象背后其实是一个很实际的考量：没有哪个模型在所有维度上都碾压对手。Claude 写代码细节好，但某些指令跟随场景不如 GPT 灵活；GPT 生态强，但 API 价格让人肉疼；DeepSeek 便宜，但部分复杂推理任务的上限确实不如头部旗舰。所以“工作中用什么模型”的答案，往往是“按需混搭”，而不是“梭哈一个”。

提示：如果你是个人开发者，预算有限，我的建议是先选一个主力模型用透，再留一个备胎。主力负责日常写代码和推理，备胎负责主力偶尔抽风时顶上。混搭的前提是先把一个模型用熟，不然切换成本会吃掉你省下的所有成本。

2. 为什么模型容量和上下文窗口，是工作中最关键的参数

参数规模、跑分这些纸面数据，工作中其实感知不强。真正每天都在影响你的，是上下文窗口长度和单次请求的 token 配额。这两样东西，直接决定了你“能不能把整个项目塞进去”。

2.1 上下文长度决定你能干多大的活

拿代码场景举例，一次代码补全请求需要把部分代码、相关定义、注释一起发给模型，让模型理解上下文。如果你的项目代码库很大，上下文窗口太小，模型就只能“管中窥豹”，生成的代码经常跟周边逻辑脱节。这也是为什么很多开发者反馈“模型写单函数还行，写跨文件的改动就拉胯”——这不是模型能力不行，是上下文窗口限制了它能看到的东西。

常见模型的上下文长度大概这几个档位：入门档在 16k 到 32k token 左右，适合处理单文件代码和轻量对话；主流档在 64k 到 128k token，能覆盖中小型项目的核心代码库；旗舰档在 200k token 以上，甚至有些模型宣称支持百万级 token，比如我看到过一个报错信息专门提到this model's maximum context length is 1048576 tokens。百万 token 是什么概念？一本书大约 10 万 token，百万 token 意味着你可以把一个大项目的好几个核心模块完整塞进去，让模型建立全局认知。

但注意，上下文窗口长不代表你就该把它用满。有两个现实问题：一是上下文越长，模型的处理速度和响应时间越慢，等你着急出结果时，慢半拍是很痛苦的；二是上下文越长，单次请求成本越高，很多模型按 token 计费，塞 50 万 token 进去，一次请求可能就是几美元。工作中比较务实的做法是：把上下文控制在你需求范围的 1.5 倍以内，给模型留点“余量”去组织输出，而不是把窗口塞到极限。

2.2 那串神秘的报错：token 上限与配置陷阱

之前我在社交平台里经常看到有人贴报错，比如api error: 400 this model's maximum context length is 1048576 tokens. however...。这种报错基本有两种情况：一是你把超长文本一次性塞给了模型，被服务端拦了；二是你用的模型实际上下文上限比宣称的小，或者你的客户端配置里设置了过大的 max_tokens 值。

我有一次踩过一个很蠢的坑：在客户端里把max_tokens设成了 8192，但模型实际只能输出 4096 token。我以为自己配置没问题，结果每次长输出都报错，排查了半天才发现是客户端配置和模型能力不匹配。这类问题在配置里很常见，尤其是当你同时用好几个模型的时候，每个模型的能力上限不一样，配置模板却是同一份。这里提醒大家，切换模型时，除了看上下文长度，还要确认一下输出 token 上限和模型支持的最大请求数。

2.3 实操经验：按任务类型决定上下文用量

我的经验是，给上下文长度分几个使用档位：

快速问答档，500 到 2000 token。问概念、问思路、做小范围代码解释，不需要塞太多上下文，响应最快。

单文件档，4k 到 16k token。处理单个文件的代码生成、重构、测试，把当前文件和相关依赖的签名塞进去。

多文件档，16k 到 50k token。处理跨文件改动、模块级重构，把相关文件的核心代码都放进去。

项目级档，50k token 以上。做架构设计、大范围代码审查、新项目起手，这时候模型需要看到项目的整体结构。

我自己在实际操作中并不会每次都手动数 token，而是按“文件数量”估算：一个文件大概 2k 到 4k token，10 个文件就是 20k 到 40k。当模型开始出现“忘了前面内容”的现象，就是上下文快不够用了，这时候要么精简输入，要么换个上下文更大的模型。

3. 模型报错的背后，是选型与配置的失衡

热词列表里有一大堆报错信息，比如selected model is at capacity. please try a different model.、the 'gpt-5.6-sol' model is not supported when using codex、error running remote compact task: codex ran out of room in the model's context。这些报错看起来五花八门，但本质上都是同一个问题：你选的模型和你的使用方式不匹配。

3.1 "model is at capacity"：容量与降级的博弈

selected model is at capacity. please try a different model.这个报错，中文意思是“你选的模型当前负载已满，请换个模型试试”。很多人遇到这个报错不知所措，其实处理逻辑很简单：要么等待重试，要么临时切换到备用模型。

我处理这个问题的经验是分两种情况讨论。如果你是个人使用，遇到高峰期报这个错，换个时间段再试就行，一般晚上和周末负载会好很多。但如果你是团队使用，模型的容量问题就没这么好糊弄了。有一次我们团队在赶一个紧急版本的代码审查，结果主力模型突然全时段报 at capacity，整个开发流程卡了大半天。后来我们总结了经验：团队用模型一定要有降级方案，把次优模型配置好，至少保证主干流程不中断。

3.2 模型不存在或不支持的报错，八成是版本问题

再看the 'gpt-5.6-sol' model is not supported when using codex with a chatgpt account和unexpected status 404 not found: the model 'gpt-6-sol' does not exist这类报错。这两个问题我见得特别多，尤其是那些喜欢追新模型、第一时间切换新型号的开发者和团队。

这类报错的原因主要有两种：一是你用的客户端工具版本太旧，不认识新模型的名字。比如你本地装的 Codex CLI 是三个月前的版本，但模型服务商已经发布了新模型，接口不认你传的模型名。二是你用的模型名写错了，或者那个模型根本不存在。比如网上的信息说gpt-5.6-sol很厉害，但实际上官方还没有这个型号，只有gpt-5.6，你硬要传一个带后缀的名字，服务端自然返回 404。

注意：当你切换到一个新模型，特别是那种带后缀、带版本号的命名（比如-sol、-mini、-latest），一定要去官方文档确认模型的确切名称，而不是从社交平台的帖子里复制一个人家的配置。很多报错就是因为单个字符的差异导致的。

3.3 上下文压缩失败的背后，是长任务处理的焦虑

error running remote compact task: codex ran out of room in the model's context这个报错就比较高级了。Compact 是很多 AI 编程工具的功能，当对话太长超出上下文窗口时，工具自动总结之前的对话，腾出空间继续干活。如果你看到这个报错，说明工具在压缩上下文时失败了，模型“没有余量”继续执行压缩任务。

我的理解是，这个问题的本质是模型上下文窗口利用失衡：会话太长，工具试图压缩，但压缩后的内容依然放不进可用窗口；或者压缩操作本身需要额外的 token，但已经被用光了。处理办法有两个，一是手动精简会话内容，比如把无关对话清理掉再继续，二是换一个大上下文窗口的模型，从根本上减少压缩的必要性。

这类报错还提醒我一件事：上下文窗口再大，也经不住无限堆积。工作中要做“会话卫生”，该开新会话就开新会话，该清理旧上下文就清理，别指望模型一直背着你增加的负担。

3.4 模型 catalog 问题：版本更新的连锁反应

glm-5.3 isn't described by this version's model catalog; update claude code这类报错，暴露了一个现代 AI 工具链的现实问题：模型更新速度远超客户端工具的适配速度。你本地装着一个稳定版工具，模型服务商发布了新模型，但你的工具里没有新模型的描述，于是出现“模型存在但工具不认识”的尴尬情况。

解决思路也很直接：升级工具版本。但我遇到过更麻烦的情况：工具升级后，旧配置不兼容新模型，导致更诡异的报错。所以我现在升级工具前，会先看更新日志，确认模型相关的改动，再决定要不要升级。团队里有时会约定一个“保守更新”策略：工具版本追进到某一个大版本，保持对当前主力模型的稳定支持，不盲目追最新。

4. 从零配置一个可用的模型工作流

理论说了一堆，来点实际的。假设你是刚开始接触 AI 编程的新手，或者想优化现有工作流，这套步骤是我验证过很多次的可用方案。

4.1 第一步：选好主力模型，配置好 API 密钥和基础参数

主力模型怎么选，我给出的判断标准很简单：看你的预算和任务类型。

如果你重度依赖代码生成，预算也充足，首选自然是 Claude 旗舰系列，代码质量在同类模型里很突出。如果你更依赖 OpenAI 的生态，比如用 Codex 或 ChatGPT 商业版，那选 GPT 系列准没错，API 兼容性和工具链成熟度很高。如果你想要性价比，DeepSeek 是很好的选择，代码能力不弱，价格只有旗舰模型的一个零头，特别适合个人开发者或者刚起步的创业团队。

选好后，配置参数时注意几个容易出错的地方：API 密钥漏填或填错会在调用时报 401 认证错误，最常见的低级错误；base_url 没填对，调用时才会报provider 缺少 base_url 配置，这个问题在自建代理、网关工具时比较常见；模型名没写对，会报model does not exist。这三个基础配置，是排错时的第一检查点。

4.2 第二步：把上下文管理做成习惯

工作中用模型最核心的习惯，其实是管理上下文。我给自己定了三条规则：

规则一，问新问题前先想一下旧对话还有没有必要。如果你的问题是全新的方向，直接开新会话，别在旧对话里继续叠加。旧对话的上下文会不知不觉吃掉你的 token 预算。

规则二，向模型提供材料时，只给相关的。有些人喜欢把整个项目代码全部塞给模型，指望模型自己挑重点。结果显示模型不仅没有挑出重点，反而被无关代码干扰了判断。工作中做代码审查或生成，我给模型的上下文是“目标文件 + 相关定义 + 设计文档摘要”，而不是“整个仓库”。

规则三，发现模型开始“遗忘”，主动精简上下文。如果你发现模型突然开始问你已经提供过的问题，或者输出内容跟之前上下文矛盾，这就是上下文被稀释的信号。这时候别继续对话，重新整理材料，开新会话。

4.3 第三步：准备一个可靠的降级方案

主力模型再好，总有翻车的时候。容量满了、服务端不稳定、API 报错，任何一环出问题，都可能卡住工作流。我的降级方案很简单：本地常备一个备用模型的 API 配置，平时不启用，主力出问题时一键切换。

这个备用模型不一定是同级别的产品。如果你主力用 Claude 旗舰，备用可以配一个 DeepSeek 或者 GPT 的中端模型。任务紧急时，备用模型可能完成不了最高难度的任务，但至少能保证基础代码生成和文本处理不断档。很多团队喜欢“只用一家模型”，我没有这个执念。工具是用来干活的，关键时刻能顶上，比品牌忠诚度重要得多。

4.4 第四步：琢磨一下工具链与模型是否匹配

模型不是孤立的，它跑在工具链里。你的 CLI 工具、IDE 插件、代码审查工具，每一个都有自己的模型适配逻辑。我用过一些工具，默认只支持特定模型，你想换新模型，还得改配置、升级版本、甚至换工具。

实际项目中常见的一个现象是：你用 Claude Code 时，工具内部集成了 Anthropic 的模型路由，你想强行换成一个不兼容的模型，就会报之前提到的claude doesn't look like an anthropic model或expected a gateway model route这类错误。遇到这种情况，不要硬来。要么换一个原生支持你选定模型的工具，要么确认工具提供的自定义模型接口是否满足条件。硬塞不兼容模型的结果，只会是浪费一晚上时间排查报错。

5. 常见问题速查表与避坑经验

这一节我把平时积累的模型使用问题整理成速查表，按场景分类，方便你遇到问题快速定位。

5.1 关于“新模型焦虑”的一些个人看法

还有一个想聊的点。我发现很多开发者有“新模型焦虑”，看到 HN 上有人讨论某个新模型性能爆炸，就忍不住想切换。我的建议是：没必要。

我自己有个惨痛教训。有一阵子一个刚发布的新模型在社交平台上口碑很好，我按捺不住切换过去，结果核心任务的效果反而不如老模型稳定。后来我发现问题不在模型能力，而在工作流适配：新模型的上下文行为、输出格式、工具调用方式都和老模型不一样，我现有的提示词和配置是为老模型调的，直接套用到新模型上自然水土不服。

所以换模型可以，但请把它当成一件需要认真对待的事，而不是“一键切换”的冲动操作。我的流程是：先拿几个典型任务用同一批提示词跑一遍对比，确认新模型确实有优势，再小范围切换，跑几天观察效果，最后才全面铺开。另外，在新模型效果还不确定的时候，务必保留旧模型的配置，方便随时回滚。

5.2 三个让你少踩坑的小技巧

最后分享三个实操小技巧，都是我反复踩坑后总结出来的：

技巧一，把所有 API 配置集中管理，不要散落各处。我有一次为了调试一个问题，改了三个地方的环境变量，结果忘了改第四处，整整排查了半天。后来我把所有 API 密钥、模型名、base_url 统一放进一个配置文件，用环境变量做动态覆盖，问题一下就少了。

技巧二，写提示词时把模型能力边界写进预期里。比如你明确知道模型上下文窗口是 128k token，就在任务描述里注明“只分析以下内容，忽略未提供的部分”，引导模型专注于你给定的材料。如果你不写，模型有时候会自己脑补一些不存在的上下文，导致回答质量下降。

技巧三，关注模型服务商的状态页。遇到诡异的报错，别急着改配置，先去服务商的状态页看有没有服务中断的公告。很多时候 is at capacity、upstream request failed 这类报错，纯粹是服务端问题，不是你配置的问题。清醒认识这一点，能节省你大量无谓的排查时间。

5.3 从长期角度理解模型选型

再说说长期视角。过去两年模型迭代速度极快，今天的最优选择，可能三个月后就过时了。与其每次试图“预测未来”，不如建立一套能快速切换模型的机制。这就是为什么我建议从第一天就把模型名称、上下文窗口、token 限制这些信息抽象成配置，而不是硬编码在代码里。

我见过一些团队的代码里写死了模型名，比如直接调用 API 时传"model": "gpt-5.6-sol"，后来模型升级了，他们花了整整一周改代码。而另一些团队用一个统一的模型配置层，切换模型只需要改一个配置文件。两种做法的差别，在迁移成本上体现得淋漓尽致。

所以我在实际工作中始终坚持一个原则：把“用什么模型”和“怎么用模型”两者分离。前者是配置问题，后者是业务逻辑问题。我会在代码里抽象一层，让模型名成为可配置的参数，而不是把模型名当成业务常量。这不是过度设计，在模型快速迭代的当下，这是最值得的投资。

6. 我的选择与实践经验

标题问的是“Which model do you use for work”，我说了这么多，也分享一下自己的实际方案。

目前我的主力模型是 Claude 的旗舰系列，主要在代码生成、复杂重构、疑难 bug 排查上使用。日常的文本处理、信息整理、轻量代码任务，我用 DeepSeek，性价比高，API 稳定，支持多个编程工具，减轻成本压力。另外还有 GPT 系列做补充，主要在需要 OpenAI 特定生态的场景下使用。三个模型各有分工，基本覆盖了我工作中从轻量问答到重型架构设计的全部场景。

这个组合不是一步到位的。早期我也试图用一个模型解决所有问题，后来发现既要应付又贵，效果也不理想。后来慢慢迭代成现在的模式，成本降下来了，效果也提升了。选的模型不一定是最强的，但一定是最契合自己工作流节奏的。每个人的情况不一样，建议你结合自己的预算和任务类型做匹配。

如果你刚开始搭建自己的模型工作流，建议先别追求“最强”，先追求“可负担、稳定、顺手”。把基础配置做好，把上下文管理做好，把降级方案准备好，剩下的交给时间。这是一个逐步演进的过程，一次到位不现实，但每一步都走稳了，你的工作流会越来越顺畅。