今天小編分享的互聯網經驗：對話凡泰極客梁啓鴻：AI時代，代碼和數據的關系将被重新定義，歡迎閲讀。
钛媒體特别專題策劃《數字思考者 50 人》：探訪中國深刻的數字化思考者群體。我們理解的 "TechThinker"，涵蓋了中國數字化浪潮中的技術踐行者、政策制定者與投資決策者。在這場長達 10 年的乘風破浪中，我們每個人都在分享技術進步的果實，卻鮮有人知道結果背後的故事。我們期待通過《數字思考者 50 人》，還原中國數字化推進過程中的關鍵決策，同時也為你呈現數字思考者們在這個技術大變革時代對未來的展望和判斷。
本期嘉賓是凡泰極客創始人梁啓鴻，他曾任廣發證券董事總經理兼首席架構師、雅虎北京研究院首席架構師、太陽微系統大中華區資深架構師，更早前曾擔任美林、摩根大通顧問、摩根士丹利研發工程師、IBMT.J. 沃森研究中心高級助理程式員，是一個橫跨金融與互聯網、技術與業務的多維度跨界思考者、實踐者。
凡泰極客成立于 2017 年，是行業領先的企業級小程式數字生态服務商，旗下產品與服務已經覆蓋超過 800 家企業用户，在政企、電商、航空、園區、零售、教育等領網域有成熟解決方案。該公司旗下核心產品 FinClip 是目前市場上獨立于巨頭企業外的唯一 ToB 小程式技術產品，技術定位是供企業可私有化部署或者雲端自部署、自運營的應用商店技術，其中的應用技術載體為小程式，兼容主流互聯網平台的小程式規範與标準。
" 能做，要排期。" 是 IT 開發者日常對話中的經驗語錄。
以一家大型銀行為例，通常内部有數百個部門和分行機構，每個機構和分行都想嘗試觸達客户。需求排期帶來的長時間排隊因此幾乎無可避免。
解決排期之後，新問題随之而來——到底哪個功能才能放在首頁，企業并沒能找到決定排序優先級的最佳路徑。事實上，客户訴求千差萬别，無論怎樣排序都不能滿足業務部門的需求，也不能滿足客户的需求。
這些觀察正來自于梁啓鴻多年業界的實踐，以上難題也正是傳統數字化困局的典型表現。換句話説，傳統的軟體開發模式，因其高成本、長周期和僵化的架構，已經難以滿足現代企業對敏捷性和用户體驗的迫切需求。
問題何解？梁啓鴻看中了小程式的價值。
在梁啓鴻看來，小程式具備跨終端運行、支持設備間傳遞接力、便于傳播分享等諸多優勢。基于以上特性，小程式不僅使用户能夠随需随用，更為企業開辟了新的場景發現和創新機制。更進一步，小程式的松散耦合架構也為企業構建全新數字化基礎設施提供了可能性。
在這一架構下，企業能夠以 " 應用商店 " 的形式，自主運營小程式商店，管理自己的軟體供應鏈。同時，這一變革不僅限于 IT 内部的優化，更使企業能夠從外部合作夥伴處獲得小程式内容，建立自己的數字生态系統，實現數字資源的交換與整合。
梁啓鴻認為，傳統的 IT 開發模式，類似于 " 計劃經濟 "，需要預先規劃好所有環節，但往往落後于變化迅速的市場。小程式的松散耦合架構，更像是 " 市場經濟 "，允許機構在建立平台後，根據需要随時調整業務功能。這一思維的轉變，不僅打破了企業 IT 的邊界，還使得 IT 資源可以全社會調度，有效消除信息孤島。
基于小程式架構搭建的 " 應用商店 " 由此成為企業内部外 IT 力量平等競逐的舞台，企業能在不影響現有操作的情況下，快速試驗和迭代新的服務或產品。文章開頭提及的開發排期慢、需求發現機制不足的問題得以解決。
AI 的價值也在顯現，大語言模型賦予的復雜的上下文描述能力，使得小程式的功能性和智能化得到顯著加強。梁啓鴻介紹，當前小程式及其服務場景可以封裝于各個标準化單元之内，每一個單元均可通過復雜的上下文進行描述，轉化為内容豐富的文本。這些數據可以被存儲于矢量數據庫中，與大型語言模型進行匹配，從而實現更高效的數據處理和應用。
" 大語言模型能相當程度地幫助我們去實現搜索功能。在過去，哪怕是大型銀行機構的 App 也無法做出像樣的搜索功能。" 梁啓鴻表示。
在這一過程中，" 數據 " 這一概念的内涵和外延發生了重大變化——從單純的結構化數據演變為帶代碼的數據。
對于這一類全新的數據形式，钛媒體聯合創始人、聯席 CEO 劉湘明結合 " 富媒體 "（這主要指具有動畫、聲音、視頻和互動性信息的豐富的媒體形式）的概念進而提出 " 富數據 " 的新概念。
與傳統的結構化數據相比，富數據有潛力實現更加動态的互動和執行功能。這種數據的智能化不僅有潛力提高數據的處理效率，也使得數據能夠在多個系統和平台之間更加自由地流動和互動，極大地增強了數據的應用價值和創新潛力。
概言之，整合小程式的敏捷性、大語言模型的智能化能力以及 " 富數據 " 的高效數據處理，我們有望見證一個全新的企業軟體開發和運營模式的誕生。這一模式有望解決傳統 IT 開發的高成本和低效率問題，也可能為企業提供更為精準和個性化的服務。
在這個意義上講，對于軟體開發者和企業決策者而言，現在是需要重新考慮和布局未來技術路線圖的時刻。
觀點摘錄：
1. 過去的 IT 開發模式是 " 計劃經濟模式 "，業務功能點的實現需要預先作出詳盡甚至過度的統籌規劃。松散耦合架構可以類比成 " 市場經濟模式 "，讓業務部門按市場需要、局部需求敏捷實現應用。這是一個重大的思維改變。
2. 沒有第三方社會力量參與的 App，體量再大也是很難真正定義為超級 App。
3. 傳統企業觀念下，似乎有數據就能獲得所謂智能，但實際上智能在代碼裏。在馮諾依曼架構下，存儲與計算是分離的，将數據和代碼分開處理，未來是否會實現存算訓一體化。
4. 與中國相比，整體海外市場的運營能力非常薄弱，差距在 5 年以上。在海外需要 " 扶上馬，送 N 程 "。
5. 過去以來，哪怕是很大型的銀行機構的 App 也無法做出像樣的搜索業務功能發現機制，例如搜索能力就幾乎無用。傳統 App 往往不得不通過界面堆砌和深層的菜單去暴露功能入口，讓用户自己去搜尋、發現，大語言模型 + 檢索增強生成（RAG）可能從根本上解決這個問題。
以下是對談實錄，钛媒體 APP 整理（有删節）：
IT 開發模式要從 " 計劃經濟 " 轉向 " 市場經濟 "
钛媒體：從金融行業的即時通訊工具起步到如今專注于小程式，你創業是如何一步步迭代到今天的？
梁啓鴻：從創業最開始到今天，我們一步一步迭代，做了很多事情。在證券公司我們主要是做财富管理咨詢，财富管理咨詢的數字化需要一個合規可控的即時通訊工具。在探索的過程中我們發現，投資顧問和客户之間的咨詢交流需要一個輕應用，可以在交流匯報的過程中轉發分享交流。
2017 年，我們正在做運行在即時通訊裏的輕應用技術。微信小程式也剛剛推出，我們認為輕應用的想法與小程式非常相似。我們意識到小程式有在互聯網一統天下的趨勢，而且它更有生命力。因此，我們決定采用兼容小程式的方式來實現我們的輕應用技術。
在這一過程中我們發現，金融行業的即時通訊是一個場景發現機制和場景創新機制。比方我們去尋求客服服務的時候，金融機構 App 的反饋并不只是文字流信息，更包括着許多場景。在這一過程中，小程式的作用就可以體現出來，一個場景也就可以意味着一個小程式。
後續我們放棄了即時通訊的方向，專注在小程式領網域。我們認為類似微信那樣的技術架構，把松散耦合這件事情做到了極致，企業 IT 如果獲得類似的能力，對企業軟體開發促進裨益巨大。事實上，在軟體工程中，以前一直都有插件的概念，但是每個插件的生命周期和宿主是完全綁定一起的。而在微信中，每個小程式都是獨立生存的。微信 APP 與小程式兩方的更新迭代完全無關，在這種完全解耦的情況下，安全性仍能夠得到保障，并不用擔心幾百萬第三方小程式會拖累微信 APP 本身。
因此，我們發現，小程式可能非常承擔适合企業軟體載體的角色。
長期以來，開發難是企業的一大痛點。以銀行為例，幾百個部門、眾多的分行，每個部門和分行都想嘗試觸達客户。過去金融機構開放的慣常做法是排期，各個部門需要長時間排隊。
另外，部門間還需要考慮 " 競争排名 "，決定哪個部門的哪個功能應該放在首頁。但沒有一個最佳的路徑來決定排序算法和優先級。因為每個客户的訴求都不一樣，有些客户關注信貸，有些關注信用卡，有些關注其他方面。因此，無論怎樣排序，都不能滿足業務部門的需求，也不能滿足客户消費者的需求。因此，發現機制非常重要。
App 的 UI 界面無法簡單粗暴 " 陳列 " 幾十個或幾百個功能點。因此，我們需要一種更智能的方法，讓客户方便的發現。
要實現這一點，就要做到檢索與推薦，提供真正智能的功能發現機制。
" 超級 App+ 小程式 "，是一種極致的松散耦合技術架構。在這一松散耦合的架構之下，銀行及其分支機構可以各自負責各自的業務的獨立小程式化，各自有各自的預算和 IT 團隊，完成各自的小程式後再申請上架。小程式化的業務功能的審核發布，可通過平台上可以實現合規、風控、法務、安全等一整套智能工具輔助的半自動化檢測流程，取代傳統離線、低效且漏洞百出的 OA、郵件手工審批。
也正是在這一邏輯之下，微信才得以支持數百萬個團隊同時在做數百萬個獨立的小程式。
從這個角度來看，過去的 IT 開發模式是 " 計劃經濟模式 "，需要預先統籌規劃、排優先級、分配資源，但是計劃一定更沒有變化快，業務部門的因應市場需要而獨立自主的數字創新權限被剝奪，但 IT 卻永遠無法及時響應業務需求。而松散耦合架構可以類比成 " 市場經濟模式 "，企業 IT 摒棄 " 大一統 " 思維，只關注建安全可監測的平台以及定規則定标準。搭建平台之後，你們想唱什麼戲可以随時上來。這是一個重大的思維改變。
其次，這一模式還打破了企業 IT 的邊界。過去 IT 應用開發幾乎肯定來源于公司内部或者授權的外包機構。但是如果現在企業類比成一個應用商店，應用軟體的來源不再限于内部，IT 開發可以進行全社會資源的調度。這一套基于小程式建立的數字化底座可以化整為零，重塑 ERP、CRM 等企業軟體。
超級 APP 解決 Complexproblem，AI 解決 Complicated problem
钛媒體：這個邏輯很好，創業往往是從發現一個需求開始的。但這個需求可能不是剛需，需要不斷迭代才能貼近用户需求。小程式是最近大家談論的熱點，它使得開發成本急劇下降。任何一個生态中，開發成本的急劇下降都會帶來特别大的變化。AI 技術實際上也帶來了整個開發成本的下降。按照這一邏輯，你覺得未來的開發形态會如何變化？
梁啓鴻：超級 App+ 小程式，它首先體現了計算機科學裏的分治算法精神，将一個復雜的社會問題拆抽成很多小問題。另外，它還降低了個體單元的開發成本。現在，小程式的開發成本已經比 APP 低很多了。小程式和低代碼結合也非常自然寫完即扔——有用扔進生產、無用扔進垃圾桶，快速低成本試錯。
同時，針對小程式的具體場景，是可以結合 AI 代碼生成的能力的。但是目前這一方面的工具不是很成熟。
钛媒體：歷次技術變革對于架構的選擇特别重要，從大機、到分布式、到雲，到現在讨論的松耦合架構。其間還出現過 SOA 各類架構，也在致力于推動實現資源的復用和可裝卸。目前來看，小程式似乎正在接近這一初衷，你怎麼看？同時，小程式和超級 APP 之間其實是一個辯證關系，這兩者之間會如何迭代和發展？
梁啓鴻：關于超級 APP，我認為它解決的是 complex problem，而 AI 解決的是 complicated problem；後者的特點是有算法可依、有規則可循或相對可預測性，且往往需要進行大量的數據處理和計算，complex problem 的典型例子是金融業務，例如開放銀行需要處理來自不同金融機構和服務提供商的數據，同時還要考慮到數據安全、用户隐私保護、技術兼容性等問題。财富管理則需要考慮到市場風險、客户的投資偏好、税務規劃等復雜因素。這些業務的特點是它們都是動态的、有高度不确定性的，并且涉及到大量的人為決策和行為。這類問題适合通過超級 App 進行社會化協作來解決，将整個問題拆抽成獨立的單元，共同求解。
我認為超級 APP 和小程式之間可能是一個雞和蛋的問題。超級 APP 内部可以包括非常復雜的内容，但如果其外延是不開放的，比如一個銀行 App 裏面通常有數以百計的功能，但是沒有第三方社會力量的參與，是很難真正定義為超級 App。
數據和代碼不要對立，要結合
钛媒體：你很多客户都在金融行業，現在部署小程式這樣的架構，與機構原來的數字化系統之間的迭代關系是怎樣的？
梁啓鴻：我們當前的客户主要集中在金融和政務領網域。政府部門有很多部門，每個部門都要提供便民服務，銀行也是如此，很多業務有一定的交叉銷售關系，但業務性質聯系不是那麼緊密。
對此，我們的業務邏輯是非入侵性的。這一邏輯與部分競品的業務邏輯差别很大，他們往往有一個 " 最佳實踐 " 在前，客户需要從頭到尾依照其方案落地，但這對于銀行機構和政府部門來説是很難接受的。我們的做法是在客户原有的基礎之上做 " 加法 "，我們只需要在原來的 App 中增加小組件，同時在雲端部署應用商店。對于客户現有的系統集成和架構只是補充完善，并非徹底颠覆。
钛媒體：之前有過一個非常好的概念 " 富媒體 "，原來這一概念主要指的是具有動畫、聲音、視頻和互動性信息的豐富的媒體形式。未來随着數字化的發展，我認為将會出現 " 富數據 "，是一種帶代碼的數據，它具備你剛才提到的可搜索性和可分享性，和原來的數據概念完全不同。
梁啓鴻：傳統企業觀念下，似乎有數據就能獲得所謂智能，但實際上智能在代碼裏。在馮諾依曼架構下，存儲與計算是分離的，将數據和代碼分開處理，未來是否會實現 " 存算訓一體化 "。事實上，究竟是把數據放到運算能力中，還是運算能力放入數據存儲中這一話題也讨論了很久。
現在的思路是把數據和代碼放在一起，打開即具備一定程度的智能。Adobe 在十幾年前推出的 Flash 在一定程度上講就是當年的小程式，它的開發環境直到今天還是領先的。但是它的弊端在于他是在互聯網的開放标準之外并行的，兩者不能融合。實際上，小程式也可以理解為一個和 Flash 一樣的通用的壓縮包，只不過小程式更加開放，内部只是 HTML5。
最近看到一個 AI 領網域的訪談，也提到大語言模型的出現，對馮諾依曼架構的颠覆，他并不是最看好英偉達，覺得還是馮諾依曼架構的延續，在 " 存算訓一體化 " 的新架構上走的不堅定，但同時指出，最終這種架構的成功也可能給世界帶來新的風險。
小程式與出海
钛媒體：數據資產入表相關問題正在受到關注，現在考慮的還是單純的數據問題。剛才的讨論給我很大的啓發，當數據和算力、代碼相結合，封裝起來。這對于未來的數據交易、數據跨境的流通，是否也會帶來很大的挑戰？
梁啓鴻：以大灣區為例，政務服務、金融服務的融合應該在發生中吧。港澳與内地是既隔離又聯通，如果區網域之間采用一種通用的技術格式，就能在彼此内容與服務的交換上獲得很大的便利。例如北上的港澳居民需要用到内地的政務服務、金融服務時，只要使用港澳的超級 App，這個 App 引入了内地的小程式給港澳用户一站式便利，同時用户行為數據依然留存在港澳的超級 App 平台上。反之，内地訪客出入港澳，涉及一些市政服務、金融服務，同樣有可能在内地主流超級 App 上打開港澳本地的小程式獲得服務。彼此都不需要再去臨時性的下載一個當地的 App。用户在平台上數據的歸屬權，都在各自的管轄地。
钛媒體：跨境小程式，未來法規方面是否會遇到障礙？
梁啓鴻：現在我們在講出海市場，第一關注點是技術标準化。第二個問題是缺乏内容。例如我們接觸到東南亞以及南美的客户，他們近年來已經比較理解和認可超級 App 的概念，也有較強的模仿意願，我們可以輕易就給他們搭建一整套超級 App 平台，但問題是缺乏内容。所以我們需要幫助他們建立開發者生态，并引入存量内容。我們還可以幫助他處理外包業務，嘗試建立起一些行業标準。
钛媒體：如何解決海外小程式的運營能力？
梁啓鴻：目前行業内也有部分企業在海外成立或培養一些 " 超級 APP 數字化咨詢公司 "，但是與中國相比，整體海外市場的運營能力非常薄弱，差距在 5 年以上。在海外不僅幫助他們建平台還需要 " 扶上馬，送 N 程 "。
我了解所謂數字化轉型對于很多企業來説就是講的頂層設計，但實際上我們覺得數字化轉型其實需要解決的是經濟規模效應（economyofscale）問題。當我們的企業 IT 能做到讓業務應用場景的開發成本非常低、發布成本非常低而敏捷程度非常高的時候，業務場景的數字化變的非常便利非常可行，線上場景越來越豐富、迭代更新越來越頻繁，實現了規模效應，當員工或者客户所需要的一切事情都在 App 裏可以完成，幾乎可以 " 活在 App 裏面 " 而無需離線的時候，可以説 " 數字化轉型 " 就成功了。就是一個量變到質變的過程。
钛媒體：這一邏輯之下，其實原來的 IT 部門會受到非常大的衝擊和挑戰，意味着他們需要讓渡很多權力和利益。
梁啓鴻：我們認為 IT 部門應該扮演平台的角色。 IT 不再是開發測試、招标采購、運行運維的職能，而應該是建平台、定标準定規則、控制業務數字化應用的準入、做安全監測、為 " 安全開放 " 保駕護航。
對于大型企業，我認為這一衝擊其實也已經開始了。以前的做法是先從一個部門開始，通過調整組織架構進行嘗試。現在的方法是雙向而行，不幹預組織架構調整，但有了技術平台後，各個部門一定需要去擁抱它。這樣的平台将成為具有運營色彩的部門，扮演 " 招商引資 " 的角色——招募外部商業合作夥伴、引進數字服務資產。
一方面，這個部門需要招徕内容将其上架到平台；另一方面，這個部門需要将這些内容投放給消費者，提高他們的參與度，以此吸引更多的用户來接觸我們的客户。
在這一過程中，原來 IT 部門的一部分也許會成為平台運維，另一部分則靠攏平台運營。 如果平台是負責數字業務内容的審核上架與分發的發行商的話，那麼各條業務線也就是具體數字業務内容的 " 業主 " 部門則是這些内容的 " 出版商 "。
大語言模型的價值
钛媒體：小程式對傳統的企業軟體帶來怎樣的衝擊？
梁啓鴻：其實不能説衝擊，只是在分治算法精神下的重新安排，借 " 超級 App+ 小程式 " 這種極致松散耦合的技術架構，解決企業部分老大難問題。但化整為零的代價是高度碎片化，碎片的管理、索引和發現機制，過去是挺難做好的，多少大型的金融機構都沒有能力把它 App 裏的功能智能便利的讓消費者用户去訪問使用，導致很多 IT 辛苦做的功能埋藏在 App 深處無人知曉，另一方面用户又投訴 App 難用、功能找不到。但大語言模型 +RAG 的技術出現，應該能讓發現機制得以非常容易的實現。
現在我們将小程式和服務場景包裝在一個個的标準單元之中，每個單元都可以用一個復雜的上下文來描述，這些上下文在過去只是一個個的标籤，現在可以轉化成非常豐富的文本，這些數據都可以放入矢量數據庫之中，并與大語言模型相匹配。
我們并沒有發明什麼新技術，但是通過這一套流程模式的轉變，就解決了過去難以解決的搜索功能弱、推薦功能弱的問題。有了分治的架構、有了服務單元，對這些服務單元進行索引，結合更智能的人機互動方式，用户體驗就得到很大的提升。
钛媒體：這一點我很認同，原來編程的過程中，超過六七成的代碼都在編 UI，努力讓 UI 編的更加好看，努力設計更好的菜單系統，但是真正核心的功能不多。但現在通過大語言模型，可以幾句話就能迅速定位位置。流程的復雜性正好可以通過智能化來解決。未來整個的工作流程可能都會發生重大變化，可能會更加貼近交流習慣。
梁啓鴻：是的，同時大語言模型在描述用户畫像方面也有巨大的幫助，過去只能收集到結構性數據，再基于這些結構性數據做分析，而現在收集到用户每一次的提示詞，與光靠點擊數據相比，信息豐富很多。
小程式的未來空間
钛媒體：你們公司的業務側重點是什麼，小程式以及整套框架還有什麼提升空間？
梁啓鴻：小程式主要依賴幾方面：一是安全沙箱，因為所有代碼都是網上下載的，原則上是不可信的，所以要把小程式的代碼加載到一個安全沙箱之中，與其他小程式相隔離；二是性能問題；三是應用商店，這個應用商店放在雲端，店面并不一定需要 UI，本身是一個搜索引擎或者是智能推薦引擎，把用户需要的小程式推薦給用户；四是解決挂設備的問題，比如新能源車、智能電視機頂盒等。
钛媒體：小程式作為工具，它對于銀行機構的有效性如何？能否結合一些合作案例來聊一聊？
梁啓鴻：我們主要是為銀行提供一個開放環境，并嘗試建立起生态。比如銀行區網域周邊的商家，可以将小程式放到銀行 App 中，用户在商家消費時，可以使用小程式，商家可以通過小程式提供額外的打折優惠。在這一方面，銀行的目标是激活其 App 的日活數據。
另外，銀行的目标也不只是在商業方面。比如銀行可以月甚至周為部門，持續上架累積數以百計以灰度發布、風險可控的場景，相當于幾百個功能點。在當前的開放和松耦合的架構下，才有可能實現，僅靠 App 是不可能實現的。
钛媒體：現在銀行 APP 流量瓶頸非常明顯。
梁啓鴻：這也是一個 " 蛋雞困局 "。有些銀行想通過引進生态（包括衣食住行和周邊服務）來吸引本地客户，繼而提升 DAU。銀行自營 App 出于各種原因在一段時間内還是必要的，但沒有場景也就沒有 DAU，也沒有數據，在動辄稱 " 智能 " 的當下，智能能力也有限。我們的客户成功團隊也嘗試協助銀行客户建立數字生态、承載商業合作夥伴、發掘存量小程式内容，從而豐富他們的場景。通過自營的 " 網銀超級 App+ 小程式 " 平台，實現 " 走出去、引進來 "，也許是另一種較為務實的開放銀行策略嘗試。（本文首發于钛媒體 APP）
