今天，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 年依然成立，甚至接下來幾年，也是做產品、創業時應該花時間去思考和實踐的。
更多微信小程式想要什麼相關文章請關注PHP中文網！
