1. 前言感悟

1.1 所有产品的开始，都是满足用户的需求

首先，AI产品一定还是以 满足用户需求 为核心前提的。

大家可能觉得这是一句有用的废话，能够坚持这个这个思路做 AI 的人是少数；尤其作为经历过「移动互联网」爆发期的人来说，更难。

因为我们习惯了那个在 VC催化下，用 成熟的技术 和 稳定的输出结果 来解决 新的场景问题；从而带来高速增长。而路径依赖又让我们将同样的思路复制到AI的风口上。

不过AI的技术特性和能力边界不同，在很多场景下也确实产出了超预期的效果。但随之而来的，是导致其输出的内容 会面临大量的不确定性 ，这种不确定性甚至会聚焦在某一场景上；这就造成类似的场景看似高价值，但无法落地。

但也正是由于效果的开放性，形成了对移动互联网产品能力的补充，未来我相信也会有更多的场景会被重新塑造。

1.2 不要拿 AI 的锤子，去敲传统互联网的钉子

我这样理解：AI产品≠移动互联网；AI产品是传统互联网产品的价值与场景补充，两种产品的底层逻辑完全不同。

从历史上看，移动互联网爆发的前置条件，是产生了新的终端，同时匹配了成熟的技术；

新的终端贡献了大量的用户场景增量，而成熟的技术使得实现边界不再成为卡点，产品的PMF也水到渠成。

而 AI 技术的变革，并没有伴随新的终端出现，且技术也尚未成熟；所以短期的产品爆发一定是在既定的 垂直小场景中挖掘用户需求。

那垂直的小场景，就意味着不会诞生新的颠覆性产品吗？我对此是否定的。

试着思考上一代AI产品，我第一个想到的不是AI四小龙，而是字节跳动。

而字节跳动的第一个爆款产品，是一个新闻客户端：今日头条。也许它的成功一方面是由于踩到了移动互联网风口，但另一方面看，新闻客户端在那个时代早已不是一个新的产物，而头条却成功通过AI算法能力，改变了信息的分发效率，在既定的场景上取得了成功。

所以很多类似甚至看似相同的场景，以技术的视角看，可能最后的价值都大相径庭。这篇文章会把我之前踩过的坑，和验证过的场景，和大家聊一聊，希望能够带给大家一些启发。

2. AI 场景落地的思考框架

在做AI产品落地时，一般我会围绕这样以下几个维度，来评判场景的可落地价值：

开放域、不可穷举性、技术匹配成熟度、技术路径与商业平衡

2.1 维度一：开放域

首先介绍一下我定义的开放域的概念：我对它的定义是：是否会产生会无限种输出的可能性，且能够被用户接受，则符合开放域原则。

这里我举2个例子：

LLM在最典型的chat场景中，用户问法一定是无限种可能性，而答案会随着指令的不同，产生各种各样的输出结果，甚至同一个问题，输出的答案；

在文生图场景中，通过调提示词，能够输出无限种图片样式，且每次输出的都会不一样。

以上都是LLM 乃至 整个AI场景的典型应用案例，但是大家其实都了解：在实际落地的时候，我们并不会拿来即用，因为模型存在的 指令遵循、灾难性记忆遗忘，幻觉问题甚至推理错误 等问题，且垂直领域专业度差；也正是因为这些问题，我们的prompt工程，实际上是为了解决模型不稳定输出的问题。

但做着做着会陷入到一个怪圈，我们顺其自然会觉得，我们觉得LLM能够解决实际业务场景中封闭的问题。

以下几个典型的看似高价值，但结果可能值得推敲的案例：

通过自然语言，让大模型识别并开启某个app软件；

通过自然语言，请帮我周末自动抢中秋回家的票；

拆解一下，这里简单的流程可以总结为：输入自然语言——识别语言——做具体明确的操作动作；唯一的不同是，日程的创建相对开放，需要提取语言中的信息，插入日程中。

