从零到一：写给初学者的提示工程（Prompt Engineering）完全入门指南
目录
从零到一：写给初学者的提示工程（Prompt Engineering）完全入门指南
三、聊天模型里的三种角色：system / user / assistant
6.5 Frequency Penalty / Presence Penalty（频率惩罚 / 存在惩罚）
十、链式思考（Chain-of-Thought）：让模型“把中间步骤写出来”
从零到一：写给初学者的提示工程（Prompt Engineering）完全入门指南
本文学习与整理自开源学习资源 Prompt Engineering Guide（DAIR.AI）。若你希望对照原文与更多论文链接，建议直接收藏该站点并按目录循序渐进阅读。
一、你会从这篇文章里得到什么
如果你刚开始接触大语言模型（Large Language Models，简称 LLM），你很可能会遇到这些困惑：为什么同样的问题，别人问得更准；为什么模型有时“很聪明”，有时又“很离谱”；为什么换了一个词，答案就完全不同。提示工程（Prompt Engineering）正是围绕这些问题展开的一套实践方法：它帮助你更稳定、更可控、更高效地与模型协作。
根据 Prompt Engineering Guide 的定义，提示工程是一门相对较新的学科，目标是开发与优化提示（prompt），从而更高效地使用语言模型，服务于研究与应用场景。它不仅能提升常见任务（例如问答、算术推理）的表现，也能帮助开发者设计更稳健、更有效的提示策略，使 LLM 更好地与外部工具或领域知识结合。
对初学者而言，你不需要先啃完所有论文。更务实的路径是：先建立正确直觉，再掌握少量“高杠杆”的技巧，最后通过迭代把提示打磨到可用。下面我们将按这个路径展开。
二、先建立直觉：模型到底在做什么
你可以把 LLM 理解为一个极其擅长续写与模式匹配的系统：它根据你给出的上文，预测接下来最“像话”的内容。因此，“提示”并不是魔法咒语，而是你提供给模型的上下文与任务约束。
Basics of Prompting 用一个极简例子说明这一点：当你只给模型一个很短的片段（例如 “The sky is”），模型会顺着语言习惯补全（例如 “blue.”）。这看起来合理，但未必符合你的真实目标。若你改为明确要求（例如 “Complete the sentence: …”），输出往往会更贴近你的意图。
这个对比非常关键：模型默认在做“续写合理文本”，而你要它做的是“完成你的任务”。提示工程的核心，就是把任务说清楚，让“续写”的方向对齐到“交付”。
三、聊天模型里的三种角色：system / user / assistant
当你使用 ChatGPT、Claude、或各类 API 的 chat 模型时，通常会看到三种消息角色（roles）：
-
system：用于设定助手整体行为、边界与风格（不是必须，但往往很有用）。
-
user：用户的输入，也就是你最常见的提问与指令。
-
assistant：模型的回复；有时你也可以手动写入 assistant 消息，用来提供“期望行为的示范”（具体用法因平台而异）。
初学者常见误区是：把所有约束都堆在 user 里。更稳健的做法通常是：把长期稳定的规则放进 system（例如输出格式、禁止事项、语气），把当次任务的细节放进 user（例如要处理的文本、要分析的数据）。
四、提示的基本格式：从“问法”到“任务模板”
在 Basics of Prompting 中，标准提示可以非常朴素，例如：
-
问答式：
<Question>? -
指令式：
<Instruction>
也可以采用更明确的 QA 结构：
Q: <Question>? A:
这类“直接问、直接答、不给示例”的方式，通常被称为 zero-shot prompting（零样本提示）：模型不依赖你在提示里提供的示范样例，而是凭借训练阶段学到的能力与指令遵循能力来完成任务。
零样本是否够用，取决于任务复杂度、领域知识要求，以及模型本身能力。对很多日常任务（摘要、翻译、简单分类）零样本已经很强；但对更复杂、更专业、或更需要一致性格式的任务，你可能需要进入下一阶段：few-shot prompting（少样本提示）。
少样本提示的关键思想是：在提示中加入若干“输入—输出”示范，让模型通过上下文学习（in-context learning）对齐你的任务格式与判定边界。Basics of Prompting 也给了一个情感极性分类的极简示范格式（用 // 标注标签），初学者可以把它理解为：用格式教会模型“怎么答”。
五、提示的四个构件：把“说清楚”拆成可操作的模块
Elements of a Prompt 把常见提示拆成四类元素，这对初学者非常有用，因为它让你从“凭感觉写一段话”升级为“像搭积木一样组装提示”。
-
Instruction（指令）：你要模型做什么。
-
Context（上下文）：外部信息或背景，用来降低歧义、提供判断依据。
-
Input Data（输入数据）：要被处理的对象（文本、表格片段、日志等）。
-
Output Indicator（输出指示）：你希望输出以什么形态开始或呈现（标签名、JSON 字段名、分段结构等）。
该页面给出的情感分类示例（“Classify … / Text: … / Sentiment:”）就是一个典型组合：指令 + 输入 + 输出指示。你也可以把“额外示例”作为 context 的一部分，用来进一步稳定输出。
需要强调的是：不是每次都要四要素齐全。要素是否齐全取决于任务。初学者可以先用这个清单自检：我是不是缺了“输入对象”？我是不是没规定“输出形态”？我是不是上下文不足以消歧？
六、模型参数：温度、Top‑P、长度与重复惩罚
提示文字解决“说什么”，而 API/平台参数往往解决“怎么说得更像你想要的那种统计特性”。根据 LLM Settings，常见参数包括：
6.1 Temperature（温度）
温度越低，生成越“确定”，更偏向选择概率最高的下一个 token；温度越高，随机性更强，输出更可能多样、更有创造性。一般经验是：偏事实、偏严谨的问答可以把温度调低；诗歌、头脑风暴类任务可以尝试更高温度。
6.2 Top‑P（核采样）
Top‑P 与温度都属于采样控制思路：Top‑P 通过限制候选 token 的概率质量集合来调节多样性。若你追求更精确、更“自信”的答案，通常倾向更低的 Top‑P；若你希望更发散，可以提高。
该指南给出的总体建议是：Temperature 与 Top‑P 不要同时猛调，通常先改其中一个，观察稳定性与质量，再决定下一步。
6.3 Max Length（最大生成长度）
用于限制模型输出 token 数量，能避免冗长回答，也有助于控制成本。初学者在构建应用时，建议给输出长度一个合理上限，并在提示里同时说明“简洁/条目数/字数范围”，双管齐下更稳。
6.4 Stop Sequences（停止序列）
当模型生成到某个特定字符串时停止。它可以用来控制结构，例如限制列表条目数量等（具体实现依赖平台）。
6.5 Frequency Penalty / Presence Penalty（频率惩罚 / 存在惩罚）
两者都用于抑制重复，但机制不同：frequency 会对出现次数多的 token 施加更强惩罚；presence 对“是否出现过”更敏感，重复次数变化带来的额外惩罚不如 frequency 那样随次数累积得那么“狠”。
同样地，指南建议：frequency 与 presence 一般不要同时大幅混调，优先选一个方向做实验。
最后一句提醒非常重要：不同模型版本、不同厂商实现细节会有差异，因此参数需要“以实验为准”，不要死记某个魔法数值。
七、设计提示的通用原则：从简单迭代到高质量交付
General Tips for Designing Prompts 提供了一套初学者最该内化的工作方式，我把它翻译成更可执行的“流程”。
7.1 从简单开始，刻意迭代
提示设计几乎总是迭代过程。建议你先写一个最小可用版本（MVP prompt），跑通后再逐步加入：更明确的指令、更相关的上下文、更清晰的输出格式、必要的示例。
如果任务很大，把它拆成子任务：先抽取，再总结，再格式化；先分类，再生成理由；先列提纲，再扩写。这样你能定位“究竟是哪一步不稳”，而不是把全部复杂性一次性塞进一个巨型提示里。
7.2 指令要“动词驱动”，并考虑位置与分隔
像 “Write / Classify / Summarize / Translate / Order …” 这类明确动词，往往比含糊描述更有效。很多实践建议把指令放在开头，并用清晰分隔符区分指令与材料，例如用 ### Instruction ### 包裹指令区，让模型更容易解析结构。
7.3 具体，但要避免“啰嗦式含糊”
具体不等于堆叠无关细节。好的具体是：每个补充信息都能减少歧义或约束输出空间。指南里对比了两种提问方式：一种要求“短一点、别太描述”，但“短”没有量化；另一种明确要求“用 2–3 句话，向高中生解释概念”。后者更可验证、更容易得到稳定风格。
7.4 用“要做什么”替代“不要做什么”
指南用电影推荐机器人例子说明：当你强调 “DO NOT ASK …”，模型仍可能继续追问。更好的写法是明确职责与默认策略：例如从全球趋势影片中推荐、缺少信息时如何兜底、遇到边界条件如何回复。对初学者来说，这是一个重要心智转变：否定句不如可执行策略。
7.5 需要结构化输出时，给出“可照抄的模板”
例如提取地名时指定：
Desired format: Place: <comma_separated_list_of_places>
这类“输出模板”往往比口头描述格式更有效，因为它把模型的续写锚定在固定字段名上。
八、零样本提示：什么时候够用
Zero-Shot Prompting 强调：许多现代模型经过指令微调与人类反馈对齐（如 RLHF 相关路线），因此具备较强的指令遵循与零样本能力。情感分类就是一个典型：你不需要给正反例，模型也能输出 Neutral/Positive/Negative。
初学者可以建立一个判断标准：
-
任务边界清晰、输出格式简单、错误成本低：优先零样本。
-
任务需要特定口径（你们公司怎么定义“负面”）、或输出必须严格一致：尽快引入示例或规则模板。
九、少样本提示：用“示范”解决对齐问题
Few-Shot Prompting 指出：对更复杂任务，仅零样本可能不足；少样本通过在提示中加入 demonstrations 来启用上下文学习，从而提升表现。
指南里还提到一些反直觉但重要的实验结论（来自相关研究工作的总结）：示范中标签空间与输入文本分布往往很重要；格式本身也很关键；甚至在某些设置下随机标签也可能带来一定收益（当然不应理解为“标签可以乱标”，而是强调格式与分布信号的作用）。初学者更实用的读法是：先把格式对齐，再谈语义细节。
同时，Few-shot 也有局限：对需要多步推理的问题，单纯堆例子可能仍失败。指南用“奇数之和是否为偶数”的例子说明：模型可能给出看似自信但错误的推理链。此时需要更强调推理过程的提示策略，例如链式思考。
十、链式思考（Chain-of-Thought）：让模型“把中间步骤写出来”
Chain-of-Thought Prompting 的核心思想是：对复杂算术、常识与符号推理任务，让模型生成中间推理步骤，再给出结论，往往更可靠。你可以把它与 few-shot 结合：示范里不仅给答案，还给“怎么算出来的”。
另外，Zero-shot CoT 的一个著名技巧是在问题后追加类似 “Let’s think step by step.” 的句子，促使模型分步推理。对初学者来说，这几乎是最划算的升级之一：成本低、实现简单、对多步应用题类问题常常有效。
也要注意：CoT 的能力与模型规模、训练与推理模式相关；并且写出步骤不等于一定正确——步骤反而帮助你检查与自动评测。
十一、RAG：当问题不在“怎么说”，而在“凭什么知道”
RAG（Retrieval Augmented Generation） 适合知识密集型任务：让系统先检索相关文档，再把文档作为上下文与问题一起交给模型生成答案。它的动机很直观：通用模型的参数化知识是静态的，而世界信息与你的私有文档会更新；RAG 用外部知识源增强事实一致性，并缓解“胡编”（hallucination）风险。
初学者可以把 RAG 理解为三层结构：
-
检索：从向量库/搜索引擎找到相关片段。
-
组装提示：把检索结果作为 context 注入。
-
生成：模型基于证据回答，并要求引用或标注不确定性（这部分通常还要配合提示与后处理）。
当你发现“无论怎么改提示，模型都缺乏领域事实”，不要硬磨提示；该考虑数据与检索。
十二、把提示工程放进软件工程：版本化、评测与监控
要把提示从“聊天技巧”升级为“工程质量”，建议你尽早建立这些习惯：
-
提示版本管理：像管理代码一样管理 prompt 模板（变更记录、回滚）。
-
固定评测集：准备 20–200 条代表性用例，覆盖边界情况。
-
输出契约：JSON schema、字段必填、枚举值范围。
-
失败模式分类：胡编、格式错、漏项、过度拒绝、跑题等，分别对症下药。
-
线上监控：抽样复核、用户反馈闭环。
十三、安全与误用：初学者也必须知道的底线
Prompt Engineering Guide 站点也包含风险与对抗提示相关内容（例如提示注入、越狱等主题的目录）。对初学者，你至少应建立这些意识：
-
不要把密钥、令牌、隐私数据直接喂给不可信链路。
-
提示注入：攻击者可能通过用户输入诱导模型绕过系统指令。解决方案通常靠架构（权限隔离、工具白名单、人机确认）而不只靠“更聪明的提示”。
-
事实性：模型可能自信地错；关键领域需要检索、引用、校验或人工审核。
十四、推荐学习路径（面向初学者，4 周可执行）
第 1 周：熟读 Basics 与 Elements，用四个要素改写你日常最常用的 5 个提示。 第 2 周：练习 Tips 的“具体化 + 模板化输出”，并理解 Settings 的参数影响。 第 3 周：系统对比 Zero-shot 与 Few-shot，为你的任务找到最小示例数。 第 4 周：把 CoT 用于需要推理的任务；若涉及知识库，阅读 RAG 并做一个最小原型。
十五、结语：提示工程不是“咒语学”，而是协作接口设计
提示工程的价值，不在于寻找某个神奇关键词，而在于你对任务的理解是否足够清晰，是否能把约束编码成模型可执行的上下文结构。对初学者而言，最有效的提升通常来自三件事：更明确的指令、更相关的上下文、更可验证的输出格式；在此之上，再使用少样本、链式思考、检索增强等方法逐级加码。
如果你希望持续深入，建议将 Prompt Engineering Guide 作为长期手册：它的目录覆盖了从零基础到智能体、工具调用、上下文工程等更前沿主题，你可以按站点结构逐步扩展。
参考资料
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
11
0- 0
已为社区贡献2条内容
所有评论(0)