1. 从“咒语”到“工程”为什么我们需要系统化的提示词技术如果你最近在折腾大语言模型不管是 ChatGPT、Claude 还是开源的 Llama、Qwen你肯定有过这样的经历你问了一个问题模型给的答案要么是车轱辘话来回说要么就是完全跑偏离你想要的差了十万八千里。这时候你可能会想是不是我“问”得不对于是你开始尝试换一种说法加一些限定词甚至把问题拆成好几步。恭喜你你已经无意识地踏入了“提示词工程”的领域。但提示词工程远不止是“换个说法问问”这么简单。它已经从早期用户摸索的“玄学咒语”演变成了一套有方法论、有最佳实践、甚至有设计模式的系统性技术。为什么需要这么复杂因为大语言模型本质上是一个基于概率的、极其复杂的函数。你输入的提示词就是调用这个函数的“参数”。参数给得模糊函数的输出自然就飘忽不定参数给得精准、结构清晰模型才能稳定地输出高质量、符合预期的结果。今天我们不谈那些零散的技巧而是深入拆解六个在专业场景下被反复验证、能显著提升模型表现的核心技术Few-shot、思维链、函数调用、ReAct 以及自洽性。掌握它们你才能真正从“碰运气”的用户转变为能稳定驾驭模型的“工程师”。2. Few-shot给模型“打个样”告别模糊指令Few-shot Learning直译是“少样本学习”在提示词工程里它的核心思想非常简单通过提供少量的输入-输出示例让模型理解并模仿你想要的任务格式和风格。这比单纯用文字描述任务要求要有效得多。想象一下你是一个新来的助理老板让你“整理一下会议纪要”。这个指令非常模糊是要逐字记录还是要提炼要点用什么样的格式如果你一头雾水很可能交出一份不符合要求的报告。但如果老板先给你看了三份他满意的、格式统一的过往会议纪要示例你立刻就能明白他想要的是什么。Few-shot 提示就是在给大语言模型做同样的事情。2.1 Few-shot 的核心价值与适用场景它的价值在于对齐认知。人类的语言充满歧义同一个词在不同语境下含义不同。例如“总结”这个词可以是一句话概括也可以是分点罗列。通过示例你明确地告诉了模型“看像我给的例子这样去处理类似的输入。”它特别适用于以下场景复杂格式输出当你需要模型生成特定结构的数据如 JSON、XML、特定标记的文本、表格等。纯文字描述格式容易出错示例是最直观的。风格迁移例如将口语化内容改为正式公文或将技术文档改为科普风格。示例能完美定义“风格”。分类与标注任务定义新的、非标准的分类类别。比如从客服对话中识别“情绪激动但未辱骂”、“咨询产品规格”、“请求转人工”等自定义类别。代码生成要求模型按照特定代码风格如特定的函数命名规范、注释格式生成代码。2.2 如何构建有效的 Few-shot 示例构建示例不是随便扔几个例子进去就行这里面有讲究示例的选择要具有代表性你提供的例子应该覆盖任务可能遇到的主要情况或边界情况。例如如果你在做一个情感分析示例应该包含正面、负面、中性以及那些带有讽刺、难以判断的复杂语句。示例的格式必须严格一致输入和输出的格式、分隔符如Input:Output:###必须完全一致。模型会极度依赖这些模式。不一致的格式会严重干扰模型。示例的数量并非越多越好通常 2-5 个高质量示例就能达到很好的效果。过多的示例会消耗大量上下文窗口Token增加成本有时甚至可能引入噪声。关键在于质量而非数量。一个具体的例子假设我们需要模型将用户查询转换为标准化的 API 搜索参数。糟糕的单指令提示将用户的问题转换成搜索关键词。 用户我想找附近评价不错的川菜馆。模型可能回复“搜索关键词川菜馆 附近 评价好”。这个结果不结构化无法直接使用。有效的 Few-shot 提示请根据以下示例将用户查询转换为JSON格式的搜索参数。 示例1 用户查询 “北京明天天气怎么样” 输出 {intent: query_weather, parameters: {location: 北京, date: 明天}} 示例2 用户查询 “播放周杰伦的七里香” 输出 {intent: play_music, parameters: {artist: 周杰伦, song: 七里香}} 示例3 用户查询 “我想找附近评价不错的川菜馆” 输出在这个结构清晰的示例下模型几乎必然能输出{intent: search_business, parameters: {category: 川菜馆, sort_by: rating, location: nearby}}注意Few-shot 示例会占用上下文令牌。对于超长上下文模型如 128K这问题不大但对于 4K 或 8K 的模型需要精打细算确保示例本身简洁高效。3. 思维链让模型“把思考过程说出来”思维链是提示词工程领域的一次重大突破。它的核心指令是“让我们一步步思考”。其原理是通过要求模型在给出最终答案前先展示其推理的中间步骤可以显著提升其在复杂推理、数学计算和常识问题上的准确性。为什么这有效对于多步推理问题直接要求答案相当于让模型执行一个复杂的“端到端”计算容易出错。而 CoT 将这个过程分解相当于让模型先解决子问题再整合。这更符合模型序列生成的工作方式也降低了每一步的认知负荷。3.1 CoT 的两种主要实践方式1. 零样本思维链这是最简单的应用。直接在问题后加上Let‘s think step by step.或其变体如“请逐步推理”。对于许多逻辑和数学问题这能产生立竿见影的效果。示例问题一个篮子里有5个苹果你拿走了2个又放进去3个梨最后篮子里有多少个水果 让我们一步步思考。模型可能会输出首先篮子里最初有5个苹果。 然后拿走了2个苹果剩下 5 - 2 3个苹果。 接着放进去3个梨。现在篮子里有苹果和梨两种水果。 水果的总数是剩下的苹果数加上放进去的梨数3个苹果 3个梨 6个水果。 所以最后篮子里有6个水果。2. 少样本思维链这是 Few-shot 与 CoT 的结合。你不仅给出输入和输出还在输出中详细展示推理步骤。这是最强大、最稳定的方式。示例数学应用题示例 问题小明有15元钱一个面包3元一瓶牛奶5元。他买了一个面包和一瓶牛奶后还剩多少钱 分步解答 1. 计算购买面包和牛奶的总花费3元 5元 8元。 2. 从小明原有的钱中减去总花费15元 - 8元 7元。 所以小明还剩7元钱。 现在请回答新问题 问题书店举行促销每买3本书送1本。小华买了12本书她一共能拿到多少本书 分步解答在这个清晰的示例引导下模型会模仿“分步解答”的格式进行推理。3.2 CoT 的进阶技巧与局限自动 CoT对于没有明确要求 CoT 的模型你可以尝试在系统提示中植入“你是一个严谨的助手在回答复杂问题前总是喜欢先一步步推理”这样的角色设定有时也能诱导出链式思考。局限性CoT 并非万能。它主要对需要逻辑、数学、分步规划的问题有效。对于纯粹的事实性问答、创意写作或格式转换CoT 可能没有帮助甚至会产生冗余信息。此外模型有时会产生“幻觉推理”即推理过程看起来合理但基于错误的前提或计算导致错误答案。这就需要我们下面要谈的“自洽性”来纠偏。4. 函数调用让模型学会“使用工具”函数调用是构建 AI 应用特别是智能体的基石。它的模式是用户提问 - 模型分析需求 - 模型决定是否需要调用外部函数/工具 - 如果需要则输出结构化的调用请求 - 系统执行函数 - 将结果返回给模型 - 模型整合结果并生成最终回答。这解决了大模型的两个核心短板1)知识截止性模型不知道最新信息如今天天气、股价。2)缺乏执行能力模型无法直接操作数据库、发送邮件、执行计算等。4.1 函数调用的工作流程详解以一个“查询天气并建议穿衣”的智能体为例第一步定义工具函数开发者需要向模型描述可用的工具。这通常是一个 JSON Schema 列表。[ { “name”: “get_current_weather”, “description”: “获取指定城市的当前天气情况” “parameters”: { “type”: “object”, “properties”: { “location”: { “type”: “string”, “description”: “城市名如‘北京’、‘San Francisco’” }, “unit”: { “type”: “string”, “enum”: [“celsius”, “fahrenheit”], “description”: “温度单位” } }, “required”: [“location”] } } ]第二步用户提问与模型决策用户输入“旧金山现在冷不冷需要穿外套吗” 模型会分析这段文本。它识别出“天气”是核心需求并且有具体的城市“旧金山”。于是它决定调用get_current_weather函数。第三步模型生成结构化调用请求模型不会直接说“去查一下天气”而是输出一个严格符合定义格式的 JSON 对象{ “function”: “get_current_weather”, “arguments”: { “location”: “San Francisco”, “unit”: “celsius” } }这个输出是可解析、可执行的。第四步系统执行与返回你的应用程序接收到这个 JSON调用真实的气象 API如 OpenWeatherMap获得结果{“location”: “San Francisco”, “temperature”: 14, “unit”: “celsius”, “condition”: “Partly cloudy”}第五步模型合成最终答案你将这个真实数据返回给模型。模型结合原始问题和天气数据生成最终回答 “旧金山现在气温14摄氏度局部多云。这个温度对于很多人来说会感觉有点凉特别是晚上或有风的时候。建议带一件薄外套或针织衫出门。”4.2 设计函数描述的关键点函数的description和参数的description至关重要。模型完全依赖这些文本来理解何时以及如何调用函数。描述要清晰、无歧义说明函数做什么在什么场景下使用。参数描述要具体说明参数期望的格式和含义。好的描述能极大减少模型误调用。处理好“不需要调用函数”的情况很多对话是纯聊天不需要工具。模型需要能正确判断。这通常通过在对话历史中展示正反例来训练。实操心得在测试阶段一定要模拟各种边缘查询。比如用户问“我该穿什么”没有地点。这时一个设计良好的模型应该能识别信息缺失并主动追问“请问您在哪里我需要知道地点才能查询天气并给您穿衣建议。” 这需要通过精心设计的示例对话来教导模型。5. ReAct推理与行动的协同框架ReAct 框架是对思维链和函数调用的一个优雅整合。它的名字来源于Reasoning推理和Action行动。其核心思想是让模型交替进行思考推理和行动调用工具并将两者的历史都记录在上下文中形成一个完整的决策循环。为什么需要 ReAct单纯的函数调用模式中模型可能做出武断的决定。而 ReAct 强制模型在行动前先“想一想”解释为什么要采取这个行动这提高了决策的透明度和准确性尤其是在需要多步工具调用的复杂任务中。5.1 ReAct 的标准流程与示例ReAct 提示通常会给模型规定一个严格的输出格式例如Thought: [模型在此分析当前情况、已知信息、下一步该做什么] Action: [要调用的工具名称如 search calculator] Action Input: [调用工具所需的输入必须是字符串] Observation: [工具执行后返回的结果] ...这个循环可以重复多次... Thought: 我现在有足够的信息来回答问题了。 Final Answer: [最终的回答]让我们看一个复杂查询的例子任务“埃隆·马斯克创办的第一家公司卖了多少钱这笔钱按今天的汇率换算成人民币是多少”在一个集成了搜索引擎和计算器的 ReAct 智能体中对话可能如下进行用户埃隆·马斯克创办的第一家公司卖了多少钱这笔钱按今天的汇率换算成人民币是多少 Thought: 用户问了两个有联系的问题。首先我需要找出埃隆·马斯克的第一家公司是什么以及它卖了多少钱。这需要搜索。然后我需要知道卖出时的货币是什么并查询当前对该货币的汇率最后进行计算。 Action: search Action Input: “Elon Musk first company sale price” Observation: [搜索引擎返回] 埃隆·马斯克的第一家公司是 Zip2一家网络城市指南公司于1999年以大约3.07亿美元的价格卖给了康柏公司。 Thought: 我找到了第一个信息Zip2售价3.07亿美元时间是1999年。货币是美元。现在我需要将3.07亿美元1999年的美元价值换算成今天的人民币。但这涉及两个问题1. 1999年的3.07亿美元相当于今天多少美元通货膨胀调整2. 再将调整后的美元金额按当前汇率换算成人民币。或者用户可能只关心当前汇率换算。为了准确我应该先确认“按今天的汇率换算”这个指令的含义。通常这意味着忽略通货膨胀直接用当前汇率计算历史金额。我应该先查询当前美元对人民币的汇率。 Action: search Action Input: “current USD to CNY exchange rate” Observation: [搜索引擎返回] 1美元 ≈ 7.25人民币实时汇率可能有波动此为示例。 Thought: 当前汇率大约是1:7.25。现在我需要计算3.07亿美元按此汇率换算成人民币是多少。这需要计算器。 Action: calculator Action Input: 307000000 * 7.25 Observation: 2225750000 Thought: 计算结果是22.2575亿人民币。我可以整理信息给出最终答案了。 Final Answer: 埃隆·马斯克创办的第一家公司是 Zip2于1999年以约3.07亿美元的价格出售。如果按当前汇率1美元≈7.25人民币计算这笔钱大约相当于**22.26亿人民币**。5.2 ReAct 的优势与实现挑战优势可解释性强每一步的Thought都揭示了模型的“心路历程”便于调试和信任。纠错能力强如果某次Action得到了意外或无效的Observation模型可以在下一个Thought中识别并调整策略例如“刚才搜索的结果不相关我应该换一个关键词”。适合复杂任务对于需要多步信息检索、筛选、计算和合成的任务ReAct 框架提供了清晰的路径。挑战与注意事项提示设计复杂需要精心设计示例教会模型遵循Thought-Action-Observation的格式并在适当的时候结束循环。上下文消耗大整个推理和行动历史都会保留在上下文中对于长序列任务可能很快耗尽模型的上下文窗口。依赖可靠的工具如果工具如搜索、API不稳定或返回错误信息会直接导致整个链条失败。需要为工具层设计重试和错误处理机制。6. 自洽性用“投票”机制提升答案可靠性自洽性是一种用于减少模型随机性错误和“幻觉”的后处理技术。它的概念非常直观对于同一个问题让模型生成多个不同的推理路径和答案然后从中选择出现频率最高的那个答案作为最终输出。这背后的直觉是虽然模型在单次生成中可能会因为随机采样而“跑偏”但正确的答案或推理模式往往在多次生成中更稳定、更一致。错误则更具随机性。6.1 自洽性的具体操作方法它通常与思维链结合使用称为“自洽思维链”。步骤如下多次生成使用同一个 CoT 提示让模型独立生成N次例如N5 或 10。由于模型生成具有随机性除非温度设为0每次的推理过程和最终答案都可能略有不同。提取答案从每一次生成的文本末尾提取出最终的答案例如一个数字、一个选项字母、一个实体名称。多数投票统计所有答案中哪个答案出现的次数最多。选择最终输出将得票最多的答案作为最终答案。有时为了可解释性也会输出得票最高的那个答案所对应的完整推理链。示例小学数学题问题一个水池有一个进水管和一个出水管。单开进水管4小时可注满水池单开出水管6小时可放完满池水。如果同时打开进水管和出水管多少小时可注满水池模型生成5次假设温度0生成1...计算得出需要12小时注满。答案12生成2...计算得出需要12小时注满。答案12生成3...计算中犯了算术错误得出需要5小时注满。答案5生成4...计算得出需要12小时注满。答案12生成5...计算得出需要12小时注满。答案12统计答案“12”出现4次答案“5”出现1次。最终答案12小时。6.2 自洽性的代价与权衡自洽性通过“集思广益”显著提升了复杂推理任务的准确性但它并非没有成本。主要代价是计算成本和延迟生成N个响应意味着需要调用模型N次这直接带来了N倍的计算开销Token 消耗和响应时间。对于实时性要求高的应用这可能不可接受。实践建议关键任务使用在医疗、法律、金融等对准确性要求极高的场景或是在评估模型基准性能时值得使用自洽性。调整生成参数可以通过提高采样温度来增加生成结果的多样性从而让“投票”更有意义。但温度太高也可能导致所有答案都发散。与置信度结合除了简单投票还可以分析不同生成结果中推理链的一致性。最一致的推理链所对应的答案可能比简单票数最高的答案更可靠。不是万能药如果问题本身模糊或者模型在训练数据中对这个问题存在系统性偏见那么多次生成可能会一致地输出同一个错误答案。自洽性无法纠正这种系统性错误。7. 技术融合实战构建一个多功能查询助手纸上得来终觉浅。现在让我们把这些技术融合起来设计一个简单的“多功能查询助手”的提示系统。这个助手能处理事实问答、计算和实时信息查询。我们将设计一个系统提示它定义了助手的角色、可用工具函数以及工作要求融合了 Few-shot 和 ReAct 思想。你是一个智能查询助手可以回答用户的问题。为了提供最佳答案请遵循以下流程 1. **分析问题**首先判断用户问题的类型。主要类型有 - A. 通用知识/事实问答例如“珠穆朗玛峰有多高” - B. 数学计算例如“计算 125 的平方根” - C. 需要实时信息的问题例如“纽约现在几点”“特斯拉当前股价” 2. **选择工具**根据问题类型决定是否需要使用工具以及使用哪个工具。 - 对于类型A优先使用你自身的知识回答。如果问题涉及非常近期的事件2024年7月之后或非常小众的知识你无法确定则使用 search_web 工具。 - 对于类型B使用 calculator 工具。 - 对于类型C必须使用 search_web 工具。 3. **输出格式**你必须严格按照以下格式输出。 - 如果**不需要使用工具**直接以“Answer:”开头给出最终答案。 - 如果**需要使用工具**请按如下格式输出 Thought: [解释你为什么需要这个工具以及你需要查询什么] Action: [工具名称只能是 search_web 或 calculator] Action Input: [给工具的输入查询字符串必须简洁明确] 在我返回工具执行结果Observation后你再基于结果生成最终答案以“Answer:”开头。 4. **示例** 用户光速是多少 你Answer: 光在真空中的速度大约是每秒299792458米。 用户3456除以128等于多少 你 Thought: 这是一个精确的数学计算问题需要使用计算器工具。 Action: calculator Action Input: 3456 / 128 用户侧程序执行计算返回 Observation: 27 你Answer: 3456 除以 128 等于 27。 用户今天法国巴黎的天气如何 你 Thought: 这是一个需要实时信息的问题我必须使用网络搜索工具来获取最新天气。 Action: search_web Action Input: Paris France weather today 用户侧程序执行搜索返回 Observation: 今天巴黎晴气温12-18摄氏度微风 你Answer: 根据最新信息法国巴黎今天天气晴朗气温在12到18摄氏度之间有微风。 现在请开始回答用户的问题。这个系统提示融合了多项技术Few-shot提供了三个清晰的示例A/B/C 三种类型定义了输出格式。ReAct 框架规定了Thought-Action的循环结构要求模型先推理再行动。函数调用思想定义了search_web和calculator两个“工具”并描述了它们的用途。角色与规则设定明确了任务类型判断逻辑指导模型决策。当用户提问“苹果公司最新发布的 iPhone 起售价是多少”时模型会进行如下推理分析问题类型涉及“最新发布”这很可能是 2024年7月之后的信息属于需要实时信息的类型C。选择工具必须使用search_web。生成结构化请求Thought: 用户询问的是苹果公司最新iPhone的起售价这是一个需要获取最新市场信息的问题我必须使用网络搜索。 Action: search_web Action Input: Apple latest iPhone release starting price USD系统执行搜索并返回结果后模型再合成最终答案。通过这样一个精心设计的提示系统我们就能构建出一个行为相对稳定、可控、能力边界清晰的 AI 助手原型。这比直接问“苹果手机多少钱”要可靠得多。