提示工程（Prompt engineering）

Prompt engineering 是使用 LLM 时最实用的技术之一。它能让你在不修改模型本身的情况下，引导模型行为、提升输出质量，并构建可靠的应用。

什么是 prompt engineering？

Prompt 本质上就是你发送给 AI 模型的输入。模型可以进行推理并生成文本，但它需要依赖 prompt 来理解：

• 它应执行什么任务
• 答案应遵循什么格式
• 它必须遵守哪些约束

Prompt engineering 就是以某种方式组织指令、示例和上下文，使模型更倾向于产出你想要的结果。对于许多 inference 工作负载来说，更好的 prompt 往往是获得更好结果的最简单路径。

例如，下面两个 prompt 会产生非常不同的结果：

# Basic prompt
Summarize this article.

# Improved prompt
Summarize the article in three bullet points.
Focus on key technical insights.
Do not include opinions or marketing language.

第二个 prompt 给了模型清晰的期望，因此更容易得到更有意义的输出。

为什么 prompt engineering 对 inference 很重要

面向 LLM 的 prompt engineering 与 inference 的工作方式密切相关。

在 inference 期间，模型不会改变权重。它只是基于收到的输入生成 token。这意味着 prompt 就成了应用与模型之间的主要接口。你的 prompt 设计会直接影响模型在运行时的行为。

Token 使用量与成本

每个请求都包含输入 token（prompt）和输出 token（生成的响应）。更长的 prompt 会增加模型需要处理的 token 数量，这会影响：

• Latency：更多 token 意味着 prefill 阶段需要更多计算
• GPU utilization：更多 token 需要更多算力和内存带宽
• Inference cost：按 token 计费或基础设施成本会随着 token 使用量增长

对于高吞吐 inference 系统，prompt 长度会成为一个重要的优化因素。

KV cache 使用

LLM inference 严重依赖 KV cache (Key-Value cache) 来加速生成。

在 prefill 阶段，模型会处理整个 prompt，并把中间 attention states 存入 KV cache。到了 decoding 阶段，模型会复用这份 cache，而不是重新计算先前 token 的 attention。

不过，KV cache 的大小会随着 prompt 中 token 数量增加而增长。这意味着更长的 prompt 会导致：

• 更大的 KV cache 内存占用
• 更高的 GPU VRAM 消耗
• 每块 GPU 可同时处理的并发请求更少

对于大模型或长上下文工作负载，prompt 大小会直接影响 throughput 和系统可扩展性。

模型可靠性

在生产 inference 系统中，模型必须在成千上万甚至数百万次请求中保持行为一致。

结构不良的 prompt 可能导致：

• 输出不一致
• 格式错误
• 意外的推理路径

精心设计的 prompt 可以降低这些风险。通过清晰定义任务、输出格式和约束，你可以让模型在 inference 期间的行为更加可预测。

当 LLM 被嵌入自动化工作流、API 或 agentic 系统中时，这一点尤其重要。

运行时控制层

在许多 AI 部署中，prompt engineering 成为了模型之上的第一层控制。开发者无需修改模型本身，而是通过调整 prompt 来：

• 强制输出结构（JSON、markdown 等）
• 控制语气或风格
• 限制行为
• 引导推理

由于 prompt 是请求 payload 的一部分，它可以快速更新，而无需重新训练模型或修改 serving 基础设施。这使 prompt 成为在生产环境中引导模型行为的一种灵活方式。

Prompt engineering 往往会与 inference parameters 一起调优。Prompt 定义任务和约束，而 temperature、top_p、max_tokens 等参数则控制模型如何采样以及如何限制响应长度。

Prompt 角色

大多数现代 LLM API 会把 prompt 拆分成不同角色。最常见的类型有：

• System prompt
• User prompt
• Assistant messages

系统提示词（System prompt）

System prompt 定义模型的整体行为。它相当于一组操作指令，用于指导模型如何响应。

示例：

You are a technical assistant that explains LLM inference concepts clearly.
Use short paragraphs and simple language.
Avoid unnecessary jargon.

