提示词工程入门教程

编辑部发布 2026-06-23 更新 2026-06-27 11 分钟阅读 2,179 字

提示词工程（Prompt Engineering）并非玄学，而是一套可复用的方法论——通过结构化地设计指令，让大语言模型稳定输出你期望的结果。本教程从零开始，带你走完完整工作流：理解基本原理、掌握核心撰写结构、避开入门常见陷阱，并以实例验证每个步骤的效果。

开始之前

你需要准备什么

一个可访问的大语言模型：如 Claude、ChatGPT、Gemini 等。本教程示例基于 Claude 3.5 Sonnet 编写，但核心原则适用于多数模型。
一个测试用的文本编辑器：用于记录和对比不同提示词的效果。推荐支持 Markdown 预览的编辑器（如 Typora、Obsidian），因为结构化提示在 Markdown 中更易组织。
一个具体任务：避免模糊目标（如“写一篇文章”），请先明确一个可验证任务，例如：“用 200 字以内总结这篇论文的核心论点”或“将这段 Python 代码用函数式风格重写”。

注意版本差异

不同模型、甚至同一模型的不同版本，对相同提示词的敏感度可能截然不同。例如：

Claude 3 Opus 对 XML 标签结构高度敏感。
GPT-4 Turbo 对“角色设定”类提示的响应更直接。
同一模型更新后（如 GPT-4 到 GPT-4o），以前好用的提示可能不再稳定。

实操提示：若从教程复制提示词，务必确认对方所使用的模型和版本。将“在 Claude 3.5 Sonnet 上测试通过”视为一种环境标注。

步骤

1. 明确任务类型

提示词工程的第一步并非写作，而是分类。不同类型的任务，推荐的结构截然不同。下表列出最常见的四类：

任务类型	示例需求	推荐结构	成功率关键点
摘要/改写	将 3000 字压缩为 3 句话	输出格式 + 长度硬约束	明确定义“保留什么、省略什么”
代码生成	编写一个冒泡排序	输入/输出规范 + 边界条件	给出测试用例比描述算法更有效
创意写作	写一个科幻短梗概	角色/风格/禁忌三要素	“不要”列表比“要”列表更能避免翻车
逻辑推理	判断三段论是否有效	逐步推理（Chain-of-Thought）	要求分步写出推理过程

2. 套用三段式模板

这是经过大量验证的通用结构，适用于 80% 以上的日常任务：

[角色/上下文] + [任务描述] + [输出要求]

实操示例（目标：让模型将一段市场数据保存为 JSON 格式）：

你是一个数据清理助手。以下是一组原始市场数据，每行是一个产品名和对应销售额，用逗号分隔。请将其转换为 JSON 数组，每个对象包含 "product" 和 "revenue" 两个字段。只在最终输出中返回 JSON，不要添加额外注释。

原始数据：
Widget A, 12345
Widget B, 8765
Widget C, 23456

为什么有效：角色限定了模型的行为方式，任务描述消除了歧义，输出要求直接控制了格式。

3. 添加约束和边界

这是新手最容易忽略的一步。没有边界条件的提示词，失败概率极高。

必须明确的约束包括：

长度：不是“尽量简短”，而是“不超过 100 字”或“控制在 3 个要点以内”。
格式：不是“输出列表”，而是“每行一个要点，要点前加 - 符号”。
内容边界：不是“合理假设”，而是“不要补充原始数据中没有的信息”。

边界约束示例（接续上一个例子）：

要求补充：如果某行格式不正确（例如缺少逗号），跳过该行，不要猜测数据。
如果原始数据为空，返回一个空数组 []。

4. 用分隔符隔离输入

当提示词中包含用户输入文本时，务必用分隔符将指令和输入区分开。最通用的做法是用三个反引号或 XML 标签包裹输入。

推荐做法：

请将以下用 ``` 包裹的文本翻译成英文：

这是一段需要翻译的中文文本。

为什么重要：这能防止模型将用户输入中的内容误解为新的指令（即 prompt injection 的最简单变体）。

5. 迭代测试

提示词工程并非一次性完成。每次修改后，至少测试两次：

标准测试：用预设的正常输入测试。
边界测试：用空输入、超长输入、格式异常的输入测试。

理想的工作流：

编写第一版提示词。
用正常输入运行一次，记录输出。
针对不满意之处，仅修改提示词的一个部分（不要同时改动结构和示例）。
重新测试，对比输出差异。
重复直至稳定。

检查清单

每次写好提示词后，对照这个清单检查一遍：

检查项	自检问题	通过标志
任务明确	模型看完第一句是否无需猜测“我要什么”？	是
格式指定	输出格式有明确示例或规则？	是
长度约束	有具体数字（字/词/段落数）？	是
边界处理	输入为空、格式错误时怎么办？	是
指令与输入隔离	用户输入用分隔符包裹了？	是
一次性测试	至少用一组正常数据和一组异常数据测试过？	是

一个完整示例

任务

给定一组销售记录，要求模型按月份汇总销售额，输出 Markdown 表格。

第 1 版提示词

汇总以下销售数据，输出表格。
2025-01-01, 产品A, 1200
2025-01-15, 产品B, 800
2025-02-01, 产品C, 1500
2025-02-10, 产品A, 900

输出问题：模型可能只输出简单的列对齐文本，或用中文“2025年1月”和英文“Jan 2025”混用，格式不统一。

第 2 版提示词（优化后）

你是销售数据汇总助手。你只会输出 Markdown 格式的表格。

以下是销售记录，每条一行：日期（YYYY-MM-DD），产品名称，销售额（元）。

请按自然月（YYYY-MM 格式）汇总销售额，输出 Markdown 表格。表格包含三列：月份（格式 YYYY-MM）、产品数量、总销售额（元）。只输出表格，不要其他文字说明。

如果输入数据为空，输出空表格（只有表头，没有数据行）。

原始数据：
2025-01-01, 产品A, 1200
2025-01-15, 产品B, 800
2025-02-01, 产品C, 1500
2025-02-10, 产品A, 900

预期输出：

月份	产品数量	总销售额（元）
2025-01	2	2000
2025-02	2	2400

边界测试

将输入改为空行后，模型应输出：

月份	产品数量	总销售额（元）

（只有表头，没有数据行）

故障排查

提示词无效时，按以下顺序检查前三项原因（大约解决 90% 的问题）：

1. 验证起始状态

确认模型版本：打开模型对话界面，查看当前加载的模型名称和版本号。不同版本的行为差异可能是最大的变数。
确认对话是全新的：如果当前对话已有历史记录，模型可能受到之前指令的影响。新建一个会话重新测试。
确认没有全局系统提示：部分 API 或平台会自动附带系统提示（如“你是 Claude，由 Anthropic 创造”）。检查 API 调用中的 System 参数是否为空。

2. 对比预期与实际结果

写出你期望的输出格式，然后逐条与模型的实际输出对比差异：

格式不同 → 检查是否提供了明确格式示例。
内容遗漏 → 检查是否要求了“不要遗漏任何行”或类似约束。
长度不符 → 检查长度约束是否有歧义（如“不超过 3 个要点”比“简短”有效）。

3. 回滚更改

当你搞砸了——不要继续调整，直接回到上一个能用的版本。

保留每个版本的提示词草稿（用版本号或时间戳标记）。
每次只修改一个变量。如果同时改了格式和边界条件，你无法判断哪个改动导致了问题。

常见问题