提示工程基础实战指南：基于 generative-ai-for-beginners 构建高质量的 LLM 提示词-平芜编程栈

提示工程基础实战指南：基于 generative-ai-for-beginners 构建高质量的 LLM 提示词

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

导读

提示（Prompt）如今已经成为生成式 AI 应用的核心"编程接口"——你写给大语言模型（LLM）的每一句提示词，都直接影响着返回内容的质量与稳定性。本文以微软开源课程 generative-ai-for-beginners 的第 4 课《提示工程基础》（对应文档位于 translations/el/04-prompt-engineering-fundamentals/README.md）为骨架，系统讲解提示词工程的定义、token 化原理、提示词构造方法、few-shot 等关键技术与官方推荐的最佳实践。读完本文，你将能掌握一套可复用的"设计→优化→验证"提示词方法论，并借助仓库内附的 Jupyter Notebook 沙箱实际动手验证每一种技巧。

提示：本文对应的英文原始课件位于 04-prompt-engineering-fundamentals/README.md，互动练习 Notebook 位于 04-prompt-engineering-fundamentals/python/ 目录下，可按需对照查阅。

从"对话"到"编程接口"：为什么提示工程如此重要

生成式 AI 能够根据用户请求创建全新内容（文本、图像、音频、代码等），其底层是 OpenAI GPT 系列这类以自然语言与代码为训练目标的大语言模型。过去，人类与计算机交互需要学习编程语言，而今天用户可以用聊天这种最熟悉的方式驱动模型——发送一段文本（提示 / Prompt），得到 AI 的回应（补全 / Completion），并通过多轮对话反复打磨提示，直到结果符合预期。

这一转变意味着两件事：

提示即界面：在生成式 AI 应用中，提示词取代传统 API 调用成为主要的"编程接口"，承担"告诉模型做什么"以及"左右回复质量"的双重职责。
提示工程是一门新学科：这门快速成长的学科专注于提示词的设计与优化，目标是在大规模生产场景下获得一致且高质量的回复。

在开始深入之前，先明确三个贯穿全篇的核心术语（原文 Key Terms 定义）：

术语	含义
提示工程（Prompt Engineering）	设计并改进输入，引导 AI 模型产出期望输出的实践
Token 化（Tokenization）	把文本切分为模型能够理解与处理的最小单元 token 的过程
指令微调 LLM（Instruction-Tuned LLMs）	经过特定指令微调、以提升回复准确性与相关性的大语言模型

学习目标

按本课设定，完成学习后你应当能够：

解释什么是提示工程、为什么它重要；
描述提示词的组成要素及其用法；
掌握提示工程的常用技巧与最佳实践；
借助 OpenAI 服务端点，把学到的技巧落地到真实示例中。

上图是本课的速写导览（Sketchnote），它把整章内容串成一条主线：从核心概念（token 化、基础 LLM、指令微调模型）与核心挑战（随机性、编造、能力差异），到提示词构造（基础/复杂/指令型）、主要内容的三种用法（示例、线索、模板），再到最佳实践。其中标注的"高级技巧"部分会在本课程的下一章（第 5 课）展开。

业务场景代入：为"个性化教育"设计提示词

本课以一个致力于将 AI 创新带入教育的初创公司为叙事主线，目标是构建个性化学习的 AI 应用。同一款应用里的不同角色，会"设计"出完全不同风格的提示词：

管理员（Administrators）：请求 AI分析课程数据、找出覆盖缺口——AI 负责汇总结果或用代码可视化；
教师（Educators）：请求 AI针对特定受众与主题生成教案——AI 需要按指定格式输出个性化方案；
学生（Students）：请求 AI在困难科目上辅导自己——AI 需要结合学生水平给出讲解、提示与示例。

三个必须先理解的概念：Token 化、基础模型与指令微调

提示工程之所以必要，根源在于模型如何"看待"与"处理"提示词。原文用一个两阶段流程概括提示工程：为给定模型与目标设计初始提示，再迭代优化以提升回复质量——这是一项必然依赖用户直觉的试错过程。而在动手之前，必须先建立三个底层认知。

概念一：Token 化——模型如何"看见"你的提示

LLM 眼中并不存在"单词"，只有token 序列。不同模型（或同一模型的不同版本）可能用不同方式切分同一条提示；由于模型基于 token 而非原始文本训练，token 化的方式会直接影响生成回复的质量。

