企业官网建设流程全解析

简介：这是一份谷歌官方发布的《AI 提示工程指南》中文版 PDF，面向数据科学家、机器学习工程师、软件开发者以及所有对大型语言模型感兴趣的技术人员。文档系统梳理了提示工程的核心概念与进阶技巧，从零样本、少样本、系统提示、角色提示与情境提示等基本方法，延伸到思维链、自我一致性、思维树、ReAct、自动提示工程与代码提示等高级技术，并结合文本摘要、信息提取、问答系统和代码生成等典型场景给出可操作的示例与最佳实践。资源为单个 PDF 文件，压缩包大小约 7.12MB，方便下载后在电脑、平板或手机上直接阅读。目前已有 411 人学习浏览。读者可以通过完整目录快速定位感兴趣的主题，既能获得提示编写与调试的系统框架，也能参考大量现成提示模板，适合在日常模型调用、应用开发与算法研究中边学边用，切实提升提示设计与模型输出质量。

1. Google AI 提示工程指南（中文版）：它到底在讲什么

网上流传的这份PDF，文件名十有八九把 Google 拼成了 Goolge。我一开始也以为是哪家培训机构的二手教程，打开才确认内容来自 Google 官方提示工程指南的翻译，讲的是把大模型当作可编程组件来使用，而不只是教人怎么闲聊。它解决的核心问题很具体：提示词怎么写才能可靠复现，怎么在不同模型、不同业务场景里都拿到预期结果，而不是每次换句话就翻车。

这本指南的核心主张是：提示词不是玄学，而是一套可以被设计、被测试、被维护的工程产物。对正在用大模型 API 做功能、搭 AI Agent、写 AI 编程提示词的开发者来说，它比绝大多数网文值得精读；对普通用户来说，它也能解释「为什么同一个问题换个说法，结果就差这么多」。下面按我从指南里提炼的落地顺序来展开：先吃透五个基础策略，再谈复杂任务拆解、采样参数和翻车排查。

2. 提示工程的基本功：五个策略和它们各自的适用边界

指南前半部分在讲提示词的基础策略，这些策略不绑定任何具体模型，对对话式大模型通用。我把它拆成五个方向：指令式提示、少样本提示、思维链提示、角色扮演与格式约束。先搞清楚每个策略解决什么问题、代价是什么，再谈组合使用，不然很容易出现「策略叠了一堆，效果反而更差」的情况。

2.1 指令式提示：把任务说完整，比说人话难

最早的提示词写法就是给一段指令，让模型做什么。但大多数人写指令时只给了「做什么」，没给「做成什么样」。一段完整的指令式提示至少要包含四要素：任务目标、输入内容、输出格式、边界条件。缺一个，模型就开始自由发挥。

常见做法是先搭一个角色框架，再写任务，最后给输出约束。我一般在代码里直接构造这样的模板：

system_prompt = ( "你是一名日志分析工程师。\n" "任务：分析给定的应用日志，找出异常项。\n" "输入：\n" "{log_text}\n" "输出要求：\n" "1. 用列表返回异常项，每项包含：时间戳、错误级别、简述。\n" "2. 如果没有异常，输出：无异常。\n" "边界：只分析输入日志，不要推测日志之外的信息。" )

这里的逻辑是：任务目标让模型知道做什么，输出要求规定了结果结构，边界条件防止模型自作主张补内容。换到其他场景时，你只需要改任务句、输出要求和边界，骨架可以复用。常见的错误是把指令写成祈使句连发，比如「分析这段日志，找出错误，给我建议」。模型确实能执行，但输出可能是几个要点、一段长文、甚至带 Markdown 标题的，对要靠程序解析结果的人来说就是灾难。指令写完整，模型才不敢跑偏。

2.2 少样本提示：例子比形容词管用

少样本提示（few-shot prompting）的核心是把任务映射直接铺给模型看：输入长什么样，输出长什么样。指南里反复强调要给质量高、口径一致的样例。给两三个正例的效果，远好于写一句「请用专业、严谨的语气回答」。

为什么例子比形容词管用？因为大模型是从 token 分布里做预测，形容词只影响表层风格，而例子直接规定了输出的结构和取值口径。这对分类、抽取、翻译这类任务特别重要。我在做关键词抽取时，只要在 prompt 里放上两三个「原文→抽取结果」的例子，准确率就能提一截；而用写规则的方式调一周都未必有同样的效果。

