提示词工程入门：从 API 封装到 Prompt 设计的五种核心技巧

一、背景：LLM 接口并不复杂，复杂的是怎么问

在 ModelScope Notebook 环境中，调用大模型只需要几行代码。DeepSeek 的接口与 OpenAI 完全兼容，引入 openai 模块即可使用：

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://api.deepseek.com/v1"
)

接口层面的事情很简单。真正需要花时间琢磨的，是怎么设计 Prompt——同一个任务，Prompt 写得好和写得随意，输出质量相差悬殊。

今天的学习就是围绕这个问题展开的：从封装一个基础调用函数出发，做了五组实验，逐步摸清了 Prompt 设计的几条核心规律。

二、封装基础调用函数

2.1 函数设计

def get_completion(prompt, model='deepseek-chat'):
    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "user", "content": prompt}
        ],
        temperature=0.5,
        max_tokens=1024,
    )
    return response.choices[0].message.content

这个函数是后续所有实验的基础，有几个细节值得展开说。

2.2 参数解析

messages 的结构

LLM 的 chat 接口本质上是多轮对话，messages 是一个列表，每条消息包含 role 和 content 两个字段：

role含义
user用户的输入，即我们发出的 prompt
assistant模型的回复，多轮对话时需要手动拼入历史
system全局系统指令，用于设定模型的角色和行为规则

单轮调用只需要传 user 角色即可。多轮对话则需要把历史的 user 和 assistant 消息都追加进列表，模型没有记忆，上下文全靠调用方自己维护。

temperature 控制随机性

0          0.5          1          2
|----------|------------|----------|
严谨确定   均衡适中     略有创意   随机发散
  • 写代码、做分析、提取信息 → 用低 temperature（0~0.3）
  • 写文案、写诗、头脑风暴 → 可以适当放高（0.7~1.2）

max_tokens 控制输出长度

max_tokens 限制的是输入 + 输出的总 token 数量，不是单独的输出长度。设置过小会导致回复被截断，实际使用时需要根据任务复杂度调整。

2.3 第一次调用

print(get_completion("写一首夏天游玩的七言诗"))

模型返回了一首工整的七言诗。这只是热身——真正有意思的在后面。

三、Prompt 技巧一：用分隔符隔离数据与指令

3.1 问题背景

当 Prompt 里既有指令又有待处理的文本时，如果两者混在一起，模型有时会"搞混"——把数据当成指令的一部分，或者把指令当成需要处理的内容。

3.2 实验

text = f"""
你应当通过尽可能清晰、具体的指令，来明确你希望模型完成的任务。
这能引导模型产出符合预期的结果，同时降低回复内容偏离主题或出现错误的概率。
不要把编写清晰的提示词和精简提示词混为一谈。
很多时候，篇幅更长的提示词能为模型提供更完整的说明与背景信息，进而让输出内容更加详实、贴合需求。
"""

prompt = f"""
将三个反引号之间的文本总结为一句话
```{text}```
"""

print(get_completion(prompt))