想建立直觉，可以借助 OpenAI Tokenizer 之类的工具（课程英文版还演示了 tiktoken 的使用方式）：把你的提示复制进去，观察文本如何被拆解为 token，特别注意空白字符与标点的处理——例如单词 "Jupiter" 可能是一个 token，而其他较长或罕见的词组会被切成多个片段。

动手验证（源码级）：在仓库的练习 Notebook（如 oai-assignment.ipynb）中，练习 1 使用 OpenAI 开源的tiktoken库对一段木星介绍文本做编码与解码：
import tiktoken encoding = tiktoken.encoding_for_model("gpt-4o") # 指定与目标模型匹配的编码器 tokens = encoding.encode(text) # 文本 → 整数形式的 token [encoding.decode_single_token_bytes(t) for t in tokens] # 还原每个 token 的文本形态
建议把text换成你自己的任意提示词再运行，直观感受不同措辞会消耗多少 token——token 数量直接关联上下文窗口与调用成本。

概念二：基础模型（Base/Foundation LLM）——"下一个 token 预测器"

提示被 token 化之后，基础模型（Base LLM）的核心职能只剩一件：预测序列中紧随其后的那个 token。由于在大规模文本语料上训练，模型对 token 间的统计关系把握得很好，能以一定置信度完成预测。但请注意一个关键事实：模型并不理解词与 token 的"含义"，它只是看到一个可以"补全"的模式，并持续预测下去，直到被用户打断或触发某个预设的停止条件。

把上文的木星文本直接丢进 Playground 并保持默认设置，你会看到模型把它当作"索取信息"的请求，输出一段自由展开的科普式回复：

这种补全虽然有信息量，却未必符合用户的特定目标——例如一位教师想要的可能是"适合二年级学生的 3～5 条要点总结"。

概念三：指令微调 LLM（Instruction-Tuned LLM）——让它"看见任务"

指令微调 LLM 以基础模型为起点，进一步用包含明确指令的输入/输出对（例如多轮"消息"）微调模型。这类训练常借助基于人类反馈的强化学习（RLHF）等技术，使模型学会遵循指令并从反馈中学习，从而产出更贴近实际应用、更契合用户目标的回复。

把上一条提示的**系统消息（system message）**替换为如下指令再试一次：

Summarize content you are provided with for a second-grade student. Keep the result to one paragraph with 3-5 bullet points.（把提供给你的内容总结给二年级学生听，将结果控制在一段话，配 3～5 个要点。）

对比两张截图即可发现：输出立刻"对齐"了目标受众与格式要求，教师可以把它直接搬进自己的课件。这正是"系统上下文与用户输入对补全质量同样有影响力"的直观证据。

为什么要提示工程：随机性、编造与能力差异三大挑战

当前 LLM 存在若干固有挑战，若不投入提示词的构造与优化，就难以获得可靠一致的补全：

模型回复具有随机性（Stochastic）：同一条提示在不同模型/模型版本下极可能产出不同结果，甚至在同一模型的不同时刻也会漂移。提示工程通过提供更明确的规则（护栏）来压低这种波动。
模型可能编造回复（Fabrication）：模型只掌握庞大但有限的训练语料，对训练范围之外的概念一无所知，于是可能生成不准确、臆想甚至与已知事实相悖的内容。提示工程帮助用户识别并缓解编造——例如要求 AI 给出引用来源或推理过程。
模型能力存在差异（Capability Variation）：新一代模型能力更强，但也伴随独特的怪癖与成本/复杂度权衡。提示工程帮助沉淀最佳实践与工作流，抽象掉模型差异，以可扩展的方式适配不同模型。

你可以亲自在 Playground 里做两组对照实验：

对不同LLM 部署（如 OpenAI、Azure OpenAI、Hugging Face）使用同一条提示——观察差异；
对同一LLM 部署反复使用同一条提示（如 Azure OpenAI Playground）——观察变体之间的差异。

深度聚焦：什么是"编造"，以及为什么我们用这个词

本课使用"编造（fabrication）"而非流行的"幻觉（hallucination）"来指代 LLM 偶尔生成与事实不符信息的现象。原文强调：后者会把类人特质不自觉地投射到机器行为上，属于"拟人化"；而"编造"一词在术语层面也更贴合微软负责任 AI 指南的方向，避免在某些语境下显得冒犯或不包容。

课程给出了一个经典实验提示：

提示：generate a lesson plan on the Martian War of 2076. （为 2076 年火星战争生成一份教案。）

