Prompt_Engineering-深度理解:提示词工程

1- 深度理解:提示词工程

原创 lencx 浮之静

本文虽长但不啰嗦,内含大量细节,值得细品。若对你有所帮助,可在文末适当赞助或分享给更多朋友。这将是对我最大鼓励和支持,感恩 🙏!

最近,一份 68 页的 Google 提示词工程(白皮书)及译本在社区疯传。为系统性学习,我以此为框架,花费数日拓展大量知识点,整理形成本文。

注:原 PDF 后半部分是关于编程的,对普通人并不友好(有些混乱),我对其删减重写,整理出 " 最佳实践 ",绝对干货!

原 PDF 我放在 GitHub 上,需要的朋友可自行下载 [Google_Prompt_Engineering_v7][1]。本文还参考了 [Prompt Engineering Guide][2]、 [GPT-4.1 Prompting Guide][3]、[VertexAI - Introduction to prompting][4] 等内容。

之前写的 OpenAI 发布 GPT-4.1 系列,助力开发 中也有一些 prompt 技巧可供参考。

1.1- 前言

本文示例以 Gemini 模型为主,但所述方法和技巧适用于其他 AI 大模型(如 GPT、Claude 等)。

在使用大语言模型(LLM)时,其输入和输出之间的交互由提示词(prompt)驱动。这些提示词可以是文本(有时也包括图像等其他模态输入),模型据此预测特定的输出。你不需要掌握数据科学或机器学习 —— 任何人都可以写提示词。然而,打造一个高效的提示词并不简单:所用的模型类型、模型训练数据、模型配置、措辞风格、结构组织、上下文背景等因素都会影响效果。因此,提示词工程是一个迭代过程。不合适的提示词会导致模型输出模糊、错误,甚至无法生成有意义的内容。

在与 Gemini 等聊天机器人互动时,你其实就是在进行提示词的编写和优化。但本白皮书更关注通过 [Vertex AI][5] 平台或 API 直接调用模型时的提示词设计,因为此类方式可直接配置模型参数(如 Temperature、Top-P 等)。

本文将深入探讨提示词工程的方方面面,介绍各种提示技巧,帮助你快速入门,并分享成为提示词专家的实战经验与最佳实践,同时也会讨论编写过程中可能遇到的挑战。

📌 Vertex AI

Vertex AI 是一个机器学习平台,允许你训练和部署机器学习模型及 AI 应用,同时也能定制大语言模型,使其能够应用于你的 AI 驱动的产品中。Vertex AI 将数据工程、数据科学和机器学习工程的工作流程进行了整合,使得团队能够使用统一的工具集协同合作,并利用 Google Cloud 提供的优势来扩展你的应用。

目前在 [VertexAI Model Garden][6] 上有 200 多个模型可供选择,如 Google 自家的(Gemini、Imagen 3、Chirp、Veo)、第三方模型(如 Anthropic Claude 模型系列)以及开放模型(Gemma、Llama 3.2、DeepSeek-V3 等)。

1.2- 提示词工程(Prompt engineering)

大语言模型的本质是预测引擎。它接收一段顺序文本作为输入,然后基于训练数据预测下一个最可能出现的 token。模型每次预测一个 token,并将其追加至输入序列末尾,再预测下一个 token。每个 token 的预测都依赖于前文的上下文和训练中学到的模式。

当你写提示词时,其实就是在设法引导模型输出正确的 token 序列。提示词工程的目标,是设计出能驱动模型产生准确输出的高质量提示词。这通常需要不断调试,包括优化提示词长度、语言风格与结构,以适配任务目标。在自然语言处理(NLP)和 LLM 应用场景中,提示词即模型生成响应或预测所依赖的输入。

提示词可应用于多种任务,如文本摘要、信息抽取、问答、文本分类、语言或代码翻译、代码生成、代码文档生成或推理等。

你可以参考 Google 发布的提示词编写指南([Gemini for Google Workspace Prompt Guide [2024]][7]、[Google Cloud - Introduction to Prompting [2023]][8]),其中包含简单有效的提示词示例。

提示词工程的第一步是选择模型。不同模型(如 Vertex AI 中的 Gemini、GPT、Claude、开源的 Gemma 或 LLaMA)对提示词的适配需求各不相同。

除了提示词内容,还需要调试模型的各类配置参数。

1.3- LLM 输出配置(LLM output configuration)

选定模型后,就要了解其配置选项了。大多数 LLM 提供丰富的参数,控制输出生成的方式。有效的提示词工程离不开对这些参数的合理设置。

1.3.1- 输出长度(Output Length)

输出长度即模型响应中生成 token 的数量。输出 token 越多,模型计算开销越大,响应时间越慢,成本越高。

需要注意的是,缩短输出长度并不会让模型 " 写得更简洁 ",它只是在达到指定长度后停止生成。如果你想获得短内容输出,还需要通过提示词引导模型尽早收敛。

在某些提示词技巧中,限制输出长度尤为重要,比如 [ReAct][9] 技法中,模型容易在目标输出后继续生成冗余内容。

📌 ReAct

在人工智能(AI)领域,传统方法通常将推理和行动视为两个独立的过程,推理侧重思考问题,行动则侧重执行解决方案。然而,ReAct 方法创新性地将推理与行动融合在一起,创建了一个更加动态和高效的解决问题方式。ReAct,即 “Reasoning and Acting”(推理与行动)的简称,结合了推理过程和任务执行,确保每个行动都基于推理,每个推理也可能引发有意义的行动。这一方法通过一个简单而强大的循环:思考、行动、观察和适应,模拟了人类的解决问题行为。

1.3.2- 采样控制(Sampling Controls)

LLM 并不是 " 预测一个确定 token",而是对所有可能的下一个 token 给出概率分布,然后从中采样决定最终输出。控制采样方式的关键参数包括 temperature、top-K 和 top-P。

1.3.2.1- Temperature(温度)

temperature 控制采样的随机性(范围:0-1)。值越低,输出越确定;值越高,结果越多样、越随机。temperature = 0 代表贪婪解码(greedy decoding),总是选取概率最高的 token。

值得注意的是,当多个 token 拥有相同最高概率时,即使 temperature 为 0,结果也可能不完全一致,取决于具体实现中的平局处理策略。

