吴恩达提示词工程课程精解：从理论到实战的开发者指南

提示词工程大语言模型吴恩达

于 2026-07-07 15:47:45 修改

·本内容遵循CC 4.0 BY-SA版权协议

如果你正在学习大模型，或者想用大模型解决实际问题，那么“提示词工程”这个词你一定不陌生。但你可能也发现了，网上关于提示词的教程质量参差不齐：有的只讲几个基础模板，解决不了复杂问题；有的过于理论化，看完还是不知道怎么写；还有的干脆就是“咒语大全”，让你对着抄，却不知道为什么有效。

这导致一个普遍现象：很多人学了一堆“技巧”，面对真实业务需求时，依然写不出高质量的提示词，模型输出还是“一本正经地胡说八道”。问题的核心在于，大多数人把提示词工程当成了“魔法咒语”的背诵，而不是一门有原理、有方法、可迭代的工程学科。

最近，吴恩达（Andrew Ng）与 OpenAI 合作推出的《ChatGPT Prompt Engineering for Developers》课程，在开发者社区引起了广泛关注。很多人将其誉为“2026年公认最好的提示词工程教程”。这个评价是否过誉？这套课程究竟解决了哪些传统教程没讲透的痛点？更重要的是，一个开发者如何将这套方法论真正落地到自己的项目中？

本文将带你深入拆解这套课程的核心精髓。我们不止步于复述课程内容，而是结合实际的开发场景，为你提炼出一套从入门到进阶的、可操作的提示词工程实践框架。你会看到清晰的代码示例、常见的“坑”以及针对不同任务类型（如总结、推理、转换、扩写）的最佳实践。无论你是想快速上手大模型应用，还是希望优化现有产品的AI体验，这篇文章都将提供一条从“知道”到“做到”的清晰路径。

1. 这篇文章真正要解决的问题：从“玄学咒语”到“工程方法”

在深入具体技术之前，我们必须先统一认知：提示词工程（Prompt Engineering）的本质是什么？

它不是寻找“万能咒语”，而是通过结构化、可迭代的文本输入，精准地控制大语言模型（LLM）的输出行为，以可靠地完成特定任务。这里的核心词是“控制”和“可靠”。一个随机的、模糊的提示词，得到的输出也是随机和模糊的。而工程化的方法，追求的是在给定输入下，输出具有高度的可预测性和稳定性。

吴恩达课程之所以被推崇，正是因为它跳出了“技巧合集”的框架，回归到了工程化的本质。它主要解决了三大痛点：

系统性缺失：很多教程是零散的“技巧点”，而课程提供了一个从原则（Principles）到迭代（Iterative）的完整工作流。
开发者视角偏差：大多数提示词教程面向终端用户（“如何让ChatGPT写诗”），而课程完全从开发者（Developer）视角出发，教你如何将LLM作为API集成到应用中，关注的是提示词作为“程序输入”的稳定性和效率。
实操指导不足：课程不仅讲理论，更通过Jupyter Notebook提供了完整的、可运行的代码示例，让学习者能在真实调用API的环境中立刻验证和练习。

因此，本文的目标是：为你提炼这套课程中最高频、最实用的工程化原则和模式，并将其转化为你可以立即在代码中使用的实践指南。 我们将重点关注那些能显著提升提示词效果、但容易被忽略的“非直觉”技巧。

2. 核心概念与两种关键提示策略

在开始写代码之前，需要理解两个贯穿始终的核心策略。它们是你与模型沟通的“元语言”。

2.1 策略一：编写清晰、具体的指令（Write clear and specific instructions）

这听起来像是一句正确的废话，但90%的提示词问题都源于此。“清晰”和“具体”不是让你写长篇小说，而是指消除歧义，提供充分上下文，并明确输出格式。

误区：“总结这篇文章。”
清晰具体的做法：“用不超过三句话总结下面这篇文章的核心论点，并提取出作者使用的两个主要论据。总结语言需简洁，面向高中生读者。”
- 为什么有效：它限制了输出长度（三句话）、定义了内容要素（核心论点、两个论据）、指定了风格（简洁、面向高中生）。模型有了明确的“施工图纸”。

在工程上，“清晰具体”常常通过以下技术手段实现：