常识告诉我们：2076 年尚在未来、不可能对应真实历史事件；网络上关于火星战争的虚构作品也没有设定在 2076 年。然而把这条提示分别喂给 OpenAI（GPT-3.5）、Azure OpenAI（GPT-3.5）与 Hugging Face（LLaMA-2）三个端点，三个模型全都一本正经地产出了看似合理、足以让不知情用户信以为真的教案——尽管具体细节各不相同（有的面向八年级，有的假设高中生）。相关对比截图与复现步骤，可直接在练习 Notebook 的Exercise 3（Fabrications）中运行查看。

应对编造，提示工程领域已有若干可用的缓解手段：元提示（metaprompting）、温度（temperature）参数调节，以及把新工具/新技术无缝嵌入提示流程的新型提示架构。在代码层面，温度可以直接通过 API 参数控制——例如 oai-assignment Notebook 中封装的get_completion将temperature=0用于降低输出随机性（该参数表示模型输出的随机程度，0 最确定，数值越大越发散），并配合max_output_tokens=1024限制输出长度。

案例研究：GitHub Copilot 如何用提示工程改造代码补全

真实世界的最佳例证是GitHub Copilot——它把文本提示转换为代码补全，并集成进 VS Code 等开发环境。最早版本基于 OpenAI Codex 模型，工程师们很快意识到必须对模型做微调、并开发更好的提示工程技术以提升代码质量；2023 年 7 月他们又推出了超越 Codex 的改进模型，补全速度更快。

课程按时间线整理了官方博客的"学习轨迹"（5 月到 9 月），涵盖"Copilot 如何更好理解你的代码""与 Copilot 背后的 LLM 协作""如何为 Copilot 写出更好的提示""开发者提示工程与 LLM 指南"以及"构建企业级 LLM 应用的经验"等主题。这组文章说明：提示工程不是实验室里的纸上谈兵，而是驱动真实产品迭代的关键工程能力。

提示词的四种构造形态：从"一句话"到"结构化消息"

理解完"为什么"，接下来看"怎么搭"。课程把提示词按复杂程度划分为四种形态。

基础提示（Basic Prompt）：无上下文的纯文本输入

最简单的提示就是一段没有附加任何上下文的文本。把美国国歌的开头几个词 "Oh say can you see" 发给补全 API，模型会立刻"续写"出接下来的几行：

提示（输入）	补全（输出）
Oh say can you see	听起来你正在输入《星条旗》（美国国歌）的歌词，完整歌词是……

这直观展示了模型"预测下一个 token"的本能行为。

复杂提示（Complex Prompt）：以消息集合承载多轮对话

仅靠续写远远不够，生产级应用需要携带上下文与指令。聊天补全 API 允许我们把提示构造为消息（messages）集合，其结构包含：

反映用户输入与助手回复的输入/输出对；
设定助手行为或人格上下文的系统消息（system message）。

