LLM-Native：AGI的另一种路径

《银河系漫游指南》的作者——道格拉斯·亚当斯曾经对「技术」一词做出这样一种解释：

「技术」是描述某种尚未发挥作用的东西的词汇。

这是一个充满实用主义的定义，这句话可以被更直观地表述为：当我们还在热烈讨论某种技术时，往往意味着该技术还未真正发挥作用。

事实上所有底层技术驱动的产业革命都将经历一个市场焦点从技术向应用转移的过程，而当这种转移开始发生时，才意味着该技术开始兑现其价值。

对于大语言模型技术（下文称：LLMs）来说，在经历了注定载入科技史册的技术狂飙后，虽然目前其技术进展依然占据绝大多数的市场关注度，但已有迹象表明我们正处于技术兑现价值的破晓：

5月：Character.ai web端月访问量超过2亿并拥有恐怖的平均使用时长——Killer App的产品形态初见端倪。
6月：OpenAI招聘了世界级产品经理Peter Deng来操刀未来的消费级产品（可能是个人助理）——头部玩家的战略变化。
7月：Inflection完成13亿美元融资，创始人Mustafa明确表示公司定位为应用公司而非AGI研究机构——以应用为目标的新公司开始建立。

所以在AGI到来前，一个与“如何实现AGI”同样值得我们兴奋的问题摆在了面前：

当信仰AI的先知们摆脱AGI执念，带领信徒到达技术的应许之地后，拔地而起的将是一座何等壮丽的全新城邦。

这个问题的可能答案指向LLM-Native产品：一种建立在LLMs技术特点和思维方式上的全新产品范式。

事实上，LLM-Native产品并不意味着与AGI技术分道扬镳，而更像是某种形式的殊途同归，也许当我们暂时忘记AGI而转向扩大LLMs技术的使用范围以及创造全新产品时，这反而会成为另一种实现AGI的路径，就如同现在LLMs技术得以发展是建立在互联网数十年产品化积累的海量数据一样。

下面我们将对LLM-Native产品的底层逻辑、特点、以及如何创建等问题展开讨论。

产品视角下的LLMs技术

在开始讨论LLM-Native产品之前，我们需要对LLMs技术的特点进行分析，这里的分析将从产品视角进行，更具体来说，我们将从产品开发者和产品使用者两种视角来观察LLMs技术。

产品开发者视角

模型即应用

从产品形态角度来看，LLMs相关的模型接收的输入是用户的自然语言，输出是最终可用信息或者任务执行结果（不需要开发者或者用户继续处理），所有中间处理所需的能力（如，任务拆解、信息生成、工具调用）都被封装在了模型中，所以对于LLMs来说，模型本身就是一个应用。

需求即功能

从功能设计角度来看，由于「涌现」的存在，LLMs所具备的能力是一个开放域，其能够解决何种问题同时取决于模型能力如何被设计以及用户如何去使用（即描述需求），也就是说LLMs会根据其对用户需求（意图）的理解自动形成对应的能力，这种能力的呈现形式不仅仅是我们所熟知的文本或者图像回应，也可以是一个交互界面或者是一个行动。

语言即代码

从产品开发角度来看，由于LLMs使用自然语言作为输入并对其进行回应，用户的文本描述将部分替代开发代码，由用户自己实现其需要的功能，另一方面也带来了LLMs产品天然的UGC属性。

Mr.-Ranedeer-AI-Tutor：用400+行prompt实现教学机器人

产品使用者视角

实时性

从信息时效性来看，由于LLMs的输出是对用户所描述需求的回应，所以用户从LLMs产品中每次获取的信息都是实时生成的，而非对已经存在的信息按照某种规则进行分发。

自主性

从使用过程来看，由于LLMs具备对用户需求进行任务拆解、目标规划、自动执行的能力，所以一个任务的完成过程并非完全由用户控制，LLMs产品在其中具有很强的自主性，任务将由用户和LLMs协作完成，这个特点已经在Agent类产品中出现。

Agent具备显著的自主性：规划、行动、使用工具

不确定性

从获取的信息质量来看，由于LLMs采用自回归方式生成，并且面向开放性任务的目标设计，其生成结果存在较强的不确定性，即用户很难精确、稳定、可控的获取其想要的内容或者结果。

我们当然还能总结出LLMs技术的其他特点，但由于本文的目标，这里主要关注对LLM-Native有决定性影响的部分，在下文中我们将看到这些产品维度的特点将如何影响我们对LLM-Native产品的设计与决策。