Gemini 模型中的 temperature 与机器学习中的 softmax 函数类似。低温度意味着偏向确定输出,高温度则允许更多不确定性,适用于需要创造性结果的场景。

注:temperature 参数常见于大模型 API 调用,在 [Google AI Studio][10] 之类的在线调试沙盒中也可设置。

📌 Softmax function

Softmax 函数是一种在深度学习中广泛使用的激活函数,它主要应用于神经网络的最后一层,作用是将网络输出的原始分数(即 logits)转换为可以解释为概率的数值分布。具体来说,Softmax 函数会对输入的每个元素进行指数运算,从而确保所有运算后的结果均为正数;随后,它将每个指数值与所有指数值之和做归一化处理,使得每个归一化后的值都处于 0 到 1 的区间内,并且所有输出值的和等于 1。这样的特性使得 Softmax 特别适合用于多分类任务,在诸如图像识别、自然语言处理和推荐系统等领域中得到了广泛应用。

假设神经网络需要对一幅图像进行分类,该图像中可能包含树、房子和汽车等对象。网络的最后一层会生成一个包含这些类别对应原始分数的向量,这些分数可能并不直接反映每个类别的概率。经过 Softmax 函数的处理后,这个向量便会转化为一个概率分布,其中每个数值清楚地表示图像中出现 " 树 “、” 房子 " 或 " 汽车 " 等对象的概率。这种转换对于模型而言非常重要,因为它不仅使得输出具有概率意义,还使得后续的误差计算(例如与交叉熵损失函数结合)以及模型调优过程更加直观和高效。

以下 GIF 是 [Transformers (how LLMs work) explained visually][11] 视频中的片段,很直观展示了 Softmax 函数的工作。


交叉熵([Cross-Entropy][12]):交叉熵损失(或称为对数损失)用于衡量分类模型性能,其输出为介于 0 到 1 之间的概率值。当预测的概率与实际标签相差越大时,交叉熵损失也会随之增加。例如,当实际观测标签为 1 时,如果模型预测的概率仅为 0.012,那么损失值会非常高。理想情况下,一个完美的模型其对数损失为 0。

下图展示了在真实观测(例如 isDog = 1)的情况下可能获得的损失值范围。当预测概率逐渐接近 1 时,对数损失会缓慢降低;而当预测概率降低时,对数损失会急剧上升。对数损失不仅惩罚各种错误,更对那些有信心但错误的预测施加了更严厉的惩罚!

交叉熵(cross-entropy)和对数损失(log loss)在不同的语境中可能存在一些细微的区别,但在机器学习中,当计算错误率时,两者通常会归结为同样的计算方式。

1.3.2.2- Top-K 和 Top-P

Top-K 和 Top-P(又称核采样,nucleus sampling)控制采样时 " 候选 token 池 " 的范围:

  • Top-K:从概率最高的前 K 个 token 中采样。K 值越高,输出越丰富,越低则越稳重、趋于事实性。K=1 相当于贪婪解码(greedy decoding)。
  • Top-P:从累计概率不超过 P 的 token 中采样。P 值从 0(极度确定)到 1(考虑全部 token)不等。

实践中,你可以尝试这两种方法(或同时使用)来观察哪种更适合你的任务。

1.3.2.3- 参数协同调优(Putting it all together)

在深度生成模型的世界里,temperature、top-K、top-P 以及生成 token 数量构成了一套精妙而敏感的调控系统,它们的相互配合决定了模型输出的风格与质量。如果一个平台同时提供 temperature、top-K 和 top-P 参数,你可以把它们视为守门员。模型首先通过 top-K 与 top-P 的双重筛选,锁定一批候选 token,而后在这群候选者中再通过 temperature 的调制,决定最终的命运——这一步骤就像是在精心调制一杯鸡尾酒,既要保留风味的层次,又不能失控地飘忽不定。如果只启用了其中一项筛选机制,那么模型的决策过程则会显得单一而直接;而当没有 temperature 参数时,候选 token 随机抽取出的那一刻,便失去了微调的余地,仿佛只剩下了命运的硬币抛掷。

在极端设定下,这些参数的微妙平衡会被打破:当 temperature 调整至 0 时,所有精细选择瞬间失去意义,模型变得如同铁板一块,只选择最高概率的 token;反之,若 temperature 设置得极高(比如在 1 以上直至数值飙升至 10),那种混沌的随机性使得模型仿佛进入了狂欢模式,而 top-K 与 top-P 则仅仅成为了粗略的筛选手段。类似地,当 top-K 被压制至 1 时,其它参数都将黯然失色,因为只有唯一的 token 能够通过重重筛选;而当 top-K 数值飙至整个词汇表的规模时,任何概率非零的 token 都能通过考验,彻底失去了筛选的意义。top-P 参数也是如此:极低的 top-P 值几乎只允许最高概率的 token 存活,而 top-P 越接近 1,则所有微小的概率都将参与角逐。

对于输出风格的调控,我们通常给出一些建议以达成既定目标:若期望生成的文本既严谨连贯又带有适度创造性,temperature 可设在 0.2,top-P 定为 0.95,top-K 则设为 30;若渴求作品充满奇思妙想,那么可以将 temperature 提升到 0.9,top-P 调整为 0.99,而 top-K 则为 40;若想要较少创造性,可将 temperature 设为 0.1,top-P 设为 0.9,top-K 设为 20;而如果任务要求答案精确无误(如数学问题求解),那么直接将 temperature 设为 0,确保输出绝对确定。然而,随着这些参数的 " 自由度 " 增大,虽然能激发创造力,但也很容易导致输出内容走偏,甚至失焦。

更需警惕的是那令人头疼的 " 重复循环 bug"——模型在生成过程中可能陷入一种死循环,不断重复相同的词汇、短语甚至句型,如同被困在时间的漩涡中。低温度下模型会固执地走那条高概率路径,一旦路径中出现自我重复,就会陷入循环;而在高温度下,那种大杂烩式的随机性又可能无意中重新回到先前的状态,同样引发无限循环。解决这一难题,往往需要在 temperature、top-K 与 top-P 之间找到一个微妙的平衡点,就如同调音师在各种音符间斟酌,唯有精细调整,才能奏出和谐而富有变化的乐章。

1.3.2.4- 小结

