如何应用大模型 — 大模型使用范式

从OpenAI发布ChatGPT开始，大模型就开始受到大家关注，到DeepSeek-R1出现，大家的关注达到了顶峰，越来越多的企业，机构，学校，政府部门希望接入大模型，希望通过大模型来提升效率，赋能产业。但好像做来做去，要不就是客服、要不就是知识库、要不就是聊天，既没有新意，也没感受到太多的生产力，渐渐的大模型在一部分人的眼里就愈发像是一个昂贵的玩具。也有一部分看到了cursor，v0这样的产品，通过大模型的加持大幅提升了开发效率，甚至可以说没有大模型这样的产品压根就无法做出来。矛盾的双方出现了，我会简单就自己的理解来梳理，我们如何来应用大模型进行生产。

这篇文档尝试说明一个核心问题，大模型能怎么用。
注：这里讲的都指的是语言大模型，其他模态或多模态的大模型在应用范式上有一定相似性。

理解大模型

为了说清楚怎么使用大模型，我们先要理解大模型是个什么东西。大模型是一个知识丰富，能够理解和执行指令，有一定归纳和演绎能力，只能对话的类人。这是我对大模型的一个理解定义，让我们分别理解一下：

• 知识丰富：训练大模型基本要用上人类所有的数据，里面包含了几乎所有人类的知识结晶，大模型的知识丰富程度远超个人。
• 理解和执行、归纳和演绎：这是大模型区别于传统模型最大的特点，大模型能够理解你的问题，能够给出执行的步骤，能够针对内容进行归纳，甚至可以讲一些经验迁移到其他领域，进行延展。这些大家在使用各家开放的大模型产品进行聊天的时候多多少少都能感受到。
• 只能对话：这也是很多人对大模型的误区之一，大模型本身只能对话，它没法干除了对话以外的任何事情。大家看到的很多大模型能干这，能干那，那都是外部的系统帮大模型干的，大模型+系统才能完成这些工作。
• 类人：这里的类人并不是强调理解归纳这些特点，而是大模型整体体现出了输入的重要性，好的输入能够得到好的输出，就像是面对人一样。你的要求提的越准确，越具体，越有可操作性，去执行的人就越有可能得到你想要的结果。大模型也是这样。

大模型的使用范式

当我们对大模型有一个基础的理解之后，我们来看看都有哪些使用大模型的范式类型，这些都是我基于自身的经验进行的总结，可能有一定的局限性，希望跟大家多多交流。

交谈类型

交谈类型的使用方法是简单的，达到的目的就是与大模型进行交谈，得到大模型的反馈。
大家看到的kimi，豆包这类APP都是属于这个类型，随便聊，随便问，怎么说大模型都能够有所反馈。
这个类型的系统构建方式也最简单：把用户的问题直接给到大模型

在这种构建方式下，我们如果想要对大模型生成的结果进行干预，主要的方式就是修改这个问题，比如：增加一些背景知识、增加一些格式要求、增加一些身份设定。

这其实就是RAG的思想，很多大模型chatbot网站允许用户自己建立AI角色，实际就是这种类型，这种类型下已经能做出很多有意思有娱乐属性的chatbot了。
一些copilot产品底层也是基于这种范式

如果我们想更进一步，让这个过程更有生产的能力，那我们可以在附加内容上再做文章，比如附加内容可以是搜索引擎、是系统查询出的统计数据、或者是上传的一个文档

这样我们就可以轻松的打造具有业务属性的对话大模型，已经能够满足很丰富的业务场景了

总结一下这种类型的优缺点
优点：

• 本质还是与大模型一对一的对话，因此响应效率高，回复块
• 能够与业务快速对接，快速落地
• 门槛低，大家都能玩

缺点：

• 无法做一些很深入的内容
• 准确程度也受限

任务类型