但其本质上解决的都是偏 封闭型的问题，不符合开放域原则，所以个人觉得不属于高价值的落地场景；

当然如果是在抢票场景中稍作变化，加入了多轮对话，并通过AI 主动询问抢票的信息并最终将结果收敛，这样就是比较高价值的场景了；只不过在多轮对话确认问题场景下，却不一定要依赖大模型；这个我们后续再聊。

那么思考一个问题：大家都在尝试RAG应用在企业知识库，看似是要在封闭的企业知识体系下应用AI，那为什么依然是一个可落地的场景？

虽然在落地时，确实会遇到各种各样的问题，但实际上我依然对这个场景保持信心，说下我的思考：

如果从封闭性和开放性的角度说，个人认为这个场景实现了开放性和封闭性的互补；而LLM提供开放能力，信源的提供获得了准确性与封闭性。而LLM提供的是开放性能力：不仅仅是对内容的摘要，而且是可以根据用户不同的问法，提供开放性的解答方式。

可落地的典型案例：

知识条目：

• 用户自己创建的日报，可以在24小时之内删除。

用户问法：

• 已经创建的日志可以删除吗？

• 我可以删除别人的日报吗？

• 我5天前创建的日报，现在还能删除吗？

2.2 维度二：不可穷举性

不可穷举性是指：输出的结果是否在真实业务场景中具有不可穷举的规则，即：人无法一一归纳并设计出所有结果产生的背后逻辑。

上面的表述可能比较拗口，我来举个场景示例：

在电商客服领域中，经常会遇到一个场景：我要查询我买的商品现在物流状态是怎样？

在此场景下，可能第一反应是，通过LLM理解语义后并查询物流单号。但是把这个case拆解一下：

1. 输入的时候是否一定要通过大模型识别？用 关键词规则 也能解决和收敛大部分问题？

2. 输出的是一段结构化信息，其实并不需要进行信息的总结与摘要

对此我的思考是，在这个场景下，如果我们采用 物流、订单、查询 等关键词规则穷举，其实在上线的第一个版本是可以覆盖大部分的问题的，同时我们在产品层面，给用户一个问题提示，提示用户输入哪些关键词，也可以收敛用户的输入，获得可预期的结果；

当然在实际落地中，会遇到大量长尾的问法，而当用户规模足够大，从商业平衡的角度上，依然会上AI算法能力，这个我们后文中再探讨。

特别要注意的是，不可穷举指的是规则，而不代表一定是封闭的输出。从上面的例子看，一个关键词会产生无数输出，但其实依然是由一个可穷举的规则生成的。

相应的，电商的商品推荐、内容平台的推荐系统是一个典型的通过算法带来高价值收益的场景：用户的特征因为其大量的行为留存到线上，而产生了上千甚至更多个特征维度；一个浏览的特征，就可以拆解出浏览内容、时间、时长、跳出、访问深度等无数个维度细节；对应的商品的特征也会基于用户在线行为、商品本身特征等形成大量的特征集合。

这些特征集合聚集在一起后，会形成无限种排列组合的方式，而人无法通过穷举来设计推荐逻辑。

那所有的推荐系统，是否都值得用AI能力落地吗？

显然不是所有的推荐系统都适合用AI能力，下面我曾经踩过的坑。

某个头部二手房交易平台希望引入推荐能力，来提升房-客匹配效率。之前在用户端场景下，在用户浏览房源时提供房源推荐已经获得了一些收益；这次希望在房产经纪人端的客户详情页中，放入给这个客户推荐的房源，以提升交易效率和转化率。

于是我们前期做了大量的调研，抽象出针对房源区位、房型等数百个房源特征；同时抽象出数百个用户特征，加入了经纪人特征，并进行房客匹配并展示。

结果实际的TOP5召回（即推荐房源中产生带看的比率）低于5成；为此我们下店咨询了经纪人的使用情况，经纪人一直给出的结论是：不准。

