同一个模型，不同提示词的输出质量可以天差地别。原因在前面聊大模型训练时说过：模型本质是”条件续写”，提示词就是它续写的全部前提。提示工程（Prompt Engineering）要做的，就是把意图、上下文和约束表达成模型最容易正确续写的形式。

基础技巧

  • 角色设定：开头声明”你是一位资深 Java 架构师”，让模型进入对应知识分布与语气
  • 明确任务：动词开头说清要做什么，”总结””对比””改写”比含糊的”看看”好得多
  • 给出上下文：背景资料、目标读者、输入数据直接贴进提示词，别假设模型知道
  • 约束输出：指定格式（Markdown 表格 / JSON）、长度、语言，减少返工

少样本示例（Few-shot）

与其描述规则，不如给例子：

  • 零样本：直接问，靠模型通用能力
  • 少样本：给 2-3 个”输入→期望输出”的示例，模型会模仿示例的格式与判断标准

对格式敏感或带主观判断的任务（情感分类、文案风格），few-shot 往往比长篇规则描述更有效。

思维链（Chain of Thought）

对推理类问题，让模型”先想再答”：

  • 加一句”请逐步推理后再给出结论”，准确率显著提升
  • 原理：中间推理步骤把复杂问题拆成多个简单续写，降低一步出错的概率
  • 复杂场景可再叠加”自我检查”：答完后让模型复查一遍自己的推理

结构化与分解

  • 分隔符：用 ```、”””、XML 标签把指令与资料隔开，避免模型混淆”要处理的内容”和”指令”
  • 任务分解：大任务拆成多步提示，每步只做一件事，比一个巨型提示更稳
  • 先问后答：让模型在信息不足时先提问澄清，而不是硬猜

常见误区

  • 暗示性提问：”这个方案没问题吧？”会诱导模型顺从，应改为中立提问
  • 堆砌冗余：无关背景越多，关键约束越容易被”淹没”
  • 一次改多处：调试提示词时每次只改一个变量，否则无法归因

提示工程不是玄学，而是把需求文档写清楚这门老手艺在模型时代的延伸：意图明确、上下文充分、约束可验证，输出自然稳定。