3、提示词核心概念：System Prompt、User Prompt、Few-shot、Zero-shot、温度、Top-p等参数的作用

在提示词工程中，理解底层参数与提示词结构是区分“偶然得到好结果”与“稳定产出高质量结果”的关键分水岭。本章将深入剖析大语言模型（LLM）推理时的核心控制杠杆：System Prompt与User Prompt的角色分工、Few-shot与Zero-shot的样本策略，以及温度（Temperature）与Top-p等采样参数对输出质量的影响。我们将从原理、操作到实战调优，建立一套系统化的提示词设计框架。

3.1 System Prompt与User Prompt：职责分离与协作机制

核心原理

System Prompt（系统提示词）是定义模型全局行为模式的“元指令”，它设定角色、语气、输出格式、知识边界和道德约束。User Prompt（用户提示词）则是每次请求中携带的具体任务、数据或问题。二者的本质区别在于作用域：System Prompt在对话开始时一次性注入，影响整个会话的基调；User Prompt则随每次交互动态变化。现代LLM（如、Claude 3）对System Prompt的遵循优先级通常高于User Prompt，但若两者冲突，模型可能产生不可预测的行为。

判断方法与操作流程

设计System Prompt时，应遵循“角色-规则-格式-边界”四步法：
① 明确角色（如“你是一名资深数据分析师”）；
② 列出硬性规则（如“只使用中文回答”）；
③ 规定输出格式（如“使用Markdown表格”）；
④ 声明边界（如“不讨论政治敏感话题”）。User Prompt则需包含“任务动词+对象+约束条件”三要素，例如：“请将以下客户评论分类为正面/负面/中性，并给出置信度分数：{评论内容}”。

System Prompt: 你是一名客服工单分类专家。工单类型仅限：退款、物流、产品质量、账号问题、其他。输出JSON格式：{"type": "...", "confidence": 0.0-1.0}。若信息不足，type为"其他"。

常见误区

误区一：将System Prompt写得过于冗长，导致模型注意力分散。建议控制在200字以内，突出核心约束。误区二：User Prompt中重复System Prompt已设定的规则，浪费且可能造成冲突。误区三：忽略System Prompt的“负面指令”设计，例如明确说“不要输出解释，直接给结果”比“请简洁回答”更有效。

3.2 Few-shot与Zero-shot：示例引导的威力与局限

核心原理

Zero-shot指不提供任何示例，直接让模型完成任务，依赖模型预训练阶段积累的知识。Few-shot则在User Prompt中插入2~5个输入-输出对作为示范，让模型通过上下文学习（In-Context Learning）模仿示例的模式。Few-shot的核心价值在于：它不需要更新模型参数，仅通过调整输入即可实现“任务定制化”，尤其适合格式严格、逻辑固定的任务（如实体抽取、SQL生成、情感分类）。

判断方法与操作流程

选择Few-shot还是Zero-shot，可依据以下判断路径：
① 任务是否依赖特定领域知识？若是，优先Few-shot；
② 输出格式是否严格（如JSON、表格）？若是，Few-shot可提供格式模板；
③ 模型是否已在该任务上表现良好？若Zero-shot效果已达标，无需增加示例；
④ 示例质量是否可靠？低质量示例会误导模型，不如不用。

案例拆解：法律文书摘要生成

某法律科技公司需要将判决书自动摘要为“案件焦点-法院认定-判决结果”三段式。Zero-shot提示词：“请摘要这份判决书。”输出结构混乱，经常遗漏关键信息。改进后的Few-shot提示词：

请将判决书摘要为三段式：
输入：原告主张被告违约，要求赔偿50万元。法院查明合同真实有效，被告未按期履行。
输出：案件焦点：合同履行争议；法院认定：合同有效，被告违约；判决结果：赔偿50万元。
输入：{待处理判决书}

采用Few-shot后，结构符合率从41%提升至93%。但代价是每次请求增加约200 的示例开销，且示例需人工精心编写。复盘发现：示例中的法律术语必须与目标文档风格一致，否则模型会模仿示例的措辞而非结构。

