1. 從一次字幕“跳字”事故說起去年幫一個(gè)做在線教育的朋友排查直播字幕問題他跟我抱怨“學(xué)生端老是看到字幕先蹦出半句話過一會(huì)兒又整段變了像有人在后臺(tái)偷偷改稿?！蔽易屗言际录鲗?dǎo)出來一看問題很典型——客戶端把committed事件里的文本直接當(dāng)成了最終定稿渲染到屏幕上就不再管了結(jié)果后面來的intermediate增量把整句話補(bǔ)全時(shí)前端已經(jīng)“鎖死”了舊文本只能整段替換視覺上就是跳字、閃動(dòng)、甚至前后矛盾。這個(gè)坑不是個(gè)例。只要涉及實(shí)時(shí)字幕、語音轉(zhuǎn)寫、協(xié)同編輯這類流式文本場(chǎng)景committed、delta、intermediate、completed這幾個(gè)詞就會(huì)反復(fù)出現(xiàn)。很多人第一反應(yīng)是committed不就是“已提交、已確認(rèn)”嗎那它應(yīng)該就是定稿了。但實(shí)際協(xié)議里committed描述的是一段已確定的前綴它保證的是“這部分不會(huì)再被推翻”而不是“整句話已經(jīng)說完”。真正決定一句話是否終結(jié)的是completed這個(gè)狀態(tài)位。這篇內(nèi)容就圍繞 MAI 協(xié)議里這套“已定稿前綴 暫定后綴”的機(jī)制展開。我會(huì)把committed、delta、intermediate、completed四個(gè)概念拆開講清楚說明為什么不能把committed當(dāng)文字定稿以及在實(shí)際工程里應(yīng)該怎么處理。適合正在做實(shí)時(shí)字幕、語音轉(zhuǎn)寫、流式對(duì)話前端渲染的開發(fā)者也適合被“字幕跳字”折磨過的產(chǎn)品同學(xué)。讀完你至少能判斷你手里的字幕抖動(dòng)到底是協(xié)議理解錯(cuò)了還是渲染策略寫歪了。2. MAI 協(xié)議里四個(gè)關(guān)鍵詞到底在說什么2.1 committed 不是“定稿”是“不可回退的前綴”先把最容易誤解的詞拎出來。committed在流式文本協(xié)議里的含義接近于“這段文本已經(jīng)被確認(rèn)不會(huì)再被修改”。注意它修飾的是一段前綴不是一整句。舉個(gè)生活化的例子你在餐廳點(diǎn)菜服務(wù)員復(fù)述“您要的是宮保雞丁、米飯……”說到“米飯”時(shí)他停了一下這部分他已經(jīng)記下了不會(huì)改口但他還沒說完后面可能還有“再加一個(gè)湯”。committed就是“已經(jīng)記下的那部分”不是“整單已經(jīng)下完”。在 MAI 協(xié)議的事件流里committed通常攜帶的是從句子開頭到某個(gè)穩(wěn)定邊界之間的文本。這個(gè)邊界可能是標(biāo)點(diǎn)、可能是聲學(xué)上的靜音段、也可能是模型置信度足夠高的一個(gè)切分點(diǎn)。協(xié)議保證的是這段前綴在后續(xù)事件里不會(huì)再被否定或重寫。但它不保證這句話已經(jīng)結(jié)束后面完全可能繼續(xù)追加內(nèi)容。2.2 delta 是增量不是全量delta這個(gè)詞在流式場(chǎng)景里出現(xiàn)頻率極高它的本質(zhì)是“相比上一次新增了什么”。很多初學(xué)者會(huì)把它和全量文本搞混導(dǎo)致每來一個(gè)delta就重新拼一次整句拼著拼著就重復(fù)了。正確的理解是delta是一塊積木你要把它按順序壘到已有文本后面。在 MAI 的語境下delta往往和committed配合出現(xiàn)committed告訴你“前綴到哪兒了”delta告訴你“這次又多了哪幾個(gè)字”。兩者一個(gè)是位置錨點(diǎn)一個(gè)是增量內(nèi)容缺一不可。只盯著delta拼字符串容易在斷句處丟字只盯著committed不處理增量就會(huì)漏掉后續(xù)內(nèi)容。2.3 intermediate 是暫定后綴隨時(shí)可能被替換intermediate是這套機(jī)制里最“不穩(wěn)定”的部分。它代表的是暫定的后綴——模型當(dāng)前猜測(cè)的、還沒被確認(rèn)的文本。它可能被修正、被截?cái)?、被整體替換。你可以把它理解成輸入法里的候選詞你打了拼音候選欄里先蹦出一個(gè)詞你還沒按空格確認(rèn)它隨時(shí)會(huì)變。實(shí)時(shí)字幕里最典型的場(chǎng)景是用戶說“今天天氣”模型先給出intermediate“今天天氣真”過一會(huì)兒又變成“今天天氣真好”再后來確認(rèn)成committed“今天天氣真好?！比绻惆裪ntermediate直接當(dāng)最終文本渲染并且不做替換屏幕上就會(huì)留下“今天天氣真”這種半截話如果你每次都整段重繪又會(huì)閃得厲害。所以intermediate的正確用法是渲染但標(biāo)記為可替換區(qū)域。2.4 completed 才是“這句話說完了”的信號(hào)completed是整句話的終結(jié)標(biāo)記。它出現(xiàn)時(shí)意味著當(dāng)前這句話已經(jīng)完整后續(xù)不會(huì)再對(duì)這句話做增刪改。注意區(qū)分committed是“前綴鎖定”completed是“整句終結(jié)”。一句話可能經(jīng)歷多次committed比如長句被分成幾個(gè)穩(wěn)定段但通常只有一個(gè)completed。很多字幕跳字的根因就是把committed誤當(dāng)成completed。前端收到committed就以為萬事大吉把文本寫進(jìn)“最終區(qū)”結(jié)果后面intermediate還在變兩邊打架。正確的狀態(tài)機(jī)應(yīng)該是intermediate區(qū)可替換committed區(qū)只追加不修改completed到來時(shí)才把整句歸檔。關(guān)鍵詞含義是否可回退典型用途committed已確認(rèn)前綴否鎖定已穩(wěn)定文本作為錨點(diǎn)delta增量內(nèi)容否按序追加拼接新增文本intermediate暫定后綴是實(shí)時(shí)預(yù)覽可被替換completed整句終結(jié)否歸檔整句觸發(fā)后續(xù)處理3. 為什么“committed 當(dāng)定稿”一定會(huì)出問題3.1 前綴鎖定不等于整句終結(jié)這是最核心的認(rèn)知偏差。committed的語義邊界是“從句子開頭到當(dāng)前穩(wěn)定點(diǎn)”它鎖定的是已經(jīng)過去的部分而不是整句話的終點(diǎn)。把前綴當(dāng)整句等于把“已經(jīng)記下的半句”當(dāng)成“用戶已經(jīng)說完了”。在短句場(chǎng)景下這個(gè)錯(cuò)誤可能不明顯因?yàn)榍熬Y往往就是整句但在長句、口語化表達(dá)、帶停頓的敘述里錯(cuò)誤會(huì)被放大。我實(shí)測(cè)過一個(gè)案例用戶說“我想訂一張明天下午三點(diǎn)從北京到上海的高鐵票”。模型可能在“明天下午三點(diǎn)”處給出一個(gè)committed因?yàn)檫@里有明顯的語義邊界。如果前端此時(shí)把“我想訂一張明天下午三點(diǎn)”當(dāng)成定稿渲染后面“從北京到上海的高鐵票”就只能另起一行或者硬插進(jìn)去視覺上非常割裂。3.2 暫定后綴會(huì)持續(xù)修正前綴的“觀感”intermediate雖然叫“暫定后綴”但它修正的往往不只是后綴本身還會(huì)影響整句的觀感。比如前綴是“我想訂一張”暫定后綴先給出“明天”再變成“明天下午”再變成“明天下午三點(diǎn)”。如果你把前綴當(dāng)定稿、后綴當(dāng)獨(dú)立文本渲染用戶看到的就是“我想訂一張”后面跟著一個(gè)不斷變長的尾巴而不是一句自然生長的話。更麻煩的是有些模型會(huì)在intermediate階段對(duì)前綴做微調(diào)比如把“一張”改成“1張”把“明天”改成“明早”。雖然committed理論上保證前綴不變但intermediate階段的文本是允許波動(dòng)的。如果前端把committed和intermediate混在同一個(gè)渲染層就會(huì)看到已經(jīng)“定稿”的字又被改了信任感直接崩掉。3.3 渲染層如果沒有“可替換區(qū)”概念必然抖動(dòng)前端渲染實(shí)時(shí)字幕本質(zhì)上是在維護(hù)一個(gè)“文本狀態(tài)機(jī)”。這個(gè)狀態(tài)機(jī)至少要有兩個(gè)區(qū)穩(wěn)定區(qū)和暫定區(qū)。穩(wěn)定區(qū)放committed的內(nèi)容只追加不修改暫定區(qū)放intermediate的內(nèi)容每次新事件來了就整體替換。completed到來時(shí)把暫定區(qū)的內(nèi)容合并進(jìn)穩(wěn)定區(qū)并清空暫定區(qū)。如果渲染層只有一個(gè)文本緩沖區(qū)收到什么就寫什么那committed和intermediate就會(huì)互相覆蓋。表現(xiàn)就是先顯示committed的半句然后intermediate來了把整句重寫用戶看到文字跳了一下下一個(gè)intermediate又重寫一次再跳一下。這就是“跳字”的物理來源。注意不要把committed事件里的文本直接append到最終輸出里。它應(yīng)該進(jìn)入穩(wěn)定區(qū)而穩(wěn)定區(qū)的更新策略是“只增不改”不是“來了就覆蓋”。3.4 協(xié)議設(shè)計(jì)本身就在鼓勵(lì)“分段確認(rèn)”MAI 這套機(jī)制的設(shè)計(jì)意圖其實(shí)是讓流式文本更穩(wěn)。它把一句話拆成“已確認(rèn)前綴”和“暫定后綴”就是為了讓前端可以盡早渲染穩(wěn)定部分同時(shí)給暫定部分留出修正空間。如果你把committed當(dāng)定稿等于主動(dòng)放棄了這個(gè)設(shè)計(jì)帶來的容錯(cuò)能力把“分段確認(rèn)”退化成了“一次性確認(rèn)”那協(xié)議里的intermediate和completed就形同虛設(shè)。換個(gè)角度想如果committed就是定稿那協(xié)議為什么還要單獨(dú)設(shè)計(jì)completed為什么還要有intermediate這三個(gè)狀態(tài)的存在本身就說明它們各司其職。committed管前綴穩(wěn)定intermediate管后綴預(yù)覽completed管整句終結(jié)?；煊萌魏我粋€(gè)都會(huì)破壞這套分工。4. 正確的前端狀態(tài)機(jī)該怎么搭4.1 兩個(gè)緩沖區(qū)stable 和 pending最直接的做法是在前端維護(hù)兩個(gè)字符串stableText和pendingText。stableText只接受committed和delta的內(nèi)容按序追加永不回退pendingText每次收到intermediate就整體替換。最終渲染給用戶的是stableText pendingText。這個(gè)模型的好處是職責(zé)清晰穩(wěn)定區(qū)負(fù)責(zé)“不跳”暫定區(qū)負(fù)責(zé)“實(shí)時(shí)”。用戶看到的文本始終是“已確認(rèn)部分 當(dāng)前猜測(cè)部分”既不會(huì)丟字也不會(huì)因?yàn)闀憾ú糠值男拚绊懸汛_認(rèn)部分。completed到來時(shí)把pendingText合并進(jìn)stableText清空pendingText整句歸檔。// 簡(jiǎn)化版狀態(tài)機(jī)示意 let stableText ; let pendingText ; function onCommitted(text) { stableText text; // 只追加不覆蓋 } function onDelta(text) { stableText text; } function onIntermediate(text) { pendingText text; // 整體替換 } function onCompleted() { stableText pendingText; pendingText ; archive(stableText); stableText ; } function render() { return stableText pendingText; }4.2 committed 和 delta 的拼接順序不能亂committed和delta雖然都進(jìn)穩(wěn)定區(qū)但它們的語義不同。committed通常攜帶的是“從某個(gè)錨點(diǎn)到當(dāng)前穩(wěn)定邊界”的文本而delta是“相比上次新增的內(nèi)容”。如果協(xié)議里兩者同時(shí)存在一定要按事件到達(dá)順序處理不能先拼所有committed再拼delta。我踩過的一個(gè)坑是某次為了“優(yōu)化性能”把同一批事件里的committed和delta分別收集后統(tǒng)一拼接結(jié)果順序錯(cuò)亂文本變成了“我想訂一張高鐵票明天下午三點(diǎn)”。后來改成嚴(yán)格按事件時(shí)間戳順序處理問題消失。流式文本的順序就是語義亂序拼接等于制造亂碼。4.3 intermediate 的替換要整段替換不能增量追加intermediate最容易寫錯(cuò)的地方是把它當(dāng)delta用。有人看到intermediate里只有幾個(gè)字就append到pendingText后面結(jié)果暫定區(qū)越來越長重復(fù)內(nèi)容堆疊。正確的做法是每次intermediate事件里的文本就是當(dāng)前暫定后綴的全量內(nèi)容直接替換pendingText。這一點(diǎn)在協(xié)議文檔里通常不會(huì)寫得特別顯眼但實(shí)測(cè)下來是鐵律。你可以做個(gè)簡(jiǎn)單驗(yàn)證連續(xù)打印幾個(gè)intermediate事件的文本如果它們是遞增的完整后綴那就該整體替換如果它們是碎片那才需要追加。MAI 語境下intermediate一般是完整后綴整體替換更穩(wěn)。4.4 completed 到來時(shí)的歸檔動(dòng)作completed不只是“這句話說完了”它還是一個(gè)觸發(fā)點(diǎn)。歸檔時(shí)要做幾件事把pendingText合并進(jìn)stableText把整句寫入歷史記錄清空當(dāng)前緩沖區(qū)準(zhǔn)備接收下一句。如果業(yè)務(wù)上有翻譯、摘要、關(guān)鍵詞提取等下游任務(wù)也應(yīng)該在completed時(shí)觸發(fā)而不是在committed時(shí)觸發(fā)。我見過一個(gè)反例某系統(tǒng)在committed時(shí)就觸發(fā)翻譯結(jié)果翻譯的是半句話等completed來了又翻譯一次用戶看到兩句翻譯來回閃。改成completed觸發(fā)后翻譯穩(wěn)定了成本也降了。這個(gè)細(xì)節(jié)看似小但對(duì)下游鏈路影響很大。事件進(jìn)入?yún)^(qū)域更新策略是否觸發(fā)下游committedstable追加否deltastable追加否intermediatepending整體替換否completed歸檔合并并清空是5. 實(shí)操從事件流到屏幕的完整鏈路5.1 事件接收與排序第一步是保證事件按正確順序到達(dá)處理層。實(shí)時(shí)字幕的事件流可能來自網(wǎng)絡(luò)存在亂序、重復(fù)、延遲。處理層需要有一個(gè)輕量級(jí)的排序緩沖按事件序號(hào)或時(shí)間戳排序后再分發(fā)。如果協(xié)議里有sequence字段優(yōu)先用它沒有的話用到達(dá)順序加時(shí)間戳兜底。這里有個(gè)經(jīng)驗(yàn)不要在主渲染線程里做排序和拼接。字幕事件頻率可能很高主線程被占滿會(huì)導(dǎo)致界面卡頓。我通常把事件處理放在 Web Worker 或獨(dú)立線程里處理完只把stableText和pendingText兩個(gè)字符串傳回渲染層。這樣即使事件密集界面也不會(huì)掉幀。5.2 穩(wěn)定區(qū)與暫定區(qū)的渲染分離渲染層最好把穩(wěn)定區(qū)和暫定區(qū)分開樣式。穩(wěn)定區(qū)用正常字重暫定區(qū)用淺色或斜體讓用戶直觀感受到“這部分還沒最終確定”。這不是為了好看而是為了管理預(yù)期。用戶看到淺色部分在變不會(huì)覺得系統(tǒng)出錯(cuò)看到深色部分穩(wěn)定會(huì)對(duì)已確認(rèn)內(nèi)容產(chǎn)生信任。如果產(chǎn)品不允許樣式區(qū)分至少要在邏輯上分開。比如暫定區(qū)的內(nèi)容不參與復(fù)制、不參與搜索、不寫入數(shù)據(jù)庫。等completed后再統(tǒng)一處理。這樣即使視覺上沒區(qū)分?jǐn)?shù)據(jù)層面也是干凈的。5.3 參數(shù)選擇緩沖區(qū)大小與刷新頻率緩沖區(qū)不能無限增長。我一般設(shè)兩個(gè)閾值單句最大長度和最大暫定時(shí)長。單句超過一定字?jǐn)?shù)比如 200 字還沒completed就強(qiáng)制歸檔避免內(nèi)存泄漏暫定后綴超過一定時(shí)長比如 5 秒還沒確認(rèn)就降低刷新頻率減少渲染壓力。刷新頻率也要控制。intermediate可能每秒來很多次如果每次都觸發(fā)重繪性能吃不消。常見做法是節(jié)流到 30ms 或 50ms 一次用requestAnimationFrame對(duì)齊屏幕刷新。實(shí)測(cè)下來50ms 的節(jié)流在視覺上已經(jīng)足夠流暢CPU 占用能降一半以上。// 節(jié)流渲染示意 let renderScheduled false; function scheduleRender() { if (renderScheduled) return; renderScheduled true; requestAnimationFrame(() { renderScheduled false; updateDOM(stableText pendingText); }); }5.4 與后端 completed 信號(hào)的配合前端狀態(tài)機(jī)要和后端的completed信號(hào)對(duì)齊。有些后端會(huì)在completed之后還發(fā)一些修正事件這時(shí)候前端要能識(shí)別并處理。我的做法是completed之后進(jìn)入一個(gè)短暫的“靜默期”比如 200ms期間如果還有同句的修正事件就合并處理靜默期結(jié)束后再真正歸檔。這個(gè)靜默期的長度要根據(jù)實(shí)際鏈路延遲調(diào)整。如果后端和前端在同一臺(tái)機(jī)器上50ms 就夠如果跨網(wǎng)絡(luò)可能要 200ms 到 500ms。設(shè)得太短修正事件會(huì)被當(dāng)成新句子設(shè)得太長用戶會(huì)覺得字幕“卡住不動(dòng)”。我一般先用 300ms 起步再根據(jù)實(shí)測(cè)調(diào)整。6. 常見問題與排查技巧實(shí)錄6.1 字幕跳字、閃動(dòng)、重復(fù)的排查順序遇到字幕異常我通常按這個(gè)順序排查先看事件流里committed和intermediate的比例如果intermediate頻繁且文本波動(dòng)大說明暫定區(qū)替換策略有問題再看completed是否正常到達(dá)如果長時(shí)間沒有completed可能是后端斷句邏輯卡住最后看渲染層是否把兩個(gè)區(qū)混在一起這是最常見的低級(jí)錯(cuò)誤。有個(gè)快速判斷方法在控制臺(tái)里把stableText和pendingText分別打印出來。如果stableText在completed之前就包含了整句說明你把intermediate誤寫進(jìn)了穩(wěn)定區(qū)如果pendingText越來越長且包含重復(fù)內(nèi)容說明你把intermediate當(dāng)delta追加了。這兩個(gè)現(xiàn)象對(duì)應(yīng)兩種不同的修法別搞混。6.2 committed 之后文本還在變的幾種可能理論上committed之后前綴不該變但實(shí)際中確實(shí)會(huì)遇到。常見原因有三個(gè)一是前端把intermediate寫進(jìn)了穩(wěn)定區(qū)看起來像committed在變二是后端在committed之后又發(fā)了修正事件這屬于協(xié)議實(shí)現(xiàn)問題三是事件亂序舊的intermediate晚于新的committed到達(dá)覆蓋了穩(wěn)定區(qū)。排查時(shí)先確認(rèn)事件順序再看后端是否有修正事件。如果是亂序加排序緩沖如果是后端修正需要和后端對(duì)齊協(xié)議語義。我遇到過第三種情況原因是網(wǎng)絡(luò)抖動(dòng)導(dǎo)致事件亂序加了序號(hào)排序后解決。這個(gè)坑不常見但一旦遇到很難查建議提前在事件里帶序號(hào)。6.3 intermediate 為空或缺失時(shí)的降級(jí)策略有些場(chǎng)景下intermediate可能為空或者干脆不發(fā)送。這時(shí)候前端不能傻等要有降級(jí)策略。我的做法是如果一段時(shí)間內(nèi)沒有intermediate就只渲染stableText暫定區(qū)留空等completed來了再一次性補(bǔ)全。這樣雖然少了實(shí)時(shí)預(yù)覽但至少不會(huì)顯示錯(cuò)誤內(nèi)容。還有一種情況是intermediate發(fā)送頻率極低比如每秒一次。這時(shí)候節(jié)流策略要調(diào)整不能按 50ms 節(jié)流否則大部分渲染都是空轉(zhuǎn)?？梢愿鶕?jù)實(shí)際頻率動(dòng)態(tài)調(diào)整或者干脆在intermediate到達(dá)時(shí)才觸發(fā)渲染不做定時(shí)節(jié)流。6.4 長句、無標(biāo)點(diǎn)、口語化場(chǎng)景的特殊處理長句和無標(biāo)點(diǎn)場(chǎng)景是committed機(jī)制最容易暴露問題的地方。用戶說了一長串沒有標(biāo)點(diǎn)的話模型可能很久才給一個(gè)committed暫定后綴越來越長。這時(shí)候如果暫定區(qū)渲染不當(dāng)用戶會(huì)看到一大段淺色文字在不停變化體驗(yàn)很差。我的處理方式是對(duì)暫定后綴設(shè)一個(gè)長度上限超過上限就只顯示最后 N 個(gè)字符前面的用省略號(hào)代替。這樣既保留了實(shí)時(shí)感又不會(huì)讓屏幕被不穩(wěn)定的文本占滿。等completed來了再完整顯示。這個(gè)策略在會(huì)議記錄、直播字幕場(chǎng)景下特別有用。問題現(xiàn)象可能原因排查方法解決方向字幕跳字穩(wěn)定區(qū)被覆蓋打印兩個(gè)緩沖區(qū)分離 stable 和 pending文本重復(fù)intermediate 被追加檢查 pending 長度改為整體替換長時(shí)間不更新completed 未到達(dá)檢查后端斷句加超時(shí)強(qiáng)制歸檔前綴被修改事件亂序檢查事件序號(hào)加排序緩沖暫定區(qū)過長長句無標(biāo)點(diǎn)觀察 intermediate 長度設(shè)長度上限6.5 實(shí)測(cè)有效的三個(gè)避坑技巧第一個(gè)技巧在開發(fā)階段把stableText和pendingText用不同顏色渲染在頁面上一眼就能看出哪個(gè)區(qū)在變。這個(gè)土辦法幫我省了很多排查時(shí)間。第二個(gè)技巧給每個(gè)事件打上序號(hào)處理層按序號(hào)排序亂序問題直接消失。第三個(gè)技巧在completed之后加一個(gè)短靜默期合并可能的修正事件避免一句話被拆成兩句歸檔。這三個(gè)技巧都不復(fù)雜但都是實(shí)際踩坑后總結(jié)出來的。尤其是第一個(gè)看起來簡(jiǎn)陋但對(duì)理解狀態(tài)機(jī)的行為特別直觀。建議你在本地調(diào)試時(shí)先加上等邏輯穩(wěn)定了再去掉。7. 我個(gè)人在實(shí)際操作中的體會(huì)這套committed前綴加intermediate后綴的機(jī)制剛接觸時(shí)容易覺得繞但用順了會(huì)發(fā)現(xiàn)它其實(shí)很符合流式文本的本質(zhì)。文本本來就是逐步生成的硬要把它當(dāng)成一次性定稿來處理反而別扭。把穩(wěn)定區(qū)和暫定區(qū)分開不僅解決了跳字問題還讓整個(gè)渲染鏈路變得可預(yù)測(cè)。我現(xiàn)在的習(xí)慣是任何流式文本場(chǎng)景先畫狀態(tài)機(jī)再寫代碼。狀態(tài)機(jī)里明確標(biāo)出哪些事件進(jìn)穩(wěn)定區(qū)、哪些進(jìn)暫定區(qū)、哪個(gè)事件觸發(fā)歸檔。畫清楚了代碼基本不會(huì)寫歪。如果狀態(tài)機(jī)畫不出來說明對(duì)協(xié)議的理解還有漏洞這時(shí)候?qū)懘a大概率要返工。最后分享一個(gè)小技巧如果你不確定某個(gè)事件該進(jìn)哪個(gè)區(qū)就問自己一個(gè)問題——“這個(gè)內(nèi)容如果下一秒被替換用戶會(huì)覺得是 bug 嗎”如果會(huì)它就該進(jìn)暫定區(qū)如果不會(huì)它才可以進(jìn)穩(wěn)定區(qū)。這個(gè)判斷標(biāo)準(zhǔn)簡(jiǎn)單但很準(zhǔn)。