不准的原因也很简单，经纪人在和客户沟通交流之后，客户往往会说一些并不在系统中才有的特征，而这些特征不会线上化，比如“我家有一些贵重物品，必须要放在储物柜里，且保证干燥，而且比较重，要好拿”。当经纪人了解这些情况后，会给介绍相应的小区，并往往会在1个小区介绍多个空出来的房源，所以往往1次带看都在1个小区中

而推荐的逻辑往往是：找到附近的房源，不会TOP5只推荐一个小区的房源；

所以经纪人的思维中，已经有了一个思维定式，推荐策略是既定的，且线下会收集到线上收集不到的重要信息；这些因子加在一起，导致AI再怎么优化，也无法超越经纪人固有的思维；

回归场景看：给经纪人推荐客户喜欢的房源，和用户端推荐房源；是看似类似，但本质上是完全不同的逻辑；

首先用户端的使用逻辑是：先在用户端看到房源，然后基于房源做推荐后，再一同浏览，这时了解房源信息的成本很低；而当线上环境切入到了线下，线下的逻辑、未被收集到的特征、以及经纪人的固有思维就成为价值阻塞点。

2.3 维度三：技术与价值平衡性

当我们完成了对以上两个维度的论证，且垂直场景梳理的足够清晰。我们最后就需要从技术和商业价值等角度，看待AI技术的可用性。

从这个维度上看，我们核心关注以下几个问题：

• 大模型 or 小模型：如果采用了AI能力，是否一定需要大模型的能力？传统小模型是否也能达到类似结果？

• 商业价值评估：如果AI能力是面向特定领域，那么它所在的特定领域，是否是一个高价值场景？

• 成本收益评估：如果是一定采用大模型能力，采用什么样的技术路径，能够达到产品可用标准？易用标准？分别的成本评估是怎样？

下面针对以上几个问题，逐层展开我的一些见解。

2.3.1 大模型 or 传统小模型？

首先，我们要思考的第一个问题，就是大模型与传统小模型的选型问题；注意，这里说的小模型是传统小模型而非类似千问7B的，基于tramsformer架构的小模型

而选型问题的背后，场景的预期是核心要素，它决定了选型成本。

在聊场景预期时，我简单介绍一下大模型与小模型的能力差异，这里我暂时不会讲晦涩的内容，如果大家关心技术原理本身，我会在后面的文章中介绍，这里围绕主题，重点介绍应用场景的差异。

个人认为，大小模型在应用场景上的差异，体现以下几点：

• 擅长在 相对模糊 的自然语言指令中，识别并支持多种任务中处理问题（识别、提取、分类）

模型更擅长具体的识别能力，且识别的信息是标准的答案（枚举值、标签）

• 大模型更擅长于解决 生成问题（例如：摘要、生成、知识库解答）

• 大模型更擅长将多渠道信息源聚合在一起，并整理成一段话（信息渠道越多，信息量越大，价值就越大）

下面是一个在To B 的 CRM领域应用较多的一个案例：

在和客户进行在线会议结束后，在经过客户允许的情况下，会议信息录屏将保存下来：

销售人员此时会针对会议信息做两件事，对应的AI场景我也在内容中标记出来：

1. 销售记录：会议的信息需要进行摘要提炼，提炼出重点沟通要点，例如：

1. 客户提出了哪些对产品的疑问；以及每个问题的应答是什么？（内容摘要）

2. 客户的业务现状是怎样，目前客户在业务运营过程中的痛点是什么？（内容摘要）

3. 文中是否提到了报价？（信息提取）

4. 是否表现出正向态度？（文本分类）

2. 针对会议内容，自动提取信息至客户表单中（信息提取）

从以上的案例中，我们分别从用户故事角度拆解一下场景：

在场景1中，当会议内容存档后，可能的场景之一，是：我们后续会打开客户详情页，向AI询问上述这些问题，方便我们快速review客户情况，因此是一个 基于不同指令的多任务场景，此模式下我们基本只能采用大模型方案来解决。

