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