1. Introduction to Prompt Engineering
什么是提示词工程？
提示词工程是一门技术实践，致力于开发、组织和优化语言输入，以引导大语言模型（LLM）产生特定、可靠的输出。它结合了以下领域的原则：
- 语言学：理解语言结构如何影响理解
- 认知心理学：利用模型处理和生成信息的方式
- 软件工程：应用系统化的设计、测试和迭代模式
- 机器学习：理解模型的能力、限制和行为
与代码确定性执行的传统软件工程不同，提示词工程运作在生成式 AI 的概率空间中，措辞的细微变化可能显著影响结果。
核心洞察
"提示词工程弥合了人类意图与机器理解之间的差距。"
将其想象为与 AI 设计 API 契约：你指定输入、约束和预期输出，以实现可预测的生产级行为。正如 API 设计需要仔细考虑请求/响应格式、错误处理和文档，提示词工程需要精心设计提示词结构、上下文提供和输出规范。
提示词工程背后的科学
2022-2025 年的研究已将提示词工程确立为一门严谨的学科：
| 研究领域 | 关键发现 | 影响 |
|---|---|---|
| 少样本学习（Brown et al., 2020） | 从 3-5 个示例进行上下文学习改善任务适应 | +40% 准确率提升 |
| 思维链（Wei et al., 2022） | 显式推理步骤改善数学/逻辑性能 | 复杂任务 +23-50% |
| 自洽性（Wang et al., 2023） | 多条解决路径 + 多数投票 | 比 CoT 单独使用 +11-17% |
| 思维树（Yao et al., 2023） | 带前瞻的审慎问题求解 | Game of 24 成功率 74% vs 4% |
| ReAct（Yao et al., 2022） | 推理 + 行动模式用于工具使用 | Agent 任务 +34% |
这些发现表明提示词工程不是试错——它是解锁模型能力的系统化方法。
为什么在 2025 年很重要
企业影响
| 指标 | 影响 | 来源 |
|---|---|---|
| 质量提升 | 精心设计的提示词提升输出质量 3-5 倍 | Braintrust 2025 调查 |
| 成本降低 | 结构化输出减少 Token 浪费 30-50% | Leanware 分析 2025 |
| 可靠性 | 适当的模式将一致性从约 60% 提升到 95%+ | Lakera 研究 2025 |
| 开发速度 | 可复用模板加速迭代 70% | 行业基准 |
| 幻觉减少 | 上下文感知提示词减少虚假信息 40-60% | 学术研究 2024 |
实际应用
企业 AI 系统：
- 客户支持：基于 RAG 的助手从公司文档回答问题，准确率 90%+
- 代码生成：为 API 集成和数据库记录提供类型安全输出，错误率低于 5%
- 内容运营：可扩展的内容流水线，格式一致，品牌语调统一
- 数据抽取：从非结构化文档（发票、合同、报告）中提取结构化 JSON
- Agent 工作流：用于复杂决策和研究综合的多 Agent 系统
行业特定用例：
| 行业 | 应用 | 技术 |
|---|---|---|
| 医疗 | 病历摘要 | CoT + 结构化输出 |
| 金融 | 欺诈检测分析 | ReAct + RAG |
| 法律 | 合同审查和提取 | Few-Shot + XML 标签 |
| 教育 | 个性化辅导系统 | 多轮推理 |
| 制造 | 技术文档生成 | 基于模板的提示词 |
演进历程：2022-2025
2022: Zero-Shot 时代
├─ 简单提示词，基本指令
├─ "告诉我关于 X" 风格的查询
└─ 有限结构，不可预测的输出
2023: Few-Shot + CoT 革命
├─ 添加示例（少样本学习）
├─ 思维链推理步骤
├─ 结构化格式规范
└─ 显著的准确率提升
2024: 结构化输出与工具使用
├─ JSON/XML schema 强制
├─ 函数调用和工具集成
├─ RAG（检索增强生成）
└─ 生产级模式出现
2025: 智能体 AI 与评估
├─ 多 Agent 编排
├─ 自动化提示词优化
├─ 系统化评估框架
└─ CI/CD for prompts（promptOps）
转变：从一次性提示词到工业规模的提示词基础设施。2022 年，提示词工程是早期采用者实践的艺术形式。2025 年，它是一门系统化的工程学科，具备：
- 标准化模式（CO-STAR、RTF、CRISP 框架）
- 评估框架（RAGAs、TruLens、Arize Phoenix、Promptfoo）
- 版本控制系统（PromptLayer、Weights & Biases、DVC）
- 自动化优化（APE、DSPy、OptiGuide）
- 生产监控（LLM 可观测性平台）
关键原则
1. 结构优于巧妙
"结构良好的提示词每次都能打败巧妙的提示词。"
// ❌ 模糊 - 结果不可预测
"Tell me about climate change"
// ✅ 结构化 - 可靠的输出
<persona>You are a climate scientist specializing in public communication</persona>
<context>For a general audience with no scientific background</context>
<task>Explain the causes, effects, and solutions in 3 paragraphs</task>
<constraints>Use simple language, avoid jargon, include one concrete example</constraints>
<output_format>Return as clear paragraphs with section headers</output_format>
为什么结构有效：
- 明确边界：模型知道具体要做什么
- 减少歧义：清晰的规范最小化误解
- 可复现：结构化提示词可以版本化和测试
- 协作性：团队可以共享和迭代模板
2. 度量优先
"没有度量，提示词工程就是猜测。"
每个生产提示词都应有：
成功标准：
accuracy_target: 0.95 # 95% 正确答案
latency_p95: 2000ms # 第 95 百分位 < 2 秒
cost_per_query: $0.02 # 最大可接受成本
relevance_threshold: 0.8 # 上下文相关性分数
评估指标：
- 任务特定：准确率、F1 分数、BLEU、ROUGE
- 质量导向：相关性、连贯性、有用性
- 运营指标：延迟、Token 使用量、错误率
- 业务指标：用户满意度、任务完成率
生产监控：
@Component
public class PromptMetrics {
private final MeterRegistry registry;
public void trackPrompt(String promptId, String result) {
// 跟踪执行时间
registry.timer("prompt.duration", "id", promptId)
.record(() -> processPrompt(promptId));
// 跟踪 Token 使用量
registry.counter("prompt.tokens", "id", promptId)
.increment(calculateTokens(result));
// 跟踪质量指标
registry.gauge("prompt.quality", evaluateQuality(result));
}
}
3. 迭代改进
草稿 → 测试 → 评估 → 优化 → 重复
↓ ↓ ↓ ↓
度量 分析 对比 优化
迭代循环：
- 草 稿：基于最佳实践创建初始提示词
- 测试：在多样化测试数据集（100+ 样本）上运行
- 评估：衡量准确率、延迟、成本、质量
- 优化：基于失败分析调整
- 重复：持续迭代直到指标达标
迭代示例：
迭代 1："Summarize this article"
→ 准确率：65%，太模糊
迭代 2："Summarize in 3 bullet points"
→ 准确率：72%，结构更好
迭代 3：添加 few-shot 示例
→ 准确率：85%，大幅提升
迭代 4：添加约束和格式规范
→ 准确率：94%，生产就绪
4. 上下文为王
"正确的上下文将一个困惑的模型变成专家助手。"
上下文类型：
| 类型 | 目的 | 示例 |
|---|---|---|
| 领域知识 | 确立专业背景 | "You are a senior Java architect" |
| 任务上下文 | 定义具体工作 | "Reviewing code for security issues" |
| 环境上下文 | 描述场景 | "E-commerce platform processing 10K TPS" |
| 受众上下文 | 针对性输出 | "For non-technical stakeholders" |
| 历史上下文 | 提供相关背景 | "Previous attempts showed X issue" |
5. 约束激发创造力
"矛盾的是，约束使 LLM 更有创意和专注。"
约束类型：
// 负面约束（不要做什么）
<constraints>
- Do NOT suggest architectural changes
- Do NOT use external libraries
- Do NOT exceed 200 lines of code
- Do NOT include TODO comments
</constraints>
// 正面约束（要做什么）
<requirements>
- MUST use Java 17+ features
- MUST include error handling
- MUST provide unit tests
- MUST follow Spring Boot conventions
</requirements>
// 格式约束（如何输出）
<output_format>
Return ONLY valid JSON with this schema:
{
"summary": "string",
"issues": ["array of strings"],
"recommendations": ["array of strings"]
}
</output_format>
你将学到什么
本指南涵盖从基础到生产部署的提示词工程：
第一部分：基础
| 章节 | 内容 | 收获 |
|---|---|---|
| 1. 引言 | 本节 — 为什么重要、核心原则、演进 | 理解提示词工程的战略价值 |
| 2.1 提示词剖析 | 五个组件：角色、指令、上下文、约束、格式 | 系统化构建结构良好的提示词 |
| 2.2 核心推理模式 | Zero-shot、Few-shot、CoT、ReAct、自洽性、思维树 | 应用研究支持的技术 |
| 2.3 结构化输出 | JSON 模式、XML 标签、Anthropic prefilling、Spring AI 转换器 | 获得可解析的类型安全输出 |
第二部分：生产实现
| 章节 | 内容 | 收获 |
|---|---|---|
| 2.4 Spring AI 实现 | ChatClient、PromptTemplate、RAG、advisors、工具调用 | 用 Spring Boot 构建企业 AI 应用 |
| 2.5 评估与版本控制 | LLM-as-judge、A/B 测试、CI/CD 集成、监控 | 实现系统化的提示词工程工作流 |
第三部分：高级模式
| 章节 | 内容 | 收获 |
|---|---|---|
| 3.1 高级技术 | 自我批评、迭代精炼、元提示、多轮推理 | 利用高级推理能力 |
| 3.2 多模态提示 | GPT-4V、Gemini、Claude 的视觉-文本、Spring AI 视觉集成 | 构建处理图像+文本的应用 |
| 3.3 Agent 编排 | 层次化、并行、共识、生产者-审查者模式 | 设计复杂的多 Agent 系统 |
开始之前
前提条件
技术背景：
- 基本 LLM 了解：理解 GPT/Claude/Gemini 的基本能力
- 编程基础：Spring AI 章节需要 Java/依赖注入知识
- API 经验：理解 REST API 和 JSON 数据结构
心态准备：
- 实验性：愿意迭代和测试不同方法
- 分析性：能够评估结果并识别失败模式
- 系统化：以测试和度量为导向，而非试错
- 耐心：认识到提示词优化需要多次迭代
推荐工具
| 工具 | 用途 | 最适合 |
|---|---|---|
| Spring AI 1.0 | 企业 Java 框架 | 本指南重点，生产应用 |
| LangChain | Python 替代方案 | 原型开发，跨平台开发 |
| PromptLayer | 提示词版本控制和评估 | 跟踪提示词实验 |
| Weights & Biases | 实验跟踪 | ML 工作流 ，详细指标 |
| Promptfoo | 开源测试 | 本地开发，CI/CD 集成 |
| Arize Phoenix | LLM 可观测性 | 生产监控，链路追踪 |
| TruLens (RAGAs) | RAG 评估 | 检索增强系统 |
| DSPy | 自动化提示词优化 | 高级用户，编程式提示词 |
商业案例
为什么投资提示词工程？
1. 速度：无需重新训练模型即可迭代
传统 ML：模型更新需要数周到数月
提示词工程：分钟级迭代和部署
速度提升：100-1000 倍
2. 灵活性：即时适应新需求
// 需要改变输出格式？更新提示词模板
// 需要添加新约束？添加到 <constraints> 部分
// 需要面向不同受众？更新 <persona> 和 <context>
// 所有变更分钟级部署，而非数周
3. 成本：优化 Token 使用和减少 API 调用
优化前：2000 tokens/查询，$0.06/查询
优化后：800 tokens/查询，$0.024/查询
结果：大规模使用下成本降低 60%
4. 可靠性：达到生产级一致性
非结构化提示：约 60% 一致性
结构化提示：约 95% 一致性
改进：输出可靠性提升 58%
5. 可维护性：版本控制、可测试的提示词
# prompts/qa/v2.1.yaml
id: qa-rag-v2.1
version: "2.1"
previous: "v2.0"
changes:
- "Improved context extraction"
- "Added few-shot examples"
- "Refined constraints"
performance:
accuracy: 0.94 # 从 0.89 提升
latency_ms: 850 # 从 1200 降低
tokens: 650 # 从 900 降低
ROI 示例：客户支持助手
提示词工程之前：
- 准确率：65%（回答经常不正确或不相关）
- 解决率：40%（大多数问题升级给人工）
- 成本：$0.08/查询（高 Token 使用，重试提示）
- 客户满意度：3.2/5
系统化提示词工程之后：
- 准确率：94%（可靠、准确的响应）
- 解决率：78%（大多数问题自主解决）
- 成本：$0.025/查询（优化提示词，结构化输出）
- 客户满意度：4.6/5
商业影响：
- 人工升级减少 69%
- 每查询成本降低 69%
- 客户满意度提升 44%
- 中型支持团队年节省估计：$500K+
常见陷阱
| 陷阱 | 原因 | 解决方案 |
|---|---|---|
| 模糊指令 | 假设模型理解意图 | 使用结构化五组件格式 |
| 无输出格式 | 让模型自行决定如何响应 | 指定 JSON、markdown 或文本结构 |
| 忽略失败用例 | 仅用理想输入测试 | 用对抗性、边界情况输入测试 |
| 一次性提示 | 期望立即获得完美结果 | 复杂多步任务使用 CoT |
| 没有度量 | 依赖主观质量判断 | 从第一天开始实施评估 |
| 过度提示 | 添加过多上下文 | 从最小开始，增量添加上下文 |
| 复制粘贴提示词 | 不加调整使用模板 | 为特定领域定制化 |
| 忽视迭代 | 将提示词视为一次编写 | 规划持续改进 |
提示词工程心态
像老师一样思考
优秀的提示词工程师像老师一样思考：
- 明确期望：精确指定你要什么
- 提供示例：展示，而不仅仅是讲述
- 搭建支架：将复杂任务分解为步骤
- 给予反馈：用评估指导改进
- 适应学习者：为特定模型定制提示词
像工程师一样思考
优秀的提示词工程师像工程师一样思考：
- 定义需求：成功标准、约束、边界情况
- 系统设计：使用经过验证的模式和框架
- 全面测试：多样化数据集、失败模式
- 度量一切：跟踪指标并迭代
- 文档决策：版本控制、变更追踪
像科学家一样思考
优秀的提示词工程师像科学家一样思考：
- 提出假设："这种技术将提升 X% 准确率"
- 控制变量：一次只改变一件事
- 运行实验：A/B 测试不同提示词
- 分析结果：定量衡量改进
- 发表发现：与社区分享有效方法
开始检查清单
在深入下一章之前，确保你已具备：
- LLM 访问：OpenAI GPT-4、Anthropic Claude、Google Gemini 或本地模型
- 开发环境：Spring AI 示例需要 Java 17+，或 Python 替代方案
- API Key 已配置：用于模型访问的环境变量
- 测试数据集：与你用例相关的样本输入
- 评估框架：衡量成功的方法（准确率、质量等）
- 版本控制：用于提示词模板的 Git 仓库
- 迭代心态：准备好测试、优化和重复
快速入门练习
试试这个 5 分钟练习，亲身体验提示词工程：
任务：让 LLM 从非结构化文本中提取结构化数据
初始提示词（先试这个）：
Extract information from this text: [paste a product description]
改进提示词（然后试这个）：
<persona>You are a data extraction specialist</persona>
<context>E-commerce product catalog management</context>
<task>Extract the following fields from the product description:
- Product name
- Price (numeric value only)
- Brand
- Category
- Key features (list)</task>
<constraints>Return ONLY valid JSON, no markdown formatting</constraints>
<output_format>
{
"name": "string",
"price": number,
"brand": "string",
"category": "string",
"features": ["string"]
}
</output_format>
Product description: [paste the same product description]
观察差异：第二个提示词应该产生可靠可解析的 JSON，包含所有必需字段，而第一个可能遗漏信息或使用不一致的格式。
下一步
准备好深入了解？继续阅读 提示词剖析，学习使提示词有效的基础结构。
接下来你将掌握：
- 每个有效提示词的 5 个核心组件
- 如何构建最大清晰度和影响力的提示词
- 何时使用每个组件以及包含什么
- 展示前后对比的真实示例
下一篇：2.1 提示词剖析 →