今天小编分享的互联网经验：对话凡泰极客梁启鸿：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）
