微信小程式想要什麼？by 阿禅 Jason Ng

　　今天，1 月 9 日，小程式正式釋出，使用者可以體驗到各種各樣的小程式，從 8 月中旬寫了《别開發 app 了》後，我對小程式和微信的觀察沒有停止過，通過外部的觀察以及和一些業内朋友交流，我逐漸清晰地推導出，微信到底想用小程式幹什麼，以及從小程式當中，我們能看到哪些可用創業的場景。（用一句話總結了張小龍對小程式的定義：小程式希望用即用即走的方式激活線下的弱連接配接場景。）

 1、小程式的定位在變化？

1 年前的微信公開課，張小龍提出要做應用号，經過 8 個月的研發，小程式（應用号）開始内測。如果你有觀察從内測至今微信小程式提供的 API、背景功能等的變化，你會發現，似乎過去 2 個月微信團隊做的事比之前 8 個月還要多。

微信團隊有 1000 多人，參與小程式項目的人也至少有二三十人，如果這是一個創業公司的項目，顯然一年的開發周期太長了。況且，微信團隊已經有數年做公衆平台的經驗，這樣一個平台，如果純開發，可能一兩個月就能完成。

是什麼原因導緻 1 年後才釋出當初被外界期待萬分的應用号？

我的了解是，微信團隊也在推演小程式的定位，在過去一年，尤其是内測前的 8 個月，他們可能推翻了多個版本。

 1.1、給服務号接棒的小程式

雖然服務号上誕生了招商銀行、朝夕月曆、助理來也、Yoli 口語等優秀的服務号，但不可否認的是，服務号生态遠遠沒有訂閱号的繁榮。

我們能輕松查到，像一條、二更、新世相等公司，通過營運訂閱号，獲得了豐厚的融資，訂閱号領域也出現了很多周邊服務，比如 WeMedia，這家為訂閱号提供服務的公司已經在新三闆上市；比如新榜，這家公司彙聚了非常多的訂閱号資料。

前面提到的 3 個訂閱号，他們初期隻做了訂閱号，獲得了投資，但你幾乎沒有聽到多少公司是「隻」做了服務号，然後做得不錯而獲得投資。

雖然我們不能隻從一小部分産品獲得融資的情況去判斷某個平台是否足夠繁華，但毋庸置疑的是，整個訂閱号生态被曝光、被投資的總量相對服務号多了幾個數量級。

如果訂閱号是微信無心插柳締造了一個新的創業生态，那麼服務号顯然是微信想仿照訂閱号的路線，把内容之外的東西，也連接配接到微信，這些内容之外的東西，就是服務。

可惜的是，服務号發展得遠遠沒有訂閱号好，但微信從戰略層面上，是希望連接配接一切的，如果服務号沒有很好地解決「微信連接配接一切」的目的，是否應該有新的産品來完成這個使命？

我相信，這是小程式（應用号）誕生的背景之一，它要接棒服務号，連接配接更多服務和場景。

 1.2

連接配接新場景的小程式

利用小程式提供的架構和 API，開發出來的程式體驗是優于 HTML5 的，于是在 9 月底剛開始内測時，業界就出現了很多争論，包括小程式會不會替代 HTML5，會不會替代 app。這些讨論都是脫離場景的。

如果說 App 會被替代，它肯定不是被小程式替代，而是被微信替代，因為我們在微信裡已經能找到 90% 以上的常用服務，完全不需要去下載下傳一個 app。

不久前，張小龍朋友圈發了這張照片：

照片中你能看到，在安卓系統裡，小程式能直接「釘在」桌面，就像一個 app 那樣。仔細觀察這張圖，你會發現大多數都是中大型公司的産品，比如去哪兒、貓眼、攜程、海航等。

如果我們認同，張小龍分享的照片，代表了當時微信對小程式的期待，那麼，當時小程式的定位就是要替代原生 app，讓使用者在微信裡就能瞬間獲得服務。

然而，在微信公開課上，他卻舉了這樣兩個小程式的例子：

        在公共汽車站，你掃一下公交站牌的二維碼就可以了解下一輛公共汽車到站的時間

        在汽車站，掃一下汽車站的二維碼就可以購買車票，而不需要排長隊

如果我們認同，張小龍的演講，代表了當時微信對小程式的期待，那麼，這個時候，小程式的定位其實是連接配接更多線下場景。