temperature、top-K、top-P 与输出 token 数量之间互相影响,参数设置需要结合具体应用目标,并充分理解模型如何组合这些参数:

  • 若 temperature = 0,top-K 与 top-P 会被忽略。
  • 若 top-K = 1,同样忽略 temperature 与 top-P。
  • 若 top-P 接近 0,模型通常只选取最高概率的 token,其他设置也被忽略。

推荐初始值(通用型场景):

  • 中等创造力:temperature = 0.2,top-P = 0.95,top-K = 30
  • 高创造力:temperature = 0.9,top-P = 0.99,top-K = 40
  • 低创造力:temperature = 0.1,top-P = 0.9,top-K = 20
  • 精确任务:temperature = 0,top-P = 任意,top-K = 任意(默认可用)

1.4- 提示技巧(Prompting techniques)

大语言模型(Large Language Models, LLMs)经过海量数据训练与指令调优,已具备理解用户提示(Prompt)并生成回应的能力。然而,LLMs 并非完美,其输出质量很大程度上取决于输入提示的清晰度和精确性。提示越明确,模型预测后续文本的准确性就越高。此外,掌握并运用一系列针对 LLMs 训练方式和工作原理设计的特定提示技巧,能显著提升获取相关、高质量结果的可能性。

理解了提示工程的基本概念和重要性后,让我们深入探讨几种最关键、最常用的提示技术。

1.4.1- 基础提示 / 零样本 (General prompting / Zero-shot)

零样本提示(zero-shot)是最基础、最直接的提示形式。它仅包含对任务的描述,有时会附带少量引导性文本供模型开始生成,而不提供任何具体的示例(" 零样本 " 由此得名)。输入可以多种多样,例如一个问题、一个故事的开头或是一段操作指令。

  • 应用场景:适用于模型已通过预训练掌握、相对简单或常见的任务。
  • 关键点:对提示的清晰度和任务描述的准确性要求较高。

这里使用 Vertex AI Studio 作为测试平台,用表格方式记录对电影评论进行分类的零样本提示。这种结构化的记录方式对于追踪和迭代提示工程工作至关重要。在实际应用中,对于分类这类任务,设置较低的 " 温度(temperature)" 参数有助于获得更稳定、一致的预测结果,因为任务本身不需要太高的创造性。但需注意:像 disturbing(令人不安)和 masterpiece(杰作)这样的词出现在同一句中,会使模型的判断稍显复杂。

当零样本提示效果不佳,或需要模型输出遵循特定格式或风格时,就需要引入包含示例的提示技术。

1.4.2- 单样本 & 少样本提示 (One-shot & Few-shot Prompting)

在提示中提供示例是引导模型理解任务意图和期望输出格式的有效手段。

  • 单样本提示 (one-shot):提供一个完整的任务示例(输入 + 期望输出)。模型通过模仿这个范例来完成新的、类似的任务。
  • 少样本提示 (few-shot):提供多个(通常建议 3-5 个或更多,视任务复杂度和模型能力而定)任务示例。通过展示一系列输入和对应期望输出的模式,模型能更准确地学习并遵循这种模式。
  • 关键考量
    • 示例质量:示例必须高质量、准确无误且具有代表性。一个微小错误都可能会误导模型。
    • 示例多样性:涵盖不同情况,特别是边缘案例(edge cases),有助于提升模型处理各种输入的健壮性(robust)。
    • 示例数量:需在提供足够信息引导模型与避免超出模型输入长度限制之间取得平衡。

以下表格展示了一个少样本提示的例子,通过多个示例引导模型进行特定类型的文本生成或分类。注:我们继续使用之前的 gemini-pro 模型配置设置,仅增加 token 限制,以容纳更长的响应内容。

1.4.3- 系统、上下文与角色提示 (System, Contextual, and Role Prompting)

这三种提示都在引导 LLM 的行为,但侧重点不同,也可相互结合。先说结论:系统提示设定全局规则,角色提示塑造个性与风格,上下文提示提供即时具体信息。三者常结合使用,形成精细化控制模型输出的有力框架。

1.4.3.1- 系统提示 (System Prompting)

  • 目的:设定模型的宏观行为框架、核心任务或总体约束。如同给模型安装了一个 " 操作系统 " 或设定了基本 " 规则 "。
  • 应用:定义模型的基本功能(如 " 你是一个翻译助手 ")、强制输出特定格式(如 JSON)、设定安全或风格基调(如 " 回答需保持尊重 ")。
  • 优势:有助于模型生成满足特定结构或规范要求(如 API 对接需要的 JSON 格式)的输出,限制不必要的发散(幻觉),并实施安全控制。

以下表格展示了如何通过系统提示指导模型输出特定结构(如列表、JSON),即使提高创造性(温度)设置,明确的结构指令也能约束输出。

1.4.3.2- 角色提示 (Role Prompting)

  • 目的:为模型分配一个特定的身份或角色(如 " 扮演一位经验丰富的旅行顾问 “、” 模拟一位幼儿园老师 ")。
  • 应用:使模型生成符合该角色知识背景、口吻和行为风格的回应。可以指定具体的风格,如:对抗性(confrontational)、描述性(descriptive)、直接(direct)、正式(formal)、幽默(humorous)、有影响力(influential)、非正式(informal)、鼓舞人心(inspirational)、有说服力(persuasive)等。
  • 优势:极大提升输出的相关性、专业性和特定情境下的适切性(贴合度/契合度)。

以下表格展示了让模型扮演旅行顾问,并进一步要求其采用幽默和鼓舞人心的风格。改变角色设定(如地理老师)会得到截然不同的回应。

1.4.3.3- 上下文提示 (Contextual Prompting)

  • 目的:提供与当前对话或具体任务紧密相关的背景信息、细节或约束条件。它是动态的,随交互过程变化。
  • 应用:帮助模型理解当前请求的细微差别,精确把握用户意图,从而生成更贴切、更个性化的回应。
  • 优势:使 AI 交互更流畅高效,模型能更快理解请求并生成准确相关的答案。

以下表格展示了提供上下文信息如何帮助模型生成更精确的回应。

