在实操层面，尝试给出 LLM-Native 产品创建的原则、针对产品特点提出可能的产品构想、并对如今的代表性产品进行分析。

撰文：

LLMs 技术的新特点必然会给我们的产品工作以及思维方式带来变化，认识并接受这些变化的过程也许会像从麻瓜世界长大的巫师首次进入霍格沃兹——有趣、反常、但必要。在应用之上，LLM 作为一种新的信息媒介将带来人与信息的交互变革，信息论、心理学、经济学下的第一性原理值得重新被拿出来重塑思考。在上期的文章（《市场熵增，LLM 正在成为延伸人类智慧的新型媒介》）中我们从宏观层面对 LLMs 的技术特点进行分析并试图构建新一代信息媒介下的产品哲学。本期我们回到实操层面，尝试给出 LLM-Native 产品创建的原则、针对产品特点提出可能的产品构想、并对如今的代表性产品进行分析。

欢迎回到霍格沃茨。

Sense 思考

• 构建自己的 LLMs 能力光谱：在未来的 AI 生态中，通用模型解决长尾问题，而垂直模型面向高价值场景。LLMs 类似原子的特征光谱，会根据其应用场景、面向的人群等不同而需要呈现不同的能力，而这则需要未来的 AI Engineering 进行应用和模型的匹配。
• 慢思考融合快思考：对比《思考 快与慢》中的两种思维模型，底层通用模型类似人脑的系统 1 ，而生成器类似系统 2。但与人脑的两个系统之间相对独立不同，对 LLMs 而言，系统 2 的能力会不断被系统 1 内化，所以系统 2 需要不断被设计，而系统 1 则会不断增强。
• LLM-Native 特点：新问题、新形态、新交互是三个 native 特点，可以从底层需求和新技术本身两个维度寻找增量需求，极简、动态、定制化是三个产品新形态，而自然语言将成为新的基于意图（Intent-based）的交互维度，即更好地让机器知道用户想要什么，而不是简单的交互本身。SenseAI 非常看好：新硬件，新场景，新系统。
• 早期产品观察：社交、内容和工具三个层面，目前的产品还处在交互方式改变的早期阶段，需要更本质的产品全链路设计。
• 社交的新供给就是人 - 机和机 - 机交互，情绪价值和效率价值的数量级提升是关键，而机 - 机交互模式的窥探和影响方式值得探索。
• 内容生成会真正进入流时代，当更多垂直的 LLMs 在各自领域开始落地，LLMs 的生产和推理成本将大幅降低并出现全新的内容产品。
• 工具产品目前 Chat 的交互方式并不本质，Copilot 形态的本质应当是如何获取工作流中对 LLMs 内容的处理和优化数据，最终过渡成为 AI-worker。

01.创建 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）进行设计的观点，就是试图利用模型优势进行设计的一种尝试。（Sense 说：参考我们的往期文章：《a16z：巧用「幻觉」的应用架构思考》对概率型产品进行了详细解读。）

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

也许，未来每个 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 产品的关键设计环节，结合上文的信息，产品设计工作将从功能性设计向模型能力 + 生成器的建设：

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

02.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 产品势必会展现出一种新的交互思想，即：面向不确定性设计，这将展现出的工作特点为：

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

03.早期 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 产品

04.总结

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

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

具体而言：

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

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

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

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

参考材料

https://github.com/JushBJJ/Mr.-Ranedeer-AI-Tutor#prompt-formats

https://kwokchain.com/2021/02/05/atomic-concepts/

https://www.nngroup.com/articles/ai-paradigm/

https://maithraraghu.com/blog/2023/does-one-model-rule-them-all/

https://www.bilibili.com/video/BV1ts4y1T7UH/?vd_source=0a7349493c5d70149efefa88eac70de1

https://mp.weixin.qq.com/s/p0qFgduUX4R-4LnRDhHP2Q

https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html?utm_source=bensbites&utm_medium=newsletter&utm_campaign=have-you-been-a-bard-boy

https://www.youtube.com/watch?v=rd-J3hmycQs

https://a16z.com/2023/05/23/generative-ai-probabilistic-products/

https://mp.weixin.qq.com/s/JvnGT9RnrcO1KGn6c-9qMg

https://mp.weixin.qq.com/s/quzcSo7y-z96k_waujYjAw

https://mp.weixin.qq.com/s/m85shIJ5r-kYvXkuHrrnFQ?from=timeline&isappinstalled=0&scene=2&clicktime=1686992182&enterid=1686992182

https://mp.weixin.qq.com/s/_vqNmQECdKaJJXW4agQh9g

https://www.inworld.ai/

https://www.youtube.com/watch?v=OT7XvazhHgE