核心要点

  • 讲清角色、任务、输出格式与约束(长度、语言、字段),别让模型猜。

  • 给示例(Few-shot)并对复杂任务分步引导(先拆解再执行/CoT)。

  • 多用正面说明「应该怎么做」,少用单纯的「不要做 X」。

  • 交代边界与异常处理:信息不足、无法回答、特殊输入时该如何应对。

标准回答

核心原则

  • 明确角色与任务:用 System Prompt 设定角色,并清楚说明要完成什么、面向谁、目标是什么,避免模糊表述。
  • 指定输出格式与约束:明确要求 JSON、表格或固定结构,规定长度、语言、必填字段等,便于程序解析和结果稳定。
  • 给示例:对格式要求严格或任务复杂的情况,提供少量输入-输出范例(Few-shot),让模型照样照做。
  • 分步引导:复杂任务先让模型拆解步骤或展开推理(CoT)再给结论,比一步到位更稳。
  • 正面表述优先:尽量写「应该怎么做」,而非只罗列「不要做什么」——模型对正面、具体的指令遵循更好。
  • 交代边界条件:说明信息不足、无法回答、遇到异常/越界输入时该如何处理(如返回「无法确定」),减少幻觉与跑偏。

落地建议

把这些原则组合成结构化提示:角色—任务—约束—示例—输出格式—边界,逐项写清。更多实践见 Prompt Engineering 最佳实践高级 Prompt 工程技术

常见误区

⚠️ 常见踩坑

别只堆「不要做 X」的禁令——模型对否定指令遵循不稳,正面、具体地说明期望做法更有效。也别省略输出格式和边界条件,否则结果难解析、易在异常输入上跑偏。

追问

追问 1为什么「正面说明」通常比「禁止」更有效?

模型是按概率续写,正面、具体的指令直接指向期望分布,更易遵循;而「不要做 X」既要理解否定、又没给出替代方向,反而可能强化对 X 的注意。最佳做法是把禁止改写成「应当怎样」,必要时再补少量明确禁项。

追问 2指令型提示和 Few-shot 示例如何配合?

指令负责讲清任务、约束和输出格式;示例负责直观示范期望的输入-输出映射,尤其在格式严格或任务复杂时弥补纯文字描述的不足。二者结合(清晰指令 + 贴切示例)通常比只用其一效果更稳定。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。