Prompt Engineering

这一节解决什么问题

Prompt Engineering 不是"写一句好提示词"那么简单。在 LLM 应用和 Agent 系统中，Prompt 是约束模型行为的核心工程手段——它定义模型的角色、任务边界、输入输出格式、工具调用约束和安全边界。

好的 Prompt Engineering 能降低模型输出的随机性、提高结构化输出的稳定性、让工具调用参数更可靠。差的 Prompt 设计会导致模型行为不可预测、输出格式不稳定、工具调用频繁出错。

本节会系统讲解 Prompt Engineering 的核心概念、工程化方法和常见误区。

核心概念

System Prompt

System Prompt 定义模型的角色、能力边界和行为约束。它是整个对话的"基调"，决定了模型应该如何理解用户请求、如何组织输出、在什么情况下拒绝回答。

好的 System Prompt 应该明确：模型是谁（角色）、能做什么（能力边界）、不能做什么（安全约束）、输出什么格式（结构化要求）。

User Prompt

User Prompt 是用户的实际请求。在 Agent 系统中，User Prompt 可能不是用户的原始输入，而是经过系统处理后的结构化指令。

User Prompt 的设计要考虑：指令是否清晰、是否包含足够的上下文、是否与 System Prompt 中的角色定义一致。

Few-shot Prompting

Few-shot 是在 Prompt 中给出几个输入输出的示例，让模型通过示例学习期望的行为模式。这比纯文字描述更有效，因为模型可以直接从示例中提取模式。

Few-shot 的关键：示例要覆盖典型场景和边界案例、示例的格式要与期望输出一致、示例数量不宜过多（通常 2-5 个）。

结构化输出

要求模型按照固定的格式输出（如 JSON、XML、特定模板），而不是自由文本。结构化输出是 Agent 系统的基础——工具调用参数、任务分解结果、状态更新都需要结构化格式。

实现方式包括：在 Prompt 中明确输出格式要求、给出输出示例、使用 JSON Schema 约束、配合模型的结构化输出能力（如 function calling）。

Prompt 模板化

Prompt 不应该散落在代码中硬编码，而应该作为模板管理。模板化的好处是：Prompt 可以独立于代码修改、可以复用、可以版本化、可以做 A/B 测试。

模板通常包含变量占位符（如用户输入、工具描述、上下文信息），在运行时填充。

Prompt 版本管理

Prompt 是系统的核心配置，每次修改都应该有版本记录。版本管理的好处是：可以回溯到之前的版本、可以对比不同版本的效果、可以在出问题时快速回滚。

Prompt 版本应该和评测数据关联——每次 Prompt 变更后，用回归测试验证效果。

输出格式约束

除了要求模型输出特定格式外，还需要在工程层面做输出校验。模型的结构化输出可能有格式错误（如 JSON 语法错误）、字段缺失、类型不匹配等问题。

输出校验应该在 Prompt 之外、由代码层完成——不要把格式正确性完全寄托在模型上。

安全边界提示

Prompt 中需要明确安全约束：模型不应该执行哪些操作、不应该输出哪些内容、遇到敏感请求应该如何处理。安全边界提示是 Agent 系统安全性的重要组成部分，但不能作为唯一的安全手段。

分步骤分析提示

在需要模型进行复杂推理时，可以在 Prompt 中要求模型"先分析再输出"——先列出关键因素和分析步骤，再给出最终结论。这比直接要求模型给出答案更可靠，因为模型需要显式地组织推理过程。

注意：这种方式是 Prompt 技巧，不是系统记录。系统不应该保存模型的中间分析过程，只需要记录最终输出和关键决策摘要。

为什么重要

Prompt Engineering 在 LLM 应用和 Agent 系统中的价值体现在多个方面。

首先，约束模型行为。没有好的 Prompt，模型的行为是不可预测的——可能用不同的语气、输出不同的格式、在不同的场景下做出不同的判断。Prompt 通过角色定义、行为约束和输出格式要求，让模型的行为变得可预期。