对于开发者来说，system prompts 通常用于：

• 定义 assistant 的角色或 persona
• 强制响应格式（例如 JSON）
• 限制话题或行为
• 提供任务特定指令

对于直接与聊天界面交互的个人用户，system prompt 通常是隐藏在后台的。它由应用开发者配置，用于帮助在不同用户之间保持一致行为。

用户提示词（User prompt）

User prompt 包含用户或应用真正发送的请求。

示例：

Explain what a transformer model is in simple terms.

对于个人用户来说，这就是他们在聊天界面里输入的问题或指令。

对于开发者来说，user prompt 往往由应用动态生成。它可能包含：

• 用户输入
• 从数据库检索出的文档
• 对话上下文
• 结构化任务指令

例如，在一个文档问答系统中，user prompt 可能如下所示：

Answer the question using the context below.

Context:
{retrieved_documents}

Question:
{user_question}

在生产 inference 系统中，user prompts 通常会先通过程序拼装，再发送给模型。

提示词模板（Prompt templates）

在生产系统中，prompt 很少每次都手写。相反，开发者通常会使用插入动态数据的 prompt templates。

示例模板：

You are a helpful assistant.

User question:
{question}

Provide a concise answer in three bullet points.

Prompt templates 使以下事情更容易实现：

• 在应用间标准化 prompt
• 保持一致性
• 在一个地方更新行为

像 LangChain、LlamaIndex 以及许多 inference 平台都支持 templated prompts。

助手消息（Assistant messages）

Assistant messages 表示模型在对话先前轮次中生成的响应。它们主要有两个用途：

• 表示先前的模型输出
• 被开发者用来引导或约束后续响应

由 API 返回

在大多数 chat API 中，模型会返回一个角色为 assistant 的 message。构建多轮对话时，应用通常会在下一次请求里带上这些先前消息。

示例：

messages = [
  {"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?"}
]

通过包含先前消息，模型就能维持连贯的对话。

但从模型视角来看，这些消息并不会被特殊对待。在 inference 期间，整个对话历史只是被转换成一串 token，并作为输入 prompt 的一部分进行处理。

对于大型 inference 系统，长对话会降低 throughput，并提高基础设施成本。为管理这一点，AI 团队通常会实现以下策略：

• 截断消息，只保留最近几轮
• 对旧上下文做对话总结压缩
• 使用 Prefix caching 复用共享 prompt 片段
• 使用 KV cache offloading 在需要时把 cache 数据迁移到低成本存储

由开发者注入

Assistant messages 不一定只能来自模型本身。开发者也可以插入合成的 assistant messages 来引导模型行为。

这种技术有时被称为 assistant prefilling 或 response prefixing。

由于 LLM 是自回归模型（它会基于之前所有 token 预测下一个 token），模型并不在乎 "Assistant" 角色中的文字究竟是它自己生成的，还是你手动写进去的。它只会把这些文字视作既定开头，并从那里继续。

这让开发者可以引导响应或强制结构。例如，你可以引导模型生成有效的 JSON 输出：

messages = [
  {"role": "user", "content": "Show me a list of popular open-source llms in JSON."},
  {"role": "assistant", "content": "Here is the JSON list you need:\n{"}, # The model continues from here
]

大多数现代 chat 风格 LLM API 都支持 assistant prefilling。不过，具体 API 结构以及这种行为的可靠性会因 provider 和模型而异。

编写更好 prompt 的实用技巧

几个简单做法就能显著提升结果：

说得明确

准确告诉模型你想要什么。

不佳示例：

Explain this.

更佳示例：

Explain this concept to a beginner using simple language and one example.

指定输出格式

如果你的应用需要 structured output，就明确写出来。

示例：

Return the answer in JSON format with fields:
- summary
- key_points
- confidence

保持 prompt 聚焦

包含无关指令的长 prompt 可能会让模型困惑。应让指令清晰、聚焦任务本身。

测试不同变体

微小的措辞变化有时会带来很大的结果差异。Prompt engineering 通常需要实验和迭代。

---

