随着大模型技术的兴起，许多企业纷纷投入资源开发相关应用产品，试图在这股浪潮中占据一席之地。然而，随着市场热度的逐渐退潮，真正能够满足客户需求、创造价值的产品才逐渐显现出来。

今年，几乎是all in在大模型应用的产品上。

现在大模型的热度，已经有退潮的迹象，不像去年那么火爆，人人都在讨论。不过，这退潮之后，真正属于大模型产品的机会，才像沙滩上的贝壳一样，一个个冒出来。

任何一个事物的发展，都会有一阵狂热期，大家都去吹捧，进入到一个“造神”的阶段。

在这个阶段，你做出来的产品，就是个“蹒跚学步”的小孩，而客户眼里的产品，那得是能上天入地、无所不能的“超级英雄”，所以你这产品很难达到客户的预期。

等第一批花了大价钱尝鲜的客户，新鲜劲儿过了，也冷静下来了，也就进入到了“去魅”的阶段。

这个时候，客户才像个理智的大人，选产品的时候不再盲目跟风，对产品也有个合理的预期，不会再提那些不切实际的要求。

可咱就身处这波浪潮之中，你该如何去定位产品，选择什么样的产品路线，也就决定了浪潮退去之后，你还能游多远。

以我切身做产品这几个月的经历，给大家分享一下我做大模型应用产品的几个关键决策。

一、完全依赖大模型，行不行？

咱先说说这大模型能干啥。它就像个超级小能手，数据处理、要素提取、文章生成这些活儿，它都不在话下。要是做个软件类应用，那基本把产品要用的功能都给包圆儿了。

就拿我们正在做的文书生成系统来说吧，用户只要把材料往上一传，各类文档“唰”地一下就自动生成了，跟变魔术似的。

这么牛掰的产品一出来，哪个客户能不心动啊？这简直就是工作效率的“加速器”，生产力的“解放者”。

所以，一开始设计产品的时候，我们心里就琢磨着，干脆全靠大模型来实现各种功能。

那咋实现呢？

其实原理简单得很，就跟和大模型玩“你问我答”的游戏一样。咱把数据一股脑儿地喂给它，再通过提示词问问题，它给出答案后，咱直接把答案展示在系统页面上，齐活！

不过，很快我们就否决了这种方案。

这是为啥呢？

首先，面临的问题就是输入给大模型的数据大小限制。

市面上那些大模型啊，就像有个小肚量，只能装下一定量的东西。根据模型参数大小不一样，能理解的上下文长度大概在1万到20万字之间。

咱选的是个7B的小参数模型，它最多也就只能理解1万字的内容。要是遇到一份材料有几百页文书，那它直接就“懵圈”了，根本给不出答案。

那，为什么不用更大参数的模型呢？

这想法是挺好，可问题是，模型参数越大，对显卡资源的要求就越高。一个7B的小模型，一张4090显卡就能让它跑起来。要是换成70B的模型，估计得4 – 8张4090显卡才能伺候得了它。

而我们做产品要考虑到生产成本和客户的购买力，如果光采购显卡的费用就要一二十万，产品就没有太多客户消费得起。

其次，还有一个当前无法解决的问题，就是大模型特别容易“犯迷糊”，出现“幻觉”。

简单来说，就是它经常“答非所问”，同样一个问题，你问它十次，它能给你十个不一样的答案。

这产品的稳定性可就没法保证了，咱总不能让客户用产品的时候全凭运气吧，今天好用明天不好用，那不得把客户气跑了？

既然如此，我们在做产品的时候，就不能完全依赖大模型。

这就好比当年纯电车刚出来的时候，大部分人都有“里程焦虑”，就怕开着开着在高速上没电了，那可就尴尬了。所以啊，后来就出现了“增程式”电动车，既有电动的优势，又不用担心没电的问题。

