提示词工程核心技术：从Few-shot到ReAct，构建稳定AI应用

1. 从“咒语”到“工程”：为什么我们需要系统化的提示词技术

如果你最近在折腾大语言模型，不管是 ChatGPT、Claude 还是开源的 Llama、Qwen，你肯定有过这样的经历：你问了一个问题，模型给的答案要么是车轱辘话来回说，要么就是完全跑偏，离你想要的差了十万八千里。这时候你可能会想，是不是我“问”得不对？于是你开始尝试换一种说法，加一些限定词，甚至把问题拆成好几步。恭喜你，你已经无意识地踏入了“提示词工程”的领域。

但提示词工程远不止是“换个说法问问”这么简单。它已经从早期用户摸索的“玄学咒语”，演变成了一套有方法论、有最佳实践、甚至有设计模式的系统性技术。为什么需要这么复杂？因为大语言模型本质上是一个基于概率的、极其复杂的函数。你输入的提示词，就是调用这个函数的“参数”。参数给得模糊，函数的输出自然就飘忽不定；参数给得精准、结构清晰，模型才能稳定地输出高质量、符合预期的结果。今天，我们不谈那些零散的技巧，而是深入拆解六个在专业场景下被反复验证、能显著提升模型表现的核心技术：Few-shot、思维链、函数调用、ReAct 以及自洽性。掌握它们，你才能真正从“碰运气”的用户，转变为能稳定驾驭模型的“工程师”。

2. Few-shot：给模型“打个样”，告别模糊指令

Few-shot Learning，直译是“少样本学习”，在提示词工程里，它的核心思想非常简单：通过提供少量的输入-输出示例，让模型理解并模仿你想要的任务格式和风格。这比单纯用文字描述任务要求要有效得多。

想象一下，你是一个新来的助理，老板让你“整理一下会议纪要”。这个指令非常模糊：是要逐字记录？还是要提炼要点？用什么样的格式？如果你一头雾水，很可能交出一份不符合要求的报告。但如果老板先给你看了三份他满意的、格式统一的过往会议纪要示例，你立刻就能明白他想要的是什么。Few-shot 提示就是在给大语言模型做同样的事情。

2.1 Few-shot 的核心价值与适用场景

它的价值在于对齐认知。人类的语言充满歧义，同一个词在不同语境下含义不同。例如，“总结”这个词，可以是一句话概括，也可以是分点罗列。通过示例，你明确地告诉了模型：“看，像我给的例子这样去处理类似的输入。”

它特别适用于以下场景：

1. 复杂格式输出：当你需要模型生成特定结构的数据，如 JSON、XML、特定标记的文本、表格等。纯文字描述格式容易出错，示例是最直观的。
2. 风格迁移：例如，将口语化内容改为正式公文，或将技术文档改为科普风格。示例能完美定义“风格”。
3. 分类与标注任务：定义新的、非标准的分类类别。比如，从客服对话中识别“情绪激动但未辱骂”、“咨询产品规格”、“请求转人工”等自定义类别。
4. 代码生成：要求模型按照特定代码风格（如特定的函数命名规范、注释格式）生成代码。

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 的优势与实现挑战

优势：

1. 可解释性强：每一步的Thought都揭示了模型的“心路历程”，便于调试和信任。
2. 纠错能力强：如果某次Action得到了意外或无效的Observation，模型可以在下一个Thought中识别并调整策略（例如，“刚才搜索的结果不相关，我应该换一个关键词”）。
3. 适合复杂任务：对于需要多步信息检索、筛选、计算和合成的任务，ReAct 框架提供了清晰的路径。

挑战与注意事项：

1. 提示设计复杂：需要精心设计示例，教会模型遵循Thought-Action-Observation的格式，并在适当的时候结束循环。
2. 上下文消耗大：整个推理和行动历史都会保留在上下文中，对于长序列任务，可能很快耗尽模型的上下文窗口。
3. 依赖可靠的工具：如果工具（如搜索、API）不稳定或返回错误信息，会直接导致整个链条失败。需要为工具层设计重试和错误处理机制。

6. 自洽性：用“投票”机制提升答案可靠性

自洽性是一种用于减少模型随机性错误和“幻觉”的后处理技术。它的概念非常直观：对于同一个问题，让模型生成多个不同的推理路径和答案，然后从中选择出现频率最高的那个答案作为最终输出。

这背后的直觉是，虽然模型在单次生成中可能会因为随机采样而“跑偏”，但正确的答案或推理模式往往在多次生成中更稳定、更一致。错误则更具随机性。

6.1 自洽性的具体操作方法

它通常与思维链结合使用，称为“自洽思维链”。步骤如下：

1. 多次生成：使用同一个 CoT 提示，让模型独立生成N次（例如，N=5 或 10）。由于模型生成具有随机性（除非温度设为0），每次的推理过程和最终答案都可能略有不同。
2. 提取答案：从每一次生成的文本末尾，提取出最终的答案（例如，一个数字、一个选项字母、一个实体名称）。
3. 多数投票：统计所有答案中，哪个答案出现的次数最多。
4. 选择最终输出：将得票最多的答案作为最终答案。有时，为了可解释性，也会输出得票最高的那个答案所对应的完整推理链。

示例（小学数学题）：问题：一个水池有一个进水管和一个出水管。单开进水管，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: 光在真空中的速度大约是每秒299，792，458米。 用户：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 起售价是多少？”时，模型会进行如下推理：

1. 分析问题类型：涉及“最新发布”，这很可能是 2024年7月之后的信息，属于需要实时信息的类型C。
2. 选择工具：必须使用search_web。
3. 生成结构化请求：

   Thought: 用户询问的是苹果公司最新iPhone的起售价，这是一个需要获取最新市场信息的问题，我必须使用网络搜索。 Action: search_web Action Input: Apple latest iPhone release starting price USD

4. 系统执行搜索并返回结果后，模型再合成最终答案。

通过这样一个精心设计的提示系统，我们就能构建出一个行为相对稳定、可控、能力边界清晰的 AI 助手原型。这比直接问“苹果手机多少钱”要可靠得多。