简介：《Goolge AI 提示工程指南（中文版）》是一份面向大语言模型使用者与开发者的系统化技术文档，适合数据科学家、机器学习工程师、软件开发者及对人工智能感兴趣的读者，帮助掌握从基础到进阶的提示设计方法。文档覆盖零样本、少样本、系统提示、角色提示、情境提示等基本技术，并深入讲解思维链、自我一致性、思维树、ReAct、代码提示、多模态提示与自动提示工程等高级方法，结合大量示例与最佳实践，可应用于代码生成、文本摘要、信息提取和问答系统等真实场景。资源为单个 PDF 文档，共 1 个文件，大小 7.12MB，内容编排完整，便于离线阅读与检索。目前已有 411 人学习浏览。文档强调提示工程的迭代属性，提供了多种实用模板和调试思路，无论是入门还是进阶，都能帮助读者优化提示质量，获得更稳定、更准确的模型输出。
1. 提示工程指南讲了什么：提示词不该靠“玄学”碰运气
很多人第一次拿到 Google 这份提示工程指南（中文版）PDF 时，第一反应是：提示词还需要专门学？我自己不是一直在写吗？可一旦真的开始做大模型应用，你会发现提示词就是整个系统最前置的入口——Agent 能不能正确调用工具、RAG 能不能给出可落地的答案、代码生成能不能一次跑通，全卡在这一段话上。这份指南最大的价值，是把提示词从“碰运气”变成了可拆解的工程方法：角色、指令、上下文、示例、输出格式五件事，每件都有明确写法。适合正在做 AI 应用开发、刚接触提示词工程、或者对模型输出稳定性不满意的从业者。它不是一本让你读完就会“召唤神级回答”的咒语书，而是一套可以照着执行、照着排查的工程手册。
2. 把提示拆成五个模块：角色、指令、上下文、示例、输出格式
2.1 角色设定不是“加一句废话”，它决定了模型调用的知识域
提示工程里最容易被人忽略的，是开头那句角色设定。很多人觉得“你是一个资深工程师”跟“请帮我写一段代码”没区别，实际上，角色会给模型一个隐性的知识域和语言风格约束。同一个问题，让模型以“运维专家”和“产品经理”的身份回答，输出的侧重点完全不同——这不是模型在表演，而是训练阶段它就学会了在不同角色语境下调用不同的知识分布。
我一般会建议把角色设定写成一个独立的提示行，放在所有指令之前，并用“你的任务是……”“你需要遵守……”这样的句式明确边界。Google 指南里反复强调的一点是：角色不能只给头衔，还要给职责范围。比如“你是一个Python后端工程师，熟悉FastAPI和PostgreSQL，擅长写生产级代码”就比“你是程序员”有用得多，因为后者没有给模型任何检索锚点。
这里给一个最小可用的提示模板，常见做法是直接在代码里拼字符串：
SYSTEM_PROMPT = """ 你是一个资深的大模型应用工程师。 你的职责： 1. 根据用户描述，设计可运行的提示词模板。 2. 输出必须包含：问题拆解、提示词正文、参数建议。 3. 如果信息不足，先列出你需要补充的内容，不要猜测。 用户描述：{user_request} """这段代码里，SYSTEM_PROMPT是系统级提示，{user_request}是运行时填充的用户输入。三行职责说明分别对应了“做什么”“输出什么”“做不到怎么办”三个维度。很多新手在写角色设定时，只会写“你是一个专家”，漏掉了职责边界，模型就开始自由发挥——这在提示词工程里叫“角色漂移”，是输出不稳定的头号原因。
2.2 指令要具体到可执行的粒度，而不是“帮我分析一下”
提示词工程里最常见的翻车现场，就是指令太抽象。“分析这份文档”“总结一下这段代码”“优化一下这个提示词”——这类指令的粒度是“目标级”的，模型不知道你要以什么视角分析、按什么结构总结、从哪些维度优化。指南里给的做法是：把指令拆成“动作 + 对象 + 约束”三段式。
比如“分析这份文档”，可以拆成：先提取文档中的关键实体，再判断实体间的因果关系，最后输出一份结构化报告，报告不超过300字，使用Markdown列表。这样模型每一步都有明确动作，产出物的形状也被框住了。如果允许模型先处理“提取”再处理“判断”，它的中间结果可以缓存，出问题时也方便定位是提取错了还是推理错了。
在代码里，我通常会用一个 Python 字典来管理指令的多个部分，而不是把一大段话硬拼接：
instruction = { "task": "提取文档中的关键技术名词", "constraint": "只输出名词列表，不解释", "format": "每行一个，按首字母排序", "context_limit": "只分析前2000字" } prompt = f""" 请完成以下任务： 1. 任务：{instruction['task']} 2. 约束：{instruction['constraint']} 3. 输出格式：{instruction['format']} 4. 范围：{instruction['context_limit']} 文档内容： {document_text[:2000]} """这套写法的好处是：指令的每个维度都可以独立调整，改约束时不会影响任务定义，跑测试时能清楚知道是哪一项改动导致了输出变化。参数说明上，document_text[:2000]是对上下文做截断，这个值不是固定的——如果模型上下文窗口大、文档关键信息靠后，可以放宽到 4000，但要注意截断位置尽量落在语义完整的边界上，避免从句子中间切断。
2.3 输出格式约束：比“请用JSON”更可靠的是给出Schema
“请用JSON格式回答”是提示词工程里最典型的无效指令之一。模型知道 JSON 是什么，但它不知道你的 JSON 需要哪些字段、字段类型是什么、嵌套关系怎么定。它可能给你一个包含多余字段的 JSON，或者把数组套错了层——解析时照样崩。Google 指南里给的关键思路是：与其说“用JSON”，不如直接把 JSON Schema 写进提示里。
output_schema = """ { "summary": "string, 不超过100字", "key_points": ["string"], "risk_level": "low | medium | high", "suggested_actions": [ {"action": "string", "owner": "string", "deadline": "string"} ] } """ prompt = f""" 根据以下内容生成分析报告。 必须严格按照下面的JSON结构输出，不要添加额外字段： {output_schema} 待分析内容：{content} """这段提示把输出结构变成了“填空模板”，模型要做的事情从“理解并组织一个JSON”降级成“照着字段填内容”，成功率会明显提升。注意这里的字段名我用了小写下划线风格——如果你接的后端代码用的是 camelCase，字段名也要跟着改，否则前端解析时又要写一层转换。输出格式约束这件事，本质上是在“模型的自由发挥空间”和“下游代码的可解析性”之间找平衡，Schema 写得越细，模型自由度越低，但成功率越高。
3. 从单轮问答到复杂推理：Few-shot、思维链与 ReAct 模式
3.1 Few-shot 示例怎么选、怎么排：不是越多越好
提示词工程里能立竿见影的手段，就是给示例。模型看过几个“输入→输出”对之后，会模仿这个模式去回答新问题。但示例不是越多越好——示例超过一定数量，收益会递减，而且如果示例之间风格不一致，模型会学习到“混乱的模式”，反而比不给示例更差。
选示例有三个原则：第一，示例要和真实输入分布接近，不要拿“完美样本”当示例，因为线上输入往往是带噪声的；第二，示例之间要有区分度，尽量覆盖不同的输入形态，比如一个长文本、一个短文本、一个带错误拼写的文本；第三，示例的排列顺序有讲究，我一般会把最典型的示例放在第一位，因为模型对开头内容的注意力权重更高。
few_shot_examples = [ { "input": "这个API返回超时，日志里没有错误信息", "output": "现象：API超时无日志。假设：请求未到达服务端或网关拦截。排查：先查网关访问日志，再查服务端入口日志。" }, { "input": "模型生成的JSON解析失败，报错expect value", "output": "现象：JSON解析失败。假设：输出包含多余文本或引号转义问题。排查：打印原始输出，检查前后是否存在非JSON内容。" } ] prompt = "请模仿下面示例的格式，对问题进行排查分析：\n\n" for ex in few_shot_examples: prompt += f"问题：{ex['input']}\n分析：{ex['output']}\n\n" prompt += f"问题：{user_question}\n分析："这段代码里每个示例的 output 都遵循“现象→假设→排查”三段式结构。模型学到的不只是“格式”，还学到了“遇到问题时先分现象、再给假设、最后给动作”的推理路径。参数说明：示例数量我一般控制在 2 到 5 个之间，超过 5 个以后，边际收益会明显下降，而且提示词变长、推理耗时增加、费用上升——在做提示词工程时，这些工程成本必须一起算进去。
3.2 思维链不是让模型“多想一步”，是让它把推理过程说出来
大模型在复杂推理任务上翻车，很多时候不是知识不够，而是跳步太狠。人做题时会在草稿纸上分步演算，模型同样需要这个空间。思维链（Chain-of-Thought）提示词的核心，就是明确要求模型把推理过程写出来，而不是直接给结论。
最简单的做法是零样本思维链：“请一步一步思考，然后给出答案”。这句提示在很多推理任务上都能带来效果提升。但注意，它有一个适用边界：当任务本身是常识性问答时，思维链可能没用甚至有害——因为模型会为了“展示思考过程”而编造不存在的推理逻辑。Google 指南里强调的是，思维链适合数学、逻辑、多步决策这类可以验证中间步骤的任务，不适合开放性创作。
prompt = """ 请按以下步骤回答用户问题： 1. 先列出问题中的关键条件和约束。 2. 逐步推理，每一步标注依据。 3. 最后用一句话给出结论。 题面：{question} """这里的“列出关键条件”“标注依据”是在模仿人类的草稿纸习惯。容易踩坑的地方是顺序——必须先让模型列出条件，再推理，否则模型会在第一步就直接给结论。如果你发现加了思维链后输出变长但质量没提升，可以尝试限定推理步数：比如“最多推理三步，每步不超过50字”。这个约束能防止模型在简单问题上过度推理，把输出控制在一个可读的范围内。
3.3 AI Agent 的工具调用提示：ReAct 模式怎么落进提示词
最近大家在折腾 AI Agent 时，提示词工程的重点已经从“让模型回答”变成了“让模型决定下一步动作”。ReAct 模式就是典型代表：推理（Reason）和行动（Act）交替进行——模型先分析当前状态，再选择调用哪个工具，观察工具返回结果后继续推理。这个循环的过程描述，完全可以通过提示词来控制。
agent_prompt = """ 你是系统管理员，可以调用以下工具： - search_log(service_name): 查询服务日志 - check_cpu(host): 查看服务器CPU使用率 - restart_service(service_name): 重启服务 你的工作流程： 1. 分析用户问题，确定需要哪些信息。 2. 调用工具获取信息，等待工具返回。 3. 根据返回结果判断下一步，必要时继续调用工具。 4. 问题解决后，输出最终结论。 用户问题：{task} """这段提示里最关键的是“等待工具返回”这句。没有这句时，模型经常在调用工具后自己脑补结果——它明明还没执行check_cpu，就假设 CPU 已经爆了。这是 Agent 搭建里非常典型的失败模式。另外，工具清单里的描述要包含参数说明，比如search_log(service_name)里的service_name要额外注明“必填，传服务名称，例如 order-service”——模型对工具参数的理解，完全依赖你在提示词里的描述粒度。
4. 代码提示与结构化输出：把大模型当成可靠的生产工具
4.1 代码生成的提示词：从“写个函数”到“写一个能跑的函数”
用 AI 编程辅助写代码时，最容易踩的坑是只给出功能描述而没给出约束。比如“写一个读取CSV文件的函数”，模型大概率会给你一个只处理理想情况的版本——没考虑文件不存在、字段缺失、编码异常。想让模型生成生产级代码，提示词里必须明确输入输出规格、异常处理策略、依赖限制。
code_prompt = """ 请用 Python 写一个函数，实现以下规格： - 函数名：load_csv_with_schema - 输入：file_path (str), schema (dict[str, str]) - 输出：list[dict] - 功能：读取CSV，按schema指定类型转换字段 - 异常处理：文件不存在时返回空列表；字段缺失时报错并指明字段名 - 禁止使用pandas，只用标准库csv schema格式示例：{{"id": "int", "name": "str", "price": "float"}} 只输出代码，不要解释。 """注意这段提示里的几个细节：输出格式明确说了“只输出代码，不要解释”——这能省掉你自己剥离 Markdown 代码块的麻烦；“禁止使用 pandas”是为了避免依赖冲突；“字段缺失时报错并指明字段名”是典型的异常路径约束，很多模型默认不处理这种情况。提示词工程在代码生成上的核心逻辑是：你定义清楚“什么算跑通”，模型才有可能跑通。
4.2 结构化输出的工程化做法：JSON 与函数调用的选择
上一章提到在提示词里嵌入 JSON Schema，但在真正的生产环境中，更可靠的做法是使用模型服务商提供的结构化输出能力——比如响应格式限定、强制 JSON 模式、或者函数调用。提示词工程到这一步就不再只是“写提示词”，而是“配置怎么用接口”。
client.chat.completions.create( model="gpt-4o", response_format={"type": "json_object"}, messages=[ {"role": "system", "content": "只输出JSON对象，不要输出其他文本"}, {"role": "user", "content": "将用户反馈分类，输出：{category, sentiment, priority}"} ] )跟纯提示词方案相比，response_format在接口层就约束了解码逻辑，模型根本不可能输出 JSON 以外的内容。这解决了一个很实际的问题：你在提示词里写“只输出JSON”，模型偶尔还是会在前面加一句“好的，这是结果：”——这行字会让下游的json.loads()直接炸掉。强制 JSON 模式相当于把提示词里的格式要求提到了协议层，稳定性远高于文本层约束。做 AI Agent 时，如果有工具调用能力，优先用工具调用而不是让模型自己在 JSON 里填action字段——前者的参数校验、中间状态管理都更成熟。
4.3 长文档场景：上下文窗口有限时，提示词怎么设计
大模型上下文窗口越来越大，但窗口大不等于效果好。把一份 5 万字文档全部塞进提示词，模型会陷入“注意力稀释”——开头结尾的信息保留度高，中间部分被忽略。提示词工程里对长文档的常见做法是分块处理：先切块，再逐块执行子任务，最后汇总。
def process_long_document(doc, chunk_size=3000): chunks = [doc[i:i+chunk_size] for i in range(0, len(doc), chunk_size)] summaries = [] for idx, chunk in enumerate(chunks): prompt = f""" 这是文档的第{idx+1}/{len(chunks)}部分。 提取本部分的关键信息点，每条不超过50字。 如果本部分无关键信息，回复"无"。 内容：{chunk} """ summaries.append(llm_call(prompt)) return summarize_all(summaries)这里的chunk_size是个关键参数。我一般会根据文档语言来调——中文文档可以放到 4000 字左右，因为中文的信息密度比英文高；英文文档 3000 字左右比较安全。切块时尽量按段落切，不要从句子中间断开。分块策略的本质，是把“一次处理不完”的问题拆成“多次处理没问题”的子任务，但代价是可能丢失跨区块的关联信息——如果文档的关键逻辑分布在多个块里，你要在最后的汇总提示里明确要求“整合各块之间的逻辑关系”，否则汇总结果会变成流水账。
5. 提示词排查清单：模型“不听话”的 5 个真实原因
5.1 现象：输出总是太笼统，全是正确的废话
原因：指令缺少约束维度。你说“总结这篇文章”，模型只能给最通用的总结；你说“从成本、时间、风险三个维度总结”，输出立刻具体。这是提示词工程里最常见的问题，也是最容易修的。
解决：给输出加“视角”和“边界”。在提示词中明确列出分析维度、字数限制、目标读者。比如“以技术负责人的视角，总结这个方案的迁移成本，不少于3条风险”——维度限制了内容范围，视角限制了语言风格，数字给模型提供了一个可感知的目标。
5.2 现象：加了 Few-shot 示例之后效果反而变差
原因：示例与目标任务的领域不一致，或者示例之间的模式不统一。模型不是只模仿示例的内容，它是在学习示例背后的规律——如果示例一会是“现象→结论”，一会是“先分析后建议”，模型就会困惑。
解决：检查示例是否来自真实分布，并且格式是否完全一致。我踩坑的经验是：示例宁缺毋滥，2 个高质量示例胜过 5 个随意写的示例。改完示例之后，先在 10 条验证集上手动跑一遍，别直接上生产。
5.3 现象：让模型输出 JSON，解析时总是报错
原因：两层问题——要么模型输出了 JSON 之外的内容，要么 JSON 本身不符合你的字段预期。前者用强制 JSON 模式解决；后者需要在提示词里给 Schema，不能只写“用JSON”。
解决：先打印模型的原始输出，看是不是有 Markdown 代码块包裹、尾部有多余逗号；再对着 Schema 检查字段名和类型。提示词里多写一句“不要输出Markdown代码块标记，直接输出JSON”可以避免一半的解析问题。
5.4 现象：提示词改了之后，线上效果不升反降
原因：你只测了几个手工例子，没跑回归集。提示词工程里有个隐蔽的坑：改了一个问题的写法，可能修复了 A 场景却在 B 场景翻车。没有评测集的“调优”都是赌博。
解决：每次修改保留一份旧版本提示词，新版本在同一条测试集上对比跑分。这是提示词工程的底线动作，否则你根本不知道改动是变好还是变差。
5.5 现象：提示词越长，模型越抓不住重点
原因：注意力被长上下文稀释。你把所有约束、背景、示例都塞进提示词，模型反而不知道哪些是核心指令。
解决：把最重要的指令放在提示词的开头和结尾——这是模型注意力最高的两个位置；次要信息放中间。另外，提示词里的每个句子都要问一句“删掉它会影响输出吗”，不影响就删。提示词的“瘦身”跟代码重构一样，是持续的动作，不是一次性的。
6. 给提示词上版本管理：用回归评测让每次调参都有后悔药
最后一件事建议你尽早做：给提示词建一个回归评测集。不需要很庞大，20 到 30 条有代表性的输入就够了，覆盖你系统里最核心的几种场景。每次修改提示词，跑一遍全部用例，把输出存到文件里，再和上一个版本对比。这个习惯能救你无数次。
# 简单的回归评测脚本 test_cases = [ {"prompt_id": "summary_v1", "input": "..."}, {"prompt_id": "summary_v1", "input": "..."}, ] def run_eval(prompt_template, cases): results = [] for case in cases: output = llm_call(prompt_template.format(**case)) results.append({"case": case["input"], "output": output}) return results # 每次改版本，保存一份结果 results_v2 = run_eval(prompt_template_v2, test_cases) save_results("results_v2.json", results_v2)对比两个版本时，不要只凭感觉判断“读起来顺了”。逐条对照输入输出，标注“变好”“变差”“持平”，再决定是否合并改动。如果改动的目标是提升某类场景的效果，就重点看那类场景的用例是否都变好了——局部提升很容易，全局稳定才是难点。有条件的话，可以让模型充当评审员：用另一个模型对比新旧输出，按“准确性、完整性、格式合规”三个维度打分。但要记住，模型评审也有自己的偏好，所以最终拿主意的还得是你本人。
提示词写久了你会发现，这份指南真正教会你的不是怎么“写好一句话”，而是怎么把模型行为当成一个可以测量、可以比较、可以回溯的系统来治理。我自己踩过太多次“翻车后不知道是哪句话导致的”的坑，后来老老实实把每个版本存下来，每条改动配一行说明，线上出了问题直接回滚上一版。这套方法不高级，但有效。希望帮到你。
本文还有配套的精品资源，点击获取