Welcome to Hogwarts

LLMs技术的新特点必然会给产品工作带来变化，认识并接受这些变化的过程也许会像从麻瓜世界长大的巫师首次进入霍格沃兹——有趣、反常、但必要，下面我们将从用户、需求、产品、业务、市场等不同维度来介绍我们在开展LLM-Native产品工作时将要面临的变化，欢迎进入LLMs的产品新世界。

当用户=开发者

用户作为产品的开发者并不是一件新鲜事，由用户为产品开发插件、甚至优化产品功能“古已有之”，但是像LLMs产品这样，每个用户的每次使用都是在对产品进行「开发」的情况却是头一次出现。

由于上文提到的「语言即代码」和「需求即功能」特点，LLMs产品的每一个prompt，都会是一个对应特定功能、或者可复用插件，而当将Agent、UI生成等能力加入产品后，用户的开发能力将会得到更大提升。

生产力决定生产关系，在LLMs提供的强大生产力下，我们将迎来一个全民开发的时代，如果说互联网实现了信息自由，那么LLM-Native产品将实现开发自由。

FlowiseAI：通过简单的操作和prompt就能创建自己的应用

需求的无损传递与个性化满足

对于产品有这样一种表述：对用户需求抽象后的解决方案实现。那么从这个角度来看，产品功能其实是对用户需求的接收和翻译。

在实际产品工作中，无论是对需求的人为抽象还是对功能的人工设计，都无法实现用户需求的无损传递，而功能的标准化设计则注定其无法满足用户的个性化需求，那么不可避免的结果会是：

总有人不满意——功能设计的标准化与用户需求的个性化矛盾。
功能变复杂——为了更精确翻译更多的用户需求，不得不增加功能。
学习门槛增加——功能变多，以及单个功能与用户需求的匹配度降低。

在产品的生命周期中，这三者体现出相互叠加促进的关系，最终的结果是产品功能越来越复杂、新用户进入门槛高、老用户因体验下降流失，这个过程是很多产品在增长过程中无法逃脱的“用户规模马尔萨斯陷阱”。从搜索到推荐，算法一直在试图让产品增长脱离这个困境，即努力让功能内化在算法中从而实现用更少的产品复杂度来实现更多的功能，而这正是LLMs最为擅长的，具体来说：

对于LLM-Native产品，由于「模型即应用」、「需求即功能」的特点，我们可以实现：

需求通过自然语言描述输入模型——需求的高效传递。
需求对应的功能被实时生成——面向不同用户的个性化功能。

所以LLM-Native产品有很可能会打破产品设计的“用户规模马尔萨斯陷阱”，即用极简的产品设计在保持低使用门槛的前提下，个性化的满足复杂、海量的用户需求。

供给侧与消费侧改革

从经济角度来看，我们日常使用的绝大多数互联网产品都在围绕信息的生产、分配和消费进行设计，LLMs技术「需求即功能」和「语言即代码」的特点将对信息的供给和消费同时带来变革，具体如下：

在供给侧

信息的生产角色从人类开始向人类+算法过渡，这个过程将逐步实现信息内容生产的工业化、自动化和智能化，这意味着更高的内容生产效率以及内容生产成本边际递减。
信息生产活动将从库存逻辑向订单逻辑变化，即信息生产从一项业务的固定成本（提前生产好信息等待用户阅读、搜索、推荐）变成了一项可变成本（根据用户需求实时生成）。
信息的供给模式将从分发逻辑向生成逻辑转变，搜索和推荐都在进行信息分发，即让用户更高效地获得正确的「原始信息」，而LLMs生产信息的方式天然会将「原始信息」与用户进行隔离，当用户得到有用的信息时可能并不需要知道这个信息原本来自于哪里。

在消费侧

信息的使用方式从消费离线内容向消费实时内容变化，与信息生产逻辑变化相对应，用户使用信息的方式将从消费已经生产好的信息变为消费实时生成的信息。
信息的形式从静态向动态变化，与上一个变化对应，内容形式将从静态内容逐渐向可交互内容变化（比如对话实际上可被视为可交互的文本）。
获取的信息的方式从个性化向定制化变化，LLMs时代产品提供信息的方式将实现针对不同用户的定制化，即为特定用户生产专属信息，这在带来更好的信息消费体验的同时也会进一步增加信息茧房效应。

从产品的算法到算法的产品

