本文深入探讨了如何通过精确定义和匹配输出域与需求域，来提升大模型工具产品的市场适应性和用户粘性。通过具体的例子展示了如何将理论应用于实践，以及如何通过不断的迭代和优化来提高产品的市场适应性和用户粘性。
我的上一份工作是企业内部AI产品经理，类同市面上绝大多数的同行与前辈，在工作开始初期我围绕着完善知识库体系和搭建各个智能助手（agent）的方向开展了我的工作。
然而在工作中我发现无论是知识库还是智能助手都存在着刚上线时人头涌动，但上线一阵时间之后就无人问津的尴尬状态，由于我当时的绩效是由用户的AI使用渗透率与业务感知打分两者合一进行评估的，所以这个问题如果不解决，那么很有可能在一段时间后被解决的就是我了。
基于当时的压力，围绕着该问题我开始了调研，在对用户的访谈与各个助手使用记录的观测中我们发现：
让我们将这些问题带入到俞军老师的产品价值公式中：
哦，不对！不是这个而是下面这个，关于上面这个问题，我会在后续的分享中给出明确的产品定位思路，来破解上述的另一个困境。
我们可以很直观的看出，由于我们是无法改变旧体验的，那么AI在专业知识的类的具象问题，以及AI进行输出时的不稳定问题极大的损害了新体验，而prompt对AI使用的影响又极高的抬高了迁移成本，那么自然用户在使用一段时间后就会选择离开，这无可厚非。
想要做好大模型工具产品
基于上述的公式我们可以得到一个思路，想要做好大模型工具产品就需要尽力的稳定大模型产出，并且最简化prompt对于用户的学习成本，只有当任何人的首轮对话或者前三轮对话都能达成需求，即（以前置prompt框定）输出域=需求域（以场景页面信息框定）时产品价值才能真正的打动用户。
在使用这一思路后我对手头的产品功能进行了一轮改动，最终成功实现了产品上线后AI产品对全公司的渗透。
众所周知，我们目前的大模型本质上是一个概率分布的预测机，我尝试过在同一个大模型产品里创建几个不同的对话，然后输入同样的信息，得到的结果其实只能用大同小异这一结果来进行总结了，信息是不会出现太大偏差的，但是回答的方式回答的说法其实都是会有些许的差异的；
而这也就给了我们一定的空间，本质上既然它是一个不稳定的、存在一定随机性的输出模型，那么我们用针对性的单一结果去要求它或者说去以单一结果的视角去看待它来制作需求，这件事是不切实际且具有很大的局限性的。
既然如此，那么我们就应该在做需求的时候试图去用一种新的视角去看待它，并且围绕着这种视角去让它产生原本旧时代无法产生的业务效果，而以域的视角去看待就是这里的关键。
因为有信息或者固定的输入信息作为框定，所以它的回答通常在上下文相对完整时尤其是在微调后，输出是不会越出边界的，每一次的输出都是围绕着固定信息所产生出某一种可能，而这种可能的集合就是输出域。
在我们探讨需求域之前有一个前置概念是要明确好的，那就是用户在我们产品中的动作其实背后都是存在着一定的动机的，也就是我们产品经理口中的需求，而需求域的概念则是用户在使用该产品之前他对于信息的需求或者说对于模型输出内容的底层需求是宽泛的并非指定的。
在这里我以市面上常见的三种比较明确的大模型需求为例来阐述需求域的体验是如何在这些需求中的。
1）文案输出类产出需求：文案内容的输出通常是伴随着用户的指定背后产品需求的，以我之前的东家为例，在文案输出时用户心里的底层逻辑是希望大模型可以输出针对该商品在固定平台上面进行文案推广时使用，该需求的需求域是一个很明确的范围，即通过两条边
（1）文案输出的逻辑（平台用户喜好）
（2）商品自身信息两个线来框定的，前面我们有指出过在通用大模型上即便我们使用同样的prompt，让大模型生成10个对话其文案的重复率也不会太高，而这恰恰是电商推品的需求，用户不需要一成不变的答案，用户需要稳定的但又灵活的域式答案。
2）角色扮演类游戏需求：通常来说角色类需求的背后通常为对某一角色或者某一动作的交互模拟，不管其根源需求是情绪价值还是体验价值，以需求域的角度来看都是对于一个由初始设定与当前交互的常规回答（通用大模型中的概率回答）的两条边所拼凑而成的回答域，当然由于这里的交互通常都是比较开放的所以这条边足够长，导致了该域非常大。
3）知识转化类需求：在这里我将智能问答、常规模拟、概要提取等需求集合在这里，这个分类最大，究其原因是这类需求的本质都是对信息的加工处理，不论是各大搜索引擎的概要提取还是对某一类信息的客服问话，本质还是对输入信息进行附加逻辑后的转化输出，毫无意外在这里边界也很明显，信息主体加转述逻辑构成了此类需求的域。
从以上的例子中我们可以抽象出一个用户需求域的统一概念：1、有明确边界的 2、多样化或者说容错高的3、存在内部一致性（有不可变中心的）需要大模型输出此类内容的集合便是需求域。
我们现在有了输出域与需求域这一评定需求的概念，那么接下来我们需要考虑的就是怎么样能让输出域与需求域进行匹配了，对于这一问题的解我们可以根据现阶段大模型工作的一个方式来思考找到答案。
不知道大家对于初次接触gpt或者文心一言此类工具时觉得惊为天人的点是什么，对我而言惊为天人的是它可以与我进行多轮的对话，不同于早期的语音助手类的撞大运式对话，
这一次的AI在与我对话时让我感受到了一种与真人交互的流畅感。随着我自己参与到AI应用的制作后，我发现其实现阶段大模型所支持的这种连贯输出的技术方案其实极其简单粗暴，那就是将历史沟通的记录包起来加在当前对话中打包一起作为输入来进行续写输出。
从这个处理方式中我们可以得到一个信息，那就是在一个会话中，每一轮的对话都会收到前一轮对话的影响，而其中对后续沟通影响最大，最能够影响整个对话输出域的内容的毫无疑问就是从始至终会影响每一次问答的第一句话。
一个话题的第一句话无论是在与大模型的交互还是与人的交互中都是非常重要，其自身所起到的对后续对话的范围与深度的框定作用恰恰是需求域与输出域能否在初始阶段达成一致的关键。
试想一下如果我们将第一轮对话以一种最符合用户需求的方式去代替用户完成创建，将需求域和输出域进行了初始的最大化匹配的话，首先我们可以给用户一个可以接受的内容范围，并且后续不论用户是否拥有prompt等和大模型交互的经验，他们都可以通过极简单的自然语言在我们给到的输出结果上基础上进行修改，而这时的修改交互就无需任何的前置学习成本了，也就是完成了我们前面所提到的，用户价值中对替换成本这一值的减小。
我们之前的沟通中我们可以清晰一点，绝大多数的“域”通常都是由两个边界来进行框定的，而在我们现阶段以GPTS为首的各大大模型平台中，我们通常可以看到用户创建的大模型应用通常是单边的，既预制一个逻辑边的prompt作为框定，而另一条边是交给用户让用户在使用该应用时自然输出，以此来进行框定的。
不可否认在通用型平台上这么做是可以理解的，毕竟会主动来到大模型页面的人通常也都知道自己该如何提问，而且这样也开放了更多偏个性化问答域的可能。
但这样我们就不得不面对一个问题，那就是如果我们将该模型应用进行大范围推广的时候，我们的用户不再是大模型的爱好者，而是一个个希望尽快通过该工具完成自己的任务的用户时，这种开放式的方式就变得不再适用了。
因此，我们需要重新思考如何设计去让用户在首轮对话中完成对输出域的框定，并且完成产品自身输出域与用户需求域的匹配。
在这里可能会产生些疑问，用户自己希望和大模型聊些什么或者让大模型说一些什么，这是因人而异的，我们怎么能在用户进行讲述前将用户的需求发掘出来并进行取而代之呢？
对于这个问题，我想引用一下俞军老师的话来进行解答“用户的本质是需求的集合！”我们也许无法预知现实中朝夕相处的同学与家人下一秒会做什么动作，但是我们一定可以预知口渴的人一定会喝水，所以场景就是我们的最好帮手，毫无疑问前置页面就是我们预知当前用户对大模型需求域的预知手段。
在现阶段大多数人的思考方向都是如何让大模型通过调用接口来操控程序，但其实程序与大模型的关系只有后置这一种么？我认为用一个前置的页面或者现有的页面去调用模型的前置其实对于现阶段的产品设计更为重要。
以现在百家争鸣的大模型搜索为例，我们不难发现，整个需求的本质是一个将大批量信息进行总结压缩的过程，而这个总结过程是由用户自己筛选并且输入的prompt么？并不是，事实上在用户点击搜索框的搜索时，就已经由触发了由程序所发起的第一句问话，而这就是在用户不与大模型直接沟通的情况下由程序辅助完成第一轮问答来匹配输出域与需求域的示例。
在这个案例中，搜索框的存在帮助我们预测了接下里用户的需求，让我们能够在第一轮对话发起时，将用户所可能输入的无法控制的prompt，换成可控的调整好的prompt调用大模型，从而实现了用户需求的达成。
同样的这种通过前置页面精确控制输入的方法实际上可以带入到我们目前的很多种大模型工具之中，我接下来会以我工作中运用这种思路所做的两个工具需求为例，展示这种方式在文案输出、角色模拟、知识转化三类需求中的余下两类具象化应用。
1）文案输出：由于我上一家公司是一家品牌代理与平台销售一体的电商企业，所以内部的品牌部门实际上是需要大量的文案类内容来在各个平台上对商品进行曝光的，产品初期我们类同市面上绝大多数的文案助手将各个平台的文案风格等内容写成prompt包成agent然后开放给用户做对话使用，但实际的产出效果公司的同事们其实是不太买账的，至于具体的原因，我在文中的一开始已经提到了。
因此在思考好了要以前置页面作为首轮对话的发起的解题思路后，我们将公司旗下的某一个品牌的商品与花色进行了信息的前置整合，并且通过与现阶段公司发在各个平台的文案进行比对，确认了大模型输出文案时以什么样的逻辑输出和商品信息组合才能产出比较符合业务需求的文案后，敲定了文案中心的产品设计；
即以各个商品与花色制成表单给用户筛选，然后通过生成按钮触发prompt进行文案产出的交互方式，后续如若产出不满意，可以通过调整按钮跳转至对话页面让用户以自然语言与大模型交互去进行改正。
在进行了这样的改版之后可以预见的是我们让用户的使用成本大大的降低了，文案助手的平台并没有像之前上线一样仅仅被“宠幸”了几天就被弃如敝履，这次我们功的将AI工具渗透入了公司的生产环节之中，虽然没有达到主推品的文案级别需求，但是普通商品的日常曝光维护都由我们的文案助手完成了承接。
（由于我是之前给企业内部做AI改革的产品，所以商品的信息我可以通过erp自行的进行查看，但是这并不代表在通用C端或者B端的SAAS上无法实现，只需要给用户做一个便于录入的界面或者支持主流电商平台的信息导入，便可构建起用户自己的文案表单来控制第一次输入了。）
2）角色模拟：由于第一份工作是比较偏b端的原因，虚拟女友类的需求我并没有涉猎很多，但在我的工作中有一个与之比较相似的年终报告答辩助手的工具项目。
在制作这个需求时，由于我们已经知晓用户有着对自己年终述职报告不断模拟答辩的需求，并且也知道公司老板对某大厂的管理方法极为推崇的特点，我们在制作该需求时也并没有开放对话框，在每次对话的初始我们只提供了用户一个上传文件的入口并且配置了“方法论检视”“问答模拟”“文档修正”三个按钮，通过该方式触发各个对应的prompt开启对话，让用户在进入到聊天界面后直接就可以接收到对应的大模型输出，排除了有可能由于用户使用不当而有可能产生的问题。
当然该需求其实在我们实际测试时所产出的问题或者检视其实并不是特别的优秀，毕竟有关细化行业的问题从不是大模型的专长，但出人意料地是该助手在上线之后用户的使用频次非常高，直接完成了我们原定的通过年终大会的辅助工具完成AI助手对公司内部管理层的渗透任务。
本文由@Maru同学 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。