我相信，過去一年，張小龍本人也好，小程式團隊也好，都在不斷思考和推演，小程式到底要解決哪些需求，滿足哪些場景的需要。從最新在外界看到的資訊來看，似乎，小程式希望更多地連接配接線下。

 1.3

既替代服務号又連接配接新場景的小程式

實際上，從功能角度，小程式替代一些低頻的 app 和體驗不佳的服務号是合情合理的，不管從哪個角度來看，對開發者有好處，對微信也有好處。

另一方面，線下仍有很多未被連接配接的場景，微信期待用小程式去連接配接這些場景，戰略上，也是符合邏輯的。

外界對小程式的期待不斷在變化，微信對小程式的定位，也一直在推演。從外部看到的資訊來看，微信似乎更偏向于連接配接線下。

為什麼？

 2

小程式想要連接配接一切

2014 年 11 月，馬化騰在「世界網際網路大會」上提出騰訊要「連接配接一切」，要成為網際網路連接配接器。

毫無疑問，連接配接一切的重任落在了微信身上。

何為連接配接一切？

        連接配接人與人

        連接配接人與服務

        連接配接人與商業

        連接配接人與物品

人與人之間的連接配接，第一個版本的微信已經實作，目前，微信已經有超過 8 億的日活使用者，幾乎每個有手機的中國人，已經被微信連接配接。

人與服務的連接配接，也基本上通過服務号和微信内置的服務連接配接起來。這裡所說的服務包括了内容。我們可以在微信裡完成閱讀、購物、娛樂等。

人與商業的連接配接，一個層面是建立在服務上，另一個層面是建立支付手段上，從這個角度，微信也已經連接配接了商業。

然而，物品仍然沒被連接配接。

一張桌子、一支筆、一台空調、一輛公共汽車、一隻狗……都沒有通過微信與人産生連接配接。

微信以及騰訊的野心是要連接配接一切，但世界上仍然有很多物品沒有被電子化，沒有被電子化意味着無法被連接配接起來。

怎麼辦？

過去幾年，我們看到很多「智能裝置」出現，很多創業公司強行把晶片塞進手表、空調、自行車、水杯、台燈等現實世界的物品裡，然後通過手機的 app 與這些物品産生連接配接。

似乎這是解決人與物品連接配接的好方法，然而，我們不可能在所有現實世界的物品裡都塞上一塊晶片，那麼，這些物品該如何被連接配接起來？

一種很容易想到的思路是，利用圖像識别和 AR 技術，通過攝像頭，把現實世界的物品一一識别，就像以下這張「科幻」圖檔一樣：

然而，如果你玩過最近支付寶推出的 AR 紅包，你會發現，計算機還遠遠不能精準識别實體世界的物品，換個角度、變換一下光線，就會出現識别誤差，我們也不可能花時間讓機器 360 ° 掃描所有物品。

那麼，在目前技術條件下，實作人與物品連接配接的「折中」解決方案有可能是什麼？

二維碼

設想一張桌子、一支筆、一台空調、一輛公共汽車、一隻狗……上面都有一個二維碼，通過掃碼，我們能進入相應的服務，比如桌子的二維碼告訴你桌子的産地，公共汽車的二維碼告訴你下一輛車什麼時候到你不用着急擠上去，狗身上的二維碼記錄了你與它之間的回憶……

似乎，通過一張簡單的黑白二維碼，我們就能輕易把現實世界的物品「拉到」電子世界中去。二維碼成為了現實世界和電子世界的超連結。

你可能會問，難道 AR 不是更好的解決方案麼？二維碼那麼醜。可是，剛才說了，圖像識别技術并不成熟；難道用 NFC 晶片不是更好的解決方案麼？每個物品都貼一個 NFC 晶片不更友善麼？況且 NFC 成本那麼低。可是，二維碼的成本更低，而且，不是每一台手機都能識别 NFC，但可能中國每台手機，都有能識别二維碼的程式 — 微信也好，支付寶也好。

是以二維碼成為了目前技術條件下，最有可能實作人與物品連接配接的「技術」手段。二維碼的背後，可以是資訊，也可以是服務，微信希望用小程式來承載這些資訊和服務。

從某種角度上來說，小程式就是微信嘗試通過二維碼連接配接實體世界的實驗田。