使用分隔符：用 ```, ", < >, : 等符号清晰地标明文本的不同部分（如指令 vs. 待处理文本）。
要求结构化输出：如JSON、HTML或带标记的文本，便于后续程序化处理。
指定完成任务所需的步骤：将复杂任务拆解为模型易于遵循的步骤。
提供示例（Few-shot prompting）：给出一两个输入输出的例子，让模型模仿格式和风格。

2.2 策略二：给模型时间“思考”（Give the model time to “think”）

这是课程中最具启发性的一点。模型在给出最终答案前，也需要推理过程。如果你直接问一个复杂问题，它可能跳过推理，直接给出一个可能错误但看起来合理的答案。

误区：“这个数学题的解是什么？问题：...”
给时间思考的做法：“请按步骤解决以下数学问题。首先，解释你的推理过程。然后，在最后一行给出最终答案，格式为 ‘答案：X’。问题：...”
- 为什么有效：你强制模型将其内部的“思维链”（Chain-of-Thought）输出出来。这不仅能提高答案的正确率（因为模型必须一步步推导），还能让你在结果错误时，通过检查推理过程来诊断问题所在。

在工程上，这通常意味着：

指定任务步骤：明确要求模型先做什么，再做什么。
指导模型自行推导解决方案：而不是直接要求它给出答案。

3. 环境准备与API调用基础

我们将使用 OpenAI 的 API 进行演示，这是课程中使用的主要工具。其他主流模型（如 Anthropic Claude, Google Gemini, 国内各大模型）的提示词原则是相通的，只是API调用方式略有不同。

3.1 前置条件

Python环境：建议使用 Python 3.8 及以上版本。
OpenAI账户与API Key：访问 OpenAI 平台注册并获取API Key。请妥善保管你的API Key，不要将其提交到代码仓库中。
基础库：安装 openai Python 库。

3.2 基础配置与安全实践

首先，设置你的环境。最佳实践是使用环境变量来管理敏感信息。

BASH

# 在终端中设置环境变量（Linux/macOS）

export OPENAI_API_KEY='your-api-key-here'

# Windows (PowerShell)

$env:OPENAI_API_KEY='your-api-key-here'

然后，在你的Python代码中：

PYTHON

# 文件：prompt_engineering_demo.py

import openai

import os

from openai import OpenAI

# 从环境变量读取API Key，这是安全做法

client = OpenAI(

api_key=os.environ.get("OPENAI_API_KEY"), # 优先从环境变量获取

)

# 一个通用的调用函数，后续示例会基于此扩展

def get_completion(prompt, model="gpt-3.5-turbo", temperature=0):

"""

调用Chat Completion API的辅助函数。

:param prompt: 用户提示词

:param model: 使用的模型，默认为 gpt-3.5-turbo（成本较低，适合练习）

:param temperature: 温度参数，控制随机性。0表示确定性最高，适合有标准答案的任务。

:return: 模型生成的文本内容

"""

messages = [{"role": "user", "content": prompt}]

try:

response = client.chat.completions.create(

model=model,

messages=messages,

temperature=temperature,

)

return response.choices[0].message.content

except Exception as e:

print(f"调用API时发生错误: {e}")

return None

# 测试连接

if __name__ == "__main__":

test_prompt = "请用一句话介绍你自己。"

result = get_completion(test_prompt)

if result:

print("API调用成功！")

print("模型回复：", result)

else:

print("API调用失败，请检查网络和API Key。")

关键参数解释：

model: 对于大多数提示工程实验，gpt-3.5-turbo 性价比高，响应快。对于需要更强推理或复杂理解的任务，可选用 gpt-4 或 gpt-4-turbo。
temperature: 这是最重要的参数之一。它控制输出的随机性。
- temperature=0：模型每次都会对相同输入给出几乎相同的输出。非常适合需要确定性结果的场景，如信息提取、分类、代码生成。
- temperature=0.7（默认值附近）：输出有一定创造性，适合写作、创意生成。
- temperature=1 或更高：输出非常随机，可能不连贯。谨慎使用。
max_tokens: 限制生成内容的最大长度，防止意外消耗过多token。

4. 核心任务模式拆解与代码实战

现在，我们结合具体任务类型，看看如何应用上述两大策略。每个模式都包含“错误示范”、“正确示范”和“代码实现”。

4.1 模式一：文本总结（Summarization）—— 控制粒度与焦点

总结是最常见的需求。工程化的总结不是“变短”，而是“提取特定信息”。

场景：你有一篇关于新产品发布的冗长新闻稿，需要为不同部门生成摘要。

给市场部：关注核心卖点和市场定位。
给技术部：关注技术规格和实现难点。
给高管：关注成本、时间线和风险。

PYTHON

# 文件：summarization_demo.py

text = """

[这里是一篇虚拟的长篇新闻稿，关于“星海科技”发布新一代量子计算芯片“玄玑”。内容包含：芯片采用新型拓扑量子位设计，将错误率降低了70%；算力达到1000量子比特；预计明年Q2量产；目标客户是科研机构和大型云服务商；研发历时5年，耗资数十亿；CEO王博士强调了其在药物发现和气候模拟领域的潜力。]

"""

# 错误示范：过于模糊

bad_prompt = f"总结一下这篇文章：{text}"

# 预期问题：总结可能冗长，没有重点，不符合任何一方的需求。

# 正确示范：为特定角色和焦点撰写总结

prompt_for_marketing = f"""

请扮演一名市场分析师，为市场部门撰写一份摘要。

请从以下文本中，提取与**产品市场定位、核心卖点、目标客户**相关的信息。

用三个要点（bullet points）的形式呈现，每个要点不超过两句话。

文本内容用三个反引号分隔。

```{text}```

"""

prompt_for_tech = f"""

请扮演一名技术架构师，为研发部门撰写一份摘要。

请从以下文本中，提取与**技术规格、性能提升、实现难点**相关的信息。

以JSON格式输出，包含以下字段：`technology`, `specifications`, `breakthrough`, `challenges`。

文本内容用三个反引号分隔。

```{text}```

"""

# 调用函数

print("=== 市场部摘要 ===")

marketing_summary = get_completion(prompt_for_marketing, temperature=0)

print(marketing_summary)

print("\n")

print("=== 技术部摘要 ===")

tech_summary = get_completion(prompt_for_tech, temperature=0)

print(tech_summary)

工程要点：

使用分隔符（```）：清晰地将指令与待处理文本分开，防止指令被误读为文本的一部分。
指定角色（Role-playing）：“扮演市场分析师”让模型调整其语言风格和关注点。
明确输出格式：“三个要点”、“JSON格式”让输出结构化，便于后续自动化处理或直接阅读。
聚焦信息维度：不是总结所有内容，而是提取与“市场定位”、“技术规格”等特定维度相关的信息。