从业务角度看，传统的AI业务中，算法与产品是两个有关联但又有各自独立的工作环节，而对于LLMs的产品来说，由于「算法即产品」的特点，对产品功能的设计将逐渐等同于对算法能力的设计，这将在以下三个维度带来变化：

目标层面：LLMs模型工作的目标是直接满足业务需求，而非提供某种模型能力后再进行业务封装，这需要对模型进行产品化的设计。
组织层面：与上述变化需要配套的是组织层面的变化，LLMs的模型研发团队不应是一个并行于业务单元的支持单元，而是其本身就是一个业务单元。
执行层面：对LLMs的产品经理有更多的要求，其工作范围将包括模型应当具备何种能力（任务设计），模型实际具备何种能力（模型评测），模型如何具备何种能力（数据与对齐策略）等。

新的市场熵增周期

市场熵（Market Entropy）用来代表市场上用户需求的无序程度（Figma的投资人Kevin Kwok提出），如果用户的需求变化速度更快，市场熵就会更高，其核心表述为：

较低的市场熵有利于已有产品（组织），较高的市场熵更有利于新产品（组织），市场熵处于上升趋势时，是拓展新业务的好时机，市场熵处于下降趋势时，则更需要考虑如何巩固已有优势。
自然状态下，市场熵的发展趋势是逐渐减少的，原因在于产品设计者会通过不断增加功能来满足、引导用户的需求，从而让市场上存量的有效用户需求不断减少，底层技术的革命会带来新的市场熵增。
底层技术能够将原本处在低熵状态的市场进行有效整合，从而形成全新的市场机会，而这是变革中最容易被忽视的点，即在被认为没有机会的市场中长出伟大的新产品。

显然LLMs技术将对市场熵产生广泛且剧烈的影响，带来新的熵增周期，这是本轮LLM-Native产品工作开展的一个基本外在客观事实，具体到当下，我们可以观察到：

熵增已经开始出现，用户对LLMs能做的事情正在进行积极地探索，需求产品化的速度显然低于用户在这种探索中形成新需求的速度。
目前的LLMs产品并未影响新增的市场熵，因为其仍处在面向已有需求设计产品的阶段，解决的是存量需求，比如实现更高效的搜索（直接获取加工后的信息）、更高的文本处理效率（摘要、数据处理、翻译）、辅助内容创作（代码、邮件、报告）。

我们正处在新一轮市场熵增的早期

在变革到来时，是否能够率先参考并利用这些变化来完成产品设计将会成为早期LLM-Native产品发展过程的胜负手。

变革中的那些确定性

信息的解构

对于信息内容来说，一个显著的趋势是新技术将带来基于原有媒介内容被解构并增强互动性后形成全新产品形态，其过程分为两个循环交替的环节：

旧的内容形式被解构后用来满足原有用户需求并形成新的产品形态。
新的产品形态在迭代中形成新的内容形式。

一些典型的内容被解构的例子：

博客被解构为内容更短、参与门槛更低的Twitter、instgram。
电影被解构为电影解说类视频和弹幕。
歌曲被解构为其中最好听的那一小部分来作为短视频的BGM。

对于LLM-Native产品来说，我们相信一定会出现新的信息解构形式及其对应的产品形态，比如，可交互的视频内容也许可以将现有的单位视频的播放时间进一步解构到更短、已有IP内容（如小说、漫画）通过加入生成技术被解构为新的可交互内容。

通过制造稀缺

稀缺性是所有商品和服务都试图去设计的，其主要原因为：

从经济学的供需原理来看，稀缺性将提升价格——卖的更贵。
从心理学的稀缺效应来看，稀缺将带来更多的关注——获得更多注意力从而获得更高的经济价值。
从行为经济学来看，稀缺将带来更容易做出的消费决策——更高的付费意愿。

稀缺性是互联网产品一直在努力追求但却不好获得的一种产品属性，因为这通常与互联网技术基因中的「免费原则」、「平等精神」背道而驰。

但是在通过稀缺性获取更高的注意力方面，LLMs的技术可能会带来突破：提供完全定制化的内容会比推荐算法带来的个性化内容具有更强的稀缺感（专属商品、服务当然会有更高的吸引力），从而更容易让用户交出自己的注意力。

从这个角度来看，对于LLM-Native产品来说，在单位内容中获取的用户注意力会更高，从而让用户的单位产品使用时长具备更高的经济价值。

满足控制感

