简介这份《google提示工程.pdf》面向具备一定编程基础、希望深入掌握大语言模型交互技巧的开发者、数据科学家与机器学习工程师系统讲解如何编写高质量提示词以提升模型输出的准确性与相关性。内容覆盖零样本、少样本、系统提示、角色提示、上下文提示、退步提示、思维链、自洽性、思维树与ReAct等主流技巧并延伸至自动提示工程APE、代码生成与调试提示、多模态提示等进阶主题。文档还详解温度、Top-K与Top-P等输出配置参数总结提供示例、保持简洁、明确输出要求、优先使用指令而非约束等最佳实践并强调提示工程的迭代性与实验记录价值。资源包共1个pdf文件大小约1018KB结构完整、便于通读与检索。目前已有393人学习下载适合希望为文本生成、代码编写、数据解析等任务设计高效提示词的读者参考。1. 从一份 google提示工程.pdf 说起为什么提示词工程值得系统啃一遍很多人第一次接触提示工程是从一份流传很广的 google提示工程.pdf 开始的。它不像论文那样堆公式也不像产品文档那样只讲接口而是把「怎么跟大模型说话」这件事拆成了可操作的模块。你如果正在用 Google 的 Gemini、Colab 或者任何支持 prompt 的模型这份材料能帮你把零散的试错经验变成一套可复用的方法。它适合三类人刚入门想少走弯路的开发者、需要把提示词固化进产品的工程师、以及被「模型输出不稳定」折磨过的从业者。核心问题只有一个同样的模型为什么别人能稳定拿到结构化结果而你只能靠玄学反复重试。提示工程就是把这层不确定性压下去的手艺而这份 pdf 的价值在于它给出了从零样本到少样本、从角色设定到格式约束的完整阶梯。2. 提示工程的核心机制模型到底在「听」什么2.1 从 token 预测到指令跟随提示词的作用点在哪大模型本质上是一个条件概率预测器给定前文 token 序列预测下一个 token。提示工程之所以有效是因为你写的每一句话都会改变条件概率的分布。当你写「请用 JSON 输出」时模型并不是真的理解 JSON 规范而是因为训练数据中「请用 JSON 输出」后面大概率跟着合法的 JSON 结构。这就是为什么格式约束要写得具体只说「结构化输出」太模糊模型可能给你 Markdown 表格也可能给你 YAML。Google 那份材料里反复强调「明确输出格式」背后的机制就在这里。另一个关键点是指令跟随能力它来自 RLHF 阶段的微调模型被训练成优先响应显式指令。所以提示词里「忽略之前的指令」这类话有时能生效有时翻车取决于模型对指令层级的敏感度。理解这一点你就不会把提示工程当成咒语而是当成对概率分布的定向引导。2.2 零样本、少样本与思维链三种模式的选型依据零样本适合任务定义清晰、模型见过大量类似样本的场景比如「把下面这句话翻译成英文」。少样本适合输出格式特殊或领域术语多的任务你给两三个示例模型就能模仿格式。思维链适合推理类任务比如数学题或多步逻辑判断加上「让我们一步步思考」能显著提升准确率。选型时看两个维度任务复杂度和输出约束强度。复杂度高、约束强就上少样本加思维链复杂度低、约束弱零样本就够。Google 的 pdf 里有一个很实用的判断表我把它简化成下面这个对照模式适用场景典型 token 开销风险零样本翻译、摘要、简单分类低格式不稳定少样本结构化抽取、特定风格生成中示例偏差被放大思维链数学、逻辑、多跳推理高可能编造中间步骤实际项目中我一般先用零样本跑一版看失败案例集中在哪再决定加示例还是加推理指令。不要一上来就堆思维链token 成本和延迟都会上去。2.3 用 Google AI Studio 快速验证一条提示词的最小步骤如果你手头没有现成环境最快的方式是用 Google AI Studio 的网页界面。打开后选择 Gemini 模型在左侧输入系统指令右侧输入用户消息。系统指令里写角色和全局约束用户消息里放具体任务。比如下面这段# 系统指令 你是一个电商评论分类器。只输出 JSON格式为 {sentiment: positive|negative|neutral, reason: 一句话理由}。 不要输出任何其他内容。 # 用户消息 这条评论是「发货太慢了但东西还不错。」点运行后看输出。如果模型多说了废话就在系统指令里加一句「只输出 JSON不要解释」。如果分类边界模糊就在用户消息里加两个示例。这个循环就是提示工程的基本功改一句跑一次看输出再改。Google AI Studio 的好处是延迟低、免费额度够试错适合把一条提示词打磨到稳定再搬到代码里。3. 把提示词从 pdf 搬进代码参数、模板与批量测试3.1 系统指令与用户消息的分工别把约束写错地方系统指令和用户消息在模型眼里权重不同。系统指令通常在整个对话中持续生效用户消息只影响当前轮。所以全局约束——角色、输出格式、禁止事项——放系统指令具体任务数据放用户消息。常见错误是把「只输出 JSON」写在用户消息里结果多轮对话后模型忘了。另一个错误是把任务描述写得太长塞进系统指令导致模型对用户消息不敏感。我一般的原则是系统指令不超过 200 字只写角色和硬约束用户消息里写任务和输入数据。如果任务本身复杂用少样本示例放在用户消息里而不是系统指令里。3.2 用 Python 调用 Gemini API 跑通第一条结构化输出下面这段代码是最小可复现版本依赖google-generativeai包。先安装pip install google-generativeai然后设置 API key 并调用import google.generativeai as genai import json genai.configure(api_key你的API_KEY) # 系统指令角色和硬约束 system_instruction ( 你是一个评论分类器。只输出 JSON格式为 {sentiment: positive|negative|neutral, reason: 一句话理由}。 不要输出任何其他内容。 ) model genai.GenerativeModel( model_namegemini-1.5-flash, system_instructionsystem_instruction ) # 用户消息具体任务 user_message 这条评论是「发货太慢了但东西还不错。」 response model.generate_content( user_message, generation_configgenai.types.GenerationConfig( temperature0.2, # 低温度让输出更确定 max_output_tokens200 # 防止模型啰嗦 ) ) # 解析输出失败时打印原始文本 try: result json.loads(response.text) print(result) except json.JSONDecodeError: print(解析失败原始输出, response.text)逻辑说明system_instruction在模型初始化时传入保证每轮都生效。temperature0.2降低随机性适合分类任务。max_output_tokens限制长度避免模型加解释。解析失败时打印原始输出方便定位是格式问题还是模型没遵守指令。参数怎么改如果分类准确率不够先把 temperature 降到 0再考虑加少样本示例。如果输出被截断调大 max_output_tokens。如果模型偶尔加 Markdown 代码块在系统指令里加「不要用 Markdown 代码块包裹」。3.3 批量测试提示词用循环和断言把稳定性量化单条跑通不算数要批量测。下面这段代码读一个评论列表逐条调用统计 JSON 解析成功率和分类一致率import google.generativeai as genai import json genai.configure(api_key你的API_KEY) system_instruction ( 你是一个评论分类器。只输出 JSON格式为 {sentiment: positive|negative|neutral, reason: 一句话理由}。 不要输出任何其他内容。 ) model genai.GenerativeModel( model_namegemini-1.5-flash, system_instructionsystem_instruction ) comments [ 发货太慢了但东西还不错。, 质量很差退货了。, 包装完好物流很快。, 一般般没什么惊喜。, 客服态度好问题解决了。 ] success 0 results [] for c in comments: resp model.generate_content( f这条评论是「{c}」, generation_configgenai.types.GenerationConfig( temperature0.2, max_output_tokens200 ) ) try: parsed json.loads(resp.text) results.append(parsed) success 1 except json.JSONDecodeError: results.append({error: resp.text}) print(f解析成功率{success}/{len(comments)}) for r in results: print(r)逻辑说明循环里每条评论独立调用避免上下文污染。success统计解析成功率低于 90% 就说明提示词需要加固。results保留每条输出方便人工核对分类是否合理。参数怎么改如果成功率低先检查系统指令是否被模型忽略再尝试在用户消息里加一个示例。如果分类结果和预期偏差大说明任务定义模糊需要补充边界说明比如「包含转折词的评论按整体情感判断」。4. 避坑与排查提示工程里那些血泪经验4.1 现象模型输出带 Markdown 代码块JSON 解析失败原因模型在训练数据里见过大量「用代码块包裹 JSON」的样本即使系统指令说「只输出 JSON」它仍可能加json 包裹。解决在系统指令里明确写「不要用 Markdown 代码块包裹直接输出纯文本 JSON」。如果还不行在解析前做一次清洗用正则去掉首尾的json 和 。更稳妥的做法是换用支持结构化输出的 API 参数比如 Gemini 的 response_mime_type 设为 application/json。4.2 现象多轮对话后模型忘记格式约束原因系统指令的权重会随着对话轮次增加而衰减尤其是用户消息很长时。解决每轮用户消息末尾重复一次关键约束比如「记住只输出 JSON」。或者把格式约束做成少样本示例每轮都带上一个输入输出对。另一个办法是缩短对话历史只保留最近两轮。4.3 现象少样本示例给了三个模型只模仿最后一个原因模型对靠近用户消息末尾的示例更敏感这是注意力机制的位置偏差。解决把最重要的示例放在最后或者把示例顺序打乱后多跑几次看稳定性。如果任务对格式要求极高把示例写成「输入 → 输出」的固定模板并在系统指令里说「严格按照示例格式输出」。4.4 现象思维链让模型编造中间步骤答案反而错了原因思维链会诱导模型生成看似合理但实际错误的推理路径尤其在数学题里。解决对事实性任务慎用思维链改用「先给出答案再简要说明理由」的顺序。如果必须用思维链加一句「如果无法确定输出『不确定』而不是编造」。另外temperature 设到 0 能减少编造。4.5 现象中文提示词效果不如英文但任务本身是中文原因部分模型的训练数据中英文指令跟随样本更多英文提示词的指令遵循率更高。解决系统指令用英文写角色和格式约束用户消息用中文写任务数据。比如系统指令写「You are a classifier. Output JSON only.」用户消息写中文评论。实测这种混搭在 Gemini 上比纯中文提示词稳定。5. 进阶技巧把提示词当成可版本管理的代码5.1 用模板变量和配置文件管理提示词提示词一旦超过三条就该从代码里抽出来。我一般用一个 YAML 文件存系统指令和少样本示例Python 里读进来做字符串替换。这样改提示词不用动代码也方便做 A/B 测试。下面是一个最小示例# prompts/classifier.yaml system_instruction: | 你是一个评论分类器。只输出 JSON格式为 {sentiment: positive|negative|neutral, reason: 一句话理由}。 不要输出任何其他内容。不要用 Markdown 代码块包裹。 few_shot: - input: 质量很好下次还来。 output: {sentiment: positive, reason: 明确正面评价} - input: 发货慢东西还行。 output: {sentiment: neutral, reason: 有负面也有正面}Python 里加载import yaml with open(prompts/classifier.yaml, r, encodingutf-8) as f: prompt_config yaml.safe_load(f) system_instruction prompt_config[system_instruction] few_shot_text \n.join( f输入{ex[input]}\n输出{ex[output]} for ex in prompt_config[few_shot] )逻辑说明YAML 的|保留换行适合多行系统指令。few_shot列表转成文本后拼进用户消息。参数怎么改加示例就改 YAML不用动 Python。如果某个示例效果不好删掉或替换后重新跑批量测试。5.2 用版本号和回归测试防止提示词退化提示词改了一版怎么知道比上一版好我习惯给每个提示词文件加版本号比如classifier_v1.yaml、classifier_v2.yaml然后跑同一批测试用例对比解析成功率和分类准确率。测试用例至少覆盖正常输入、边界输入如中英混合、对抗输入如带指令注入的评论。如果新版本在某个用例上退化就回滚。这个习惯能避免「改了一句感觉更好」但实际翻车的情况。5.3 一个具体技巧用「输出前缀」强制模型进入格式如果模型总是先输出一句「好的以下是分类结果」再给 JSON可以在用户消息末尾加一个输出前缀比如输入这条评论是「发货太慢了但东西还不错。」 输出注意「输出」后面直接换行模型会倾向于接着写 JSON而不是加解释。这个技巧在少样本示例里也适用把示例的输出部分写成「输出{...}」模型会模仿这个模式。实测在 Gemini 和同类模型上加输出前缀能把格式遵循率从 70% 提到 90% 以上。如果还不行就把前缀写成「输出{」模型会直接补全 JSON 对象。我自己的习惯是每接一个新任务先花二十分钟把提示词在 AI Studio 里打磨到批量测试成功率 95% 以上再写进代码。这个时间投入比后期调 bug 划算得多。提示工程不是玄学是把模型行为当成一个需要反复校准的系统来对待。希望帮到你。本文还有配套的精品资源点击获取