這就能解釋，為什麼張小龍舉的兩個例子，都是線下的場景。

其實，從小程式的功能限制上，也能看出這個偏向性。

 3

人為的線上導流限制

微信小程式無法分享到朋友圈，甚至無法通過長按二維碼進入，也就是說，即使你在一個網頁或一篇訂閱号的文章裡放上小程式的二維碼，使用者還是無法長按打開小程式。

使用者隻能通過：

        線下掃碼

        搜尋

        朋友分享

來打開小程式。

微信人為地限制了小程式的線上導流，通過主動搜尋進入，量顯然不會特别大，朋友之間的分享，擴散的速度也有限，可以說，微信在逼迫開發者嘗試線下的導流管道。

這與微信想通過二維碼連接配接現實世界的戰略是具有一緻性的。

 4

為什麼是線下？

如果前面的論述是正确的，那麼，小程式的出現，要解決的就不是 HTML5 的體驗問題，沒錯，它是提高了網頁應用的體驗，但更多地，它是要解決商業問題。

過去 1 年，我不少創業圈的朋友都感歎，五六年前，做一個純線上的産品，可能能養活一家公司甚至上市，但如今，開發一個純線上的産品，比如社群、比如工具、比如内容，已經沒有多少生存空間了。

App 的世界已經趨于飽和，我們幾乎可以在 App Store 找到各種各樣滿足不同需求的 app，每個 app 都在互相競争使用者的時間，線上的競争如此激烈，一個新網站或新 app，可能一年隻能獲得一個使用者 10 秒的使用時間。

面對這樣的現狀，作為一個創業者，如何才能獲得更多的使用者時間？

設想這樣一個圖景，你的創業項目是一本書，你最大的期望是希望使用者把書讀完。然而，使用者在閱讀時，可能一邊還在看微信，一邊在看綜藝節目，一邊還在吃着薯片，可能一個微信通知，就讓使用者離開了閱讀狀态，「專注」地去回複微信，你的使用者時間被微信「搶走」了。

那麼，如果你有權力，可以把使用者都關在一個密閉的小房間裡，并且能取走他們身邊所有電子裝置和零食，隻給他們一本書，他們可能一兩天就能把一本書看完。在這個小房間裡，使用者的時間都是你的。

又或者，你的書有足夠大的吸引力，能持續占有使用者的關注度，使用者也可能很快地把書讀完。

再或者，你能證明，讀完你的書，使用者能馬上走上通往财務自由之路，使用者也可能很快把書看完。

在這個圖景裡，書是你的産品，小房間是場景，吸引力就是你提供的精細服務。

線上上，我們已經很難把使用者裝進一個「小房間」裡，讓它隻能看書，因為面對螢幕時，使用者有太多選擇。

但線上下，使用者的時間是可以被某個線下場景獨占的，比如等公交時，被公交站獨占，吃飯時，被餐館獨占，那麼，如果在這些使用者時間被獨占的場景，提供最适合這個場景的服務，是否更容易讓使用者從微信、從手遊中離開，去使用這個服務？

也就是說，與線下的場景分享它所占有的使用者時間是有可能的。

就像張小龍在演講中提到的，如果你去到長途客運站，剛好你看到有個二維碼可以掃碼購買車票，顯然在這種場景下，你掃碼的可能性會比線上上時高，這樣，就相當于你原本被客運站獨占了時間，這個購票産品，在這個場景裡，與客運站分享了你的時間。

這樣一種場景化的推廣方式，是否比線上上投放一個廣告更容易獲得使用者？實際上，線上推廣的成本已經奇高無比，而且往往很多推廣帶來的都隻是一次性的使用者，不少創業者已經在思考如何通過線下場景化的方式更低成本地獲客。

小程式主推線下場景，除了帶着騰訊「連接配接一切」的目的，其實也迎合了挖掘線下流量的趨勢。

 5

小程式想要最短服務路徑

微信試圖用小程式來重新定義服務路徑的長度。

過去幾個月，業界一直在讨論微信對小程式的定義：即用即走、觸手可及。這一度讓開發者疑惑，因為如果微信你期待我做的産品是即用即走的，那為什麼我要開發小程式？難道産品不應該想方設法粘住使用者麼？