同样的道理，现在大模型还没办法稳定输出答案，咱就得考虑用“大模型+工程”的方式来搞功能实现，这样才能让产品更靠谱！

二、大家都做“大而全”的产品，怎么选？

刚开始，我们用大模型来做产品，心里就盘算着，先从一个业务场景入手，就像玩拼图，先把这一小块儿弄明白了，总结出经验来，再去搞更多的业务场景，一块儿一块儿拼出个完整的大图。

结果，时间不等人。我们这边还在做一个细分业务，客户那边就反馈，已经有一家公司做了全场景的产品出来了。

咱这产品还没见着影儿呢，就已经被人家甩在后面，out得没边儿了。

起初，我也感到很焦虑，心里直犯嘀咕：别人都搞那种大而全的产品了，咱还有必要在这个细分场景上死磕下去吗？这不是往死胡同里钻嘛！

客户明显是更想要大而全的产品，毕竟，他关注的是全局，就想让宣传出去的东西看起来啥都有，倍儿有面儿

后面，在和某个客户的沟通中，我发现，站在他的工作视角，他压根就不关心我们做的产品覆盖的业务全不全，他只在乎自己负责的这块业务，用咱这产品做出来的效果好不好，能不能让他少操点心。

这下可好了，咱面前出现了两条产品选择的路：一条是走领导喜欢的“大而全”路线；另一条是走业务人员满意的“小而精”路线。

回归到做大模型产品的价值层面来思考，我找到了答案。

在我看来，大模型产品的核心价值就是提高工作效率，改变生产力的，所以，才会受到大家的追捧。

这类产品啊，它可没带来啥业务模式的创新，也不是政策逼着搞的“管理型”产品。它就是个实实在在的生产工具，就像工人手里的锤子、钳子一样。既然是工具，大家评判它好不好用的标准，就是看它能不能极大地提升生产效率。

那产品咋提升工作效率呢？

关键就看生成内容的准确率。准确率越高，大家用的时候就越省心，不用像改作文似的，这儿改改那儿改改。

在有限的资源下，咱有两个选择：要么做一个可以达到60分效果的“大而全”的产品；要么做一个在小部分场景下可以达到90份的“小而精”的产品。

这里有一个前提条件，就是没有经过调优训练的通用大模型，在某个垂直领域做出来能达到的效果就只有30～50分的水平。

这么一分析，从产品得有更强的生命力，能给客户带来更高使用价值的角度来看，咱就决定聚焦在小部分场景下，死磕准确率。

后来啊，经过产品之间的“大比拼”，还真证明咱选的方向是对的。

宣传造势那都是一时的，就像放烟花，看着热闹，一会儿就没了。产品好不好用才是决定性的，就像好酒不怕巷子深，只要产品好用，客户自然就来了。

三、客户就想要一个“对话框”，做不做？

有一回产品汇报的时候，友商给咱产品来了个“精准定位”：我们是“要素式”的方式获取答案，他们采用的是“问答式”的方式实现交互。

啥意思呢？

翻译一下：咱想做出一道色香味俱全的大菜（也就是准确度更高的文书），前期就得把各种食材（文书需要的要素）提前准备好，像切菜、备料一样把这些要素抽取出来。然后再把这些食材按照一定的顺序和方法组合起来，一句一段地炒出这道大菜。

那“问答式”交互又是咋回事呢？

简单来说，就是在系统里放个AI问答机器人，用户有啥问题，直接跟它说，它立马就给你答案

现在咱们用的Chat GPT、Deepseek、文心一言、豆包这些，不都有个问答输入框嘛，你想要什么就直接问，它就会给你答案。

就因为大家平时都习惯了用这些AI问答应用，所以我去问客户，需不需要在咱产品里也配个这样的问答机器人，大家那都是异口同声地说：要！

这下可好，又到了产品决策的“十字路口”：竞品都有这玩意儿，客户也想要，那咱到底做不做这个问答机器人呢？

先说答案：不做。

