提示工程

概述

提示工程是如何编写和组织 LLM 指令以获得最优输出的艺术与科学——本质上是一次性、静态的文本设计问题，正在被上下文工程这一动态多轮信息策展范式所取代。

关键内容

1. 定义与局限：提示工程关注单次 LLM 调用中的文本设计，即 [System Prompt + User Query] → Response 的模式。核心挑战是如何通过精准的指令编写、示例选择和格式组织来引导模型输出期望结果。但在多轮 Agent 循环中，每一轮都生成新数据，单纯依靠静态提示设计无法解决上下文质量随轮次衰减的问题。

2. 与上下文工程的范式对比：

3. 提示工程：解决"如何说"的问题——一次性文本设计
4. 上下文工程：解决"何时加入什么信息"的问题——动态多轮信息策展

5. 范式迁移的驱动力是从单次对话到多轮 Agent 循环的转变，带来了根本性复杂度提升

6. 少样本示例策略：精心选择多样化、有代表性的典范示例，而非穷举所有边缘情况。危险做法是将大量边缘情况堆砌到 prompt 中——示例是"图片"不是规则集，过多边缘示例会淹没核心模式。

7. 系统提示设计原则：Anthropic 提出的"适当高度（Right Altitude）"原则同样适用于提示工程——介于硬编码复杂逻辑（过低）和过度抽象（过高）之间的黄金区间，提供足够具体的行为启发，同时允许灵活处理未预见情形。

8. 历史地位：提示工程是 LLM 应用工程的起点，随着模型能力提升和 Agent 系统复杂化，工程挑战从"如何写"升级为"何时加入什么信息"，但提示工程的核心原则（清晰指令、恰当示例、结构化格式）仍然是上下文工程的基础组成部分。

来源

• raw/articles/ai-engineering/anthropic-engineering/claude-engineering/04_context_engineering.md — Anthropic Applied AI 团队上下文工程分析

相关

• 上下文工程 — supersedes（上下文工程正在替代提示工程成为核心挑战）
• Agent 架构与设计原则 — relates_to
• Token 资源管理 — relates_to