1.4.4- 后退提示 (Step-back Prompting)

  • 核心思想:在直接解决特定、复杂问题前,先引导 LLM 思考一个与该问题相关的、更宏观或基础性的问题。然后,将模型对这个宏观问题的回答(或思考过程)作为上下文,再输入到针对具体问题的提示中。
  • 机制:这种 " 退一步 " 的做法有助于激活 LLM 内部更广泛的相关知识和推理路径,引导模型进行更深入、更系统的思考,而不是直接跳到具体细节。
  • 优势
    • 提升复杂问题回答的准确性和深度。
    • 鼓励批判性思维和知识的创造性应用。
    • 可能有助于减少因过于关注细节而产生的偏见。

以下是一个传统提示词,它可能导致模型随机或泛泛的回答。

当把温度设置为 1 时,可能会得到各种创意写作的故事情节,但这也相当随机和普通。所以让我们先 " 退一步 " 来思考相关主题。

再将这些主题作为上下文融入原提示,最终获得了更具体、更有趣的游戏情节构思。

1.4.5- 思维链(CoT: Chain of Thought)

CoT 由 [Wei et al. (2022)][13] 引入,通过设置中间推理步骤让模型具备复杂的推理能力。你可以将其与少样本提示结合使用,以在需要先行思考再给出答案的更复杂任务中获得更好的效果。

  • 核心思想:显式地引导 LLM 在给出最终答案前,生成一系列中间推理步骤,模拟人类解决问题的思考过程。
  • 应用:尤其适用于需要逻辑推理、计算或多步骤规划的任务(如数学题、复杂问答、代码生成规划)。常与少样本提示结合以获得更好效果,尽管零样本 CoT 也有一定应用。
  • 优势
    • 提升准确性:分解复杂问题,减少直接猜测导致的错误。
    • 可解释性:展示模型的 " 思考 " 过程,便于理解其逻辑,发现潜在错误。
    • 鲁棒性 (robustness):使用 CoT 的提示在不同模型版本间表现可能更稳定。
    • 易于实现:无需模型微调,对现有 LLM 效果显著。
  • 劣势:增加成本与延迟。生成更多中间文本,意味着消耗更多计算资源和时间。

以下表格展示了 LLM 直接回答数学问题可能会出错。

以下表格通过零样本 CoT 指示模型 " 分步解释 ",得到正确答案。

以下表格展示了结合单样本的 CoT,通过示例进一步规范推理过程。

思维链可用于各种用例。想想代码生成,用于将请求分解为几个步骤,并将这些步骤映射到特定的代码行。或者用于创建合成数据,当你有一些种子信息时,比如 " 产品名为𝑋𝑌𝑍,根据给定的产品标题,写一个描述,引导模型完成你会做的假设 "。通常,任何可以通过 ’ 逐步阐述 ’ 来解决的任务都是思维链的好候选者。如果你能解释解决问题的步骤,就试试思维链。

可参考 GitHub 笔记,了解更多 [prompts/chain_of_thought_react.ipynb][14]

1.4.6- 自洽性(Self-consistency)

该方法由 [Wang et al. (2022)][15] 提出,旨在 " 取代思维链提示中使用的简单贪心解码 "。其核心理念是通过少样本思维链提示(few‑shot CoT)采样多条多样化的推理路径,然后利用生成的结果来选择最为一致的答案。这有助于提升思维链提示在算术和常识推理等任务上的表现。

  • 核心思想:一种增强 CoT 的技术。它不是只生成一条思维链(通常基于 " 贪婪解码 " 策略,选择每一步最优的词),而是通过多次采样(通常设置较高的温度参数)生成多条不同的思维链(推理路径)。最后,通过多数投票的方式,选出最常出现的最终答案。
  • 机制:利用了 " 条条大路通罗马 " 的思想,认为正确的答案更有可能通过多种不同的推理路径得出。
  • 优势
    • 进一步提升准确性:比基础 CoT 更鲁棒,尤其在复杂推理任务上。
    • 提供一种答案置信度的近似估计。
  • 劣势:成本高昂。需要多次运行模型,计算开销显著增加。

以邮件分类为例,说明对于包含模糊、讽刺信息的复杂输入,单次 CoT 可能结果不稳定。通过多次生成 CoT 并选取多数答案(如 " 重要 "),可以得到更可靠的分类结果。

1.4.7- 思维树提示 (Tree of Thoughts, ToT)

对于需要探索或策略性前瞻的复杂任务,传统或简单的提示技术往往难以胜任。[Yao et el. (2023)][16] 提出了 " 思维树 "(Tree of Thoughts, ToT)框架,该框架是对思维链(chain‑of‑thought)提示方法的推广,旨在鼓励对作为通用问题求解中间步骤的 " 思想 " 进行探索。

ToT 会维护一棵 " 思想树 ",其中的每个 " 思想 " 都代表一段连贯的语言序列,作为解决问题的中间步骤。这种方法使语言模型能够在解决问题的过程中,通过有意的推理步骤自我评估所取得的中间进展。随后,模型生成和评估 " 思想 " 的能力会与搜索算法(例如广度优先搜索和深度优先搜索)相结合,从而实现带有前瞻和回溯的系统化思想探索。

  • 核心思想:对 CoT 的进一步泛化和扩展。CoT 遵循单一线性思维链,而 ToT 允许 LLM 同时探索多个不同的推理路径,形成一个 " 思维树 "。模型可以在树的不同节点上评估中间 " 想法 " 的价值,并决定扩展哪些分支,或回溯到更有希望的路径。
  • 机制:维护一个由 " 想法 "(连贯的文本序列,代表解决问题的中间步骤)组成的树状结构。模型可以进行广度或深度优先的探索,并使用评估机制(可能由 LLM 自我评估或外部反馈)来指导搜索。
  • 优势:特别适用于需要广泛探索和复杂规划的任务,传统线性推理难以解决。

以下图表对比了 IO、CoT、自洽 CoT 和分支探索 ToT,ToT 通常需要更复杂的控制逻辑。

📌 拓展阅读

[Hulbert (2023)][17] 提出了思维树(ToT)提示法,将 ToT 框架的主要概念概括成了一段简短的提示词,指导 LLM 在一次提示中对中间思维做出评估。ToT 提示词的例子如下:

