昨天，微信發了《 關於開發者接入微信AI生態的指引 》。
業內還是非常關注的，我看大家都在紛紛轉發。
但鮮有人真正去研究和細看那些具體接入文檔，大部分都是在說微信終於動手了之類滴。
我昨晚去小程序後臺看了一眼，發現這次覆蓋非常廣，我那個幾乎沒有用戶量、好久不看的小程序也被灰度到了。
於是我盤了一下這些文檔，通篇看下來，還是有非常多增量信息滴，值得業內深入研究——
（文檔地址：https://developers.weixin.qq.com/miniprogram/dev/ai/guide.html）
一、業內的反響應該說是波瀾不驚
先看熱度——
官方有兩個賬號——微信公開課、微信開發者，都發了這個公告。
微信公開課那篇，閱讀3.3萬，點贊410，轉發3533；
微信開發者那篇稍好一些，閱讀6.5萬，點贊660，轉發5647。
這兩個數放在微信官方賬號的量級裏，只能算普通，談不上爆。
再看接入文檔裏放在GitHub上那個官方示例Demo（ https://github.com/wechat-miniprogram/ai-mode-demo ）的數據。
這在一定程度上代表了有多少開發者真的動手了。
截止到今天中午12點，fork11，star92，這就非常一般了。
說明絕大多數開發者還在觀望，連Demo都懶得clone下來跑一遍。
當然，這也算正常。
畢竟GitHub上只是一個Demo，不是整個項目，而且文檔自己都寫着 “當前處於內測階段，暫未開放小程序AI開發模式的代碼提審”。
但波瀾不驚恰恰說明，很多開發者還停留在微信又搞了個AI功能的認知上。
這也是我要拆解這份文檔的原因。
二、自願原則很重要
《關於開發者接入微信AI生態的指引》開篇第一句就是，在充分尊重開發者權益和自主選擇的基礎上。
文末的Q&A裏還專門強調： 是否接入由開發者自主決定，接入與否不會影響現有的小程序服務。
爲啥要反覆說這個？
因爲微信很清楚開發者在怕什麼——怕被平臺強推，怕不接入就被穿小鞋。
微信趕緊把姿態擺得很低：我不強迫，你不接也不影響你現在的生意。
這種小心翼翼本身，就說明這事有多大。
在我看來，這也是微信要邏輯自洽的一種方式：
畢竟豆包手機上的時候，微信屏蔽了人家，豆包手機沒經過微信同意。
平臺和開發者的關係，很多時候逃不掉兩種模式——店大欺客和客大欺店。
微信有時候是客（對AppStore而言），有時候是店（對小程序而言）
這次的自然原則，也是避免被業界認爲是店大欺客。
它想通過自然的驅動讓大家順理成章地接進來。
這是微信AI雄心背後的耐心。
三、自動模式和開發者模式背後是兩種Agent範式
讓一個AI去用一個本來給人用的小程序，技術上到底有幾種姿勢？
答案是兩種。
第一條路，讓AI像人一樣盯着屏幕用手點。
這個叫GUI Agent，Computer Use走的就是這條路，豆包手機走的也是這條路。
邏輯很樸素：人怎麼用手機，AI就怎麼用。
好處是通用，壞處是有一定出錯的概率，而且又慢又巨消耗token。（用過Claude Code和CodeX的Computer Use就知道我說的事啥）
第二條路，讓小程序主動遞接口給AI。
它的邏輯反過來：讓開發者直接給數據和接口。好處是又穩又準，代價是開發者得動手。
自動模式基本等於第一條路（還是有點區別，後邊再說），開發模式等於第二條路。
微信兩個都要。
四、自動模式的精髓：讀屏加讀碼
那麼問題來了——
自動模式如何實現開發者零投入？
我們來看《微信AI自動模式服務條款》，很少有人認真讀這個——
我來個小範圍的中譯中：
第一項叫頁面交互技術授權——
微信AI可通過頁面交互技術的方式訪問或操作你開發、運營的小程序，包括但不限於獲取小程序服務頁面進行識別讀取、分析處理，根據需要代替微信用戶執行搜索、下單或者代替微信用戶輸入、授權服務所需的信息等操作。
（這個文檔沒有可訪問的鏈接，我複製了一份，想仔細讀的同學可在“衛夕指北”公衆號後臺回覆“條款”獲取全文，很值得讀）
翻譯過來就是AI像一個真人一樣，去看你小程序的頁面，然後動手幫用戶點擊和下單。
這就是標準的GUI Agent。
當然，微信AI團隊也一直在解決讀屏效率的問題，大家可以去搜這兩個東西：POINTS-GUI-G和UI-Oceanus。
前者在ScreenSpot-Pro這個公認業界最難的GUI定位基準上做到了59.9分，拿到同尺寸模型的SOTA。
這是微信AI技術團隊通過強化學習提高讀屏性能的技術成果。
爲什麼機器人要做成人的形狀？
原因是在於物理世界的基礎設施都是爲人設計的，人的形狀可以最大程度上覆用現有的基礎設施。
這也是微信AI團隊強化GUI讀屏技術的原因，畢竟小程序都是爲人設計的界面。
扯遠了，打住！
第二項授權叫小程序技能生成、調用授權。
平臺會讀取源碼，解析頁面結構和邏輯、API定義、交互流程，據此生成一個skills，之後就按這個skill走。
從讀屏到讀碼，這就高了一個段位，也比豆包手機純粹的GUI更高一級。
五、自動模式也不是木有代價滴
那麼問題來了——自動模式有代價嗎？
翻翻條款第8條——
微信AI功能可能會適當調整你的小程序的展示方式與用戶交互體驗，包括但不限於在後端運行小程序、僅展示部分小程序交互界面以及爲用戶提供快速確認或中止操作的能力等。
讀懂這句話了嗎？
在後端運行小程序、僅展示部分交互界面——
這意味着用戶基本上是看不到你精心設計的小程序首頁了。
你做的品牌門面、運營位、廣告banner，在AI模式下大概率被直接跳過。
當然，針對這個問題，微信也有一定的解法：原子組件（後邊會講）。
它讓商家能在AI的對話流裏，渲染出自己的、帶品牌的、能交互的卡片。
官方還要求，卡片右上角要提供進入小程序的入口，並配置關聯的小程序頁面，等於給商家在AI對話裏留了一扇自己的門。
再看第6條：
微信AI在獲得用戶授權後的行爲均視爲微信用戶操作的延伸和微信用戶的行爲，開發者無正當理由不得擅自變更、屏蔽或拒絕執行。
這就是說——
當你同意自動模式之後，AI替用戶操作你的小程序，法律上算用戶自己在操作，你不許攔着。
六、開發模式的三件套：原子接口、原子組件、skill
再來看開發者模式，核心就三個概念—— 原子接口、原子組件、Skill
原子接口， 是最小執行單元，封裝單一業務功能。
“查詢飲品列表”是一個原子接口，“創建訂單”是一個，「發起支付」又是一個。每個接口有標準化輸入和輸出。
原子組件， 是原子接口的可視化展示單元。
你可以理解成一個卡片，是接口吐出來一堆結構化數據渲染出來的，直接顯示在你跟AI的對話流裏。
Skill， 是把上面這些打包成的一個完整能力。
一個SKILL包含業務說明（SKILL.md）、模型可調用能力聲明（mcp.json）、原子接口和原子組件的代碼實現。
一個小程序最多30個 Skill 。
這三個東西通過小程序MCP連接起來，微信在文檔裏特意強調了自己的小程序MCP與標準MCP不同——
小程序MCP是向小程序AI暴露可調用能力的一套協議，與標準MCP不同，小程序MCP適應於小程序開發的特點，開發者只需要按設計提供完整的SKILL實現，小程序AI就能正確地推理及執行相應的原子接口。
個人感覺這三件套的設計哲學還挺清晰滴—— 簡單、穩、靈活。
七、一杯咖啡背後的Agent閉環
這套東西跑起來到底長什麼樣？
《運行機制》文檔裏有一張時序圖，能幫助我們直觀理解上面整個流程——
複述一遍這個點單全流程——
用戶說來杯拿鐵，AI推理後決定調用確認訂單（confirmOrder）接口。
微信客戶端啓動運行環境、下載分包，執行接口代碼，順手通過wx.login拿到用戶身份。
接口去請求開發者自己的第三方服務器創建訂單，信息回傳給AI。
AI再推理，下發渲染指令，原子組件把訂單渲染成一張確認卡片。用戶點確認支付，這個動作變成一條上行消息發回給AI。
AI調用payOrder接口，拉起wx.requestPayment，即微信支付收銀臺付款。
整個過程，用戶全程沒離開過那個對話框。
搜索、下單、支付、出結果，閉環全在對話流裏完成。
注意：運行環境也有隔離設計，文檔特別說明——
這個設計初衷是讓AI能執行開發者給的工具代碼，但不會把原小程序運行環境全盤暴露出來。
穩，是微信很看重的。
好，看完自動模式和開發者模式，我發現這和當年搜索引擎乾的事挺像——
搜索引擎一邊派爬蟲去無差別地抓取全網頁面，這是自動模式。
一邊又鼓勵站長做SEO、填結構化數據、提交sitemap，這是開發模式。
微信把這套打法原封不動搬到了AI Agent時代。
八、卡片和半屏頁面的考量
如果你仔細看接入文檔，就會發現文檔裏反覆出現卡片、半屏頁面、確認按鈕這種有些老派的東西。
這也是有考量的。
微信把關鍵步驟設計成卡片和半屏頁面，核心是想給給用戶足夠多的確認空間。
原子組件渲染GUI卡片展示在對話流裏，官方要求卡片右上角提供進入小程序的入口。
半屏頁面只允許展示更多詳情，不許跳出去到公衆號、視頻號、其他小程序、地圖App。
用戶在對話裏說需求，但關鍵確認要落到卡片上。
Agent最大的問題之一就是喜歡自以爲是地腦補。
比如用戶說那個就猜一個，這放在聊天裏是幻覺，但放在交易裏，那是要出事故滴。
微信AI通過不同的確認卡片，就是想儘可能消除這種不確定性。
九、注意力權重表開發者應該引起重視
再看官方的最佳實踐，我覺得很有意思的是這個——
《最佳實踐》裏有一張注意力權重表：
原子接口返回的content，五顆星。它離當前決策點最近，模型會把它當作事實加動作來讀取。
mcp.json裏的description，四顆星，影響模型選不選這個接口。
inputSchema.description，四顆星，影響模型怎麼填參數。
SKILL.md，三顆星，適合寫業務流程編排和跨接口規則。
這就是從提示詞工程拆到了產品工程。
所以，開發者一定要注意，寫錯位置，模型就容易跑偏。
比如ID類字段，反例是隻寫飲品ID。推薦做法是聲明取值來源——飲品唯一標識，取自上游接口searchDrinks或getRecommendedDrinks返回。
爲什麼要這麼寫？
因爲業務ID容易被模型按格式湊出來，不聲明來源的話模型真的會編一個。
十、登錄態和工具：微信的那條護城河
《能力介紹》裏有句話，我覺得極其重要——
用戶在此模式下的登錄身份跟原小程序保持一致，開發者可以通過storage接口共享小程序內的登錄憑證，也可以通過wx.login、wx.getPhoneNumber等接口完成登錄流程。
這意味着AI替用戶下單時，就已經在小程序裏登錄好的賬號、地址、會員等級、優惠券，全都無縫繼承。
這是豆包靠讀屏極難復刻的體驗。
身份的連續性，就是微信無形的護城河。
別人做Agent找來找去，想要的入口就是微信。
而微信做Agent——它本身就是入口。
對比一下你就更有感覺：
ChatGPT從今年2月開始測廣告，接入了Stripe支付、Shopify電商、DoorDash外賣，鉚足了勁想讓用戶在對話裏直接成交。
結果目前只有2.1%的查詢跟交易有關。
這裏邊就有一個技術上的尷尬——
Agent通過API完成的交易，傳統歸因工具根本追蹤不到，沒有瀏覽器session，沒有cookie。
別家公司做Agent，最頭疼的是沒東西可調，得滿世界求着別人接入。
而微信手裏這座工具庫，規模大的很：14.32億月活體量下，點餐、打車、掛號、繳費.....幾百萬個，還都跟微信支付、社交、身份體系長在一起。
從這個意義上，微信AI團隊對自己的優勢理解得很深刻。
那麼問題來了——微信AI會怎樣改變小程序生態的競爭規則？
過去，小程序要爭入口、爭搜索詞、爭最近使用。
以後用戶通過微信AI表達需求，AI會在可用小程序裏做匹配。
開發者寫在agent.skills.description、mcp.json description、page-meta.json裏的文字，就會變成新的可見性資產。
文檔裏甚至說，小程序AI可以在回覆裏帶上小程序短鏈，短鏈文本由模型根據聊天上下文、頁面name、頁面description、頁面query動態生成。
這意味着小程序開發者的確要注意： 一個字段寫得含糊，就可能導致模型選錯接口。
開發者文檔裏那些看起來有些枯燥的禁令和示例，得認真看。
結語
2017年，小程序讓很多服務不用下載App，解決了安裝和分發問題。
2026年，小程序接入微信AI，想進一步解決尋找和調用問題。
以前是用完即走，現在是來都不用來就用完了。
小程序會從輕應用變成可調度服務。
對話成了新的UI，小程序會變成另一個物種。
當然，別把這事想得過於一帆風順——
開發者積極性是一個雞生蛋蛋生機的問題。
有人用纔能有開發者接入，有足夠開發者接入纔能有人用。
看報道微信目前還是積極和美團、攜程等頭部聊接入，但撬動長尾開發者的速度到底是快還是慢，還有待觀察。
然後調度本身也是地獄級難題。
幾百萬個小程序要協同、要排序，AI憑什麼知道你說想喝咖啡時該調瑞幸還是星巴克？
最重要的也是一個習慣問題。
用戶真的喜歡在對話框裏打車訂外賣嗎，這種交互是未來最優解嗎？
很難說。
比如到底有多少人通過千問下單點外賣？
路還很長，不過我相信微信團隊。
這年頭，認真寫文章的人不多了，加個關注吧！
- 完-
作者簡介：衛夕，公衆號“衛夕指北”出品人，科技專欄作者，專寫長文，專寫不一樣的，專注剖析AI、廣告及互聯網的底層邏輯；不關注這個賬號，你都不知道你會錯過神馬！