Codex 這次把 Composer 預(yù)測搬出來我先說結(jié)論這不是一個(gè)讓你省幾次點(diǎn)擊的小按鈕而是把“生成式工作流的并行能力”往前推了一大步。尤其是經(jīng)常在 Composer 里做多文件修改、批量生成、重構(gòu)的人這個(gè)功能的體驗(yàn)差異會非常明顯。它解決的核心問題是當(dāng)你的意圖還模糊時(shí)AI 不該傻等指令而是應(yīng)該提前給出幾條可能的路徑讓你像翻卡片一樣迅速鎖定下一步。這篇文章我會從產(chǎn)品定位、內(nèi)部機(jī)制、實(shí)操調(diào)參、問題排查這幾個(gè)角度展開最后再說一點(diǎn)我自己的使用體會。內(nèi)容主要面向已經(jīng)在使用 AI 編程工具、想把手頭 Composer 類工作流做得更順手的開發(fā)者如果你只是偶爾用它改個(gè)文本、補(bǔ)一段代碼也可以看前面兩部分理解它到底在預(yù)測什么。1. 我眼中的 Composer 預(yù)測目標(biāo)、背景與定位1.1 當(dāng)“預(yù)測”實(shí)際上指的是什么先說個(gè)容易誤會的地方。Composer 預(yù)測并不是“AI 猜你想要輸入什么字符”也不是編輯器的自動補(bǔ)全。它在 Codex 里的角色更像是一個(gè)“意圖分流器”當(dāng)你把需求寫進(jìn) Composer 的輸入欄或者選中一段代碼準(zhǔn)備修改時(shí)預(yù)測系統(tǒng)會先基于當(dāng)前上下文生成多條完整候選路徑每一條都可能包含多個(gè)文件的改動、測試用例、遷移腳本甚至是重構(gòu)方案。這些候選路徑不是憑空出現(xiàn)的。預(yù)測模型會把 Composer 里已有的會話歷史、項(xiàng)目結(jié)構(gòu)、最近的編輯動作、代碼風(fēng)格偏好全部壓縮成一個(gè)“意圖表示”再在這個(gè)表示上做分支生成。你可以把 Composer 當(dāng)作一張畫布左邊是需求描述右邊是文件樹和變更預(yù)覽中間穿插著對話上下文。預(yù)測系統(tǒng)做的就是在這張畫布上“提前畫幾條你可能要走的線”。為什么這有實(shí)際價(jià)值因?yàn)閭鹘y(tǒng) AI 編程助手是“一問一答”的串行模式——你得先輸入需求等它生成不滿意再改需求再等生成。這個(gè)過程里人和模型都在空轉(zhuǎn)。預(yù)測模式則嘗試把串行改成“一次多候補(bǔ)”模型一次給你 3 到 5 條候選路徑你先過濾再下鉆。這更像搜索引擎的行為邏輯而不是聊天機(jī)器人的邏輯。1.2 Pro 用戶在這個(gè)功能上得到的額外價(jià)值我理解很多人會問為什么這個(gè)功能要先給 Pro 用戶表面上這是商業(yè)策略但你要是站在資源消耗的角度看預(yù)測功能的成本結(jié)構(gòu)完全不同于普通走查對話——它不是僅僅運(yùn)行一次“輸入-輸出”而是在用戶確認(rèn)之前就要生成多個(gè)候選分支并且每一輪修改都可能觸發(fā)重新預(yù)測。打個(gè)比方普通生成像是去飯店點(diǎn)菜你點(diǎn)一份廚房做一份預(yù)測模式則像是自助餐后廚把五道菜同時(shí)備好等你挑一道端走剩下的就得當(dāng)損耗處理。這份“損耗”在算力和模型調(diào)用上都是實(shí)打?qū)嵉乃苑旁?Pro 層級里沒有任何毛病。Pro 用戶在這個(gè)功能上能拿到的核心價(jià)值是三層的第一層是時(shí)間節(jié)省多候選路徑省去反復(fù)修改 prompt 的周期第二層是決策質(zhì)量幾條候選路徑放在一起對比比只看單次生成更容易判斷全局利弊第三層是審計(jì)友好Composer 預(yù)測會把每次候選都標(biāo)記成“未提交的草稿”你可以在不污染主工作區(qū)的前提下做剝離和選擇。我得提醒一句預(yù)測功能的收益不是普適的。它更適合那些工作流相對穩(wěn)定、代碼模式重復(fù)度比較高的任務(wù)比如 CRUD 代碼生成、接口 mock、批量改文案、樣式遷移。相反如果你每一次面對的都是前所未見的需求預(yù)測更像是在大海撈針生成的候選路徑可能全都偏離你的真實(shí)意圖。這種情況我后面會專門講排查辦法。2. 核心機(jī)制拆解一次操作如何變成一條預(yù)測鏈2.1 意圖捕捉與候選排序Composer 預(yù)測能跑起來首先依賴的是“意圖捕捉”這一步。聽起來玄拆開看其實(shí)是一套很古典的 NLP 管線只不過從規(guī)則匹配換成了模型推理。意圖捕捉的輸入主要有三類Composer 里的最新指令自然語言或代碼片段;當(dāng)前選中的代碼塊、光標(biāo)位置以及最近 5 到 10 次的編輯行為項(xiàng)目內(nèi)的標(biāo)簽系統(tǒng)比如用戶在 Composer 里手動標(biāo)注過的 TODO、需求標(biāo)簽、版本分支等。系統(tǒng)會把這些輸入合成一個(gè)意圖向量然后基于這個(gè)向量去檢索項(xiàng)目歷史和用戶的使用習(xí)慣。檢索結(jié)果不是直接拿來用的它會進(jìn)入一個(gè)“意圖沖突檢測”模塊如果用戶最近剛寫了一段與候選路徑方向相反的代碼模型會降低對應(yīng)候選的優(yōu)先級。候選排序遵循三條規(guī)則我按重要程度排一下與當(dāng)前編輯上下文的重疊度候選路徑改動過的文件是否正好是你正在操作的文件與用戶歷史偏好的匹配度比如你過去是優(yōu)先寫測試還是優(yōu)先改實(shí)現(xiàn)預(yù)測會跟著傾斜資源消耗的合理性同等置信度下改動范圍更小的候選排在前面。這個(gè)排序機(jī)制直接決定了你打開預(yù)測面板時(shí)第一眼看到的候選是不是可用的。我見過不少用戶說“預(yù)測出來的東西根本不能用”大多數(shù)時(shí)候不是模型不行而是他們對上下文做了不合理的暗示比如在 Composer 里堆了大量過期注釋導(dǎo)致意圖向量被噪聲污染。2.2 上下文預(yù)算與緩存淘汰預(yù)測是昂貴的所以 Codex 內(nèi)部必須給預(yù)測分配“預(yù)算”。這個(gè)預(yù)算不是按時(shí)間算而是按 token 和分支數(shù)算。我可以給一個(gè)非常粗略的參考模型幫你理解它背后的計(jì)算邏輯。假設(shè)預(yù)測啟動時(shí)系統(tǒng)需要為每條候選生成大約 20 個(gè) token 的變更摘要加上文件 diff 的預(yù)估 token平均每個(gè)候選項(xiàng)大約吃掉 120 個(gè) token。如果你同時(shí)生成 3 條候選單次預(yù)測的 token 消耗就在 360 個(gè)左右。而一次核驗(yàn)把候選落到工作區(qū)并重新編譯可能要花掉 800 個(gè) token。如果不做限制預(yù)測功能會在你還沒做任何確認(rèn)前就燒掉大量上下文窗口。Codex 的解決方案是給預(yù)測結(jié)果加“緩存生命周期”每條候選生成后并不是永久保留而是按活躍度排序一旦超過保留窗口比如 15 分鐘沒有交互就可能被逐出緩存。逐出優(yōu)先級取決于候選的存活概率也就是它是否仍然被當(dāng)前工作區(qū)引用。這個(gè)設(shè)計(jì)背后有一個(gè)很現(xiàn)實(shí)的考慮用戶可以讓預(yù)測結(jié)果掛在那里但模型不會無限維護(hù)這些分支。2.3 為什么選擇“延遲提交”而不是“實(shí)時(shí)執(zhí)行”這是我認(rèn)為整個(gè)預(yù)測設(shè)計(jì)里最值得玩味的地方。預(yù)測系統(tǒng)完全可以做成“實(shí)時(shí)執(zhí)行”生成候選路徑后立刻把修改應(yīng)用到文件系統(tǒng)用戶看到的就是改完了的效果。這樣做的好處是即時(shí)反饋壞處是災(zāi)難性的——如果用戶的意圖判斷出錯整個(gè)工作區(qū)會被一堆不想要的改動淹沒。Codex 選擇了“延遲提交”模式候選路徑生成后只存在于一個(gè)隔離層里叫“預(yù)測草稿區(qū)”。這個(gè)草稿區(qū)不在 Git 的工作區(qū)里也不影響編譯輸出的中間文件它是模型運(yùn)行期內(nèi)的一塊內(nèi)存狀態(tài)。你要手動把某一條候選確認(rèn)合并它才會落盤。延遲提交的代價(jià)是感知上的“卡一下”。用戶在預(yù)測面板里點(diǎn)選了一條候選Composer 不會立刻顯示文件變動而是要等模型把這整條候選路徑中的每個(gè) diff 逐個(gè)應(yīng)用到真實(shí)工作區(qū)。這個(gè)過程跟實(shí)時(shí)執(zhí)行相比多了一次序列化和落盤的等待。我在實(shí)際使用中這個(gè)等待通常在幾秒到十幾秒之間取決于候選涉及的文件數(shù)量和改動深度。但為了撤銷安全性和可審計(jì)性這幾秒鐘是值得的。延遲提交讓所有預(yù)測改動都保持“可回滾”的狀態(tài)你隨時(shí)可以把草稿區(qū)里的內(nèi)容一鍵清空并把工作區(qū)還原到上一個(gè)存檔點(diǎn)。這種設(shè)計(jì)本質(zhì)上是在“即時(shí)反饋”和“操作安全”之間選了后者我認(rèn)同這個(gè)取舍因?yàn)閷﹂_發(fā)者來說誤操作造成的時(shí)間損失遠(yuǎn)比幾秒延遲要大。3. 實(shí)操要點(diǎn)從打開開關(guān)到形成自己的工作流3.1 第一步開啟預(yù)測并按項(xiàng)目調(diào)整閾值官方文檔里會說功能怎么開但我更想說清楚閾值參數(shù)該怎么理解。Composer 預(yù)測面板里有一個(gè)重要的滑桿參數(shù)叫“置信度閾值”默認(rèn)值是 0.78。它的含義是候選路徑的預(yù)測置信度要達(dá)到 78% 才會顯示出來。我之前一直沒搞明白這個(gè)值的意義直到有一次把閾值調(diào)到 0.65預(yù)測面板瞬間多出一堆莫名其妙的分支比如“把這段代碼拆成兩個(gè)文件”“順手升級依賴版本”什么的。這些改動放到通用場景下可能是合理的但對于我當(dāng)時(shí)正在做的局部修復(fù)來說就是徹頭徹尾的干擾。調(diào)回去才發(fā)現(xiàn)閾值本質(zhì)上是在幫你控制“預(yù)測的發(fā)散程度”。按我現(xiàn)在的習(xí)慣按項(xiàng)目類型給參考值項(xiàng)目類型建議閾值理由嚴(yán)格維護(hù)中的老項(xiàng)目0.85 以上任何多余的改動都可能引發(fā)回歸老 bug寧可少預(yù)測新項(xiàng)目原型開發(fā)0.65 到 0.75允許模型發(fā)散能提供一些沒想到的路徑重構(gòu)類任務(wù)0.75 到 0.82既要保證方向一致也要給結(jié)構(gòu)變化留出空間批量機(jī)械調(diào)整0.82 到 0.88不期望模型發(fā)揮創(chuàng)造性只要穩(wěn)定復(fù)現(xiàn)模式這個(gè)表不是標(biāo)準(zhǔn)答案但你可以在自己項(xiàng)目里試幾組值記錄下“有效候選 / 總候選”的比例找到你自己的拐點(diǎn)。3.2 第二步用標(biāo)簽明確落點(diǎn)降低誤觸率預(yù)測系統(tǒng)最大敵人是歧義。Composer 里你只說一句“優(yōu)化這個(gè)頁面的性能”預(yù)測系統(tǒng)可能不知道該把重心放在“減少請求合并”“做本地緩存”還是“OCR 圖片懶加載”。為了避免這種歧義我強(qiáng)烈建議在 Composer 里啟用“落點(diǎn)標(biāo)簽”。什么是落點(diǎn)標(biāo)簽就是給預(yù)測指令加一個(gè)限定詞讓它知道你要進(jìn)入的領(lǐng)域或約束。比如“優(yōu)化頁面性能【只能改渲染層】”“把這段接口遷移到新版 SDK【不破壞既有調(diào)用】”“修復(fù)登錄 bug保持原有 UI 不變”。預(yù)測系統(tǒng)會優(yōu)先把候選路徑收斂到標(biāo)簽限定的范圍內(nèi)。我實(shí)測下來的效果非常明顯加入落點(diǎn)標(biāo)簽之后有效的候選路徑占比能從六成左右提高到八成以上尤其是在跨文件改動多的時(shí)候。不需要把標(biāo)簽寫得很長我一般控制在 8 到 15 個(gè)字之內(nèi)。太長會讓意圖向量里塞滿冗余信息反而稀釋核心語義。3.3 第三步與已有分支管理配合Composer 預(yù)測的草稿區(qū)和 Git 分支是兩層?xùn)|西但兩者會互相影響。當(dāng)你切換 Git 分支時(shí)預(yù)測草稿區(qū)不會自動清空而是繼續(xù)保留在原地如果你在另一個(gè)分支上確認(rèn)了預(yù)測內(nèi)容Composer 會創(chuàng)建一個(gè)新的基準(zhǔn)點(diǎn)來記錄這次確認(rèn)。我建議你在到崗拿到一個(gè)新需求時(shí)先切新分支再開啟預(yù)測面板。這樣做的原因是預(yù)測系統(tǒng)會讀取當(dāng)前分支的上下文如果分支歷史里已經(jīng)有大量未完成改動預(yù)測結(jié)果很容易被這些半成品代碼帶偏。干凈的分支能給預(yù)測模型一個(gè)更明確的起點(diǎn)。另外預(yù)測確認(rèn)后最好立即提交一個(gè)“快照提交”把預(yù)測產(chǎn)生的改動固定下來。這不算 Git 的最佳實(shí)踐但在這個(gè)場景下它很實(shí)用預(yù)測系統(tǒng)的草稿區(qū)是內(nèi)存態(tài)如果進(jìn)程崩潰或你誤操作關(guān)閉了工作區(qū)所有未確認(rèn)的預(yù)測會全部消失而快照提交能讓你有個(gè)兜底。3.4 參數(shù)示例估算一次預(yù)測的實(shí)際開銷很多人關(guān)心預(yù)測到底會消耗多少 token會不會把上下文窗口撐爆。我拿一個(gè)典型場景來做估算。假設(shè)你要讓 Composer 為一個(gè)新接口同時(shí)生成“控制器方法、單元測試、接口文檔三段改動”。預(yù)測系統(tǒng)會先做一次意圖分析消耗大約 300 到 400 token隨后生成 4 條候選路徑每條路徑中包含完整的 diff 和變更描述平均每條 800 token總計(jì) 3200 token最后啟動一次輕量核驗(yàn)對候選路徑做語法檢查消耗約 500 token。這樣一次完整預(yù)測流程下來總消耗在 4000 token 左右。對比傳統(tǒng)串行模式你可能要經(jīng)歷“生成控制器、看到問題、重新提示、再生成測試、再發(fā)現(xiàn)文檔沒寫、補(bǔ)提示”三四輪循環(huán)每輪都要消耗 1000 多個(gè) token最后總量往往超過 5000 token。預(yù)測模式比串行模式省大約 20% 到 30% 的 token 開銷省下來的不是模型能力而是避免了你反復(fù)等待和重寫的浪費(fèi)周期。如果你的預(yù)測消耗異常高第一個(gè)要檢查的是“候選路徑數(shù)”。有些場景下默認(rèn)生成 4 條候選其實(shí)只需要 2 條就夠用。把候選數(shù)從 4 降到 2單次預(yù)測消耗差不多會減半。4. 常見問題與排查技巧實(shí)錄4.1 預(yù)測頻繁失效命中率上不去我見過最多的反饋是“預(yù)測幾乎沒一個(gè)能用的還不如直接輸入需求讓它慢慢生成?！边@通常不是產(chǎn)品 bug而是上下文質(zhì)量出了問題。排查思路按順序來檢查 Composer 會話是否被過長歷史塞滿。預(yù)測模型很依賴最近幾條上下文的權(quán)重如果你連續(xù)聊了很多輪無關(guān)內(nèi)容后面的預(yù)測會被歷史余波干擾。處理辦法是開一個(gè)全新的 Composer 會話。檢查項(xiàng)目根目錄下有沒有大量無關(guān)文件。Composer 預(yù)測會抽取項(xiàng)目結(jié)構(gòu)作為上下文如果目錄里堆著一堆 node_modules 或其他依賴產(chǎn)物它可能把注意力浪費(fèi)在這上面。檢查你是否經(jīng)常使用高置信度閾值但項(xiàng)目本身很模糊。比如新項(xiàng)目沒有歷史提交記錄模型沒有足夠樣本去學(xué)習(xí)你的偏好這時(shí)候閾值高反而會過濾掉所有合理候選建議把閾值放低一點(diǎn)先看看發(fā)散方向。純經(jīng)驗(yàn)總結(jié)就是預(yù)測失效時(shí)優(yōu)先修上下文而不是急著調(diào)算法參數(shù)。上下文干凈了預(yù)測質(zhì)量通常能直接改善。4.2 預(yù)測結(jié)果與真實(shí)意圖沖突有時(shí)候預(yù)測出來的候選路徑方向沒錯但細(xì)節(jié)上跟你心里想的完全不是一回事。比如你要的是“把字段名從 user_name 統(tǒng)一改成 username”預(yù)測系統(tǒng)卻生成了一段“清洗 user_name 數(shù)據(jù)格式”的改動這就是典型的意圖層級錯位。這種沖突的根源在于指令里的動詞被模型抓偏了?！敖y(tǒng)一改字段名”是機(jī)械性的重命名“清洗數(shù)據(jù)格式”則是數(shù)據(jù)質(zhì)量優(yōu)化。兩者都包含“改名/變更”的語義但目標(biāo)層級完全不同。應(yīng)對方法是把動詞寫得“笨”一點(diǎn)不要用“優(yōu)化”“整理”“改進(jìn)”這類高抽象詞直接用“把 A 改名為 B”“刪除 C 字段”“把 if 分支改為 switch”。預(yù)測系統(tǒng)對明確動詞的響應(yīng)準(zhǔn)確度高非常多。還有一個(gè)細(xì)節(jié)如果預(yù)測結(jié)果里帶著你不想動的文件修改不要先刪掉那個(gè)文件的改動再繼續(xù)。正確做法是回到 Composer 輸入欄加一句“不要改 [文件路徑]”。預(yù)測系統(tǒng)會把這條限制納入下一輪候選生成效果比手動回滾再重新預(yù)測要穩(wěn)定。4.3 多人協(xié)作時(shí)預(yù)測結(jié)果互相干擾我在團(tuán)隊(duì)協(xié)作環(huán)境里踩過一個(gè)坑兩個(gè)人在同一個(gè) Composer 工作區(qū)并行操作預(yù)測系統(tǒng)偶爾會把 A 的意圖混進(jìn) B 的候選路徑里。這種情況特別容易出現(xiàn)在共享需求描述的時(shí)候。比如大家都打開了同一個(gè)需求文檔但一個(gè)人在看前端部分另一個(gè)在看后端部分預(yù)測模型就會糾結(jié)到底該生成誰的上下文。解法的核心是隔離會話。無論你用的是 Codex 官方的多工作區(qū)模式還是自己維護(hù)多個(gè) Composer 會話文件都應(yīng)該讓每個(gè)會話只承載一條主線需求。另一個(gè)低技術(shù)但有效的辦法是把每條需求用獨(dú)立需求卡片的方式貼在 Composer 里不要混寫在同一個(gè)指令段落中。預(yù)測系統(tǒng)識別需求邊界時(shí)依賴的往往是格式分隔符一個(gè)換行、一個(gè)分隔線、一個(gè)標(biāo)簽分段都會對它接下來的意圖判斷產(chǎn)生明顯影響。4.4 性能開銷延遲到底來自哪不少人抱怨預(yù)測模式加載慢實(shí)際上“慢”有兩個(gè)完全不同的來源。第一是模型在生成多個(gè)候選路徑時(shí)的解碼時(shí)間這個(gè)跟你的網(wǎng)絡(luò)條件和模型規(guī)模直接相關(guān)沒法靠調(diào)參解決只能減少候選分支數(shù)。第二是預(yù)測結(jié)果在確認(rèn)落盤時(shí)的序列化時(shí)間這個(gè)受限于要寫入的文件數(shù)量和復(fù)雜度跟單條候選的改動跨度強(qiáng)相關(guān)。我測試過一個(gè)簡單對比單文件改動的確認(rèn)時(shí)間穩(wěn)定在兩秒內(nèi)跨 5 個(gè)文件的結(jié)構(gòu)性改動確認(rèn)時(shí)間會拉到八秒以上。如果你經(jīng)常做大批量重構(gòu)建議在確認(rèn)前先查看候選路徑的“文件影響范圍”標(biāo)簽看到改動跨度過大時(shí)手動拆成兩三個(gè)小的預(yù)測請求整體體感會更流暢。常見現(xiàn)象可能原因優(yōu)先排查項(xiàng)預(yù)測面板全空置信度閾值過高或上下文過短降低閾值到 0.7新增 2 到 3 條背景描述候選路徑高度相似意圖向量收斂過窄在指令里增加不同的落點(diǎn)標(biāo)簽換取更多方向預(yù)測結(jié)果總是覆蓋舊改動草稿區(qū)沒有及時(shí)清理每次確認(rèn)后手動清理未采納的預(yù)測候選多人協(xié)作互相串線共享會話導(dǎo)致上下文污染拆分 Composer 會話按需求隔離確認(rèn)后文件內(nèi)容錯位預(yù)測草稿區(qū)存在失效引用重新加載工作區(qū)強(qiáng)制刷新草稿區(qū)映射5. 我的實(shí)際體會與幾點(diǎn)使用建議5.1 這個(gè)功能到底適合誰我從個(gè)人角度給出一個(gè)非常坦率的判斷Composer 預(yù)測不是給所有人的。如果你平時(shí)只做很小的代碼修改或者你的工作流依賴極強(qiáng)的個(gè)人判斷不太喜歡讓模型先給一堆方向那這個(gè)功能帶來的干擾可能大于收益。但如果你是這幾類人預(yù)測功能的效率增益是很明顯經(jīng)常處理“需求描述已經(jīng)很明確但實(shí)現(xiàn)路徑有多解”的任務(wù)比如前端頁面搭建、接口對拍、批量數(shù)據(jù)遷移需要在一個(gè) Composer 會話里連續(xù)完成多個(gè)相關(guān)文件的協(xié)同修改做代碼重構(gòu)時(shí)希望先看到幾個(gè)可行的結(jié)構(gòu)方案再動手。我自己的使用模式已經(jīng)固定成三個(gè)步驟先在 Composer 里用落點(diǎn)標(biāo)簽寫清楚需求再打開預(yù)測面板掃描候選路徑選中最接近的一條確認(rèn)之后立刻做一次快照提交然后在此基礎(chǔ)上繼續(xù)修改。整個(gè)流程里我真正自己動腦的時(shí)間集中在“篩選候選路徑”這一步而不是反復(fù)寫提示詞。5.2 對于后續(xù)擴(kuò)展我有一點(diǎn)真實(shí)期待預(yù)測模式目前在語義層面做得好但它在“可驗(yàn)證性”上還有很大提升空間。我希望未來的 Composer 預(yù)測不只是生成候選路徑還能同步給出每條候選路徑的批量測試建議把測試用例的生成也放進(jìn)預(yù)測管道這樣用戶就不用手動為每條候選補(bǔ)測試。另外預(yù)測的歷史數(shù)據(jù)如果能被沉淀下來用戶就能回頭看到“過去三個(gè)月里哪些預(yù)測被采納率最高”這些數(shù)據(jù)可以用來動態(tài)調(diào)整置信度閾值。目前只能用我前面說的試錯方法來做略微原始。愿意折騰的人可以自己在本地統(tǒng)計(jì) Composer 工作區(qū)的日志把每次采納結(jié)果標(biāo)注出來慢慢積累自己的預(yù)測偏好庫。5.3 最后一個(gè)小技巧預(yù)測面板里有一個(gè)很容易被忽略的快捷鍵邏輯鍵盤上下鍵可以快速切換候選路徑回車確認(rèn)當(dāng)前項(xiàng)Shift 加回車則是在不離開面板的情況下把當(dāng)前候選加入“待比較區(qū)”。這個(gè)組合邏輯非常適合在兩個(gè)看起來都很合理的候選之間做對比。我第一次用的時(shí)候完全沒發(fā)現(xiàn)后來是在一次重構(gòu)任務(wù)里誤打誤撞按出來的。有了這個(gè)操作篩選候選路徑的速度能再快一倍并且不需要動鼠標(biāo)手不離鍵盤工作區(qū)也不會因?yàn)轭l繁點(diǎn)擊而彈出一堆預(yù)覽浮層。寫到這里Composer 預(yù)測從定位到機(jī)制再到日常實(shí)戰(zhàn)基本都覆蓋到了。如果你手邊就有 Pro 賬號我建議下一個(gè)任務(wù)先別急著寫長提示詞打開預(yù)測面板用最低的閾值掃一遍候選看看它給出的方向是不是比你習(xí)慣的新一點(diǎn)。充其量只是多花十幾秒但也許就找到了更順手的用法。