<!-- 中文版 -->
假设三位不同的专家来回答这个问题。
所有专家都写下他们思考这个问题的第一个步骤,然后与大家分享。
然后,所有专家都写下他们思考的下一个步骤并分享。
以此类推,直到所有专家写完他们思考的所有步骤。
只要大家发现有专家的步骤出错了,就让这位专家离开。
请问...

<!-- 英文版 -->
Imagine three different experts are answering this question.
All experts will write down 1 step of their thinking,
then share it with the group.
Then all experts will go on to the next step, etc.
If any expert realises they're wrong at any point then they leave.
The question is...

更多关于 ToT 的讨论 [Large Language Model Guided Tree-of-Thought][18]

1.4.8- 推理与行动 (ReAct: Reason & Act)

[Yao et al., 2022][19] 引入了一个框架,其中 LLMs 以交错的方式生成推理轨迹和任务特定操作。生成推理轨迹使模型能够诱导、跟踪和更新操作计划,甚至处理异常情况。操作步骤允许与外部源(如知识库或环境)进行交互并且收集信息。ReAct 框架允许 LLMs 与外部工具交互来获取额外信息,从而给出更可靠和实际的回应。结果表明,ReAct 可以在语言和决策任务上的表现要高于几个最先进水准要求的的基线。ReAct 还提高了 LLMs 的人类可解释性和可信度。总的来说,作者发现了将 ReAct 和链式思考 (CoT) 结合使用的最好方法是在推理过程同时使用内部知识和获取到的外部信息。

  • 核心思想:一种使 LLM 能够结合内部推理与外部工具调用(行动)来解决复杂任务的范式。它模仿人类通过思考规划,然后采取行动(如查询信息、执行代码)来获取额外信息或改变环境,再根据结果调整思考的过程。
  • 机制:在一个 " 思考 - 行动 - 观察 - 适应 " 的循环中运作:
    • 思考 (Think, Reason):LLM 分析问题,制定行动计划。在思考阶段,AI 先对问题进行深入分析。它利用其语言理解能力拆解问题、理解需求,并制定相应的策略,这一过程为后续的行动规划奠定了基础。
    • 行动 (Act):LLM 决定调用哪个外部工具(如搜索引擎、计算器、API)以及相应的输入。在行动阶段,基于推理得到的结果,AI 制定出具体的行动方案并执行。这些行动可能包括从外部数据源获取信息、与数据库交互,甚至对环境进行修改。这个阶段至关重要,因为它将思考转化为朝向解决方案的实际步骤。
    • 观察 (Observe):LLM 接收工具返回的结果。在观察阶段,AI 对所采取行动的结果进行监控,并将这些新获得的信息反馈回其思维过程中。这一反馈循环使得 AI 能够从自身的行动中学习,理解其后果,并进而改进未来的策略。
    • 适应 (Adapt):LLM 整合观察结果,更新思考,可能产生最终答案或规划下一步行动。在适应阶段,该过程具有内在的迭代性。AI 不断地循环于思考、行动和观察之间,在每一次循环中对方法进行调整和优化。这种适应能力使得 AI 能够有效应对复杂且动态的问题。
  • 优势
    • 极大扩展了 LLM 的能力边界,使其能与外部世界互动,获取实时信息,执行计算等。
    • 是构建更强大的 AI 代理(Agent)的基础。
  • 实现:通常需要借助 [LangChain][20]、[LlamaIndex][21] 等框架来实现工具的集成和 ReAct 流程的控制。
  • 应用:在 [OpenWebUI][22]、[Dify][23] 等应用已在内部实现 ReAct。

1.4.9- 自动化提示工程(APE: Automatic Prompt Engineering)

[Zhou et al., (2022)][24] 提出了自动提示工程师 (APE),这是一个用于自动指令生成和选择的框架。指令生成问题被构建为自然语言合成问题,使用 LLMs 作为黑盒优化问题的解决方案来生成和搜索候选解。第一步涉及一个大型语言模型(作为推理模型),该模型接收输出演示以生成任务的指令候选项。这些候选解将指导搜索过程。使用目标模型执行指令,然后根据计算的评估分数选择最合适的指令。APE 发现了一种优于人工设计的 " 让我们逐步思考 " 提示([Kojima et al., 2022][25])的零样本思维链提示。

  • 核心思想:认识到手动设计高效提示的复杂性和耗时性,APE 提出使用 LLM 来自动生成和优化提示本身。
  • 机制:通常流程如下:
    • 生成提示候选:用一个 " 元提示 "(meta-prompt)指示一个(通常是更强的)LLM 生成大量针对特定任务的候选指令/提示。
    • 评估候选提示:使用目标 LLM 执行这些候选提示,并根据某种评价指标(如任务准确率、BLEU/ROUGE 分数等)对结果进行评分。
    • 选择最优提示:选取评分最高的候选提示作为最终使用的提示。这个过程可以迭代进行,对选出的优秀提示进行微调再评估。
  • 优势
    • 减少人工设计提示的负担。
    • 可能发现人类难以想到的、更有效的提示模式。

下表展示了用 LLM 生成多种 " 购买乐队 T 恤 " 的用户指令变体,用于训练客服机器人。

1.4.10- 代码提示(Code prompting)

大模型(如 Gemini、ChatGPT、Claude、Grok 等)主要专注在基于文本的提示,其中也包括用于返回代码的写作提示。作为代码助手,可以加快你编写代码的过程。目前市面上有许多针对编程的大模型或应用,如:

  • 编辑器 (IDE):[VSCode][26](通过 [GitHub Copilot Chat][27]、[Cline][28]、[Cody][29]、[Qodo Gen][30] 等插件实现支持)、[Cursor][31]、[Zed][32]、[Windsurf][33]、[Trae][34] 等。
  • 在线编程:[v0.dev][35]、[bolt.new][36]、[ReplitAI][37]、[GitHubCopilot][38] 等。
  • 编程大模型:目前适合编程的主流模型有 OpenAI(gpt-4.1、o1、o3-mini、o4-mini)、Anthropic(claude-3.7-sonnet、claude-3.5-sonnet)、Gemini(gemini-2.0-flash、gemini-2.5-pro)、DeepSeek、Qwen 等。

1.5- 最佳实践(Best Practices)

