基础的 prompting

#如何向 LLM 提问：三种方式，一条规则

语言模型会续写文本。因此，它生成的内容几乎完全取决于您提供的输入。Anthropic 的文档提出了一条对任何模型都有用的黄金法则：把您的提示给一位不了解任务的同事看，并请其执行；如果同事感到困惑，模型也会如此。该文档建议明确提出自己的要求，包括希望模型投入多少努力，而不是期待模型从模糊的指令中自行推断。这条规则既适用于您电脑上的 80 亿参数模型，也适用于前沿模型。参数、量化方式和所选模型都很重要，但模糊的提示会让任何模型都无法发挥作用。

#向本地模型发送问题的三种方式

聊天界面

Open WebUI、LM Studio、Jan：您输入，模型响应，历史记录得以保留。这是入门的最简单途径。

命令行

ollama run suivi du nom du modèle ouvre une session interactive dans le terminal. Pratique pour des essais rapides.

API

程序向本地服务器发送 HTTP 请求，并接收 JSON 格式的响应。这是脚本和自动化所采用的方式。

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss",
  "messages": [
    {"role": "system", "content": "Tu réponds en français, en trois phrases maximum."},
    {"role": "user", "content": "Explique ce qu'est un token."}
  ],
  "stream": false
}'

system 角色的消息设定持续生效的基本框架，user 角色的消息包含具体请求。系统提示词指南详细介绍了其中应包含哪些内容。无论采用哪种方式，回答质量都取决于消息的内容。

#良好提示的结构：角色、任务、上下文、格式

许多指南强调四个要素：角色、任务、上下文和格式。这并非标准，而是一种记忆技巧，与文档建议相契合：要具体、提供上下文、结构化、明确格式，必要时指定角色。Anthropic的文档指出，系统消息中仅用一句话定义角色，已能影响模型的语气和行为。

角色

用一句话设定模型的角色：“你是一名严谨的法语校对员。”角色设定调整的是语言风格，而不是模型的智能水平。

任务

动作动词应尽可能具体：“用五个要点总结，只陈述事实，不使用形容词”比“总结”更好。

上下文

需处理的数据及请求原因。解释约束条件的依据有助于模型正确泛化。

格式

长度、结构、语言、语气。缺少这些说明，模型将自行决定。

Tu es un assistant juridique qui explique en français simple.

Tâche : résume le contrat ci-dessous en 5 points, du plus risqué
au moins risqué pour le signataire.

<contrat>
[le texte du contrat ici]
</contrat>

Format : liste à puces, une phrase par puce, 20 mots maximum.

上面示例中用于包裹合同内容的标签并非只是装饰：文档指出，XML 标签有助于模型明确区分指令、上下文、示例和可变输入。请选用一致且具有描述性的名称，并在各个提示中使用相同的分隔符。

#最浪费时间的错误

在倒数第二行，Anthropic的文档建议告诉模型它应该做什么，而不是它不能做什么，并以将‘不要使用Markdown’替换为期望的文本格式描述、流畅的散文段落 作为示例。在最后一行，它建议为指令提供理由：模型会从中推导出一条通用规则，而非字面意义上的禁止。

#在几乎所有模型上都有效的技术

#提供示例

根据 Anthropic 的文档，示例是引导输出格式、语气和结构的最可靠方法之一。通常，三个至五个示例能取得最佳效果，前提是这些示例相关且多样（包括边界情况），并用标签包裹，以免被误认为指令。这种方法在分类、提取或重新格式化时尤其有效。

#要求进行推理

对于逻辑问题、计算或代码，要求模型在得出结论前先列出步骤，通常能改善结果，代价是回答更长。有些本地模型会自动这样做：Ollama 文档说明，推理模型会返回一个与最终回答分开的 thinking 字段，您可以读取、显示或隐藏它。对于其他模型，一句话就够了：“请逐步解释你的推理过程，然后给出最终答案”。

#放入长文档

