作為一個(gè)常年在 Hacker News 上潛水、靠 AI 模型吃飯的開發(fā)者每次刷到 Which model do you use for work? 這種帖子我都會(huì)停下來認(rèn)真翻一遍評(píng)論。這問題看似簡(jiǎn)單背后卻是過去兩年里所有工程師都在經(jīng)歷的焦慮模型迭代太快今天剛上手一個(gè)明天就有新版本號(hào)稱性能翻倍昨天還在用 A 模型寫代碼今天 B 模型已經(jīng)能把 A 的活全包了。選型這件事已經(jīng)從“看看哪個(gè)跑分高”變成了“真正影響工作流效率和代碼質(zhì)量”的決策。這篇文章不聊跑分榜單不聊參數(shù)規(guī)模。我想結(jié)合自己實(shí)際工作中用過的模型、踩過的坑以及從 HN 討論串里看到的全球開發(fā)者共識(shí)聊聊“工作中到底該用哪個(gè)模型”這個(gè)話題。如果你是剛接觸 AI 編程工具的新手這里有從零開始的模型選型思路如果你已經(jīng)在用 Claude、GPT、DeepSeek 這些模型寫生產(chǎn)代碼后面關(guān)于上下文窗口、報(bào)錯(cuò)排查、模型切換策略的章節(jié)應(yīng)該能幫你省下不少折騰時(shí)間。1. 工作場(chǎng)景下的模型選型到底在選什么先別急著看型號(hào)想清楚一個(gè)問題你讓模型干活干的是什么活同樣是“用模型”寫一封郵件和重構(gòu)一個(gè)微服務(wù)對(duì)模型的要求完全是兩碼事。1.1 三類核心工作負(fù)載對(duì)應(yīng)三種選型邏輯我把日常工作中模型承擔(dān)的任務(wù)分成三類每一類的選型邏輯都不一樣第一類純對(duì)話與內(nèi)容生成。包括寫周報(bào)、捋需求、做會(huì)議紀(jì)要、生成 PRD 草稿。這類任務(wù)對(duì)代碼能力沒有要求但對(duì)語言組織、邏輯連貫性、指令跟隨能力要求高。選型邏輯是上下文窗口大不大單次能塞多少材料輸出穩(wěn)定不穩(wěn)定會(huì)不會(huì)寫著寫著開始胡編成本低不低畢竟這類任務(wù)量大沒必要用最貴的模型。第二類代碼生成與理解。寫函數(shù)、補(bǔ)測(cè)試、解釋老代碼、做 code review。這是目前競(jìng)爭(zhēng)最激烈、也是大家最關(guān)心的場(chǎng)景。選型邏輯是代碼能力是否足夠強(qiáng)能不能理解復(fù)雜業(yè)務(wù)邏輯是否擅長(zhǎng)工具調(diào)用能自動(dòng)讀文件、改文件、跑命令對(duì)主流語言和框架的掌握程度比如 Go、Rust、TypeScript 的支持質(zhì)量。第三類復(fù)雜推理與架構(gòu)設(shè)計(jì)。拆解大型需求、設(shè)計(jì)系統(tǒng)方案、排查疑難 bug。這類任務(wù)對(duì)模型的上限要求最高選型邏輯只有一條推理能力是不是第一梯隊(duì)。你會(huì)發(fā)現(xiàn)HN 帖子下面大家吵來吵去其實(shí)吵的不是“哪個(gè)模型更好”而是“哪個(gè)模型更適合我的工作負(fù)載”。有人天天寫 CRUD用輕量模型就夠有人做大規(guī)模重構(gòu)就得用最強(qiáng)推理模型。選型的第一步是搞清楚自己的需求而不是跟著別人的推薦走。1.2 從 HN 討論里看出的選型共識(shí)這幾年的 HN 帖子我看下來有個(gè)很有意思的現(xiàn)象早期大家推薦的模型五花八門現(xiàn)在越來越趨同。倒不是因?yàn)榇蠹业南敕ㄗ兘y(tǒng)一了而是模型市場(chǎng)經(jīng)過洗牌后各價(jià)位段的頭部產(chǎn)品逐漸清晰了。評(píng)論區(qū)里最常被提到的幾個(gè)模型基本覆蓋了不同需求段位像 Claude 的旗艦?zāi)Ｐ褪恰邦A(yù)算充足、對(duì)代碼質(zhì)量要求高”的團(tuán)隊(duì)首選GPT 系列是“全家桶生態(tài)、重度使用 OpenAI 工具鏈”的用戶首選而 DeepSeek 這類高性價(jià)比模型則成了“想省錢但又不愿犧牲太多質(zhì)量”的開發(fā)者的共識(shí)選擇。還有個(gè)有意思的現(xiàn)象很多人會(huì)同時(shí)訂閱兩到三個(gè)模型按任務(wù)類型分開用而不是把所有雞蛋放一個(gè)籃子里。這個(gè)現(xiàn)象背后其實(shí)是一個(gè)很實(shí)際的考量沒有哪個(gè)模型在所有維度上都碾壓對(duì)手。Claude 寫代碼細(xì)節(jié)好但某些指令跟隨場(chǎng)景不如 GPT 靈活GPT 生態(tài)強(qiáng)但 API 價(jià)格讓人肉疼DeepSeek 便宜但部分復(fù)雜推理任務(wù)的上限確實(shí)不如頭部旗艦。所以“工作中用什么模型”的答案往往是“按需混搭”而不是“梭哈一個(gè)”。提示如果你是個(gè)人開發(fā)者預(yù)算有限我的建議是先選一個(gè)主力模型用透再留一個(gè)備胎。主力負(fù)責(zé)日常寫代碼和推理備胎負(fù)責(zé)主力偶爾抽風(fēng)時(shí)頂上?；齑畹那疤崾窍劝岩粋€(gè)模型用熟不然切換成本會(huì)吃掉你省下的所有成本。2. 為什么模型容量和上下文窗口是工作中最關(guān)鍵的參數(shù)參數(shù)規(guī)模、跑分這些紙面數(shù)據(jù)工作中其實(shí)感知不強(qiáng)。真正每天都在影響你的是上下文窗口長(zhǎng)度和單次請(qǐng)求的 token 配額。這兩樣?xùn)|西直接決定了你“能不能把整個(gè)項(xiàng)目塞進(jìn)去”。2.1 上下文長(zhǎng)度決定你能干多大的活拿代碼場(chǎng)景舉例一次代碼補(bǔ)全請(qǐng)求需要把部分代碼、相關(guān)定義、注釋一起發(fā)給模型讓模型理解上下文。如果你的項(xiàng)目代碼庫(kù)很大上下文窗口太小模型就只能“管中窺豹”生成的代碼經(jīng)常跟周邊邏輯脫節(jié)。這也是為什么很多開發(fā)者反饋“模型寫單函數(shù)還行寫跨文件的改動(dòng)就拉胯”——這不是模型能力不行是上下文窗口限制了它能看到的東西。常見模型的上下文長(zhǎng)度大概這幾個(gè)檔位入門檔在 16k 到 32k token 左右適合處理單文件代碼和輕量對(duì)話主流檔在 64k 到 128k token能覆蓋中小型項(xiàng)目的核心代碼庫(kù)旗艦檔在 200k token 以上甚至有些模型宣稱支持百萬級(jí) token比如我看到過一個(gè)報(bào)錯(cuò)信息專門提到this models maximum context length is 1048576 tokens。百萬 token 是什么概念一本書大約 10 萬 token百萬 token 意味著你可以把一個(gè)大項(xiàng)目的好幾個(gè)核心模塊完整塞進(jìn)去讓模型建立全局認(rèn)知。但注意上下文窗口長(zhǎng)不代表你就該把它用滿。有兩個(gè)現(xiàn)實(shí)問題一是上下文越長(zhǎng)模型的處理速度和響應(yīng)時(shí)間越慢等你著急出結(jié)果時(shí)慢半拍是很痛苦的二是上下文越長(zhǎng)單次請(qǐng)求成本越高很多模型按 token 計(jì)費(fèi)塞 50 萬 token 進(jìn)去一次請(qǐng)求可能就是幾美元。工作中比較務(wù)實(shí)的做法是把上下文控制在你需求范圍的 1.5 倍以內(nèi)給模型留點(diǎn)“余量”去組織輸出而不是把窗口塞到極限。2.2 那串神秘的報(bào)錯(cuò)token 上限與配置陷阱之前我在社交平臺(tái)里經(jīng)?？吹接腥速N報(bào)錯(cuò)比如api error: 400 this models maximum context length is 1048576 tokens. however...。這種報(bào)錯(cuò)基本有兩種情況一是你把超長(zhǎng)文本一次性塞給了模型被服務(wù)端攔了二是你用的模型實(shí)際上下文上限比宣稱的小或者你的客戶端配置里設(shè)置了過大的 max_tokens 值。我有一次踩過一個(gè)很蠢的坑在客戶端里把max_tokens設(shè)成了 8192但模型實(shí)際只能輸出 4096 token。我以為自己配置沒問題結(jié)果每次長(zhǎng)輸出都報(bào)錯(cuò)排查了半天才發(fā)現(xiàn)是客戶端配置和模型能力不匹配。這類問題在配置里很常見尤其是當(dāng)你同時(shí)用好幾個(gè)模型的時(shí)候每個(gè)模型的能力上限不一樣配置模板卻是同一份。這里提醒大家切換模型時(shí)除了看上下文長(zhǎng)度還要確認(rèn)一下輸出 token 上限和模型支持的最大請(qǐng)求數(shù)。2.3 實(shí)操經(jīng)驗(yàn)按任務(wù)類型決定上下文用量我的經(jīng)驗(yàn)是給上下文長(zhǎng)度分幾個(gè)使用檔位快速問答檔500 到 2000 token。問概念、問思路、做小范圍代碼解釋不需要塞太多上下文響應(yīng)最快。單文件檔4k 到 16k token。處理單個(gè)文件的代碼生成、重構(gòu)、測(cè)試把當(dāng)前文件和相關(guān)依賴的簽名塞進(jìn)去。多文件檔16k 到 50k token。處理跨文件改動(dòng)、模塊級(jí)重構(gòu)把相關(guān)文件的核心代碼都放進(jìn)去。項(xiàng)目級(jí)檔50k token 以上。做架構(gòu)設(shè)計(jì)、大范圍代碼審查、新項(xiàng)目起手這時(shí)候模型需要看到項(xiàng)目的整體結(jié)構(gòu)。我自己在實(shí)際操作中并不會(huì)每次都手動(dòng)數(shù) token而是按“文件數(shù)量”估算一個(gè)文件大概 2k 到 4k token10 個(gè)文件就是 20k 到 40k。當(dāng)模型開始出現(xiàn)“忘了前面內(nèi)容”的現(xiàn)象就是上下文快不夠用了這時(shí)候要么精簡(jiǎn)輸入要么換個(gè)上下文更大的模型。3. 模型報(bào)錯(cuò)的背后是選型與配置的失衡熱詞列表里有一大堆報(bào)錯(cuò)信息比如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。這些報(bào)錯(cuò)看起來五花八門但本質(zhì)上都是同一個(gè)問題你選的模型和你的使用方式不匹配。3.1 model is at capacity容量與降級(jí)的博弈selected model is at capacity. please try a different model.這個(gè)報(bào)錯(cuò)中文意思是“你選的模型當(dāng)前負(fù)載已滿請(qǐng)換個(gè)模型試試”。很多人遇到這個(gè)報(bào)錯(cuò)不知所措其實(shí)處理邏輯很簡(jiǎn)單要么等待重試要么臨時(shí)切換到備用模型。我處理這個(gè)問題的經(jīng)驗(yàn)是分兩種情況討論。如果你是個(gè)人使用遇到高峰期報(bào)這個(gè)錯(cuò)換個(gè)時(shí)間段再試就行一般晚上和周末負(fù)載會(huì)好很多。但如果你是團(tuán)隊(duì)使用模型的容量問題就沒這么好糊弄了。有一次我們團(tuán)隊(duì)在趕一個(gè)緊急版本的代碼審查結(jié)果主力模型突然全時(shí)段報(bào) at capacity整個(gè)開發(fā)流程卡了大半天。后來我們總結(jié)了經(jīng)驗(yàn)團(tuán)隊(duì)用模型一定要有降級(jí)方案把次優(yōu)模型配置好至少保證主干流程不中斷。3.2 模型不存在或不支持的報(bào)錯(cuò)八成是版本問題再看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這類報(bào)錯(cuò)。這兩個(gè)問題我見得特別多尤其是那些喜歡追新模型、第一時(shí)間切換新型號(hào)的開發(fā)者和團(tuán)隊(duì)。這類報(bào)錯(cuò)的原因主要有兩種一是你用的客戶端工具版本太舊不認(rèn)識(shí)新模型的名字。比如你本地裝的 Codex CLI 是三個(gè)月前的版本但模型服務(wù)商已經(jīng)發(fā)布了新模型接口不認(rèn)你傳的模型名。二是你用的模型名寫錯(cuò)了或者那個(gè)模型根本不存在。比如網(wǎng)上的信息說gpt-5.6-sol很厲害但實(shí)際上官方還沒有這個(gè)型號(hào)只有g(shù)pt-5.6你硬要傳一個(gè)帶后綴的名字服務(wù)端自然返回 404。注意當(dāng)你切換到一個(gè)新模型特別是那種帶后綴、帶版本號(hào)的命名比如-sol、-mini、-latest一定要去官方文檔確認(rèn)模型的確切名稱而不是從社交平臺(tái)的帖子里復(fù)制一個(gè)人家的配置。很多報(bào)錯(cuò)就是因?yàn)閱蝹€(gè)字符的差異導(dǎo)致的。3.3 上下文壓縮失敗的背后是長(zhǎng)任務(wù)處理的焦慮error running remote compact task: codex ran out of room in the models context這個(gè)報(bào)錯(cuò)就比較高級(jí)了。Compact 是很多 AI 編程工具的功能當(dāng)對(duì)話太長(zhǎng)超出上下文窗口時(shí)工具自動(dòng)總結(jié)之前的對(duì)話騰出空間繼續(xù)干活。如果你看到這個(gè)報(bào)錯(cuò)說明工具在壓縮上下文時(shí)失敗了模型“沒有余量”繼續(xù)執(zhí)行壓縮任務(wù)。我的理解是這個(gè)問題的本質(zhì)是模型上下文窗口利用失衡會(huì)話太長(zhǎng)工具試圖壓縮但壓縮后的內(nèi)容依然放不進(jìn)可用窗口或者壓縮操作本身需要額外的 token但已經(jīng)被用光了。處理辦法有兩個(gè)一是手動(dòng)精簡(jiǎn)會(huì)話內(nèi)容比如把無關(guān)對(duì)話清理掉再繼續(xù)二是換一個(gè)大上下文窗口的模型從根本上減少壓縮的必要性。這類報(bào)錯(cuò)還提醒我一件事上下文窗口再大也經(jīng)不住無限堆積。工作中要做“會(huì)話衛(wèi)生”該開新會(huì)話就開新會(huì)話該清理舊上下文就清理別指望模型一直背著你增加的負(fù)擔(dān)。3.4 模型 catalog 問題版本更新的連鎖反應(yīng)glm-5.3 isnt described by this versions model catalog; update claude code這類報(bào)錯(cuò)暴露了一個(gè)現(xiàn)代 AI 工具鏈的現(xiàn)實(shí)問題模型更新速度遠(yuǎn)超客戶端工具的適配速度。你本地裝著一個(gè)穩(wěn)定版工具模型服務(wù)商發(fā)布了新模型但你的工具里沒有新模型的描述于是出現(xiàn)“模型存在但工具不認(rèn)識(shí)”的尷尬情況。解決思路也很直接升級(jí)工具版本。但我遇到過更麻煩的情況工具升級(jí)后舊配置不兼容新模型導(dǎo)致更詭異的報(bào)錯(cuò)。所以我現(xiàn)在升級(jí)工具前會(huì)先看更新日志確認(rèn)模型相關(guān)的改動(dòng)再?zèng)Q定要不要升級(jí)。團(tuán)隊(duì)里有時(shí)會(huì)約定一個(gè)“保守更新”策略工具版本追進(jìn)到某一個(gè)大版本保持對(duì)當(dāng)前主力模型的穩(wěn)定支持不盲目追最新。4. 從零配置一個(gè)可用的模型工作流理論說了一堆來點(diǎn)實(shí)際的。假設(shè)你是剛開始接觸 AI 編程的新手或者想優(yōu)化現(xiàn)有工作流這套步驟是我驗(yàn)證過很多次的可用方案。4.1 第一步選好主力模型配置好 API 密鑰和基礎(chǔ)參數(shù)主力模型怎么選我給出的判斷標(biāo)準(zhǔn)很簡(jiǎn)單看你的預(yù)算和任務(wù)類型。如果你重度依賴代碼生成預(yù)算也充足首選自然是 Claude 旗艦系列代碼質(zhì)量在同類模型里很突出。如果你更依賴 OpenAI 的生態(tài)比如用 Codex 或 ChatGPT 商業(yè)版那選 GPT 系列準(zhǔn)沒錯(cuò)API 兼容性和工具鏈成熟度很高。如果你想要性價(jià)比DeepSeek 是很好的選擇代碼能力不弱價(jià)格只有旗艦?zāi)Ｐ偷囊粋€(gè)零頭特別適合個(gè)人開發(fā)者或者剛起步的創(chuàng)業(yè)團(tuán)隊(duì)。選好后配置參數(shù)時(shí)注意幾個(gè)容易出錯(cuò)的地方API 密鑰漏填或填錯(cuò)會(huì)在調(diào)用時(shí)報(bào) 401 認(rèn)證錯(cuò)誤最常見的低級(jí)錯(cuò)誤base_url 沒填對(duì)調(diào)用時(shí)才會(huì)報(bào)provider 缺少 base_url 配置這個(gè)問題在自建代理、網(wǎng)關(guān)工具時(shí)比較常見模型名沒寫對(duì)會(huì)報(bào)model does not exist。這三個(gè)基礎(chǔ)配置是排錯(cuò)時(shí)的第一檢查點(diǎn)。4.2 第二步把上下文管理做成習(xí)慣工作中用模型最核心的習(xí)慣其實(shí)是管理上下文。我給自己定了三條規(guī)則規(guī)則一問新問題前先想一下舊對(duì)話還有沒有必要。如果你的問題是全新的方向直接開新會(huì)話別在舊對(duì)話里繼續(xù)疊加。舊對(duì)話的上下文會(huì)不知不覺吃掉你的 token 預(yù)算。規(guī)則二向模型提供材料時(shí)只給相關(guān)的。有些人喜歡把整個(gè)項(xiàng)目代碼全部塞給模型指望模型自己挑重點(diǎn)。結(jié)果顯示模型不僅沒有挑出重點(diǎn)反而被無關(guān)代碼干擾了判斷。工作中做代碼審查或生成我給模型的上下文是“目標(biāo)文件 相關(guān)定義 設(shè)計(jì)文檔摘要”而不是“整個(gè)倉(cāng)庫(kù)”。規(guī)則三發(fā)現(xiàn)模型開始“遺忘”主動(dòng)精簡(jiǎn)上下文。如果你發(fā)現(xiàn)模型突然開始問你已經(jīng)提供過的問題或者輸出內(nèi)容跟之前上下文矛盾這就是上下文被稀釋的信號(hào)。這時(shí)候別繼續(xù)對(duì)話重新整理材料開新會(huì)話。4.3 第三步準(zhǔn)備一個(gè)可靠的降級(jí)方案主力模型再好總有翻車的時(shí)候。容量滿了、服務(wù)端不穩(wěn)定、API 報(bào)錯(cuò)任何一環(huán)出問題都可能卡住工作流。我的降級(jí)方案很簡(jiǎn)單本地常備一個(gè)備用模型的 API 配置平時(shí)不啟用主力出問題時(shí)一鍵切換。這個(gè)備用模型不一定是同級(jí)別的產(chǎn)品。如果你主力用 Claude 旗艦備用可以配一個(gè) DeepSeek 或者 GPT 的中端模型。任務(wù)緊急時(shí)備用模型可能完成不了最高難度的任務(wù)但至少能保證基礎(chǔ)代碼生成和文本處理不斷檔。很多團(tuán)隊(duì)喜歡“只用一家模型”我沒有這個(gè)執(zhí)念。工具是用來干活的關(guān)鍵時(shí)刻能頂上比品牌忠誠(chéng)度重要得多。4.4 第四步琢磨一下工具鏈與模型是否匹配模型不是孤立的它跑在工具鏈里。你的 CLI 工具、IDE 插件、代碼審查工具每一個(gè)都有自己的模型適配邏輯。我用過一些工具默認(rèn)只支持特定模型你想換新模型還得改配置、升級(jí)版本、甚至換工具。實(shí)際項(xiàng)目中常見的一個(gè)現(xiàn)象是你用 Claude Code 時(shí)工具內(nèi)部集成了 Anthropic 的模型路由你想強(qiáng)行換成一個(gè)不兼容的模型就會(huì)報(bào)之前提到的claude doesnt look like an anthropic model或expected a gateway model route這類錯(cuò)誤。遇到這種情況不要硬來。要么換一個(gè)原生支持你選定模型的工具要么確認(rèn)工具提供的自定義模型接口是否滿足條件。硬塞不兼容模型的結(jié)果只會(huì)是浪費(fèi)一晚上時(shí)間排查報(bào)錯(cuò)。5. 常見問題速查表與避坑經(jīng)驗(yàn)這一節(jié)我把平時(shí)積累的模型使用問題整理成速查表按場(chǎng)景分類方便你遇到問題快速定位。錯(cuò)誤現(xiàn)象常見原因快速處理model is at capacity模型負(fù)載過高換備用模型或錯(cuò)峰重試model does not exist / 404模型名拼寫錯(cuò)誤/不存在去官方文檔確認(rèn)準(zhǔn)確名稱model not supported with xxx客戶端工具不支持該模型升級(jí)工具版本或換兼容模型maximum context length exceeded輸入內(nèi)容超出上下文上限精簡(jiǎn)輸入或換大窗口模型provider 缺少 base_url 配置API 網(wǎng)關(guān)未配置補(bǔ)全 base_url 配置model catalog 版本過舊工具未適配新模型升級(jí)工具/更新模型目錄compact task failed上下文過滿、壓縮失敗開新會(huì)話、整理上下文5.1 關(guān)于“新模型焦慮”的一些個(gè)人看法還有一個(gè)想聊的點(diǎn)。我發(fā)現(xiàn)很多開發(fā)者有“新模型焦慮”看到 HN 上有人討論某個(gè)新模型性能爆炸就忍不住想切換。我的建議是沒必要。我自己有個(gè)慘痛教訓(xùn)。有一陣子一個(gè)剛發(fā)布的新模型在社交平臺(tái)上口碑很好我按捺不住切換過去結(jié)果核心任務(wù)的效果反而不如老模型穩(wěn)定。后來我發(fā)現(xiàn)問題不在模型能力而在工作流適配新模型的上下文行為、輸出格式、工具調(diào)用方式都和老模型不一樣我現(xiàn)有的提示詞和配置是為老模型調(diào)的直接套用到新模型上自然水土不服。所以換模型可以但請(qǐng)把它當(dāng)成一件需要認(rèn)真對(duì)待的事而不是“一鍵切換”的沖動(dòng)操作。我的流程是先拿幾個(gè)典型任務(wù)用同一批提示詞跑一遍對(duì)比確認(rèn)新模型確實(shí)有優(yōu)勢(shì)再小范圍切換跑幾天觀察效果最后才全面鋪開。另外在新模型效果還不確定的時(shí)候務(wù)必保留舊模型的配置方便隨時(shí)回滾。5.2 三個(gè)讓你少踩坑的小技巧最后分享三個(gè)實(shí)操小技巧都是我反復(fù)踩坑后總結(jié)出來的技巧一把所有 API 配置集中管理不要散落各處。我有一次為了調(diào)試一個(gè)問題改了三個(gè)地方的環(huán)境變量結(jié)果忘了改第四處整整排查了半天。后來我把所有 API 密鑰、模型名、base_url 統(tǒng)一放進(jìn)一個(gè)配置文件用環(huán)境變量做動(dòng)態(tài)覆蓋問題一下就少了。技巧二寫提示詞時(shí)把模型能力邊界寫進(jìn)預(yù)期里。比如你明確知道模型上下文窗口是 128k token就在任務(wù)描述里注明“只分析以下內(nèi)容忽略未提供的部分”引導(dǎo)模型專注于你給定的材料。如果你不寫模型有時(shí)候會(huì)自己腦補(bǔ)一些不存在的上下文導(dǎo)致回答質(zhì)量下降。技巧三關(guān)注模型服務(wù)商的狀態(tài)頁(yè)。遇到詭異的報(bào)錯(cuò)別急著改配置先去服務(wù)商的狀態(tài)頁(yè)看有沒有服務(wù)中斷的公告。很多時(shí)候 is at capacity、upstream request failed 這類報(bào)錯(cuò)純粹是服務(wù)端問題不是你配置的問題。清醒認(rèn)識(shí)這一點(diǎn)能節(jié)省你大量無謂的排查時(shí)間。5.3 從長(zhǎng)期角度理解模型選型再說說長(zhǎng)期視角。過去兩年模型迭代速度極快今天的最優(yōu)選擇可能三個(gè)月后就過時(shí)了。與其每次試圖“預(yù)測(cè)未來”不如建立一套能快速切換模型的機(jī)制。這就是為什么我建議從第一天就把模型名稱、上下文窗口、token 限制這些信息抽象成配置而不是硬編碼在代碼里。我見過一些團(tuán)隊(duì)的代碼里寫死了模型名比如直接調(diào)用 API 時(shí)傳model: gpt-5.6-sol后來模型升級(jí)了他們花了整整一周改代碼。而另一些團(tuán)隊(duì)用一個(gè)統(tǒng)一的模型配置層切換模型只需要改一個(gè)配置文件。兩種做法的差別在遷移成本上體現(xiàn)得淋漓盡致。所以我在實(shí)際工作中始終堅(jiān)持一個(gè)原則把“用什么模型”和“怎么用模型”兩者分離。前者是配置問題后者是業(yè)務(wù)邏輯問題。我會(huì)在代碼里抽象一層讓模型名成為可配置的參數(shù)而不是把模型名當(dāng)成業(yè)務(wù)常量。這不是過度設(shè)計(jì)在模型快速迭代的當(dāng)下這是最值得的投資。6. 我的選擇與實(shí)踐經(jīng)驗(yàn)標(biāo)題問的是“Which model do you use for work”我說了這么多也分享一下自己的實(shí)際方案。目前我的主力模型是 Claude 的旗艦系列主要在代碼生成、復(fù)雜重構(gòu)、疑難 bug 排查上使用。日常的文本處理、信息整理、輕量代碼任務(wù)我用 DeepSeek性價(jià)比高API 穩(wěn)定支持多個(gè)編程工具減輕成本壓力。另外還有 GPT 系列做補(bǔ)充主要在需要 OpenAI 特定生態(tài)的場(chǎng)景下使用。三個(gè)模型各有分工基本覆蓋了我工作中從輕量問答到重型架構(gòu)設(shè)計(jì)的全部場(chǎng)景。這個(gè)組合不是一步到位的。早期我也試圖用一個(gè)模型解決所有問題后來發(fā)現(xiàn)既要應(yīng)付又貴效果也不理想。后來慢慢迭代成現(xiàn)在的模式成本降下來了效果也提升了。選的模型不一定是最強(qiáng)的但一定是最契合自己工作流節(jié)奏的。每個(gè)人的情況不一樣建議你結(jié)合自己的預(yù)算和任務(wù)類型做匹配。如果你剛開始搭建自己的模型工作流建議先別追求“最強(qiáng)”先追求“可負(fù)擔(dān)、穩(wěn)定、順手”。把基礎(chǔ)配置做好把上下文管理做好把降級(jí)方案準(zhǔn)備好剩下的交給時(shí)間。這是一個(gè)逐步演進(jìn)的過程一次到位不現(xiàn)實(shí)但每一步都走穩(wěn)了你的工作流會(huì)越來越順暢。