任务类型与交谈类型的主要区别在于是否由大模型来进行任务分解以及指挥系统执行。
区别于交谈类型的一问一交互形式，任务类型在界面上还是进行一次提问，但后面系统则需要与大模型进行多次交互，其中最重要的就是由大模型规划任务完成的路径。大模型规划好路径之后，由系统逐步去执行，最后再由大模型汇总结果给出答案。

这种形式肉眼可见的复杂，且与大模型有多次交互，适合由大模型独立执行一些复杂的任务。

在这个基础上，可以加上大模型对每一步结果的检查和后续步骤的修正，让整个过程更加的准确。

此类应用范式也被称为agent或者智能体。这里面说的步骤大多数情况下会对应到一个API上，可能是URLAPI也可能是本地调用API，但通常都需要这个API来完成步骤中规划的操作。

在此基础上，我们甚至可以让多个具有思考能力的大模型相互写作，共同完成任务，其中有一个大模型承担任务分配的角色，将用户的问题拆分成若干个任务或角色，设定好目标，由不同的大模型智能体完成不同的任务，过程中他们还能沟通，通过将自己的过程输出交给对方来让对方调整自己的计划。

这就是通常提到的多智能体。

Cursor就是这类范式非常典型的产品，包括值卡很火的斯坦福小镇。

总结一下这种类型的优缺点
优点：

• 能够完成复杂的任务
• 准确度较高，但受限于大模型本身的能力，通常结果会有一定瑕疵

缺点：

• 门槛很高，一方面需要强大的业务抽象能力，另一方面对于系统搭建的能力要求也很高。
• 成本高，这个成本主要体现在后面的大模型交互上，一个对话后面可能要很多次的与大模型交互
• 场景受限，这种类型并不能像交谈类型那样什么都能回答，而是由自己的业务限制，后面搭建的智能体所能拥有的能力都是预置好的，并不能实时添加。
• 交互很慢，基本上一个问题或命令下去，需要等待很久。

工具类型

这类其实是大家经常忽视的一种类型，但我觉得是大模型落地非常重要的一种类型，可以说这才是让大模型走进各个行业的标准范式。
这个类型总结下来就一句话：让大模型在已有的工作流程中替换原本无法由机器执行的模糊型任务。
这种类型的起点可能就不是客户了，可能原本就是某个业务的工艺流程，只不过原先这个工艺流程中有一部分需要复杂决策，或者需要灵活判断，无论是专家系统还是硬编码都无法满足，通常这里就会中断，由人来进行这种操作或者决策。那现在这部分就可以由大模型来把系统串起来，无需再有中间的中断等待。

比如：一个软件产品发版，经过了CICD的过程，部署到了测试环境中，通常这个时候我们需要中断，等待测试工程师进行测试，即使有了自动化测试，依然需要人工来进行测试结果的整理，判断测试结果是否有效，是否需要重测，问题如何归类、确定优先级及分派，再把这些信息录入到禅道，jira这类跟踪管理软禁中。有了大模型，人工整理的这一步就完全可以由大模型系统来处理。以后可能就能做到下班前提交集成构建，晚上自动进行构建、部署、测试、分拣、录入等工作，第二天大家晨会就能拿到测试报告，BUG也做好了指派，大家的开发完全没有思维上的gap，延续性高，自然研发效能就得到了提升。

总结一下这种类型的优缺点
优点：

• 重塑传统的工作流程，往往会发挥意想不到的效果，传统流程的场景通常都是经过验证，试错成本低
• 在落地层面可以做出差异化，并且能快速产生效果
• 准确度最高，因为范围受限，可以让大模型专注的处理某一类业务

缺点：

• 会受固化思维的影响，场景并不好开拓
• 不太容易跟风吹牛，大模型是手段，不是目的，很可能黑盒之外无法感知到大模型的存在

结语

上面三种类型并不是分裂独立的存在，我们完全可以将上面三种类型进行组合来完成更为复杂的目标。
其实工具模式可以认为已经组合了前两种，只不过我觉得他也很重要，值得拿出来单独说说。

如果大家有自己的观点或者想要交流沟通，可以留言，期待与大家的沟通交流。