常见误区

误区一：认为Few-shot一定优于Zero-shot。对于通用任务（如翻译、简单问答），Zero-shot更简洁高效。误区二：示例数量越多越好。超过5个示例后，模型可能过拟合示例中的噪声。误区三：忽略示例的顺序效应。研究表明，模型对最后出现的示例记忆更强，因此应将最典型的示例放在末尾。

3.3 温度（Temperature）与Top-p：采样参数的精细调控

核心原理

Temperature和Top-p共同控制LLM生成文本时的随机性。Temperature通过缩放Softmax层的logits来调整概率分布的尖锐程度：温度趋近0时，模型几乎总是选择最高概率的，输出确定性强；温度升高（如1.5），概率分布趋于平坦，低概率也有机会被选中，输出更多样。Top-p（核采样）则从累积概率达到p值的候选词集合中采样，例如Top-p=0.9意味着只从概率总和为90%的最小集合中选取，丢弃尾部低概率词。

判断方法与操作流程

参数调优应遵循“先定任务类型，再调参数”的原则：
① 事实性任务（代码、数学、数据提取）：Temperature=0~0.3，Top-p=0.1~0.3；
② 平衡型任务（邮件撰写、摘要）：Temperature=0.3~0.7，Top-p=0.5~0.8；
③ 创意型任务（故事、营销文案）：Temperature=0.7~1.2，Top-p=0.8~0.95。
注意：Temperature和Top-p并非完全独立，同时调高两者会叠加随机性，可能导致输出失控。

案例拆解：电商产品描述生成调优

某电商平台使用LLM自动生成商品描述。初始参数Temperature=1.0，Top-p=0.95，输出虽然丰富但经常出现夸张表述（如“史上最佳”），违反广告法。调优过程：
① 将Temperature降至0.4，Top-p设为0.7，输出变得保守但缺乏吸引力；
② 改为Temperature=0.6，Top-p=0.85，并增加System Prompt约束“禁止使用化用语”，最终在合规性与吸引力间取得平衡。
关键指标对比：合规率从78%提升至99%，点击率仅下降2%。复盘发现：参数调整需与提示词配合，单独调参无法解决所有问题。

常见误区

误区一：将Temperature视为“创造力开关”，认为越高越好。实际上，高温度在长文本生成中容易导致主题漂移。误区二：忽略Top-p与Temperature的交互效应。建议先固定一个参数，调整另一个，避免同时大幅变动。误区三：在需要确定性输出的场景（如API调用返回JSON）使用非零温度，导致输出格式不稳定。此时应设置Temperature=0，并配合严格的System Prompt格式约束。

3.4 综合调优策略与工程实践

核心原理

在实际项目中，提示词结构（System/User/Few-shot）与采样参数（Temperature/Top-p）需要协同优化。一个完整的调优流程应包含：基线评估→单变量调整→组合验证→回归测试。建议建立“提示词版本管理”，每次修改记录参数配置和效果指标，便于回溯。

操作流程清单

1. 定义评估指标（准确率、格式符合率、用户满意度等）；
2. 使用Zero-shot + Temperature=0.3作为基线；
3. 逐步增加Few-shot示例，观察效果变化；
4. 固定提示词结构，扫描Temperature（0.1/0.3/0.5/0.7）；
5. 固定最优Temperature，扫描Top-p（0.1/0.5/0.9）；
6. 在验证集上测试组合参数，选择最优配置。

总结复盘

提示词工程的核心在于“结构化控制”与“概率控制”的平衡。System Prompt和Few-shot提供确定性约束，Temperature和Top-p管理生成多样性。优秀工程师应建立“先结构后参数”的调优习惯：先用提示词锁定输出框架，再用采样参数微调风格。同时，务必记录每次实验的完整配置，因为LLM的非确定性意味着同一参数在不同运行中可能产生微小差异，需要多次采样取稳定结果。