Prompt 工程的几种核心模式与实战示例
引言 Prompt 工程不是玄学。表面看是"会不会写话"，本质上是对模型能力边界的工程性利用。下面整理我在生产项目中验证有效的几种核心模式。 模式一：角色 + 任务 + 约束 + 输出格式 最基础但被严重低估的模式。一个完整的 Prompt 至少要包含这四块： 你是一名资深的 SQL 性能专家（角色）。 请审查以下 SQL 查询并指出可能的性能问题（任务）。 要求： - 只关注会导致全表扫描或 N+1 问题的写法（约束） - 不要建议添加索引（约束） 输出 JSON 格式（输出格式）： { "issues": [ {"line": 行号, "problem": "...", "fix": "..."} ] } 为什么有效：每一块都在收窄模型的"概率云"。少了角色，模型不知道用什么专业度回答；少了输出格式，下游无法解析。 模式二：Few-shot 示例 模型从描述中学习有上限，但从示例中学得很快。一两个高质量示例往往胜过 500 字的描述。 关键原则： 示例要覆盖边界情况，而不是只展示典型情况 示例之间要有对比性，让模型理解为什么这样而不是那样 示例数量 1-5 个最佳，太多反而稀释主任务 实战例子：做情感分类时，光给"好评/差评"两个示例不够，加上"中性评论"“讽刺好评"“含吐槽的好评"等边界案例，效果显著提升。 模式三：Chain of Thought 让模型先"思考"再回答，复杂推理任务的标配。两种触发方式： 显式触发： 请一步步思考，先分析问题再给出最终答案。 隐式触发（更优）： 请按以下步骤完成： 1. 列出问题中的所有已知条件 2. 识别需要求解的目标 3. 选择合适的求解方法 4. 执行计算 5. 验证答案的合理性 第二种把"思考"结构化，模型不会跳步，且每一步都可以单独检查。 模式四：自我校验与反思 让模型质疑自己的输出。有两种实现： ...