简介《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( modelgpt-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_size3000): chunks [doc[i:ichunk_size] for i in range(0, len(doc), chunk_size)] summaries [] for idx, chunk in enumerate(chunks): prompt f 这是文档的第{idx1}/{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)对比两个版本时不要只凭感觉判断“读起来顺了”。逐条对照输入输出标注“变好”“变差”“持平”再决定是否合并改动。如果改动的目标是提升某类场景的效果就重点看那类场景的用例是否都变好了——局部提升很容易全局稳定才是难点。有条件的话可以让模型充当评审员用另一个模型对比新旧输出按“准确性、完整性、格式合规”三个维度打分。但要记住模型评审也有自己的偏好所以最终拿主意的还得是你本人。提示词写久了你会发现这份指南真正教会你的不是怎么“写好一句话”而是怎么把模型行为当成一个可以测量、可以比较、可以回溯的系统来治理。我自己踩过太多次“翻车后不知道是哪句话导致的”的坑后来老老实实把每个版本存下来每条改动配一行说明线上出了问题直接回滚上一版。这套方法不高级但有效。希望帮到你。本文还有配套的精品资源点击获取