微信小程式的定位在變化？

　　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 和體驗不佳的服務号是合情合理的，不管從哪個角度來看，對開發者有好處，對微信也有好處。

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

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

　　為什麼？小程式想要連接配接一切