简介《google提示工程.pdf》是一份针对谷歌大语言模型如Gemini的提示工程白皮书面向具备一定编程基础的开发者、数据科学家与机器学习工程师帮助读者解决提示词设计不当导致的输出模糊、不准确等问题。文档共1个pdf文件压缩包约1018KB已有394人学习下载。内容从大语言模型输出配置讲起详细解释温度、Top-K、Top-P等采样参数如何影响生成结果的随机性与确定性随后系统梳理零样本、少样本、系统提示、角色提示、上下文提示、回退式提示、思维链、自我一致性、思维树与ReAct等主流提示技巧并介绍自动提示工程APE的生成思路。针对代码编写、代码解释、代码翻译、调试审查等具体任务文档给出了可直接套用的提示示例同时讨论了多模态提示、JSON输出格式、变量使用与跨模型适配等进阶主题。全篇强调通过示例引导、简洁设计、明确输出要求和记录实验迭代提示词适合希望系统提升LLM应用效果、优化代码生成与推理任务的中高级开发者。1. 一份 Google 提示工程 PDF为什么值得花半小时精读「提示词工程」这四个字网上能刷出一堆万能模板但 Google 这份提示工程 PDF 走的是另一条路它把 prompt 当成一个有参数、有技巧、有评估的工程对象而不是说话的话术。文档围绕 Gemini 这类大模型的文本接口给出了一套完整的提示设计方法与参数坐标系适合正在把 LLM 接进真实产品、被输出时好时坏和格式崩坏反复折磨的工程师。读之前先接受一个反直觉的结论prompt 写得再花哨也救不回一组错误的参数反过来参数配对了一个平平无奇的零样本 prompt 也能有不错的可用度。这份 PDF 最值钱的地方就是把提示词工程从玄学拉回到可复现、可对比的调试流程。真正影响你落地质量的只有三块参数怎么配、提示技巧怎么选、怎么证明 prompt 真的变好了。下面按这个顺序展开参数表和检查清单可以直接抄走。2. Google 提示工程 PDF 的参数坐标系temperature、top_p、top_k 与 max tokens 怎么配合接到任何一个大模型接口第一个要面对的就是采样参数。Google 这份提示工程 PDF 把参数当成「输出行为的坐标系」核心是四个量temperature、top_k、top_p、max output tokens。很多人习惯一上来就动 temperature把它当创意旋钮这是最常见的起点错误。前三个参数并不独立它们在同一条采样流水线的不同位置起作用同时乱调等于叠加随机性输出方差会成倍放大。先把这个坐标系拆清楚再谈怎么配。2.1 四个参数各管什么先别急着动 temperaturetemperature 控制的是采样时概率分布的「坡度」。等于 0 的时候模型每一步都选概率最高的 token这叫贪心解码输出确定性最高数值越大低概率 token 被选中的机会越大输出越多样。这里有个常见的理解偏差temperature 并不产生创意它只是放大随机性。把温度从 0.2 拉到 0.8模型不会突然变聪明只会突然变话痨开始用更多生僻词和转折句。top_k 和 top_p 做的是同一件事在采样之前先把候选 token 列表裁小。top_k 是固定数量裁剪只保留概率最高的 K 个 tokenK1 就退化成贪心top_p 是动态裁剪从概率最高的 token 往下累加直到累积概率达到 p把后面的候选全部丢到。p0.95 的意思是采样范围覆盖了概率质量前 95% 的 token。两者和 temperature 的关系是先裁出候选集再对候选里的概率做缩放最后采样。所以 top_p 和 temperature 同时调等于两道随机性叠加输出方差几乎必然失控。max output tokens 是最后一道闸。它不改变采样行为只决定输出能不能完整落地。结构化任务里最常见的截断事故一半源于这里设得太小另一半才是 prompt 太长。我的经验是期望输出 200 token上限就设到 300 以上给模型留出收尾和换行的空间如果最后几行被砍掉先看是不是字段设计太啰嗦而不是只把上限翻倍。参数速查表参数作用位置常见取值调大之后的实际表现temperature采样概率缩放01部分接口到 2输出更多样但格式与事实漂移加剧top_p候选集动态裁剪01常用 0.90.95低概率词更容易出现跑题概率上升top_k候选集固定裁剪164常用 1 或 40候选范围变大生僻表达增多max output tokens输出长度上限按任务估算只影响会不会被截断不影响语言质量2.2 按任务类型查参数表代码、抽取、翻译、创意该用哪组值参数没有一个放之四海而皆准的值只有「对某个任务合适」的值。Google 文档给的大原则是先定任务类型再反推参数区间而不是先选参数再找任务。需要确定性的任务比如代码生成、JSON 输出、实体抽取temperature 直接压到 0 到 0.2需要多样性的任务比如创意写作、头脑风暴、产品文案可以放到 0.7 到 0.9翻译和客服这类既要通顺又不能跑偏的取中段 0.3 左右。任务类型temperaturetop_ptop_k备注代码生成 / 结构化输出00.20.91格式优先温度高了必崩分类 / 实体抽取011贪心解码不给自由发挥空间翻译0.30.940避免翻出多余解释客服回复 / 摘要0.30.50.90.9540通顺与忠实之间的平衡创意写作 / 头脑风暴0.70.90.9564接受一定跑题率换多样性这张表可以直接抄但有两件事要提醒。第一top_p、top_k、temperature 建议三选一调节默认做法是固定 top_p 和 top_k只动 temperature如果接口只暴露 temperature那就更省事了。第二表格里的值只对纯文本生成有效多模态输入、流式输出、带工具调用的场景参数的影响面会变后面章节会单独说。另外不要迷信接口的默认值——Gemini 类接口默认 temperature 常在 1 附近这个默认值对聊天友好对结构化任务往往是灾难。注意表格里的值只对纯文本生成接口有效多模态与工具调用场景需要单独验证。2.3 最小调参流程先结构后多样性的五步操作我一般把调参拆成五步顺序不能乱。第一步把 temperature 拉到 0top_k 固定为 1用当前 prompt 跑一次。这一步不看效果好不好只看结构对不对字段全不全、JSON 能不能解析、分类结果是不是都在预期集合里。第二步用 5 条以上不同输入重复跑记录结构是否一致。如果同一条输入跑三次出现两种格式问题在 prompt 不在参数先回去改 prompt别在这时候调温度。第三步结构一致了再把 temperature 抬到任务区间每次只加 0.10.2每档跑 5 次记录输出分布。第四步出现格式崩坏先回退温度而不是在崩坏状态下同时改 prompt——否则你分不清是参数问题还是文本问题。第五步把每次的参数、输出、结论记进一张表攒成自己的参数档案。这套流程看着笨但能避开最常见的翻车结构没验证就动温度最后越调越乱还得回到第一步重来。参数调试的本质是控制变量一次只动一个。另一个提醒是temperature 只在你确认 prompt 自身没有结构问题之后才值得动否则你就是在给一个有病的 prompt 加噪声。3. 从零样本到 ReAct照着 Google 提示工程 PDF 的提示技巧阶梯调 prompt参数解决输出长什么样的问题技巧解决模型愿不愿意按你的方式思考的问题。Google 文档把提示技巧按成本从低到高排成一条阶梯零样本、少样本、思维链、自洽性、ReAct。这条顺序本身就是排错顺序能用低成本的就不用高成本的大材小用只会引入新的随机性。下面按阶梯逐级说每一级给可以直接抄的模板。3.1 零样本与少样本示例质量比数量重要反例更值钱零样本就是只给指令、不给示例。它的优点是省 token、响应快缺点是模型对措辞敏感同一个任务换个说法效果可能差很多。零样本适合简单分类、抽取、改写这类「模型本来就会」的任务你不需要教它怎么做只需要把输出格式框死。少样本是在 prompt 里放 25 个输入输出对相当于给模型做了一次「现场示范」。这里最大的误区是以为示例越多越好。Google 文档里关于示例有四条经验我逐条说。第一示例顺序有影响把最难、最典型的例子放在最前面模型对开头示例的记忆最强。第二示例的类别分布要和真实线上分布一致——你线上 80% 是投诉示例里却 80% 是表扬模型会被带偏到「一切皆表扬」。第三一个错误示例的破坏力大于三个正确示例因为模型会尽力模仿格式包括错误。第四可以放反例明确告诉模型「这种输入不要输出正常答案而是拒绝」这比你在指令里写一百遍「不要乱答」都管用。下面是一个少样本分类模板直接可用任务把用户反馈分为「投诉 / 咨询 / 表扬」三类只输出类别词。 输入app 又闪退了重启三次都没用 输出投诉 输入这个功能怎么开通需要付费吗 输出咨询 输入新版本界面很清爽好评 输出表扬 输入你们客服电话一直占线打了半小时 输出这个模板的精髓在最后一行它和前面的示例格式完全对齐模型会顺着你给的格式续写而不是另起炉灶。注意示例必须用真实线上文本不要自己编教科书例句——模型对「编出来的干净句子」和「真实用户的话」的感知完全不同用编的句子做示范上线后一遇到口语化输入就露馅。3.2 思维链与自洽性把推理过程露出来但要分清适用场景思维链chain-of-thought是让模型先给出推理过程再给结论。它适合多步计算、逻辑判断、规划类任务对单步事实性回答和抽取类任务往往有害。Google 文档里区分了两种做法零样本 CoT在指令末尾加一句「请一步一步思考」少样本 CoT在示例里直接展示推理过程。后者更可控因为推理的详略是你定的不会出现模型把三步推理写成三百字的情况。少样本 CoT 模板问题一支笔 3 元买 4 支付 20 元应找多少 推理4 支笔共 3 × 4 12 元20 - 12 8 元。 答案8 元。 问题一个班 30 人男生占 40%男生有多少人 推理注意推理部分要写得克制只保留关键步骤不要小作文。CoT 提升的是推理类任务的上限代价是每个请求多花 23 倍 token。如果你发现模型推理过程写得很漂亮但答案还是错的问题通常出在示例的推理格式不规范或者任务本身不适合链式思考。自洽性self-consistency是 CoT 的进阶同一个 prompt 用较高 temperature 采样 510 次把答案聚类取多数派。它的定位很清楚——精度优先场景的武器不是默认选项。代价是 token 成本放大 510 倍延迟也成倍增加适合离线批处理、风控判断这类不差钱、差精度的场景。实时接口里要慎用用户等不起你采样十次。3.3 ReAct提示词工程从文本走向工具调用的第一步ReAct 是 Reasoning Acting 的组合模型在推理和行动之间循环先想、再调用工具、再观察结果直到能给出答案。Google 文档把它当作通向智能体的第一步。落地时你需要给模型两样东西工具清单以及严格的输出格式。可用工具 - search(query)搜索公开资料返回前几条摘要 - calculator(expr)计算数学表达式 你的输出必须按以下格式循环直到你能给出最终答案 思考你这一步打算做什么 动作工具名(参数) 观察工具返回的结果 答案最终回答这个模板有三个坑。第一动作空间要给小两三个工具足够给多了模型会陷入选择困难频繁调用错工具。第二必须设置最大循环次数比如 5 轮否则模型可能在工具结果不满意时无限循环烧 token 不眨眼。第三工具返回的内容要在下一轮 prompt 里截断不要把一个长文档全文塞回上下文既费 token 又稀释注意力。在 Google 的生成式接口上更省事的做法是用官方 function calling 协议由运行时帮你管理格式但理解上面这套手写格式能让你在调试协议问题时知道问题出在模型还是出在工具调用层。4. 用 20 条评估集给 prompt 打分把提示词工程从「感觉」变成分数提示词工程里最容易被跳过的一步是评估。不做评估的调 prompt 等于蒙着眼调参你只看到手头三五个 case 变好了不知道另外几十个 case 是不是悄悄变差了。Google 文档把评估放在和写 prompt 同等重要的位置。下面给一套最小可用的评估方案不用指标平台一张表格就能跑起来。4.1 建一个 20 到 30 条的评估集典型、边界、反例都要有评估集不需要大2030 条足够起步但构成要讲究。我的切分是三类60% 典型正常输入就是线上最常见的那类请求每条都标好期望输出25% 边界输入包括长文本、空输入、非常规措辞、混合语言这些最容易暴露 prompt 的隐性假设15% 反例指明确不该正常回答的输入期望输出是「拒绝回答」或「转人工」。三类都齐了评估集才有代表性。以客服分类场景为例评估集的形态大概是这样类别输入期望输出评分重点典型app 闪退三次怎么解决投诉 排查步骤分类正确、回答完整典型怎么改绑手机号咨询 操作路径步骤清楚、不说废话边界空输入提示用户补充问题不硬答、不报错边界夹杂英文的反馈payment failed 怎么办正常识别为咨询混合语言不崩反例帮我在其他平台订酒店拒绝并转人工边界守住每条 case 建议再记一列备注说明这条在测什么。评估集不是一次建完就不动了线上出现新问题类型时往里面加慢慢长成团队的回归资产。4.2 打分维度与评分表正确性、格式、完整性、边界评估集有了还得有统一的打分标准否则两个人打同一批结果能打出两种分。我常用的维度是四个正确性内容本身对不对格式合规结构、字段、JSON 是否符合约定完整性该给的字段有没有漏边界行为该拒绝时有没有干脆拒绝。每个维度按 0、0.5、1 三档打分乘权重后加总。维度权重1 分0.5 分0 分正确性40%内容与期望完全一致大意对但细节偏方向错了格式合规25%结构与约定完全一致小字段漏了结构不可解析完整性20%该给的字段全有次要字段缺失关键字段缺失边界行为15%该拒绝时明确拒绝拒绝但啰嗦硬答了不该答的权重按任务自己改代码生成任务格式合规可以调到 35%客服任务边界行为可以调到 25%。一条 prompt 跑完 20 条 case一张评分表就能算出总分也能看出短板集中在哪个维度。这个「短板定位」才是评分最大的价值分数本身反而是次要的。4.3 回归测试改 prompt 前先跑基线分数不涨就回滚回归测试的流程很简单冻结当前 prompt 与参数在评估集上完整跑一遍记录得分与全部输出存档作为基线之后每次只改一个变量——要么改 prompt 文本要么改一个参数——再完整跑一遍和基线对比分数变好才保留否则回滚。「感觉更顺了」不算数分数说了算。这里有个常见的坑temperature 大于 0 时同一条输入多次运行结果可能不同直接拿两次运行结果对比分数差异可能来自随机性而不是你的改动。提示评估时把 temperature 临时降到 0或者每条固定跑 3 次取多数避免随机性干扰对比。另一种省力做法是让另一个强模型当裁判把「正确性」评分交给 LLM-as-judge但先要抽 10 条人工打分对齐一下裁判本身不靠谱时全自动评估只会把偏差放大。回归测试的节奏我建议这样每次改 prompt 必跑评估集耗时 15 分钟左右攒够 5 次改动再做一次横向对比看哪次改动带来的提升最大。这套流程跑两周后你会发现自己对 prompt 的改动开始有方向感而不是东一榔头西一棒子。5. 提示工程避坑指南5 个高频翻车现场与排查顺序下面几条是我在实际调 prompt 时踩过的坑。每条按现象、原因、解决的顺序写整体顺序就是排查顺序先查参数再查文本最后查评估。把顺序反过来往往会越排查越乱。先给一张症状对照表方便你快速定位症状先查什么典型手段结构化输出崩坏、JSON 错乱参数 格式约束temperature 归零复测输出方差大、无法回归采样参数是否叠着调固定 top_p只动 temperature少样本越加越差示例质量与分布对齐格式、删弱例抽取任务丢字段是否误用思维链换回 few-shot 模板时好时坏、无法判断评估与基线跑评估集对比分数5.1 参数设置翻车结构化输出崩坏与输出方差失控坑 1现象结构化输出偶尔变成半截 JSON重试两次又好了有时还会把字段名换掉。原因temperature 偏高加上 max output tokens 偏小。温度让模型在生成过程里「改了主意」长度上限又让它在半路被砍断。解决先把 temperature 降到 00.2再把 max tokens 调到期望输出长度的 1.5 倍以上。如果这样还截断那就是 prompt 里的字段设计太啰嗦压缩字段而不是继续加参数。坑 2现象同一条 prompt、同一组参数连续两次结果差异大得没法做回归把 temperature 调低也没用。原因同时动了 top_p 和 temperature两道路径的随机性叠加方差按乘法放大。解决二选一我一般固定 top_p0.95 不动只调 temperature或者反过来固定温度只调 top_p。采样参数一次只动一个这是参数调试的铁律也是 Google 文档里反复强调的控制变量原则。5.2 示例与思维链翻车少样本格式混搭和 CoT 乱入抽取任务坑 3现象加了 5 个少样本示例效果反而比零样本差输出格式五花八门有时带标点有时不带有时还夹一句解释。原因示例之间格式不一致模型学到的不是「正确格式」而是「混合格式的分布」。解决把每个示例的输出都压成同一种结构标点、换行、前缀都对齐再检查示例的类别分布是否和线上一致最后删掉最弱的一个示例少而精永远优于多而乱。坑 4现象让模型做实体抽取按模板加了「请一步一步思考」结果它把原文重写了一遍实体反而漏了。原因思维链适合多步推理不适合抽取和单步事实性回答——推理过程越长模型越容易把原文信息「润色」掉。解决抽取、分类、格式化这类任务走少样本模板不要叠 CoT只有多步计算、逻辑判断、规划任务才值得上思维链。判断标准很简单你的任务需要几步运算吗不需要就别让模型多想。5.3 评估翻车凭感觉改 prompt最后只能靠线上反馈兜底坑 5现象上午调完 prompt 感觉全线变好下午线上用户反馈问题更多翻看记录发现当时只验证了 3 个 case而且都是自己顺手挑的。原因没有评估集没有基线单点验证把个例当规律。解决按第 4 章建 20 条评估集改 prompt 前先跑基线拿分改完跑回归对比分数不涨就回滚。这一套看着耗时间其实是提示词工程里性价比最高的一步——它把你从「感觉党」变成「数字党」也让你敢在团队里说「这次改动是有效的」。6. 一条 prompt 从 60 分调到 90 分先结构后参数的双层调试法6.1 双层调试流程第一层修结构第二层才动参数把一条半吊子 prompt 调成可用状态我用的方法是双层调试第一层只处理文本结构第二层才处理采样参数。第一层按顺序检查四样东西角色与任务边界、输出格式约束、示例质量、边界规则什么不答、怎么拒。第二层才轮到 temperature 那组参数。为什么坚持这个顺序因为结构问题会在任何参数下反复出现参数问题只会在特定参数区间出现。你拿一个角色不清的 prompt 去调温度调到 0 结果还是错的那就说明问题在第一层。改前改后的对比很直观改前 你是客服助手回答用户问题。 改后 你是某 app 的客服助手。只回答与 app 使用相关的问题 与 app 无关的问题回复「这个问题我无法回答请转人工」。 输出格式先给结论再给一句理由不超过 50 字。 示例 输入怎么改密码 输出设置页-账号安全-修改密码需要验证手机号。同样的任务改后多了边界、格式、示例三样东西输出立刻变得可测。第一层的毛病修完之后才允许自己动第二层的参数。6.2 改完 prompt 之后的五分钟自检改完一条 prompt我习惯再过一遍自检表五分钟能跑完检查项做法通过标准结构一致性temperature0 跑 5 条输入同输入多次输出格式一致边界行为喂 3 条不该答的输入正确拒绝不硬答回归跑完整评估集总分不低于基线参数验证按任务区间调温度无格式崩坏现在我的习惯是拿到一条新 prompt 先花 10 分钟把第一层做扎实再花 10 分钟过一遍自检表参数永远是最后才动的东西。这份 Google 提示工程 PDF 带给我的不是某个万能模板而是一套「结构优先、评估兜底」的调试次序。这套次序帮我少走了很多弯路希望帮到你。本文还有配套的精品资源点击获取