首页  思维导图  详情



 



提示词工程

2026-08-24 23:26:58   0  举报





AI智能生成

提示词工程四大核心（API调用、参数调优、Pydantic结构化输出、万能模板与Bad Case迭代方法论）

大模型RAG

提示词工程

提示词

提示词方法论

模板推荐

作者其他创作

大纲/内容

会调 API

国内平台APi 平台

阿里云百炼

硅基流动

百度千帆

火山方舟

腾讯云

OpenAI 兼容格式接口

api_key（去各平台申请）

base_url（各平台文档里给）

model_name

火山方舟的 model name 比较特殊， 是 ep-xxx 形式的接入点 ID

工程中调用的注意事项

是否要流式输出

stream=True

思考过程放在 reasoning_content 字段， 正式回复在 content 字段

stream=False

很多时候不需要流式输出，只要最终结果

首字延时

首 token 延迟

每秒生成 token 数

用来判断从哪个平台/渠道调 API 更合适

调用模板

from openai import OpenAI client = OpenAI(api_key="你的key", base_url="平台地址")   # ① 定义客户端 completion = client.chat.completions.create(     model="qwen-plus",                                      # ③ 生成参数区     messages=[                                                    # ② 消息上下文         {"role": "system", "content": "You are a helpful assistant."},  # 系统提示词：工程师内置         {"role": "user", "content": "你是谁？"},                        # 用户输入：函数的入参     ], ) print(completion.choices[0].message.content)

关键参数

核心参数总览

max_tokens

生成的最大 token 个数

太长用户要等，按场景设

temperature

温度，控制随机性

高=随机/有创造力；低=可控

top_k

只在概率前 K 的词里选

越小越确定

top_p

核采样，累计概率不超 p

越小越确定

repetition_penalty

重复惩罚

防"复读机"

seed

随机种子

固定后同输入必得同输出（测试复现用）

token 是什么

大模型处理文字的最小单位，一个 token 大约是 0.5~1 个汉字

模型生成文本就是"一个 token 一个 token 往外蹦"

Temperature 的原理

公式

z i：模型对第 i 个 token 打的原始分数（叫 logits，未归一化）；

T：temperature；

分子分母里的zi都要除以 T——这就是温度起作用的机关

T < 1（低温）：zi/T 整体被放大 → 经过 exp 之后，原来概率高的 token 更高、概率低的更低 → 分布变"尖" → 输出更确定、可控性强。

T > 1（高温）：zi/T 整体被缩小 → 高概率和低概率 token 的差距被拉平 → 采样时随机性变大 → 输出更多样、更有创造力。

两个极端

T → 0：永远只选概率最高的那个 token（= 贪心解码 argmax）

T → ∞：所有 zi/T 都趋近 0 → 所有 token 概率一样 → 完全随机

top_k 和 top_p 的区别

模型词表很大（如 Llama 系列 12.8 万个 token）。每生成一个词，模型输出的其实是一个 1×128000 的概率向量，表示每个词被选中的可能性

top_k

把概率从高到低排序，只取前 K 个，在这 K 个里随机采样

top_k=5 → 只在可能性最大的 5 个词里挑

top_p

概率从高到低累加，累加到刚好不超过 p 就停，在这些词里随机采样

例：前 4 个词概率分别是 30%、25%、15%、10%，累计 80% → top_p=0.8 时就在这 4 个词里采样

repetition_penalty 和 seed

repetition_penalty

训练/使用大模型时有时它像"复读机"一样重复生成同样的内容

调大这个值惩罚重复

seed

设置随机种子后，相同输入每次得到相同输出——调试和测试时很重要

出现不同的 case 之后应该怎么调参

随机性太强 → 把温度降低、把 top_k 降低、把 top_p 降低，控制性就都变强了

结构化输出

为什么需要

在工作流中，大模型的中间输出要传给下一个环节（比如 Manus 拆解用户输入 → 以 JSON/XML 格式传给下一步）。格式乱了下游就没法用。所以要强制模型按 JSON 格式输出