用三个反引号（```）把待处理的文本包裹起来，指令放在外面，数据和指令物理隔离。

3.3 为什么这样做有效？

分隔符的作用不仅是"格式好看"，而是给模型提供了明确的结构信号：

[指令区域] 将三个反引号之间的文本总结为一句话
[数据区域] ```...待处理文本...```

模型可以明确区分"什么是我要做的事"和"什么是我要处理的材料"，不会把数据内容误读为新的指令。

常用的分隔符方案：

分隔符适用场景
```代码块、多行文本
"""长段落文字
<tag></tag>XML 风格，结构更清晰
---简单分隔

四、Prompt 技巧二：约束输出格式

4.1 实验

让模型列出四大名著的信息，并要求以 JSON 格式返回，字段名称提前指定：

prompt = f"""
请列出四大名著，并标注对应的作者与书籍类型。
使用JSON格式呈现，需包含以下字段：
book_id（书籍编号）、title（书名）、author（作者）、desc（简介）、genre（书籍类型）
"""

response = get_completion(prompt)
print(response)

模型返回了结构整齐的四条 JSON 数据，字段完整，格式规范。

4.2 格式约束的意义

"我要什么信息"和"我要什么格式"是两件不同的事，都需要明确说出来。

不约束格式时，模型可能以任意形式回答：自然语言段落、Markdown 表格、Python 字典……格式不固定，后续程序处理就很麻烦。

约束为 JSON 之后：

import json
data = json.loads(response)
# 直接可用，不需要任何额外解析

这是 Prompt 工程中非常实用的一条原则：输出格式是给程序看的，不只是给人看的。 在 AI 应用开发中，模型的输出往往是数据流水线的一个环节，格式稳定是下游处理的前提。

4.3 常用格式约束方式

场景建议格式
结构化数据，需程序处理JSON（指定字段名）
列表类输出Markdown 列表 或 JSON 数组
文本摘要、翻译纯文本，无需格式
多任务并行输出XML 标签分区，如 <summary>...</summary>

五、Prompt 技巧三：条件判断——让模型识别输入类型

5.1 实验设计

用同一个 Prompt 模板处理两段性质不同的文字：

  • 文本一：泡茶的操作步骤（有明确的动作序列）
  • 文本二：晴天公园的景色描写（纯描述性文字，无操作指引）

Prompt 的逻辑是：有步骤就格式化输出，没有步骤就直接声明。

# 文本一：泡茶步骤
text = f"""
泡一杯茶其实很简单！首先把水烧开。烧水的同时，拿出茶杯，放入茶包。
水烧开后，将热水冲入杯中浸泡茶包。静置片刻让茶香析出。
几分钟后，根据个人口味，还可以加入糖或牛奶。这样一杯美味的茶饮就泡好了。
"""

prompt = f"""
你将收到由三引号包裹的文本。若文本中包含一系列操作指令，
请按照下述格式重新整理这些指令。
步骤 一 ...
步骤 二 ...
...
步骤 N ...
如果文本中没有一系列操作指引，直接输出**"没有提供步骤。"**
\"\"\"{text}\"\"\"
"""

print(get_completion(prompt))

# 文本二：公园景色描写
text_2 = f"""
今日阳光明媚，鸟儿欢唱。这样的好天气很适合去公园散步。
花儿竞相绽放，树木在微风中轻轻摇曳。
人们纷纷出门，享受这宜人的天气……
"""

结果：文本一被正确拆分为步骤列表；文本二返回"未提供步骤"，判断准确。

5.2 分析：Prompt 可以携带逻辑

这个实验打破了一个认知误区：很多人以为 Prompt 只是"提问"，其实它可以携带完整的判断逻辑。

IF 文本包含操作步骤
    THEN 格式化输出步骤列表
ELSE
    THEN 输出固定文本

这段逻辑用自然语言写进 Prompt，模型完全能理解并执行。这意味着 Prompt 本身就是一种轻量级的业务规则描述语言，在不写代码的情况下，可以处理一定复杂度的分类和判断任务。

六、Prompt 技巧四：Few-Shot 少样本提示

6.1 实验

直接问"何为韧性"，会得到一段平铺直叙的解释。但先给一个示例，效果截然不同：

prompt = f"""
你的任务是保持统一的行文风格作答。

提问：请讲讲何为耐心。
回答：能凿出幽深峡谷的江河，源自涓涓细流；
      恢弘壮阔的交响乐，起于单个音符；
      精美繁复的织锦，始于一缕丝绒。