追求掌控感是人类的天性，所以用户对产品的控制感是评价设计好坏的一个基本维度，在《设计心理学》中，控制感被描述为：

用户心理模型（来源于经验和期望）和系统模型（产品最终提供的功能、形态、内容）的接近程度，越接近则可控感越高。

对于LLM-Native产品来说同样需要遵循控制感的设计原则，通过上面的分析，我们很容易发现LLMs将提供全新的控制感：

功能的可控性变弱：功能被隐藏在模型能力中了，对用户来说会不知所措。
形态的可控性变强：形态上，以自然语言对话为核心的产品形态将增强用户的控制感。
全新的内容可控性：与上文提到的信息供给侧逻辑变化相对应，由于内容是模型实时生成的，所以用户第一次拥有了对内容的控制感。

我们相信，对内容的控制感是一种即将被LLMs技术激活的潜在需求，这将会成为LLM-Native应用的一个重要差异化体验。

需求抽象程度不断提升

所有产品都是围绕某种抽象程度的需求来设计的，而通过观察对解决相同类型问题的产品发展历程，我们可以看到一个显著的趋势：产品所对应的需求抽象程度不断提高。

两个具体的例子：

Photoshop面向的需求为如何更好的控制像素点，而到了Canvas、Figma时代需求变成了如何更快的使用模板得到一个可用的设计稿。
搜索引擎面向「哪些信息包含我提供的query」的需求，而推荐引擎使用更高抽象程度的user profile作为分配依据，将需求抽象至「哪些信息可能是符合我的偏好」。

显然，LLMs技术将带来更高的需求抽象程度：

Midjourney面向图像所包含的要素、风格以及其他用户要求来创作图像。
Jasper等文本生成产品将文本创作需求的抽象程度提升到对内容的直接描述。
Perplexity等搜索（或者称之为生成）引擎则将获取信息的需求抽象到了对所需信息本身的描述（当然也继承了推荐时代的user profile）。

所以，更高的需求抽象程度是LLM-Native产品的必然发展方向，每一个需求都值得用更高的需求抽象程度来重新审视。

加工更高层级的智慧信息

LLMs是一种新型媒介，那么从媒介的角度分析，我们能得到一些有趣的确定性。麦克鲁汉在《人的延伸——媒介通论》中对媒介有两个重要的论述：

媒介是人的延伸：一种媒介总能够映射到某种人类的能力。
媒介即是信息：媒介本身决定其传递的信息内容。

从这两个论述我们提出以下问题并给出回答：

问：LLMs延升的是人的何种能力？

答：LLMs延升的是人类的一些智慧能力，如语言理解、逻辑推理、信息构建等。

问：LLMs作为一种全新的媒介，其传递的信息是什么？

答：LLMs传递的是智慧化的互联网（或者说信息化）数据。事实上，有一种对LLMs的描述便是“一个高度压缩的互联网”。

综合上述内容，我们似乎可以对LLMs给出一个媒介版的定义：通过对互联网信息内容的压缩来延伸人类的部分智慧能力。

结合我们之前文章反复提到的「压缩产生智能」观点，如果我们能够将LLMs所压缩的信息内容进行智慧含量计算，其应与LLMs最终展现的智慧能力程度是正相关的。

目前我们可以通过互联网公开的内容信息达到当前LLMs展现的智力，而更高智慧密度的信息内容也必然诞生更高智力，这些更高智慧密度的信息可能是：

实际业务中被验证有效的工作流。
尚未被信息化的行业know-how。
带有行业属性的结构化信息模板。

如何得到更高智慧密度的信息，将决定LLMs媒介对人类智慧延伸的范围和程度，对LLM-Native产品的设计来说，当互联网已有的公开信息无法拉开LLMs的智力差距时，通过获得、压缩与自己场景相关的更高智慧密度数据，将成为产品差异化的关键（这一点我们在下面的文章中还会有相关讨论）。

创建LLM-Native产品的几个原则

以下是一些进行LLM-Native产品设计时可能有用的建议：

LLM-Native与模型自由

《Does One Large Model Rule Them All? Predictions on the Future AI Ecosystem》（作者：谷歌前CEO Eric Schmidt、Databricks首席科学家、斯坦福教授Matei Zaharia和Samaya AI创始人Maithra Raghu）这篇文章写于今年4月初，在当时GPT-4封神、GPT-5呼之欲出的舆论环境下，几位大佬提出了一个非常不合时宜的行业非共识：