结构化输出不是给用户看的，是为了满足工作流里"中间结果可传递"的要求

方法

Pydantic BaseModel + JSON Schema

输出：name="深圳游", date="2025年1月1日", participants=["小明","小丽","我"]

精细化控制每个 key 的手段

Field(description="...")

对每个 key 写详细说明，模型会按说明理解该填什么（比如不写 description，name 可能被理解成活动名"去深圳"；写清楚"谁出去玩"就会生成人名）

List[str]

该字段是列表

Optional[str]

可以为 None（没有该信息时不报错）；普通 str 则必须有值，否则报错。

Union[...]

允许多种类型

支持嵌套模型（如 UserProfile 里嵌套 Address）

典型应用场景：提取用户资料（姓名、邮箱、住址、兴趣）→ 拿到 email 字段去调发邮件的 Agent → 基于住址制定旅游攻略……中间层参数传递全靠 JSON 结构化

Pydantic 的 BaseModel 也是 FastAPI 里控制输出格式的标准工具——学它一举两得。

response_format={"type": "json_object"}（国内模型常用）

用了 json_object，提示词里必须写一句"用 JSON 格式输出"并给出示例（EXAMPLE JSON OUTPUT），否则可能报错

这种方式有概率失败：以 DeepSeek-V3 为例，成功率约 96%~97%

工程中怎么保证 100%？ 做后处理：对输出做策略性解析/校验/重试，保证每次都是合法 JSON

工程上的写法：包装成函数

实际工作里不会一行行散写，而是包装成函数/类对外提供接口

万能却又不万能的提示词模板

为什么要写提示词？

产品场景下不能让用户多轮交互

用户传一份简历上来，就要立刻得到改好的结果

提示词要兼容此场景下几乎所有用户

改简历的提示词要适应算法、工程、供应链、产品经理等所有方向

提示词工程的意义

满足工作流里对输出的要求、满足产品定义场景里用户的使用要求

提示词是为了在产品场景里，一次性解决该场景下几乎所有用户的问题

大模型应用真正的价值

集成行业 know-how，通过 3 个途径注入大模型应用

模型本身的参数（预训练/微调注入的知识）

提示词（把"怎么写好简历"这类经验写成 prompt）

RAG 系统（把行业文档做成知识库）

提示词的 4 个核心组件

指令（Instruction）

系统 prompt 怎么定

上下文（Context）

三种提示词增强技术（也叫 In-context Learning，上下文学习）

少样本学习 Few-shot

给几个输入-输出示例，让模型照着学

情感分类：国外用户骂完产品最后说"真的非常感谢"，容易被误判正面 → 加几个示例纠正

Few-shot 不是万能

有些场景加了示例反而只在几个场景表现好、泛化差，需要靠思维链等其他控制方式

思维链 Chain-of-Thought (CoT)

告诉模型第一步、第二步、第三步怎么想

解几何题：先定义圆和直线方程 → 判断关系 → 列方程 → 求解

自洽性 Self-consistency

让模型用多种思路解同一题，多个答案互相印证取一致

批改作业防幻觉：先让模型自己解一遍，再和学生答案对比

输入数据（Input）

：用户给的材料

输出格式（Output）

JSON/XML

"万能模板"的结构（非推理模型适用）

角色：你是数据分析师 / 工程师 / 十年销售…… 背景：场景上下文（如"你是一个有 10 年背景的销售，基于用户情况输出销售话术"）； 目标：这个场景要达成什么（如"更好地把产品卖出去"）； 约束：不能做什么（如"不能输出夸大内容"）； 工作流：操作流程（如 AI 电话客服：先打招呼 → 再问有没有信用卡需求 → 用户说了 X 你就回 Y）； 外部文档：就是 RAG 检索回来的背景知识——🗣️"说白了就是小抄，拿到提示词里，相当于开卷考试，生成更精准"； 输出规则：JSON / XML 等格式定义。

