生态一度激发了大家对 这个历史上用户增长曲线最陡峭产品的想象力。2 个月以来， 也有不少功能的更新、新插件的引入和使用规模的放开。在这里总结下当下 拥有的一些能力，看看最近的更新是否符合预期。
截止 23 年 5 月底， 插件商店中提供了 85 个插件，其按照能力大致可以分为 6 类：
1. 外部交互：这类插件提供了与外部的网页和产品进行交互的能力。
其中 是 官方推出的插件，思路与其在 21 年底的论文 一脉相承：使用语言模型去探索和理解外部网络上的内容。在多个用户访谈中提到，如果有明确目标的情况下，其浏览和总结能力比 New Bing 来得更好，但弊端是稳定性相对差些。
而外部工具中最好用的是 ，Zapier 作为聚合器中的领先者，本身的能力是和外部 5000 余个应用的 api 去做交互，有了很完备的 api 交互逻辑。而由于 input 的限制（容纳不下数十上百个 api 的 说明文档）和 在产品工程侧重心的差异，短期之内 生态的聚合能力是比较薄弱的一项。因此 在中短期是受益于 这个大脑的文本理解能力的。
2. 编程开发：提供开发环境，或编程开发的生产力工具。
受到最多关注的是 官方开发的 Code 。它提供了一个开发的沙盒环境，在环境中可以对用户想要执行的代码和分析的数据进行各类实验。 在 安全方面做了很多工作，来确保在这个环境中执行的代码实验会被安全地隔离在环境中，不直接地对外部网络环境造成改变和影响。由于这一特性，大家对 Code 的使用就集中在 另一个不需要部署上线的特长上——数据分析。Code 能对数据做总结和加工，并根据指令产出言之有物的数据可视化，这一点隐隐有着超越传统 BI 的希望，只是在可控性上还需继续加强。
3. 个性化交互：为 带来记忆和个性化的能力。
之前在 的研究中提到过， 插件被 Greg 认为是所有插件中最独特的，因为它补足了 原本没有的从个性化记忆和专有数据中做 的能力。插件的结构很简单，从各类 DB 的 api 中取出与 语义接近的内容交给 进行理解和学习。此外，DAN 也是这类中一个比较有趣的插件，其提供了为 改变个性的能力。
4. 生活助手：衣食住行的信息整合。
这一品类是大公司涌入最多的，如 、Kayak 是旅行机酒预定， 是预约餐厅， 是购买生鲜的领先平台。这类产品希望通过 对自然语言的理解能力，抓住这个新平台作为增量流量入口。一方面， 将这一功能全量的进度相对比较克制和保守，并没有发挥比较明显的引流作用；但另一方面，Chat 这一交互形式筛选下来的用户质量是比传统获客渠道来得更高的。
5. 垂直领域：获得专有数据的窗口。
有许多垂直领域高质量的数据并不是 核心的技能点，因此垂直领域的插件能为其带来更专业、专有的内容。例如 Vogue 有时尚领域的数据， 有 web3 领域的公开数据，UN 有联合国每年政策变化的相关文本。这些都是在垂直领域做理解和生成时重要的信息。
6. 办公效率：生产力工具。
这类插件大多是办公效率小工具的集合，例如 PDF 阅读总结、待办事项记录、发邮件、文字转语音是目前主要的插件能力。
以上介绍了当前 的具体能力，会发现其在很多领域对不同垂直领域有所影响，有些可能会对大公司的现有产品形态造成一定冲击，有些则是独立开发者积累早期高质量用户的好机会。接下来就分别对这些领域的影响进行梳理。
1：搜索
案例：, Bing,
集成了 功能在短期之内会对搜索引擎的能力有一定的冲击。因为 LLM 很大程度上就是将互联网上的公开信息学习了一遍，结合了 能力后，本身又继承了一定的内容整合和推理能力，因此使用 的用户在短期会显著减少使用搜索的频率。
但谷歌的反应也是比较迅速的，已经在内部开放了集成 LLM 的搜索引擎。以谷歌的 infra 实力和对搜索引擎的深入理解，完全有可能能在 搜索引擎中做出比 New Bing 和 更好的 AI 搜索引擎。但无论是哪个公司获胜，大家对搜索的认知在长期一定会被 LLM 部分颠覆，传统的索引排序式的 query 心智会渐渐被生成式的 心智侵蚀。
2：聚合器
案例：
LLM 时代的跨应用调度和交互需求会显著增长，因此尽管目前聚合器的使用频率相对低频，我们还是给到了中等频次的评价。
当前 有了很强的工具使用能力，但缺少在 api 聚合方面的 ，因此 的出现在中短期之内利好 这类聚合器产品。 在此领域积累很深，现在如果大家想在 上做一些复杂操作的时候：比如将文本总结之后发社交媒体，或是记录在 中，大家都会选择用 + 的方式来实现。在很多 use case 中， 只需要接入聚合器，就能做到非常好的用户体验，它也不需要接入大量 api，相当于类似 SEO 的部分由聚合器完全提供了。
但长期上，这类产品面临以下冲击：一方面， api 的组织形式可能会发生变化，LLM 时代可能跨产品交互的频次和。 最近发布了函数调用能力，使 api 的可用性显著提升，这些变化可能会弱化 的护城河。另一方面，聚合器可能会成为操作系统机会中的一部分，微软、谷歌和苹果都可能基于自己的系统去建立相应的能力，竞争激烈。
3：线上预订平台
案例：, Kayak
这类平台主要提供的能力是对平台上信息的组织和履约能力。组织指的是更了解用户，帮助其高效地预约到合适的机酒；履约指的是保障交易的安全性和流畅性，避免违约的风险。
随着 的推出，短期之内这类平台可能会增加一个高质量获客的渠道，但是长期是很可能受到比较大冲击的。因为 Chat 带来的语义理解能力提高，提供了一个更好的信息组织方式，用户能高效的给出需求，找到合适的航班信息，平台留下的主要壁垒是其交易的履约价值，这部分的价值比原来薄了很多。
4：O2O/电商平台
案例：
O2O / 电商类型的平台与线上预定平台相比，多了线下的供应链组织能力。这一部分能力是不会受到 LLM 领域冲击的，其中的 AI 算法也基本是优化方向的传统 ML 算法，并不是 LLM 擅长处理和调度的任务类型。因此，这类平台受到的影响相对较小，更多是多了一个高质量的获客渠道。
5：独立开发者&创业者
案例：
对于创业者来说，找到 PMF 和早期高质量用户是一个有难度的事情，而加入 是一条比较快速的捷径。Chat 形式带来的用户，比传统投放渠道获得的用户质量会高不少，因为都是经过门槛比较高的交互后留存的，转化率会更高一些。而且接入的产品可以拿到用户完整的对话 ，这对理解消费者的用户画像也是相当关键的。
03： 的开发方式和能力边界
开发门槛并不高
提供了一套 接入范式，供企业和个人开发者根据指南进行接入。低门槛的接入方式是经过 官方设计的。用 Greg 的话说，就是为一个语言模型写 api 的文档：
接入的开发门槛很低，只需要写两个核心组件：
1. api 接口，其中包含多个函数，负责定义不同场景下数据的输入和输出。以后文将展开的 Speak 产品为例，需要执行翻译任务时将调用 接口，需要解释具体表达时使用 接口。而具体接口的逻辑选择就要用到第二个组件了；
2. 说明文件，通过自然语言 教会产品调用 api。这个文件的核心是一段自然语言介绍，帮助机器理解这个插件本身的能力。当用户开启某些插件时， 会理解 中需要的能力是否与插件 文件中的描述匹配，进而判断何时调用 api ，以及使用哪个接口能最准确的实现目标。
例如 Speak 这款多语言翻译和学习的产品插件中，其 插件的文本内容被破解出来，大致内容如下：
• 当用户问到一个其他语言中的内容时，call Speak 插件来响应用户的语言学习意图；
• 当用户提供了一个明确的短语或句子需要翻译时，调用 接口；
• 当用户给了一个比较模糊的任务，比如“如何用西班牙语称赞别人的穿着”时，调用 接口；
• 当用户给一个表达需要详细的解释，比如“ 在法语中代表什么时，调用 接口。
这个文档的写作风格目前比较接近开发过程中的文档和注释。但未来当更多 api 接入之后，肯定会有文档风格的差异，因为未来产品需要在其他同品类产品中脱颖而出，产品文档会以接近 SEO 的思路体现出自己产品的差异化优势，做文档和 api 的优化。
提供一套安全评估能力
随着 的开发和使用量增大， 的安全问题会逐渐成为一个重要的因素。一方面， 提供方是否有过度使用用户的数据；另一方面， 是否会为了流量提高自己活跃的优先级。
在 2017 年，Adobe 曾经因为在用户的 插件中加入了静默安装和访问网站权限陷入了争论。插件中包含了这样的能力：能把用户打开的每一个网页转成 PDF，因此要求用户给插件开放读取和修改网页的能力，引起了诸多用户的不满。
安全和权限是产品可用性的一个重要组成部分，Adobe 和 在那次争议中都有一定的问题。Adobe 的产品很可能不会过度 track 用户的访问历史，但还是应该基于用户对这一功能的需求不那么激进的推进； 在权限管理时，当时没有把读取和修改网页内容的权限分级拆分出来，导致用户担心插件会在生成时修改内容。
而 的安全评估方式十分新颖：利用 LLM 的理解和角色扮演能力，让其成为 的安全审查员。根据推特上研究 和 的用户 rez0 破解得到的信息，给 AI 审核员的信息主要分为三个板块：指令、事实和政策。
指令部分主要是对 AI 角色的定义：扮演一个在 工作的产品安全工程师，分析一个包含两个文件的第三方 是否符合要求（包含了 6个基本的安全问题，如是否获取个人信息，是否有参与不正当活动的能力等），并基于以上问题为插件的安全程度和适合年龄段进行打分。
而事实和政策部分，则为 AI 审查员的决策提供了依据，政策部分明确了政治、色情的明令禁止的内容；事实部分明确了风险等级划分：
1. 低风险插件只使用公开数据，不涉及任何个人信息；
2. 中风险插件包含了个人或企业与第三方的交互；
3. 高风险插件使用了高风险数据（金融数据、医疗数据、其他用户隐私敏感信息），或可能有欺诈行为的风险。
未来会走向更复杂的系统
当下的 还有诸多不成熟的方面：
1. 模型能同时调用的 数量很有限：
目前的 只支持开启三个 ， 在 中读入这几个的说明文件。由于 32k 的 input 限制，5-10 个 的描述可能就是短时间内模型能读入的上限了。
2. 目前接入 的 api 设计方式大多还比较传统：
收到 之后，将其根据 加工理解写好给传统 api 的输入。这个优点是开发者可以很高效的把之前开发的 api 复用上，缺点是对开发者而言自由度不够高。
因此未来的 api 形式会有变化，输入数据不再是传输处理后的结构化数据，而是直接把 传给开发者，开发者将对 的理解和使用写进 api 中。
3. 当前给模型的描述文档，尚需要不断地根据竞品情况和模型的理解情况进行调整：
例如，当一个垂直领域中加入一个新的竞争者时，如果竞争者有着更细粒度、更垂直的专注方向，大模型会将其专注方向的所有机会都交给竞争者。
针对以上提到的这些问题，需要一个更复杂的插件召回 系统来进行。这个系统可能包含有几层：
• Store：提供了一个统一的文档规定，来管理数以万计的 ，经过审核后允许 api 开发者进行注册，更新和删除。进入 Store 的时候，应加入关于这一 的具体标签（就像 App Store 中的分类和信息），用于之后的召回和使用；
• ：负责根据用户需要的行为，召回推荐最相关的 5-10 个 api。召回过程中， 将 的信息与 store 中的标签和描述进行匹配，找到最相关的 ；
• ：负责调用 api 执行生成的动作代码，调用 api，返回最终执行结果（这里还有一步潜在的排序，模型选择 api 的过程类似于推荐系统中的精排）。
04： 的 App Store 野望
“App Store”不是新鲜事
由于过高的势能， 推出 被视作 推出其 App Store 的时刻。我们认为客观来看，拥有一个应用和插件生态并不代表一个开放平台必然走向成功。从 SaaS 巨头的历史来看，到达了一定体量的公司都必然选择建设 ISV 生态，通过“开放平台 + ISV”避免定制化需求开发，并且通过抽成捕获价值。能否将这样一个平台建设成功是通往千亿美元级别平台的重要试金石。
在美国的过去十年很少有下一个重量级生态在消费者侧被建立 —— Meta 也没做成微信小程序式的应用分发生态。但是一旦在消费者侧做成 App Store 级的生态，意味着：
• 比 SaaS 平台高 1-2 个数量级的生态价值；
• 比 SaaS 平台高高 2-3 个数量级的生态应用数量；
• 比 SaaS 平台高一倍的 Take Rate。
一个冷知识是 Apple 的应用商店并不是第一个“App Store”，但这个概念的起源的确是 Steve Jobs：
的创始人 2000 年左右对公司发展方向比较困惑，找 Jobs 聊了下，对方给出了 3 个建议：
1. 24 个月内增长 10 倍，不然没戏；
2. 拿下一个大客户，比如雅芳；
3. 必须建立一个 App 。
立马付诸行动，发现自己的产品形态上更像 而不是 Store，最终在 2005 年推出了 。 之前听 Jobs 建议买了 App Store 商标和 .com URL，在 2008 年送给了 Apple。
从一个框架和五个案例推演 生态的胜负手
一个框架
抛开“App Store”的视角，聚焦到开放平台之上的插件生态建设，我们认为 Figma 给出了一个最好的框架，来用于分析一个生态的成功潜力：
• 安全性：包括用户的数据隐私、权限管理以及 ISV 和平台之间的权限和能力边界；
• 稳定性：平台的速度不应该被 拖慢，平台的更新不应该影响现有的 ，平台还应该提供在多个设备内统一的 安装管理；
• 低门槛开发：平台定义的框架和语言应该足够在满足其他前提下足够低门槛以让开发者很快上手贡献一个强劲的 生态；
• 性能： 本身应该是足够快和稳定的。
除了这套框架本身的普适性之外，我们还比较吃惊于 和 Figma 的惊人相似性 —— 他们的 生态是完全云化、Web 端为主、基于强劲的开放平台并且嵌入到主产品内的。同时，我们认为这套框架缺乏包含的部分是对于开发者的激励以及在 数量膨胀后的分发机制
五个案例
我们将这套框架用于评估 5 个被视作取得了巨大成功的开放平台生态上，通过这种多案例研究的方法来得出一些对 的前景和坑的指导性判断：
除了众所周知的一些成功之处外，Apple 在激励、分发、低门槛开发上的经验教训对于今天的 非常有参考意义：
• Apple 成功在 OS 之上建立起了用户的账户体系和自己端到端建设的全球支付网络 —— Apple 在 2008 年推出 App Store 时只支持终生买断制付费，在 2009 年引入了 In App ，2010 年引入了 In App ，给了开发者完整的激励能力。而 在账户体系及支付的建设还非常早期，不过跟 的战略合作可能是一个好兆头；
• App Store 在十几年发展后表现出了明显的分发问题，马太效应问题明显，大规模的 App 难以被分发和充分匹配。在经历过个性化推荐的 、LBS 分发的 Near Me 和激励发现的 之后，Apple 最终没有发现更智能的匹配逻辑，回归到了保留至今天的 和 风格。 对于 的分发可能有新的破局之道，用更智能和非用户主动选取的方式可以承载更大量级的匹配；
• App 的开发门槛相当高，不过 Apple 从 2010 年 iPad 发布开始，会提前给开发者留出时间，让他们根据新设备和 OS 的特性开发应用。这样当用户购买时，他们会现在有丰富的新应用可供选择。 在 GPT-4 和 发布上已经是这种风格了，但是对于双边怎么放量显然还缺少经验。
是一个被许多人忽视的成功，里面包含了很多基本功建设，非常值得观察 后续能不能继续围绕这些方面优化用户体验： 给开发者的前端框架从自己的 演化为了 Web ，后端则从基本的 SDK、api 和 框架开始，发展出事件驱动的 Pub Sub api 架构，最后外部集成始于 VS Code 等 IDE 集成的优化，发展到 Flow 完善的集成方案。
上起来的应用大部分在早期关注 SME 和 。如果要搞大客户，应用可以自己锚定 3-5 个名字，然后找 的销售渠道帮忙介绍，随后开启独立的销售流程。如果 未来需要打造草根崛起的 ，这会是个还不错的范式。
大部分的中国创业者和投资人相当沉迷于“移动互联网”，反而一度忽视了 上长出的机会，除了我们写过的 和 Loom 外，第一个验证了 生态的巨大成功是 Honey。这个电商优惠券聚合插件以 40 亿美元现金卖给了 。
的生态可以引发对 的一点思考：不同于 App Store 在手机上的地位， 一直仅仅被视作 Web 上的多个渠道之一，和官网、App、社交媒体账号并行，直到 19 年之后才有越来越多的公司将它作为主要的获客渠道。如果让 的心智成为 KAYAK、、 的“获客副阵地“，它可能会陷入类似的尴尬处境。不过根据开发者的反馈，虽然在发布时引入了大量合作伙伴，实际运行的 生态更偏向新的、独立开发的、草根创业的 。
Figma 通过技术手段很好地完成了安全性、稳定性和性能的平衡，同时揭示了“低门槛”对于双边的重要性：Adobe XD 和 都拥有历史更悠久的插件生态，但是用户往往需要在社区之外发现并下载安装，而开发者则需要通过类似 C 等语言编写其插件，而 Figma 则提供了设计师更熟悉的 等语言在框架内进行开发，并且打造了跟主产品无缝的体验。
Store 也是个好的案例，用出色的插件生态（各种 插件/自动补全） 在开发体验上超越了像 IDEA 、 那样由经营者内部优化的产品。在 的设计中，他们把 IDE 涉及得可扩展性极强，能够让开发者很轻松地为自己开发设计好用的插件，并把插件开放给社区一起使用和优化。
回顾
05： 干掉 ？
紧随“App Store”论调之后的一类观点是 抹杀掉了 、Fixie AI 甚至是 Adept 的价值主张，这是相当程度上高估了 的说法。
仅仅看 这一个战略，它对 目前的直接影响：
1. 商业化方面可能会受到一定挤压，因为顺着这个开源项目本身的话， 几乎唯一的商业化方向是做 ；
2. 跟 完全不是竞争关系：
• 这个开源项目在 推出 2 天后就持续了在 抽象下的 实现；
• 将 Chain 和 Agent 跟 和 QA 逻辑做了解耦，从而更好地支持未来类似 类似的 以外的 。
从开发者反馈来看，也有相当多不同的声音：
没有之前费劲学习过 抽象、希望实现模型间可组合性独立开发者构建 的方式基本是通过 来方便地调用其他开源模型能力并通过 托管这个 。下面这个 就很好地组合了 、 和 的能力：
抛开 ， 在 6 月最新推出的函数调用对于 和 Fixie 的影响倒更大一些。
06： 的路线图与连锁反应
从增量的视角看，按照有短期到长期来排序，我们思考了 能带来的一些变化：
1. 微软在 AI 的生态进一步增强
缺审核，缺产品经理，缺运营这个生态的专家，缺更好的、比聊天界面搭配小组件更广泛的 UI。这些微软都有 —— 大量可以投入的人员，广泛可供 嵌入并发挥作用的一系列产品（消费者端的 Bing Chat 和 11 ，企业端的 365 和 365 等）。
微软共享 已有的上百个 将极大促进它自己生态的冷启动，以让客户构造更多围绕内部私有数据的 。微软围绕这个叙事布局了完整的产品和服务：Azure AI 可以提供在企业私有数据和云上运行和测试 的能力，而 及 则可以被用于帮助企业更好地构建新 。
2. 针对模型调用的调用优化和新的 api 生态
尽管真的像 SEO 或者 ASO（应用商店优化）一样的广告生态还非常远， 的一些玩法已经出现了针对模型进行优化的雏形 —— 激烈的竞争发生在“ for Model”中，那些描述自己为“宠物电商”的 可以获取精准匹配，这些流量不会被分配给拥有更粗粒度描述的 ，而更精细的“专为美国用户打造的宠物电商”则可以抢走美国的相关流量，优化这个 已经成为 开发者之间非常有趣的角逐。
除了在 JSON file 上下功夫，专门为 优化自己的 api 是另一个路径。 在 6 月新推出的 Chat api 的 call 功能可以帮助开发者实现“无代码”的体验，原来传统的 api 有很大的为模型重构的空间。
3. 多模型之间的可组合性创造更多用例
类似我们在 05 末尾所展示的 例子， 为 LLM 与 LLM 之间、LLM 与外部知识和 api 之间、LLM 与不同其他模型之间提供了一个用户可以轻松使用的 UI。发挥类似的可组合性创意能够创造出来许多在 LLM 与 Model 不存在时难以出现的工作流和产品。
4. 需求倒逼 产品形态演进
这一点是显而易见的 —— 如果 对于 成为一个在消费者侧经久不衰的伟大产品仍然抱有愿景，并且搭建了一支合适的团队来实现这一点。目前来看，这非常可能成为现实，因为 刚刚招募了来自 、Uber 和 的产品老兵 Peter Deng 担任 VP of 。
5. 类 的硬件机会出现
外界对于 进军硬件有非常高的预期。 围绕着 的策略算是硬件跟软件生态配合的比较好的例子， 在 这个类别非常占据了统治级地位，诞生了 等公司，重要的原因是有 这个硬件让 生态被分发到了大量的师生用户。即使没有带来硬件交互上的爆炸性创新，能够通过硬件建立一个独特的用户分发渠道也可以帮助到整个 生态。
6. 模型内外部数据促进 AI Agent 的出现和演进
从开放平台的视角思考 的意义会得出比较有趣的结论，它是 对外开放的一个重要数据接口，让第三方数据和用户 Query 等数据能够互动起来，而微软与 Azure 似乎致力于促进更多的企业私有数据开始与模型互动，这会加速许多人已经拉满了预期的 AI 助理的诞生。