请问：请讲讲何为韧性。
"""

print(get_completion(prompt))

模型的回答延续了示例的风格——依然是三句比喻并列，依然是"A 起于 B"的句式结构，甚至意象的层次感也保持一致。

6.2 为什么 Few-Shot 比描述风格更有效？

这是今天最有收获的实验。

描述风格的方式：

"请用诗意的、比喻性的语言回答，采用三句并列结构，每句从小到大递进……"

描述越详细越难写准，而且模型对"诗意"这类抽象词的理解因人而异。

Few-Shot 的方式：

直接给一个符合要求的例子。

模型会自动从示例中提取风格特征——句式、节奏、意象选取方式、逻辑结构，并迁移到新的问题上。样本传递的信息密度，远高于文字描述。

6.3 Few-Shot 的使用场景

场景是否适合 Few-Shot
特定写作风格复现✅ 非常适合
格式模板固定的输出✅ 适合
分类任务（如情感判断）✅ 提供正负样本效果好
事实性问答⚠️ 意义不大，不如直接问
需要泛化到未见类别⚠️ Zero-Shot 可能更合适

七、Prompt 技巧五：多步任务链——引导模型分步推理

7.1 实验

把四个子任务打包进一个 Prompt，要求模型按顺序逐步完成：

text = f"""
在一座风光宜人的小村庄里，姐弟俩杰克和吉尔动身前往山顶的水井取水。
两人一路欢歌向上攀登，不料意外突生——杰克被石头绊倒，滚下山坡，
吉尔也跟着摔了下去。二人虽受了些轻伤，还是回到了家中，得到家人温柔的安抚。
"""

prompt = f"""
执行以下操作：
1. 将三个反引号内的文本概括为一句话。
2. 把这句摘要翻译成法语。
3. 列出法语摘要中出现的所有人名。
4. 输出JSON对象，包含字段：french_summary、num_names。
答案分行展示。

文本：
```{text}```
"""

print(get_completion(prompt))

模型依次完成了摘要 → 翻译 → 提取人名 → 封装 JSON，每一步的输出自然衔接为下一步的输入，最终结果格式干净。

7.2 分析：为什么要引导分步推理？

直接问"给我这段文字的法语摘要里有几个人名，用 JSON 返回"，模型有时会跳步——摘要不够准确，或者人名提取出现遗漏。

让模型显式地一步步走，相当于强制它把中间推理过程"写出来"，每一步的结果都被检验过再进入下一步，减少了跳步导致的错误积累。

直接问答模式：输入 ──→ 输出（中间推理隐含，容易出错）

分步推理模式：输入 → 步骤1输出 → 步骤2输出 → ... → 最终输出
                         ↑每步可验证

这个思路在更复杂的 AI 应用中（比如 Chain-of-Thought 提示、ReAct 框架）是核心原则之一，今天的实验是它最简单的形态。

八、幻觉：LLM 的边界问题

8.1 实验

prompt = f"""
介绍一下博依品牌的喜多多饮料
"""
print(get_completion(prompt))

"博依"是一个不存在的品牌（或极其小众），但模型没有回答"我不了解这个品牌"，而是给出了一段有模有样的介绍：产品特点、目标人群、市场定位……读起来像真的，但全是编的。

8.2 幻觉的本质

LLM 的工作原理是基于概率预测下一个 token，它不是在检索数据库，也没有"不知道"这个选项——当它遇到没见过的信息时，会用"听起来最合理"的内容填充。

人类遇到不知道的问题：
"我不了解这个品牌，没有相关信息。"

LLM 遇到不知道的问题：
生成一段在统计上"像真实品牌介绍"的文本。

这不是模型的 bug，是它的工作机制本身决定的。模型的强项是语言理解和生成，不是事实存储和检索。

8.3 应对策略

场景建议
创意写作、风格转换、格式处理可以充分信任模型输出
知识性问答、品牌/人物/数据必须用外部资料验证
代码生成需要运行测试，不能只看"看起来对"
需要引用文献或数据来源模型会编造，务必核查原始来源

在实际应用开发中，通常的解法是RAG（检索增强生成）：先从可信数据源检索相关文档，再把文档内容作为上下文传给模型，让它基于真实资料回答，而不是凭空生成。

九、总结

今天围绕 Prompt 工程做了五组实验，把学到的规律整理如下：

Prompt 工程的五条核心原则
├── 用分隔符隔离数据与指令  → 防止模型混淆输入结构
├── 约束输出格式            → 让结果可被程序直接消费
├── 写入条件判断逻辑        → Prompt 本身是业务规则
├── Few-Shot 给示例         → 样本比描述风格更精准
└── 分步骤引导推理          → 减少跳步错误，提升稳定性

加上幻觉问题的认识：模型不会说"我不知道"，使用者要知道什么时候该信它。

Prompt 不是魔法咒语，背后是明确的逻辑——你给的上下文越清晰，约束越具体，模型的输出就越稳定、越可用。

下一步计划：学习多轮对话的上下文管理，尝试用 system 角色设定模型人格，构建一个有记忆的对话应用。