引言

Prompt 工程不是玄学。表面看是"会不会写话"，本质上是对模型能力边界的工程性利用。下面整理我在生产项目中验证有效的几种核心模式。

模式一：角色 + 任务 + 约束 + 输出格式

最基础但被严重低估的模式。一个完整的 Prompt 至少要包含这四块：

你是一名资深的 SQL 性能专家（角色）。

请审查以下 SQL 查询并指出可能的性能问题（任务）。

要求：
- 只关注会导致全表扫描或 N+1 问题的写法（约束）
- 不要建议添加索引（约束）

输出 JSON 格式（输出格式）：
{
  "issues": [
    {"line": 行号, "problem": "...", "fix": "..."}
  ]
}

为什么有效：每一块都在收窄模型的"概率云"。少了角色，模型不知道用什么专业度回答；少了输出格式，下游无法解析。

模式二：Few-shot 示例

模型从描述中学习有上限，但从示例中学得很快。一两个高质量示例往往胜过 500 字的描述。

关键原则：

  • 示例要覆盖边界情况，而不是只展示典型情况
  • 示例之间要有对比性，让模型理解为什么这样而不是那样
  • 示例数量 1-5 个最佳，太多反而稀释主任务

实战例子：做情感分类时，光给"好评/差评"两个示例不够，加上"中性评论"“讽刺好评"“含吐槽的好评"等边界案例，效果显著提升。

模式三：Chain of Thought

让模型先"思考"再回答，复杂推理任务的标配。两种触发方式：

显式触发：

请一步步思考，先分析问题再给出最终答案。

隐式触发（更优）：

请按以下步骤完成：
1. 列出问题中的所有已知条件
2. 识别需要求解的目标
3. 选择合适的求解方法
4. 执行计算
5. 验证答案的合理性

第二种把"思考"结构化，模型不会跳步，且每一步都可以单独检查。

模式四：自我校验与反思

让模型质疑自己的输出。有两种实现：

单轮反思：

[初次回答]

现在请扮演一个挑刺的同事，找出上面回答的 3 个潜在问题。
然后基于这些问题，给出修正后的最终答案。

多轮反思：把反思写成单独的 Agent 节点，与主 Agent 形成循环。LangGraph 里很容易实现。

代价是 2-3 倍的 token 开销，所以只在关键决策点用。

模式五：结构化输出 + Schema 约束

生产环境一定要用结构化输出，纯文本解析是噩梦。

  • OpenAI / Anthropic：原生支持 JSON mode 和 tool/function calling
  • 开源模型：用 outlines、guidance、xgrammar 等框架在解码层强制约束
  • Pydantic 集成：定义 Pydantic 模型，框架自动生成 JSON Schema 并解析返回值

实测在 Schema 约束下，结构化字段的有效率从 92% 提升到 99.9%+。

模式六：分治与编排

单次 Prompt 解决不了的复杂任务，拆成多步 Pipeline：

原始输入 
  → [Prompt A] 提取结构化信息
  → [Prompt B] 针对每个字段独立处理
  → [Prompt C] 聚合并校验
  → [Prompt D] 生成最终输出

每一步只做一件事，prompt 短、可调试、可缓存。比一个超长 prompt “全包"效果好得多。

模式七：负面示例与反向约束

告诉模型"不要做什么"有时比"要做什么"更有效。

错误示例：
Q: 帮我写一个排序算法
A: 好的！这是一个快速排序的实现 ... [详细代码]

为什么错：用户没说要哪种语言、没说数据规模、没说稳定性要求。
不要假设用户的需求，先反问澄清。

正确示例：
Q: 帮我写一个排序算法
A: 在写代码前我需要确认几点：
   1. 用什么语言？
   2. 数据规模大约多少？
   3. 是否需要稳定排序？

这种"展示反例 + 解释为什么错"的模式，矫正能力极强。

反模式：不要做的事

  • ❌ 用全大写或感叹号"加重语气”：模型不吃这套，反而显得不专业
  • ❌ 写成天书般的咒语：能 200 字说清楚的事不要堆 2000 字
  • ❌ 把所有信息塞进 system prompt：动态信息放 user message，system 只放角色和稳定规则
  • ❌ 一个 prompt 干十件事：拆开

最后

Prompt 工程的终极目标是让自己变得不必要 —— 当你的系统稳定到不再需要反复调 prompt，那就赢了。这意味着你已经把任务结构化得足够好，模型只需要扮演确定性的部分。

模型在升级，prompt 长度可以越写越短。这是好事。