当你开始构建真实系统时，通常会把 LLM prompt engineering 与其他技术结合使用，例如 structured outputs、 tool calling 和 fine-tuning。理解 prompt 如何影响模型行为，是构建稳健 LLM 应用的第一步。

常见问题

什么是 zero-shot、one-shot 和 few-shot prompting？

这些术语描述的是：为了引导模型，你在 prompt 中包含了多少示例。

Zero-shot prompting 表示 prompt 中只有指令，没有示例。

Classify the sentiment of the following sentence as Positive or Negative.

Sentence: I really enjoyed this movie.

模型只能根据指令本身来完成任务。

One-shot prompting 会提供一个示例，用来展示期望的行为。

Classify the sentiment of the following sentences.

Sentence: This restaurant is amazing.
Sentiment: Positive

Sentence: The service was terrible.
Sentiment:

这个示例能帮助模型理解应当遵循的模式。

Few-shot prompting 则会在真实输入前提供多个示例。借助这些示例，模型能更好地识别模式，并生成更可靠的结果。

Classify the sentiment of the following sentences.

Sentence: This restaurant is amazing.
Sentiment: Positive

Sentence: The service was terrible.
Sentiment: Negative

Sentence: I really enjoyed the meal.
Sentiment:

下面是一个并列对比：

类型	含义	示例用途	权衡
Zero-shot prompting	Prompt 仅包含指令，不包含示例。	总结、翻译等通用任务。	Prompt 短、token 成本低，但模型可能误解格式或预期。
One-shot prompting	Prompt 包含一个示例，展示期望输入输出模式。	教模型特定格式或风格。	Prompt 稍长，但有助于澄清任务。
Few-shot prompting	Prompt 在真实输入前包含多个示例。	分类、structured outputs 或领域特定格式。	往往能提升可靠性，但会增加 token 使用量和 inference 成本。

prompt engineering 和 fine-tuning 有什么区别？

Prompt engineering 和 fine-tuning 都旨在改善模型输出，但它们工作的方式非常不同。

方法	改变的是什么	适用场景
Prompt engineering	调整输入 prompt 中的指令	快速迭代、格式控制、任务引导
Fine-tuning	使用训练数据更新模型权重	领域知识、专门任务

Prompt engineering 通常是第一步。它快速、灵活，而且不需要训练基础设施。Fine-tuning 在以下情况下会变得有用：

• 仅靠 prompt 无法产出可靠输出
• 任务需要模型本身并不具备的领域知识
• Prompt 变得过长或过于复杂
• 对一致性的要求非常严格

许多生产系统会将这两种技术一起使用：

1. 先从 prompt engineering 开始。
2. 如果需要，再加入 few-shot examples。
3. 当 prompt 改进达到极限后，再对模型进行 fine-tuning。

什么是 Chain-of-Thought (CoT) prompting？

Chain-of-Thought prompting 是一种 prompt engineering 技术，它鼓励 LLM 在给出最终答案前先生成中间推理步骤。

这项技术最早由论文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 提出，作者为 Jason Wei et al. (2022)。作者表明，提示模型生成中间推理步骤，可以显著提升它在数学题、推理和逻辑推断等任务上的表现。

图片来源：Chain-of-Thought Prompting Elicits Reasoning in Large Language Models

不过，对于 inference 系统来说，这里有一些权衡：

• 推理步骤会增加输出 token 长度
• 更长的输出会增加 latency 和 inference cost
• 如果只需要最终答案，推理文本可能还需要额外过滤

因此，一些生产系统会在内部生成推理过程，只把最终结果返回给用户。

prompt engineering 在什么情况下会失效？

Prompt engineering 很强大，但它也有边界。如果一个任务需要模型并不具备的领域知识，或者你需要在数百万次请求中保持严格一致性，那么仅靠 prompt engineering 可能不够。在这些情况下，可能需要使用 fine-tuning、RAG，或 constrained decoding 等技术。

附加资源

• Prompt Engineering Guide
• Prompting best practices
• Automatic Chain of Thought Prompting in Large Language Models