4.2 模式二：推理（Inference）—— 强制思维链，提升准确性

推理任务包括情感分析、主题提取、逻辑判断等。关键是要引导模型展示其推理过程。

场景：分析用户评论的情感，并解释原因。

PYTHON

# 文件：inference_demo.py

review = """

我买了这款智能手表，续航确实像宣传的一样能撑一周，GPS也很准。但是表带太容易脏了，而且配套的App偶尔会闪退，客服响应速度一般。总体来说，硬件不错，软件和体验有待加强。

"""

# 错误示范：直接问情感

bad_prompt = f"这条评论的情感是正面的还是负面的？评论：{review}"

# 正确示范：要求分步推理，并给出结构化输出

prompt = f"""

请对以下商品评论进行情感分析。

请按以下步骤执行：

1. 从评论中提取提及产品优点和缺点的句子。

2. 基于提取的优点和缺点，判断评论者的整体情感倾向（正面、负面或中立）。

3. 用一句话解释你的判断理由。

请将最终结果以以下JSON格式输出：

{{

"advantages": ["优点1", "优点2", ...],

"disadvantages": ["缺点1", "缺点2", ...],

"overall_sentiment": "正面/负面/中立",

"reason": "解释原因的一句话"

}}

商品评论用三个反引号分隔。

```{review}```

"""

result = get_completion(prompt, temperature=0)

print("情感分析结果：")

print(result)

# 预期输出是一个JSON对象，清晰列出了优点、缺点、最终判断和理由。

工程要点：