样例1 输入：服务器A在12:23:45返回502。 输出：{"event": "http_error", "code": 502, "service": "A"} 样例2 输入：数据库连接池耗尽。 输出：{"event": "resource_exhausted", "code": "conn_pool", "service": "db"} 请按照以上格式，分析下面的日志： {log_text}

这里的关键参数是样例的「口径一致性」：字段名、值域、风格必须统一。如果样例里一个用 code 表示错误码，另一个用 error_code，模型就会在两者之间摇摆。另外，样例要和目标场景同域，拿电商客服的例子去做运维日志抽取，基本是在帮倒忙。

2.3 思维链提示：让模型把过程暴露出来

思维链（chain-of-thought，CoT）是这份指南里对我影响最大的一节。原理并不复杂：对多步推理任务，要求模型在给出结论前先输出中间推理步骤。比如算术题、逻辑题、代码调试，直接问答案经常出错；但让模型先「展开计算」，再把过程收成结论，准确率会明显上升。

请先逐步推理，再给出结论。 问题：一个服务接口平均耗时200ms，其中上游调用占150ms，剩余逻辑耗时占多少ms？ 推理过程： 结论：

需要注意，思维链是有成本的。推理过程会吃掉大量输出 token，如果你把 max_tokens 设得太小，模型推理到一半被截断，结果反而比不给思维链还差。我在调用时一般会把 max_tokens 放到原始估算值的 2 倍，并在 prompt 末尾限定「最后一行输出结论」。另外，思维链只适合多步任务，像「这段文本的情感是正面还是负面」这种简单判断，上思维链完全是画蛇添足，还可能把简单问题带偏。

2.4 角色扮演与格式约束：可控性的两个来源

角色扮演解决的是「用什么知识范围和语气回答问题」，格式约束解决的是「输出能否被程序消费」。两者经常一起用，但作用点不同。

角色设定的坑在于：模型对角色的理解会覆盖你对任务的定义。比如你让模型当「资深律师」去做代码评审，它可能会把精力放在合规表述上，而不是代码质量。格式约束的坑在于「JSON」「Markdown」这类词本身有歧义，模型可能把解释文字也包进 JSON。更可靠的做法是给出一个期望输出结构的具体示例，这也是少样本提示在格式约束里的应用。

五个策略在生产环境里通常是叠加的：角色 + 少样本 + 格式约束是三件套，思维链只在任务复杂度足够高时引入。组合时还要控制 prompt 总长度，太长会稀释模型的注意力。我的判断顺序是：能用指令说清就不放例子，能用例子解决就不上角色，只有需要推理的任务才上思维链。

3. 从提示词到系统设计：复杂任务怎么拆、怎么迭代

指南从这份材料的中段开始把视角拉高：提示词不只是单次对话，而是整个系统的输入。对复杂任务，你没法靠一句提示词让模型一次做对，需要把它拆成多个子任务，再逐层组合。这也是多 AI 协作场景里最常见的工程思路。

3.1 任务碎拆：一个「帮我搞定」是无解的

「帮我写一份市场分析报告」这种指令，模型会给你一篇看起来完整、但细节全凭想象的输出。原因不是模型笨，而是任务本身缺少边界。正确做法是任务碎拆：把一个大需求拆成粒度足够小的子任务，每个子任务用一次独立的模型调用完成，再把结果逐层汇总。

我一般按三步走：先列出子任务清单，再定义每个子任务的输入输出格式，最后编排调用顺序。举个例子，「用户增长分析」可以拆成「从原始数据中提取关键指标 → 逐项分析指标变化 → 汇总成结论」。每个子任务的输出都做成 JSON，方便下一个子任务直接消费，也方便出问题时定位是哪个环节坏了。

拆任务时要特别关注子任务之间的上下文传递。后一个模型看不到前一个模型的原始输入，所以中间结果里必须包含足够的信息，比如「时间段、指标名、数值、对比基准」都要写进 JSON。很多多 AI 协作方案跑不起来，不是模型能力不够，而是任务切得不干净，两个子任务各自在猜对方的输出含义。

3.2 迭代式修正：把模型的错误反馈给模型

很多时候第一次调用的结果不满足要求，不必重写提示词，而应该把错误结果作为输入，让模型进行二次修正。指南里强调的一个关键点是：修正提示词时要告诉模型「哪里不对」，而不是笼统地说「再写一遍」。