为什么这么一个大家都需要的功能，还是不做呢？

我就问了自己下面这三个问题：

1、用户真的就想要个问答工具吗？

其实不是，客户真正想要的是最后的结果，。问答只是个过程，只有当你给他的结果不准确的时候，他才有可能主动去提问。

2、用户用问答机器人的频率能有多高呢？

肯定高不了。

一方面，好多用户压根儿就不会提问，为啥呢？因为他们懒得思考，不想动脑子。

另一方面，要是问出来的答案不是他们想要的，他们大概率就不会再接着问了。而且，要是问出来的答案互相矛盾，那用户说不定就对咱这产品失去信任了。

3、咱去做这个问答机器人，能做好吗？

我觉得够呛。用户心里肯定会拿咱做的机器人和Deepseek、Chat GPT这些应用去对比，要是咱这机器人没有这些工具好用，那客户为啥不直接用开源的Deepseek呢，就像有更好的选择，谁还会用差的呢？

后来啊，从友商产品的使用数据来看，也证明了这一点。绝大部分用户几乎都不会去问这个所谓的“AI助理”。

四、客户啥都想“智能化”，怎么做？

我们做产品的原则是要追求准确率，在产品功能设计的时候，有些信息就得让用户手动输入，可不敢全指望大模型。

为啥呢？就怕大模型脑子一抽，输出个错误信息，那最终结果的准确率可就惨不忍睹咯。

就好比说，咱要从文件材料里把各种人物的姓名和角色给识别出来。这大模型有时候就跟个迷糊蛋似的，把A的角色安到B头上，把C的姓名写成D，这后面的产品流程还咋往下走啊，输出的结果肯定错得离谱

为了解决这个问题，咱就想了个简单粗暴的办法，让用户一开始就手动输入各种人物的姓名和角色，保证这些主体信息一点儿错都不出。

但是，哪怕就这么一个输入操作，很多客户就不愿意了。

因为，在大家的认知中，既然大模型都能直接生成文书了，那为啥一个小小的人物姓名和角色还得让我手填啊？

上面举的只是一个小例子，但它引出来个大问题：到底哪些功能该做成“智能化”的呢？

在做这个产品决策之前，咱得先明确一点，所有的智能化都不是百分百靠谱的，就跟天气预报似的，也有不准的时候，只是出错的概率大小不一样罢了。

我的决策思考是：要是通过大模型来实现某个功能，准确率达不到90%以上，那这个功能就别做成全“智能化”了。咱可以搞个“半智能”模式，一部分让大模型生成，再加上人工的增删改。

有人可能就问了，大模型有80%的准确度，这听着已经挺不错的了啊。

可你想想，哪怕有20%的错误，用户要去修改这些错误，可能就要增加40%的工作时间投入，这就间接抵消了大模型带来的80%的减负效果。

怎么判断这个准确率呢？

简单来说，就是通过大量的数据来测试验证。

但是，实际情况下，你可能没有那么多的数据，也没有那么多的时间给你去做这个验证。

还有一个简单的办法：咱看看这个业务场景有没有共性的地方，只要有规律，就能做成“智动化”。

就好比大家的身份证号码，那肯定是18位的数字加字母组成的，那身份证号就完全可以靠大模型去识别、抽取和填充。这“18位的数字+字母”就是个共性特征，直接做成规则就行。

不过呢，就算你找到了这个标准，在实际操作中，大家可能还有一些约定俗成的习惯。短期内，靠软件产品可没法做到全面改造，软件只能是个辅助工具，可别想着一下子就把旧习惯全颠覆了。

所以，稳妥的办法，还是做成智能辅助，不是“全自动驾驶”，而是辅助驾驶。降低了客户的预期，也就提升了产品的“安全性”！

最后的话

大模型应用产品的浪潮还在翻涌，我们只有不断思考、谨慎决策，才能在浪潮退去后，依然稳健前行，让产品真正为客户创造价值。