未来的AI生态中，通用大模型负责解决长尾问题，高价值的业务场景将由专业AI系统来解决，具体表示为下图：

模型类型-问题价值曲线

以这篇文章的内容为出发点，我们认为：

从产品工作的视角来看，LLM-Native产品必须拥有自己的模型。而这并不意味着通用模型和垂直模型是非此即彼的竞争关系，事实上我们相信在较长的一段时间内，我们都会看到智慧程度更高的通用底层模型与业务能力更强的垂直模型展现出某种合作关系，具体来说：

垂直模型面向应用，用更低的成本以及更好的业务效果为特定场景服务。
通用模型面向模型生产，用更强的智慧水平提高垂直模型生产的效率。

所以对于LLM-Native产品的工作来说，首先应该将专业模型加入工作计划表，其次要善于借助通用模型，最后要记住不要过分依赖通用模型。

找到自己的LLMs的能力光谱

我们在前文提到过“需求即能力”这一LLMs技术的特点，这个特点决定了不同的LLM-Native产品因其面向场景、解决的问题、面向的用户群体不同，而对模型能力的要求有所差异。

一个形象的比喻是：原子的特征光谱。即当我们将某种LLM-Native的产品对应到LLMs时，就像不同原子会显示出不同的特征光谱一样，此时应该能够列出一个明确的模型能力规格说明书，通过这份说明我们可以：

知道自己需要什么样的模型。
能够评价不同模型对业务的价值。
可以指导模型效果的优化方向。

不同的场景对模型的能力要求会有很大的差别

所以，未来LLM-Native产品经理可能会有一项工作就是定义出自己场景的模型能力光谱，而这将是整个产品设计工作的起点。

利用LLMs的优势而非劣势

任何一项技术都有其技术优劣势，所以产品设计者一定要懂得扬长避短、顺势而为。

比如相对于PC互联网，移动互联网有随时可使用、位置信息、设备绑定、相机陀螺仪等硬件优势，同样也有展示空间有限、文字输入不便等弱点，所以在扬长避短的原则下，出现了面向碎片化时间的产品（feed流类产品）、出现了基于位置信息的产品（打车）等，在设计上也会用更轻的交互来避免文字输入。

对于LLM-Native产品也是一样，我们需要找到LLMs的优点，基于这些优点来设计，并同时识别出技术的弱项，从而在产品设计时尽量规避，比如我们很容易可以整理出一些可以供参考的优劣势：

优势

能力是一个开放域
通过自然语言完成交互
内容是动态可操作的
...

劣势

内容不可控
实时生成速度慢
模型更新、使用成本高
...

比如A16Z最近提出的AIGC应该面向概率型产品（probabilistic products）进行设计的观点，就是试图利用模型优势进行设计的一种尝试。

如何利用模型的概率性进行产品设计

也许，未来每个LLM-Native的产品经理都应维护一份LLMs的优劣势清单，在确定产品的功能设计后，都应该从LLMs技术的优劣势进行一次审核，看看是否做到了“趋利避害”。

生成器和系统2

使用LLMs进行生成是以指令为起点的，即：

指令->LLMs->内容&行动

最直观的指令是用户的prompt，也就是使用自然语言将需求表述出来，此时，需求=指令，但随着LLMs技术的发展，我们会发现：

由于模型能力的开放性，相同需求的不同指令差距会很大。
除了prompt外的其他要素也会加入指令被输入模型，比如外部知识库、工具接口等。
模型能力越来越强，对应的指令也会越来越复杂，这也是上文提到的“语言即代码”特性的必然结果。

一个愈发明显的趋势是用户需求和指令的分离，即会有一个专门的指令生成环节来连接用户需求和LLMs（Agent便是这种趋势下的必然产物）。

这里我们将接收用户需求并翻译为大模型指令的工作环节称为生成器：一个面向特定任务设计的，能够将用户的需求最大限度转化为模型生成时应当执行的行动集合的指令的工作模块。

生成器将用户的需求经过处理变成大模型的可执行的生成指令，生成器可以很简单，比如一个prompt模板，也可以很复杂，比如一个Agent再加上数据库，甚至也可以是一个模型，比如生成prompt。

「生成器与底层模型共同完成生成过程」这一范式具有更深的底层逻辑，即《思考，快与慢》一书中提出的系统1和系统2，底层模型将作为系统1，而生成器将作为系统2，二者形成一个整体系统，并分别适合用来解决不同类型的问题，系统1和系统2的概念也被OpenAI联合创始人Andrej Karpthy用来解释GPT的原理，与人类的系统1与系统2更加独立的关系不同，LLMs的两个系统存在显著的转化关系：

