2026年5月，支付寶宣布AI支付筆數已超過3億筆。一個月後，微信向開發者開放了小程式AI接入，其中一項要求引發爭議：開發者授權平台讀取小程式原始碼。
兩個時間點相隔不到30天，但背後是兩條已經分野超過一年的路線。根據晚點LatePost報道，支付寶正在內測一個代號「寶計畫」的AI版本，不是加一個助手，而是讓用戶一鍵切換到一個全新的、以對話驅動的介面。微信則在財報電話會上由總裁劉熾平定調：最終會搭載一個AI智能體，但與社交關係、公眾號、視頻號深度連接，沒有單獨的時間表。
兩個手握10億用戶和數百萬小程式的平台，在同一個問題上給了相反的答案：當AI能夠替用戶操作服務時，入口應該被重寫，還是被隱藏？
支付寶切掉的不只是介面
要理解支付寶到底做了什麼，得先看一個具體的使用者動作。
過去在支付寶裡訂三杯少糖拿鐵再叫一輛去機場的車，標準流程是：找到滴滴的小程序入口，輸入目的地，確認叫車；退出，找到瑞幸的小程序入口，選品類、改糖量、加購物車、結算；在兩個小程序之間來回切換，分別完成支付。每一步都是點擊、一次頁面跳躍、一次等待。
「寶計畫」要做的改動，是把這一整套動作壓縮成一句話。用戶對著對話框說“幫我叫輛車去機場，順便在附近訂三杯少糖的拿鐵”，AI接管後續所有步驟：理解意圖、拆解任務、調用對應的出行和餐飲服務、組合訂單、完成支付。互動介面不再是一排排小程式入口，而是一個聊天視窗。
這個改動之徹底，從內部的產品設計過程就能看出來。據晚點了解，為了確定新的互動形態，專案組前後出過100多個產品設計版本。最後選擇對話為核心的方案，背後的判斷是自然語言已經成為AI互動的主流方式，服務分發應該順著這個方向重建入口，而不是在舊框架裡貼一塊AI補丁。
這種激進並非一開始就是支付寶的選擇。 2023年下半年，支付寶事業群管理階層發起「如何走向智慧化」的討論時，眼前的第一個問題是：在原端上改造，還是另起一個新端？專案組最初選的是後者。 2024年9月外灘大會上，支付寶發布了獨立AI應用“支小寶”，定位AI生活管家。
支小寶沒有跑通。知情人士透露，獨立App的日活遠不及端內的智能體助理。那個留在支付寶裡、借助首頁流量的對話助手，反而穩定在數百萬日活量級，累積了遠比獨立App充分的互動數據。
還有一個更現實的限制：當時螞蟻集團正集中力量做健康應用“螞蟻阿福”，通用AI“靈光”也在推進，算力和開發資源有限。再做一個獨立App，不光要和這些項目搶資源，還得承擔讓用戶從零遷移的龐大成本。
2025年3月，團隊調頭，不再堅持獨立端的路線。內部逐漸形成一個判斷：服務好支付寶既有的10億用戶底盤，讓用戶以零遷移成本獲得AI服務，比在站外重新拉起一個新應用程式更有效。 2025年12月，AI版支付寶計畫正式立項，最早的班底來自端內智慧助理團隊，之後陸續加入演算法、C端產品和小程式業務團隊。
最終的產品路線不是獨立原生App，也不是在現有應用程式裡內嵌助手，而是一鍵切換。新版上線後，預設開啟的仍是原廠的支付寶，用戶可自行將AI版設為首選介面。晚點報道稱，這種「留有餘地」的推進方式，指向一個內部說法叫「騰籠換鳥」。
微信不讓AI擋在人與人之間
微信的AI路線，從頭走的就是另一條邏輯。
騰訊總裁劉熾平在2025年Q3財報電話會上的表述幾乎沒有歧義：微信將推出的AI智能體會與社交關係、通信能力、公眾號、視頻號深度連接，這是一個獨特的Agent。沒有激進的時間表，官方還兩度出面闢謠過關於AI助理的傳聞。
為什麼微信不能像支付寶那樣切一個對話介面出來？原因不在技術能力，而在產品屬性。微信的核心介面是聊天列表，這是十億人每天打開最頻繁的手機頁面。任何試圖在這個介面上疊加一個AI對話入口的動作，都可能被使用者視為對社交關係的干擾。支付寶的首頁是服務入口，把服務入口變成對話窗口，使用者需要重新適應一種操作習慣。微信的首頁是人和人的對話，把人的對話替換或擠佔成AI對話，觸碰的是用戶最重要的一塊心理領地。
微信的方案更接近「寄生」邏輯。 AI助理不取代任何介面，它藏在群組聊天裡、公眾號裡，作為一個Agent等待被喚起。可以設想這樣一個場景：在家庭微信群組裡，有人轉發了一篇關於親子露營地的公眾號長文，其他成員不需要點開閱讀，直接在群組裡讓AI助手總結要點，並讓它協調群成員的日曆、預訂文章裡推薦的那個營地。 Agent消化了公眾號的內容，並調用了小程式裡的預訂服務，基於群聊裡多個成員的日程資訊完成時間協調，最後把預訂結果推送回群組。
整個過程中，AI始終在群組聊天的脈絡中運作，用戶看到的仍是這個群組、這些人、這些對話。 Agent完成的「辦事」被嵌入社交關係裡，而不是另一個介面跳出來展示自己的存在感。
這種克制有它的代價。在微信裡，服務是以小程式的形態掛在平台上的，數以百萬計。要讓AI替使用者把這些事辦完，它需要理解的不只是使用者的意圖，還有這些服務本身的資料結構、頁面邏輯和互動流程。支付寶面對同樣的問題，兩者的解決方案出現了這個賽道上最核心的一次分歧。
讀螢幕和讀取原始碼，兩種解法誰更難
微信開放社群在2026年6月發布了《小程式AI開發模式（beta）存取指南》，提供了兩種模式。
第一種是「自動模式」。開發者授權平台在提審時讀取小程式源碼，AI透過分析源碼理解頁面結構和操作邏輯，直接操控小程式。第二種是“開發模式”，開發者按照微信定義的協議把自己的服務封裝成Skill，包含原子介面和原子組件，AI透過呼叫這些標準化介面完成任務。
支付寶的方案是「雙軌制」。據晚點報道，一邊推動有意願的商戶主動接入，把自己的服務做成AI可直接調用的MCP或Skill；一邊在用戶授權下，由AI通過對現有小程序界面的“讀屏”操作，兼容尚未改造的服務。
兩相對比，核心差異在於：改造未就緒的存量小程式時，微信要求開發者交出原始碼，支付寶選擇讓AI替用戶看圖操作。
從微信開放社群文件的陳述來看，「自動模式」在技術上是更徹底的方案。 AI讀取原始碼後，對頁面的理解是結構化的，操作路徑清晰可控，不像讀取螢幕那樣依賴視覺辨識和介面模擬，出錯機率更低。但這套方案把壓力轉嫁給了開發者。原始碼是小程式開發者的核心資產，交出原始碼意味著把自己的業務邏輯、資料結構、互動設計完整暴露給騰訊。對那些靠小程式做生意的中小商家來說，這不僅是安全層面的顧慮，更是商業上的風險：服務流程被平台完全掌握之後，在流量分發和議價上還剩多少空間？
如果不選“自動模式”，開發模式同樣不輕鬆。開發者需要重新整理業務流程，拆分成原子能力，並依照微信定義的協議封裝成Skill，再通過新的審核流程。一個餐飲小程式的點餐、付款、優惠券核銷、會員積分整套流程，拆解和封裝的工作量可能是初次開發的好幾成。誰來承擔這筆成本？微信沒有給出激勵方案，至少目前沒有。
支付寶的讀屏方案繞過了這些問題。它不需要商家配合，不需要改程式碼，甚至商家不需要知道自己的小程式正被AI操作。用戶對著對話式介面說一句“幫我買張去上海的火車票”，AI打開12306的小程式介面，識別出發地、目的地、車次列表、座位選擇按鈕、支付確認頁面，一步步模擬用戶的手指操作。對於已經完成MCP或Skill接入的商戶，AI可以直接調用標準化接口，體驗更流暢；對於海量尚未改造的長尾服務，讀屏提供了最低門檻的兼容路徑。
讀螢幕的問題也很直接：穩定性沒有經過大規模驗證。小程式的介面千差萬別，動態載入、彈跳廣告、版本更新導致的版面變化，都會增加AI辨識失敗的機率。一個支付確認按鈕的位置偏移了幾個像素，AI能不能準確命中？如果讀屏過程中出現誤操作，例如看錯了金額、選錯了收貨地址，責任歸誰？支付寶尚未公開相關的免責條款和糾紛處理機制。
這條路的邏輯是先讓使用者用起來。等商家看到AI帶來的訂單轉化，自然會主動接入標準介面以優化體驗。 C端倒逼B端。
3億筆交易驗證了什麼
在產品和生態之外，支付寶做了另一件事，跟AI怎麼付錢有關。
2026年5月的AI支付生態大會上，支付寶揭露AI支付筆數已超過3億筆，支援95%的通用智能體框架，同時發布了Token Pay和AI錢包。這兩個產品是理解Agent經濟基建的關鍵。
Token Pay解決的是極小額額度、高頻率支付的問題。當AI在兩個外送平台之間比價時，可能需要調用0.01元的驗證交易來確認帳戶有效；當AI在多個優惠券裡篩選最優組合時，每核驗一張券都是一次支付動作。這些交易額度微小，但頻率遠高於人類用戶。過去的支付體係是為「人確認、人支付」設計的，Token Pay把這個動作交給了Agent。
AI錢包則更像是寄了一張預算卡給Agent。使用者設定規則和上限，AI在規則內自主完成付款。螞蟻集團CEO韓歆毅在大會上提了一個判斷：將來可能會有無數個Agent活躍在經濟活動中，交互動作從人和人的交互，變成人和Agent的交互，以及Agent之間的交互。
3億筆這個數字的絕對值放在支付寶的整個年度交易規模裡不算大，但它的意義在於驗證了一件事：用戶已經允許AI替自己完成真實的商業履約，而不只是停留在查詢和比價。從一句話叫車點餐到AI付款扣款，這條服務閉環的技術鏈路和用戶授權鏈路都被打通了。
微信支付在AI改造這一側還沒有公開具體方案。微信支付同樣涵蓋大量用戶，但其場景更多與社交轉帳、紅包、商家收款鎖定。 Agent經濟的形態可能不同，雙方在支付基建上是否會形成新的差異，取決於微信AI助手正式發佈時是否配套推出類似的Agent支付能力。
生態正在被撕開兩個縫
支付寶和微信都指向了Agent服務入口，但中間路徑的不同會在小程式生態中撕開兩條走向不同的裂縫。
支付寶的讀屏方案讓大量長尾小程式被動AI化了。商家甚麼都沒做，用戶已經可以透過AI操作他們的服務。這會產生兩種反應：一部分商家發現AI帶來的訂單量在漲，主動接入MCP或Skill來優化體驗、爭取更多流量分發；另一部分商家則可能產生抵觸，因為訂單來源變模糊了。以前用戶在小程式內的每一次點擊都是可追蹤的，現在AI讀螢幕操作的那一段路徑，商家拿不到用戶行為數據。
支付寶內部顯然預判到了這一點。晚點報道稱，AI版支付寶上線後，面向商家和開發者的AI開放平台也將很快發布。這個平台大機率要解決的就是：如何讓商家既能享受AI帶來的訂單增量，又能保留對服務流程、用戶觸達和收益分配的可見性與控制力。
微信這側的壓力不一樣。源碼授權的門檻會把開發者篩成兩撥人。頭部開發者，有技術團隊，有商業談判籌碼，願意交出源碼或投入資源封裝Skill，換取微信AI助理的優先流量分發。但大量中小商家可能既不願交出原始碼，也無力負擔封裝成本。如果微信AI助理上線後流量確實向授權商家傾斜，那些未授權的小程式會在AI服務分發的通道裡被邊緣化。長此以往，微信的小程式生態可能進一步向頭部集中，而這與微信一貫強調的「去中心化」生態敘事之間存在著張力。
一個更隱密的問題藏在技術標準上。支付寶推MCP，微信定義了自己的一套小程式MCP協議，儘管名字相同，具體實現並不完全互通。一個餐飲商家想讓支付寶AI和微信AI都能呼叫自己的點餐服務，可能需要依照兩套規範分別封裝。這不是一個技術難題，但它是成本。哪一方先形成規模優勢，就有更大的議價權去推動產業事實標準。在支付寶AI支付已超過3億筆的時間點上，這個優勢暫時在支付寶一側。
回到用戶端，改造的最終結果可能重新定義人和手機的關係。支付寶的對話式介面如果跑通，使用者開啟支付寶的頻率和場景會改變。不是付錢的時候才打開，而是有需求的時候隨口問一句。微信的Agent如果跑通，用戶在群組聊天裡做事的方式會改變。不用跳出聊天介面去找服務，一切透過群組聊天裡的Agent完成。
兩個平台在2014年春節前夕的“紅包大戰”，改變的是用戶把錢放在哪個帳戶裡。這一次，爭奪的是用戶把「幫我辦事」這句話交給誰。
12年前，微信紅包被馬雲稱為「珍珠港偷襲」。 12年後，在微信AI消息真真假假傳了幾個月的當口，支付寶率先走到了台前。兩種路徑到底哪一種更接近Agent時代的真實需求，答案不在產品發布會上，在數以百萬計的小程式如何被重新喚起，以及數以億計的用戶第一次對著手機說出那句「幫我」之後的體驗裡。
