Prompt Engineering 关键概念

Prompt Engineering 不是只写一句“好提示词”，而是在设计模型看到的任务说明、上下文、示例、约束和输出格式。

这里只记录几个最关键、最常被反复提到的概念：Zero-shot、Few-shot、XML 标签和 Chain of Thought。

Zero-shot Prompting

Zero-shot 是不给示例，直接让模型完成任务。

比如：

把下面这段文字总结成三点。

它适合任务本身比较清楚、模型已经很熟悉的场景，比如总结、翻译、改写、简单分类、常识问答。

Zero-shot 的优点是 prompt 短、成本低、维护简单。缺点是如果任务标准比较细，模型可能会按自己的默认理解来做，输出不一定稳定。

Few-shot Prompting

Few-shot 是在 prompt 里给几个输入输出示例，让模型模仿这些示例完成新任务。

比如：

请判断用户反馈的情绪。

示例 1：
输入：这个功能太好用了。
输出：正向

示例 2：
输入：页面一直打不开，很烦。
输出：负向

现在判断：
输入：还行，但加载有点慢。
输出：

Few-shot 的价值不只是“教模型知识”，更重要的是告诉模型：

判断标准是什么
输出格式是什么
边界样例应该怎么处理
语气和粒度应该长什么样

当任务有固定格式、业务标准、分类口径或风格要求时，Few-shot 通常比只写规则更稳定。

XML 标签

Anthropic 的 prompt engineering 文档里经常推荐用 XML 标签组织 prompt。它的核心作用是把不同类型的信息清楚分隔开，减少模型混淆。

比如：

<task>
总结用户提供的会议记录。
</task>

<context>
读者是项目经理，需要快速知道结论和风险。
</context>

<transcript>
这里放会议记录原文。
</transcript>

<format>
用 Markdown 输出：结论、风险、待办。
</format>

XML 标签不一定有特殊魔法，重点是结构清晰、边界明确。它适合长 prompt、多段上下文、多份材料、复杂输出要求，以及需要把用户输入和系统指令分开的场景。

实际写 prompt 时，Markdown 标题、代码块、分隔线也能起到类似作用。但 XML 标签的好处是层级和边界更显式，尤其适合 Anthropic Claude 这类文档里推荐的写法。

Chain of Thought

Chain of Thought，简称 CoT，通常指让模型进行分步推理。

早期常见写法是：

Let's think step by step.

中文里也常写成：

请一步一步思考。

CoT 对数学题、逻辑推理、规划、多约束决策这类任务很有帮助，因为它鼓励模型不要直接跳到答案，而是先拆解问题。

不过工程实践里不一定要让模型输出完整思维链。更常见、更稳妥的做法是要求模型给出简洁的推理摘要或关键依据：

请先分析关键因素，再给出结论。输出时只保留简要依据。

这样既能利用分步推理的好处，又避免输出过长、暴露不必要的中间推理，或者把不可靠的中间过程当成事实。