系统2的能力会不断被系统1内化，所以系统2需要不断被设计，而系统1则会不断增强。

作为用户需求的翻译者，生成器将会在很长一段时间内成为LLM-Native产品的关键设计环节，结合上文的信息，产品设计工作将从功能性设计转向模型能力+生成器的建设：

设计产品就是设计模型
设计产品就是设计生成器

LLM-Native产品的特点

下面我们将试图抽象出LLM-Native产品可能具有的特点，理解这些特点可以让产品方向的选择以及设计工作更容易和科学。

新问题

首先是新问题，LLM-Native产品需要面向新问题所对应的需求进行设计。什么是新问题呢？我们知道所有产品的价值基础都来自于对某种用户问题的解决，而新的技术范式通常会带来两类问题，即：

什么会更好：如何通过新技术更好的解决已有问题。
什么会出现：拥有新技术后有哪些之前无法解决的问题变得可解了。

结合在前文市场熵的部分我们已经做过的说明，我们可以分析出这两类问题有如下特点：

第一类问题：需求容易被发现，很快就能有收益，但解决的是存量需求，通常会表现为某种形式的降本，需求的价值上限低。
第二类问题：需求通常是被隐藏或者压抑的，需要被挖掘，通常需要更长的产品周期才能兑现收益，解决的是增量需求，带来的也是社会整体价值的增加，比如创造新职业，甚至新行业，需求的价值上限更高。

很明显，第二类问题才是LLM-Native产品要面向的新问题。那么如何找到这类新问题？这里提供一些可供参考的定位方法：

拥有新技术才能解决，比如短视频产品需要同时具备智能手机+4G网络才会出现。
将已有产品的底层需求代入新技术，比如个人知识库在表面解决的是信息存储和处理的问题，而其底层则包含着如何有效的使用这些信息的需求，从这个底层需求出发，就能发现LLMs的生成能力与这个需求天然契合。
从新技术的特点出发，我们上文提到了一些LLMs技术的特点，那么用这些特点来对应用户问题也是一个可行的思路，比如LLMs可以生成如何行动的信息，那么对应的问题便是计划类、行动类问题，相比上一代AI解决感知型、决策型问题而言，就是新问题。

通过技术、底层需求两个思考维度，我们还可以发现更多定义新问题的方法，这里由于篇幅原因不做赘述。

新形态

如同PC时代的网站、移动时代的APP一样，我们相信LLM-Native产品也会诞生自己的产品形态，虽然现在无法判断这个形态到底会是什么，但是已经有一些正在形成的演变趋势。

极简设计

这里的极简指的是产品表现层体现出的极简，更准确的描述应该是：极简设计+丰富能力

用看似简单的产品形态来实现复杂多样的功能，这已经成为以LLMs为核心产品的特点，如果对这类产品进行功能清单梳理，大家会发现其核心使用流程所对应的功能都非常简洁，而其能够完成的任务或者具有的能力又极其丰富。

这种趋势是由前文提到的「需求即功能」特性决定的，由于LLMs理论上可以将任何信息通过压缩+预测next token的范式进行生成，所以大量的产品功能无需暴露给用户。

但是值得注意的是，极简设计并不意味着能够帮助用户更快完成需求传递的功能和产品界面不再被需要，他们会以另一种形态存在于LLM-Native产品中。

动态功能

动态功能是指LLMs产品在使用时，其展现给用户的功能、界面并非是提前设计的，而是可以根据用户当时的需求进行动态生成，这个特点同样具有必然性：

LLMs的开放域使用方式，要求其必须拥有无限的功能与界面，而这些功能与界面显然是无法通过人工设计来满足的，所以从技术的特性上其具有必然性。
LLMs的「语言即代码」特性则提供了动态功能的可行性，在这个特性下，用户的需求以自然语言的形式进行转化和加工后，可以直接生成对应的功能或者界面。

动态功能和界面将是LLMs相关产品的重要发展方向，也许未来我们可以用动态功能在产品中的占比来衡量一个产品的LLM-Native程度，推荐系统作为对检索系统的个性化，在移动互联网开创了一个全新的产品时代，我们有理由相信LLMs的动态功能特性也将开启一个新的产品时代——个人定制化产品时代。

Perplexity的Copilot功能：根据用户输入生成动态表单来明确需求

