Prompt 不是咒语，是沟通—我的提示词工程第一课

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

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

在 ModelScope Notebook 环境中，调用大模型只需要几行代码。DeepSeek 的接口与 OpenAI 完全兼容，引入openai模块即可使用：(ModelScope Notebook使用教程请观看主页上一篇文章)

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

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

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

二、封装基础调用函数

2.1 函数设计

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

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

2.2 参数解析

messages的结构

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

单轮调用只需要传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 为什么这样做有效？

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

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

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

常用的分隔符方案：

四、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 之后：

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

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

4.3 常用格式约束方式

五、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 的使用场景

七、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角色设定模型人格，构建一个有记忆的对话应用。