這種疑惑，是因為很多人把眼光放到了「即走」上面。事實上，好的産品使用者自然會回來使用，不必花小伎倆留住使用者，就像 Google，你不會因為它給你提供了精準的搜尋結果「即用即走」了然後再也不用，相反，下次想搜尋時，你還是會打開 Google。是以問題就變成，我們怎樣才能讓使用者判斷我們的産品是好産品？

使用者的時間很寶貴，要讓使用者第一次使用就喜歡我們的産品，顯然要讓使用者在最短時間裡感受産品的核心，判斷是不是他想要的，而不是：

        打開 app，預設看幾秒鐘廣告

        第一次使用需要花時間注冊

        功能層層堆疊，難以查找

就像寫文章一樣，如果讀者沒有在短時間内判斷文章的價值，他就可能停止閱讀。

是以，如果我們做的産品确實是好産品，問題回到了「即用」上面，如何讓使用者馬上感受産品的好？

答案是 — 建立最短路徑。

如果我們認同，幫使用者節省時間的産品是好産品，那麼，服務号就不是一個好産品。

我明明隻是想買一張汽車票，我需要掃碼關注一個買票的服務号，關注後我需要花時間尋找買票的菜單，然後可能還需要注冊才能完成支付。為什麼不能掃碼後直接購買？為什麼要先關注？為什麼不能在武漢掃碼就預設選擇武漢出發的票，在北京南站掃碼就預設選擇北京南站？

小程式沒有關注功能，它所期待的，是使用者掃碼後立即獲得服務，就像張小龍在演講時舉的例子，掃碼後立即購票，不用關注，也不用花時間尋找購買按鈕，甚至，掃碼後自動用微信帳号登入，連注冊的時間也節省下來。

相比之下，小程式比服務号更節省使用者時間，縮短了使用者獲得服務的路徑。使用者在整個過程中是暢快且愉悅的，當他下一次需要服務時，自然會想起曾經「即用」過的産品。

從這個角度，我們可以推斷，微信之是以要逐漸用小程式替代服務号，是因為服務号并沒有為使用者建立比 app 更快的服務路徑，沒有節省使用者時間。

 6

場景化的最短路徑

脫離場景講縮短路徑是耍流氓，不妨舉幾個例子。

 6.1

線下場景

一個小程式能生成 10000 個帶參數二維碼，使用者通過不同的二維碼可以進入同一個小程式不同的頁面。

拿前面公共汽車的例子舉例。假設某個城市，每一個公交站的每一路車的站牌上都貼了不同的二維碼，在等車的乘客掃某路車的二維碼，就可以知道該路車的位置以及預計到達時間。

如果拿服務号來做，也能生成帶參數二維碼，但使用者依然需要點選關注和點對應的連結進入公共汽車的頁面。如果拿 app 來做，除了需要下載下傳之外，我們還需要輸入想查找的公共汽車号碼。

顯然，小程式在等車這個場景中，縮短了使用者獲得資訊的路徑。使用者将會更喜歡。

你可能會說，上面說的，用 HTML5 不也可以實作麼？每一路車不就是一個不同的 URL 麼？是的，但在這個場景裡，HTML 的體驗遠遠沒有小程式優秀。

是以，小程式可以縮短線下場景的服務路徑。

 6.2

社群場景

在《小程式的想象力》這篇文章裡，我曾經說過，微信小程式是适合做垂直社交産品的。

你會發現，不管哪個産品裡，但凡我們跟其他人建立了聯系，幾乎都會交換微信号，然後就在微信裡繼續聊，而很少回到原來的産品。

因為我們的社交關系已經被微信牢牢握住。然而，每個人都有垂直社交的需求，比如，我喜歡看賽車，是以想跟其他喜歡看賽車的人交流；他喜歡旅遊，想和其他驢友交流心得；A 和 B 都是馮大輝的粉絲，他們想和其他大輝粉一起交流……

過去大半年，你會發現大輝經常在公衆号推他的小道消息讀者群，最初，這個讀者群是基于另一個 app 的，後來，這個 app 出了微信網頁版。

你可以很容易想象，從公衆号導流到一個 app 是很不容易的，況且，還是導流到一個非剛需的垂直社交圈子裡。

路徑太長，使用者很容易流失。

設想小道消息讀者群，或者可能會有的「可能吧讀者群」是一個微信小程式，使用者在微信裡就直接使用，轉化率是不是會高很多？