Anthropic 的文档建议，对于超过 20,000 个 token 的输入，应将长文档置于提示的开头，置于问题之前，问题写在最后：根据其测试，这可将回答质量提升达 30%，尤其在涉及多个文档的输入场景中。该结果基于 Claude 模型的测试：请在本地模型上使用您的文本进行验证。

#让回答接受核查

要求模型为每项陈述引用所提供文本中支持该陈述的片段；如果找不到，就写“未验证”。这条指令无法消除幻觉，但能让错误更容易被发现。关于幻觉的指南详细说明了这条指令的局限性。

#一个具体案例：从模糊指令到可使用的提示词

以一个典型请求为例：您粘贴一份会议纪要，并写下“做个摘要”。模型不知道摘要是给谁看的、您希望有多少行、是否需要列出决策或任务，以及应该用哪种语言回答。它会生成一段长度不定的通用文本，随后您得手动修改。

对于本地模型，最后一行最有用：明确信息不足时模型应如何回应，可以减少编造内容。每项补充只需一句话，合在一起就能把需要修改的结果变成可用的结果。在固定提示词之前，请用三份不同的记录重新测试：只在一个示例上成功的提示词并不稳健。然后将最佳版本保存在文本文件中：原样复用它，比任何措辞技巧都更能节省时间，也能让您在相同指令下比较两个模型。

#强制指定输出格式

当回答需要由程序读取时，仅用一句「请以 JSON 格式回答」有时并不足够。Ollama 支持结构化输出：在请求的 format 字段中传入 JSON Schema，回答就会被约束为符合该模式。文档建议也在提示词中提供该模式，为回答提供明确依据；降低温度（例如设为 0），让结果更具确定性；并使用 Pydantic 或 Zod 定义模式，以便在验证时复用。结构化输出也可通过兼容 OpenAI 的 API 使用 response_format 实现。Ollama 的云端模型不支持结构化输出。

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss",
  "messages": [{"role": "user", "content": "Résume ce contrat : ..."}],
  "stream": false,
  "format": {"type": "object", "properties": {"resume": {"type": "string"}, "risques": {"type": "array", "items": {"type": "string"}}}, "required": ["resume", "risques"]}
}'

#无需从零开始即可迭代

对于不够完善的回答，用有针对性的指令修正，比重新写一个提示词更有效。说明哪里不对，以及您希望得到什么：“重写成三条要点，每条最多十二个词”、“语气更直接，不要客套话”、“补充三个最具体的风险”。如果结果随着对话轮次增加而变差，往往是因为历史记录已经填满了上下文窗口：请带着一份摘要重新开始对话。

#使用本地模型带来的变化

更明确的指令

小模型不太擅长补全未明确说出的信息。请把所有内容都写清楚，包括您觉得显而易见的部分。

默认上下文截断

显存低于24 GiB时，Ollama的初始上下文长度约为4,000个token，粘贴的长文本可能被截断。在认定是提示词的问题之前，请先扩大上下文窗口。

具备推理能力的模型

它们会先思考再回答：因此回答需要更长时间，并会消耗思考 token。

法语表现更不稳定

小模型更容易出现语法一致性错误。请添加一条校对指令，或选择更大的模型。

温度

较低的设置值（0 到 0.3）适合信息提取和 JSON 输出，较高的设置值适合写作。参见参数指南。

#发送提示词前的速查清单

一句话，一个动词

任务被表述为一个完整的指令，包含明确的动作动词。

数据单独放置

待处理文本由标签包围，绝不与指令混合。

写明格式要求

长度、结构、语言和语气均已标明。

明确的应对方案

模型在信息缺失时知道如何作答。

一个或两个示例

对于提取或分类任务，一个示例的价值相当于十次解释。

已核查上下文窗口

提示词和预期回答的总长度不超过分配的上下文容量。

#深入了解

• 掌握系统提示词
• 温度、top-p、top-k：参数详解
• 理解上下文窗口
• 使用 Ollama 进行函数调用和 JSON 输出
• 幻觉：如何限制其发生
• 您的第一次本地对话

• 来源：Anthropic，提示工程最佳实践
• 来源：Ollama，结构化输出
• 来源：Ollama，推理模型
• 来源：Ollama，上下文长度