而针对场景2，整个场景较为明确，就是要在每次会议录音存档后，自动识别并提取信息至表单。因此通过传统UIE小模型也能解决类似的问题，甚至在一些场景上由于领域垂直，效果不会低于大模型，而成本却远低于大模型。

2.3.2 产品价值评估

在产品价值评估的维度，我们分析的核心目标，就是为了最终达成TPF，即产品技术匹配。

而在不同的特定领域，实现产品价值的评估方法会有较大的不同；

如果是以 流量匹配效率 为核心的业务模式，其产品价值更为显性，产品价值更容易评估。

比如以过去的在线教育行业，大量的用户线索会从各大平台渠道收集，并期望通过设计分配策略，分配给最容易成交的课程销售人员。这里分配策略的算法设计优劣，就直接影响到交易转化率，进而直接影响GMV。

而如果是在To B行业，有些产品能力就不那么显性；这里主要和大家聊聊非显性场景下的评估思路

例如在销售场景中，通过LLM、结合客户信息自动生成方案PPT。这类场景其实很难直接评估，此时的评估方法更多的是从 客户体感 上得到一个满意度、和提效程度的核算。

而针对不够显性的价值评估场景下，需要通过 行业认知+客户价值感知 3个角度去整体评估

从行业认知的角度上，如果我们了解一个行业的核心业务模式，就可以推断出客户关心的产品形态是怎样；

例如在国内的CRM场景中，大家在当前的经济环境下，中小企业更关心的获客；因此在价值厚度上，获客的效率提升大概率大于客户服务场景。

如果是行业认知达成共识的前提下，另一个重要的维度是客户价值感知；正如我上述内容中提到的「房源推荐」场景，如果客户本身就对这件事有着固有的判定逻辑；虽然客户觉得这个场景很有价值，但结果也很难达成预期。

顺便说一句，从这个角度看，当一个新的技术涌现时，用户往往并不知道自己要什么。而颠覆式产品也往往在这个时候诞生。

2.3.3 商业价值（ROI）评估

个人认为【产品价值】是【商业价值】的基础条件，除此之外，还需要看到实现产品价值背后的成本，通过产品价值、成本两个维度去综合判断商业价值。

这里以企业知识库问答为例，从显性角度来看，企业知识库的成本来自RAG工程化调优的成本、模型微调成本。但是技术在很多企业落地时并不是唯一的卡点，而 企业知识文档建设的完备性。其是对于国内信息化程度不完善的情况下。

这种情况下，即使把工程化、技术做到最优，而企业内部并没有形成规范化的知识体系，依然无法将企业知识问答落地，而知识库体系的建设背后又包含大量的维护和迭代的成本，因为企业知识在迭代，相应的内容维护也要跟上。

所以这里面商业价值的最核心要素是：需要找到这样一个场景，能够cover掉知识库建设的成本、技术落地的成本、硬件的成本、技术人力的成本等等。

令人遗憾的是，目前能够cover的这些成本的企业还属于少数；往往集中于to c场景；或是银行等大型企业；因为这些场景的知识体系通用，其各项成本的随着规模效应被摊平，才使得其最先成为落地的可能。

所以短期来看，能力不够、产品来凑，也可能是一个商业最优解。

比如，一个机器人只能够实现70%的应答正确率，那么就可以将答案不直接暴露给用户，而是先给到客服团队，小幅度修改后，也能一键发给用户，在一定程度上也能阶段性解决问题。

而实践下来，把AI知识库从0提升70%的成本，远远比70%提升到90%要低得多。

以上是我在AI产品落地时遇到的一些坑，和我的一些思考。也许里面很多的内容是非共识的，或者也会有一些理解上的偏误，也欢迎大家给我留言指出。希望能够结识行业内的朋友们，一起沟通交流