提示究竟是什么
你已经知道，大语言模型 本质上是一个下一个词元的预测器：它读入到目前为止的文本，给出对接下来内容的概率分布。提示（prompting）无非就是把这段文本安排妥当，让最可能的续写恰好就是你想要的答案。当你提示时，模型那几十亿个权重并不会改变——它们在训练结束时就已经固定了。你唯一能控制的是输入，而提示就是那个输入。
这一下子就把整件事重新框定了。你并不是在持久意义上*教会*模型任何东西——你提示里的内容，对话一结束就什么也留不下。你是在*引导*一个早已在 指令微调 与预训练中吸收了海量知识的系统，把它已有的能力对准你这个具体任务。好的提示与其说像编程，不如说像给一位读过几乎一切、却对*你的*处境一无所知、聪明又死板的同事下达精确的指示。
上下文学习：不训练也能「学」
提示之所以根本就能起作用，靠的是一个引人注目的特性，叫做 上下文学习：一个大型预训练模型能从放进提示里的示例中捕捉到新的模式，而无需更新权重、无需 反向传播、无需 梯度下降。给它看三个带标注的任务示例，它往往就能正确地续写出第四个。这并不是被明确设计出来的；它是在模型大到一定程度后才浮现出来的，是少数几个真正配得上 涌现能力 这个名号的现象之一。
不过，得诚实面对这到底是什么。上下文学习不是模型在重新接线；它是模型*识别出*一个它本就能表示的模式，并据此对接下来的词元预测加以约束。这个区别解释了它的局限：当任务是模型在训练中见过同类的东西时，示例最管用；而示例无法可靠地装上一项全新的技能、教会崭新的事实，或者推翻深层的倾向。当有人把「涌现」说得好像能力一过某个阈值就魔法般冒出来时，请谨慎对待——其中很大一部分的「陡然」，其实是我们*度量*任务的方式造成的假象，而不是网络内部突然有个开关被拨动了。
零样本、少样本，以及如何挑选示例
最简单的提示是零样本（zero-shot）：你只是描述任务然后发问。得益于指令微调，现代模型能很好地应付大量 零样本 请求。当它们开始摇摆时——格式不一致、类别含糊、风格罕见——你就该祭出少样本（few-shot）提示：在提示里直接放进几组输入—输出示例。这就是纯靠上下文完成的 少样本学习，在你考虑微调之前，它往往是最快、最便宜的解法。
Classify the sentiment as positive / negative / neutral. Review: "Battery dies in an hour." -> negative Review: "Setup took five minutes, love it." -> positive Review: "It is a phone. It makes calls." -> neutral Review: "Screen is gorgeous but it overheats." ->
示例携带的信息比你想象的多。它们悄悄地固定了输出格式、演示了边角情况、定下了语气——往往比一整段指令还要可靠。几条手艺心得：要覆盖你预期输入的*多样性*，而不是三个几乎一模一样的简单例子；让每个示例的格式逐字逐句保持一致，因为模型对表面形式模仿得特别起劲；还要留意顺序——对某些任务，最后一个示例的标签会把答案往那边带。多并不总是好：两个精当的示例通常胜过十个潦草的，而且每个示例都会花掉你一部分 上下文窗口。
系统提示：搭好舞台
大多数聊天模型会把输入按角色拆分，其中第一个就是 系统提示：一条常驻的指令，在用户开口之前，就为整段对话框定了*模型在扮演谁*以及*要遵守什么规则*。人设、语气、输出格式、范围边界、拒答规则，都该放在这里——「你是一位严谨的税务助手；引用你依据的条文；不确定就如实说；绝不杜撰数字。」因为它位于最前面，而且模型被训练成会着重对待它，所以它会塑造接下来的一切。
但要把你的预期校准好。系统提示是一种强烈的*偏好*，而不是一纸牢不可破的契约。一段冗长或带有对抗性的对话可能把它一点点磨蚀掉，而一个机灵的用户输入有时能把模型劝过它的规则。把它当作你手里最可靠的行为引导层，而不是一道安全边界——任何真正绝不能发生的事，都需要在模型*之外*加护栏，而不是只在模型里面放一句严厉的话。
写出模型能遵循的指令
清晰胜过花哨。模型接触不到你的意图，只接触得到你的字句，所以 提示工程 里最大的那根杠杆，就是消除歧义。把你想要什么、要什么格式、有什么约束、遇到尴尬情况该怎么办，都说清楚。含糊的要求（「总结一下这个」）只会产出含糊、难以预料的输出；具体的要求（「用三个要点总结这段，每条不超过十五个字，面向非技术读者」）才能产出你真正可以依赖的东西。
- 先说角色与目标，再说任务——好让模型在读到细节之前就明白自己要干什么。
- 多用正面指令（「用 JSON 回复，包含 a、b 两个键」），少用反面指令（「别啰嗦」）；说该做什么，而不只是说别做什么。
- 用清晰的分隔符（小标题、三引号、类 XML 标签）把指令和数据分开，让模型绝不会把两者搞混。
- 给它一条退路：告诉它当答案不在所给材料里时该怎么说，好让它选择拒答，而不是编造。
- 用真实、多样的输入去测试并反复打磨；一个在某个例子上表现完美的提示，往往在第二个例子上就翻车。
对于需要推理的任务，一个小小的结构改动就帮助很大：让模型在作答之前先把思路一步步走一遍——思维链提示——给它留出空间去铺陈中间步骤，这能显著改善算术、逻辑和多步问题。诚实的提醒是：那段写出来的推理是一段*被生成的叙述*，并不是内部计算的忠实记录；它可以看似有理却依然错误，所以要核对答案本身，而不只是核对那段说辞。下一篇指南我们会更深入地讲推理技巧。
局限、解码与好习惯
再好的提示也越不过模型的两道硬天花板。第一道是 上下文窗口：一切——系统提示、示例、你的数据、正在进行的对话——都必须塞进一份固定的词元预算里，落在窗口之外的，对模型来说就根本不存在。第二道是 幻觉：即便没有任何依据，模型也会产出流畅、自信的文字，因为流畅正是它被训练去优化的目标。提示能减轻这两者（写简洁些、让它注明出处、叫它说「我不知道」），却无法将其根除——而那正是本阶后面要讲的检索与接地（grounding）的用武之地。
在提示旁边还有一个旋钮：解码。像 温度 这样的设置，控制着模型采样下一个词元时有多随机。低温让输出更聚焦、更可复现——这正是分类或抽取任务想要的；高温让输出更多变——适合头脑风暴或创意初稿。它不是提示文本的一部分，但它对结果的塑造毫不逊色，而一个「飘忽不定」的提示，有时其实只是温度对这个任务来说设得太高了。
最后，把提示当作代码来对待。给它做版本管理、在一组固定的输入上测试它，并且每次只改一处，这样你才能分辨出究竟是什么起了作用。提示是一项有真实杠杆的真功夫——但它是你最先伸手去拿的工具，而不是最后那个。当一个任务确实需要崭新的事实时，去用检索；当它需要的是某种基础模型怎么也无法从示例里学会的行为时，那就是该考虑微调的信号——本阶后面的指南会诚实地把它和提示放在一起权衡。