先從實(shí)際工作中的一個(gè)場景說起。開發(fā)一個(gè)帶大模型對話功能的頁面時(shí)最尷尬的階段往往是前端寫完了后端還沒聯(lián)調(diào)或者產(chǎn)品想先看效果但API密鑰還沒申請下來。如果你也遇到過這種局面那么前端模擬和大模型交互的界面這個(gè)需求就非常典型——它不需要你真接大模型而是用一套本地模擬邏輯把對話交互的完整體驗(yàn)先跑起來既能用來做UI驗(yàn)證和交互走查也能作為后續(xù)接入真實(shí)接口的過渡骨架。這篇文章要分享的就是一個(gè)簡易版實(shí)現(xiàn)方案純前端完成聊天氣泡、用戶輸入、模擬回復(fù)、流式輸出、加載狀態(tài)這些核心交互不依賴任何后端服務(wù)數(shù)據(jù)層用一個(gè)可替換的模擬響應(yīng)池。適合正在做AI對話類產(chǎn)品的前端開發(fā)者、需要快速出Demo的原型設(shè)計(jì)師以及想搞清楚對話式交互的前端到底怎么組織代碼的初學(xué)者。1. 整體方案設(shè)計(jì)為什么選擇前端模擬而不是直接接API很多第一次接觸這個(gè)需求的人第一反應(yīng)是直接調(diào)大模型接口不就行了但在實(shí)際開發(fā)中這個(gè)思路往往走不通至少在最早期走不通。1.1 三種常見場景下的真實(shí)痛點(diǎn)第一種場景是接口還沒就緒。大模型API的申請、審核、開通流程通常需要一段時(shí)間就算接口開通了還需要處理鑒權(quán)、配額限制、模型配置等問題。前端不能干等著。第二種場景是UI評審階段。產(chǎn)品經(jīng)理和設(shè)計(jì)團(tuán)隊(duì)要確認(rèn)的是交互流程和視覺呈現(xiàn)而不是模型回答的準(zhǔn)確性。用一個(gè)可控的模擬數(shù)據(jù)源反而能讓每個(gè)評審場景都精確復(fù)現(xiàn)——想演示用戶問天氣怎么樣模擬響應(yīng)池里寫好對應(yīng)答案就行不用依賴真實(shí)模型的隨機(jī)輸出。第三種場景是自動(dòng)化測試?；貧w測試時(shí)如果依賴真實(shí)API每次調(diào)用的響應(yīng)時(shí)間和返回內(nèi)容都不可控測試用例會(huì)變得極其不穩(wěn)定。模擬接口能讓測試結(jié)果具備可重復(fù)性。注意模擬方案的目標(biāo)不是替代真實(shí)API而是在真實(shí)API不可用或不便使用時(shí)為前端開發(fā)提供一個(gè)穩(wěn)定可靠的交互底座。1.2 整體技術(shù)選型與架構(gòu)思路這個(gè)項(xiàng)目名為簡易版意味著不引入重型框架或復(fù)雜狀態(tài)管理庫。我的選型原則是原生三件套為主可擴(kuò)展架構(gòu)為輔HTML負(fù)責(zé)結(jié)構(gòu)CSS負(fù)責(zé)視覺JavaScript負(fù)責(zé)交互邏輯數(shù)據(jù)層與視圖層分離模擬響應(yīng)池獨(dú)立成模塊方便后續(xù)替換成真實(shí)fetch調(diào)用用setTimeout模擬流式輸出的時(shí)間間隔用Promise封裝異步邏輯保證代碼風(fēng)格與真實(shí)API調(diào)用一致這個(gè)架構(gòu)在后期切真實(shí)接口時(shí)有個(gè)明顯好處只需替換數(shù)據(jù)層的實(shí)現(xiàn)視圖層的渲染邏輯完全不用動(dòng)。我見過很多人做模擬界面時(shí)把模擬數(shù)據(jù)直接寫死在渲染函數(shù)里等到接真實(shí)接口時(shí)發(fā)現(xiàn)代碼耦合嚴(yán)重等于重寫一遍。2. 界面搭建與視覺實(shí)現(xiàn)要點(diǎn)做對話界面視覺層不是錦上添花而是直接影響用戶對產(chǎn)品的第一判斷。一個(gè)粗糙的界面會(huì)讓整個(gè)Demo的可信度大打折扣。2.1 整體頁面布局拆解簡易版的布局采用經(jīng)典三段式結(jié)構(gòu)頂部導(dǎo)航區(qū)展示對話主題或產(chǎn)品名稱這里我建議用AI 對話助手這類通用名稱方便后續(xù)復(fù)用中間消息區(qū)聊天氣泡的滾動(dòng)容器展示用戶消息和AI回復(fù)底部輸入?yún)^(qū)文本框、發(fā)送按鈕以及一個(gè)正在生成的狀態(tài)提示這個(gè)布局幾乎涵蓋了所有對話類產(chǎn)品的基礎(chǔ)骨架。消息區(qū)需要設(shè)置flex: 1和overflow-y: auto保證消息多時(shí)可以滾動(dòng)輸入?yún)^(qū)固定在底部用flex-shrink: 0防止被壓縮。2.2 聊天氣泡的視覺細(xì)節(jié)與實(shí)現(xiàn)方案聊天氣泡是對話界面的視覺核心左右分欄的布局能直觀區(qū)分消息方向。實(shí)現(xiàn)時(shí)需要注意幾個(gè)容易被忽視的細(xì)節(jié)。氣泡的最大寬度建議設(shè)置為容器寬度的70%左右。太窄會(huì)導(dǎo)致長文本頻繁換行閱讀體驗(yàn)差太寬則會(huì)讓消息區(qū)顯得雜亂。代碼實(shí)現(xiàn)上可以用max-width: 70%配合word-break: break-word處理長單詞和URL。氣泡的圓角處理也有講究。我的習(xí)慣是左側(cè)AI消息的圓角為右上角偏小貼近頭像位置削弱邊界感右側(cè)用戶消息的圓角為左上角偏小整體呈現(xiàn)一種聊天氣泡指向發(fā)送方的視覺效果。這個(gè)細(xì)節(jié)看起來微小但對整體質(zhì)感的影響很明顯。2.3 消息時(shí)間戳與頭像的適配處理時(shí)間戳是容易被忽略但很重要的細(xì)節(jié)。建議采用12小時(shí)制或24小時(shí)制的簡短格式比如14:32不需要顯示完整日期除非消息跨越了多天。頭像方面簡易版可以直接用純色圓形文字首字母的方案避免引入圖片資源。實(shí)操心得頭像和氣泡之間留6-8px的間距視覺上更透氣。如果消息區(qū)背景色偏淺AI氣泡用淺灰、用戶氣泡用主題色對比度更清晰。3. 模擬交互的核心邏輯與狀態(tài)管理這一部分是整個(gè)項(xiàng)目的重頭戲。模擬交互不只是點(diǎn)一下按鈕彈出一句話而是要模擬出真實(shí)對話的節(jié)奏感和狀態(tài)變化。3.1 響應(yīng)池結(jié)構(gòu)設(shè)計(jì)與數(shù)據(jù)組織模擬響應(yīng)池是整個(gè)模擬邏輯的數(shù)據(jù)基礎(chǔ)。結(jié)構(gòu)設(shè)計(jì)上我建議采用關(guān)鍵詞匹配 默認(rèn)兜底策略const responsePool { greeting: { keywords: [你好, 您好, hi, hello], reply: 你好我是AI助手有什么可以幫你的嗎 }, weather: { keywords: [天氣, 下雨, 溫度], reply: 抱歉我是模擬助手暫時(shí)無法獲取實(shí)時(shí)天氣信息。真實(shí)接入API后我將為你提供準(zhǔn)確數(shù)據(jù)。 }, help: { keywords: [幫助, 怎么用, 功能], reply: 你可以向我提問任何問題我會(huì)盡力回答。在開發(fā)模式下我的回復(fù)是本地模擬的。 }, default: { reply: 這是一個(gè)模擬回復(fù)。接入真實(shí)大模型API后我會(huì)根據(jù)你的輸入生成更智能的回答。 } };匹配邏輯上采用遍歷關(guān)鍵詞數(shù)組的方式命中即返回對應(yīng)回復(fù)都不匹配則走default兜底。數(shù)據(jù)層用getMockResponse(input)函數(shù)封裝外部不直接訪問responsePool這樣后續(xù)替換真實(shí)API時(shí)只需要修改這一個(gè)函數(shù)的內(nèi)部實(shí)現(xiàn)。3.2 流式輸出效果的實(shí)現(xiàn)原理真實(shí)大模型的回答是逐字輸出的模擬界面如果不還原這個(gè)效果Demo的真實(shí)感會(huì)大打折扣。流式輸出的核心邏輯并不復(fù)雜function simulateStreaming(text, container, onComplete) { let index 0; const timer setInterval(() { index; container.textContent text.slice(0, index); if (index text.length) { clearInterval(timer); if (onComplete) onComplete(); } }, 30); }關(guān)鍵點(diǎn)是每次輸出后要滾動(dòng)到底部。這個(gè)細(xì)節(jié)很多初學(xué)者會(huì)遺漏導(dǎo)致文本在氣泡里長出來但視覺上看不到最新的輸出內(nèi)容。滾動(dòng)操作放在setInterval內(nèi)部每輸出一個(gè)字符就執(zhí)行一次messageArea.scrollTop messageArea.scrollHeight;間隔時(shí)間建議設(shè)置為20-40毫秒。太慢會(huì)顯得卡頓太快則失去逐字生成的節(jié)奏感。這個(gè)參數(shù)可以抽成常量便于后續(xù)調(diào)節(jié)。3.3 三種交互狀態(tài)的管理等待中、生成中、完成對話交互期間前端至少需要管理三個(gè)狀態(tài)等待回復(fù)、回復(fù)生成中、回復(fù)完成。簡易版里我用一個(gè)狀態(tài)變量來約束let isProcessing false;當(dāng)用戶點(diǎn)擊發(fā)送時(shí)先檢查isProcessing。如果為true說明上一輪回復(fù)還沒結(jié)束直接忽略這次發(fā)送操作——這個(gè)防重復(fù)提交機(jī)制非常關(guān)鍵能避免多次點(diǎn)擊導(dǎo)致消息順序錯(cuò)亂。狀態(tài)流轉(zhuǎn)為用戶發(fā)送 → 渲染用戶消息 →isProcessing true→ 顯示正在輸入...提示延遲800-1500毫秒模擬網(wǎng)絡(luò)耗時(shí)→ 開始流式輸出 → 隱藏輸入提示輸出完畢 →isProcessing false→ 允許下一條消息發(fā)送正在輸入...的提示建議設(shè)計(jì)為一個(gè)獨(dú)立氣泡帶跳動(dòng)的三個(gè)點(diǎn)動(dòng)畫。這個(gè)動(dòng)畫能極大增強(qiáng)交互的真實(shí)感用戶會(huì)覺得AI正在思考而不是界面卡住了。3.4 模擬網(wǎng)絡(luò)延遲的本質(zhì)作用很多初學(xué)者不理解為什么要加延遲。模擬交互時(shí)如果點(diǎn)擊發(fā)送后瞬間彈出回復(fù)整個(gè)交互節(jié)奏會(huì)非常假。真實(shí)API調(diào)用一定存在網(wǎng)絡(luò)延遲這個(gè)延遲雖然在體驗(yàn)上是一種等待成本但在模擬階段反而是真實(shí)感的來源。延遲時(shí)間建議控制在600-2000毫秒之間隨機(jī)波動(dòng)不要固定死一個(gè)值。固定延遲會(huì)讓演示時(shí)顯得機(jī)械隨機(jī)延遲更接近真實(shí)API的表現(xiàn)。4. 完整實(shí)操過程從零搭建模擬對話界面接下來是完整的實(shí)操過程。我會(huì)從HTML結(jié)構(gòu)開始一步步到JavaScript邏輯最后給出完整代碼。每個(gè)步驟我都會(huì)說明設(shè)計(jì)原因方便你理解后自行調(diào)整。4.1 第一步搭建HTML骨架HTML結(jié)構(gòu)遵循前面的三段式布局。消息區(qū)不預(yù)置任何消息頁面加載后由JavaScript渲染一條初始?xì)g迎消息讓用戶覺得這個(gè)AI是活著的。div classchat-container header classchat-header h1AI 對話助手/h1 span classstatus-dot在線/span /header main classmessage-area idmessageArea !-- 消息動(dòng)態(tài)渲染 -- /main footer classinput-area textarea iduserInput placeholder輸入你的問題.../textarea button idsendBtn發(fā)送/button /footer /div這里用textarea而不是input是因?yàn)橛脩艨赡茌斎攵嘈形谋?。如果只用一個(gè)單行input后續(xù)接真實(shí)需求時(shí)會(huì)發(fā)現(xiàn)輸入體驗(yàn)受限還要返工換控件。4.2 第二步CSS樣式與布局實(shí)現(xiàn)CSS 部分的核心是Flex布局和氣泡樣式。我給一個(gè)基礎(chǔ)版本你可以在這個(gè)基礎(chǔ)上做品牌化定制.chat-container { display: flex; flex-direction: column; width: 480px; height: 680px; border-radius: 12px; overflow: hidden; box-shadow: 0 4px 20px rgba(0, 0, 0, 0.1); } .message-area { flex: 1; overflow-y: auto; padding: 16px; background: #f7f7f8; } .message { display: flex; margin-bottom: 12px; } .message.user { justify-content: flex-end; } .bubble { max-width: 70%; padding: 10px 14px; border-radius: 14px; line-height: 1.5; font-size: 14px; word-break: break-word; } .message.ai .bubble { background: #ffffff; border-bottom-left-radius: 4px; } .message.user .bubble { background: #4e7cf7; color: #ffffff; border-bottom-right-radius: 4px; }這里需要解釋一個(gè)關(guān)鍵的視覺細(xì)節(jié)。AI氣泡用白色、用戶氣泡用主題色這在絕大多數(shù)對話產(chǎn)品中都是默認(rèn)方案。如果你們的品牌色比較特殊只要把background屬性替換即可。氣泡的陰影建議輕處理box-shadow: 0 1px 2px rgba(0,0,0,0.05)就夠不要重陰影否則界面會(huì)顯得臟。4.3 第三步完善響應(yīng)池與工具函數(shù)在第四步的完整代碼里響應(yīng)池會(huì)以一個(gè)獨(dú)立對象的形式存在。工具函數(shù)包含三個(gè)randomDelay用于生成隨機(jī)延遲時(shí)間matchResponse用于關(guān)鍵詞匹配scrollToBottom用于控制滾動(dòng)。function randomDelay(min 600, max 1500) { return Math.floor(Math.random() * (max - min 1)) min; } function scrollToBottom() { messageArea.scrollTop messageArea.scrollHeight; }scrollToBottom在消息渲染后、流式輸出過程中都會(huì)調(diào)用。這里有一個(gè)瀏覽器性能的注意事項(xiàng)在setInterval內(nèi)頻繁操作scrollTop在低端設(shè)備上可能引起性能問題。優(yōu)化方案是在流式輸出時(shí)只在每次更新文本內(nèi)容的同一個(gè)周期內(nèi)調(diào)用不額外增加頻率。4.4 第四步核心交互邏輯完整實(shí)現(xiàn)這一節(jié)給出核心JavaScript代碼。如果你要照著做建議分模塊理解不要直接整體粘貼后走人。const messageArea document.getElementById(messageArea); const userInput document.getElementById(userInput); const sendBtn document.getElementById(sendBtn); let isProcessing false; // ---- 響應(yīng)池 ---- const responsePool { /* 結(jié)構(gòu)同前文 */ }; // ---- 消息渲染 ---- function appendMessage(role, text) { const messageDiv document.createElement(div); messageDiv.className message ${role}; const bubble document.createElement(div); bubble.className bubble; bubble.textContent text; messageDiv.appendChild(bubble); messageArea.appendChild(messageDiv); scrollToBottom(); return bubble; } function showTypingIndicator() { const indicator document.createElement(div); indicator.className message ai typing-indicator; indicator.textContent 正在輸入...; messageArea.appendChild(indicator); scrollToBottom(); return indicator; } // ---- 模擬回復(fù) ---- function getMockResponse(input) { const normalized input.toLowerCase(); for (const key in responsePool) { if (key default) continue; const item responsePool[key]; if (item.keywords.some(kw normalized.includes(kw.toLowerCase()))) { return item.reply; } } return responsePool.default.reply; } // ---- 核心發(fā)送流程 ---- function handleSend() { if (isProcessing) return; const text userInput.value.trim(); if (!text) return; // 清空輸入框渲染用戶消息 userInput.value ; appendMessage(user, text); isProcessing true; sendBtn.disabled true; // 模擬網(wǎng)絡(luò)延遲后流式回復(fù) const typingIndicator showTypingIndicator(); setTimeout(() { const reply getMockResponse(text); messageArea.removeChild(typingIndicator); const bubble appendMessage(ai, ); let index 0; const streamTimer setInterval(() { index; bubble.textContent reply.slice(0, index); scrollToBottom(); if (index reply.length) { clearInterval(streamTimer); isProcessing false; sendBtn.disabled false; userInput.focus(); } }, 30); }, randomDelay()); } // ---- 事件綁定 ---- sendBtn.addEventListener(click, handleSend); userInput.addEventListener(keydown, (e) { if (e.key Enter !e.shiftKey) { e.preventDefault(); handleSend(); } }); // ---- 初始化歡迎消息 ---- window.addEventListener(DOMContentLoaded, () { appendMessage(ai, 你好我是模擬AI助手你可以發(fā)送一條消息試試。); userInput.focus(); });發(fā)送流程是這個(gè)項(xiàng)目的核心鏈路值得仔細(xì)拆解。整個(gè)過程在時(shí)序上是獲取輸入 → 渲染用戶消息 → 加鎖防重 → 顯示輸入中提示 → 延遲 → 移除提示 → 流式輸出AI回復(fù) → 解鎖。這個(gè)流程和真實(shí)API接入后的流程完全一致唯一的差異就是把調(diào)用網(wǎng)絡(luò)接口替換成了調(diào)用本地響應(yīng)池函數(shù)。鍵盤交互的細(xì)節(jié)也很重要。在textarea中按下Enter鍵需要區(qū)分單獨(dú)按Enter是發(fā)送ShiftEnter是換行。好多初學(xué)者在這里踩坑把keydown事件綁定到input上后Enter和中文輸入法沖突體驗(yàn)很糟糕。4.5 擴(kuò)展讓模擬界面連接真實(shí)API當(dāng)真實(shí)接口就緒后切換過程非常直接。只需要把handleSend流程中的getMockResponse替換為fetchAIResponseasync function fetchAIResponse(userText) { const response await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ message: userText }) }); const data await response.json(); return data.reply; }模擬方案的設(shè)計(jì)價(jià)值就在這里體現(xiàn)視圖層、消息渲染、流式輸出邏輯完全不用動(dòng)只替換數(shù)據(jù)獲取函數(shù)再補(bǔ)充錯(cuò)誤處理分支即可。5. 常見問題與排查技巧實(shí)錄做完這個(gè)項(xiàng)目后我整理了實(shí)操中容易踩的坑每個(gè)都是真實(shí)遇到過的問題寫成速查表供你參考。5.1 高頻問題速查表問題現(xiàn)象根本原因解決方案點(diǎn)擊發(fā)送沒有反應(yīng)輸入框內(nèi)容為空被trim后過濾檢查handleSend中是否有空值攔截邏輯連續(xù)快速點(diǎn)擊發(fā)送消息順序錯(cuò)亂沒有設(shè)置isProcessing鎖在發(fā)送流程開始時(shí)置位結(jié)束后復(fù)位流式輸出時(shí)頁面不滾動(dòng)沒有在setInterval內(nèi)調(diào)用scrollToBottom每次更新文本后同步執(zhí)行滾動(dòng)Enter鍵無法發(fā)送事件綁定到了錯(cuò)誤元素確認(rèn)綁定的是textarea而非父容器中文輸入法選字時(shí)直接觸發(fā)了發(fā)送未處理組合輸入狀態(tài)用e.isComposing判斷輸入法狀態(tài)中文輸入法的處理是我特別想強(qiáng)調(diào)的一點(diǎn)。用拼音輸入時(shí)選字過程會(huì)觸發(fā)keydown事件如果沒有判斷e.isComposing用戶還在選字就發(fā)送出去了體驗(yàn)非常割裂。正確寫法是在事件處理函數(shù)開頭加一句話if (e.isComposing) return;這是一個(gè)極少被教程提及但影響巨大的細(xì)節(jié)。5.2 排查技巧善用控制臺(tái)的網(wǎng)絡(luò)面板開發(fā)模擬交互界面時(shí)我建議打開瀏覽器的控制臺(tái)網(wǎng)絡(luò)面板觀察請求情況。雖然模擬方案不發(fā)請求但當(dāng)你看到?jīng)]有發(fā)出任何網(wǎng)絡(luò)請求時(shí)可以快速確認(rèn)這確實(shí)走的是本地模擬避免和真實(shí)API狀態(tài)混淆。排查邏輯問題時(shí)可以先在getMockResponse函數(shù)內(nèi)部加一個(gè)console.log輸出用戶輸入文本。如果看到日志輸出但沒有回復(fù)說明問題出在流式輸出環(huán)節(jié)反之如果日志都沒輸出說明問題在更早的事件綁定或者輸入獲取環(huán)節(jié)。通過這種方式快速二分定位問題區(qū)間。5.3 性能優(yōu)化與體驗(yàn)打磨心得流式輸出如果一次輸出大量文本比如回答很長setInterval頻繁操作DOM會(huì)導(dǎo)致掉幀。優(yōu)化手段有兩個(gè)方向一是加大間隔時(shí)間到50ms二是改為每次插入2-3個(gè)字符而不是1個(gè)字符。后面這個(gè)方案在體驗(yàn)上幾乎無差別但性能壓力能明顯降低。還有一個(gè)貼士模擬回復(fù)的文本建議控制在200字以內(nèi)。模擬階段回復(fù)太長配合30ms的逐字輸出會(huì)讓用戶等待太久反而暴露這是假的的事實(shí)。越短的回復(fù)配合合理的延遲越能達(dá)到以假亂真的效果。5.4 做得再好也要留的后門即使模擬效果做得非常逼真我也建議在界面某個(gè)不顯眼的位置標(biāo)注開發(fā)模式或模擬數(shù)據(jù)標(biāo)識(shí)。這個(gè)后門的作用是在演示時(shí)遇到無法回答的問題可以坦然地指向標(biāo)識(shí)說明目前是模擬狀態(tài)真實(shí)能力需要接入API后展示。這樣做不僅誠實(shí)也能管理好預(yù)期避免后續(xù)被追問為什么你的AI這么笨時(shí)陷入被動(dòng)。我個(gè)人在實(shí)際項(xiàng)目中的體會(huì)是模擬交互界面這個(gè)不起眼的小項(xiàng)目價(jià)值遠(yuǎn)超它表面看起來的樣子。它不僅是等API期間的過渡品更是整個(gè)前端交互邏輯的試煉場。在這里把狀態(tài)管理、交互細(xì)節(jié)、邊界情況都打磨清楚等真實(shí)大模型接入時(shí)你只需要關(guān)心數(shù)據(jù)層而不必在UI邏輯上返工。如果你正在做類似的功能建議多花一點(diǎn)時(shí)間把流式輸出的節(jié)奏感和狀態(tài)切換的細(xì)節(jié)做好這些用心最后都會(huì)在成品的質(zhì)感上體現(xiàn)出來。