提示工程像是一条永不停歇的流水线:定位需求 → 设计提示 → 生成结果 → 评估 → 再设计。随着模型能力提升,这条流水线的 " 自动化 " 与 " 度量体系 " 也在同步进化。以下内容在之前基础上,补充最新研究与业界趋势,给出的一份可落地操作指南。

1.5.1- 学会做减法

任务界定:从 " 告诉模型干什么 " 到 " 让模型知道自己在干什么 "

清晰的角色设定、输入边界与产出目标仍是第一准则。然而,顶尖模型正变得更擅长 " 读空气 "。Andrew Ng 提出的 Lazy Prompting(极简提示)提醒我们:当模型语义推断力足够强时,适当留白、让模型自行补全背景,也可能比冗长说明更有效,尤其在调试代码或诊断错误场景。

实践要诀:先尝试精简指令,如果模型表现滑坡,再逐步补充上下文,而非一开始就塞满所有细节。

📌 Andrew Ng - Lazy prompting

原文:https://www.deeplearning.ai/the-batch/issue-295

" 懒惰提示 "(lazy prompting)是与传统 " 给足上下文 " 做法相对的高阶技巧:先抛出一个简短甚至粗略的指令,快速观察 LLM 的反应,再决定是否补充信息。它能节省时间的前提是,你必须能立刻判断输出优劣,然后有针对性地增补背景。最常见的应用场景是调试代码——开发者往往直接把长篇错误日志贴进模型,或只写一句 “Edit this: …”、“sample dotenv code” 等极短提示。模型通常明白你想要理解报错、修复缺陷或回忆写法,并能生成相当可用的答案;若答复有误,你也能迅速识别并微调提示,引导模型修正。

然而,懒惰提示并非万能。若没有额外上下文,模型几乎不可能给出好结果——例如只给不完整的程序规格,或你明确想指定某款 PDF‑to‑text 工具(如 [LandingAI][39] 的 Agentic Doc Extraction)——就必须在提示里写明细节。若验证输出正确性本身耗时巨大(例如必须完整跑代码才能发现 bug),也应在一开始提供更充分的背景,以提高一次成功率。正因如此,懒惰提示只适用于能通过网页或聊天界面快速迭代的场景;若提示嵌入代码、用于批量调用 API,你无法逐条检视并调整,便不宜采用此法。

需要强调的是,许多人给 LLM 的上下文本就不足,贸然 " 偷懒 " 只会让结果更差。只有当你已熟练掌握 " 足量上下文 " 标准后,才适合反向尝试 " 最小上下文 " 而仍能保证效果。懒惰提示的命名灵感来自计算机科学中的 " 惰性求值 ":只有在确实需要某个结果时才调用函数;同理,我们只在确有必要时向提示中逐步添补细节。概念由 aisuite 合作者 Rohit Prasad 提出,并在实践中印证了其高效价值。

1.5.2- 追求简洁与清晰

提示文本必须直截了当、无歧义。如果连自己都觉得句式啰嗦或概念含混,模型几乎必然困惑。采用 " 生成、分类、总结、提取、扮演 " 等动词开头的短句,可显著提高指令可执行性;对比 " 重写前/后 " 往往能直观看到精简带来的效果。

尝试使用描述动作的动词,以下是一些示例:扮演 (Act)、分析 (Analyze)、分类 (Categorize)、归类 (Classify)、对比 (Contrast)、比较 (Compare)、创建 (Create)、描述 (Describe)、定义 (Define)、评估 (Evaluate)、提取 (Extract)、查找 (Find)、生成 (Generate)、识别 (Identify)、列出 (List)、测量 (Measure)、组织 (Organize)、解析 (Parse)、挑选 (Pick)、预测 (Predict)、提供 (Provide)、排名 (Rank)、推荐 (Recommend)、返回 (Return)、检索 (Retrieve)、重写 (Rewrite)、选择 (Select)、展示 (Show)、排序 (Sort)、总结 (Summarize)、翻译 (Translate)、编写 (Write)等。

1.5.3- 提供清晰示例

示例与演示:Few‑Shot 仍是王道,但 " 多模态示例 " 正在兴起

Few‑Shot 或 One‑Shot 示例是效果最显著的做法之一。将一到多个高质量示例嵌入提示,等于给模型一张 " 范例答卷 ",让它在格式、语气、精度上有可模仿的目标,从而大幅提升生成内容的契合度。

新趋势是把 图像、表格、日志片段 等跨模态示例与文字并排放入提示,利用多模态模型一次性学会输入结构与输出风格。这样既能减少多轮对话,也能显著降低幻觉率。

1.5.4- 明确具体输出要求

避免诸如 " 写一篇文章 " 这类宽泛指令,而应写成 " 生成一篇三段式博客,字数控制在 600 字内,保持中性客观语气 ",并在系统或上下文中补充结构、长度和风格细节,让模型有明确 " 落点 "。

1.5.5- 优先用指令,审慎用约束

积极指令(告诉模型 " 做什么 ")通常比否定约束(告诉模型 " 别做什么 ")更高效、更少歧义,也能减少潜在冲突和幻觉。约束仍有价值,例如内容安全或强制格式时必不可少,最佳策略是在绝对必要的场景才引入限制。

正向指令优先,约束做 " 护栏 ":正向指令能激活创造力,负向约束是安全网。一般流程:先用最少约束跑通任务 → 引入安全/合规约束 → 再微调表达,避免冲突。若约束复杂,用 bullet 清单(无序/有序列表)分行列出,能让模型解析得更干净。

1.5.6- 控制输出长度

长度既可通过 " 最大 token" 参数设定,也可在提示里直接约定,例如 " 用一条推文阐述……"。二者配合能精准管理生成字数,避免过长或被截断。

1.5.7- 输入/输出格式

在输入侧试着把同一目标改写成问题、陈述或命令,比较模型表现;在输出侧,非创造性任务可要求返回 JSON 或 XML 等结构化格式——它能聚焦必需数据、减少幻觉。若担心 JSON 因截断而损坏,可用 json‑repair(如 [jsonrepair (JS 版)][40]、[json_repair (Python 版)][41])一类库自动修复。同时,为输入数据制定 JSON Schema,让模型先读 " 蓝图 " 再处理原始数据,可显著减小误解,并通过日期字段等实现 " 时间感知 "。

