作为一个常年在 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 models maximum context length is 1048576 tokens。百万 token 是什么概念一本书大约 10 万 token百万 token 意味着你可以把一个大项目的好几个核心模块完整塞进去让模型建立全局认知。但注意上下文窗口长不代表你就该把它用满。有两个现实问题一是上下文越长模型的处理速度和响应时间越慢等你着急出结果时慢半拍是很痛苦的二是上下文越长单次请求成本越高很多模型按 token 计费塞 50 万 token 进去一次请求可能就是几美元。工作中比较务实的做法是把上下文控制在你需求范围的 1.5 倍以内给模型留点“余量”去组织输出而不是把窗口塞到极限。2.2 那串神秘的报错token 上限与配置陷阱之前我在社交平台里经常看到有人贴报错比如api error: 400 this models 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 token10 个文件就是 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 models 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 models context这个报错就比较高级了。Compact 是很多 AI 编程工具的功能当对话太长超出上下文窗口时工具自动总结之前的对话腾出空间继续干活。如果你看到这个报错说明工具在压缩上下文时失败了模型“没有余量”继续执行压缩任务。我的理解是这个问题的本质是模型上下文窗口利用失衡会话太长工具试图压缩但压缩后的内容依然放不进可用窗口或者压缩操作本身需要额外的 token但已经被用光了。处理办法有两个一是手动精简会话内容比如把无关对话清理掉再继续二是换一个大上下文窗口的模型从根本上减少压缩的必要性。这类报错还提醒我一件事上下文窗口再大也经不住无限堆积。工作中要做“会话卫生”该开新会话就开新会话该清理旧上下文就清理别指望模型一直背着你增加的负担。3.4 模型 catalog 问题版本更新的连锁反应glm-5.3 isnt described by this versions 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 doesnt look like an anthropic model或expected a gateway model route这类错误。遇到这种情况不要硬来。要么换一个原生支持你选定模型的工具要么确认工具提供的自定义模型接口是否满足条件。硬塞不兼容模型的结果只会是浪费一晚上时间排查报错。5. 常见问题速查表与避坑经验这一节我把平时积累的模型使用问题整理成速查表按场景分类方便你遇到问题快速定位。错误现象常见原因快速处理model is at capacity模型负载过高换备用模型或错峰重试model does not exist / 404模型名拼写错误/不存在去官方文档确认准确名称model not supported with xxx客户端工具不支持该模型升级工具版本或换兼容模型maximum context length exceeded输入内容超出上下文上限精简输入或换大窗口模型provider 缺少 base_url 配置API 网关未配置补全 base_url 配置model catalog 版本过旧工具未适配新模型升级工具/更新模型目录compact task failed上下文过满、压缩失败开新会话、整理上下文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 特定生态的场景下使用。三个模型各有分工基本覆盖了我工作中从轻量问答到重型架构设计的全部场景。这个组合不是一步到位的。早期我也试图用一个模型解决所有问题后来发现既要应付又贵效果也不理想。后来慢慢迭代成现在的模式成本降下来了效果也提升了。选的模型不一定是最强的但一定是最契合自己工作流节奏的。每个人的情况不一样建议你结合自己的预算和任务类型做匹配。如果你刚开始搭建自己的模型工作流建议先别追求“最强”先追求“可负担、稳定、顺手”。把基础配置做好把上下文管理做好把降级方案准备好剩下的交给时间。这是一个逐步演进的过程一次到位不现实但每一步都走稳了你的工作流会越来越顺畅。