[0:00]不知从什么时候开始，很多简单的事情都得换一个高级的说法，卖东西叫分销，挣钱叫变现，写文章叫内容输出，拉人进群叫私域引流。 就连AI写代码也得有个新词叫Vibe Coding，人们总是倾向用高级的词汇来掩盖内容的匮乏。 今天我们来聊几个AI时代的流行词，提示词、提示词工程、上下文，以及那个宣称可以把提示词工程踩在脚下摩擦的上下文工程。 大语言模型刚出现的时候，主要就是一个聊天机器人，用户说你好，大语言模型可能会回复我很好，你呢。 经过几年的发展，AI的能力已经远远的超过了普通的聊天机器人，但聊天依然是AI最核心也是最实用的功能之一。 在聊天这个场景下，用户说的你好就叫做Prompt，中文翻译过来就是提示词。 所以提示词最基本的定义就是用户发给AI的话，对于我很好，你呢，这种四平八稳的回答，虽然能满足大多数人在多数情况下的期望，但这也就注定这种回答将会是干巴巴的，毫无特色的。 所以即使只是聊天，也可以用上一些聊天技巧嘛，比如说我们可以用提示词给AI设定一个角色。 举个例子，你跟他说，你来扮演一个猫娘，接下来我说你好，这个时候AI就可能回复，我很好，你呢，喵。 把这种玩法推向极致的一个软件，叫做SillyTavern。 为了保证这集视频不被和谐，这里我就不展开多说了，有兴趣的朋友可以自己去搜一下。 但是问题来了，你扮演猫娘这种设定并不是用户对话内容本身，把这种设定和用户真正想说的话混在一起，不仅容易出戏，逻辑上也有点乱。 所以大模型的厂商们就把提示词分成了两部分，像你扮演一个猫娘这种设定叫做System Prompt，也就是系统提示词。 而用户说的你好则叫做User Prompt，也就是用户提示词。 我们平时在聊天框里输入的，就是用户提示词，而系统提示词呢，通常是聊天机器人内置的，用户一般不能直接修改。 不过很多AI应用也提供了一些功能，可以间接地影响系统提示词，比如在ChatGPT里面有一个叫做Customize ChatGPT的功能，可以设定一些用户的个人偏好。 这些信息最终就会成为系统提示词的一部分，从而影响ChatGPT的输出内容。 这种通过系统提示词和用户提示词的组合，来引导AI返回特定风格回复的做法就叫做提示词工程，Prompt Engineering。 当然了，提示词工程可不只是用来玩角色扮演的，它最核心的目的是通过一系列技巧来约束AI的行为，让它的回复更加稳定，减少错误和意外。 下面我们就来介绍几种常见的技巧。 比如说AI不太擅长处理数学问题，在让他解数学题的时候就比较容易做错。 这个时候我们就可以要求它在回复前仔细的检查，确保它的答案是正确的。 再比如说，有时候AI会拒绝回答我们一些问题。 这个这时候你就可以在提示词中告诉AI这件事情的严重性，于是AI就会偏向于输出更加完整的答案了。 这些都属于行为的约束，像这种只提要求，但是不给AI模型具体例子的技巧，还有一个专门的叫法叫做Zero-Shot。 与此对应的就是Few-Shot，这种方法是只用户可以在提示词里面，先给AI几个具体的例子当做参考。 比如说我希望AI帮我把正常的句子转换成猫娘体，我就可以在提示词里面先举例，比如说我们去吃饭吧，转化成我们去吃饭好不好呀，喵。 我写了一个程序，转化成我把程序撸好了，喵。 给出范例之后，我们再提出真正的需求，现在来转化这个句子，亲爱的，我买了包包送给你。 这样AI就会根据我们提供的例子，给出更贴近预期的答案了，比如说回复，亲爱的，我抓了老鼠送给你，喵。 Few-Shot这个技巧在要求AI返回特定格式的场景下会特别的有用，比如说当我们写一个AI应用或者AI Agent的时候，通常需要AI稳定的返回带有某种格式的字符串。 这种场景下用Few-Shot就非常的合适，如果有朋友想了解AI Agent是什么，可以参考这两期视频。 或者我的知识星球，我会分别从原理和编程实现，讲明白AI Agent到底是怎么回事。 链接我会置顶在评论区，除了Zero-Shot和Few-Shot，还有一种更加玄学的技巧，叫做思维链，Chain-of-Thought，简称CoT。 举个简单的例子，我们问AI一道数学题，1+2*3等于多少？ 因为大语言模型本质上是一个概率模型，他其实并不擅长做精的数字运算，对于这种问题，尤其是早期的模型上，精度是比较低的。 这个时候我们就可以在问题后面多加一句话，比如说不要先给出答案，请一步一步的拆解问题，并且给出每一步的中间结果。 收到这个指令之后，AI的回复就可能变成了，根据运算优先级，第一步需要先计算2乘以3，结果是6，然后它再计算1加6，最终结果是7。 虽然模型本身是没有变的，但我们通过提示词引导它一步步思考，然后再输出，最终算对的概率就会大大的提升，这就是所谓的思维链。 当然了，我们举的这个例子有点过于的简单了，即使不用思维链，AI基本也不会算错，而且如今的网页版聊天机器人，大多数都内置了，比我们这个例子强大得多的思维链功能，不再需要用户手动输入额外的提示词了。 但它们背后的原理都是一样的，都是通过提示词让AI自己分解问题，输出推理过程，从而解决更复杂的问题。 总结一下，所谓的提示词工程，本质上就是通过精心设计，我们向AI提问的方式，来获得更精准、更符合我们预期的回答。 再聊上下文和上下文工程之前，我们首先要澄清一个事实，AI模型本身是没有记忆的。 这意味着每次我们给AI发送一个消息，对他来说都是一次全新的、独立的请求。 但很显然，我们在进行连续对话的时候，是需要AI记我们聊过什么的，否则对话就无法成立了呀。 那么这个记忆到底是怎么实现的呢？其实在我们和AI聊天的时候，并不是直接把消息发送给大语言模型的。 用户和AI之间还隔了一个AI Agent，或者聊天机器人的服务器，正确的流程是这样的。 用户把消息先发给AI Agent或者聊天机器人服务器，聊天机器人呢，会把消息发送给AI模型的同时，还会保留下完整的历史记录。 然后当他收到一条新的用户消息的时候，他会把这条消息附加到历史记录的末尾，最后再把这个包含了所有过往信息的完整历史记录，一起发给AI模型。
[7:13]这样一来，AI模型本身是失忆的，但他每一次收到的信息都是完整的对话，所以看上去就像有了记忆一样。 这个被一次性发给AI的完整的历史记录，就叫做上下文Context，而如何管理和修改这段历史记录的技巧，就被叫做上下文工程Context Engineering。 那么这个上下文到底有什么好管理的呢？其实，如果AI只是一个简单的一问一答形式的聊天机器人，那我们之前的提示词工程基本就够用了。 因为在那种一来一回的对话中，用户总有机会通过新的提示词来修正和引导AI的行为，确保他的回答不会跑偏。 但是AI Agent的出现让情况变得复杂了起来，AI Agent除了传递消息，维护历史之外，他还拥有一个工具箱，里面有一些他自己定义的工具，可以供AI模型来调用。 如果你觉得AI Agent它的概念有点复杂，我们还是以网页版聊天机器人来举例。 许多网页版聊天机器人提供了网页浏览功能，这种聊天机器人本质上就是一个简单的AI Agent，而浏览网页就是它提供的一个工具。 比如说当用户问猫娘的口头禅是什么？ 这个时候聊天机器人就会把当前的上下文连同它能使用的所有的工具说明，一起都打包发送给AI模型。 AI模型收到消息之后，就会发现工具箱里面有一个用于浏览网页的工具可以用，于是他可能会决定不直接回答用户的问题，而是先用Google搜索一下，搜索猫娘的口头禅是什么。 此时AI模型就会返回一个特殊的指令，叫做ToolCall，这个指令大意就是帮我访问这个Google网址，搜索猫娘的口头禅是什么？ 聊天机器人收到指令之后，就会去调用访问网页的工具，访问网页的工具就会去访问Google，返回网页的内容。 接下来网页的内容会被打包成一条ToolResponse消息，和对应的ToolCall一起放到上下文之中。 而这个变得更长的上下文，会被重新地发给AI模型。 这个时候AI可能还觉得信息还是不够，又想去萌娘百科里面再查一下，于是就又重复了一次刚才的那个过程。 上下文里面因此又多出了一对ToolCall和ToolResponse，对于比较复杂的问题，在AI生成最终答案之前，这样的一来一回可能会重复几十甚至上百次，上下文就会变得特别特别的长。 这里请注意一下，在这个漫长的探索过程之中，用户能施加的影响只有在最开头的那一句提示词。 而后续几十次ToolCall和ToolResponse不仅数量多，而且像是浏览网页这种ToolResponse内容通常也非常的长，比如说包含了一篇上万字的文章。 不难想象，当AI模型面对一个越来越长，充斥着各种中间信息的上下文，而用户又没办法及时的纠正他的行为的时候，他的行动方向就很容易跑偏，忘记自己到底要干什么。 所以如何通过一套程序化的规则来自动的管理和修改这个上下文，确保AI在漫长的自主行动中，始终符合用户的最初要求，这就是上下文工程要解决的核心问题。 很可惜的是，关于上下文到底要怎么管理，目前还没有一个公认的完美方案。 不过这里我可以介绍几种在业界比较常见，比较有效的做法。 第一招，让AI学会记笔记，它的原理类似于我们之前提到的网页浏览工具。 不过这次我们再给AI模型提供一个专门用来记笔记的工具，当AI在处理任务的时候，如果想要记下一些关键信息，就可以调用这个工具。 当然了，只提供工具，然后让AI自由的发挥记笔记，效果一般都不会太好，所以我们还需要在系统提示词里面明确地给出笔记的使用策略。 比如说我们可以这样指导模型，一，在行动前先将任务分解，二，在笔记中写下你的任务清单，三，严格根据任务清单来执行任务，四，每完成一项就在笔记中更新该项的状态。 这样一来，当AI再拿到猫娘的口头禅是什么这个任务的时候，大模型自己就会先头脑风暴出一个任务清单，比如说一，用Google搜索猫娘，二，用萌娘百科搜索猫娘，三，综合两次的搜索结果总结出口头禅。 然后AI就会通过之前我们介绍的ToolCall方法，调用记笔记的工具，让Agent把这个清单记录下来。 现在我们来看一下整个上下文是什么样子，里面包含了最开始的系统提示词和用户提示词，还有AI调用记笔记的ToolCall和ToolResponse。 其中的ToolResponse一般不会包含什么有用的信息，只是告诉AI笔记更新成功了。 而这里最关键的一步来了，这个被保存的笔记会被Agent插入到整个上下文的开头或者结尾，这个插入的位置其实也是有讲究的。 因为现在的大语言模型普遍采用的是Transformer架构，而这种架构天生就对输入信息的开头和结尾部分特别的敏感。 所以即使上下文变得非常长，无论AI中间执行了多少次ToolCall和ToolResponse，开头结尾的信息也基本不会被模型忽略，写着核心目标的任务清单和最初的提示词，始终都处在最显眼的位置。 当AI完成一项任务，比如用Google搜索猫娘，它又会根据系统提示词的指示，再次调用记笔记的工具，把第一项任务标记为已完成，然后开始执行第二项。 通过这种方式，就能很大的程度上保证AI在执行复杂的任务的时候不会跑偏。 当然了，笔记里面也不仅限于记录任务的清单，比如说我们还可以通过系统提示词，让AI记录搜索出的关键信息，便于后续进行总结等等。 但无论记录什么，这项技术的本质都是人类用户通过控制最初的提示词，来指导AI如何写笔记，再通过把笔记放到上下文中最显眼的位置，来间接引导整个AI的处理流程。 那么既然上下文太长是问题的根源，另一个优化的方向就是让它变短。 最直接的做法就是直接丢掉太老的消息，只保留新的消息。 当然了，最开始的系统和用户提示词部分是必须要保留的，不然AI就不知道自己要干什么了。 如果你觉得直接舍弃信息这种方式太暴力了，可能会丢失关键的内容，那么还有一种更加优雅的做法，就是压缩。 许多Agent会把较老的消息提取出来，然后让AI模型去总结其中的关键信息，再用这个精炼的总结去替换掉原来的上下文，从而达到压缩的目的。 除了这些，还有更高级的压缩方法，某些ToolResponse可能会非常的长，比如说包含了一篇上万字的文章。 这个时候Agent就会先把ToolResponse的内容处理后，存到一个临时的向量数据库里面，这个过程就类似我们之前讲过的RAG技术。 RAG的知识可以回顾我做的这一期视频，链接我会置顶到评论区。 文章存入之后，Agent就会修改这次的ToolResponse不再包含原文，而是用一句话来代替，比如说文章已经存入知识库，我为你提供了一个新的工具，叫做query_document，你可以用它来查询文章的片段。 然后AI模型就只要查找自己感兴趣的片段就可以了。 这样一来，一个几万字的ToolResponse就被压缩成了一句几十个字的指令，和一些AI主动查出来的片段，上下文的长度就得到了很大的控制。 还有一种方法是直接优化工具的返回值，比如说对于网页浏览工具，Agent可以先去掉网页里面不必要的HTML标签，只把最核心的内容返回给AI模型，从源头就减少信息的冗余。 当然了，这里我提到的只是几种比较常见的上下文管理方法。 这是一个非常热门的AI应用研究方向，新的研究和技术也在不断的涌现之中。 总而言之，无论是我们前面聊的记笔记，还是刚刚所说的减少上下文长度的各种方法，所有所有的一切目的都只有一个，在人类用户无法实时干预AI行动的时候，确保AI模型始终都记得自己最初的任务是什么。 小学的时候，老师问我们长大以后想做什么，当时我在作业本上写下的答案是当老师，因为我觉得他们是超人啊，什么都懂，什么都能讲的明明白白的，也不知道老师当时花了多少心思，到底用了什么神奇的方法，过去了十几年，我现在依然还记得。 这里是程序员老王，我们下期再见。
