核心要点
讲清角色、任务、输出格式与约束（长度、语言、字段），别让模型猜。
给示例（Few-shot）并对复杂任务分步引导（先拆解再执行/CoT）。
多用正面说明「应该怎么做」，少用单纯的「不要做 X」。
交代边界与异常处理：信息不足、无法回答、特殊输入时该如何应对。
标准回答
一、核心判断
核心原则
二、明确角色与任务
用 System Prompt 设定角色，并清楚说明要完成什么、面向谁、目标是什么，避免模糊表述。
三、指定输出格式与约束
明确要求 JSON、表格或固定结构，规定长度、语言、必填字段等，便于程序解析和结果稳定。
四、给示例
对格式要求严格或任务复杂的情况，提供少量输入-输出范例（Few-shot），让模型照样照做。
五、分步引导
复杂任务先让模型拆解步骤或展开推理（CoT）再给结论，比一步到位更稳。
六、正面表述优先
尽量写「应该怎么做」，而非只罗列「不要做什么」——模型对正面、具体的指令遵循更好。
七、交代边界条件
说明信息不足、无法回答、遇到异常/越界输入时该如何处理（如返回「无法确定」），减少幻觉与跑偏。
落地建议
把这些原则组合成结构化提示：角色—任务—约束—示例—输出格式—边界，逐项写清。更多实践见 Prompt Engineering 最佳实践 与 高级 Prompt 工程技术。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：别只堆「不要做 X」的禁令——模型对否定指令遵循不稳，正面、具体地说明期望做法更有效。也别省略输出格式和边界条件，否则结果难解析、易在异常输入上跑偏。
追问
追问 1：为什么「正面说明」通常比「禁止」更有效？
模型是按概率续写，正面、具体的指令直接指向期望分布，更易遵循；而「不要做 X」既要理解否定、又没给出替代方向，反而可能强化对 X 的注意。最佳做法是把禁止改写成「应当怎样」，必要时再补少量明确禁项。
追问 2：指令型提示和 Few-shot 示例如何配合？
指令负责讲清任务、约束和输出格式；示例负责直观示范期望的输入-输出映射，尤其在格式严格或任务复杂时弥补纯文字描述的不足。二者结合（清晰指令 + 贴切示例）通常比只用其一效果更稳定。
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