如果結合小程式可以在對話清單置頂、可以收藏、可以深度搜尋的特點，這種垂直社交的轉化率和活躍度是不是會高很多？

是以，小程式可以縮短社群場景的轉化路徑。

 6.3

協作場景

和社群場景類似，以往我們要在手機上與同僚做工作上的溝通或協作要通過微信之外的工具，但與外部合作夥伴的溝通又必須回到微信，資訊在兩個工具之間并不能做很好互通，在這種場景裡，溝通的路徑被拉長了。

設想一個公司内部溝通用的是阿裡的釘釘，但與外部溝通依然是微信，假設（不過不太可能）阿裡做了一個微信小程式版本的釘釘，這個公司的協作和溝通就可以全部在微信裡進行，不管是資訊的傳輸路徑還是員工的協作路徑，都被縮短了一大截。

你可能會問，為什麼做小程式就是縮短了路徑？因為絕大部分中國使用者的絕大部分時間，都被微信這個「場景」霸占了，通過小程式，可以與微信分享使用者的時間。

是以，小程式可以縮短協作場景的溝通路徑。

 7

小程式生态的 3 個階段

這篇文章其實是比較發散的，如果你已經讀到這裡，那麼，讓我們回到小程式本身吧。

因為寫了不少關于小程式的文章，過去幾個月很多人問我小程式适合做什麼，應該怎樣做，我的了解是這樣的：

        小程式是一個生态

        這個生态希望連接配接更多線下場景

        生态裡出現的産品，會分 3 個階段

這 3 階段分别為：

 7.1

摸索與搬遷階段

第一個階段，以開發者的摸索和網際網路公司的搬遷為主。開發者會在這個平台做各種小玩意嘗鮮，看看能玩出什麼花。網際網路公司會把已有的業務，複制一份到小程式平台，比如美團、攜程等。

這個階段裡，會出現各種圍繞小程式生态的産品，比如：

        外包

        快速拼裝小程式的服務

        教育訓練（比如有可能學院）

        資料統計（比如阿拉丁）

        廣告聯盟

        小程式商店

這個階段，大家都在摸索。

一句題外話，我認為小程式商店對使用者來說沒有多大意義，因為小程式的獲得應該是場景化的，而不是通過在商店探索獲得，試想我們已經有多久沒有在 App Store 探索新的 app 了？但對開發者來說，用來研究競争對手，是個不錯的工具，用來做資料服務幫助廣告主做投放決策，也是不錯的，本質是，這是個 to B 的産品。

 7.2

工具階段

因為大部分嘗鮮者都是網際網路公司，大部分網際網路公司的線下能力是比較弱的，如果要針對微信場景做深度嘗試，從成本等角度考慮，他們會優先尋找基于微信的線上場景。

網際網路創業者的嗅覺很敏銳，他們會很快找到使用者在微信裡未被滿足且能用小程式滿足的需求，前面提到的社群場景、協作場景有可能會在第二階段出現。

 7.3

場景化階段

有了開發者的嘗鮮和網際網路公司的産品搬遷，小程式已經逐漸為人所知，真正的場景化小程式會在這個階段出現并被推廣到普通使用者身上。

這個階段強調的是場景化和本地化，線下的流量在這個階段可能才被真正激活，被真正地連接配接起來。

 8

通過小程式看趨勢

小程式的本質是提供一種服務觸手可及的能力，并建議開發者嘗試連接配接線下場景，一方面為開發者帶來新的流量，另一方面，幫助微信建構更大的帝國。

這篇文章的目的，與其說是分析微信想要什麼，不如說通過微信小程式看創業的趨勢，因為小程式想要的，其實也是創業者想要的。

前面舉例的場景化最短路徑，如果支付寶也做一套應用号，我相信他們也會采用同樣的思路。

舉這些例子，包括分析微信為什麼要讓小程式先主攻線下，并不是想說微信有多精明，而是想通過我觀察到的現象，抽離出一些趨勢，比如線上已經沒有太多流量空間但線下依然有可連接配接的機會，比如能幫自己節省時間可能是使用者越來越看重的産品特性，比如場景化的精細營運獲得成功的可能性更大。

即使沒有小程式，這些結論在 2017 年依然成立，甚至接下來幾年，也是做産品、創業時應該花時間去思考和實踐的。