1. 從“開會工具”到“辦公中臺”這個轉(zhuǎn)變到底在轉(zhuǎn)什么視頻會議這個品類過去十年基本被定義為“開會的工具”。你約一個會議發(fā)一個鏈接大家點(diǎn)進(jìn)來開完會關(guān)掉完事。產(chǎn)品經(jīng)理們比拼的是誰的通話更穩(wěn)、誰的美顏更自然、誰共享屏幕不卡。但最近兩年我觀察到一批團(tuán)隊在重新思考這件事會議本身不是目的會議只是辦公流程中的一個節(jié)點(diǎn)。真正有價值的東西是會議前后那些散落的信息、決策和任務(wù)。這個判斷背后有一個很樸素的觀察一場一小時的會真正產(chǎn)生有效決策的時間可能只有十分鐘剩下的五十分鐘在同步背景、對齊認(rèn)知、確認(rèn)細(xì)節(jié)。而會議結(jié)束后這些信息又以錄音、聊天記錄、共享文檔的形式散落在不同地方?jīng)]有人真正去整理。等到下次開會又要重新同步一遍。這個循環(huán)消耗了大量組織效率。所以“AI重構(gòu)視頻會議產(chǎn)品體驗(yàn)”這件事核心不是給會議加一個AI字幕或者AI紀(jì)要而是把會議從一個孤立的工具變成一個智能辦公中臺的入口。什么叫中臺就是它不再是終點(diǎn)而是起點(diǎn)。會議中產(chǎn)生的討論、決策、待辦能夠自動流轉(zhuǎn)到項目管理、文檔協(xié)作、任務(wù)分配等下游環(huán)節(jié)。AI在這里扮演的角色不是錦上添花的功能而是打通整個鏈路的粘合劑。我見過不少團(tuán)隊做AI會議功能最常見的做法是接一個語音轉(zhuǎn)文字API生成一份會議紀(jì)要然后讓用戶自己去復(fù)制粘貼。這個做法的問題在于它只解決了“記錄”的問題沒有解決“流轉(zhuǎn)”的問題。紀(jì)要生成了然后呢誰來看誰來跟進(jìn)任務(wù)怎么分配截止時間怎么定這些才是真正影響辦公效率的關(guān)鍵節(jié)點(diǎn)。從技術(shù)架構(gòu)上看這個轉(zhuǎn)變意味著產(chǎn)品需要從“實(shí)時音視頻處理”為核心轉(zhuǎn)向“實(shí)時音視頻AI理解工作流引擎”的三層架構(gòu)。實(shí)時音視頻層負(fù)責(zé)采集和傳輸AI理解層負(fù)責(zé)把非結(jié)構(gòu)化的語音和文本轉(zhuǎn)化為結(jié)構(gòu)化的信息工作流引擎負(fù)責(zé)把這些信息路由到正確的人和系統(tǒng)。這三層缺一不可而且每一層的技術(shù)選型和工程實(shí)現(xiàn)都有不少坑。我個人的判斷是未來兩年內(nèi)單純的視頻會議產(chǎn)品會越來越難獨(dú)立生存因?yàn)樗峁┑膬r值太單薄了。而能夠把會議能力嵌入到辦公流程中的產(chǎn)品會逐漸吃掉這個市場。這不是功能層面的競爭而是產(chǎn)品定位層面的競爭。誰先完成從“工具”到“中臺”的認(rèn)知轉(zhuǎn)變誰就能在下一輪競爭中占據(jù)有利位置。2. 會議場景下AI能力的真實(shí)邊界在哪里2.1 語音轉(zhuǎn)寫的準(zhǔn)確率陷阱幾乎所有做AI會議產(chǎn)品的團(tuán)隊第一個要面對的就是語音轉(zhuǎn)寫。很多團(tuán)隊覺得這個事情很簡單接一個成熟的ASR服務(wù)就行了。但實(shí)際跑下來會發(fā)現(xiàn)通用ASR在會議場景下的準(zhǔn)確率遠(yuǎn)低于預(yù)期。原因有幾個會議場景存在大量專業(yè)術(shù)語和內(nèi)部縮寫通用模型沒有這些詞匯多人交替發(fā)言時說話人分離的準(zhǔn)確率會顯著下降遠(yuǎn)場拾音帶來的混響和噪聲會進(jìn)一步降低識別質(zhì)量。我實(shí)測過幾個主流ASR服務(wù)在真實(shí)會議錄音上的表現(xiàn)在安靜環(huán)境、單人發(fā)言的情況下字準(zhǔn)確率可以到95%以上。但一旦切換到多人討論、有交叉發(fā)言的場景字準(zhǔn)確率會掉到80%左右而說話人歸屬的準(zhǔn)確率可能只有70%。這意味著生成的紀(jì)要里有相當(dāng)一部分內(nèi)容是張冠李戴的。解決這個問題的思路不是去追求一個完美的ASR模型而是在工程層面做補(bǔ)償。常見的做法包括在會前讓用戶上傳參會人名單和議題關(guān)鍵詞用這些信息去熱更新ASR的詞匯表在會中通過聲紋識別輔助說話人分離在會后用大模型對轉(zhuǎn)寫結(jié)果做一次語義校正把明顯不合邏輯的句子修正過來。這些補(bǔ)償手段疊加起來可以把最終紀(jì)要的可用性提升到一個可接受的水平。注意不要向用戶承諾“100%準(zhǔn)確”的轉(zhuǎn)寫。會議場景的復(fù)雜性決定了這不可能做到。更務(wù)實(shí)的做法是提供一個“置信度”指標(biāo)讓用戶知道哪些段落可能需要人工復(fù)核。2.2 會議紀(jì)要生成從“摘要”到“結(jié)構(gòu)化輸出”轉(zhuǎn)寫只是第一步真正體現(xiàn)AI價值的是從轉(zhuǎn)寫文本中提取結(jié)構(gòu)化信息。很多產(chǎn)品做的“AI紀(jì)要”其實(shí)就是把轉(zhuǎn)寫文本丟給大模型讓它生成一段摘要。這個做法的問題在于摘要丟失了大量細(xì)節(jié)而且沒有結(jié)構(gòu)用戶看完之后還是不知道要做什么。我在實(shí)際項目中總結(jié)出一個更有效的做法把會議紀(jì)要拆成幾個固定的模塊讓AI分別填充。這些模塊包括議題回顧這次會議討論了哪幾個話題、關(guān)鍵決策達(dá)成了哪些共識、待辦事項誰在什么時間之前要完成什么、遺留問題哪些話題沒有結(jié)論需要下次繼續(xù)。每個模塊的prompt設(shè)計都不一樣需要針對性地調(diào)優(yōu)。以“待辦事項”為例prompt里需要明確要求AI識別出“動作主體”、“動作內(nèi)容”、“時間約束”三個要素。如果原文中沒有明確的時間約束AI應(yīng)該標(biāo)注“未指定”而不是自己編一個。這個細(xì)節(jié)很重要因?yàn)榫幵斓臅r間約束會導(dǎo)致后續(xù)任務(wù)管理出現(xiàn)混亂。2.3 實(shí)時輔助AI在會議進(jìn)行中能做什么除了會后的紀(jì)要生成AI在會議進(jìn)行中也有不少可做的事情。我見過比較實(shí)用的功能包括實(shí)時字幕幫助聽力障礙人士或非母語參會者、發(fā)言計時提醒超時發(fā)言、話題偏離提醒當(dāng)討論偏離議程時給出提示、實(shí)時投票快速收集意見。但這些功能有一個共同的挑戰(zhàn)延遲。會議是實(shí)時進(jìn)行的如果AI的響應(yīng)延遲超過兩三秒用戶體驗(yàn)就會很差。實(shí)時字幕的延遲需要控制在500毫秒以內(nèi)話題偏離提醒可以稍微寬松一些但也不能超過五秒。這對系統(tǒng)的推理性能提出了很高的要求。我目前的經(jīng)驗(yàn)是實(shí)時字幕可以用流式ASR來解決邊轉(zhuǎn)邊出延遲可以做到比較低。但話題偏離檢測需要理解上下文必須等一段話說完才能判斷所以延遲天然會高一些。一個折中的方案是用輕量級模型做實(shí)時檢測只判斷當(dāng)前發(fā)言和議程關(guān)鍵詞的匹配度不做深度語義理解。這樣可以把延遲壓下來代價是準(zhǔn)確率會打一些折扣。3. 把會議變成中臺入口工作流打通的具體做法3.1 會議與任務(wù)系統(tǒng)的對接邏輯會議中產(chǎn)生的待辦事項如果不能自動流轉(zhuǎn)到任務(wù)系統(tǒng)那AI紀(jì)要的價值就少了一半。我見過很多團(tuán)隊的做法是在紀(jì)要頁面提供一個“導(dǎo)出到任務(wù)系統(tǒng)”的按鈕用戶手動點(diǎn)擊后把待辦事項同步過去。這個做法雖然能用但多了一步操作實(shí)際使用率并不高。更好的做法是自動同步。會議結(jié)束后AI提取的待辦事項自動在任務(wù)系統(tǒng)中創(chuàng)建對應(yīng)的任務(wù)卡片并分配給相應(yīng)的負(fù)責(zé)人。負(fù)責(zé)人會收到通知任務(wù)卡片里包含會議上下文鏈接點(diǎn)擊可以跳回會議紀(jì)要查看詳情。這個鏈路的打通需要產(chǎn)品在任務(wù)系統(tǒng)和會議系統(tǒng)之間建立一套映射關(guān)系會議中的參會人對應(yīng)任務(wù)系統(tǒng)中的用戶會議中的議題對應(yīng)任務(wù)系統(tǒng)中的項目或標(biāo)簽。這里有一個工程上的細(xì)節(jié)需要注意去重。如果同一場會議被多次處理比如用戶手動觸發(fā)了一次重新生成紀(jì)要待辦事項可能會被重復(fù)創(chuàng)建。解決方案是在任務(wù)卡片上記錄來源會議ID和來源時間戳創(chuàng)建前先做一次查詢?nèi)绻呀?jīng)存在則更新而不是新建。3.2 會議知識的沉淀與檢索會議中討論的內(nèi)容其實(shí)是非常寶貴的組織知識。但傳統(tǒng)模式下這些知識隨著會議結(jié)束就消失了下次有人問起同樣的問題又要重新開會討論。把會議內(nèi)容沉淀為可檢索的知識庫是智能辦公中臺的一個重要能力。具體做法是把每次會議的轉(zhuǎn)寫文本、紀(jì)要、決策記錄都存入一個向量數(shù)據(jù)庫同時保留結(jié)構(gòu)化的元數(shù)據(jù)參會人、時間、議題標(biāo)簽。當(dāng)用戶搜索某個關(guān)鍵詞時系統(tǒng)不僅返回相關(guān)的會議片段還能顯示這個議題在歷次會議中的討論脈絡(luò)。這個能力對于新員工入職、項目復(fù)盤、決策追溯等場景非常有價值。我實(shí)測下來向量檢索的效果很大程度上取決于切分策略。如果按固定長度切分很容易把一個完整的決策拆成兩半檢索出來的是殘缺信息。更好的做法是按語義段落切分同時保留前后各一段的上下文。另外元數(shù)據(jù)的過濾也很重要比如用戶只想搜索某個項目相關(guān)的會議就需要在檢索時加上項目標(biāo)簽的過濾條件。3.3 跨會議的話題追蹤單次會議的信息提取相對容易難的是跨會議的話題追蹤。比如一個產(chǎn)品需求第一次會議討論了方案第二次會議評審了設(shè)計第三次會議確認(rèn)了排期。這三次會議分散在不同的時間點(diǎn)但邏輯上是連貫的。如果AI能夠自動識別出這些會議之間的關(guān)聯(lián)把同一個話題的討論串聯(lián)起來就能形成一個完整的決策鏈路。實(shí)現(xiàn)這個功能的技術(shù)路徑是對每次會議的議題進(jìn)行向量化然后在歷史會議中檢索相似議題。如果相似度超過閾值就建立關(guān)聯(lián)。同時用大模型對關(guān)聯(lián)的會議片段做一次摘要生成一個“話題演進(jìn)”的視圖。這個視圖可以展示某個話題從提出到?jīng)Q策的完整過程對于項目管理和知識傳承都很有幫助。不過這個功能有一個前提議題的識別要準(zhǔn)確。如果AI把不相關(guān)的議題錯誤地關(guān)聯(lián)在一起反而會造成困擾。我的經(jīng)驗(yàn)是閾值不要設(shè)得太低寧可漏掉一些關(guān)聯(lián)也不要產(chǎn)生錯誤的關(guān)聯(lián)。另外可以提供一個手動關(guān)聯(lián)的入口讓用戶自己來修正AI的判斷。4. 工程落地中的性能與成本平衡4.1 大模型推理的成本控制AI會議產(chǎn)品的成本大頭在推理。一場一小時的會議轉(zhuǎn)寫文本大概在一萬字左右如果用大模型做紀(jì)要生成和待辦提取一次推理的token消耗量不小。如果每天有幾百場會議成本會非?？捎^?？刂瞥杀镜乃悸酚袔讉€。第一是分級處理不是所有會議都需要用大模型做深度分析。內(nèi)部站會、閑聊性質(zhì)的會議可以用輕量級模型或者規(guī)則引擎處理。只有正式的決策會議、評審會議才值得用大模型。第二是緩存復(fù)用同一場會議如果被多次處理結(jié)果應(yīng)該緩存起來避免重復(fù)推理。第三是prompt優(yōu)化精簡prompt去掉不必要的示例和說明可以顯著減少token消耗。我實(shí)測過一個優(yōu)化案例把紀(jì)要生成的prompt從800token壓縮到300token同時保持輸出質(zhì)量基本不變單次推理成本下降了約40%。這個優(yōu)化的關(guān)鍵是找到prompt中真正影響輸出的部分把那些“錦上添花”的說明去掉。4.2 實(shí)時處理的延遲優(yōu)化實(shí)時字幕和實(shí)時輔助功能對延遲非常敏感。如果用戶說話后兩秒才看到字幕體驗(yàn)會非常割裂。優(yōu)化延遲的手段包括使用流式ASR邊說話邊出字在客戶端做VAD語音活動檢測只把有效語音片段上傳到服務(wù)端使用邊緣節(jié)點(diǎn)做推理減少網(wǎng)絡(luò)傳輸時間。但這里有一個權(quán)衡流式ASR的準(zhǔn)確率通常低于整段ASR因?yàn)槟Ｐ蜎]有看到完整的上下文。我的做法是實(shí)時字幕用流式ASR保證低延遲會議結(jié)束后再用整段ASR重新轉(zhuǎn)寫一遍用高質(zhì)量的結(jié)果替換實(shí)時字幕。這樣用戶在會中看到的是低延遲但可能有些誤差的字幕會后看到的是高準(zhǔn)確率的紀(jì)要。4.3 多模態(tài)信息的融合處理會議場景中除了語音還有共享屏幕的內(nèi)容、聊天區(qū)的文字、參會人的視頻畫面。這些多模態(tài)信息如果能夠融合處理可以產(chǎn)生更豐富的洞察。比如當(dāng)有人在共享屏幕上展示一份數(shù)據(jù)報表時AI可以自動識別報表中的關(guān)鍵數(shù)字并和語音中提到的數(shù)字做交叉驗(yàn)證。但多模態(tài)融合的技術(shù)復(fù)雜度很高而且對算力的要求也更高。我目前的建議是優(yōu)先做好語音和文本的處理多模態(tài)能力可以作為進(jìn)階功能逐步引入。如果要做可以從最簡單的場景開始比如只識別共享屏幕中的文字和語音轉(zhuǎn)寫做關(guān)鍵詞匹配暫時不做深度的語義融合。5. 產(chǎn)品設(shè)計中的幾個關(guān)鍵決策點(diǎn)5.1 用戶隱私與數(shù)據(jù)安全的邊界會議內(nèi)容往往涉及商業(yè)機(jī)密用戶對數(shù)據(jù)安全的敏感度很高。在做AI會議產(chǎn)品時必須明確數(shù)據(jù)的存儲位置、使用范圍和保留期限。我見過一些產(chǎn)品因?yàn)樵谶@方面處理不當(dāng)導(dǎo)致用戶信任度大幅下降。一個務(wù)實(shí)的做法是提供分級的數(shù)據(jù)策略用戶可以選擇“不留存”會議結(jié)束后立即刪除所有數(shù)據(jù)、“僅本地”數(shù)據(jù)只存在用戶設(shè)備上不上傳云端、“云端留存”數(shù)據(jù)存在云端用于后續(xù)檢索和分析。不同的策略對應(yīng)不同的功能集用戶根據(jù)自己的需求選擇。同時在AI處理環(huán)節(jié)要確保數(shù)據(jù)不被用于模型訓(xùn)練這一點(diǎn)需要在隱私政策中明確說明。5.2 人機(jī)協(xié)作的交互設(shè)計AI生成的紀(jì)要和待辦不應(yīng)該直接生效而應(yīng)該經(jīng)過人工確認(rèn)。這個確認(rèn)環(huán)節(jié)的設(shè)計很關(guān)鍵如果確認(rèn)流程太重用戶會覺得麻煩干脆不用如果太輕又容易漏掉AI的錯誤。我的經(jīng)驗(yàn)是把確認(rèn)環(huán)節(jié)設(shè)計成“默認(rèn)采納一鍵修正”的模式。AI生成的結(jié)果默認(rèn)是采納狀態(tài)用戶如果發(fā)現(xiàn)錯誤可以點(diǎn)擊修正。修正的操作要盡量簡單比如直接在下拉菜單里換一個負(fù)責(zé)人或者拖動時間選擇器改一下截止日期。同時提供一個“全部確認(rèn)”的按鈕讓用戶可以在快速瀏覽后一次性確認(rèn)所有內(nèi)容。5.3 與現(xiàn)有辦公工具的集成策略智能辦公中臺不可能孤立存在它需要和現(xiàn)有的辦公工具集成。但集成哪些工具、集成到什么程度是一個需要仔細(xì)考慮的問題。我的建議是優(yōu)先集成那些用戶使用頻率最高的工具比如即時通訊、日歷、任務(wù)管理。集成的深度上先做單向同步會議待辦同步到任務(wù)系統(tǒng)再做雙向同步任務(wù)系統(tǒng)的狀態(tài)更新回寫到會議紀(jì)要。集成的技術(shù)實(shí)現(xiàn)上優(yōu)先使用標(biāo)準(zhǔn)協(xié)議如CalDAV、WebDAV和開放API避免為每個工具單獨(dú)開發(fā)適配層。如果必須做定制適配也要把適配邏輯封裝成獨(dú)立的模塊方便后續(xù)維護(hù)和擴(kuò)展。6. 我踩過的幾個坑和對應(yīng)的解法6.1 說話人分離在交叉發(fā)言時的崩潰前面提到過說話人分離的問題這里展開說一下我踩過的具體坑。在一個多人圓桌討論的場景中兩個人同時說話的情況很常見。通用的聲紋分離模型在這種情況下會頻繁切換說話人標(biāo)簽導(dǎo)致紀(jì)要里出現(xiàn)大量“某人說……”但實(shí)際上這句話是另一個人說的。我試過的解法是在聲紋分離的基礎(chǔ)上加入一個“發(fā)言連續(xù)性”的后處理邏輯。如果兩個說話人標(biāo)簽在短時間內(nèi)頻繁交替就判定為交叉發(fā)言把這段時間的文本合并標(biāo)注為“多人討論”。雖然損失了一些精度但避免了錯誤歸屬帶來的誤導(dǎo)。另外在會前讓參會人依次說一句話做聲紋注冊可以顯著提升分離準(zhǔn)確率。6.2 大模型幻覺在紀(jì)要生成中的表現(xiàn)大模型在生成紀(jì)要時有時會“腦補(bǔ)”一些原文中沒有的內(nèi)容。比如原文只是說“這個方案需要再討論”AI可能會生成“會議決定推遲該方案下次會議繼續(xù)討論”。后者看起來更完整但實(shí)際上是AI自己加的。解決這個問題的方法是在prompt中明確要求“只使用原文中出現(xiàn)的信息不要添加任何推斷”。同時在輸出格式上要求AI對每一條紀(jì)要標(biāo)注來源句的序號方便人工核對。如果某條紀(jì)要找不到對應(yīng)的來源句就應(yīng)該被標(biāo)記為“待確認(rèn)”。6.3 實(shí)時字幕的斷句問題實(shí)時字幕的斷句是一個容易被忽視但很影響體驗(yàn)的細(xì)節(jié)。如果斷句斷得不好用戶讀起來會很費(fèi)勁。比如“我們今天討論一下這個方案的可行性”被斷成“我們今天討論一下這/個方案的可行性”閱讀體驗(yàn)就很差。我的解法是在流式ASR的輸出上疊加一個輕量級的斷句模型根據(jù)語義和標(biāo)點(diǎn)來調(diào)整斷句位置。同時在客戶端做一個小優(yōu)化如果當(dāng)前識別的文本以“的”、“了”、“嗎”等虛詞結(jié)尾就暫不顯示等下一個詞出來再一起顯示。這個優(yōu)化雖然簡單但對閱讀體驗(yàn)的提升很明顯。6.4 待辦事項的負(fù)責(zé)人識別錯誤從會議對話中識別待辦事項的負(fù)責(zé)人是一個比想象中更難的問題。中文表達(dá)中負(fù)責(zé)人經(jīng)常是省略的。比如“這個事情下周搞定”沒有說誰搞定。AI需要根據(jù)上下文推斷可能是上一個發(fā)言的人也可能是某個被點(diǎn)名的人。我的做法是在prompt中要求AI在無法確定負(fù)責(zé)人時標(biāo)注為“待分配”而不是猜測一個。同時在界面上提供一個快速分配的功能讓用戶可以在確認(rèn)環(huán)節(jié)手動指定負(fù)責(zé)人。這個“待分配”的狀態(tài)反而成了一個提醒促使用戶去明確責(zé)任歸屬。7. 對想入局這個方向的團(tuán)隊的一些建議如果你正在考慮做AI會議或者智能辦公中臺方向的產(chǎn)品我有幾個基于實(shí)際經(jīng)驗(yàn)的想法。第一不要試圖做一個大而全的產(chǎn)品從一個具體的場景切入比如“銷售團(tuán)隊的客戶會議紀(jì)要”或者“研發(fā)團(tuán)隊的技術(shù)評審記錄”把這一個場景做深做透比泛泛地做通用會議紀(jì)要更有價值。第二AI能力是手段不是目的用戶不會因?yàn)槟阌蠥I就買單用戶買單是因?yàn)槟憬鉀Q了他的問題。所以產(chǎn)品設(shè)計的出發(fā)點(diǎn)應(yīng)該是“用戶在會議場景中遇到了什么問題”而不是“我們有什么AI能力可以用”。第三數(shù)據(jù)閉環(huán)很重要。AI模型的效果依賴于數(shù)據(jù)而會議場景的數(shù)據(jù)又特別敏感。如何在保護(hù)用戶隱私的前提下建立起有效的數(shù)據(jù)反饋閉環(huán)是一個需要提前思考的問題。我的建議是通過用戶的修正行為來收集反饋比如用戶修改了AI生成的待辦負(fù)責(zé)人這個修正信號就可以用來優(yōu)化模型。這種方式不需要直接獲取用戶的原始數(shù)據(jù)也能達(dá)到優(yōu)化的目的。第四要有耐心。AI會議產(chǎn)品的成熟度曲線比想象中要長。語音轉(zhuǎn)寫的準(zhǔn)確率、說話人分離的精度、大模型的理解能力這些都需要時間打磨。不要指望一上線就完美而是要在真實(shí)使用中持續(xù)迭代。我見過一些團(tuán)隊因?yàn)槌跗谛Ч焕硐刖头艞壛撕芸上?。?shí)際上只要方向是對的每一次迭代都會帶來可感知的提升。最后說一個我自己的體會這個方向最吸引人的地方不是技術(shù)本身有多難而是它真的能改變?nèi)藗兊墓ぷ鞣绞健．?dāng)我看到用戶因?yàn)锳I紀(jì)要而省下了整理會議記錄的時間因?yàn)榇k自動同步而不再遺漏任務(wù)因?yàn)闀h知識庫而快速找到了半年前的決策依據(jù)我就覺得這個事情值得做。技術(shù)最終是要服務(wù)于人的而會議這個場景恰恰是技術(shù)和人的交匯點(diǎn)。