Prompt工程不是玄学

很多人认为Prompt工程就是"试不同的话术看哪个效果好"。这是误解。好的Prompt工程是系统工程——有方法论、有评估标准、有优化路径。

第一原则：明确目标

写Prompt之前先问自己：我要模型输出什么？质量的衡量标准是什么？

常见任务类型

  • 信息提取：从文本中提取结构化数据
  • 内容生成：生成文本/代码/分析报告
  • 推理决策：逻辑推理/分类/判断
  • 格式转换：翻译/摘要/格式化

每种类型的Prompt设计策略完全不同。信息提取追求精确，内容生成追求创意，推理决策追求严谨。

结构化Prompt框架

CREATE框架

  • Context：背景信息（你是谁，在什么场景）
  • Role：角色定义（专家/分析师/审查者）
  • Expectation：期望输出（格式/内容要求）
  • Action：具体任务（做什么）
  • Tone：语气风格（正式/轻松/专业）
  • Examples：示例（Few-Shot）

示例

[Context]
你是一位资深的安全工程师，正在审查一个PR。

[Role]
你以严谨著称，不放过任何安全风险。

[Action]
审查以下代码变更，识别：
1. 潜在的安全漏洞（SQL注入、XSS、CSRF等）
2. 敏感信息泄露
3. 权限控制缺陷

[Expectation]
输出JSON格式：
{
  "severity": "high/medium/low",
  "issue": "问题描述",
  "suggestion": "修复建议"
}

[Tone]
专业、简洁、直接

[Examples]
输入: const query = `SELECT * FROM users WHERE id=${req.query.id}`
输出: {"severity":"high","issue":"SQL注入风险","suggestion":"使用参数化查询"}

Few-Shot策略

示例数量

  • 0-shot：简单、明确的任务
  • 1-shot：需要格式示范
  • 3-5 shot：需要模式引导（平衡效果和成本）

  • 5 shot：过度依赖示例可能限制创造力

示例选择

静态选择：手工挑选最有代表性的示例 动态选择：根据当前输入，检索语义相似的示例（类似RAG） 多样性选择：覆盖不同类型/难度的示例

示例顺序

Few-shot的效果对示例顺序敏感。经验法则：

  • 简单→复杂排列
  • 相关示例放在后面（近因效应）
  • 前面放多样性示例

思维链推理

CoT（Chain of Thought）

让模型"想一想再回答"。将推理过程显式化：

Q: 一个商店有23个苹果，卖出17个，又进了12个，还有多少？
A: 让我们一步步算：
1. 初始有23个苹果
2. 卖出17个：23 - 17 = 6
3. 又进了12个：6 + 12 = 18
答案：18个

适用场景

CoT对以下场景特别有效：

  • 数学计算
  • 逻辑推理
  • 多步规划
  • 因果分析

对简单任务（分类、提取、翻译）使用CoT可能适得其反——模型在"思考"过程中可能引入错误。

Self-Consistency

生成多条CoT推理路径，取多数票答案。适合数学和推理类任务，准确率比单次CoT提升5-10%。

Tree of Thoughts (ToT)

CoT是线性推理，ToT是树形推理——在每个步骤生成多个可能方向，评估后选择最优路径继续。适合规划、博弈、创意任务。

ReAct（Reasoning + Acting）

结合推理和行动的框架：

Thought: 我需要查询今天的天气
Action: search_weather(北京)
Observation: 晴，25°C
Thought: 天气不错，用户可能想出门
Action: search_nearby_parks()
Observation: 颐和园、圆明园...
Answer: 今天天气晴好25°C，推荐去颐和园游玩

ReAct是Agent框架的基础——模型自主决定下一步行动，观察结果后再决定下一步。

高级技巧

自我修正

请回答以下问题。回答后，审查你的答案，指出任何错误或遗漏，然后给出修正后的最终答案。

这个简单的技巧可以显著减少错误率——模型审查自己的输出比从头生成更有效。

角色扮演

你是一位有20年经验的儿科医生。一个3岁孩子的母亲询问...

角色设定不只是"你是XX"。要包含：

  • 专业背景
  • 思维方式（医生注重安全边际）
  • 语言习惯（医生用专业但通俗的语言）

结构化输出

强制JSON输出：

请严格按照以下JSON格式输出，不要输出任何其他内容：
{"summary": "摘要", "sentiment": "positive/negative/neutral", "confidence": 0.0-1.0}

多轮优化

第一轮生成初稿，第二轮批评改进：

第一轮：根据需求生成文章。
第二轮：以编辑角度审查上面的文章，指出3个改进点。
第三轮：根据改进建议重写文章。

Prompt评估

量化指标

不要用"看起来不错"评估Prompt。建立评估集：

  • 准备50-100个测试用例
  • 定义量化指标（准确率、完整度、格式合规率）
  • A/B测试不同Prompt的指标差异

自动化评估

用强模型（如GPT-4/Claude）做评判：

  • 定义评分维度和标准
  • 让模型对输出打分
  • 比较不同Prompt的得分

常见误区

误区1：越长越好

不是。过长Prompt会稀释注意力。简洁明确优于冗长详细。

误区2：越多约束越好

过多的约束可能冲突。模型试图同时满足所有约束时可能都做不到。

误区3：模板固定

一个Prompt模板不适用于所有输入。应该根据输入类型动态调整Prompt（路由式Prompt）。

总结

Prompt工程是"用语言编程"的工程。好的Prompt设计需要：明确的任务定义、结构化的指令组织、恰当的示例选择、有效的推理引导和量化的评估闭环。随着模型能力提升，Prompt工程正在从"写技巧"转向"设计系统"——不是写一个完美的Prompt，而是构建一个能自动优化Prompt的流程。