其次，降低输出随机性。LLM 的输出天然有随机性，但好的 Prompt 可以显著降低这种随机性。Few-shot 示例、明确的格式要求、结构化输出约束都能让模型的输出更稳定。

再次，让工具调用参数更可靠。Agent 系统中，模型需要生成工具调用参数。如果工具描述不清晰、参数约束不明确，模型会频繁生成无效参数。Prompt 和工具 Schema 的配合设计是 Tool Calling 可靠性的关键。

最后，让系统边界更清晰。Prompt 定义了模型"能做什么"和"不能做什么"，这是 Agent 系统安全性的重要组成部分。清晰的系统边界能让用户、开发者和审计方都明确系统的职责范围。

工程化理解

从工程角度看，Prompt 不是"写完就不管"的配置，而是需要持续管理的工程资产。

Prompt 不应该散落在代码中。硬编码在代码里的 Prompt 难以修改、难以复用、难以版本化。Prompt 应该作为独立的配置文件或模板文件管理。

Prompt 应该模板化。Prompt 中的变量部分（用户输入、工具描述、上下文信息）应该用占位符表示，在运行时填充。这样同一个 Prompt 模板可以用于不同的输入。

Prompt 应该版本化。每次 Prompt 修改都应该有版本记录，包括修改内容、修改原因、评测结果。版本化让 Prompt 变更可追溯、可回滚。

Prompt 应该配合结构化输出校验。不要把输出格式的正确性完全寄托在模型上。Prompt 要求输出 JSON，代码层也要做 JSON 解析和字段校验。

Prompt 应该和工具 Schema、状态字段、错误处理配合。Prompt 不是独立的——它需要和工具定义一致（工具描述要和 Prompt 中的说明匹配）、和状态结构一致（输出字段要和状态字段对应）、和错误处理配合（Prompt 要告诉模型如何处理工具返回的错误）。

Prompt 变更应该可追踪。每次 Prompt 修改后，应该用回归测试验证效果。如果效果下降，可以快速回滚到之前的版本。

常见误区

误区一：Prompt 越长越好

Prompt 过长会增加 token 消耗、可能超出上下文窗口、还可能让模型"迷路"。好的 Prompt 应该精炼、清晰、有结构，而不是把所有信息都塞进去。

误区二：只靠 Prompt 就能保证模型稳定

Prompt 能约束模型行为，但不能完全消除随机性。结构化输出校验、参数验证、错误处理等工程手段是 Prompt 的必要补充。把系统稳定性完全寄托在 Prompt 上是危险的。

误区三：Prompt 可以替代权限控制

Prompt 中说"你不能执行删除操作"不代表模型一定不会生成删除调用。安全约束必须在执行层实现（代码层的权限校验），不能只靠 Prompt 提示。

误区四：Prompt 不需要版本管理

Prompt 是系统的核心配置，和代码一样需要版本管理。没有版本管理，Prompt 的修改历史无法追溯，出了问题无法回滚。

误区五：Prompt 写好后就不用评测

Prompt 的效果会随着模型更新、输入分布变化而变化。需要定期用评测数据验证 Prompt 的效果，发现下降时及时调整。

和项目的关系

后续在项目实践中，Prompt Engineering 会用于定义模型的任务边界、输入输出格式和工具调用约束。当前阶段只做知识准备，不展开具体项目实现。

理解 Prompt 的模板化管理、版本化、结构化输出约束和安全边界设计，是构建可靠 Agent 系统的基础。

面试表达

可以这样表达：

> 我理解的 Prompt Engineering 不是简单写提示词，而是将模型行为约束、任务边界、输出格式和工程校验结合起来。对于 Agent 系统来说，Prompt 要和工具 Schema、状态管理、结构化输出校验一起设计，不能把系统稳定性完全寄托在自然语言提示上。Prompt 本身也需要工程化管理——模板化、版本化、配合回归测试。每次 Prompt 变更都要验证效果，确保优化没有引入新问题。