简介：这份《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_name="gemini-1.5-flash", system_instruction=system_instruction ) # 用户消息：具体任务 user_message = '这条评论是：「发货太慢了，但东西还不错。」' response = model.generate_content( user_message, generation_config=genai.types.GenerationConfig( temperature=0.2, # 低温度让输出更确定 max_output_tokens=200 # 防止模型啰嗦 ) ) # 解析输出，失败时打印原始文本 try: result = json.loads(response.text) print(result) except json.JSONDecodeError: print("解析失败，原始输出：", response.text)逻辑说明：system_instruction在模型初始化时传入，保证每轮都生效。temperature=0.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_name="gemini-1.5-flash", system_instruction=system_instruction ) comments = [ "发货太慢了，但东西还不错。", "质量很差，退货了。", "包装完好，物流很快。", "一般般，没什么惊喜。", "客服态度好，问题解决了。" ] success = 0 results = [] for c in comments: resp = model.generate_content( f'这条评论是：「{c}」', generation_config=genai.types.GenerationConfig( temperature=0.2, max_output_tokens=200 ) ) 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", encoding="utf-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 划算得多。提示工程不是玄学，是把模型行为当成一个需要反复校准的系统来对待。希望帮到你。
本文还有配套的精品资源，点击获取