定制化产品

如同推荐带来了信息内容的个性化，我们相信LLMs技术将带来产品的个性化。

产品的标准化和需求的个性化是一组产品设计中的基本矛盾，用户天然希望产品为自己量身定做，而产品提供者则需要通过标准化来确保产品的生产和运营成本，我们在前文「用户需求的无损传递」中已经涉及到这个问题的讨论。

相比于软件范式下产品必须标准化不同，LLMs带来了「产品说不定也可以个性化」的全新机会，那么这将带来内容个性化后的新一轮产品革命，围绕「个人定制化产品」的理念，所有的已知产品都存在升级迭代的可能。

新交互

关于LLM-Native产品的交互工作变化是近期被讨论比较多的一个话题，有不少文章进行进行了很好的说明，在此我们提供几个交互设计工作中原则性的特点：

从告诉机器怎么做到告诉机器要什么

全球顶级的用户体验研究机构Nielsen Norman Group在6月的一篇文章中提出，LLMs为核心的AI技术将带来计算机出现后的新一次交互范式革命，之所以称之为革命的关键原因在于交互设计工作的目标发生了变化：

上一个交互范式的工作目标为「如何更好的告诉机器该如何遵循用户指令」（Command-Based Interaction Design），而新的AI交互范式下，工作目标将更新为「如何更好让机器知道用户想要什么」（Intent-Based Outcome Specification）。

人机交互的三种范式

自然语言成为一个新的交互维度，但不是交互本身

我们上文提到过LLMs具有通过自然语言来驱动产品使用流程的特点，这意味着自然语言从交互的内容成为了一种交互设计的维度。

而随着ChatGPT的出现，产品的设计出现了一种“万物皆为Chatbot”的设计趋势，但是实际上Chatbot只是LLMs在交互中的一种展现形式，更为本质的问题在于自然语言从交互的内容变成了交互的方式。

对此问题，Notion的UX研究员Linus Lee在其《Generative Interfaces Beyond Chat》的talk中有过论述，其核心观点为：

自然语言作为交互方式有优点（更高的灵活性）也有弱点（可理解性）。
LLMs对交互设计来说，其价值在于增加了一种新的维度，应当与其他的交互维度（如GUI）配合使用。

自然语言交互提供了更好的灵活性，但也损失了产品的可理解性

所以对于LLM-Native产品来说，一方面我们将显著的观察到，自然语言将在交互中出现并承担重要的角色，但同时我们也应尽量避免陷入「LLM-Native=Chatbot」的设计误区。

面向不确定性进行设计

在前文中，我们提到过LLMs具有能力黑盒和生成内容不可控等特点，这些特点将带来产品使用过程中的巨大不确定性。

对于传统的软件产品思路，交互一定要是清晰、准确、具体的，而这与LLMs的生成技术显然存在冲突，所以LLM-Native产品势必会展现出一种新的交互思想，即：面向不确定性设计，这将展现出的工作特点为：

尽可能减少对用户行为的约束。
会有更多设计被用于帮助和引导用户理解和调起模型能力。
对模型输出会有更多的引导和约束从而确保结果的可控。

早期LLM-Native产品的观察

已经有越来越多令人兴奋的的新产品开始出现，下面将从一些可观察的市场信息中尝试抽象出某些共性和趋势，以期为正在面向LLM-Native理念进行设计的产品工作提供一些有价值参考。

社交

马克思曾说「人的本质是一切社会关系的总和」，从这个角度而言，LLMs的出现对社交产生的一个重大影响在于：在社会关系中，增加了AI这一全新的社交维度。

这使得社交产品有了全新的想象空间，具体表现为除了人-人社交的角度外，我们还可以从如下角度进行设计：

人-机社交：人类与AI进行社交，比如Character.ai，Replika。
机-机社交：AI与AI进行社交，人类进行观察或者参与，比如chirper。

注：机-机社交是一个尚未得到足够重视的方向，该方向下人类可以为AI智能体们设计各种活动和任务，并以上帝视角进行观察和干预实验，比如用LLMs模拟人类成长过程中不同类型事件对其后续行为可能产生的影响。

Inworld：提供游戏中的智能NPC服务，已经具备了机-机交互的观测价值

从产品价值维度来看，目前的社交服务主要提供两种价值：

交换信息：即提供效率价值
找到同类（from 张小龙）：即提供情绪价值

那么AI维度的加入后，我们可以得到这样一张有趣的产品定位表，并能够对已有的产品进行定位：