拆解步骤：将复杂的“情感分析”任务拆解为“提取优点/缺点 -> 综合判断 -> 解释理由”三个子任务。这模仿了人类的思考过程，极大提高了模型处理复杂任务的可靠性。
结构化输出（JSON）：这使得分析结果可以被其他程序轻松解析和使用，例如自动生成报告或触发不同的工作流（如负面评论转交客服系统）。

4.3 模式三：文本转换（Transformation）—— 格式、风格与语言

转换任务包括翻译、润色、格式调整、语气转换等。核心是明确“源格式”和“目标格式”。

场景：将一段技术文档的摘要，转换成面向社交媒体（如微博）的推广文案。

PYTHON

# 文件：transformation_demo.py

tech_abstract = """

本文提出了一种基于注意力机制的新型神经网络架构——Transformer。该架构完全摒弃了循环和卷积结构，仅依赖自注意力机制来处理序列数据，在机器翻译任务上取得了显著优于当时最佳模型的性能，同时具有更高的并行化能力，大大缩短了训练时间。Transformer的核心组件包括编码器、解码器和多头注意力层。

"""

prompt = f"""

你是一位资深社交媒体运营专员。你的任务是将一段专业的技术摘要，改写成适合在微博平台发布的、吸引普通科技爱好者关注的推广文案。

要求：

1. 语言风格：活泼、口语化、带有一定悬念和号召力。

2. 包含合适的标签（Hashtag），例如 #AI #技术前沿。

3. 长度控制在140字以内。

4. 保留原文的核心技术亮点（如：注意力机制、并行化、训练快）。

请直接输出改写后的微博文案。

技术摘要用三个反引号分隔。

```{tech_abstract}```

"""

weibo_copy = get_completion(prompt, temperature=0.7) # 适当提高温度以增加创造性

print("生成的微博文案：")

print(weibo_copy)

工程要点：

定义明确的转换目标：不仅仅是“改写”，而是“为微博平台”、“面向科技爱好者”、“活泼口语化”的改写。目标越具体，输出越精准。
利用角色扮演：“资深社交媒体运营专员”这个角色能有效引导模型的风格。
设置约束条件：“140字以内”、“包含标签”是硬性要求，确保输出可直接使用。

4.4 模式四：扩写（Expansion）—— 从大纲到成文

扩写是根据简短的指令或要点生成更长、更丰富的文本。风险在于内容可能偏离主题或空洞。控制的关键在于提供充足的上下文和约束。

场景：根据几个关键词，生成一封专业的商务邮件。

PYTHON

# 文件：expansion_demo.py

key_points = """

收件人：某云厂商销售总监李总

事由：咨询GPU云服务器批量采购的折扣和定制化方案

我方信息：我们是“深瞳AI”，一家初创的AIGC公司，目前有大约50人的算法和研发团队。

需求：需要至少20台A100级别的GPU实例，使用周期预计1年起。

期望：了解阶梯报价、长期合约优惠、以及是否支持混合部署（部分公有云+部分托管私有云）。

语气：专业、礼貌、表达明确合作意向，但留有谈判空间。

"""

prompt = f"""

你是一名商务拓展经理。请根据以下要点，撰写一封完整的商务咨询邮件。

请确保邮件包含：标准的邮件格式（称呼、正文、落款）、清晰的结构、专业的措辞，并涵盖所有要点信息。

邮件的语气应该专业且礼貌。

要点信息用三个反引号分隔。

```{key_points}```

"""

business_email = get_completion(prompt, temperature=0.3) # 较低温度，保证专业性和稳定性

print("生成的商务邮件：")

print(business_email)

工程要点：

提供结构化输入：即使只是要点，也尽量按“收件人”、“事由”、“我方信息”等维度组织好。这为模型构建输出提供了清晰的框架。
明确输出格式要求：“标准的邮件格式”是一个强约束，确保生成结果符合规范。
控制创造性：对于商务邮件这类严肃文本，使用较低的 temperature（如0.3）来减少不可预测的发挥，保证内容的专业和可靠。

5. 迭代与评估：提示词的优化循环

写提示词不是一蹴而就的，而是一个“编写 -> 测试 -> 分析 -> 改进”的循环。课程中强调了迭代的重要性。

5.1 如何分析失败的输出

当模型输出不符合预期时，不要简单地重试或抱怨模型“笨”。应该系统性地排查：

