提示工程基础

提示（Prompt）是你写给模型的指令。同样的模型，提示不同，结果可能天差地别；对 Agent 来说，提示不仅是「问问题」，更是定义它身份与行为规则的「说明书」。提示工程就是系统化设计这套说明书的学问。

一段好提示的五个要素

任何任务提示都建议覆盖五类信息：角色、目标、上下文、约束、输出格式。拼起来大致是这样一份「任务单」：

你是一名资深数据分析师。                      # 角色：模型以谁的身份工作
任务：把下面的聊天记录整理成项目周报。        # 目标：要达成什么
背景：团队本周上线 v2 版本，出现两次线上事故。 # 上下文：模型需要知道的事实
要求：不超过 200 字，只说结论与风险。          # 约束：必须遵守的边界
输出格式：Markdown 列表，每项一行。           # 输出格式：便于程序处理

要素逐个说清

• 角色：给模型一个身份（医生、代码评审员、SQL 专家），让它调用对应领域的表达习惯与检查标准。
• 目标：一句话说清「做完什么算成功」，别让模型猜。
• 上下文：只给与任务相关的背景，无关信息越多越容易带偏。
• 约束：字数、语气、禁止事项、不确定时怎么办，都属于约束。
• 输出格式：要列表、JSON 还是表格要写明；对 Agent 尤其重要，因为结果要交给程序处理。

少样本示例

除了解释规则，还可以直接给几个「输入→正确输出」的例子让模型模仿，这就是少样本（few-shot）：

把句子改写得更正式：
输入：老板让我周五前交报告。
输出：请于本周五前提交报告。
输入：这个接口挂了，快看下。
输出：

模型看到前两对示例后，会按「书面、直接」的口吻补完第三句，而不是按口语风格随意发挥。

提示词组织最佳实践

• 系统提示词放开头，明确角色与全局规则；用户消息放后面、紧跟当前问题。
• 重要信息（工具说明、硬规则）放开头或紧邻问题处，别埋在长文本正中间。
• 一次只交代一个核心目标，目标太多模型会顾此失彼。
• 该给规则时给规则，该给例子时给例子，两者常搭配使用。
• 输出格式要求写成模板或 JSON Schema，而不是一句「请返回 JSON」。
• 用换行、编号、标题把提示分区，模型对结构清晰的指令遵从度更高。
• 同一提示多跑几次观察波动：波动大未必是提示问题，也可能是温度设置偏高。

提示工程是 Agent 系统设计的一部分

对 Agent 而言，提示词不是一次性文案，而是与工具定义、上下文管理、循环逻辑并列的系统组件：它定义模型在循环里扮演什么角色、何时该调用工具、失败时怎么汇报。因此提示要跟着 Agent 一起设计、一起评测、一起迭代，作为代码一样版本化管理。

小结

提示工程五要素是角色、目标、上下文、约束与输出格式；少样本用例子补足规则说不清的部分，最佳实践清单保证提示稳定可维护。牢记：在 Agent 里提示是系统设计的一部分，不是写一次就交付的文案。