4. Prompt Engineering：Prompt设计原则、Few-shot与Chain-of-Thought、结构化Prompt模板

聊到Prompt Engineering，我脑子里第一个蹦出来的画面，是几年前带团队做智能客服项目。那时候模型刚出来，大家一股脑把用户问题扔进去，结果出来的答案经常让人哭笑不得。后来我花了整整两周，专门研究怎么写“提示词”。说白了，Prompt Engineering就是教你怎么跟大模型“好好说话”。

你想想看，模型再聪明，它也不知道你心里想什么。你给的信息越模糊，它猜得就越离谱。所以这一章，我把这几年踩过的坑、总结出来的套路，一次性讲清楚。

4.1 Prompt设计三大原则

我个人习惯把Prompt设计原则归纳为三条。这三条看着简单，但真能做到位的人不多。

原则一：指令要清晰，别让模型猜

很多新手写Prompt，喜欢用“帮我分析一下这段文本”。模型一听就懵了——分析什么？情感？主题？关键词？还是语法结构？

我建议你直接告诉它：“请从这段文本中提取出三个核心观点，每个观点用一句话概括，并标注对应的原文引用。” 你看，这样模型就知道该干什么了。

原则二：提供上下文，别让它盲猜

我记得有一次做金融研报生成，直接问“写一段关于新能源行业的分析”。模型输出了一堆泛泛而谈的内容，什么“新能源是未来趋势”之类的废话。后来我加上了上下文：“你是一位资深行业分析师，专注于新能源领域。请基于2024年Q3的数据，分析光伏产业链的供需格局。” 效果天差地别。

为什么会这样？因为模型需要知道“你是谁”、“在什么场景下”、“要解决什么问题”。上下文就是给模型搭了一个舞台，它才知道怎么表演。

原则三：指定输出格式，方便后续处理

我在项目中遇到过最头疼的事，就是模型输出格式不统一。今天给你JSON，明天给你Markdown，后天给你一段散文。你写解析代码的时候，心态直接崩了。

所以我现在写Prompt，一定会加上格式要求。比如：“请以JSON格式输出，包含title、summary、keywords三个字段。” 这样下游程序直接解析，省心省力。

4.2 Few-shot与Chain-of-Thought

这两个概念，可以说是Prompt Engineering的进阶玩法。我刚开始接触的时候也觉得玄乎，后来用多了才发现，其实就是“给例子”和“教思路”。

Few-shot：给几个例子，模型就懂了

Zero-shot就是不给例子，直接让模型干活。但有些任务太复杂，模型理解不了你的意图。这时候Few-shot就派上用场了。

举个例子，我想让模型做情感分类，但分类标准比较细——比如“愤怒”、“失望”、“讽刺”、“开心”。直接问模型，它可能把“呵呵”这种词分错。但如果你给两个例子：

输入：这个产品真是绝了，用了三天就坏了。
输出：讽刺

输入：等了两个小时还没到，太失望了。
输出：失望

模型看到这两个例子，基本就知道你要它干什么了。我一般给2-3个例子就够了，太多反而会让模型困惑。

Chain-of-Thought：让模型“说人话”地推理

Chain-of-Thought（CoT）是我个人最喜欢的技术。说白了，就是让模型把思考过程写出来，而不是直接给答案。

为什么会有效？因为很多复杂问题，模型直接跳到最后一步容易出错。但如果它一步步推理，中间步骤错了你也能看出来，甚至能纠正它。

比如我问模型：“小明有10个苹果，给了小红3个，又从小刚那里拿了5个，现在小明有几个苹果？” 直接问，模型可能算错。但如果你说：“请一步步推理，最后给出答案。” 模型就会写：

第一步：小明最初有10个苹果。
第二步：给了小红3个，剩余10 - 3 = 7个。
第三步：从小刚那里拿了5个，现在有7 + 5 = 12个。
答案：12个。

你看，每一步都清清楚楚。我在做研报Agent的时候，经常用CoT让模型先分析数据趋势，再给出结论。这样生成的报告，逻辑性明显强很多。

4.3 结构化Prompt模板

写多了Prompt，你会发现很多模式是重复的。比如“角色设定+任务描述+输出格式+示例”。与其每次都从头写，不如做成模板。我自己的模板库里，现在有十几个常用模板。

一个通用的结构化模板

下面这个模板，是我在多个项目中验证过的，基本覆盖了大部分场景：

# 角色
你是一位[角色描述]，擅长[专业领域]。

# 任务
请完成以下任务：[具体任务描述]

# 上下文
[提供背景信息、数据或参考材料]

# 输出要求
- 格式：[JSON/Markdown/纯文本等]
- 字段：[列出需要输出的字段]
- 长度：[字数或段落数限制]

# 示例（可选）
输入：[示例输入]
输出：[示例输出]

# 约束条件
- 不要[禁止做的事情]
- 必须[必须做的事情]

这个模板的好处是结构清晰，每个部分各司其职。我建议你根据自己的业务场景，调整里面的字段。比如做客服问答，可以加一个“语气要求”；做技术文档，可以加一个“术语规范”。

实战案例：研报摘要生成模板

拿我们研报Agent来说，我设计的模板长这样：

# 角色
你是一位资深金融分析师，专注于[行业名称]研究。

# 任务
请根据以下研报内容，生成一份300字以内的摘要。

# 上下文
[粘贴研报全文]

# 输出要求
- 格式：Markdown
- 结构：
  ## 核心观点（1-2句话）
  ## 关键数据（3-5个数据点，带单位）
  ## 风险提示（1-2条）

# 约束条件
- 不要添加原文中没有的信息
- 保持客观中立，不要带主观评价

你看，这个模板把角色、任务、上下文、输出格式、约束条件都写清楚了。模型拿到这个模板，基本不会跑偏。我在项目中用这个模板，摘要的准确率从60%提升到了85%以上。

4.4 知识体系总览

为了让你更直观地理解这一章的内容，我画了一张图。它把Prompt Engineering的核心要素串起来了：

这张图把这一章的核心逻辑串起来了。你从中心出发，左边是三大原则，中间是进阶技术，右边是结构化模板。三者层层递进，缺一不可。

最后说一句，Prompt Engineering不是玄学，它是有方法论可循的。你只要把原则记牢、把技术练熟、把模板建好，写出来的Prompt基本不会差。我在项目中反复验证过，这套方法能让模型的输出质量提升一个档次。