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