为什么 AI 需要一次 Web 2.0 式的革命？副本|web|AI|twitter_新浪科技

摘要

大模型产品化需要更多「二次开发」，创造出 AI 应用的「UGC」。

大模型 AI 行业正在寻找 2.0 时代的入口。

因为 Web 2.0 的降临，就是上一轮互联网革命，最重要的爆发节点。行业在经历了千禧年的泡沫破裂后，很多人一度认为计算机对大多普通人「没有实用价值」。但随着 Web 2.0 革命，UGC、社交媒体开始出现，把所有人代入了「裂变传播」的时代，之后的智能手机、移动互联网革命，就建立在此之上。

自此之后，每一款互联网产品的成功，都与「参与性」息息相关，只有能调动用户的产品才是好产品。

但过去两年，大模型 AI 产品面临的，就是「参与」的难题。模型的性能越来越强，相关产品应用越来越多，但大多数普通用户，依然没有被调动起来。ChatGPT 完成了互联网历史上最快的冷启动，又最快遇到了增长的瓶颈，其他聊天机器人产的命运也大多类似。

很大程度上，今天的大模型 AI，需要一场类似 Web 2.0 的革命。通过降低技术门槛，拓宽开发生态，激发出有效的用户需求和产品供给。

11 月 28 日，扣子平台推出了今年最重要的更新，Project IDE。通过 UI Builder、应用模版，将 AI 应用的开发门槛进一步降低，且丰富了 AI 应用的交互范式，他们正在尝试将大模型 AI 应用开发代入「2.0 时代」。

为什么 AI 需要一次「2.0」更新？

要理解 AI 应用开发的 2.0 时代，我们需要先回到 20 年前。

2000 年以前，互联网还是一个类似电视和广播的「单向传播系统」。在 Web 1.0 时代，大部分人用电脑上网，基本只进行「浏览」，你可以阅读上面的新闻、文章，查询天气等信息。

这时的网页就像一张报纸，只不过设立一个页面的成本比发行报纸要低得多。所以很多人都可以建立自己的主页，整个互联网上网站的数量很多。

定义 Web 1.0 时代的应用是搜索引擎，因为整个互联网上有大量的网站，大家很难找到自己需要的信息，Google 通过关键词搜索和网页排序算法，建立了搜索引擎，人们就更容易找到自己想要的信息。

而今天的 AI 聊天机器人，它和搜索引擎在逻辑上有着很大的相似之处。它们的交互界面都是一个输入框，让用户输入关键词、提示词，AI 大模型生成内容的过程其实也就像一种「权重排序算法」，通过语言模型，把「权重最高」的词语提取出来，生成连贯的语句。

这里最大的问题在于，大部分用户，并没有自我挖掘需求的能力。在 Web 1.0 时代，他们可能并不知道自己想搜的是什么，在 AI 大模型的时代，他们又难以编写出完整严密的提示词。

所以 2000 年以后，第一轮互联网泡沫破裂，当时大部分互联网公司的用户和收入增长都不足预期，股价暴跌，包括雅虎在内的一大批互联网巨头都被时代重刷下去。

直到 2003 年后，MySpace、Facebook、Twitter 相继上线，Web 2.0 的时代到来了。

Web 2.0 让用户不再只是内容的消费者，而是成为了创造者，「社交媒体」的概念诞生，平台的内容量得到极大充实。与此同时，围绕各个社交媒体平台的「二次开发」也出现了，Web 2.0 时代的社交媒体，往往会开放很多产品接口，让开发者可以基于这些产品，二次开发出更多功能，满足用户不同的需求。

其中最典型的案例之一就是 Twitter。早期的 Twitter 只是一个短内容发布平台，但因为有着开放的第三方开发生态，Twitter 迅速成为了「独立开发者的游乐场」，各种第三方客户端、自动化 app 都被开发出来，使 Twitter 在早期竞争中，战胜了一大批对手。

2008 年，Twitter 的第三方客户端 Twitteriffic 成为了 App Store 前十热门应用

回到今天，大模型 AI 面临的状况其实与 Web 2.0 的前夜非常类似。当下大模型已经有了强大的生成能力，但大部分用户利用它的效率依然不高，很多基于大模型能力的产品应用已展现出强大的能力，比如针对视频的多模态实时字幕生成、并可以翻译，但这显然只是 AI 能做到事情的冰山一角。

特别是随着大模型训练效率的提升，同性能模型的运算成本已经在飞速下降，AI 产品化的展开面正在被拓宽。

为 AI 应用开发「搭一座桥」

