makeCoder
  • 首页
  • 对话
  • 智能体
  • 模型&API
  • 知识库
    • 免费注册
    最佳实践

    谷歌提示词工程指南核心解读中文版

    由coder创建，最终由coder 被浏览 3 用户

    作者: Lee Boonstra | 来源: Google | 发布时间: 2025年2月

    1. 引言：每个人都可以写提示词

    当你在使用大型语言模型（LLM）时，提示词（Prompt）是你提供给模型用于预测输出的输入（通常是文本，也可以包含图像等其他模态）。

    你不需要成为数据科学家或机器学习工程师，每个人都可以编写提示词。

    然而，要设计出最有效的提示词可能很复杂。许多因素都会影响效果：你使用的模型、模型的训练数据、配置参数、措辞、风格、语调、结构以及上下文。

    因此，提示词工程（Prompt Engineering）是一个迭代的过程。不恰当的提示词会导致模棱两可或不准确的回答，阻碍模型提供有价值的输出。简而言之，提示词工程就是设计高质量提示词以引导 LLM 生成准确输出的过程。

    LLM 的工作原理

    记住 LLM 的本质：它是一个预测引擎。模型接收序列文本作为输入，根据训练数据预测下一个 Token（词元）应该是什么。当你编写提示词时，你实际上是在设置场景，引导 LLM 预测出正确的 Token 序列。

    2. LLM 输出配置 (Output Configuration)

    除了编写文本，优化 LLM 输出的另一个关键在于配置参数。

    输出长度 (Output Length)

    这是限制模型在响应中生成的 Token 数量。

    • 注意：减少输出长度限制并不会让模型变得更简洁，它只会让模型在达到限制时强行停止生成。
    • 成本：生成更多的 Token 需要更多的算力，意味着更高的能耗、潜在的更慢响应速度和更高的成本。

    采样控制 (Sampling Controls)

    LLM 并不是仅仅预测单一的下一个 Token，而是预测下一个 Token 的概率分布。Temperature（温度）、Top-K 和 Top-P 是决定如何从这些概率中选择最终 Token 的关键设置。

    1. Temperature (温度)

    控制 Token 选择的随机性程度。

    • 低温度 (接近 0)：适合需要确定性回答的场景（如数学、事实问答）。模型倾向于选择概率最高的 Token。
    • 高温度：适合需要多样性或意想不到结果的场景（如创意写作）。所有 Token 被选中的概率变得更均等。

    2. Top-K

    Top-K 采样从模型预测概率最高的 K 个 Token 中进行选择。

    • Top-K 越高：输出越具创意和变化。
    • Top-K 越低：输出越保守和符合事实。Top-K 为 1 时等同于贪婪解码（Greedy Decoding）。

    3. Top-P (核采样)

    Top-P 采样选择累积概率不超过特定值 P 的那些 Token。

    • P 值范围从 0 到 1。
    • 建议通过实验来决定使用 Top-K 还是 Top-P（或两者结合）。

    ⚠️ 参数组合的相互影响

    • 如果 Temperature = 0：Top-K 和 Top-P 将失效，模型只选概率最高的 Token。
    • 如果 Top-K = 1：Temperature 和 Top-P 失效，结果是确定性的。
    • 推荐的起始设置：Temperature = 0.2, Top-P = 0.95, Top-K = 30。这能提供连贯且适度有创意的结果。
    • 重复循环 Bug：不恰当的参数设置（过高或过低）可能导致模型陷入重复生成填充词的死循环。

    3. 提示词技术 (Prompting Techniques)

    3.1 零样本提示 (Zero-shot)

    这是最简单的提示类型，只提供任务描述，没有任何示例。

    • 示例：直接要求模型将电影评论分类为“正面”或“负面”。

    3.2 单样本与少样本提示 (One-shot & Few-shot)

    当零样本效果不佳时，提供示例（Demonstrations）非常有帮助。

    • 原理：向模型展示一个或多个期望的输入-输出模式，让模型模仿。
    • 经验法则：通常建议提供 3 到 5 个示例。
    • 注意：示例必须高质量、多样化且无错误。即使是一个小错误也可能混淆模型。
    • 应用：例如，将客户的披萨订单解析为 JSON 格式，通过提供几个“自然语言 -> JSON”的对照示例，模型能更准确地处理复杂的半份半口味订单。

    3.3 系统、上下文与角色提示

    这三种技术用于从不同维度引导模型：

    1. 系统提示 (System Prompting)：设定模型的整体背景和目标（如“你是一个翻译引擎”），类似于为系统设定“大局观”或特定格式要求（如“只返回 JSON”）。
    2. 上下文提示 (Contextual Prompting)：提供与当前任务相关的具体背景信息。例如，“你正在为复古游戏博客撰写文章”，这能帮助模型理解细微差别。
    3. 角色提示 (Role Prompting)：为模型指定一个角色（如“导游”、“小学老师”或“幽默的博主”）。这决定了输出的风格和语气。
      • 示例：扮演一个幽默的导游介绍曼哈顿，模型可能会输出：“觉得自己像金刚站在大苹果上，只是少了大香蕉”。

    3.4 后退一步提示法 (Step-back Prompting)

    这是一种通过让 LLM 先思考与具体任务相关的一般性问题（后退一步），然后再解决具体问题来提高性能的技术。

    • 流程：

      1. 原任务：写一个第一人称射击游戏的故事线。
      2. 后退一步：先问模型“第一人称射击游戏有哪些具有挑战性和吸引力的核心设定？”。
      3. 最终提示：将第 2 步得到的背景知识（如“废弃军事基地”、“赛博朋克城市”）作为上下文，再让模型写故事线。这能显著提高结果的深度和质量。

    3.5 思维链 (Chain of Thought, CoT)

    CoT 通过让模型生成中间推理步骤来提高推理能力。

    • 关键技巧：在提示词中加入 "Let's think step by step"（让我们一步步思考）。
    • 解决数学问题：LLM 并不擅长直接计算。通过 CoT，模型会写出推理过程（如：先算年龄差，再加法），从而得出正确答案。
    • 优势：低投入高产出，增加了可解释性（你可以看到它是怎么错的）。

    3.6 自我一致性 (Self-consistency)

    结合 CoT 和“少数服从多数”的投票机制。

    • 方法：让模型（在较高的 Temperature 下）对同一个问题进行多次推理，生成多条不同的推理路径，然后选择出现频率最高的那个答案。
    • 应用：例如判断一封看起来像玩笑其实是报告漏洞的邮件是否“重要”。通过多次推理投票，可以消除随机性误差。

    3.7 思维树 (Tree of Thoughts, ToT)

    CoT 的泛化版本。它允许 LLM 同时探索多个推理路径，像树的分支一样，而不是线性的。适合需要探索的复杂任务。

    3.8 ReAct (Reason & Act)

    结合推理 (Reasoning) 和 行动 (Acting) 的范式。

    • 原理：LLM 推理问题 -> 生成行动计划（如使用搜索工具） -> 执行行动 -> 观察结果 -> 更新推理 -> 继续行动，直到解决问题。
    • 示例：问“Metallica 乐队成员哪怕有几个孩子？”。模型会通过 ReAct 循环，分别搜索每个成员的孩子数量，最后加总。

    3.9 自动提示词工程 (Automatic Prompt Engineering, APE)

    用 LLM 来写提示词。

    • 流程：

      1. 让模型生成多个提示词变体（例如：生成 10 种“订购 Metallica T恤”的表达方式）。
      2. 评估这些变体（使用 BLEU 或 ROUGE 等指标）。
      3. 选择得分最高的提示词。

    4. 代码提示词 (Code Prompting)

    Gemini 等模型也是优秀的程序员，可以帮助编写、解释、翻译和调试代码。

    4.1 编写代码 (Writing Code)

    • 场景：你需要用 Bash 脚本批量重命名文件夹中的文件。
    • 提示词：清楚描述需求（“写一个 Bash 代码片段，询问文件夹名称，将该文件夹内所有文件重命名为前缀 draft_”）。
    • 结果：模型不仅生成代码，还会添加注释。

    4.2 解释代码 (Explaining Code)

    • 场景：你在阅读别人（或模型生成）的代码，想知道它是做什么的。
    • 提示词：粘贴代码，问“解释下面这段 Bash 代码”。
    • 结果：模型会分步骤解释：1. 用户输入；2. 检查文件夹是否存在；3. 文件列表遍历；4. 重命名操作。

    4.3 翻译代码 (Translating Code)

    • 场景：想把上面的 Bash 脚本改成 Python 以便跨平台或扩展。
    • 提示词：“将下面的 Bash 代码翻译成 Python 代码片段”。
    • 注意：在 Vertex AI Studio 中，获取代码时请使用 Markdown 模式，以保留正确的缩进（这对 Python 至关重要）。

    4.4 调试代码 (Debugging Code)

    • 场景：Python 脚本报错（如 NameError: name 'toUpperCase' is not defined）。
    • 提示词：粘贴错误信息和代码，问“调试哪里错了，并解释我该如何改进”。
    • 结果：模型会指出 Python 中应该用 .upper() 方法，并提供修复后的完整代码，甚至还会给出额外的优化建议（如使用 os.path.join 处理路径以兼容不同系统）。

    5. 最佳实践 (Best Practices)

    要成为提示词专家，请遵循以下原则：

    ✅ 1. 提供示例 (Provide Examples)

    这是最重要的实践。提供 One-shot 或 Few-shot 示例是强大的教学工具，能显著提高准确性、风格和语调的一致性。

    ✅ 2. 设计要简洁 (Design with Simplicity)

    提示词应简洁明了。如果连人都看不懂，模型大概率也看不懂。

    • Bad: “我现在在纽约，带着两个3岁孩子，我想听听哪里好玩...”
    • Good: “扮演导游。描述纽约曼哈顿适合带3岁孩子游玩的景点。”。
    • 使用动词: 如 Act, Analyze, Create, Describe, List, Summarize 等。

    ✅ 3. 对输出要具体 (Be Specific about the Output)

    不要含糊其辞。

    • Do: “生成一篇关于前5大游戏主机的3段式博客文章，风格要对话式且引人入胜。”
    • Do Not: “写一篇关于游戏主机的博客。”。

    ✅ 4. 优先使用指令而非约束 (Use Instructions over Constraints)

    告诉模型要做什么（正向指令），而不是不要做什么（负面约束）。人类和模型都更擅长处理正向指令。

    • Do: “只讨论主机名称、制造商、年份和销量。”
    • Do Not: “不要列出游戏名称。”。

    ✅ 5. 控制 Token 长度与使用变量

    • 明确要求长度：“用一条推文的长度解释量子物理”。
    • 使用变量（如 {city}）来构建可复用的动态提示词模板。

    ✅ 6. 混合分类示例

    在做分类任务的 Few-shot 提示时，确保示例中的类别是混合的（不要全都是正面评论，也不要按顺序排列），以防止模型过拟合于示例的顺序。

    ✅ 7. 实验输出格式 (JSON & Schemas)

    对于非创意任务（提取、分类等），强烈建议要求返回 JSON 格式。

    • 优点：结构化、易于程序处理、减少幻觉。
    • JSON Repair：由于 Token 限制，JSON 输出可能会被截断。使用 json-repair 库可以自动修复不完整的 JSON。
    • JSON Schemas (结构化输入)：不仅输出可以使用 JSON，输入也可以。通过提供 JSON Schema（定义数据结构），你可以明确告诉模型数据的属性（如日期、价格类型），这比纯文本描述更精准。

    ✅ 8. 文档化 (Documentation)

    记录你的提示词尝试是至关重要的。

    • 建议创建一个表格记录：目标、模型版本、Temperature、Top-K/P、提示词全文、输出结果以及反馈。
    • 版本控制：模型更新会导致输出变化，通过文档追踪可以帮助调试和迭代。
    名称 目标 模型 Temp Token限制 Prompt内容 输出结果
    [名称/版本] [一句话目标] [模型名] [0-1] [数字] [完整提示词] [记录输出]


    总结：提示词工程是从零样本到 ReAct 等一系列技术的集合。通过不断实验（Tinkering）、记录和遵循最佳实践（如使用示例、明确指令、结构化数据），你可以驾驭 LLM 的能力，构建出强大的应用。

    {link}