尧图网站建设 
简介《google提示工程.pdf》是一份面向具备编程基础的开发者、数据科学家与机器学习工程师的提示工程实用指南系统讲解如何为大语言模型编写高质量提示适用于文本生成、代码编写、调试审查、数据解析等常见任务。内容从模型输出配置入手详细拆解输出长度、Temperature、Top-K/Top-P 等采样参数的影响并逐项介绍零样本、少样本、系统提示、角色提示、上下文提示、思维链、自我一致性、思维树、ReAct 以及自动提示工程APE等主流方法。文档配有大量实例和代码片段既说明“如何写提示”也总结“如何调优”包括善用示例、保持简洁、明确输出要求、优先指令而非限制、实验 JSON 输出、记录每次尝试并与他人协作等最佳实践同时强调要随模型更新持续迭代提示词。资源包内含 1 个 PDF 文件压缩包大小约 1018KB便于离线通读已有 394 人浏览学习。对想系统提升大模型交互效果、优化代码生成与逻辑推理的读者来说是一份高性价比的参考资料。1. 提示词工程在 Google 生态里的位置提示工程 PDF 解决的三个实际问题提示词工程在 Google 生态里不是单纯的“把话问漂亮”而是面向 Gemini 系列以及 Vertex AI、AI Studio 上托管模型的提示设计与调优方法。一份以《google提示工程.pdf》为名的资料锁定的主题就在这为什么同样一个需求别人用 Gemini 一次返回就是能直接入库的 JSON自己写的提示却返回格式错乱、逻辑断裂甚至直接拒绝执行的结果。它适合三类人——在 Google Cloud 上做 AI 功能落地的后端开发者、给 RAG 和 Agent 应用做提示编排的工程师、想把大模型接进内部流程的架构选型者。你这三类身份无论占哪一类最终诉求都是同一个把模型输出从“可用”变成“可控”。本文按“原理 → 操作 → 踩坑 → 进阶”拆这条路径读完你能从“填 prompt”升级为“控输出”。2. 先立住原理Google 系模型的提示结构、解码参数与上下文设计在动手调提示之前先搞清楚 Google 系模型和 OpenAI 系模型在提示格式上的差异。Gemini API 的请求体里有三个角色system、user、model。system 角色负责立规则user 角色放任务model 角色是模型的回复也可以用来放少样本示例。很多从 GPT 系转过来的人第一个翻车点就是把大量任务细节塞进系统指令导致模型回复变得机械呆板。原因在于 system 的角色是“约束行为”而不是“承载任务”任务描述、输入数据、期望输出结构这些应该出现在 user 消息里。系统指令里该放什么放那些“不管任务怎么变都不能变”的规则比如输出语言、格式要求、禁止事项、安全边界。做客服工单分类时系统指令只写“你是客户反馈分类助手只输出类别词不输出解释”把具体反馈文本放到 user 消息里。这条边界划清楚后续调参和排错才有基准线。2.1 系统指令与用户消息的边界在 AI Studio 里怎么验证差异以 Google AI Studio 为例界面左侧有 System Instructions 输入框下方是对话输入区。一个值得做的实验是第一次把完整任务放进系统指令第二次把同样内容放到用户消息里对比两者在 Gemini 系列模型上的表现。我做过多次验证结论倾向于后者对复杂业务规则的遵守度更高。原因是系统指令在长对话中起的是“隐性约束”作用模型把它当成设定而非当前请求当任务细节很多时模型倾向于简化处理导致细粒度要求失真。因此边界划分的习惯可以固定为系统指令只用三到五句话描述角色和硬性约束任务本身放 user输出格式要求放在任务末尾用独立的“输出格式”段说明。这个习惯和 Google 官方提示工程指南中“上下文 任务 输出格式 约束”的四段式结构对应得上。四段式里前两段都在 user 消息里输出格式也在 user 消息末尾系统指令只承担角色定义和全局禁止事项。这样划分后模型的输出一致性会有明显提升。2.2 temperature、top_k、top_p 三颗旋钮怎么配合参数表与业务场景对应Gemini API 里能调的解码参数有三个temperature、top_p、top_k。注意这和 GPT 系不同——GPT 系列主要用 temperature 和 top_ptop_k 只是可选而在 Google 的 API 和 AI Studio 里top_k 是显式暴露出来的。top_k 控制每次生成时模型考虑候选词的数量top_p 控制累积概率temperature 控制概率分布的平坦程度。三个参数都影响随机性但作用层面不一样。参数取值范围作用推荐场景temperature0 ~ 1 或 0 ~ 2不同模型上限不同概率分布平坦度越高越随机0.0-0.3 分类/抽取/格式化0.4-0.7 改写/摘要0.8 创意写作top_k1 ~ 40部分模型更高从概率最高的前 k 个词里采样默认 20 可覆盖多数任务追求稳定可降到 10top_p0 ~ 1从累积概率达 p 的候选集合采样0.8 附近微调与 top_k 同时调时先固定一个这里有个易走弯路的点三个参数不是等价的随机性控制。temperature 调高会让模型在低置信区更“敢说”top_k 收紧是直接砍掉低概率词top_p 则是动态收缩候选集合。实际调参顺序我一般建议先固定 temperature再单独动 top_k 和 top_p一次只动一个变量。不要同时把 temperature 拉到 1.0 又把 top_k 拉到 40否则输出天马行空出了问题却分不清是哪颗旋钮造成的。2.3 上下文设计多轮对话里任务约束如何保持提示工程资料里常出现一个场景模型在前两轮表现很好到第五轮开始夹带无关内容、丢失指定格式。原因在于多轮对话里模型对最近的 user 消息关注度最高系统指令和首条 user 消息的约束力会随轮次衰减。Google 系模型虽然上下文窗口很长但这种约束力衰减依然存在只是不同模型版本衰减速度不同。处理方法有两条。第一条是轮次精简与业务无关的中间对话不进入下一次请求每次请求只带「系统指令 最新任务 必要的历史摘要」。第二条是约束重申在最新一条 user 消息里重复核心输出要求比如每轮请求末尾都加一句“仍按第 1 轮约定的 JSON 格式输出”。这在 RAG 应用里尤其重要因为多轮检索会积累大量历史消息模型很容易把检索结果当用户输入直接输出。保持请求体精简比把整个 session 历史都塞给模型更可靠。3. 动手落地从 AI Studio 验证到 Gemini API 固化的完整链路原理立住之后进入可以照着做的部分。整条链路分三步先在 AI Studio 界面里把提示调到稳定再用 Python SDK 固化成模板代码最后用版本管理控制提示的改动轨迹。这三步对应提示词工程从“临时对话”到“可交付代码”的转变。3.1 在 AI Studio 里先调通最小可用提示第一步建议不要直接写代码而是打开 Google AI Studio选一个支持文本生成的 Gemini 模型常见做法是选当前默认的 flash 版本响应快、成本低先把提示在对话框里调通。所谓最小可用提示指的不是把需求写得最短而是把输出稳定地限制到“解析一次就能用”的最低成本状态。最小可用提示模板如下你是客户反馈分类助手。你的任务是把用户反馈归类为投诉、建议、咨询。 规则 1. 只输出一个类别词不要输出解释。 2. 无法判断时输出“咨询”。 用户反馈{input}这里的 {input} 在 AI Studio 里可以直接换成测试文本。注意规则两条就够不要罗列十几条——规则越多模型越难权衡容易互相冲突。AI Studio 右侧的 Parameters 面板可以实时调 temperature先把温度设为 0.2连续跑 5 条不同反馈观察分类稳定性。这一步的验收标准是连续 5 条输入模型输出全部是类别词且分类合理。达到这个标准再进入代码固化阶段。3.2 用 google-genai SDK 把提示模板固化成 Python 代码提示在 AI Studio 里调通后接下来固化成代码。Google 官方的 Python SDK 包名是 google-genai安装命令是pip install google-genai。代码的关键不在于复杂而在于把「系统指令、任务模板、参数、输出解析」四个部分拆开方便后续维护。# -*- coding: utf-8 -*- from google import genai from google.genai import types client genai.Client(api_keyYOUR_API_KEY) SYSTEM_INSTRUCTION ( 你是客户反馈分类助手。 把用户反馈归类为投诉、建议、咨询。 只输出类别词不输出解释。 无法判断时输出咨询。 ) def classify_feedback(user_input: str) - str: response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instructionSYSTEM_INSTRUCTION, temperature0.2, top_p0.8, top_k10, ), contentsuser_input, ) return response.text.strip()这段代码做了四件事定义系统指令常量、把任务参数放进 contents、在 config 里设置解码参数、剥离输出空白字符后返回。temperature0.2 是为了让分类结果尽量稳定top_k10 相比默认的 20 更保守能减少低概率词的干扰。如果你的业务对响应时间敏感可以把 model 换成当前项目里有权限的最新 flash 版本接口签名不变只需改模型名。提示API Key 不要硬编码在代码里。常见做法是放到环境变量中用os.getenv(GEMINI_API_KEY)读取避免把密钥提交到 Git 仓库。3.3 少样本示例的模板化写法单靠指令在某些任务上稳定不住典型场景是格式复杂的输出比如把一句话转成带多个字段的 JSON。这时候少样本示例比多写十条规则更有效。Gemini API 支持在 contents 里传多轮消息来构造示例让模型从示例对中推断输出模式。few_shot_contents [ types.Content(roleuser, parts[types.Part(text你们的App闪退重装了也不行)]), types.Content(rolemodel, parts[types.Part(text投诉)]), types.Content(roleuser, parts[types.Part(text希望增加夜间模式晚上太亮)]), types.Content(rolemodel, parts[types.Part(text建议)]), types.Content(roleuser, parts[types.Part(text退款什么时候到账)]), ] response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instruction你是客服反馈分类助手输出的类别只能是投诉、建议、咨询。, temperature0.1, ), contentsfew_shot_contents, ) print(response.text) # 期望输出: 咨询这个写法的关键点是 role 顺序必须严格交替user、model、user、model、最后再 user。前四段是示例最后一段是真实任务。很多从 GPT 系转过来的人习惯把示例塞进系统指令这在 Gemini 上不是最佳做法——系统指令里堆示例会拉长指令且示例权重不如对话序列中显式出现的交替结构高。少样本示例的数量控制在 2 到 5 个之间最稳妥少于 2 个模型学不到模式多于 5 个模型可能开始模仿示例中的噪声。4. 避坑与排查提示词工程里最容易翻车的 5 个位置这一章是血泪经验合集。以下五个坑在实际业务里反复出现每一条按「现象 → 原因 → 解决」记录。排查顺序也建议按这个优先级来先解决格式问题再处理逻辑问题最后治理上下文和版本问题。4.1 指定 JSON 输出模型却返回 Markdown 代码块现象提示里写了“以 JSON 格式输出”response.text 拿到的却是json\n{...}\njson.loads 直接报错。这在 flash 系列模型上非常常见。原因模型默认习惯里JSON 输出通常会带代码块语法高亮尤其是提示里出现“JSON”这个英文词时模型更倾向于按 Markdown 格式包裹。解决第一在提示里显式写“直接输出 JSON 对象不要用 Markdown 代码块包裹不要包含注释”第二更可靠的方式是使用 Google API 的结构化输出能力不靠措辞约束。response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instruction你是数据抽取助手。, temperature0, response_mime_typeapplication/json, response_schema{ type: object, properties: { category: {type: string, enum: [投诉, 建议, 咨询]}, confidence: {type: number}, }, required: [category], }, ), contents你们的App闪退, ) print(response.text)response_mime_type 和 response_schema 是 Google API 里结构化输出的标准做法。设置之后模型端就按 schema 约束生成返回的 text 是纯 JSON。enum 字段可以把分类值锁死比任何文字提示都可靠。处理格式问题时这条路径优先于措辞调整。4.2 temperature 调高后逻辑断裂现象把 temperature 调到 1.0 做多轮对话模型在第三轮开始自相矛盾比如先断言“该方案成本最低”后一句又“该方案成本最高”。原因temperature 的作用范围是整个序列生成过程高温度让每个位置的采样波动变大约束力在长输出中被逐步放大。解决不是所有任务都需要高温度。分类、抽取、格式化、代码生成用 0 到 0.3摘要和改写用 0.4 到 0.7开放式头脑风暴才适合 0.8 以上。如果任务既要创造性又要逻辑自洽把温度设在 0.4 附近把创造性放在任务描述层面而不是交给解码参数。4.3 长上下文里中段信息被忽略现象向 Gemini 传了包含多页文档的上下文任务是“依据第 3 段内容回答问题”结果模型返回的是第 1 段和第 8 段的内容。原因长上下文场景下模型对中间位置的注意力权重显著低于首尾两段业界称之为 lost in the middle。Google 系模型的上下文窗口很长但注意力分布并非均匀。解决从提示层面做三点处理。第一把最重要的约束和任务放到系统指令和最后一条 user 消息里第二需要参照的长文档按重要性排序核心片段前置或直接摘出关键段放进 user 消息第三在请求里明确“请严格依据以下段落回答忽略其他段落”并附上精简后的文本。不要靠拉长上下文窗口来解决问题先做检索和切片。4.4 少样本示例反噬现象为了教模型模仿输出风格在提示里放了 8 个示例结果模型把示例中的语气一并模仿甚至把示例里的领域名词当成正确答案输出。原因示例数量和内容质量相互博弈。示例过多时模型把示例当作“标准答案”而不是“格式参考”尤其当示例里包含否定句时模型容易学到错误模式。解决示例控制在 2 到 5 个每个示例只演示一种格式变体并在系统指令里说明“以上是格式示例不是真实数据答案”。如果模型仍然模仿示例内容把示例减到两条并在示例与真实任务之间插入一条分隔消息“以下开始真实任务”。4.5 提示版本失控现象昨天调好的提示今天被同事改了一句话输出格式全崩排查半天发现是有人直接改了源代码里的 prompt 字符串。原因提示文本没有被当作代码资产管理。提示词工程里最容易翻车的就是隐式改动——没有版本记录、没有变更说明、没有回归测试。解决把提示常量抽成独立文件用 Git 管理。每次改动后跑测试用例做回归。命名用可追溯的编号变更日志写在文件头部注释里。# PROMPT_分类_v3 # 变更记录: # v2: 增加无法判断时输出咨询兜底规则 # v3: 简化规则数量, 从7条精简为3条, 修复过度拒绝问题 SYSTEM_INSTRUCTION_V3 ( 你是客户反馈分类助手。 把用户反馈归类为: 投诉、建议、咨询。 只输出类别词。无法判断时输出咨询。 )5. 进阶用法用回归测试集锁定提示质量把改提示变成改代码提示的改动具有“改善一个样本、弄坏另五个样本”的特点所以最后一个值得投入的关键动作是建立回归测试集。做法不复杂把业务里真正会遇到的 15 到 30 条输入样本固化成测试用例每条带期望输出以后每次改动系统指令或解码参数都跑一遍测试集观察通过率和失败类型。样本的选择思路是覆盖边界——短文本、超长文本、带数字的、带情绪的、带错别字的、非中文的内容各准备几个。边界样本的作用不是让测试全过而是让失败模式暴露得足够明显。import pytest from your_prompt_module import classify_feedback CASES [ (你们的App闪退重装了也不行, 投诉), (希望增加夜间模式, 建议), (退款什么时候到账, 咨询), (, 咨询), (App是垃圾我不用了, 投诉), ] pytest.mark.parametrize(text,expected, CASES) def test_classify_returns_expected(text, expected): result classify_feedback(text) assert result expected这个测试集的验收标准不是 100% 通过而是每次改动提示后通过率的趋势可对比。如果 v3 比 v2 的通过率低了 10 个百分点就要回滚或继续迭代。我在自己的项目里养成的习惯是每版提示都记录一份测试通过率和平均响应延迟这两个指标在模型升级时特别有用——比如从 Gemini 1.5 切到 2.x 系列后能立刻判断新模型对现有提示是变友好了还是变敏感了。提示词工程走到这一步才算真正从“调提示”变成了“维护提示系统”。希望帮到你。本文还有配套的精品资源点击获取 Google提示词工程实战：从Gemini API到可控输出
简介《google提示工程.pdf》是一份面向具备编程基础的开发者、数据科学家与机器学习工程师的提示工程实用指南系统讲解如何为大语言模型编写高质量提示适用于文本生成、代码编写、调试审查、数据解析等常见任务。内容从模型输出配置入手详细拆解输出长度、Temperature、Top-K/Top-P 等采样参数的影响并逐项介绍零样本、少样本、系统提示、角色提示、上下文提示、思维链、自我一致性、思维树、ReAct 以及自动提示工程APE等主流方法。文档配有大量实例和代码片段既说明“如何写提示”也总结“如何调优”包括善用示例、保持简洁、明确输出要求、优先指令而非限制、实验 JSON 输出、记录每次尝试并与他人协作等最佳实践同时强调要随模型更新持续迭代提示词。资源包内含 1 个 PDF 文件压缩包大小约 1018KB便于离线通读已有 394 人浏览学习。对想系统提升大模型交互效果、优化代码生成与逻辑推理的读者来说是一份高性价比的参考资料。1. 提示词工程在 Google 生态里的位置提示工程 PDF 解决的三个实际问题提示词工程在 Google 生态里不是单纯的“把话问漂亮”而是面向 Gemini 系列以及 Vertex AI、AI Studio 上托管模型的提示设计与调优方法。一份以《google提示工程.pdf》为名的资料锁定的主题就在这为什么同样一个需求别人用 Gemini 一次返回就是能直接入库的 JSON自己写的提示却返回格式错乱、逻辑断裂甚至直接拒绝执行的结果。它适合三类人——在 Google Cloud 上做 AI 功能落地的后端开发者、给 RAG 和 Agent 应用做提示编排的工程师、想把大模型接进内部流程的架构选型者。你这三类身份无论占哪一类最终诉求都是同一个把模型输出从“可用”变成“可控”。本文按“原理 → 操作 → 踩坑 → 进阶”拆这条路径读完你能从“填 prompt”升级为“控输出”。2. 先立住原理Google 系模型的提示结构、解码参数与上下文设计在动手调提示之前先搞清楚 Google 系模型和 OpenAI 系模型在提示格式上的差异。Gemini API 的请求体里有三个角色system、user、model。system 角色负责立规则user 角色放任务model 角色是模型的回复也可以用来放少样本示例。很多从 GPT 系转过来的人第一个翻车点就是把大量任务细节塞进系统指令导致模型回复变得机械呆板。原因在于 system 的角色是“约束行为”而不是“承载任务”任务描述、输入数据、期望输出结构这些应该出现在 user 消息里。系统指令里该放什么放那些“不管任务怎么变都不能变”的规则比如输出语言、格式要求、禁止事项、安全边界。做客服工单分类时系统指令只写“你是客户反馈分类助手只输出类别词不输出解释”把具体反馈文本放到 user 消息里。这条边界划清楚后续调参和排错才有基准线。2.1 系统指令与用户消息的边界在 AI Studio 里怎么验证差异以 Google AI Studio 为例界面左侧有 System Instructions 输入框下方是对话输入区。一个值得做的实验是第一次把完整任务放进系统指令第二次把同样内容放到用户消息里对比两者在 Gemini 系列模型上的表现。我做过多次验证结论倾向于后者对复杂业务规则的遵守度更高。原因是系统指令在长对话中起的是“隐性约束”作用模型把它当成设定而非当前请求当任务细节很多时模型倾向于简化处理导致细粒度要求失真。因此边界划分的习惯可以固定为系统指令只用三到五句话描述角色和硬性约束任务本身放 user输出格式要求放在任务末尾用独立的“输出格式”段说明。这个习惯和 Google 官方提示工程指南中“上下文 任务 输出格式 约束”的四段式结构对应得上。四段式里前两段都在 user 消息里输出格式也在 user 消息末尾系统指令只承担角色定义和全局禁止事项。这样划分后模型的输出一致性会有明显提升。2.2 temperature、top_k、top_p 三颗旋钮怎么配合参数表与业务场景对应Gemini API 里能调的解码参数有三个temperature、top_p、top_k。注意这和 GPT 系不同——GPT 系列主要用 temperature 和 top_ptop_k 只是可选而在 Google 的 API 和 AI Studio 里top_k 是显式暴露出来的。top_k 控制每次生成时模型考虑候选词的数量top_p 控制累积概率temperature 控制概率分布的平坦程度。三个参数都影响随机性但作用层面不一样。参数取值范围作用推荐场景temperature0 ~ 1 或 0 ~ 2不同模型上限不同概率分布平坦度越高越随机0.0-0.3 分类/抽取/格式化0.4-0.7 改写/摘要0.8 创意写作top_k1 ~ 40部分模型更高从概率最高的前 k 个词里采样默认 20 可覆盖多数任务追求稳定可降到 10top_p0 ~ 1从累积概率达 p 的候选集合采样0.8 附近微调与 top_k 同时调时先固定一个这里有个易走弯路的点三个参数不是等价的随机性控制。temperature 调高会让模型在低置信区更“敢说”top_k 收紧是直接砍掉低概率词top_p 则是动态收缩候选集合。实际调参顺序我一般建议先固定 temperature再单独动 top_k 和 top_p一次只动一个变量。不要同时把 temperature 拉到 1.0 又把 top_k 拉到 40否则输出天马行空出了问题却分不清是哪颗旋钮造成的。2.3 上下文设计多轮对话里任务约束如何保持提示工程资料里常出现一个场景模型在前两轮表现很好到第五轮开始夹带无关内容、丢失指定格式。原因在于多轮对话里模型对最近的 user 消息关注度最高系统指令和首条 user 消息的约束力会随轮次衰减。Google 系模型虽然上下文窗口很长但这种约束力衰减依然存在只是不同模型版本衰减速度不同。处理方法有两条。第一条是轮次精简与业务无关的中间对话不进入下一次请求每次请求只带「系统指令 最新任务 必要的历史摘要」。第二条是约束重申在最新一条 user 消息里重复核心输出要求比如每轮请求末尾都加一句“仍按第 1 轮约定的 JSON 格式输出”。这在 RAG 应用里尤其重要因为多轮检索会积累大量历史消息模型很容易把检索结果当用户输入直接输出。保持请求体精简比把整个 session 历史都塞给模型更可靠。3. 动手落地从 AI Studio 验证到 Gemini API 固化的完整链路原理立住之后进入可以照着做的部分。整条链路分三步先在 AI Studio 界面里把提示调到稳定再用 Python SDK 固化成模板代码最后用版本管理控制提示的改动轨迹。这三步对应提示词工程从“临时对话”到“可交付代码”的转变。3.1 在 AI Studio 里先调通最小可用提示第一步建议不要直接写代码而是打开 Google AI Studio选一个支持文本生成的 Gemini 模型常见做法是选当前默认的 flash 版本响应快、成本低先把提示在对话框里调通。所谓最小可用提示指的不是把需求写得最短而是把输出稳定地限制到“解析一次就能用”的最低成本状态。最小可用提示模板如下你是客户反馈分类助手。你的任务是把用户反馈归类为投诉、建议、咨询。 规则 1. 只输出一个类别词不要输出解释。 2. 无法判断时输出“咨询”。 用户反馈{input}这里的 {input} 在 AI Studio 里可以直接换成测试文本。注意规则两条就够不要罗列十几条——规则越多模型越难权衡容易互相冲突。AI Studio 右侧的 Parameters 面板可以实时调 temperature先把温度设为 0.2连续跑 5 条不同反馈观察分类稳定性。这一步的验收标准是连续 5 条输入模型输出全部是类别词且分类合理。达到这个标准再进入代码固化阶段。3.2 用 google-genai SDK 把提示模板固化成 Python 代码提示在 AI Studio 里调通后接下来固化成代码。Google 官方的 Python SDK 包名是 google-genai安装命令是pip install google-genai。代码的关键不在于复杂而在于把「系统指令、任务模板、参数、输出解析」四个部分拆开方便后续维护。# -*- coding: utf-8 -*- from google import genai from google.genai import types client genai.Client(api_keyYOUR_API_KEY) SYSTEM_INSTRUCTION ( 你是客户反馈分类助手。 把用户反馈归类为投诉、建议、咨询。 只输出类别词不输出解释。 无法判断时输出咨询。 ) def classify_feedback(user_input: str) - str: response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instructionSYSTEM_INSTRUCTION, temperature0.2, top_p0.8, top_k10, ), contentsuser_input, ) return response.text.strip()这段代码做了四件事定义系统指令常量、把任务参数放进 contents、在 config 里设置解码参数、剥离输出空白字符后返回。temperature0.2 是为了让分类结果尽量稳定top_k10 相比默认的 20 更保守能减少低概率词的干扰。如果你的业务对响应时间敏感可以把 model 换成当前项目里有权限的最新 flash 版本接口签名不变只需改模型名。提示API Key 不要硬编码在代码里。常见做法是放到环境变量中用os.getenv(GEMINI_API_KEY)读取避免把密钥提交到 Git 仓库。3.3 少样本示例的模板化写法单靠指令在某些任务上稳定不住典型场景是格式复杂的输出比如把一句话转成带多个字段的 JSON。这时候少样本示例比多写十条规则更有效。Gemini API 支持在 contents 里传多轮消息来构造示例让模型从示例对中推断输出模式。few_shot_contents [ types.Content(roleuser, parts[types.Part(text你们的App闪退重装了也不行)]), types.Content(rolemodel, parts[types.Part(text投诉)]), types.Content(roleuser, parts[types.Part(text希望增加夜间模式晚上太亮)]), types.Content(rolemodel, parts[types.Part(text建议)]), types.Content(roleuser, parts[types.Part(text退款什么时候到账)]), ] response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instruction你是客服反馈分类助手输出的类别只能是投诉、建议、咨询。, temperature0.1, ), contentsfew_shot_contents, ) print(response.text) # 期望输出: 咨询这个写法的关键点是 role 顺序必须严格交替user、model、user、model、最后再 user。前四段是示例最后一段是真实任务。很多从 GPT 系转过来的人习惯把示例塞进系统指令这在 Gemini 上不是最佳做法——系统指令里堆示例会拉长指令且示例权重不如对话序列中显式出现的交替结构高。少样本示例的数量控制在 2 到 5 个之间最稳妥少于 2 个模型学不到模式多于 5 个模型可能开始模仿示例中的噪声。4. 避坑与排查提示词工程里最容易翻车的 5 个位置这一章是血泪经验合集。以下五个坑在实际业务里反复出现每一条按「现象 → 原因 → 解决」记录。排查顺序也建议按这个优先级来先解决格式问题再处理逻辑问题最后治理上下文和版本问题。4.1 指定 JSON 输出模型却返回 Markdown 代码块现象提示里写了“以 JSON 格式输出”response.text 拿到的却是json\n{...}\njson.loads 直接报错。这在 flash 系列模型上非常常见。原因模型默认习惯里JSON 输出通常会带代码块语法高亮尤其是提示里出现“JSON”这个英文词时模型更倾向于按 Markdown 格式包裹。解决第一在提示里显式写“直接输出 JSON 对象不要用 Markdown 代码块包裹不要包含注释”第二更可靠的方式是使用 Google API 的结构化输出能力不靠措辞约束。response client.models.generate_content( modelgemini-2.0-flash, configtypes.GenerateContentConfig( system_instruction你是数据抽取助手。, temperature0, response_mime_typeapplication/json, response_schema{ type: object, properties: { category: {type: string, enum: [投诉, 建议, 咨询]}, confidence: {type: number}, }, required: [category], }, ), contents你们的App闪退, ) print(response.text)response_mime_type 和 response_schema 是 Google API 里结构化输出的标准做法。设置之后模型端就按 schema 约束生成返回的 text 是纯 JSON。enum 字段可以把分类值锁死比任何文字提示都可靠。处理格式问题时这条路径优先于措辞调整。4.2 temperature 调高后逻辑断裂现象把 temperature 调到 1.0 做多轮对话模型在第三轮开始自相矛盾比如先断言“该方案成本最低”后一句又“该方案成本最高”。原因temperature 的作用范围是整个序列生成过程高温度让每个位置的采样波动变大约束力在长输出中被逐步放大。解决不是所有任务都需要高温度。分类、抽取、格式化、代码生成用 0 到 0.3摘要和改写用 0.4 到 0.7开放式头脑风暴才适合 0.8 以上。如果任务既要创造性又要逻辑自洽把温度设在 0.4 附近把创造性放在任务描述层面而不是交给解码参数。4.3 长上下文里中段信息被忽略现象向 Gemini 传了包含多页文档的上下文任务是“依据第 3 段内容回答问题”结果模型返回的是第 1 段和第 8 段的内容。原因长上下文场景下模型对中间位置的注意力权重显著低于首尾两段业界称之为 lost in the middle。Google 系模型的上下文窗口很长但注意力分布并非均匀。解决从提示层面做三点处理。第一把最重要的约束和任务放到系统指令和最后一条 user 消息里第二需要参照的长文档按重要性排序核心片段前置或直接摘出关键段放进 user 消息第三在请求里明确“请严格依据以下段落回答忽略其他段落”并附上精简后的文本。不要靠拉长上下文窗口来解决问题先做检索和切片。4.4 少样本示例反噬现象为了教模型模仿输出风格在提示里放了 8 个示例结果模型把示例中的语气一并模仿甚至把示例里的领域名词当成正确答案输出。原因示例数量和内容质量相互博弈。示例过多时模型把示例当作“标准答案”而不是“格式参考”尤其当示例里包含否定句时模型容易学到错误模式。解决示例控制在 2 到 5 个每个示例只演示一种格式变体并在系统指令里说明“以上是格式示例不是真实数据答案”。如果模型仍然模仿示例内容把示例减到两条并在示例与真实任务之间插入一条分隔消息“以下开始真实任务”。4.5 提示版本失控现象昨天调好的提示今天被同事改了一句话输出格式全崩排查半天发现是有人直接改了源代码里的 prompt 字符串。原因提示文本没有被当作代码资产管理。提示词工程里最容易翻车的就是隐式改动——没有版本记录、没有变更说明、没有回归测试。解决把提示常量抽成独立文件用 Git 管理。每次改动后跑测试用例做回归。命名用可追溯的编号变更日志写在文件头部注释里。# PROMPT_分类_v3 # 变更记录: # v2: 增加无法判断时输出咨询兜底规则 # v3: 简化规则数量, 从7条精简为3条, 修复过度拒绝问题 SYSTEM_INSTRUCTION_V3 ( 你是客户反馈分类助手。 把用户反馈归类为: 投诉、建议、咨询。 只输出类别词。无法判断时输出咨询。 )5. 进阶用法用回归测试集锁定提示质量把改提示变成改代码提示的改动具有“改善一个样本、弄坏另五个样本”的特点所以最后一个值得投入的关键动作是建立回归测试集。做法不复杂把业务里真正会遇到的 15 到 30 条输入样本固化成测试用例每条带期望输出以后每次改动系统指令或解码参数都跑一遍测试集观察通过率和失败类型。样本的选择思路是覆盖边界——短文本、超长文本、带数字的、带情绪的、带错别字的、非中文的内容各准备几个。边界样本的作用不是让测试全过而是让失败模式暴露得足够明显。import pytest from your_prompt_module import classify_feedback CASES [ (你们的App闪退重装了也不行, 投诉), (希望增加夜间模式, 建议), (退款什么时候到账, 咨询), (, 咨询), (App是垃圾我不用了, 投诉), ] pytest.mark.parametrize(text,expected, CASES) def test_classify_returns_expected(text, expected): result classify_feedback(text) assert result expected这个测试集的验收标准不是 100% 通过而是每次改动提示后通过率的趋势可对比。如果 v3 比 v2 的通过率低了 10 个百分点就要回滚或继续迭代。我在自己的项目里养成的习惯是每版提示都记录一份测试通过率和平均响应延迟这两个指标在模型升级时特别有用——比如从 Gemini 1.5 切到 2.x 系列后能立刻判断新模型对现有提示是变友好了还是变敏感了。提示词工程走到这一步才算真正从“调提示”变成了“维护提示系统”。希望帮到你。本文还有配套的精品资源点击获取