1. 從默認(rèn)用Opus到主動(dòng)換Sonnet 5.5我的判斷依據(jù)1.1 旗艦與非旗艦的定位差異原來(lái)不是我想的那樣過(guò)去很長(zhǎng)一段時(shí)間里我主力編碼模型一直鎖定 Opus 檔位。原因很簡(jiǎn)單同一系列里Opus 是旗艦參數(shù)規(guī)模最大、推理能力最強(qiáng)凡是涉及復(fù)雜算法、框架設(shè)計(jì)和疑難 Bug 的場(chǎng)景我都會(huì)優(yōu)先丟給它。Sonnet 定位是日常均衡款主打速度和成本我默認(rèn)它只是處理簡(jiǎn)單問(wèn)答、改寫(xiě)文案這類輕活從來(lái)沒(méi)認(rèn)真測(cè)過(guò)它的代碼能力。這個(gè)認(rèn)知直到 Sonnet 5.5 上線才被打破。我最初只是在 IDE 的模型下拉菜單里順手切過(guò)去試試結(jié)果連續(xù)幾道中等偏上的算法題都被它干凈利落地解出來(lái)甚至有一道我之前用 Opus 調(diào)了三輪才跑通的動(dòng)態(tài)規(guī)劃題Sonnet 5.5 一次就給到了可運(yùn)行且邊界完整的版本。這個(gè)結(jié)果讓我不得不重新審視旗艦一定最強(qiáng)的慣性判斷。一個(gè)系列里的多個(gè)檔位本質(zhì)是同一套底層技術(shù)在不同規(guī)格下的裁切與再訓(xùn)練旗艦的強(qiáng)體現(xiàn)在綜合能力和復(fù)雜推理的上限但代碼場(chǎng)景更看重的指令遵循、工具調(diào)用和上下文利用效率完全可能出現(xiàn)非旗艦反超的情況。尤其當(dāng)一個(gè)版本號(hào)跨度足夠大時(shí)比如從舊版直接跳到 5.5中間迭代帶來(lái)的單項(xiàng)能力提升足以抹平甚至反轉(zhuǎn)檔位差距。1.2 真正讓我動(dòng)心的三個(gè)信號(hào)在決定全面切換之前我給自己定了三個(gè)觀察維度實(shí)測(cè)數(shù)據(jù)達(dá)到預(yù)期后才真正動(dòng)手改配置。第一個(gè)信號(hào)是復(fù)雜任務(wù)的一次通過(guò)率。我不看單次驚艷表現(xiàn)而是在一小時(shí)內(nèi)故意用隨機(jī)題目轟炸對(duì)比兩者在第一次回答時(shí)就給出正確、可運(yùn)行代碼的比例。Sonnet 5.5 在我隨機(jī)挑選的 12 道題里有 9 道一次通過(guò)Opus 是 7 道。雖然樣本不大但趨勢(shì)已經(jīng)很明顯。第二個(gè)信號(hào)是長(zhǎng)對(duì)話場(chǎng)景下的穩(wěn)定性。我模擬真實(shí)開(kāi)發(fā)場(chǎng)景把一個(gè)項(xiàng)目中十幾個(gè)零散的報(bào)錯(cuò)日志、需求變更記錄連續(xù)粘貼進(jìn)去問(wèn)它根據(jù)這些信息給出重構(gòu)方案。Opus 在對(duì)話中后段開(kāi)始出現(xiàn)遺忘早期上下文的情況Sonnet 5.5 卻能準(zhǔn)確引用我第 8 條消息里的關(guān)鍵約束。代碼開(kāi)發(fā)恰恰是上下文極長(zhǎng)的場(chǎng)景這一點(diǎn)對(duì)體驗(yàn)影響巨大。第三個(gè)信號(hào)更主觀但也更重要它是否理解我的潛臺(tái)詞。我會(huì)故意用口語(yǔ)化、省略主語(yǔ)的描述發(fā)需求比如這個(gè)接口限流還沒(méi)做幫我補(bǔ)上注意別影響現(xiàn)有調(diào)用方。Sonnet 5.5 能自主聯(lián)想到需要補(bǔ)充限流策略、保持入口參數(shù)兼容、補(bǔ)充異常日志而不是機(jī)械地只寫(xiě)一個(gè)限流注解。這種貼近真實(shí)協(xié)作者的理解力是讓我愿意切換的最終推手。2. 代碼能力實(shí)測(cè)Sonnet 5.5 和 Opus 硬碰硬2.1 我用的測(cè)試方法沒(méi)有花架子的實(shí)測(cè)方案為了不讓對(duì)比變成印象流我把測(cè)試分成三個(gè)固定板塊每個(gè)板塊都有明確的評(píng)分標(biāo)準(zhǔn)盡量模擬真實(shí)開(kāi)發(fā)而非腦筋急轉(zhuǎn)彎。第一個(gè)板塊是LeetCode 風(fēng)格的中高難度題覆蓋動(dòng)態(tài)規(guī)劃、圖遍歷、滑動(dòng)窗口、線段樹(shù)這些高頻考點(diǎn)。評(píng)分標(biāo)準(zhǔn)不是有沒(méi)有寫(xiě)出來(lái)而是三條硬指標(biāo)能否一次編譯通過(guò)、能否覆蓋全部邊界條件、時(shí)間復(fù)雜度是否達(dá)到題目要求的最優(yōu)解。我特意選了多道需要先建模型再實(shí)現(xiàn)的題這類題最能區(qū)分模型是背模板還是真理解。第二個(gè)板塊是真實(shí)項(xiàng)目場(chǎng)景。我把自己最近寫(xiě)的某個(gè)內(nèi)部工具項(xiàng)目拆出三個(gè)子任務(wù)把一個(gè)老舊的同步請(qǐng)求模塊改造成異步并發(fā)模式在一份 3000 行左右的代碼里定位死鎖隱患并給出修復(fù)根據(jù)新的接口文檔重寫(xiě)數(shù)據(jù)解析層。這部分沒(méi)有標(biāo)準(zhǔn)答案我只看方案是否合理、改動(dòng)是否可控、能不能直接跑通。第三個(gè)板塊是Debug 專項(xiàng)。我埋了幾個(gè)常見(jiàn)的陰間 Bug數(shù)組越界但報(bào)錯(cuò)信息不對(duì)、并發(fā)條件下偶現(xiàn)的數(shù)據(jù)錯(cuò)亂、正則表達(dá)式在極端字符下的性能退化。考察點(diǎn)不是能不能發(fā)現(xiàn) Bug而是發(fā)現(xiàn)后能否解釋根因并給出不會(huì)引入新問(wèn)題的修復(fù)方案。整套測(cè)試我花了三個(gè)晚上跑完每個(gè)模型都從冷啟動(dòng)開(kāi)始同一題目只測(cè)一次避免第二次記住答案的干擾。測(cè)試過(guò)程中我也不做任何引導(dǎo)性提示模型說(shuō)改哪就改哪完全模擬一個(gè)新手開(kāi)發(fā)者機(jī)械執(zhí)行 AI 建議的真實(shí)狀態(tài)。2.2 實(shí)測(cè)結(jié)果分項(xiàng)打分差距比我想象的還要大先給結(jié)論Sonnet 5.5 在代碼能力這個(gè)維度上以非常明顯的優(yōu)勢(shì)壓過(guò)了 Opus尤其體現(xiàn)在實(shí)現(xiàn)速度和邊界處理上。測(cè)試板塊Opus 表現(xiàn)Sonnet 5.5 表現(xiàn)我的主觀評(píng)價(jià)算法題一次通過(guò)率7/129/12Sonnet 5.5 更穩(wěn)最優(yōu)解命中率9/1210/12差距不大項(xiàng)目改造方案可落地性需要我額外修正 2 處改動(dòng)基本可直接提交Sonnet 5.5 細(xì)節(jié)更好死鎖定位準(zhǔn)確度找到了問(wèn)題但解釋含糊明確給出競(jìng)態(tài)條件分析高下立判Debug 根因定位2/3 命中3/3 命中更重要的其實(shí)是過(guò)程算法題板塊里有一個(gè)值得單獨(dú)說(shuō)的情況一道拓?fù)渑判蜃兎N題Opus 給出了正確解法但返回結(jié)果時(shí)沒(méi)有處理多個(gè)合法解的情況這在我預(yù)埋的測(cè)試用例里屬于扣分項(xiàng)。Sonnet 5.5 不僅主動(dòng)識(shí)別出存在多個(gè)合法解還在注釋里說(shuō)明了自己的輸出策略。這種主動(dòng)發(fā)現(xiàn)題目隱含歧義的能力說(shuō)實(shí)話已經(jīng)超出我對(duì)非旗艦?zāi)Ｐ偷钠诖?。?xiàng)目改造板塊的差距更刺激。異步并發(fā)改造任務(wù)里Sonnet 5.5 產(chǎn)出的代碼考慮了線程池參數(shù)的調(diào)優(yōu)依據(jù)而 Opus 給出的版本更偏教科書(shū)式的改法功能沒(méi)問(wèn)題但生產(chǎn)環(huán)境下的坑沒(méi)避開(kāi)。這項(xiàng)對(duì)比讓我徹底確認(rèn)代碼能力的比較不能只看會(huì)不會(huì)寫(xiě)更要看是否具備工程直覺(jué)。2.3 為什么 Sonnet 5.5 能反超技術(shù)層面的幾點(diǎn)推測(cè)雖然拿不到內(nèi)部實(shí)現(xiàn)細(xì)節(jié)但從表現(xiàn)反推原因大概有三個(gè)方向第一訓(xùn)練側(cè)重可能做了調(diào)整。新一代模型明顯在代碼生成、工具調(diào)用類任務(wù)上做了專項(xiàng)優(yōu)化這類數(shù)據(jù)在訓(xùn)練語(yǔ)料里的占比和權(quán)重可能已經(jīng)壓過(guò)通用知識(shí)。一個(gè)直接證據(jù)是Sonnet 5.5 在代碼問(wèn)答上的回答風(fēng)格明顯更結(jié)構(gòu)化——它傾向于先給方案概覽再給實(shí)現(xiàn)代碼最后補(bǔ)測(cè)試用例而不是像通用問(wèn)答那樣一股腦輸出。第二推理時(shí)長(zhǎng)的分配策略變了。我實(shí)測(cè)發(fā)現(xiàn)Sonnet 5.5 在復(fù)雜問(wèn)題上的響應(yīng)并不比 Opus 快多少說(shuō)明它把時(shí)間花在了內(nèi)部推理鏈路上。大概率是慢思考機(jī)制在非旗艦?zāi)Ｐ蜕弦灿辛烁玫母采w。這也是為什么它在邊界條件、隱含歧義這類需要多想一步的場(chǎng)景上表現(xiàn)更好。第三架構(gòu)層面的優(yōu)化收益常常最先體現(xiàn)在中等規(guī)模模型上。小模型不夠復(fù)雜體現(xiàn)不出新機(jī)制的收益旗艦?zāi)Ｐ褪苤朴诠こ虖?fù)雜度和成本新技術(shù)的落地節(jié)奏反而更謹(jǐn)慎。Sonnet 5.5 恰好處在規(guī)模足夠大、更新足夠激進(jìn)的甜蜜點(diǎn)吃到了一波架構(gòu)紅利。說(shuō)到底模型能力從來(lái)不是簡(jiǎn)單的線性排行版本迭代和專項(xiàng)調(diào)優(yōu)帶來(lái)的變量足以讓次旗艦反超旗艦成為一個(gè)正?，F(xiàn)象。這也提醒我做選型不能只看檔位名稱必須回到自己的核心使用場(chǎng)景里去實(shí)測(cè)。3. 切換后的日常工作流哪些場(chǎng)景收益最大3.1 我實(shí)際用得最爽的幾個(gè)高頻場(chǎng)景切換成 Sonnet 5.5 已經(jīng)幾周日常工作流基本沒(méi)有為這個(gè)改變付出額外成本反而明顯輕松了不少。最爽的場(chǎng)景集中在以下五個(gè)第一個(gè)是IDE 內(nèi)的實(shí)時(shí)補(bǔ)全。之前用 Opus 做行級(jí)補(bǔ)全總有一種殺雞用牛刀的笨重感偶爾還會(huì)因?yàn)槟Ｐ吞髮?dǎo)致補(bǔ)全等待時(shí)間過(guò)長(zhǎng)。Sonnet 5.5 的響應(yīng)節(jié)奏更跟手補(bǔ)全內(nèi)容的命中率也更高尤其在 Python 和 TypeScript 這種語(yǔ)法糖多的語(yǔ)言里它給出的代碼風(fēng)格更貼近我現(xiàn)有代碼庫(kù)的寫(xiě)法。第二個(gè)是代碼審查。我每次提 MR 前會(huì)把 diff 丟給它讓它從可讀性、性能隱患、邊界缺失、日志合理性四個(gè)維度挑問(wèn)題。Sonnet 5.5 給出的意見(jiàn)更尖銳甚至?xí)驗(yàn)槲覜](méi)寫(xiě)空指針保護(hù)直接提出質(zhì)疑。這種敢挑刺的風(fēng)范正是審查工具最需要的。第三個(gè)是批量寫(xiě)測(cè)試用例。這個(gè)場(chǎng)景非?？菰锏珮O其重要Sonnet 5.5 能根據(jù)已有函數(shù)自動(dòng)生成覆蓋正常路徑、異常路徑、邊界值的整套測(cè)試生成速度比 Opus 快約 20%并且會(huì)主動(dòng)補(bǔ)充我容易遺漏的負(fù)數(shù)、空數(shù)組這類 case。第四個(gè)是跨語(yǔ)言遷移。把一段 Java 代碼翻譯成 Go 語(yǔ)言同時(shí)保留原有并發(fā)語(yǔ)義——這種任務(wù)最怕模型機(jī)械直譯。Sonnet 5.5 會(huì)主動(dòng)重構(gòu)出更符合 Go 習(xí)慣的 goroutine 和 channel 模式而不是逐行照搬。這背后其實(shí)是理解意圖和掌握目標(biāo)語(yǔ)言慣例雙重能力的體現(xiàn)。第五個(gè)是長(zhǎng)對(duì)話需求梳理。當(dāng)我把產(chǎn)品需求文檔、會(huì)議記錄、技術(shù)債清單一股腦丟進(jìn)去讓它拆解成開(kāi)發(fā)任務(wù)列表時(shí)Sonnet 5.5 的輸出結(jié)構(gòu)清晰度更好任務(wù)拆解顆粒度也恰到好處——既不會(huì)碎成上百條流水賬也不會(huì)粗到無(wú)法執(zhí)行。3.2 哪些場(chǎng)景還是建議保留 Opus當(dāng)然切換不是一刀切。在我這幾周的并行測(cè)試?yán)锎_實(shí)有幾個(gè)場(chǎng)景 Opus 依然更合適。最突出的是高度抽象的系統(tǒng)設(shè)計(jì)討論。比如如果讓你從零設(shè)計(jì)一套支持千萬(wàn)級(jí)連接的消息推送架構(gòu)Opus 給出的方案在系統(tǒng)邊界劃分、容量評(píng)估、演進(jìn)路線上的思考確實(shí)更完整更像一份架構(gòu)評(píng)審文檔Sonnet 5.5 雖然也能答但更偏向給個(gè)可落地方案少了一點(diǎn)全局視野。其次是開(kāi)放域知識(shí)推理。代碼之外的通用問(wèn)題比如技術(shù)選型分析、論文思路拆解、職業(yè)規(guī)劃討論Opus 的表達(dá)質(zhì)量和思維深度仍然占優(yōu)。這說(shuō)明兩者的訓(xùn)練目標(biāo)已經(jīng)出現(xiàn)了明顯分化——Sonnet 5.5 更像專業(yè)助手Opus 更像通才大腦。還有一個(gè)細(xì)節(jié)場(chǎng)景當(dāng)代碼問(wèn)題涉及業(yè)務(wù)上下文時(shí)。我會(huì)先給 Opus 完整的業(yè)務(wù)背景再問(wèn)設(shè)計(jì)問(wèn)題它更擅長(zhǎng)把非技術(shù)因素利益相關(guān)方、迭代節(jié)奏、團(tuán)隊(duì)能力納入技術(shù)方案里。Sonnet 5.5 更聚焦純代碼層面偶爾會(huì)給出技術(shù)上最優(yōu)但團(tuán)隊(duì)接不住的方案。所以我的最終配置是IDE 寫(xiě)代碼、改 Bug、寫(xiě)測(cè)試、Code Review 這些高頻操作全部走 Sonnet 5.5遇到架構(gòu)設(shè)計(jì)和跨領(lǐng)域思考我還是會(huì)手動(dòng)切回 Opus。兩個(gè)模型配合使用比單押任何一個(gè)都穩(wěn)。3.3 響應(yīng)速度和成本賬算下來(lái)省了不少除了能力日常使用還有一筆必須算清楚的賬成本和速度。我這次特意把 API 調(diào)用日志拉出來(lái)做了一組統(tǒng)計(jì)。先說(shuō) Token 消耗。同樣一個(gè)代碼重構(gòu)任務(wù)Opus 往往輸出更多解釋性文字而 Sonnet 5.5 更傾向直接給精簡(jiǎn)方案加代碼最終總 Token 大約能省 18% 到 25%?？紤]到它的單價(jià)遠(yuǎn)低于旗艦檔位折算成實(shí)際費(fèi)用同一任務(wù)成本大概只有原來(lái)的一半多點(diǎn)。再說(shuō)響應(yīng)速度。在相近配置下Sonnet 5.5 的平均首 Token 延遲快 30% 左右但復(fù)雜任務(wù)的總耗時(shí)反而和 Opus 相差不大這說(shuō)明它在想的階段多花了一點(diǎn)時(shí)間收尾階段更利落。對(duì)一個(gè)高頻寫(xiě)代碼的人來(lái)說(shuō)這種體感差異非常明顯——補(bǔ)全不再卡頓長(zhǎng)篇生成的等待焦慮也基本消失了。還有一點(diǎn)容易被忽視上下文緩存命中率。我反復(fù)測(cè)試后發(fā)現(xiàn)Sonnet 5.5 在多輪對(duì)話中對(duì)早期信息的二次利用效率更好相同長(zhǎng)度的對(duì)話上下文里它很少讓我重復(fù)強(qiáng)調(diào)前提。這不僅節(jié)省 Token更重要的是減少了你以為它記住了、其實(shí)早忘了的溝通損耗。4. 從 Opus 切換到 Sonnet 5.5 的實(shí)操手冊(cè)4.1 工具鏈里的正確接入方式切換不是一個(gè)改個(gè)下拉菜單那么簡(jiǎn)單的事尤其當(dāng)你同時(shí)使用 IDE 插件、命令行工具和自有腳本時(shí)需要保證三處配置一致否則會(huì)出現(xiàn)IDE 里是 5.5腳本里還是舊模型的混亂。我目前的技術(shù)棧配置方案如下可以直接參考IDE 插件場(chǎng)景把默認(rèn)模型名改成sonnet-5.5同時(shí)把自動(dòng)補(bǔ)充對(duì)話上下文這個(gè)開(kāi)關(guān)打開(kāi)讓它每次請(qǐng)求自動(dòng)帶上最近若干條消息。這兩個(gè)配置缺一不可只改模型名不改上下文策略長(zhǎng)對(duì)話體驗(yàn)會(huì)大打折扣。命令行 CLI 場(chǎng)景我習(xí)慣用腳本封裝 API 請(qǐng)求在配置中心里統(tǒng)一維護(hù)模型名和溫度參數(shù)。重點(diǎn)提醒多個(gè)腳本文件不要各自硬編碼模型名統(tǒng)一從環(huán)境變量讀取切換時(shí)只改一處。自有應(yīng)用場(chǎng)景如果你的應(yīng)用同時(shí)對(duì)接多個(gè)模型一定要設(shè)計(jì)一層模型路由。我目前的路由規(guī)則是代碼任務(wù)默認(rèn)走 Sonnet 5.5架構(gòu)設(shè)計(jì)類問(wèn)題走 Opus簡(jiǎn)單格式化走更輕量的檔位。這層路由可以是一個(gè)簡(jiǎn)單的規(guī)則函數(shù)核心是讓模型選擇自動(dòng)化而不是每次手動(dòng)改。接入完成后別急著全面切換先跑一遍自己的核心用例確認(rèn)模型名、參數(shù)、上下文策略都生效了再逐步放大使用范圍。我見(jiàn)過(guò)太多人一次性全面切換結(jié)果某個(gè)腳本里還是舊配置排查半天。4.2 漸進(jìn)式切換的三個(gè)步驟我自己的切換節(jié)奏是三步走既不耽誤工作又能充分驗(yàn)證效果。第一步是影子模式。保持 Opus 為默認(rèn)模型但同時(shí)在 IDE 里把 Sonnet 5.5 開(kāi)啟為備選。每次遇到具體代碼任務(wù)時(shí)我會(huì)讓兩個(gè)模型各答一遍對(duì)比輸出質(zhì)量。這個(gè)過(guò)程大約持續(xù)兩到三天核心目的是建立信心——更準(zhǔn)確地說(shuō)是積累足夠多的它確實(shí)更好的證據(jù)而不是憑一兩次驚艷表現(xiàn)做決定。第二步是低風(fēng)險(xiǎn)場(chǎng)景切換。先從測(cè)試用例生成、日志分析、簡(jiǎn)單 Bug 修復(fù)、代碼格式化這些最壞情況只是多改兩行的任務(wù)開(kāi)始全面改用 Sonnet 5.5。這類任務(wù)即使出現(xiàn)輸出偏差損失也可控適合用來(lái)摸清它的脾氣。我在這個(gè)階段發(fā)現(xiàn)了一個(gè)重要規(guī)律它對(duì)需求描述的敏感度比 Opus 更高描述不清時(shí)會(huì)自己追問(wèn)而不是瞎猜。第三步才是核心開(kāi)發(fā)場(chǎng)景切換。算法實(shí)現(xiàn)、模塊重構(gòu)、復(fù)雜 Debug 這些直接影響交付質(zhì)量的工作在解決完第二步暴露的問(wèn)題后逐步遷入。這個(gè)階段我會(huì)持續(xù)盯一周的改動(dòng)提交記錄確認(rèn)沒(méi)有出現(xiàn)模型建議引入新問(wèn)題的情況才徹底完成切換。4.3 新手最容易踩的幾個(gè)坑切換過(guò)程中我踩過(guò)一些坑整理出來(lái)給大家避避雷。第一個(gè)坑是忘了調(diào)整提示詞。很多人以為換成新模型原有的提示詞模板可以原封不動(dòng)繼續(xù)用。實(shí)際上不同模型的指令偏好差異不小。Sonnet 5.5 對(duì)結(jié)構(gòu)化指令的響應(yīng)更好比如要求它先列出問(wèn)題清單再給出解決方案時(shí)輸出會(huì)規(guī)整得多如果你給的指令過(guò)于開(kāi)放它的輸出反而會(huì)偏簡(jiǎn)短少了深度打磨的過(guò)程。第二個(gè)坑是上下文長(zhǎng)度配置沒(méi)跟上。Sonnet 5.5 支持很長(zhǎng)的上下文窗口但如果你在 API 調(diào)用里手動(dòng)把max_tokens設(shè)得偏小長(zhǎng)任務(wù)很容易被截?cái)?。我之前就因?yàn)檠赜门f配置導(dǎo)致兩次長(zhǎng)代碼生成都在 70% 處突然斷掉一度以為模型被降智了。檢查配置后立刻恢復(fù)正常。第三個(gè)坑是跨任務(wù)的隱性污染。在 IDE 里用過(guò)一段時(shí)間后模型可能會(huì)被同一個(gè)會(huì)話里早期不相關(guān)的話題干擾。我建議在開(kāi)啟新任務(wù)時(shí)主動(dòng)開(kāi)新會(huì)話不要圖方便在一個(gè)對(duì)話框里連續(xù)處理多個(gè)毫不相關(guān)的任務(wù)。這個(gè)習(xí)慣在長(zhǎng)上下文模型上尤其重要。第四個(gè)坑是盲目追求全切。通過(guò)上面的實(shí)測(cè)你應(yīng)該也看出來(lái)了Sonnet 5.5 并非全面碾壓在架構(gòu)設(shè)計(jì)類任務(wù)上 Opus 依然有優(yōu)勢(shì)。如果因?yàn)榇a能力強(qiáng)就全線替換反而會(huì)在部分場(chǎng)景損失體驗(yàn)。正確的做法是構(gòu)建模型路由而不是做單選題。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 常見(jiàn)問(wèn)題速查表切換這段時(shí)間我把社區(qū)里討論最多和自己實(shí)際遇到的問(wèn)題整理成了一張速查表邏輯上先看現(xiàn)象再看排查方向最后給方案。問(wèn)題現(xiàn)象排查思路解決辦法Sonnet 5.5 輸出質(zhì)量不穩(wěn)定看看是不是開(kāi)了多個(gè)會(huì)話上下文被污染開(kāi)新會(huì)話單任務(wù)單會(huì)話響應(yīng)變慢且結(jié)果變差檢查 API 配置里是否殘留舊模型參數(shù)統(tǒng)一從配置中心讀取模型名清理硬編碼補(bǔ)全內(nèi)容風(fēng)格與代碼庫(kù)不一致沒(méi)在提示詞里提供項(xiàng)目代碼風(fēng)格示例在系統(tǒng)提示詞中追加 2-3 個(gè)風(fēng)格示例長(zhǎng)任務(wù)生成到一半截?cái)鄊ax_tokens上限設(shè)置過(guò)小調(diào)整到目標(biāo)輸出長(zhǎng)度上限的 1.5 倍代碼審查漏報(bào)明顯問(wèn)題沒(méi)給審查維度清單明確要求按四個(gè)維度逐項(xiàng)審查而不是開(kāi)放輸出與舊腳本返回格式不兼容API 返回的 JSON 字段可能調(diào)整用 jq 或腳本做好字段兼容先跑通示例再上線這里最想強(qiáng)調(diào)的還是第一行上下文污染。它可以說(shuō)是所有明明模型很強(qiáng)但輸出很蠢現(xiàn)象的頭號(hào)解釋。尤其是 IDE 的自動(dòng)補(bǔ)全場(chǎng)景一個(gè)會(huì)話里往往混入了大量無(wú)關(guān)文件內(nèi)容模型需要從中甄別相關(guān)信息遺漏和誤判自然增多。5.2 幾個(gè)細(xì)節(jié)很多人會(huì)直接忽略除了上面這張表還有三個(gè)容易忽略的細(xì)節(jié)值得單獨(dú)說(shuō)一說(shuō)。第一個(gè)是溫度參數(shù)的差異感知。代碼生成任務(wù)我強(qiáng)烈建議把溫度保持在 0 到 0.2 之間一旦超過(guò) 0.5模型輸出的創(chuàng)造性會(huì)明顯增強(qiáng)但代碼里的創(chuàng)造性往往意味著不穩(wěn)定的格式和跳脫的邏輯。Sonnet 5.5 在低溫下的穩(wěn)定性特別好這也是它在代碼場(chǎng)景表現(xiàn)優(yōu)異的原因之一。第二個(gè)是緩存預(yù)熱的作用。如果你每天都要處理大量代碼任務(wù)建議先用幾個(gè)高頻需求把 API 的上下文緩存熱起來(lái)實(shí)際使用中我發(fā)現(xiàn)緩存命中后的響應(yīng)速度提升非常明顯尤其是在重復(fù)處理同一個(gè)項(xiàng)目的后續(xù)修改時(shí)整個(gè)體驗(yàn)會(huì)順滑一個(gè)檔次。第三個(gè)是保持對(duì)版本的敏感度。這一代 Sonnet 5.5 代碼強(qiáng)不代表下一代依然如此。我的習(xí)慣是每?jī)芍芑ㄒ恍r(shí)用固定測(cè)試題集重新跑一遍主力模型的對(duì)比檢查它是否依然在自己的核心場(chǎng)景里保持領(lǐng)先。把選型變成一個(gè)周期性動(dòng)作而不是一勞永逸的決策。5.3 我的最終使用策略供參考繞了一大圈最后分享一下我現(xiàn)在實(shí)際在用的配置方案。不算標(biāo)準(zhǔn)答案但至少折騰過(guò)一段時(shí)間踩過(guò)坑參考價(jià)值還是有。我現(xiàn)在的規(guī)則是項(xiàng)目里 80% 的代碼開(kāi)發(fā)任務(wù)直接交給 Sonnet 5.5包括寫(xiě)函數(shù)、改模塊、調(diào) Bug、生成測(cè)試剩下 20% 涉及系統(tǒng)架構(gòu)、跨模塊設(shè)計(jì)、疑難算法選型的任務(wù)我會(huì)切回 Opus。判斷依據(jù)很簡(jiǎn)單——如果我需要的是把活干完選 Sonnet 5.5如果我需要的是把問(wèn)題想透選 Opus。工具鏈方面我在 IDE 里默認(rèn)模型設(shè)置為 Sonnet 5.5在命令行工具里寫(xiě)了一個(gè)簡(jiǎn)單的路由腳本根據(jù)問(wèn)題關(guān)鍵詞自動(dòng)選擇模型。比如檢測(cè)到系統(tǒng)設(shè)計(jì)架構(gòu)選型CAP這些詞時(shí)自動(dòng)路由到 Opus其余代碼問(wèn)題全部走 Sonnet 5.5。成本上這個(gè)策略里同一月活相比之前全部使用 Opus大概省了 40% 左右的 API 費(fèi)用。最后再分享一個(gè)小技巧如果你不確定某個(gè)模型適不適合自己的核心業(yè)務(wù)不要直接在生產(chǎn)環(huán)境切換而是翻出過(guò)去一個(gè)月你處理過(guò)的最難的 10 個(gè)代碼任務(wù)做成測(cè)試集用這個(gè)固定集合去批量驗(yàn)證。這是我現(xiàn)在做任何模型選型評(píng)估的標(biāo)準(zhǔn)動(dòng)作比看任何榜單都靠譜。