1. 移動端調(diào)試的困局為什么AI看不見H5的真實運(yùn)行狀態(tài)做過H5開發(fā)的人大概都有過這種體驗頁面在電腦瀏覽器里跑得好好的一放到手機(jī)端就各種詭異問題——接口偶發(fā)失敗、某個按鈕點(diǎn)了沒反應(yīng)、頁面白屏但控制臺干干凈凈。你打開手機(jī)上的調(diào)試工具翻半天日志好不容易定位到問題改完代碼重新部署結(jié)果發(fā)現(xiàn)是另一個問題。整個過程像在黑暗里摸象效率低得讓人抓狂。傳統(tǒng)的移動端調(diào)試方案無非幾種真機(jī)連電腦用遠(yuǎn)程調(diào)試、頁面里嵌入vConsole手動看日志、或者干脆在代碼里到處埋console.log然后靠alert彈出來。這些方法各有各的痛點(diǎn)。遠(yuǎn)程調(diào)試需要數(shù)據(jù)線、需要驅(qū)動、需要端口轉(zhuǎn)發(fā)換個手機(jī)或者換個網(wǎng)絡(luò)環(huán)境就得重新折騰一遍vConsole雖然方便但日志得靠人眼一條條翻請求多了根本看不過來埋點(diǎn)彈窗就更原始了改一次代碼就得重新發(fā)一次包。而這兩年AI編程助手的能力突飛猛進(jìn)很多人已經(jīng)習(xí)慣讓AI幫忙看代碼、分析報錯、給出修復(fù)建議。但這里有個根本性的斷層AI能看見你的源碼卻看不見你的運(yùn)行時。你跟AI說我這個頁面在手機(jī)上請求失敗了AI只能根據(jù)你貼過去的日志片段猜測它不知道完整的請求鏈路、不知道請求頭里帶了什么、不知道響應(yīng)體長什么樣、不知道這個請求是在什么用戶操作之后觸發(fā)的。信息缺失導(dǎo)致AI給出的建議往往是隔靴搔癢。vConsole MCP這個思路要解決的就是這個斷層。它做的事情說起來很直接把vConsole采集到的日志和網(wǎng)絡(luò)請求通過MCP協(xié)議暴露出去讓AI助手能夠直接讀取。這樣一來AI就不再是盲人摸象而是能看見H5頁面在真實設(shè)備上的完整運(yùn)行狀態(tài)。你可以直接問AI剛才那個登錄請求為什么失敗了AI能自己去讀請求詳情、看響應(yīng)內(nèi)容、結(jié)合源碼給出判斷而不是等你手動復(fù)制粘貼一堆信息過去。這篇文章會從實際落地角度把vConsole MCP的搭建過程、核心原理、踩坑經(jīng)驗完整講一遍。不管你是剛接觸MCP的新手還是已經(jīng)在用AI輔助開發(fā)的老手都能從中找到可以直接復(fù)用的東西。涉及的關(guān)鍵詞包括vConsole、MCP、H5調(diào)試、WebSocket通信、日志采集、請求攔截等下面會逐一展開。2. 拆解vConsole MCP的通信鏈路從頁面日志到AI可讀數(shù)據(jù)2.1 vConsole本身能拿到什么拿不到什么vConsole是一個輕量級的移動端調(diào)試面板核心能力是攔截console方法、捕獲window.onerror、代理XMLHttpRequest和fetch把這些信息渲染成一個浮層面板顯示在頁面上。它能拿到的東西包括console.log/warn/error的輸出、未捕獲的JS異常、網(wǎng)絡(luò)請求的方法/URL/請求頭/請求體/響應(yīng)狀態(tài)/響應(yīng)體/耗時。但它拿不到的東西也很關(guān)鍵它不知道這些日志之間的因果關(guān)系不知道某個請求是在哪個用戶操作之后觸發(fā)的不知道當(dāng)前頁面的路由狀態(tài)和組件樹。而且vConsole的數(shù)據(jù)是存在頁面內(nèi)存里的頁面一刷新就沒了也沒法跨設(shè)備訪問。MCP要做的就是把這些散落在頁面內(nèi)存里的數(shù)據(jù)變成AI可以按需查詢的結(jié)構(gòu)化信息。這里的關(guān)鍵在于按需查詢——不是把所有日志一股腦推給AI而是讓AI能夠像查數(shù)據(jù)庫一樣根據(jù)當(dāng)前調(diào)試的問題去拉取相關(guān)的日志和請求。2.2 MCP協(xié)議在這里扮演什么角色MCP全稱Model Context Protocol是一套讓AI助手能夠訪問外部工具和數(shù)據(jù)源的協(xié)議規(guī)范。你可以把它理解成AI的USB接口——只要某個服務(wù)實現(xiàn)了MCP協(xié)議AI就能通過標(biāo)準(zhǔn)化的方式去調(diào)用它。MCP的核心概念包括Resources資源AI可以讀取的數(shù)據(jù)、Tools工具AI可以調(diào)用的函數(shù)、Prompts提示模板。在vConsole MCP這個場景里vConsole采集到的日志和請求就是ResourcesAI可以通過MCP讀取這些資源。同時還可以暴露一些Tools比如清空日志、按關(guān)鍵詞過濾請求、獲取某個請求的完整詳情等讓AI能夠主動操作這些數(shù)據(jù)。這里有個設(shè)計上的關(guān)鍵選擇數(shù)據(jù)是通過MCP Server中轉(zhuǎn)還是讓AI直接連頁面直接連頁面的話AI需要知道頁面的IP和端口而且頁面關(guān)閉后連接就斷了。通過MCP Server中轉(zhuǎn)的話Server可以維護(hù)一個日志緩沖區(qū)即使頁面刷新了歷史日志還在。實際落地時通常采用后者頁面通過WebSocket把數(shù)據(jù)推給MCP ServerServer再通過MCP協(xié)議暴露給AI。2.3 WebSocket在整條鏈路里的位置頁面和MCP Server之間的通信WebSocket是最自然的選擇。原因有幾個第一日志和請求是持續(xù)產(chǎn)生的需要服務(wù)端主動推送或者客戶端持續(xù)上報HTTP輪詢延遲高且浪費(fèi)資源第二WebSocket是全雙工的Server可以反向給頁面發(fā)指令比如開始錄制、清空日志第三WebSocket的連接狀態(tài)可以反映頁面是否還活著頁面關(guān)閉時連接斷開Server能感知到。WebSocket的心跳機(jī)制在這里也很重要。移動端網(wǎng)絡(luò)環(huán)境復(fù)雜頁面切到后臺、網(wǎng)絡(luò)切換、信號弱等情況都可能導(dǎo)致連接假死。如果不做心跳檢測Server可能以為頁面還在線實際上連接早就斷了。常見的做法是客戶端每隔一段時間發(fā)一個pingServer回pong連續(xù)幾次沒收到pong就判定連接斷開清理對應(yīng)的會話。2.4 數(shù)據(jù)格式的設(shè)計取舍頁面推給Server的數(shù)據(jù)格式設(shè)計直接影響后續(xù)AI讀取的效率。如果直接把vConsole的原始數(shù)據(jù)扔過去AI讀起來會很費(fèi)勁因為里面夾雜了大量渲染相關(guān)的字段。更好的做法是在頁面?zhèn)茸鲆粚虞p量清洗只保留調(diào)試真正需要的字段。以網(wǎng)絡(luò)請求為例一條請求記錄至少應(yīng)該包含唯一ID、時間戳、方法、URL、請求頭、請求體、響應(yīng)狀態(tài)碼、響應(yīng)頭、響應(yīng)體、耗時、觸發(fā)時的頁面路由。日志記錄則應(yīng)該包含級別、時間戳、參數(shù)序列化后的內(nèi)容、調(diào)用棧如果有。這些字段設(shè)計得越規(guī)整AI理解起來越容易。注意響應(yīng)體可能非常大直接全量傳輸會拖慢WebSocket。實際實現(xiàn)時通常會對響應(yīng)體做截斷比如超過一定長度只保留前N個字符同時標(biāo)記已截斷。AI需要完整內(nèi)容時可以通過單獨(dú)的Tool去請求完整數(shù)據(jù)。3. 從零搭建一套可用的vConsole MCP環(huán)境3.1 環(huán)境準(zhǔn)備與依賴選型搭建這套環(huán)境需要三個部分頁面?zhèn)鹊牟杉_本、中間的MCP Server、以及AI助手側(cè)的MCP客戶端配置。頁面?zhèn)茸詈唵蔚姆绞绞侵苯右雟Console然后在其基礎(chǔ)上擴(kuò)展一個WebSocket上報模塊。如果不想改動現(xiàn)有代碼結(jié)構(gòu)也可以寫一個獨(dú)立的腳本在vConsole初始化之后掛載上報邏輯。MCP Server可以用Node.js寫因為MCP的官方SDK對Node支持最好而且WebSocket庫ws成熟穩(wěn)定。Server需要同時監(jiān)聽兩個端口一個WebSocket端口給頁面連接一個MCP端口給AI客戶端連接。這兩個端口可以復(fù)用同一個HTTP Server通過路徑區(qū)分。AI助手側(cè)需要配置MCP Server的地址。不同的AI客戶端配置方式不同但核心都是告訴客戶端有一個MCP Server在某個地址上去連接它。配置完成后AI就能看到這個Server暴露的Resources和Tools。3.2 頁面?zhèn)炔杉_本的關(guān)鍵實現(xiàn)頁面?zhèn)鹊牟杉_本核心是兩件事攔截數(shù)據(jù)、上報數(shù)據(jù)。攔截數(shù)據(jù)可以直接復(fù)用vConsole的能力也可以通過vConsole的插件機(jī)制來擴(kuò)展。vConsole本身支持插件可以監(jiān)聽它的事件來獲取日志和請求。上報數(shù)據(jù)時要注意幾個細(xì)節(jié)。第一要做批量上報不能每條日志都發(fā)一次WebSocket消息那樣消息太碎Server處理壓力大。通常的做法是維護(hù)一個緩沖區(qū)每隔100到200毫秒或者緩沖區(qū)達(dá)到一定條數(shù)時批量發(fā)送。第二要處理連接斷開的情況斷線后要有重連機(jī)制重連期間產(chǎn)生的數(shù)據(jù)可以先緩存在內(nèi)存里連上之后再補(bǔ)發(fā)。第三要給每條數(shù)據(jù)打上會話ID這樣Server能區(qū)分不同頁面實例的數(shù)據(jù)。// 頁面?zhèn)壬蠄筮壿嫷暮喕疽?const buffer []; let ws null; let sessionId generateSessionId(); function enqueue(type, payload) { buffer.push({ sessionId, type, payload, timestamp: Date.now() }); } function flush() { if (ws ws.readyState WebSocket.OPEN buffer.length 0) { ws.send(JSON.stringify(buffer.splice(0, buffer.length))); } } setInterval(flush, 150); function connect() { ws new WebSocket(ws://your-server:port/page); ws.onopen () { ws.send(JSON.stringify({ type: register, sessionId })); }; ws.onclose () { setTimeout(connect, 2000); }; }3.3 MCP Server的資源與工具設(shè)計Server側(cè)要把接收到的數(shù)據(jù)組織成MCP的Resources和Tools。Resources適合放那些AI需要讀取的數(shù)據(jù)比如當(dāng)前會話的日志列表、當(dāng)前會話的請求列表、某個請求的詳情。Tools適合放那些AI需要執(zhí)行的操作比如清空日志、按條件篩選請求、獲取請求的完整響應(yīng)體。資源的設(shè)計要考慮AI的讀取習(xí)慣。AI通常不會一次性讀取所有日志而是根據(jù)當(dāng)前問題去讀取相關(guān)部分。所以資源應(yīng)該支持參數(shù)化比如獲取最近N條日志、獲取狀態(tài)碼為500的請求。MCP的Resources支持URI模板可以用類似logs://{sessionId}/recent?count50這樣的形式來定義。工具的設(shè)計則要考慮操作的原子性。比如清空日志這個操作應(yīng)該只清空指定會話的日志而不是所有會話。再比如獲取請求詳情應(yīng)該接受請求ID作為參數(shù)返回該請求的完整信息。3.4 AI客戶端側(cè)的配置與驗證配置AI客戶端連接MCP Server時最容易出問題的地方是地址和端口。如果Server跑在本地地址通常是localhost或127.0.0.1但如果AI客戶端跑在容器里或者遠(yuǎn)程機(jī)器上就需要用實際的IP地址。另外要注意防火墻設(shè)置確保MCP端口是開放的。配置完成后可以先讓AI列出當(dāng)前可用的Resources和Tools確認(rèn)連接正常。然后打開一個測試頁面觸發(fā)一些日志和請求再讓AI去讀取這些數(shù)據(jù)。如果AI能正確讀到頁面產(chǎn)生的日志說明整條鏈路是通的。提示初次調(diào)試時建議先用一個最簡單的HTML頁面測試頁面上只放一個按鈕點(diǎn)擊后產(chǎn)生一條日志和一個請求。這樣排查問題時變量最少容易定位是哪一環(huán)出了問題。4. 實際調(diào)試場景中的效果與邊界4.1 接口偶發(fā)失敗的排查過程接口偶發(fā)失敗是移動端最頭疼的問題之一因為復(fù)現(xiàn)困難而且失敗時往往沒有完整的上下文。用vConsole MCP之后排查思路會發(fā)生變化。你不需要在失敗發(fā)生時立刻去抓日志而是讓頁面持續(xù)上報AI在后臺維護(hù)一個請求歷史。當(dāng)用戶反饋剛才提交訂單失敗了你可以讓AI去查最近幾分鐘內(nèi)狀態(tài)碼非200的請求。AI拿到請求列表后可以進(jìn)一步查看失敗請求的詳情請求頭里帶了什么token、請求體里的參數(shù)是什么、響應(yīng)體里服務(wù)端返回了什么錯誤信息。結(jié)合源碼AI往往能直接給出判斷比如這個請求的token過期了因為響應(yīng)體里返回了401而且請求頭里的token時間戳是兩小時前的。這里的關(guān)鍵在于AI看到的不再是你手動篩選后貼過去的信息而是完整的原始數(shù)據(jù)。它能自己決定去看哪些字段、去對比哪些請求。這種自主性帶來的效率提升是很明顯的。4.2 頁面白屏但無報錯的定位思路頁面白屏但控制臺沒有報錯這種情況通常是因為某個異步操作失敗了但沒有被捕獲或者某個資源加載失敗但沒有觸發(fā)onerror。用傳統(tǒng)方式排查你得在代碼里到處加日志然后一遍遍刷新看輸出。有了vConsole MCP之后你可以讓AI去分析頁面加載過程中的所有請求。白屏往往伴隨著某個關(guān)鍵JS文件加載失敗或者某個接口返回了空數(shù)據(jù)導(dǎo)致渲染邏輯提前返回。AI可以通過對比正常情況和異常情況下的請求列表快速定位到差異點(diǎn)。比如AI可能會發(fā)現(xiàn)正常加載時有一個獲取用戶信息的請求返回了200但這次這個請求返回了401導(dǎo)致后續(xù)的渲染邏輯沒有執(zhí)行。這種分析如果靠人眼去翻請求列表可能要翻很久但AI可以瞬間完成對比。4.3 這套方案的適用邊界與不適用場景vConsole MCP不是萬能的它有明確的適用邊界。首先它依賴于頁面能夠運(yùn)行JavaScript如果頁面在JS執(zhí)行之前就崩潰了比如HTML解析出錯那vConsole根本來不及初始化也就采集不到任何數(shù)據(jù)。其次它依賴于網(wǎng)絡(luò)連接如果頁面所在的設(shè)備完全離線數(shù)據(jù)傳不到ServerAI也看不到。另外這套方案對性能有一定影響。WebSocket連接和頻繁的數(shù)據(jù)上報會消耗一定的CPU和電量對于性能敏感的頁面需要做取舍。通常的做法是在開發(fā)環(huán)境和測試環(huán)境開啟上報生產(chǎn)環(huán)境關(guān)閉或者只在需要調(diào)試時動態(tài)開啟。還有一個容易被忽略的點(diǎn)數(shù)據(jù)隱私。頁面上報的請求可能包含用戶敏感信息比如token、手機(jī)號、地址等。如果MCP Server部署在公網(wǎng)這些數(shù)據(jù)就有泄露風(fēng)險。實際使用時應(yīng)該把Server部署在內(nèi)網(wǎng)或者對敏感字段做脫敏處理。5. 落地過程中容易踩的坑與應(yīng)對經(jīng)驗5.1 WebSocket連接在移動端的穩(wěn)定性問題移動端WebSocket連接比桌面端脆弱得多。頁面切到后臺一段時間后系統(tǒng)可能會掛起WebSocket連接網(wǎng)絡(luò)從WiFi切到4G時連接會斷開甚至某些手機(jī)瀏覽器在鎖屏后直接殺掉連接。如果不處理這些情況你會發(fā)現(xiàn)日志上報時斷時續(xù)AI讀到的數(shù)據(jù)不完整。應(yīng)對方案是雙重的客戶端做自動重連服務(wù)端做會話保持。客戶端在onclose事件里啟動重連定時器重連成功后把斷線期間緩存的數(shù)據(jù)補(bǔ)發(fā)。服務(wù)端在連接斷開后不立即清理會話而是保留一段時間比如5分鐘如果客戶端在這個時間內(nèi)重連上來就恢復(fù)到同一個會話。心跳機(jī)制也要做但不能太頻繁否則耗電。通常30秒一次ping就夠了連續(xù)3次沒收到pong才判定斷開。這里有個細(xì)節(jié)頁面切到后臺時定時器可能會被瀏覽器節(jié)流導(dǎo)致心跳發(fā)不出去。所以心跳檢測要結(jié)合visibilitychange事件頁面回到前臺時立即發(fā)一次心跳確認(rèn)連接狀態(tài)。5.2 大量日志導(dǎo)致的數(shù)據(jù)淹沒頁面跑一段時間后日志和請求會積累到幾千條甚至上萬條。如果AI每次都去讀全量數(shù)據(jù)不僅慢而且容易迷失在無關(guān)信息里。這時候需要在Server側(cè)做數(shù)據(jù)管理。一個實用的做法是給日志和請求加上重要性標(biāo)記。console.error和狀態(tài)碼非2xx的請求標(biāo)記為高重要性console.warn和慢請求超過一定耗時標(biāo)記為中重要性普通的console.log和正常請求標(biāo)記為低重要性。AI查詢時默認(rèn)只讀高重要性和中重要性的數(shù)據(jù)需要時再主動去讀低重要性的。另一個做法是支持時間范圍過濾。AI可以指定只看最近30秒的數(shù)據(jù)這樣即使總數(shù)據(jù)量很大每次讀取的量也是可控的。Server側(cè)維護(hù)一個環(huán)形緩沖區(qū)只保留最近N條數(shù)據(jù)更早的數(shù)據(jù)自動淘汰。5.3 AI讀取數(shù)據(jù)時的上下文窗口限制AI的上下文窗口是有限的如果一次讀入太多數(shù)據(jù)要么被截斷要么擠占了其他信息的空間。所以Server返回給AI的數(shù)據(jù)要盡量精簡。比如請求列表只返回摘要信息方法、URL、狀態(tài)碼、耗時不返回請求頭和響應(yīng)體AI需要詳情時再單獨(dú)請求。這里有個設(shè)計上的權(quán)衡返回太精簡AI可能缺少判斷依據(jù)返回太詳細(xì)又浪費(fèi)上下文。實際經(jīng)驗是摘要信息里至少要包含狀態(tài)碼和耗時因為這兩個字段最能反映問題。URL要保留完整路徑和查詢參數(shù)因為參數(shù)往往是問題所在。請求頭和響應(yīng)體則按需獲取。5.4 多頁面多會話的數(shù)據(jù)隔離一個調(diào)試場景里可能有多個頁面同時運(yùn)行比如主頁面、iframe、WebView里的子頁面。如果這些頁面的數(shù)據(jù)混在一起AI就很難區(qū)分哪條日志來自哪個頁面。所以會話隔離是必須的。每個頁面實例在初始化時生成一個唯一的sessionId上報數(shù)據(jù)時帶上這個ID。Server按sessionId分組存儲數(shù)據(jù)。AI查詢時可以指定sessionId也可以先列出所有活躍會話再選擇要查看的會話。頁面的URL和標(biāo)題也應(yīng)該作為會話的元信息上報方便AI識別。注意iframe和WebView里的頁面可能無法直接訪問父頁面的WebSocket連接需要各自建立獨(dú)立的連接。這種情況下Server要能處理多個連接對應(yīng)同一個邏輯會話的情況或者把它們視為不同的會話但在元信息里標(biāo)注關(guān)聯(lián)關(guān)系。6. 讓AI真正用起來查詢策略與協(xié)作技巧6.1 怎么問AI才能讓它高效利用這些數(shù)據(jù)有了數(shù)據(jù)通道之后提問方式直接決定了AI的排查效率。如果你只是籠統(tǒng)地說幫我看看有什么問題AI可能會漫無目的地翻數(shù)據(jù)。更好的方式是給出明確的線索和范圍比如最近一分鐘內(nèi)狀態(tài)碼為500的請求有哪些、用戶點(diǎn)擊提交按鈕之后產(chǎn)生了哪些日志。另一個技巧是讓AI做對比分析。比如對比一下成功提交和失敗提交的請求差異AI會自動去拉取兩組請求的數(shù)據(jù)找出不同點(diǎn)。這種對比如果靠人來做需要手動篩選、逐字段比對很費(fèi)時間但AI可以很快完成。還可以讓AI做時間線重建。告訴AI一個用戶操作序列讓它按時間順序把相關(guān)的日志和請求串起來形成一個完整的執(zhí)行鏈路。這對于理解復(fù)雜交互場景下的問題特別有用。6.2 把常見排查流程固化成提示模板MCP協(xié)議支持Prompts可以把常見的排查流程固化成模板。比如接口失敗排查模板會自動引導(dǎo)AI去查最近的失敗請求、讀取請求詳情、對比成功請求、給出可能原因。這樣每次遇到類似問題不需要重新描述排查思路直接調(diào)用模板就行。模板的設(shè)計要結(jié)合團(tuán)隊的實際排查習(xí)慣。比如你們團(tuán)隊排查接口問題時習(xí)慣先看狀態(tài)碼、再看響應(yīng)體、最后看請求頭那模板就按這個順序來。模板里還可以預(yù)置一些常見的錯誤模式比如401通常是token問題、502通常是網(wǎng)關(guān)問題幫助AI更快定位。6.3 和現(xiàn)有開發(fā)流程的銜接方式vConsole MCP不應(yīng)該是一個孤立的工具最好能融入現(xiàn)有的開發(fā)流程。比如在CI流程里可以在自動化測試跑完之后讓AI去讀取測試過程中的日志和請求自動生成一份問題報告。又比如在代碼審查時可以讓AI結(jié)合運(yùn)行時的請求數(shù)據(jù)來評估代碼改動的影響。對于測試同學(xué)來說這套方案也很有價值。測試發(fā)現(xiàn)bug時不需要再手動整理日志和請求信息直接讓AI去讀取對應(yīng)會話的數(shù)據(jù)自動生成bug報告。報告里包含完整的請求鏈路和錯誤日志開發(fā)拿到后能更快定位問題。6.4 數(shù)據(jù)留存與回放的價值頁面關(guān)閉后數(shù)據(jù)如果直接丟棄就失去了回溯的可能。Server側(cè)應(yīng)該把會話數(shù)據(jù)持久化一段時間比如保留24小時。這樣即使問題發(fā)生在一段時間之前只要還在保留期內(nèi)就能讓AI去讀取歷史數(shù)據(jù)。更進(jìn)一步可以把會話數(shù)據(jù)做成可回放的?；胤诺囊馑际前涯硞€時間段的日志和請求按時間順序重新播放出來模擬當(dāng)時的運(yùn)行狀態(tài)。這對于復(fù)現(xiàn)偶發(fā)問題特別有用因為你可以讓AI在回放過程中去分析每一步的狀態(tài)變化。持久化時要注意數(shù)據(jù)量全量存儲可能占用大量磁盤。通常的做法是只持久化高重要性和中重要性的數(shù)據(jù)低重要性的數(shù)據(jù)在會話結(jié)束后就丟棄。同時要設(shè)置過期清理策略避免磁盤被占滿。7. 我對這套方案的實際體會用了一段時間vConsole MCP之后最大的感受是調(diào)試的信息不對稱被大幅削弱了。以前跟AI描述問題時總擔(dān)心自己漏掉了關(guān)鍵信息導(dǎo)致AI給出錯誤判斷?，F(xiàn)在AI能自己去看原始數(shù)據(jù)我只需要告訴它去看哪個會話、關(guān)注哪個時間段剩下的它自己會搞定。另一個體會是這套方案的價值不僅在于讓AI看見更在于讓AI記住。人看日志是瞬時的看完就忘了但AI可以把整個會話的數(shù)據(jù)都保持在上下文里隨時回溯。排查復(fù)雜問題時這種全局視角特別有用。當(dāng)然也有不完美的地方。WebSocket在移動端的穩(wěn)定性仍然是個挑戰(zhàn)偶爾還是會出現(xiàn)數(shù)據(jù)丟失。另外AI讀取大量數(shù)據(jù)時的上下文管理也需要優(yōu)化有時候它會在無關(guān)的日志上浪費(fèi)注意力。這些都是后續(xù)可以繼續(xù)改進(jìn)的方向。如果你也在做H5開發(fā)并且已經(jīng)在用AI輔助編程我建議試試這套方案。搭建成本不高但帶來的效率提升是實實在在的。尤其是排查那些偶發(fā)、難復(fù)現(xiàn)的問題時有一個能看見完整運(yùn)行時的AI助手體驗完全不一樣。