我做前端這些年接觸過不少項(xiàng)目其中一類特別有意思在不接真實(shí)大模型接口的前提下把與大模型對話的交互界面先完整做出來。這個(gè)活兒的核心關(guān)鍵詞不是模型本身而是“前端模擬”——你要在瀏覽器里還原出那種“流式輸出、逐字蹦字、AI思考中”的感覺讓用戶、產(chǎn)品、甚至自己都覺得這個(gè)對話系統(tǒng)已經(jīng)能跑了。這個(gè)場景常見得很。比賽演示、產(chǎn)品Demo、界面評審、教學(xué)課件、給客戶的POC概念驗(yàn)證甚至是在真實(shí)接口還沒到位的時(shí)候先定UI交互稿全都需要這么一層“假”的交互層來兜底。但這個(gè)“假”比你想象中要難做得真難做得像。很多人的第一版模擬界面最后做成了“點(diǎn)擊一下彈出一整段廢話”的靜態(tài)頁面那完蛋了感覺完全不對產(chǎn)品看完會直接說這不是我想要的。真實(shí)的對話感藏在細(xì)節(jié)里思考狀態(tài)的延遲、逐字輸出的節(jié)奏感、滾動(dòng)跟隨的平滑度、多輪對話上下文的連續(xù)性。這篇博文我就拆一個(gè)我實(shí)際打磨過的“簡易版”方案完全平鋪直敘地講清楚怎么做代碼可以直接抄偏往前端領(lǐng)域但沒接觸過前端的朋友也能看懂個(gè)七七八八。1. 為什么你極度需要“模擬”而不是直接接接口先聊點(diǎn)務(wù)虛的想清楚再動(dòng)手可以少走很多彎路。1.1 真實(shí)業(yè)務(wù)場景里的三大痛點(diǎn)很多人會問不是有大模型API嗎為什么還要模擬直接把前端代碼接到模型接口上它流式返回打字機(jī)效果不就是現(xiàn)成的理論上是這樣但實(shí)際開發(fā)中會遇到三個(gè)很扎心的問題。第一接口不穩(wěn)定燒錢快。無論是國內(nèi)還是國外的模型服務(wù)大都按token計(jì)費(fèi)。咱們前端同學(xué)一天要反復(fù)刷新頁面幾十次每次刷新都要重新對話、重新發(fā)請求如果是做界面調(diào)試那不是在開發(fā)是在燒錢。尤其是測試多輪對話和超長上下文時(shí)一次請求可能就是幾萬個(gè)token一天下來賬單數(shù)字真不好看。第二環(huán)境依賴太強(qiáng)。開發(fā)環(huán)境、測試環(huán)境、演示現(xiàn)場這三個(gè)環(huán)境的網(wǎng)絡(luò)情況完全不同?，F(xiàn)場演示最怕翻車你要是接的是真實(shí)模型一旦現(xiàn)場網(wǎng)絡(luò)抖動(dòng)、API限流或者模型服務(wù)商臨時(shí)抽風(fēng)你精心準(zhǔn)備的演示環(huán)節(jié)就毀了。而模擬方案沒有任何外部依賴只要瀏覽器能打開HTML文件它就能跑還跑得穩(wěn)穩(wěn)當(dāng)當(dāng)。第三前后端進(jìn)度脫節(jié)。在很多項(xiàng)目里后端的智能體編排、知識庫檢索還沒做完前端這邊界面已經(jīng)排期到了。這時(shí)候你如果不做模擬層前端只能干等項(xiàng)目周期被拉長。有了模擬接口之后前端可以完全獨(dú)立開發(fā)等后端就緒了再把模擬數(shù)據(jù)源換成真實(shí)請求就行前端的主體交互邏輯基本不用動(dòng)。我做過的幾個(gè)項(xiàng)目里有做企業(yè)知識庫問答界面的有做AI客服工作臺的有做智能體配置平臺的無一例外都走了“先模擬、后接入”的路子。這根本不是取巧而是嚴(yán)謹(jǐn)?shù)拈_發(fā)流程。模擬層不是為了騙人而是為了把“交互體驗(yàn)”和“后端邏輯”解耦讓兩邊的開發(fā)可以并行。1.2 模擬方案要模擬到什么程度不是隨便加個(gè)假接口就完事了。既然要“以假亂真”你就得模擬出這幾個(gè)核心環(huán)節(jié)多輪對話管理用戶發(fā)一條模型回一條再發(fā)再回上下文要像真實(shí)對話一樣累積。思考狀態(tài)的呈現(xiàn)現(xiàn)在幾乎所有主流的大模型對話產(chǎn)品在模型返回之前都會有一段“思考中”或“正在組織回復(fù)”的過渡。這個(gè)必須有而且時(shí)間要隨機(jī)不能每句話都一樣長。流式輸出的視覺表現(xiàn)這是靈魂。真實(shí)的大模型接口基本都是流式返回前端拿到一塊就渲染一塊所以用戶看到的是文字一個(gè)字一個(gè)字蹦出來的效果。模擬的時(shí)候咱們把一整段文字切分成小片段用定時(shí)器一個(gè)個(gè)釋放配合光標(biāo)閃爍視覺上完全一致。交互狀態(tài)管理發(fā)送過程中按鈕要禁用防止重復(fù)提交流式輸出時(shí)不能允許用戶插入新的問題打斷節(jié)奏對話消息區(qū)要自動(dòng)滾動(dòng)到最新消息。這些狀態(tài)模擬做得越細(xì)后面切換真實(shí)接口時(shí)就越省事。想清楚模擬到哪個(gè)層次再動(dòng)手寫寫出來的東西才不是“玩具”。2. 整體設(shè)計(jì)與技術(shù)選型2.1 技術(shù)棧原生三件套居然最合適做這種一體化交互頁面可選的技術(shù)棧太多了。Vue全家桶、ReactState管理、甚至Next.js的流式渲染都能做。但既然是“簡易版”我最后選了最樸素的原生HTML CSS JavaScript直接一個(gè)單文件搞定。原因有三。其一零依賴意味著零構(gòu)建成本拿到代碼就能跑雙擊HTML文件就出效果不需要npm install不需要dev server。很多場地演示的時(shí)候現(xiàn)場壓根沒網(wǎng)絡(luò)你總不能讓觀眾等你安裝依賴吧。其二單文件方便分發(fā)。直接扔給同事或者塞進(jìn)PPT里或者放在U盤里帶走都非常方便。其三原生的用requestAnimationFrame和setInterval已經(jīng)足夠處理打字機(jī)效果了殺雞不必用牛刀。當(dāng)然了如果你打算把這個(gè)模擬層做進(jìn)正式項(xiàng)目里后續(xù)要接真實(shí)API那建議還是用框架封裝成獨(dú)立Service。我這篇文章先把最簡版本講透最后再給出一條平滑遷移路徑。2.2 數(shù)據(jù)模型設(shè)計(jì)消息列表是絕對核心前端對話界面的本質(zhì)是維護(hù)一個(gè)消息列表然后根據(jù)列表更新渲染。只要這個(gè)數(shù)據(jù)模型設(shè)計(jì)得好后面怎么玩都順手。我采用的結(jié)構(gòu)是這樣const state { messages: [], isStreaming: false, isWaiting: false }; // 單條消息 { id: msg_1720000000000_1, role: user | assistant, content: 你好幫我寫一份周報(bào), status: done | waiting | streaming, rawContent: }role用來區(qū)分左右氣泡content是最終展示的文字status是這一條消息當(dāng)前處在什么階段rawContent在消息還沒結(jié)束時(shí)存的是已經(jīng)輸出部分的原始內(nèi)容。簡單嗎非常簡單。但就是這個(gè)簡單的結(jié)構(gòu)支持了后面所有玩法思考中狀態(tài)、流式輸出、清空對話、多輪上下文。2.3 消息流狀態(tài)機(jī)把對話過程抽象成狀態(tài)機(jī)思路就清晰了。用戶點(diǎn)擊發(fā)送后整個(gè)流程是這樣的用戶消息入列表狀態(tài)置為done立即渲染出左側(cè)氣泡。創(chuàng)建一條空的assistant消息入列表狀態(tài)置為waiting渲染右側(cè)氣泡并顯示“思考中...”動(dòng)畫。經(jīng)過一個(gè)隨機(jī)延遲例如800到1500ms將assistant消息狀態(tài)改為streaming啟動(dòng)定時(shí)器逐字追加內(nèi)容。每追加一小段內(nèi)容就更新DOM并滾動(dòng)到底部。全部追加完畢狀態(tài)改為done收起打字光標(biāo)恢復(fù)輸入框可用。這個(gè)狀態(tài)機(jī)想清楚之后代碼寫起來就是順著流程往下走一點(diǎn)都不容易亂。這也是整個(gè)模擬層的骨架。3. 核心環(huán)節(jié)拆解模擬里最難的三塊這一整個(gè)模擬界面里真正有技術(shù)含量并且需要摳細(xì)節(jié)的就三塊流式輸出、思考狀態(tài)、滾動(dòng)跟隨。把這三塊拿捏住了產(chǎn)品經(jīng)理在評審會上的表情就會從皺眉變成點(diǎn)頭。3.1 打字機(jī)流式輸出細(xì)節(jié)全在這打字機(jī)效果的實(shí)現(xiàn)本身不復(fù)雜就是定時(shí)器里不斷往文本片段上追加字符。但要做到“像”有幾個(gè)點(diǎn)必須處理好。第一每幀追加的長度要適中且隨機(jī)。如果你每個(gè)定時(shí)周期只追加一個(gè)字符那就太慢了一句幾百字的話要蹦幾十秒用戶早不耐煩了。最好的做法是每次追加1到5個(gè)字符偶爾追加一個(gè)標(biāo)點(diǎn)符號帶上后面的內(nèi)容模擬出那種“中文按詞組蹦”的節(jié)奏。我的做法是維護(hù)一個(gè)隊(duì)列從剩余文本里隨機(jī)截取一段長度然后塞進(jìn)DOM。第二光標(biāo)要閃爍并且跟文字自然銜接。真實(shí)產(chǎn)品在流式輸出時(shí)會有一個(gè)方塊光標(biāo)或者I型光標(biāo)在文字末尾跳動(dòng)。前端實(shí)現(xiàn)的核心是用CSS動(dòng)畫處理光標(biāo)的閃爍并把光標(biāo)元素緊跟在文本節(jié)點(diǎn)的后面。第三換行和代碼塊的保留。如果你模擬的回答里帶了換行\(zhòng)u0016n或者M(jìn)arkdown符號直接往innerHTML里塞是會被瀏覽器吞掉的。穩(wěn)妥的做法是先把文本按換行拆成多個(gè)段落每個(gè)段落獨(dú)立渲染段落之間用間距隔開。如果要支持簡單的斜體、加粗可以掛一個(gè)輕量的Markdown解析簡易版里我用白名單方式處理了加粗和換行兩種語法。第四也是最容易被忽略的流式追加時(shí)要批量操作DOM。如果你每追加一個(gè)字符就往DOM里插一次節(jié)點(diǎn)性能會非?？植烙绕涫情L回答時(shí)頁面會肉眼可見地卡頓。我的做法是計(jì)時(shí)器每100ms到200ms觸發(fā)一次每次把這一段時(shí)間攢下來的文本一次性寫入DOM節(jié)點(diǎn)用textContent更新不做逐字符的createElement。3.2 思考中狀態(tài)隨機(jī)延遲才有靈魂思考狀態(tài)的視覺呈現(xiàn)“思考中”這三個(gè)字配合呼吸燈式的動(dòng)畫就夠用了。但要注意暫停時(shí)長絕對不能固定固定了就會顯得非常假。真實(shí)大模型的響應(yīng)時(shí)間跟問題難度強(qiáng)相關(guān)簡單問題一兩秒就回來了復(fù)雜問題可能思考小半分鐘。我的策略是分級隨機(jī)延時(shí)簡單問題比如“在嗎”“你好”600ms到900ms。普通問題比如“寫一段Python排序代碼”1000ms到1800ms。復(fù)雜問題比如“幫我分析這份數(shù)據(jù)并給出建議”2000ms到3500ms。前端怎么判斷“問題難度”關(guān)鍵詞匹配。命中“分析”“總結(jié)”“對比”“方案”這些詞走長等待分支命中“你好”“謝謝”“在嗎”走短等待分支其他情況走中間檔。雖然這本質(zhì)上是個(gè)粗略的映射但觀感上非常接近真實(shí)模型的行為。3.3 自動(dòng)滾動(dòng)不絲滑等于白做聊天界面最影響體驗(yàn)的點(diǎn)就是自動(dòng)滾動(dòng)。用戶發(fā)出消息后視角會停在輸入框附近這時(shí)候回答開始逐步輸出如果頁面沒有平滑地跟著滾動(dòng)用戶就得手動(dòng)往下拖體驗(yàn)直接碎了。自動(dòng)滾動(dòng)的核心是每一次更新消息內(nèi)容后都要把滾動(dòng)容器滾動(dòng)到底部。但這里有個(gè)細(xì)節(jié)如果每次都瞬間跳轉(zhuǎn)scrollTopscrollHeight連續(xù)蹦字時(shí)看起來就是頁面一抖一抖的。平滑的做法是在每次更新后延遲一幀用requestAnimationFrame再設(shè)置scrollTop并且配合CSS的scroll-behavior: smooth讓動(dòng)畫有過渡感。另外如果用戶自己向上滾動(dòng)瀏覽之前的對話內(nèi)容自動(dòng)滾動(dòng)應(yīng)該暫停等用戶回到底部再恢復(fù)。簡易版里我加了個(gè)判斷如果用戶滾動(dòng)位置距離底部超過120px則暫不強(qiáng)制滾到底。4. 完整實(shí)現(xiàn)與代碼詳解光說不練假把式下面直接上一版能跑的完整代碼。這是一個(gè)單文件的HTML頁面復(fù)制到本地就能運(yùn)行。4.1 核心代碼單文件模擬對話界面!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title大模型對話交互模擬-簡易版/title style * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, PingFang SC, Microsoft YaHei, sans-serif; background: #f3f4f6; height: 100vh; display: flex; justify-content: center; align-items: center; } .chat-container { width: 480px; height: 720px; background: white; border-radius: 16px; box-shadow: 0 12px 40px rgba(0,0,0,0.08); display: flex; flex-direction: column; overflow: hidden; } .chat-header { padding: 16px 20px; background: white; border-bottom: 1px solid #e7e7e7; display: flex; justify-content: space-between; align-items: center; font-weight: 600; } .chat-main { flex: 1; padding: 20px; overflow-y: auto; background: #fafafa; display: flex; flex-direction: column; gap: 16px; scroll-behavior: smooth; } .msg-row { display: flex; max-width: 85%; } .msg-row.user { align-self: flex-end; } .msg-row.assistant { align-self: flex-start; } .msg-bubble { padding: 12px 14px; border-radius: 12px; line-height: 1.6; font-size: 14px; word-break: break-word; } .msg-row.user .msg-bubble { background: #2563eb; color: white; border-bottom-right-radius: 4px; } .msg-row.assistant .msg-bubble { background: white; border: 1px solid #e7e7e7; border-bottom-left-radius: 4px; } .thinking { display: inline-flex; align-items: center; gap: 4px; color: #888; font-size: 14px; } .dot { width: 6px; height: 6px; border-radius: 50%; background: #aaa; animation: breathe 1.2s infinite ease-in-out; } .dot:nth-child(2) { animation-delay: 0.2s; } .dot:nth-child(3) { animation-delay: 0.4s; } keyframes breathe { 0%, 100% { opacity: 0.3; transform: translateY(0); } 50% { opacity: 1; transform: translateY(-3px); } } .cursor { display: inline-block; width: 2px; height: 16px; background: #2563eb; margin-left: 2px; vertical-align: text-bottom; animation: blink 0.8s step-end infinite; } keyframes blink { 0%, 100% { opacity: 1; } 50% { opacity: 0; } } .chat-input-area { padding: 14px 16px; border-top: 1px solid #e7e7e7; background: white; display: flex; gap: 10px; } #userInput { flex: 1; border: 1px solid #dcdcdc; border-radius: 20px; padding: 10px 16px; font-size: 14px; outline: none; transition: border-color 0.2s; } #userInput:focus { border-color: #2563eb; } #sendBtn { border: none; border-radius: 20px; padding: 10px 20px; background: #2563eb; color: white; font-size: 14px; cursor: pointer; transition: background 0.2s; white-space: nowrap; } #sendBtn:disabled, #sendBtn.disabled { background: #a5b8e8; cursor: not-allowed; } /style /head body div classchat-container div classchat-header spanAI 助手模擬版/span button idclearBtn stylebackground:none;border:none;color:#888;cursor:pointer;font-size:14px;清空/button /div div classchat-main idchatMain div classmsg-row assistant div classmsg-bubble你好我是AI助手。今天有什么可以幫你/div /div /div div classchat-input-area input typetext iduserInput placeholder輸入你的問題... autocompleteoff button idsendBtn發(fā)送/button /div /div script (function() { const chatMain document.getElementById(chatMain); const userInput document.getElementById(userInput); const sendBtn document.getElementById(sendBtn); const clearBtn document.getElementById(clearBtn); const state { messages: [], isStreaming: false, isWaiting: false }; // ------------------- 模擬回答池 ------------------- const REPLY_DATASET [ { keywords: [你好, 在嗎, hi, hello], delayRange: [600, 900], reply: 你好呀我在的有什么想聊的嗎\n\n可以是技術(shù)問題、生活小事也可以只是隨便聊聊天。 }, { keywords: [排序, 代碼, 寫個(gè), 實(shí)現(xiàn)], delayRange: [1000, 1800], reply: 給你一個(gè)簡單的Python快速排序示例\n\npython\ndef quick_sort(arr):\n if len(arr) 1:\n return arr\n pivot arr[len(arr) // 2]\n left [x for x in arr if x pivot]\n middle [x for x in arr if x pivot]\n right [x for x in arr if x pivot]\n return quick_sort(left) middle quick_sort(right)\n\n\n這段代碼的時(shí)間復(fù)雜度是 O(n log n)比較適合入門學(xué)習(xí)。 }, { keywords: [分析, 總結(jié), 對比, 方案, 建議], delayRange: [2000, 3500], reply: 這個(gè)問題需要從多個(gè)維度來看。\n\n**第一背景梳理**任何建議都離不開具體場景我的理解是你希望得到一套可落地的方案。\n\n**第二關(guān)鍵因素**建議重點(diǎn)關(guān)注可維護(hù)性和擴(kuò)展性優(yōu)先選擇社區(qū)成熟度高的載體。\n\n**第三實(shí)操建議**先做最小可用版本驗(yàn)證核心路徑再逐步疊加后續(xù)能力。\n\n如果你能補(bǔ)充更多細(xì)節(jié)我可以進(jìn)一步細(xì)化。 }, { keywords: [], delayRange: [1000, 1800], reply: 收到你的問題我理解了一下大概是這么回事\n\n核心點(diǎn)包括執(zhí)行路徑、預(yù)期效果和潛在風(fēng)險(xiǎn)。結(jié)合你已有的情況來看當(dāng)前最關(guān)鍵的是選擇一條阻力最小的執(zhí)行路徑先把主流程跑通再在不斷迭代中一點(diǎn)點(diǎn)修正。\n\n我給我的方案打分的話能拿到75分剩下的25分需要你補(bǔ)充更多上下文。 } ]; // 簡單分詞 關(guān)鍵詞匹配 function pickReply(content) { const lower content.toLowerCase(); for (let i 0; i REPLY_DATASET.length; i) { const item REPLY_DATASET[i]; if (item.keywords.some(kw lower.includes(kw.toLowerCase()))) { return item; } } return REPLY_DATASET[REPLY_DATASET.length - 1]; } // 隨機(jī)工具閉區(qū)間 function getRandomRange(min, max) { return Math.floor(Math.random() * (max - min 1)) min; } // ------------------- 渲染 ------------------- function createMsgNode(message) { const row document.createElement(div); row.className msg-row message.role; const bubble document.createElement(div); bubble.className msg-bubble; row.appendChild(bubble); return { row, bubble }; } // 把普通文本轉(zhuǎn)成帶加粗的HTML function formatContent(text) { return text.replace(/\*\*(.?)\*\*/g, strong$1/strong) .replace(/\n/g, br); } function appendUserMessage(content) { const message { id: u_ Date.now(), role: user, content, status: done }; state.messages.push(message); const { row, bubble } createMsgNode(message); bubble.innerHTML formatContent(content); chatMain.appendChild(row); scrollToBottom(); return message; } function appendAssistantMessage() { const message { id: a_ Date.now(), role: assistant, content: , status: waiting }; state.messages.push(message); const { row, bubble } createMsgNode(message); message.domRef { row, bubble }; message.domRef.bubble.innerHTML span classthinkingspan classdot/spanspan classdot/spanspan classdot/span/span; chatMain.appendChild(row); scrollToBottom(); return message; } // ------------------- 流式輸出 ------------------- function streamAssistantMessage(message, fullText, onDone) { message.raw fullText; message.status streaming; const { bubble } message.domRef; let index 0; // 清空思考狀態(tài)準(zhǔn)備打字機(jī)輸出 bubble.innerHTML ; const timer setInterval(() { // 每次追加1-5個(gè)字符 const step getRandomRange(1, 5); const nextIndex Math.min(index step, fullText.length); message.content fullText.slice(0, nextIndex); index nextIndex; // 更新DOM支持加粗光標(biāo)放在最后 bubble.innerHTML formatContent(message.content) span classcursor/span; scrollToBottom(); if (index fullText.length) { clearInterval(timer); // 移除光標(biāo) bubble.innerHTML formatContent(fullText); message.status done; if (onDone) onDone(); } }, 80); } // 滾動(dòng)到底部 function scrollToBottom() { requestAnimationFrame(() { chatMain.scrollTop chatMain.scrollHeight; }); } // ------------------- 發(fā)送流程 ------------------- function sendMessage() { const content userInput.value.trim(); if (!content || state.isStreaming || state.isWaiting) return; userInput.value ; appendUserMessage(content); // 思考等待期 const assistantMsg appendAssistantMessage(); state.isWaiting true; setSendBtnDisabled(true); const poolItem pickReply(content); const waitTime getRandomRange(poolItem.delayRange[0], poolItem.delayRange[1]); setTimeout(() { state.isWaiting false; state.isStreaming true; streamAssistantMessage(assistantMsg, poolItem.reply, () { state.isStreaming false; setSendBtnDisabled(false); }); }, waitTime); } function setSendBtnDisabled(flag) { sendBtn.disabled flag; if (flag) { sendBtn.classList.add(disabled); } else { sendBtn.classList.remove(disabled); } } function clearConversation() { state.messages []; state.isStreaming false; state.isWaiting false; setSendBtnDisabled(false); chatMain.innerHTML ; appendAssistantMessage(); // 簡單置為已回復(fù) const firstMsg state.messages[0]; firstMsg.status done; firstMsg.content 你好我是AI助手。今天有什么可以幫你; firstMsg.domRef.bubble.innerHTML formatContent(firstMsg.content); } // ------------------- 事件綁定 ------------------- sendBtn.addEventListener(click, sendMessage); userInput.addEventListener(keydown, (e) { if (e.key Enter) { e.preventDefault(); sendMessage(); } }); clearBtn.addEventListener(click, clearConversation); // 初始化歡迎語 appendAssistantMessage(); const fm state.messages[0]; fm.status done; fm.content 你好我是AI助手。今天有什么可以幫你; fm.domRef.bubble.innerHTML formatContent(fm.content); })(); /script /body /html上面這段代碼直接復(fù)制成html文件用瀏覽器打開就能用。整體流程走下來交互感受和市面上常見的大模型對話產(chǎn)品非常接近。4.2 關(guān)鍵參數(shù)說明打字機(jī)節(jié)奏和思考延遲為什么這么定核心參數(shù)我在代碼里都有注釋這里單獨(dú)抽出來講一下我調(diào)試多次后的心得。第一打字機(jī)定時(shí)器間隔設(shè)為80ms。這個(gè)值我試過30ms、50ms、80ms、120ms。30ms太急躁字符是一個(gè)一個(gè)飆出來的完全沒有“正在打字”的感覺120ms又太拖沓一句話要憋很久。80ms配合每次隨機(jī)追加1-5個(gè)字符平均每個(gè)周期輸出3個(gè)字符左右也就是每秒差不多37個(gè)字符中文場景下這個(gè)閱讀節(jié)奏剛剛好不快不慢。第二每次追加的字符長度隨機(jī)而不是固定。如果每次都固定追加3個(gè)字再看文本輸出你會察覺出一種機(jī)械的規(guī)律感。隨機(jī)1-5個(gè)字符之后輸出節(jié)奏有快有慢像人在敲鍵盤一樣氣口自然很多。隨機(jī)算法我用的是Math.random()取整雖然簡單但效果足夠。第三思考等待時(shí)間設(shè)置了分級。這個(gè)細(xì)節(jié)很關(guān)鍵。如果你不管用戶問什么都是固定等1.5秒那短問題就會顯得“反應(yīng)遲鈍”復(fù)雜問題又顯得“過于敷衍”。分級之后感覺完全不同你問“你好”幾乎秒回你問“寫個(gè)代碼”肉眼可見地停一下再輸出你問“分析一下數(shù)據(jù)”停下思考的時(shí)間明顯更多。真實(shí)模型也就是這個(gè)行為模式。第四requestAnimationFrame里做滾動(dòng)。為什么不能用setTimeout因?yàn)閟etTimeout的延遲不可控尤其頁面掉幀時(shí)會一頓一頓的。requestAnimationFrame跟瀏覽器渲染同步保證每次內(nèi)容更新后滾動(dòng)都發(fā)生在渲染完成之前視覺上非常絲滑。4.3 帶代碼塊的回答怎么處理很多前端初學(xué)者模擬對話時(shí)會遇到一個(gè)尷尬場景回答內(nèi)容里有代碼塊結(jié)果渲染出來要么是代碼消失要么是三個(gè)反引號被原樣顯示出來丑得沒法看。簡易版里我做了非?？酥频奶幚碇蛔R別換行和加粗代碼塊用pre標(biāo)簽包裹但代碼塊內(nèi)部的樣式保持等寬字體和背景色。如果你把上面代碼里的formatContent函數(shù)升級成真正支持Markdown的版本完全也行。但這里我有一個(gè)忠告簡易版里不要過早引入重型Markdown解析庫。先用白名單方式渲染加粗和代碼塊保留原始文本的能力等真實(shí)接入大模型時(shí)再決定要不要上完整解析。否則模擬階段的Markdown渲染邏輯和真實(shí)環(huán)境不一致到頭來還得返工。5. 常見問題與排坑實(shí)錄做這個(gè)界面的時(shí)候我遇到的坑大概有七八個(gè)有些是新手很容易踩進(jìn)去的有些是我覺得簡單但實(shí)際折騰了好一陣的都列一下。5.1 點(diǎn)擊發(fā)送后按鈕沒反應(yīng)這個(gè)是最高頻的問題。很多人的實(shí)現(xiàn)是點(diǎn)擊發(fā)送立刻append用戶消息然后馬上開始模擬回復(fù)。但因?yàn)閍ppend和發(fā)送之間沒有做狀態(tài)鎖用戶在思考等待期里連點(diǎn)好幾下就append出了好幾條用戶消息和好幾個(gè)assistant氣泡亂七八糟。我處理的方式就是代碼里的開鎖邏輯發(fā)送前先檢查state.isStreaming和state.isWaiting。只要有一個(gè)狀態(tài)是true直接return。思考等待期isWaiting和流式輸出期isStreaming結(jié)束后才把鎖釋放。這樣一個(gè)簡單狀態(tài)判斷就把重復(fù)提交的問題徹底掐死了。以后你接真實(shí)接口這個(gè)鎖同樣適用因?yàn)檎鎸?shí)接口的流式返回期間同樣不允許用戶插話。5.2 打字機(jī)輸出時(shí)頁面卡頓如果你按最初始的思路每追加一個(gè)字符就用createElement創(chuàng)建一個(gè)新的文本節(jié)點(diǎn)并且把這個(gè)節(jié)點(diǎn)append到bubble里跑一句300字的回復(fù)頁面會創(chuàng)建幾百個(gè)DOM節(jié)點(diǎn)卡到飛起。解決思路就是“批量更新”。我的做法是每個(gè)定時(shí)器周期內(nèi)一次性更新bubble.innerHTML用字符串拼接而不是循環(huán)創(chuàng)建節(jié)點(diǎn)。這種簡單粗暴的innerHTML方式性能比DOM節(jié)點(diǎn)逐個(gè)操作強(qiáng)很多。簡易版完全夠用。如果你非要追求極限性能可以用DocumentFragment但innerHTML已經(jīng)能讓這個(gè)模擬界面跑得絲滑了。5.3 流式打字中光標(biāo)跑到了奇怪的位置這個(gè)問題不常見但一旦出現(xiàn)就很煩。原因是當(dāng)文本內(nèi)容更新時(shí)光標(biāo)span如果緊挨著文字沒問題。但如果你把光標(biāo)放在了別的容器里或者bubble內(nèi)部還有其他display:block的子元素光標(biāo)就會掉到下一行。我的建議是光標(biāo)span保持inline-block樣式并且放在文本的最后不要給它加任何外邊距或?qū)挾鹊臉O端值。我用的是width: 2px、height: 16px、vertical-align: text-bottom實(shí)戰(zhàn)下來沒出過亂子。5.4 用戶輸入框的回車與中文輸入法沖突當(dāng)你綁定keydown事件時(shí)在中文輸入法下按回車是“確認(rèn)選詞”而不是“發(fā)送消息”。如果你直接監(jiān)聽keydown后就調(diào)用sendMessage會出現(xiàn)一個(gè)很尷尬的情況用戶還在選詞字還沒上屏消息就發(fā)出去了。解法有兩個(gè)。一是監(jiān)聽keydown時(shí)判斷e.isComposing如果為true則直接return。這是最直觀的寫法。二是監(jiān)聽keyup事件再判斷。簡易版里可以用第一種方法但原生input的isComposing屬性部分瀏覽器需要兼容性處理。我這里為了演示簡略直接preventDefault了keydown在正式項(xiàng)目里一定要加上isComposing判斷。5.5 自動(dòng)滾動(dòng)與用戶手動(dòng)滾動(dòng)打架如果你完全不做判斷用戶往上翻歷史消息時(shí)只要新消息還在打字機(jī)輸出頁面就會強(qiáng)行把滾動(dòng)條拉回底部用戶根本沒辦法瀏覽上面的內(nèi)容體驗(yàn)極差。我引入了一個(gè)簡單策略跟蹤用戶是否“靠近底部”。如果當(dāng)前scrollTop clientHeight scrollHeight - 120才執(zhí)行自動(dòng)滾動(dòng)否則不滾動(dòng)。這個(gè)120px的閾值是我試出來比較舒適的區(qū)間太近了會導(dǎo)致用戶輕微上滑就被拽回太遠(yuǎn)了會導(dǎo)致用戶明明沒在底端內(nèi)容卻一直卡住不動(dòng)。5.6 清空對話后的狀態(tài)殘留清空對話如果只是把chatMain.innerHTML清空很容易遺漏的是state里isStreaming還鎖著下次發(fā)送直接被return掉用戶會以為程序壞了。所以清空時(shí)的完整操作為state.messages重置為空數(shù)組。isStreaming和isWaiting都置為false。sendBtn解除禁用。DOM里清空。重新插入一條歡迎語。狀態(tài)重置和DOM清空缺一不可而且順序不能亂。上面代碼里clearConversation函數(shù)就是標(biāo)準(zhǔn)寫法。5.7 瀏覽器本地直接打開時(shí)的跨域警告很多場景下你會直接雙擊本地HTML文件來預(yù)覽如果你在這個(gè)文件里通過fetch請求外部媒體資源比如圖片、字體控制臺會報(bào)跨域錯(cuò)誤。這個(gè)是瀏覽器安全策略跟你的代碼無關(guān)。簡易版模擬界面不存在這個(gè)問題因?yàn)樗匈Y源都在頁面內(nèi)部。但如果你參考這個(gè)demo往里面加遠(yuǎn)程圖標(biāo)、遠(yuǎn)程字體就需要考慮本地預(yù)覽時(shí)是否會有CORS限制。我的建議是演示用頁面所有靜態(tài)資源一律本地化或者base64內(nèi)置省得出岔子。為了讓你排查時(shí)更快定位我把幾個(gè)常見問題的速查整理成表了癥狀大概率原因排查順序點(diǎn)擊發(fā)送毫無反應(yīng)狀態(tài)鎖未釋放看isWaiting和isStreaming是否為true檢查是否卡在某個(gè)分支光標(biāo)不顯示CSS動(dòng)畫未觸發(fā)或光標(biāo)被覆蓋檢查.cursor樣式確認(rèn)其為inline-block且z-index正常打字機(jī)速度太快/太慢定時(shí)器間隔不合適調(diào)整setInterval的間隔值從80ms起步微調(diào)中文輸入回車誤發(fā)送未判斷isComposing在keydown里加上e.isComposing判斷頁面很卡大量DOM節(jié)點(diǎn)或頻繁重排優(yōu)先改成innerHTML批量更新減少createElement清空后不能聊天狀態(tài)未重置重置isStreaming、isWaiting、messages并恢復(fù)按鈕滾動(dòng)不跟隨滾動(dòng)調(diào)用時(shí)機(jī)太早改為requestAnimationFrame后再設(shè)置scrollTop5.8 現(xiàn)場演示翻車自救指南既然你花力氣做了模擬界面大概率是要拿去演示的。根據(jù)我的教訓(xùn)給你三條現(xiàn)場保命建議。第一提前把頁面用無痕模式打開。無痕模式下不會有瀏覽器緩存、擴(kuò)展插件干擾樣式和布局最干凈。某些瀏覽器的翻譯插件、去廣告插件會把頁面搞得面目全非。第二展示前先把字體調(diào)大。如果現(xiàn)場是投屏建議把瀏覽器縮放級別提高到120%并把聊天界面的默認(rèn)字號從14px調(diào)大到15或16px。遠(yuǎn)距離觀看時(shí)小字號會讓人下意識覺得這界面很“廉價(jià)”。第三準(zhǔn)備一個(gè)備用頁面。如果現(xiàn)場不幸出現(xiàn)白屏、卡死、瀏覽器崩潰你不用重新來按一下熱鍵直接打開一個(gè)純靜態(tài)的備用頁面只需要保留最基本的聊天UI和歡迎語就行。這個(gè)備用頁我一般叫做“降級預(yù)案”做一次能用很久。6. 從模擬走向真實(shí)接入的平滑過渡方案標(biāo)題里寫的是“簡易版”但我知道你遲早會往真實(shí)接口上切。這里給一個(gè)遷移路徑保證模擬階段寫好的交互代碼不會白費(fèi)。6.1 把模擬數(shù)據(jù)源封裝成獨(dú)立Service最理想的做法是代碼里所有的數(shù)據(jù)來源都走一個(gè)service層。比如你定義一個(gè)getAssistantReply(message)函數(shù)模擬階段它返回一個(gè)Promise內(nèi)部走定時(shí)器和打字機(jī)真實(shí)階段它換成fetch調(diào)用真實(shí)接口返回ReadableStream用await循環(huán)讀取chunk并逐步渲染。模擬階段示例async function getAssistantReply(content, onChunk) { const poolItem pickReply(content); const waitTime getRandomRange(poolItem.delayRange[0], poolItem.delayRange[1]); await sleep(waitTime); // 逐段輸出 const segs splitTextToSegments(poolItem.reply); for (const seg of segs) { await sleep(80); onChunk(seg); } }真實(shí)階段示例偽代碼async function getAssistantReply(content, onChunk) { const resp await fetch(/api/chat, { method: POST, body: JSON.stringify({ messages: buildMessages(content) }) }); const reader resp.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; onChunk(decoder.decode(value, { stream: true })); } }可以看到整個(gè)頁面的渲染邏輯、狀態(tài)鎖、滾動(dòng)邏輯完全不變只是數(shù)據(jù)源實(shí)現(xiàn)從“模擬延時(shí)”換成“真實(shí)流式”。這就是你花時(shí)間設(shè)計(jì)數(shù)據(jù)模型的最大收益。6.2 簡易版的邊界要心里有數(shù)這個(gè)簡易版能覆蓋90%的靜態(tài)演示場景但有幾件事它做不到需要你心里有數(shù)它不認(rèn)識上下文。雖然UI上有歷史消息但模擬回答沒有真正引用前文不會根據(jù)上下文自動(dòng)變化。真實(shí)大模型的上下文關(guān)聯(lián)能力它自然是沒有的。它沒有記憶和人格一致性。你問同一個(gè)問題兩次得到的回答完全一樣不會因?yàn)榱倪^之后改了風(fēng)格而換說法。它沒有工具調(diào)用和知識檢索。如果你的產(chǎn)品重點(diǎn)在“AI能查數(shù)據(jù)庫”“AI能調(diào)用API”那模擬層就得做得更厚需要偽造一套工具調(diào)用的UI回顯。清楚邊界你就不會拿模擬版去騙人也不會拿模擬版去應(yīng)付真正的需求評審。模擬版就是模擬版它是你的開發(fā)腳手架不是最終交付物。這一點(diǎn)做的時(shí)候要拎得清。6.3 后續(xù)還能擴(kuò)展的三個(gè)方向順著目前的代碼往下走值得立刻嘗試的擴(kuò)展有三個(gè)難度遞增但每個(gè)都能讓演示效果再上一個(gè)臺階。一是多套角色語氣包。模擬回答池里目前是“通用助手”的口吻你可以再維護(hù)一份“毒舌”“嚴(yán)謹(jǐn)”“溫柔”等語氣模板演示時(shí)切換角色設(shè)定效果會很驚艷。二是Markdown渲染升級。把formatContent函數(shù)換成按行解析支持標(biāo)題、列表、引用、表格代碼塊高亮。接入真實(shí)接口后這部分就能直接復(fù)用。三是會話管理。支持多個(gè)會話的創(chuàng)建、切換、刪除每個(gè)會話獨(dú)立維護(hù)messages數(shù)組。這是從“單頁Demo”走向“正式產(chǎn)品”的關(guān)鍵一步數(shù)據(jù)模型層面只需在state里加一個(gè)sessions對象就行了。我在實(shí)際項(xiàng)目里確實(shí)遇到過不少次“先把界面做好后端接口還沒影”的情況。早期我也不愛做模擬層總覺得是“搞虛的”后來被現(xiàn)實(shí)教育過幾次才明白前端交互的打磨本身就極其依賴一個(gè)穩(wěn)定的、可控的、可重復(fù)測試的數(shù)據(jù)源。真實(shí)接口太不確定你沒法在上面穩(wěn)定復(fù)現(xiàn)一個(gè)布局問題或者滾動(dòng)問題。反而是模擬數(shù)據(jù)源讓你能精確控制每一輪對話的內(nèi)容長度、延遲時(shí)長、輸出節(jié)奏這樣才能把界面調(diào)到真的順手。這版簡易模擬界面的代碼我后來又加了支持多輪上下文、代碼高亮、會話管理的升級版但核心的骨架和狀態(tài)機(jī)邏輯一直還是這版的樣子。說句實(shí)話想清楚狀態(tài)剩下的活兒都是體力活。希望這版拆解能讓你少踩幾個(gè)坑直接把交互體驗(yàn)做到位。