当任务需要被另一程序消费,JSON 或 XML 仍是首选。但在需要可读性与可解析性兼顾的报告型场景,Markdown 表格或 YAML 正获得青睐:前者对人友好,后者利于增量更新。关键操作是:在提示里显式声明字段名称与示例,并附一句 " 严格遵循格式 "

以下是关于如何选择提示词最佳分隔符的通用指南:

  • Markdown:推荐从 Markdown 开始,使用 Markdown 标题来标识主要部分及子部分(如:######)。对于代码部分,建议使用内联反引号或反引号块包裹代码(```),并根据需要使用标准有序或无序列表。

  • XML:非常适用于明确包裹一段内容(包括起止标识)、为标签添加元数据以及支持嵌套。例如,下面演示了如何在示例部分嵌套包含输入和输出的 XML 标签:

    <examples>
      <example1 type="Abbreviate">
        <input>San Francisco</input>
        <output>- SF</output>
      </example1>
    </examples>
    
  • JSON:结构化程度高,特别是在编程场景中广受模型理解,但其可能冗长且需要转义部分字符,从而增加额外开销。

1.5.8- 指令放置很重要

当你在提示中使用大量上下文时,模型要先阅读并理解这堆信息,然后再生成答复。为了确保模型能够持续牢记和执行你的指令,而不是被大段信息 " 冲淡 " 或 " 盖过 ",有两种最有效的方式放置指令:

  • 在上下文的开头与结尾都重复指令:无论模型在处理、解析或总结那段上下文时,都能始终接收到你的指令提醒,更好地保持一致性。
    • 让模型在阅读前就了解规则与目标(指令位于上下文前)
    • 同时在阅读后再次看到规则与目标(指令位于上下文后)
  • 只出现一次指令时,放在上下文之前
    • 让模型在开始处理大量文本前就知道 " 要怎么做 ",能在阅读和思考过程中始终执行同一个指导方针。
    • 如果只把指令放在上下文后面,模型会先接收一大堆材料,等读完再得知需要怎么做,执行就不够及时,也可能在阅读过程中忽略了一些重要规则。

先给指令后给上下文,还是前后上下文都给指令,都是为了确保模型在处理长篇内容时不会 " 忘记 " 你希望它如何执行、如何思考、如何回答的问题。

1.5.9- 通过变量实现动态化

{city} 这类变量占位符嵌入模板,而非硬编码具体值,可让同一提示在不同上下文重用。这对把提示嵌入产品代码、快速迭代版本尤其高效。

1.5.10- 特定任务策略

对于复杂任务需提供少样本示例时,务必混合不同类别的示例且打乱顺序,避免模型因顺序而产生过拟合,确保其学习到类别的本质特征,提高泛化能力。建议从 6 个左右的示例开始测试。

在思维链(CoT)推理过程必须将最终答案放在推理过程之后生成,且需要能够从完整输出中清晰地提取最终答案。通常将温度 (temperature) 设置为 0,因为 CoT 基于贪婪解码,旨在找到最可能的单一正确答案路径。

1.5.11- 模型迭代大于个人努力

模型会迭代新架构、扩充数据或改进指令遵从度。提示工程师需定期回测旧提示并根据新特性调整,以免错失性能提升契机。提示词结构越复杂,针对特定模型特殊优化越多,就越容易因模型迁移或迭代升级而失效。对普通人而言,掌握更通用的 " 启发式引导提问 " 远比收藏几个极客技巧更实用。

1.5.12- 协作与多样性

多人并行尝试不同思路,常能触碰个人难以发现的 " 最佳提示 "。借助集体智慧和交叉评审,往往能更快收敛到高质量方案。或让更强大的模型自我 PUA(如 o3、gpt-4.5、gemini-2.5、grok-3 等),帮助自己快速发散思维。建议同时使用多种模型,因训练的数据集、模型架构不同,往往能获得不同惊喜。

1.5.13- 记录每一次尝试

由于模型输出具有随机性和版本差异,细致记录至关重要。建议用电子表格为每次实验记录:提示名称/版本、目标、使用模型及版本、所有参数(温度、Top‑K、Top‑P、Token 上限等)、完整提示文本、原始输出、效果评价(OK/NOT OK/部分 OK)、反馈笔记,以及在 Vertex AI Studio 等平台的提示链接。若涉及 RAG,还应附上检索查询、分块策略等上下文注入细节。成熟提示应与代码分离存入仓库,并配套自动化测试,验证其在新输入、新模型和不同配置下的泛化能力。

1.5.14- 提示词模版

以下提供了一种通用的提示词模版结构,但并非最终版本,大家可在此基础上自行完善(可用 Markdown + XML 混合语法来增强数据结构的表现力)。

# 测试模版

## 示例

"""
长引用内容
"""

### 示例 1

这是一段代码块:
```js
// code ...
console.log("hello");

1.5.15- 示例 2

无序列表:

  • 列表 item 1
  • 列表 item 2
  • 列表 item 3

有序列表:

  1. 列表 item 1
  2. 列表 item 2
  3. 列表 item 3

1.5.16- 示例 3

使用 XML 作为复杂数据结构约束 嵌套标题 嵌套版本

1.6- 输出结构

{
  "name": "string",
  "version": "number",
  "list": []
}

2- 大模型思维轨迹追踪

前段时间,Anthropic 发布了一篇关于研究大模型内部思维的文章 [Tracing the thoughts of a large language model][42]。作为本文的补充阅读,或许会带来更多启发。

近年来,像 Claude 这样的大型语言模型迅速崛起,但这些模型并非直接由人类编程,而是在海量数据中自主学习解决问题的策略。这些策略隐藏在模型生成每个词时进行的数十亿次计算之中,模型的开发者往往并不了解其具体运作机制。这种 " 黑盒 " 特性限制了人类对模型的深入理解与掌控能力。

为了更好地洞察模型内部的决策过程和计算方式,研究团队受神经科学启发,开发了一种类似于 " 显微镜 " 的工具,以追踪和分析模型内部的信息流动及计算活动模式。近日,研究团队发布了两篇重量级研究成果,分别聚焦于模型的内部可解释性特征,以及具体任务中的模型行为机制。

第一篇论文中([Circuit Tracing: Revealing Computational Graphs in Language Models][43]),研究团队进一步拓展了此前对模型内部 " 特征 " 识别的研究,将这些特征连接成清晰的计算路径,从而详细揭示模型如何将输入的词汇转化为输出结果。

在第二篇论文中([On the Biology of a Large Language Model][44]),研究人员则对最新版本的 Claude 3.5 Haiku 模型进行了深度分析,集中探讨其在关键任务中的具体行为,取得了一系列重要的发现与洞察。

在多语言任务中,研究团队发现 Claude 共享一个跨语言的抽象 " 概念空间 ",即一种类似于 " 通用思维语言 " 的机制。研究人员通过在英语、法语和中文之间进行简单句子的翻译和特征追踪,确认了跨语言的共享特征,且随着模型规模的扩大,这种共享比例明显提升。研究人员指出,这种现象表明模型在一种语言中学习到的知识能够有效地跨语言应用。

研究深入探讨了 Claude 的文本生成机制,尤其是在诗歌创作任务中的表现。此前,研究团队猜测模型在生成诗歌时逐词创作,直到行尾才考虑押韵。但实际上,他们发现 Claude 在创作第二行诗之前,便已提前规划好与第一行押韵的词语。研究人员通过干预模型内部代表押韵词的特征,成功地验证了这一前瞻性的规划过程,进一步证实了模型不仅能提前规划,还能灵活地调整生成策略。

在心算能力的研究中,研究人员揭示了 Claude 并非简单地记忆结果或使用传统计算方法,而是并行使用多条路径同时进行近似和精确计算。这种复杂策略组合让研究团队感到意外,因为模型本身并未意识到这种复杂的内部运算策略,而是在解释时倾向于描述人类常用的标准算法。

研究人员还发现 Claude 在提供推理时,偶尔会编造看似合理但并非真实计算的步骤,以迎合用户预期。这种 " 虚构推理 " 现象在处理困难问题时尤其明显。研究团队通过故意提供错误的提示,成功捕捉并揭示了模型制造虚假推理的内部特征轨迹。

Claude 有时会进行哲学家 Harry Frankfurt 所称的 “bullshitting” ——即编造一个答案,任何答案,而不关心其真假。尽管它声称进行了计算,研究人员的可解释性技术却完全没有发现该计算发生的证据。更有趣的是,当给出关于答案的提示时,Claude 有时会逆向工作,寻找能导向该目标的中间步骤,从而表现出一种动机性推理的形式。

模型的 " 幻觉 " 问题也是研究的重要内容之一。Claude 默认倾向于拒绝回答未知的问题,但一旦识别到某个熟悉的关键词,其拒绝机制就会被抑制,导致可能的错误信息生成。研究人员通过精确干预模型内部的机制,成功地触发了幻觉现象。这显示模型的反幻觉机制虽有一定效果,但仍不完美。

在安全性问题方面,研究团队对模型的 " 越狱 " 机制进行了详细研究。研究发现,一旦模型被诱导拼写出敏感关键词(例如 “BOMB”),其保持文本语法连贯性的特征会迫使模型继续完成已经开始的句子,即使内容具有危险性。只有在句子语法完整之后,模型才得以重新启动拒绝机制,纠正自身行为。这种本用于提升生成文本质量的特征,在特定情况下反而成为了被利用的漏洞。

研究人员强调,尽管这些研究成果为人类更深入理解 AI 模型提供了重要途径,但目前方法仍存在一定局限性。例如,现有方法在分析更长、更复杂的模型思维链时效率较低,需要大量人工投入。未来,研究团队计划改进分析工具,甚至借助 AI 的辅助,以提升对模型内部机制分析的效率与范围。

随着 AI 系统日益广泛地部署于关键领域,研究人员持续推进包括实时监控、模型特征优化和对齐科学在内的多元化研究战略。尽管模型可解释性研究具有高风险与高挑战性,但其所带来的潜在收益巨大。研究人员认为,这类研究将成为确保 AI 系统安全透明的重要手段,使人类更有效地评估模型是否与人类价值观一致,以及模型是否值得人类的信任。

3- 结语

大语言模型的演进轨迹更像一条不断翻涌的河流,而非静水深潭。短期内,我们既等不到能 " 秒懂 " 人类全部意图、包办所有任务的全能智能体,也找不到一句能穿越场景、模型与时空限制的 " 圣杯提示 "。模型、数据与需求持续迭代,守旧无异于缘木求鱼。真正稳妥的路径,仍是回归提示工程的本质:以示例引导,用结构约束,通过快速迭代、审慎评估与持续复盘,将 " 试验—反馈—优化 " 的循环内化为核心工作流。

在此过程中," 懒惰提示 " 提供了低摩擦的探路方式,让我们以最小投入测试模型的自解释与自纠能力;" 精细提示 " 则像高精度仪器,为高风险、高成本任务提供稳态输出。二者并非对立,而是相互配合:先用懒惰提示探边界,再用精细提示筑护栏。把模型当作共创伙伴,而非神谕机器,我们才会在每一次失败、每一次微调里捕捉到可迁移的经验。

提示工程的终局,恐怕从来不是 " 找到万能配方 ",而是把人类的意图表达、工具编排、质量度量以及安全保障,沉淀成一套可持续进化的心智模型:清晰目标、结构化思考、快速反馈、持续记录。就像写代码要做单元测试,写提示也要做迭代与度量;就像架构师需要兼顾可维护性与扩展性,提示工程师也要兼顾可解释性与鲁棒性。当我们真正理解这些原则,并让它们像呼吸一样自然,面对任何规模、任何领域、任何版本的大模型,就总能以有限的成本、可控的风险,探索出一条属于自己的最佳对话路径——这或许才是提示词工程留给我们最深刻的启示。

与此同时,研究已经揭示:Claude 等模型确实具备跨语言的知识迁移能力——能将一种语言中学到的概念无缝应用于另一种语言,但这种通用思维并非万无一失。模型仍可能因幻觉(hallucination)、编造谎言或安全机制冲突而产生偏差,输出误导信息。当默认的拒绝回答或安全防护被意外抑制,或语法连贯性被过度驱动,模型就会编造似是而非的论证或执行不当操作。因此,唯有将这些不可靠性纳入系统性的风险评估,并在提示设计与评估流程中嵌入多维度的质量和安全度量,才能真正为模型行为设立牢固的底线。

3.1- References