你之前的回答有两个问题： 1. 字段命名应使用 snake_case，你使用了驼峰命名。 2. 缺少指标数值列，请在输出中补上 value 字段。 请基于以上反馈，重写你的回答。

这个循环可以写成程序：第一次结果解析失败或校验不通过，自动把错误反馈拼进下一次请求。这样做的好处是你不用在一开始就把提示词调到完美，而是靠迭代去逼近。我一般会把最大迭代次数限定在 2 到 3 次，超过就放弃，避免 token 费用失控，也避免模型在错误方向上越改越偏。

需要注意，反馈要具体到字段级。只写「格式不对」，模型会重新生成一版和你预期仍然不一致的输出；写成「字段 value 缺失、code 应为整数」，模型才能精准修正。

3.3 引导Agent的提示词：多步调用与行动边界

AI Agent 是提示工程最典型的落地场景。Agent 的系统提示词和传统对话提示词不同：它要定义行动空间，列出可用工具，设定终止条件，还要规定工具调用失败时的回退策略。指南里讲得不算深，但底层逻辑是相通的：用提示词为 Agent 画出边界，而不是期望模型自己理解业务规则。

你是订单处理助手。你可以调用以下工具： - search_order(order_id): 查询订单详情 - refund_order(order_id): 发起退款 行动规则： 1. 先调用 search_order 确认订单存在，再执行后续操作。 2. 当工具返回错误时，不要猜测，直接向用户说明失败原因。 3. 当用户请求超出工具能力范围时，回复"该操作不在我的权限内"。 终止条件： - 用户确认操作已完成，或 - 达到最大调用次数3次。

这段骨架里每部分都有它的作用：工具列表约束了 Agent 能做什么，行动规则约束了先做什么后做什么，终止条件防止 Agent 陷入无意义循环。做多 Agent 协作时，最核心的一条是各 Agent 的任务边界不能重叠，否则会出现两个 Agent 同时操作同一份数据、互相覆盖的情况。我见过最典型的翻车现场就是「写报告 Agent」和「查数据 Agent」共用一套提示词模板，最后谁都不清楚自己该负责哪一段。

4. 采样参数怎么调：temperature、top_p、max_tokens背后的逻辑

提示词只是输入的一半，另一半是采样参数。指南里反复提醒：同样的提示词，参数不同，结果可能是两个世界。多数大模型 API 都开放 temperature、top_p、max_tokens 这几个旋钮，但很多人对它们的理解停留在「调小一点更稳定」这种模糊层面，导致参数反而成了结果波动的来源。

4.1 temperature和top_p到底在控制什么

temperature 控制概率分布的形状：值越低，高概率 token 的优势越明显，输出越接近贪婪解码；值越高，低概率 token 被选中的机会越大，输出越发散。top_p 做的是另一件事：只从累积概率达到某个阈值的 token 集合里采样，相当于直接切掉候选列表的尾巴。

两者不等价，但效果可以互相补偿。指南的建议是优先调 temperature，除非你需要更精细的候选范围控制，才去动 top_p。两个同时调反而容易把输出搞得不伦不类：一个把分布拉平，另一个又把候选池削掉，最后得到的采样空间很难解释。实践中我基本只动 temperature，top_p 保持默认值不变。

4.2 不同任务的参数组合：一张能直接抄的配置表

这张表是起步值，不是结论值。不同模型对 temperature 的敏感度不一样，同一个值在 A 模型上已经很发散，在 B 模型上可能还偏保守。我一般会在新模型上线前，用一组固定提示词在 temperature=0.2、0.5、0.8 三个点上各跑十次，观察输出差异，确认参数和模型的匹配关系，再进业务配置。

4.3 为什么低温度不总是等于高质量

低 temperature 带来的结果是确定性的，但确定性不等于正确性。对一个概念模糊的问题，模型可能每次都给出同一个错误答案，只是错误得很一致。指南里强调的是：先靠提示词把正确答案空间撑大，再用低温度去锁定，顺序不能反。

反过来也一样：如果你把 temperature 调到 0，发现结果仍然时好时坏，那问题大概率不在采样参数，而在提示词本身。我的排查顺序是：temperature=0 跑五轮，如果输出差异大，说明提示词给了模型太多选择空间；如果输出一致但是错的，说明提示词引导方向就偏了。先修正提示词，再回来调参数，这个顺序能省下大量试错时间。

5. 提示工程翻车现场排查：四个高频问题的现象、原因和修法