提示词调优方法论（为什么"不万能"）

没有一个模板能解决所有场景

一个工业项目里 100 多个提示词，从 ChatGPT 系模型换成 DeepSeek-V3 后全部要重写（不同模型的温度设置、结构化输出能力都不同）

不存在一个能通吃所有场景、所有模型的万能模板。基本模板是"常规思路 + 调提示词的真正方法论"

核心方法论：基于 Bad Case 持续迭代

提示词不是一成不变的万能方案，而是需要不停优化迭代的过程。

建一个 200~500 条的测试集（测试集不给调参的工程师看，防止"过拟合"）

每改一版提示词就全量跑测试集，看准确率/召回率提升了多少

分析 bad case：能在提示词层面解决就改提示词；提示词写了很多还解决不了 → 考虑微调模型

收集分类 bad case → 深入分析每个错误的原因 → 提炼根因 → 迭代测试调整

提示词是需要不停优化迭代的过程，直到在定义场景下输出稳定

推理模型的提示词写法完全不同

对 DeepSeek-R1、OpenAI o1、Claude thinking 这类推理模型

不要用 few-shot、不要定义 JSON Schema 输出格式（官方明确不支持/会影响效果）

DeepSeek 论文写得很清楚：不支持格式化输出、函数调用，加 few-shot 会起反作用）

只需明确两件事：① 要模型完成的任务/目标 ② 需要处理的原始数据/问题/文本。

DeepSeek-R1 的问题

思考过程完全可见且效果好，但温度偏高、创造性太强

严谨场景不能直接用。

工业界流行方案：R1 思考 + V3 格式化

第一步：用 DeepSeek-R1 深度思考，理解用户需求

第二步：用 DeepSeek-V3 / Qwen-Plus 这类非推理模型

对"思考过程 + 原始输入"做格式化提取和输出

兼得：深度理解 + 可控的格式化输出

《提示词工程》PDF 的要点

提示词分两类

系统提示词

角色、个性、语气，工程师内置

用户提示词

用户的具体问题

提示词工程流程

准备测试集 → 写初版提示词 → 测试 → 持续调优 → 发布

两大编写原则

① 指令清晰明确

结构化输出

提供样例

检查条件是否满足

② 给大模型思考的时间

思维链

逐步思考

编写细节

不用"尽量、应该、最好"等模糊词；强调规则用"必须、一定"

一个任务不要超过 3 个步骤；不同模块用 ###、*** 分隔

Bad Case 处理流程

收集分类 → 分析错误原因 → 提炼根因 → 迭代测试调整

常见问题

提示词怎么调优？没有万能模板。流程：建 200-500 条盲测测试集 → 每版 prompt 全量跑测 → 分析 bad case → 能 prompt 解决就改 prompt，不行就微调。增强技术：few-shot、思维链 CoT、自洽性。推理模型（R1/o1）不给 few-shot 和格式约束，只给"目标+数据"；工业上用"R1 思考 + V3 格式化输出"组合。

temperature / top_k / top_p 的区别和原理？ temperature 作用于 softmax：P=exp(z/T)/Σexp(z/T)，T 小分布更尖（确定），T 大分布拉平（随机）；top_k 取概率最高的前 K 个采样；top_p 按概率累加到阈值 p 的候选集采样。输出太飘 → 降 temperature/top_k/top_p。

提示词工程 4 部分：调 API / 参数 / 结构化输出 / 模板与迭代方法论。 temperature 公式与两个极端；top_k = 前 K 个采样，top_p = 累计概率阈值采样。结构化输出两方式：Pydantic JSON Schema / json_object（96-97% → 后处理兜底 100%）。提示词方法论：没有万能模板；200-500 条盲测集 + bad case 迭代；推理模型只给"目标+数据"；工业方案 = R1 思考 + V3 格式化输出。