response = client.responses.create( model="gpt-4o-mini", input=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Who won the world series in 2020?"}, {"role": "assistant", "content": "The Los Angeles Dodgers won the World Series in 2020."}, {"role": "user", "content": "Where was it played?"} ] )

此时 token 化会把上下文与对话中的相关信息"截取"进注意力范围。这里有个重要推论：修改系统上下文对补全质量的影响，不亚于用户输入本身。仓库内的 oai-assignment Notebook Exercise 5 提供了一个更"叛逆"的变体——把系统人格设为 "You are a sarcastic assistant"（一个毒舌助手），并观察多轮消息如何让回复带上了戏谑语气；你也可以换成任何人格或任意一组输入/输出消息做实验。

指令提示（Instruction Prompt）：把"要信息"升级为"派任务"

前面例子中的用户提示本质上是"索取信息"。指令提示则用文本更细致地指定一项任务，给 AI 更明确的行动指引。下表展示了同主题下指令复杂度递增的效果：

提示（输入）	补全（输出）	指令类型
Write a description of the Civil War（写一段美国内战的描述）	返回一个简单段落	简单
Write a description of the Civil War. Provide key dates and events and describe their significance（……给出关键日期与事件并说明其意义）	返回一个段落 + 关键事件日期列表	复杂
Write a description of the Civil War in 1 paragraph. Provide 3 bullet points with key dates ... Return the output as a JSON file（限制为 1 段、3 个要点，并要求以 JSON 文件格式输出）	返回更详尽的细节，且格式化为可直接复制保存的 JSON	复杂 + 格式化

第三行的关键在于：明确约束了篇幅、结构与输出格式，让结果可预测、可直接用于下游程序。

主要内容（Primary Content）设计模式：指令 + 语料

上述示例仍偏"开放"，模型可以自行决定预训练数据中哪部分相关。主要内容模式把输入拆成两部分：

指令（instruction）：要执行的动作；
相关内容（relevant content）：影响该动作的素材。

最典型的例子是"把这段木星科普文本压缩成两句"，指令与素材之间用分隔符或换行隔开：

提示（输入）	补全（输出）
（木星是太阳系第五颗行星、最大气态巨行星……的长文本）Summarize this in 2 short sentences（用两句简短的话总结这段内容）	木星是距太阳第五近的行星，也是太阳系中最大的行星，以夜空中最明亮的星体之一著称；它得名于罗马神朱庇特，是质量超过其余所有行星总和两倍半的气态巨行星。

主要内容片段本身还有三种更高级的用法——这正是本课的技术精华：

用示例代替指令：Zero-shot / One-shot / Few-shot

与其用显式指令告诉模型"怎么做"，不如直接给几个期望输出的示例，让模型自己推断规律。按示例数量分为 zero-shot（零样本）、one-shot（单样本）、few-shot（少样本）：

学习类型	提示（输入）	补全（输出）
Zero-shot	"The Sun is Shining". Translate to Spanish	"El Sol está brillando".
One-shot	"The Sun is Shining" => "El Sol está brillando". "It's a Cold and Windy Day" =>	"Es un día frío y ventoso".
Few-shot	The player ran the bases => Baseball；The player hit an ace => Tennis；The player hit a six => Cricket；The player made a slam-dunk =>	Basketball（篮球）

此时提示词由三个组件构成：任务描述、若干期望输出示例、以及一个新示例的开头（它成为隐式的任务描述）。注意三种模式的差异：zero-shot 必须显式给出 "Translate to Spanish" 指令；one-shot 仅靠一个翻译示例就推断出"翻译"这一任务；而 few-shot 无需任何额外指令，仅凭三个体育动作→运动的示例就能让模型推断出 "slam-dunk" 属于篮球——示例越多，推断越准。

线索（Cues）：给模型一个"起跳点"

另一种主要内容用法是提供线索而非完整示例——给模型一小段反映期望回复格式的文字作为开头，让模型"顺着这个调子"续写。以"总结木星资料"为例，比较三种线索数量：

线索数量	提示（输入）	补全（输出）
0	（木星长文本）Summarize This	输出一段顺畅的总结
1	（木星长文本）Summarize ThisWhat we learned is that Jupiter	接续该句式，输出以 "is the fifth planet from the Sun ..." 开头的总结
2	（木星长文本）Summarize ThisTop 3 Facts We Learned:	输出编号列表：1. …… 2. …… 3. ……

线索数从 0 增加到 2，输出的结构从自由段落逐渐收敛为"要点编号列表"——用极少的提示成本换来完全可控的格式。

提示模板（Prompt Templates）：把配方沉淀为可复用资产

提示模板是为某类提示预先定义好的"配方"，可存储、可复用，用于在大规模场景下维持一致的用户体验。

简单形态：一组提示示例的集合，同时给出交互式提示组件（用户/系统消息）与 API 请求格式，便于复用；
复杂形态：包含占位符（placeholders），运行时可被用户输入、系统上下文、外部数据源等替换，从而编程式地动态生成提示；
终极价值：面向垂直领域沉淀"提示词库"——模板针对特定应用场景做过优化，使回复对目标受众更相关、更准确。微软开源仓库 Prompts For Education 正是这种思路的范例：它围绕教案设计、课程大纲、学生辅导等教育核心目标，整理了一整库教育领域提示词。

次要内容（Supporting Content）：用额外上下文微调输出

如果把提示构造理解为"指令（任务）+ 目标（主要内容）"，那么次要内容就是额外补充的上下文，目的是以某种方式影响输出。它可以是一组调节参数、格式化指令、主题分类体系等，帮助模型把回复裁剪到符合用户目标。

课程给出了一个课程目录场景：假设目录中每个条目都带名称、描述、难度、元数据标签、讲师等丰富元数据，那么：

用指令定义任务："summarize the course catalog for Fall 2023（总结 2023 秋季课程目录）"；
用主要内容给出几个期望输出格式的示例；
用次要内容指明"输出应优先关注 Top 5 标签"。

最终模型按示例格式产出摘要，但当某个条目拥有多个标签时，会依据次要内容优先挑选那 5 个标签。

提示工程最佳实践：先有正确的心态，再谈正确的技巧

三种必备心态

提示工程本质上是试错过程，原文强调三个指导性原则：

领域理解很重要（Domain Understanding Matters）：回复的准确性与相关性取决于应用所在领域。请把领域直觉注入技术细节——在系统提示里定义领域专属人格，在用户提示里使用领域专属模板，提供反映领域语境的次要内容，或用领域专属的线索与示例把模型引向熟悉的模式。
模型理解很重要（Model Understanding Matters）：不同模型在预训练数据（预训练知识）、API/SDK 能力暴露、擅长内容类型（代码 vs 图像 vs 文本）上差异巨大。理解所用模型的强弱项，用这份认知去给任务排优先级，或构建针对模型能力定制的模板。
迭代与验证很重要（Iteration & Validation Matters）：模型与提示技巧都在快速演进，你所在应用可能还有社区通用经验无法覆盖的专属约束。用工具与技术"快速启动"提示构造，再凭领域经验迭代、验证结果，把心得沉淀为知识库（如提示词库），让后来者以它为新基线做更快的迭代。

官方推荐的最佳实践清单

综合 OpenAI 与 Azure OpenAI 实践者社区建议，课程给出了一张可直接落地对照的实践表：

该做什么	为什么
评估最新的模型	新一代模型通常特性与质量更佳，但成本也可能更高。先评估影响，再做迁移决策。
分离指令与上下文	确认你的模型/提供方是否定义了分隔符，把指令、主要内容与次要内容区分清楚，帮助模型给 token 更准确地分配权重。
具体且清晰	尽量写清期望的上下文、结果、长度、格式、风格等，回复的质量与一致性都会提升；把"配方"固化到可复用模板中。
多描述、多用示例	模型对"展示与讲述"式引导更敏感。先用`zero-shot`（只有指令、无示例），再进阶到`few-shot`（补几个期望输出示例）做精修，也可以使用类比。
用线索启动补全	给模型一些能作为回复起点的开头词或短语，把它推向期望结果。
重复强调（Double Down）	有时需要对模型"重复唠叨"：在主要内容前后都放指令、指令与线索搭配使用等。多迭代、多验证。
顺序很重要	信息呈现顺序可能影响输出——连学习示例也不例外，这与近因偏差（recency bias）有关。多试几种排布。
给模型一条"退路"（Out）	给模型一个兜底回复，让它因故无法完成任务时可以使用，这能显著降低编造/虚假回复的概率。

与所有最佳实践一样，具体效果会因模型、任务与领域而异。请把它们当作起点并持续迭代，同时在新模型与新工具出现时不断重估自己的提示工程流程，重点关注流程的可扩展性与回复质量。

动手练习：搭建提示工程沙箱并逐项验证

本课认为提示工程"更多是一门艺术而非科学"，提升直觉的最好方式就是多练习，采用"领域经验 + 推荐技巧 + 模型专属优化"的试错流程。仓库在 04-prompt-engineering-fundamentals/python/ 下提供了三个版本的练习 Notebook（均含一组"启动练习"，并鼓励你自行追加 Markdown 描述单元与代码单元）：

oai-assignment.ipynb：面向 OpenAI 服务端点；
aoai-assignment.ipynb：面向 Azure OpenAI（Microsoft Foundry）v1 端点；
githubmodels-assignment.ipynb：面向 Microsoft Foundry Models 多模型目录（Azure AI Inference SDK）。

环境准备三步走

获取 API 密钥：准备一个可访问的 LLM 服务端点（OpenAI API Key，或 Azure OpenAI / Foundry 的密钥），并确认目标模型部署（练习脚本中默认使用gpt-4o-mini）；
准备 Python 运行时：确保能执行 Notebook。推荐按仓库根目录 00-course-setup/02-setup-local.md 完成本地配置——该文档提供原生 Python + 虚拟环境、VS Code Dev Container（Docker）、Miniconda与经典 Jupyter四条路径；直接用 GitHub Codespaces 打开本仓库则无需任何本地配置；
配置本地环境变量：把仓库根目录的 .env.copy 复制为.env并按需填值。文件内给出了三套提供方的变量模板：
- OpenAI：OPENAI_API_KEY='<your OpenAI API key here>'；
- Azure OpenAI（Foundry）：AZURE_OPENAI_API_VERSION='2024-10-21'（已设默认稳定版）、AZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT（如https://<resource-name>.openai.azure.com）、AZURE_OPENAI_DEPLOYMENT（如gpt-4o-mini）；
- Microsoft Foundry Models：AZURE_INFERENCE_ENDPOINT、AZURE_INFERENCE_CREDENTIAL（多提供方模型目录，一个端点/密钥即可访问 OpenAI、Meta、Mistral、Cohere、Microsoft 等模型）。
aoai-assignment Notebook 读取的正是AZURE_OPENAI_API_KEY、AZURE_OPENAI_ENDPOINT与AZURE_OPENAI_DEPLOYMENT三个变量（base_url由端点拼接/openai/v1/而来）；而.env已纳入仓库.gitignore，切勿提交密钥。建议先运行笔记本中的环境校验练习，确认oh say can you see这类基础提示能被正常补全。

五个练习对应五类概念

Notebook 内置了与本课一一对应的启动练习，可直接运行、改文本或换模型再运行：

练习	主题	要点
Exercise 1	Token 化	用 tiktoken 对文本编码/解码，观察不同提示的 token 形态与数量
Exercise 2	环境校验	用基础提示确认服务端点配置正确
Exercise 3	编造（Fabrication）	让 LLM 生成不存在的主题（如 2076 火星战争教案），观察其一本正经地编造
Exercise 4	基于指令	同一段木星文本，叠加"给二年级学生总结"等指令，观察输出结构变化
Exercise 5	复杂提示	构造带 system/user/assistant 的多轮消息，体验人格上下文的作用
附加	探索直觉	自建更多练习，把 zero-shot/one-shot/few-shot、线索等技巧组合起来

原文特别说明：本课刻意不提供标准答案——提示工程没有绝对的对错，练习 Notebook 中标题为 "My Solution:" 的 Markdown 单元只展示一个参考输出示例，目的是让你通过试错建立"什么在给定模型与领域下有效"的直觉。例如在 githubmodels-assignment.ipynb 中，Exercise 4 展示了一条二年级风格输出："Jupiter is the fifth planet from the Sun and the biggest one in our Solar System ..."，可作为指令型提示的参考样例。

知识自测与延伸挑战

自测题

在以下三个提示中，哪个最符合合理的最佳实践？

Show me an image of red car（给我看一张红色汽车图片）
Show me an image of red car of make Volvo and model XC90 parked by a cliff with the sun setting（给我看一张沃尔沃 XC90 红色轿车停在悬崖边、正值日落的图片）
Show me an image of red car of make Volvo and model XC90（给我看一张沃尔沃 XC90 红色轿车的图片）

参考答案：选2。它既说明了"是什么"（不是随便什么车，而是明确品牌与型号），又描述了整体场景（停在悬崖边、日落），细节最充分；3次之，因为它同样包含较多描述。

🚀 挑战练习

尝试用"线索"技巧补全这句话："Show me an image of red car of make Volvo and "（给我看一张红色的、沃尔沃品牌的汽车图片，并且……）。观察模型如何接续？你又会如何改进这条提示以获得更理想的构图？（提示：可以仿照自测题第 2 项，在线索后补充场景、光线与视角等期望输出。）

继续深入

本课对应的是 21 课课程体系的第 4 课。想进一步学习更复杂的提示策略，可以直接进入下一章 05-advanced-prompts/README.md（第 5 课：高级提示技巧）；课程完整的速写导览也提示了链式思考（chain-of-thought）、自我精炼、生成知识利用与温度参数调节等进阶主题。此外，英文课程文档 04-prompt-engineering-fundamentals/README.md 保留了更多原文插图与外部参考链接，适合与本文对照精读。

小结

从 token 化、基础模型与指令微调三个底层概念出发，本文完整走过了提示工程的认知链条：四大提示构造形态（基础/复杂/指令/主要内容模式）、三种强化内容的手段（示例、线索、模板）、次要内容对输出的定向微调，以及一整套可执行的最佳实践。你可以随时回到仓库的练习 Notebook 用真实端点验证每种技巧——在提示工程这个"艺术多于科学"的领域，持续的试错与直觉积累，才是把模型能力真正兑现为高质量产品的关键。

【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

提示工程基础实战指南：基于 generative-ai-for-beginners 构建高质量的 LLM 提示词