简介：这份《Google AI 提示工程指南（中文版）》面向数据科学家、机器学习工程师、软件开发者及对大语言模型感兴趣的技术人员，系统讲解提示工程从基础到进阶的完整知识体系。内容涵盖零样本、少样本、系统提示、角色提示与情境提示等基础技巧，并深入退步提示、思维链（CoT）、自我一致性、思维树（ToT）、ReAct 推理与行动、自动提示工程、代码提示及多模态提示等高级方法，同时给出输出长度、温度、Top-K 与 Top-P 等模型配置的调优思路。资源包为 1 个 PDF 文件，大小约 7.12MB，结构清晰、便于检索与通读。已有 411 人学习下载。读者可从中获得可落地的提示模板与最佳实践，掌握代码生成、文本摘要、信息提取、问答系统等场景的提示设计方法，并理解提示工程的迭代本质，学会通过试验、记录与优化持续提升模型输出质量。
1. 提示工程指南中文版：一份 PDF 为什么值得你花两小时啃完
很多人第一次接触提示工程，是从收藏夹里那几十篇「万能 Prompt 模板」开始的。结果真到项目里一用，模型该胡说还是胡说，该跑偏还是跑偏。问题不在模板本身，而在于你手里缺一份把「为什么这么写」讲清楚的系统性材料。这份中文版提示工程指南 PDF 的价值就在这——它不是给你一堆可以复制粘贴的咒语，而是把提示词从「玄学调参」拉回到「可复现的工程方法」：任务怎么拆、上下文怎么给、示例怎么选、输出怎么约束、失败怎么定位。它适合三类人：正在把大模型接进业务系统的后端和算法工程师、需要批量产出稳定结果的数据与运营同学、以及带团队做 AI 应用但苦于没有统一规范的技术负责人。读完你至少能建立一套自己的提示词版本管理和评测习惯，而不是每次靠感觉改几个字碰运气。
2. 把提示工程当成软件工程：先立住四个核心概念
这份指南最容易被低估的地方，是它开篇没有直接甩模板，而是先讲清楚几个底层概念。很多人跳过这部分直奔「技巧」，结果后面所有技巧都变成了死记硬背。我一般建议先把下面四个概念吃透，再回头看具体写法，你会发现那些看似花哨的技巧其实都是这四个概念的组合应用。
2.1 指令、上下文、输入数据、输出指示的四段式结构
指南里反复强调的一个结构，是把一次调用拆成四个部分：指令（你想让它做什么）、上下文（外部信息或补充说明）、输入数据（本次要处理的具体内容）、输出指示（格式和约束）。这个拆法的好处是，当结果不对时你能快速定位是哪一段出了问题，而不是笼统地觉得「模型不行」。
# 四段式提示词的最小骨架，注意每段之间用明确分隔符隔开 prompt = f""" # 指令 你是一个合同条款抽取助手，只负责从文本中提取指定字段。 # 上下文 字段定义：甲方名称、签署日期、合同金额（单位：元）。 若某字段在原文中不存在，填写"未提及"，不要编造。 # 输入数据 <<< {contract_text} >>> # 输出指示 以 JSON 返回，键为字段名，值为抽取结果，不要输出任何解释文字。 """这段代码的关键不在语法，而在分隔符<<< >>>的使用。它的作用是让模型清楚知道「哪里是数据、哪里是指令」，避免用户输入里恰好包含类似指令的句子时被误当成命令执行。参数上，字段定义越具体，抽取越稳；「不要编造」这类负向约束要显式写出来，因为模型默认倾向于补全缺失信息。
2.2 零样本、少样本与示例选择策略
指南把示例（few-shot）单独拎出来讲，是因为示例的质量和数量直接决定输出稳定性。零样本适合任务简单、格式要求不高的场景；一旦涉及特定格式、特定语气或领域术语，少样本几乎是必需的。但示例不是越多越好，我见过有人塞十几个例子，结果模型开始模仿示例里的无关细节。
常见做法是给 3 到 5 个覆盖边界的示例：一个标准正例、一个字段缺失的例、一个格式容易出错的例。示例之间用统一的分隔符隔开，并且示例的格式必须和你期望的输出格式完全一致——你示例里写的是 JSON，就别指望它输出 YAML。
2.3 思维链与分步推理的适用边界
思维链（Chain of Thought）在这份指南里被明确标注了适用条件：它适合需要多步推理的任务，比如数学计算、逻辑判断、多条件筛选；但对于纯抽取、纯分类任务，强行加「让我们一步步思考」反而会增加输出噪声和 token 消耗。
一个实用的判断标准是：如果这个任务你自己做的时候需要在草稿纸上算几步，那就值得加思维链；如果是一眼就能看出来的，加了就是浪费。指南里还提到，思维链的输出如果不需要展示给用户，可以在提示里要求模型「先推理，最后用一行给出最终答案」，方便程序解析。
2.4 输出格式约束与结构化返回
把输出约束成结构化格式，是让提示词能进生产系统的前提。指南推荐优先用 JSON，因为绝大多数语言都有成熟的解析库。但要注意两点：一是要在提示里明确「只输出 JSON，不要包裹在代码块里」，否则模型经常给你套一层 ```json；二是要给出字段类型和取值范围，减少解析失败。
import json # 解析时做好兜底，模型偶尔会多输出一句话 def safe_parse(text): text = text.strip() # 去掉可能存在的代码块包裹 if text.startswith("```"): text = text.split("\n", 1)[1].rsplit("```", 1)[0] try: return json.loads(text) except json.JSONDecodeError: # 记录原始输出，便于后续排查是哪条提示词出了问题 print("解析失败，原始输出：", text) return None这段兜底逻辑在生产里几乎是标配。参数上，rsplit("```", 1)是为了处理结尾的代码块标记；解析失败时一定要把原始输出落盘，否则你永远不知道模型到底返回了什么，排查就成了黑匣子。
3. 从 PDF 到可运行提示词：一套可抄的落地流程
概念讲完，接下来是把指南里的方法变成你项目里能跑的东西。这一章按「读—拆—写—测」四步走，每一步都给出具体操作，你可以直接照着在自己的任务上复现。
3.1 通读指南并建立自己的技巧索引
PDF 篇幅不短，一次性读完容易前读后忘。我的习惯是第一遍快速过，只做一件事：把每个技巧对应的「适用任务类型」记下来，形成一张索引表。比如「角色设定」对应需要特定语气或专业视角的任务，「分步推理」对应多步计算，「输出模板」对应需要固定格式的任务。第二遍再针对你当前手上的任务精读相关章节。
| 技巧 | 适用任务 | 不适用场景 |
|---|---|---|
| 角色设定 | 语气模仿、专业领域问答 | 纯数据抽取 |
| 少样本示例 | 格式固定、领域术语多 | 任务本身极简单 |
| 思维链 | 多步推理、条件判断 | 单步分类 |
| 输出模板 | 需要程序解析 | 开放式创作 |
这张表不用照搬，关键是你要有自己的版本。有了它，遇到新任务时你能快速判断该用哪几个技巧组合，而不是从头试。
3.2 把业务需求拆成模型能执行的最小任务
指南里有一句话我印象很深：模型不会做你想要的，只会做你写出来的。很多提示词失败，根源是任务本身没拆干净。比如「帮我分析这份用户反馈」就是一个没拆的任务——分析什么？情感？分类？提取改进点？不同目标对应完全不同的提示词。
拆任务的实操方法是：先写出你期望的最终输出长什么样，再倒推模型需要完成哪几步。如果一步完不成，就拆成多次调用，前一次的输出作为后一次的输入。不要试图用一个超长提示词解决所有问题，那样调试起来会非常痛苦。
3.3 写出第一版提示词并做参数标注
第一版不要追求完美，先把四段式结构填满，能跑通就行。写的时候养成一个习惯：把每个可调的地方标注出来，方便后面做对比实验。
# 第一版提示词，参数用变量抽出，方便做 A/B 对比 SYSTEM_ROLE = "你是一名严谨的客服质检员" # 角色，可调 TEMPERATURE = 0.2 # 温度，抽取任务调低 MAX_EXAMPLES = 3 # 示例数量，可调 def build_prompt(text, examples): example_block = "\n".join( f"输入：{e['input']}\n输出：{e['output']}" for e in examples[:MAX_EXAMPLES] ) return f""" {SYSTEM_ROLE} 请判断以下对话是否存在服务态度问题，只回答"是"或"否"。 参考示例： {example_block} 待判断对话： <<< {text} >>> """这里把角色、温度、示例数量都抽成变量，是为了后面做对比实验时只改一个因素。温度对抽取和分类任务建议设在 0 到 0.3 之间，太高会让输出不稳定；示例数量从 3 开始试，效果不够再加，但一般不超过 5。
3.4 用固定测试集做回归，别靠单次结果下结论
这是指南里最容易被忽略、但生产环境最该做的一步。改完提示词，随手试一条觉得「好像好点了」就上线，是翻车的常见原因。正确做法是准备一个 20 到 50 条的固定测试集，覆盖正常、边界、异常三类情况，每次改动都跑一遍，记录准确率和解析失败率。
# 简易回归脚本，跑固定测试集并统计指标 def run_regression(prompt_builder, test_cases, model_call): total, correct, parse_fail = 0, 0, 0 for case in test_cases: total += 1 raw = model_call(prompt_builder(case["input"])) result = safe_parse(raw) if result is None: parse_fail += 1 continue if result.get("label") == case["expected"]: correct += 1 print(f"准确率：{correct/total:.2%}，解析失败率：{parse_fail/total:.2%}")测试集要固定下来，不要每次换新的，否则你无法判断改动到底有没有效果。解析失败率单独统计很重要，它反映的是格式稳定性，和准确率是两回事。
4. 提示工程落地避坑：五条血泪经验
这一章单独拿出来，是因为下面这些问题我在不同项目里反复遇到，几乎每一条都让人返工过。按「现象 → 原因 → 解决」写，你可以对照自己的项目排查。
4.1 输出格式时好时坏，解析经常失败
现象：同样的提示词，大部分时候能解析，偶尔返回带解释文字或代码块包裹的内容。原因：模型对格式约束的遵守不是 100% 的，尤其是温度偏高或输入较长时。解决：把温度降到 0.2 以下；在提示词末尾再强调一次「只输出 JSON」；解析层加兜底逻辑，去掉代码块标记后再尝试解析，同时把失败样本记录下来。
4.2 示例给多了，模型开始模仿无关细节
现象：加了几个示例后，模型输出里出现了示例中特有的措辞或字段，即使当前输入并不需要。原因：示例本身携带了超出任务范围的模式，模型会一并模仿。解决：精简示例，只保留和当前任务直接相关的部分；检查示例里有没有和任务无关的固定措辞，有就删掉；示例格式和期望输出严格对齐。
4.3 长文本输入时关键信息被忽略
现象：输入一段较长的文档，模型只处理了开头或结尾，中间的关键信息没被用上。原因：长上下文里信息密度不均，模型注意力容易集中在首尾。解决：把关键指令和字段定义放在输入数据之前；如果文档很长，先做一次摘要或分段处理，再把相关段落喂给模型；必要时用「请逐段检查」这类显式指令引导。
4.4 改了提示词，效果反而变差却找不到原因
现象：凭感觉改了几个词，测试集准确率下降，但不知道是哪处改动导致的。原因：一次改了多个地方，无法归因。解决：每次只改一个变量，改完立刻跑回归；把每次的提示词版本和对应指标记录下来，形成版本表。这个习惯一开始麻烦，但能帮你省下大量返工时间。
4.5 把模型输出直接当最终结果用
现象：模型返回的内容看似合理，实际包含编造的字段或错误计算，直接进了下游系统。原因：缺少校验环节，把模型当成了确定性程序。解决：对关键字段做规则校验，比如日期格式、金额范围；对模型给出的推理过程做抽查；在提示词里明确「不确定时返回未提及，不要编造」，并在代码层对「未提及」做特殊处理。
5. 进阶：把提示词管起来，让它能长期维护
走到这一步，你已经能写出稳定可用的提示词了。但真正让提示工程产生长期价值的，是把它当成代码资产来管理。我自己的习惯是给每个提示词建一个独立文件，头部用注释写清楚用途、负责人、适用模型、最近一次评测指标，正文才是提示词内容。这样半年后回头看，你还能知道当时为什么这么写。
更进一步的做法是建一个提示词注册表，用配置的方式管理不同任务的提示词版本，代码里通过任务名去取，而不是把提示词硬编码在业务逻辑里。这样换模型、调参数、做 A/B 测试时，改动都集中在一处，不会散落在各个文件里。
# 提示词注册表的最小实现，按任务名和版本取用 PROMPT_REGISTRY = { "contract_extract": { "v1": {"template": "...", "temperature": 0.1, "model": "default"}, "v2": {"template": "...", "temperature": 0.2, "model": "default"}, }, } def get_prompt(task, version="v1"): entry = PROMPT_REGISTRY[task][version] # 返回模板和参数，业务层只关心调用，不关心具体内容 return entry["template"], entry["temperature"]这个结构的好处是，当你要对比 v1 和 v2 的效果时，只需要在测试脚本里切换版本号，业务代码一行都不用动。参数上，建议每个任务至少保留两个版本，一个稳定版、一个实验版，实验版验证有效后再提升为稳定版。
还有一个容易被忽略的点：给提示词写测试用例，就像给函数写单元测试一样。每次改动提示词，先跑测试用例，通过了再合并。这套流程一开始会觉得重，但当你手上有十几个提示词、服务多个业务方时，没有它几乎无法维护。我自己吃过亏——早期提示词全散在代码里，改一处忘一处，最后没人敢动。后来强制走注册表加回归测试，才把这块稳定下来。希望帮到你。
本文还有配套的精品资源，点击获取
