六位高手给的提示词技巧

一句话总结本文的核心价值：提示设计真的是一件事半功倍的事情。既不能太高估它的魔力，认为写个提示词就万事大吉，也不能低估它在整个应用开发中的战略意义。即便是基于提示的应用，背后依然需要大量的工程打磨才能丝滑运转。所以，咱们接下来聊几个点。

聚焦于基本提示技巧

n-shot 提示与上下文学习

上下文学习是怎么回事呢？核心思路就一句话：给大模型喂一些示例，让它明白你想要的输出长什么样。听起来简单，但真正用好它，有几个细节值得关注：

• 示例数量：
  n 不能太小气，少于5个基本等于没给，很多时候需要给出几十个样本才能稳定输出。

• 示例代表性：
  给的样本要能代表真实场景的分布。假如你要做一个电影摘要生成器，示例里就得包含不同类型、不同风格的影片，比例也要和实际数据吻合。

• 部分示例：
  不一定非要给完整的输入输出对。在很多场景下，只提供期望输出的样例就已经足够了。

• 工具使用：
  如果模型支持调用工具，那n-shot示例里也别忘记包含工具调用的轨迹，让它看到预期中的工具使用方式。

思维链（CoT）提示

思维链提示的核心理念，是鼓励模型在输出最终结果之前，先解释一下推理过程。早期做法很简单：在指令里加一句“让我们一步一步思考”。但实践中发现，如果能把思维链做得更具体——比如明确写出思考步骤的顺序——就能显著降低幻觉率。来看一个例子：

假设要总结一场会议的记录，可以用这样的思维链提示：

首先，在草稿本上列出关键决策、后续事项和相关负责人。

然后，检查草稿本中的细节是否与记录一致。

最后，将关键点综合成一个简洁的摘要。

有了这种明确定义的步骤，模型的输出质量会稳定很多。

提供相关资源

给模型附上相关的背景资料，是一种极其有效的增强方式。它既能扩展模型的知识边界、减少胡编乱造，又能提升用户对输出的信任感。实践中主要靠RAG（检索增强生成）来实现。要素：告诉模型优先使用这些资源、直接引用参考文献、并且在资源不足时主动承认这一点。

生成产品描述时，附上这些资料：

资源1：
产品名称：智能家居助手
颜色：黑色、白色
价格：49.99美元
尺寸：5英寸
功能：控制灯光、恒温器和其他连接设备

资源2：
用户评价：这个智能家居助手非常方便，能够通过语音或应用控制家中的设备。

模型拿到这些上下文，生成出来的描述自然就更精准、更有说服力。

输入输出结构化

把输入和输出都做结构化处理，能大幅提升模型的理解能力和输出可靠性。加上序列化格式，能给模型提供更多关于token之间关系的线索，也更容易匹配到训练数据中的类似案例。

网上大量关于编写SQL的问题，都是先给出模式定义，再提问。实践证明，这种结构化方式对文本转SQL的任务非常有效：

输入：
{
  "模式": "CREATE TABLE users (id INT, name TEXT, age INT);",
  "问题": "获取所有年龄大于30岁的用户。"
}
输出：
"SELECT * FROM users WHERE age > 30;"

这就是结构化的力量。

小而精的提示词

提示词往往是从简单开始，但随着产品迭代、功能增加，很容易膨胀成一坨2000个token的庞然大物。所以，保持简洁比看上去更重要。如何做到？任务分解。

与其给一个包含万象的“全能”提示词，不如把复杂任务切分成几个连续的步骤：

1. 提取关键决策、行动项和负责人，并转换为结构化格式。
2. 检查提取的细节与原始记录的一致性。
3. 从结构化的细节中生成简明的摘要。

步骤1：提取关键决策、行动项和负责人：
输入：会议记录文本
输出：{决策: [], 行动项: [], 负责人: []}

步骤2：检查一致性：
输入：提取的细节和原始记录
输出：一致性检查结果

步骤3：生成摘要：
输入：一致的细节
输出：简明摘要

每一步都聚焦，清晰且易于调试。

精心设计上下文信息

最后一个容易被忽略的点：重新审视你到底需要往上下文里塞多少信息。不是不断堆砌，而是要像雕塑一样，不断剔除多余的部分，直到核心显现。一个很有效的做法：把提示词放在一张完全空白的页面上阅读，这时候冗余、自相矛盾的语言、糟糕的格式都一目了然。

（这部分原文内容为空，但环节本身值得保留。）

THE END.