指令是否清晰？ 是否有歧义？模型是否可能误解了你的意图？
给模型思考的时间了吗？ 对于复杂问题，是否应该要求它分步推理？
提供的上下文足够吗？ 模型是否缺少做出准确判断的必要信息？
示例（Few-shot）是否有帮助？ 对于格式特别严格或风格特别独特的任务，提供一两个输入输出示例往往比长篇指令更有效。

5.2 构建评估体系

对于生产环境，你需要更系统的评估方法，而不仅仅是人工查看。

定义清晰的成功标准：例如，总结任务的成功标准可能是“包含所有三个关键点”和“字数在100字以内”。
编写测试用例：准备一批有标准答案的输入文本。
自动化评估（部分）：对于格式转换、代码生成等任务，可以编写脚本检查输出格式是否正确、代码是否能通过编译。对于总结、扩写等，可以评估关键实体（如产品名、日期、数字）是否被正确保留或改写。
A/B测试：对于重要的提示词，可以设计不同版本（V1， V2），在少量真实流量上对比效果，选择更优者。

6. 常见问题与排查思路

在实际使用中，你可能会遇到以下典型问题：

问题现象	可能原因	排查方式	解决方案
输出完全偏离主题或胡言乱语	1. 提示词歧义严重。 2. Temperature 参数设置过高。 3. 输入文本包含异常字符或格式。	1. 检查提示词，尝试用更简单明确的语言重写。 2. 将 `temperature` 设为0重试。 3. 检查输入文本，进行清洗（如去除乱码）。	简化指令，降低temperature，净化输入。
输出格式不符合要求（如未输出JSON）	1. 指令中对格式的要求不够强制。 2. 模型在生成时“忘记”了格式指令。	1. 在提示词开头和结尾都强调输出格式。 2. 使用 Few-shot 示例展示精确格式。	在提示词中使用“必须”、“请严格按以下JSON格式输出”等强动词。提供格式示例。
输出内容过于简短或冗长	1. 未指定长度限制。 2. `max_tokens` 参数设置不合理。	1. 在提示词中明确要求“用100字左右总结”或“分三点论述”。 2. 查看API返回的 `usage` 字段，了解token消耗。	在提示词中加入长度约束。合理设置 `max_tokens` 参数。
处理长文本时丢失中间信息	1. 模型有上下文长度限制（如 4K, 8K, 16K, 128K tokens）。 2. 提示词本身占用了太多token。	1. 确认输入文本+提示词的总长度未超模型限制。 2. 对长文本进行分块处理，再分别总结或分析。	1. 升级到支持更长上下文的模型（如 `gpt-4-turbo`）。 2. 实现文本分块处理逻辑。
输出包含不希望出现的内容或偏见	1. 训练数据本身的偏差。 2. 提示词无意中诱导了有偏见的输出。	1. 在提示词开头加入系统指令（System Message）进行约束，如“你是一个客观公正的助手”。 2. 对输出进行后处理过滤。	使用系统角色设定（`role: “system”`）来定义助手的行为准则。

7. 进阶技巧与生产环境最佳实践

当你掌握了基础模式后，以下进阶技巧能帮助你在复杂项目中构建更健壮的AI功能。

7.1 使用系统消息（System Message）设定角色

在Chat Completion API中，除了用户消息（role: “user”），你还可以发送系统消息（role: “system”）来持久地、高层次地定义模型的行为模式。这比在每条用户提示前都写一遍角色设定更优雅、更有效。

PYTHON

def get_completion_with_system(system_message, user_message, model="gpt-3.5-turbo"):

messages = [

{"role": "system", "content": system_message},

{"role": "user", "content": user_message}

]

response = client.chat.completions.create(

model=model,

messages=messages,

temperature=0,

)

return response.choices[0].message.content

# 示例：创建一个始终以专业翻译身份回应的助手

system_msg = “你是一位专业的英汉技术文档翻译，精通计算机科学术语。你的翻译要求准确、流畅，并符合技术文档的书面语风格。”

user_msg = “Please translate the following paragraph: ‘The transformer architecture relies entirely on self-attention mechanisms...’”

translation = get_completion_with_system(system_msg, user_msg)

print(translation)

7.2 构建提示词模板

对于需要频繁执行、结构固定的任务，应该将提示词参数化，构建成模板。