指南把提示词写得再规范，落地时还是会遇到反直觉的现场。下面四个问题是我在做 AI 编程辅助和 Agent 流程时踩得最多的，按「现象 → 原因 → 解决」展开。如果你照着指南写完提示词仍然不稳定，先对照这一章排查。

5.1 现象：模型答得对，但输出格式永远不能解析

我最早做日志分析工具时，提示词里写了「输出JSON」，但返回结果经常是 Markdown 代码块包着 JSON，或者前面多了一段「好的，以下是分析结果」。程序解析直接报错，人肉看又觉得模型挺聪明，这种问题最气人。

原因在于「JSON」这个词对模型来说只是内容提示，不是格式约束。模型默认的对话习惯是「先说句话，再给结果」，尤其当你的 prompt 语气偏口语化时，它会把回复组织成一段聊天文本。解决方法是把格式约束写到最后一行，并明确禁止附加内容：

只输出JSON对象，不要Markdown，不要解释。

这个后缀要用祈使句，放在 prompt 最末尾，效果比写在开头好很多。另外，给一个完整的输出正例仍然是最保险的，模型对「照猫画虎」的遵旨度远高于对文字描述的理解。

5.2 现象：加了「请你仔细思考」之后，结果反而更差

这是我在给数学题类任务加提示词时踩过的坑。原本直接问答案的准确率有七成，加了「请仔细思考再回答」之后掉到五成，模型开始长篇大论写推理，但推理质量明显有问题。

原因有两层：第一，「仔细思考」是一个模糊指令，模型不知道思考到什么程度停，于是它会把字面相关的可能性都枚举一遍，正确答案被淹没在大量中间结论里；第二，这类长推理会消耗 max_tokens，如果输出长度预算不够，推理被截断，结论可能根本没生成完。解决方法是把模糊指令换成结构化的思维链引导：「先列出已知条件，再分步计算，最后一行写结论。」同时把 max_tokens 翻倍，给推理留足空间。

5.3 现象：少样本里加了反例，效果反而崩了

做文本分类时，我见过有人为了把「边界情况」讲清楚，在少样本里放了一正一反两个例子，结果模型对正例的识别准确率反而下降。模型不是人，它不会自动理解「这是反面教材」这层含义，看到一个反例，它学到的可能是「这类输入也属于该分类」。

原因在于少样本提示的本质是让模型从例子中归纳输入输出映射，反例会污染这个映射。解决方法是只给正例，把反面的约束写成文字指令，比如「如果输入不满足条件，输出 null，不要猜测。」这样既保留了反例要传达的边界信息，又不会干扰模型对正例分布的学习。

5.4 现象：指南里的模板换到自家业务场景就失灵

从指南里抄来的模板，在官方示例上跑得很漂亮，换成自己的业务语料后就明显退化。这个现象很普遍，原因是提示词过拟合了示范文本的风格和领域词表。模板里的措辞、术语、甚至标点习惯，都在和指南自带的那批示例绑定。

解决思路是做提示词回归测试。建一个固定的小评测集，每个场景二十到五十条输入就够，覆盖正常情况、边界情况、异常情况三类。每次改提示词，先在这套评测集上跑一遍，对比通过率和格式不合规率。改得好不好，不再靠「感觉这版顺眼」，而是看数字有没有倒退。这套评测集不是一次性的，要随着业务场景演进持续补充用例。

6. 把指南沉淀成自己的提示词资产：版本库与回归评测

写提示词的早期，我改完就上，结果业务一换场景就回归，回头想查「上个月是怎么写的」都查不到。那之后我开始给每条提示词建版本记录，格式很简单：版本号、改动日期、改动内容、评测集通过率、是否回滚。一张表就能管住：

我的习惯是每次只改一个变量，改完先跑旧评测集，再上新场景的用例。通过率掉了就回滚，只有版本记录没有后悔药，至少还有回到上一版的路。评测集不需要大，但必须稳定，我固定用同一批输入做对比，避免「昨天那批数据和今天这批不一样」带来的干扰。

这个方法把指南里「提示词是可维护的工程产物」这句话真正落了地。早期我也觉得写提示词是玄学，改来改去全凭感觉；现在我会在一开始就给每条提示词配上版本号和评测集，把每次调整都变成可追溯的改动。时间长了，你会发现真正值钱的不是某个灵光一现的 prompt，而是那套让你每次都敢改、改完敢上线的回归流程。希望帮到你。

本文还有配套的精品资源，点击获取