那些依然重要的提示工程基本功

提示工程有个名声问题。网上一半的建议是民间传说——那些只在某一个模型上灵验过一次、却被推而广之奉为铁律的魔法咒语和仪式。另一半则确实有用、且枯燥。本指南讲的是枯燥的那一半：那些跨越模型与版本持续奏效的基本功，因为它们反映了这些系统实际上是如何使用你给它的文本的。

为什么基本功胜过花招

一个语言模型生成回应时，所依凭的是它上下文中的一切——你的指令、范例和输入。"提示"不过是安排那段上下文的手艺，好让最可能的续写恰好是你想要的答案。绑定于某个模型怪癖的花招，会在模型变化时失效。而基本功——把话说清楚、给出范例、为任务搭建结构——之所以持续奏效，是因为它们让所期望的输出对于任何有能力的模型都更有可能出现。为基本功而优化，你就很少需要那些花招。

1. 对任务和输出都要具体

最常见的失败是界定不足。"总结一下这个"把十几个决定留给了模型：多长、给谁看、用什么语气、聚焦于什么。每一个未被指定的决定都是一次抛硬币。说出你真正想要的："为一位非技术背景的经理用三个要点总结这个，聚焦于成本和风险。"具体不等于啰嗦——它是在消除那些抛硬币。

输出格式也是同理。如果你需要某种特定结构——一个列表、一张表格、JSON、一组特定的字段——就明确地说出来，并展示它的样子。模型猜不出你心里想的格式，正如它猜不出你想的内容一样。

2. 演示，而不只是讲述

范例是提示中杠杆率最高的工具。一两个"输入与期望输出"的完整范例，比一整段指令传达的信息更多，因为它们演示了模式，而不是描述它。这常被称为少样本（few-shot）提示，它奏效的原因很简单：一个清晰的范例，让目标模式成为显而易见的续写。

两点实务提示。让你的范例能代表真实的输入，把棘手的情形也包括进来——只覆盖容易路径的范例，教会的就是容易路径。并且让范例之间彼此一致；相互矛盾的范例带来的困惑多过帮助。

3. 给模型留出思考的空间

对任何涉及推理的事情——多步问题、分析、决策——立刻索要答案，往往会得到一个比让模型先把它想通更差的答案。让模型在敲定最终答案之前一步步推理，恰恰能在那些质量难以保证的任务上提升质量。其机制很直观：一个在第一个词里就敲定答案的模型无法修改；一个先推理的模型则可以。

实务版本是：对难任务，索要推理过程、然后是结论，而不是只要结论。对易任务，跳过它——推理步骤会耗费 token 和延迟，而一次简单的查找并不需要它们。

4. 把指令放在它该落脚的地方

结构很重要。把你的指令与输入清晰地分开——用标题、分隔符或带标签的区块——好让模型分得清什么是命令、什么是待处理的数据。当一段提示把指令和内容混成一堵文字墙时，模型就得去猜哪个是哪个，而它有时会猜错。一点点结构就能消除这种含混。

系统级指令（角色、规则、约束）一般应放在前面、并用大白话明说。待处理的输入则应被清楚地标记为输入。这种分隔还能防范一类失败：输入中的内容被意外读成了指令。

5. 约束住失败模式

模型即便不该作答时也会作答。如果你的任务有一个"无答案"的情形——信息不存在、请求超出范围——就明确地说出来："如果文本中不包含答案，请回复说未提及。"没有这条指令，模型就会用一个貌似合理的猜测来填补空白。把你想要的失败模式说出来，就能把一次自信的捏造，变成一句诚实的"未找到"。

6. 对照真实范例迭代

民间传说和工程之间最大的区别在于度量。不要凭一次惊艳的输出来评判一段提示。收集一小把真实、多样的输入，把你的提示在它们全部上跑一遍，然后阅读结果。每次只改一个地方。保留在那个集合上表现更好的版本，而不是产生了单个最佳演示的那个。这不光鲜，却是全部的关键所在——一段在二十个真实案例上胜出的提示，胜过一段只惊艳过一次的提示。

你大多可以无视的东西

许多流传的建议都是噪声：那些徒增篇幅而无助于清晰的繁复"人设"，迷信式的咒语，以及在毫不相关的任务之间照搬的僵硬模板。这些都不可靠。如果一项技巧无法用"让所期望的输出更有可能"来解释，那就把它当作民间传说，直到你自己的评估证明并非如此。

总结

好的提示不是一袋花招。它是清晰（确切地说出你想要什么、以及以什么形式）、演示（给出范例）、结构（把指令与输入分开）和度量（对照真实案例迭代）。这些基本功熬过了好几代模型，因为它们顺应、而非违背系统使用上下文的方式。把它们学好，你就很少需要任何更花哨的东西。