社交产品设计的维度变得更加丰富

所以对于LLM-Native的社交产品来说，我们显然将面向一个更加广阔的设计空间，比如设计一个能在图中覆盖多个社交维度以及价值维度的新型产品。

内容

前文中已经提到过，LLMs技术将为信息内容产品在生产端、消费端带来一系列变化。

目前我们已经能够看到基于这些变化进行的早期尝试，比如一些Demo中，KOL将自己的文章、对话、资料等数据作为知识库并连接ChatGPT接口，从而让读者能够实时、无限制地获取带有自己知识和语言风格的新内容。

这当然只是一个很初级的产品化尝试，LLM-Native的内容产品更大的想象力在于，当更多垂直的LLMs在各自领域开始落地、不同模态的生成能力正在产品端进行融合、LLMs的生产和推理成本大幅降低时，我们应当能够看到与现在完全不同的内容产品形态，也许是：

可以自定义剧情的多模态内容”小说“。
可以按需生产的新型”短视频“内容。
可以结合用户画像以及其需求描述的实时生成的资讯内容。
...

Talkie：提供了一种基于角色扮演的多模态游戏化内容形式

工具

对于效率工具来说，一个显著的产品趋势是：以Copilot产品形态为过渡，实现AI-worker。

这里的底层逻辑在于上文中提到的一个概念：模型需要对某种程度的人类智慧数据进行压缩，才有可能涌现出同水平或者更高水平的智能。

显然对于效率工具类产品来说，如何对AI生成的内容进行处理、优化从而成为人类标准可用的工作成果，就是一种智慧程度更高，并且尚未被信息化的数据。

所以Copilot产品形态将会以已有的LLMs模型能力为基础，通过人机协作工作方式提升效率的同时，搜集更高智慧程度数据搜集的产品，而这也将成为「从LLM-Native走向AGI」的必由之路。

Copilot产品形态的要点在于：

确实能够在LLMs的能力下提供更高的工作效率。
被集成在现有的工作流中并能够获取工作流中的用户操作信息。
用户操作信息是已有LLMs能力的衍生。

对于LLM-Native的效率工具产品来说，可能的产品设计思路会分为三个模块：

对某个场景有效的LLMs能力建设。
以尽可能高效获取工作流中的更高智慧信息为目标进行Copilot产品形态设计。
优化LLMs能力直至成为AI-worker。

相信一段较长的时间内，我们应该会看到效率工具中Copilot形态的大爆发，实际上目前各类工具中集成Chatbot只是这个趋势的开始，因为chat的交互方式并不本质，Copilot形态的本质应当是如何获取工作流中对LLMs内容的处理和优化数据。

Github Copilot：最早也是最为典型的Copilot产品

总结

本文尝试对基于LLMs技术的LLM-Native产品进行分析，试图探讨如下几个问题：

LLM-Native产品有何不同
LLM-Native产品的独特性从何而来
在进行LLM-Native产品时应当注意哪些问题

具体而言：

我们从使用产品视角出发，尝试对LLMs技术在产品维度的特点进行抽象，并基于这些特点对LLMs技术对产品工作可能带来的变化进行了推演，结合在新技术冲击下依然有效的产品逻辑，我们给出了一些创建LLM-Native应用的可能原则以及目前可见的LLM-Native产品特点，最终通过对几个经典产品方向上LLM-Native产品的观察尝试给出未来的产品工作建议。

需要强调的是，LLM-Native产品将是一个至少与互联网产品、移动互联网产品同等级别的宏大主题并正处于高速发展中，我们既难以观察其全貌，也无法对其发展进行有效判断，所以本文的目标是提供一些对LLM-Native产品工作有价值的问题并提供对这些问题可能有帮助的观察和思考，而非输出观点和提供预测。

希望以此文为基础，能够与更多关注、从事LLM-Native产品工作的朋友们进行交流探讨。

感谢Kiwi参与创作，文中的很多观点来自与行业内投资人、产品经理以及算法工程师朋友们的讨论，在此不再一一致谢。

找作者喝一杯请添加微信：captain_woon

Reference：

我是朋克又极客的AI算法小姐姐rumor

北航本硕，NLP算法工程师，谷歌开发者专家

欢迎关注我，带你学习带你肝

一起在人工智能时代旋转跳跃眨巴眼

内容中包含的图片若涉及版权问题，请及时与我们联系删除

LLM-Native产品的变与不变