PYTHON

# 文件：prompt_templates.py

class PromptTemplates:

@staticmethod

def summarize_for_role(text, role, focus_points, output_format="bullet points"):

"""生成针对特定角色的总结提示词模板"""

prompt = f"""

请扮演一名{role}，为你的同事撰写一份摘要。

请从以下文本中，重点提取与【{focus_points}】相关的信息。

请使用【{output_format}】的形式呈现你的摘要。

文本内容：

\"\"\"{text}\"\"\"

"""

return prompt

@staticmethod

def analyze_sentiment_with_chain_of_thought(text):

"""生成带有思维链的情感分析提示词模板"""

prompt = f"""

请按步骤分析以下评论的情感：

1. 列出评论中所有表达积极感受的短语或句子。

2. 列出评论中所有表达消极感受的短语或句子。

3. 基于以上列表，综合判断整体情感倾向（正面、负面、中立）。

4. 用一句话总结你的判断依据。

请将最终结果以JSON格式输出，包含字段：positives, negatives, sentiment, reasoning。

评论：

\"\"\"{text}\"\"\"

"""

return prompt

# 使用模板

text_to_summarize = “...某个长文本...”

prompt = PromptTemplates.summarize_for_role(

text=text_to_summarize,

role="产品经理",

focus_points="用户痛点、解决方案优势、市场机会",

output_format="三个要点"

)

result = get_completion(prompt)

7.3 生产环境注意事项

错误处理与重试：API调用可能因网络、速率限制（Rate Limit）失败。代码中必须包含健壮的错误处理（如重试机制、退避策略）。
成本监控：记录每次调用的token消耗（特别是输入和输出token）。设置预算警报，防止意外费用。对于长文本，输入token是成本大头。
内容安全与审核：对于面向用户开放的应用，务必对模型的输入和输出进行安全审核，过滤不当内容。可以利用API本身的内容过滤功能，或建立额外的审核层。
延迟与性能：不同模型（gpt-3.5-turbo vs gpt-4）的响应速度差异很大。在用户体验和任务需求间权衡。考虑使用异步调用或流式响应（Streaming）来处理长文本生成。
版本控制：像管理代码一样管理你的提示词模板。对提示词的任何修改都应记录，并在部署前充分测试，因为细微的改动可能导致输出行为发生巨大变化。

8. 总结：从课程到实战的思维转变

吴恩达的提示词工程课程之所以有价值，在于它完成了一次关键的思维转换：将提示词从“与模型对话的艺术”转变为“为模型编写可靠指令的工程”。

回顾全文，我们可以提炼出工程化提示词设计的核心工作流：

定义清晰目标：你到底想要模型输出什么？格式、内容、风格、长度有何要求？
应用核心原则：
- 清晰具体：使用分隔符、要求结构化输出、提供示例。
- 给予思考时间：拆分复杂任务，要求模型展示推理链。
选择合适策略：根据任务类型（总结、推理、转换、扩写）套用或组合相应的模式。
编写与测试：编写初始提示词，用代表性样例进行测试。
分析与迭代：分析失败案例，从“指令清晰度”、“思考时间”、“上下文充分性”等维度优化提示词。
模板化与集成：将验证有效的提示词抽象为模板，集成到你的应用程序中，并辅以错误处理、成本监控等生产级保障。

这门课提供的课件和代码，正是这个工作流的绝佳演练场。它让你在安全的实验环境中，亲身体会到一个微小提示词改动如何显著影响输出质量。

下一步，建议你：

动手复现：务必运行课程中的Jupyter Notebook，亲手修改参数和提示词，观察变化。
迁移到自己的项目：选择一个你正在开发或感兴趣的小功能（如自动生成邮件、分析用户反馈、整理会议纪要），尝试用本文介绍的方法设计和优化提示词。
探索更高级模式：在掌握单轮对话的基础上，可以进一步学习“链式调用”（Chaining），即用上一个模型的输出作为下一个模型的输入，来构建更复杂的多步AI工作流。

提示词工程不是关于记住最多的“咒语”，而是关于掌握最根本的“沟通语法”。当你开始用清晰、结构化的方式向模型表达需求时，你就会发现，大模型所能带来的效率提升和可能性，远比想象中更加确定和强大。