今天，AI 产品开发的主力军是技术人员，其中有独立开发者。

造成这种情况的主要原因是，AI 产品的代码往往并不复杂，开发工作量不大，很多功能都是通过大模型的接口实现。但这个代码门槛依然存在，过去「产品经理 + 程序员」的开发模式反而不适用了。第一批 AI 创业者里，有很多都是自学代码，以实现从 0 到 1 的产品开发。

这种现状意味着，AI 开发社群里还有很多潜在力量，没有被调动起来。他们可能是产品经理、设计师，更懂产品需求、设计交互，但不一定有代码经验。如果能在大模型平台和他们之间搭一座桥，进一步降低 AI 产品的代码门槛，就能给 AI 产品开发带来更大势能。

这就是扣子过去一年花精力最多，致力于实现的事：帮助创业者以最快的速度实现从 0 到 1 的应用搭建和迭代。

扣子实现的最大改变，就是对「交互」的颠覆，通过 UI Builder，AI 产品的交互不再局限于对话，而是可以加入更多按钮、菜单、选项，来规范用户输入。

当然，对话式交互是大模型 AI 应用最重要的特点和优势，因为自然语言是人类最天然的表达方式。但在很多高频、标注化的场景里，对话不应是唯一的交互方式。

比如在一个行程规划的 AI 应用里，模型需要参考的目的地、旅行时间、人数、预算……如果只用对话式 UI，就需要多轮追问，用户体验反而不好。这里完全可以固定好一个模版，形成菜单、选项，供用户填写选择，通过这种方式避免 prompt 里的信息错漏。

同样的逻辑同样适用于写作助手应用，针对不同体裁的文章，可以直接提前进行功能划分，并提前在写作要求等要填写「提示信息」的地方填入范例，这样用户只需要基于范例修改，就可以输入更高质量的提示词。

提示词的输入效率和质量，正是目前 AI 产品面临的最大难题之一，大部分用户都很难编写出详尽完整的提示词。扣子通过在开发端加入 UI Builder，基于工作流的开发思路，将很多提示词的编写都拆分成产品功能，为 AI 产品铺好了台阶。

除此之外，扣子还在尝试解决 AI 产品的另一个难题，记忆。

目前大部分 AI 产品的用户数据库，往往都比较简陋，且有明显的「稀释」问题。用户在一个对话的前半段输入的信息，随着对话的不断进行，会迅速被稀释，AI 大模型会忘掉这些关键信息，最终偏离用户最初的意愿。

针对这个问题，扣子在工作流中加入了知识库写入、SQL 数据库查询的能力，用户输入的内容，不再只是模糊的 prompt，而是可以成为确切的数据，被写进应用。这里的数据可以是确切的时间、日期、行为，也可以是用户的特定想法，输入后这些数据就能够被反复调取，且不会被神经网络稀释。

比如之前一度很火的 App「胃之书」，用户可以通过拍照，让 AI 来记录每天的食谱，分析营养摄入。在加入了数据读写能力后，App 就可以将每天的食谱信息、营养，以数据的形式储存，之后进行多次调用。比如用户就可以知道自己每周、每个月的饮食健康程度，回顾自己「这个月吃了几次薯条」，「有多少天热量超标」。

大模型 AI 的一个特征，也是弱点，就在于它输出的内容的保质期太短了，需要转化为「数据」，才能为用户提供更长期的效用和价值。通过扣子的 UI Builder 和数据库能力，独立开发者可以将 AI 大模型与更多场景结合，比如「运动书」、「旅行书」、「星座命理书」，通过完整长效的前后端，形成长期的交互循环。

而这些，还只是当下扣子平台新功能的几个应用范例。这些新的开发功能，将为大模型 AI 应用开发「搭一座桥」，弥合模型和用户之间的距离，解锁更多 AI 应用的可能性。

AI 应用的未来需要「UGC」

Project IDE 的推出，不仅意味着扣子搭建起了一个更完整的 AI 应用开发平台，还降低了 AI 开发的门槛。

通过「AI 应用模版」和「工作流」，扣子已经能够实现近似「零代码」的 AI 应用开发。即便是没有代码能力的爱好者，也能够通过扣子可视化的工作流界面，将不同的 AI 功能组合在一起，还可以对功能模版进行修改。

扣子工作流的界面，有点像当年 iOS 的 Workflow 应用，或 IFTTT，它们分别是针对 iPhone 和线上互联网服务的自动化工具，通过图形化的界面，将不同的软件功能整合到一起，形成一个新的「程序」。