實測微信小微：一個“生在微信裡”的AI，邊界在哪裡

微信近日在iOS 8.0.75版本中灰度內測原生AI助手「小微」，入口位於首頁左上角，用戶也可在主畫面右滑直接喚醒。這個「長在微信裡的AI」究竟能做到什麼，使用邊界又在哪裡？我們系統性地測試了小微在單鏈路執行、複合指令拆解、複雜小程序操控、社交語義理解、財報分析與隱私邊界等場景，試圖摸清一個AI Agent嵌入擁有14億月活用戶的超級App後，能力的上限與侷限。 當第一次問小微「你是誰」，它回答：「騰訊微信團隊的小微，生在微信裡。」這句話清楚揭示了它的本質——小微天然接入了微信的聊天、小程序與支付體系，但它的觸手也只延伸到這個生態圈內。從實測來看，小微擅長的是「填參數」而非「做選擇」，它能將任務推進到最後一步，但往往會停在付款或發送前，把決定權交還給用戶。 點咖啡是最典型的單鏈路場景。對小微說「幫我點一杯瑞幸的生椰拿鐵，去冰，埃塞金烘，不加糖」，它能正確識別意圖、喚起瑞幸小程序、選好參數並抵達訂單確認頁，但停在付款前，不會代為支付。重複測試後發現，這個過程還稱不上「一句話點咖啡」：有時卡在配送方式選擇，有時卡在加購彈窗確認，每次仍需用戶手動介入至少一次。值得注意的是，相同的最後一步背後存在技術路徑差異——阿里巴巴的千問App透過API介面直接調用淘寶閃購與支付寶系統級接口，整體流程更順暢，還能疊加平台優惠；小微則走小程序參數協議，能填參數卻難以應對複雜UI控件，且無平台級補貼機制。這種差異源於生態結構：千問在阿里系閉環內調通接口是內部工程，小微面對微信生態數百萬第三方小程序，逐一深度適配的工程量與協調成本高出許多。 群聊總結是另一個高頻場景。在科技創投類群組實測，小微能按日期梳理話題脈絡，提取人名、金額與產品動態，並給出群聊整體風格判斷。但這項功能成功率不穩定，同一指令有時成功有時失敗，失敗時回覆「接口暫時出了點小狀況」，甚至暴露底層接口名稱「list_message_edge」——這是微信消息系統的內部API字面量。由此可見，小微讀取群聊數據是透過微信內部API通道，而非屏幕識別再理解。 生成小工具是「人人是產品經理」的賣點。簡單一句「幫我做一個記賬的小工具」，小微就能生成包含收支彙總、分類標籤與新增入口的完整小程序雛形；但生成時間約兩分半鐘偏慢，且不支援對已生成工具追加修改，也無法分享給他人。代發消息同樣體現微信一貫的克制：小微能找到正確聯繫人或群組並生成內容，但最後發送需用戶手動點擊綠色按鈕。朋友圈總結則能按生活日常、工作分享、旅行打卡等分類整理好友動態，標註姓名與情緒標籤，點擊「i」圖標可跳轉原文；然而視野僅限最近兩天，無法讀取更早內容。 單一任務表現尚可，但把多件事打包成一條指令時，局面就開始不穩。我們測試了這條複合指令：「幫我點一杯瑞幸的生椰拿鐵去冰，同時幫我在附近找一家評分4.5分以上的火鍋店，再跟光頭強發消息說今天不想加班，語氣要委婉一點。」小微順利拆解三個子任務並依序執行，但完成度出現明顯梯度下降：點咖啡幾乎不受影響，選好生椰拿鐵到達確認頁；搜火鍋店卻因前一步「咖啡」上下文干擾，匹配結果全是咖啡相關小程序，回覆「沒匹配到合適的小程序」；最後給「光頭強」發消息，預填內容竟是上輪測試遺留的「可以出發了」，而非委婉拒絕。對比單獨指令時，同類需求它能生成「今天可能不太想加班，你看咱們能不能稍微靈活一點？」這樣高品質的委婉表達。 這種衰減並非因Token上限被壓縮，而是任務編排層的狀態管理出了問題：前一步檢索結果汙染後一步目標，是上下文汙染；上輪緩存覆蓋本輪草稿，是狀態隔離失效；「附近」這個空間約束壓根沒被讀入，是關鍵參數透傳斷鏈。三種失敗形態指向同一個系統級短板：小微缺乏可靠的狀態管理框架來保證步驟間接力完整傳遞。 將任務限定在一件但拉長鏈路，也呈現清晰的衰減曲線。最短的鏈路是打車——「幫我叫一輛車去北京南站出發大廳」，能正確調起滴滴小程序填好目的地，停在確認叫車頁；中鏈路的訂酒店——「訂一間杭州西湖附近明天入住的5星級酒店，價格500以下」，走到授權頁便卡住，價格篩選方向錯誤，雖有自糾正行為但最終放棄；最長鏈路是買高鐵票——「幫我買一張明天北京到上海的高鐵票，上午出發，靠窗座位」，基礎參數填對，但卡在選座與乘客資訊填寫等複合UI控件，最終退回參數頁面並推送車次卡片給用戶手動操作。 這背後是技術路線的選擇：微信Agent對小程序的操控採程序化交互，透過內部接口定位控件觸發操作，不依賴屏幕識別，更安全也不會誤觸或越權；代價是只能操控開放了程序化入口的控件，而篩選面板、選擇器、表單等複合UI控件極少提供這類接口。小微的策略是「簡單頁面優先適配，複雜頁面暫放」，跑不通的交還給人。這種「淺層橋接」的定位，決定了小微離真正的深度集成還需時間。 有趣的是，面對失敗時小微有兩套話術。當被要求「每天早上8點準時發早安到家長群」，它精確區分產品限制與權限問題：「微信沒有內置定時群發功能，我也沒有權限操作」，並給出替代方案，還追問動機、加上emoji。但在群聊總結失敗時說「接口暫時出了點小狀況」，搜不到火鍋店時說「檢索到的都是咖啡相關的小程序」，系統不支援回溯查詢時說「系統暫時不支援」——這些模糊化說詞將原因歸給外部，而非承認自身能力不足。兩種面孔對應兩種產品角色：主動拒絕是設計層面的紅線，能大方解釋；嘗試後失敗是工程實現層面的不足，暫時做不到便用兜底話術。 整體而言，小微可謂「60分助手」。單一功能多數表現不錯，但同時做兩件事或鏈路超過三步，完成度就明顯滑坡。這不是個別功能的Bug，而是當前架構的系統性特徵：任務編排能力跟不上意圖理解能力。不過，正面的發現也不少：小微能順利閱讀財報並提煉分析，騰訊財報數據幾乎零幻覺；群聊總結成功時僅需兩三秒；WeLM與DeepSeek的自動路由切換流暢。底層模型能力過硬，短板在「能不能穩定地做到底」。 換個角度看，在14億用戶的場景下，任何一點自動化都能帶來巨大效率增量。即使群聊總結成功率不穩定，每天仍能幫大量用戶省出幾分鐘；點咖啡、叫車、發消息等短鏈路對多數人已經夠用。微信不需要一個完美的AI，它需要的是不出錯、可預期、邊際成本夠低的AI中間層。不苛求小微完美，或許正是微信現階段的最佳策略。本次測試基於微信8.0.75灰度內測版，所有指令均在真實環境執行，複合指令與長鏈路場景至少重複三次以排除偶發誤差。