跳到主要内容

Prompt Engineering 系统方法

✍️ Prompt 是 LLM 的编程接口。系统化的 Prompt 设计能大幅提升输出质量、稳定性和可控性。

基本原则​

  1. 明确任务：告诉模型做什么，而不是不做什么
  2. 提供上下文：角色、背景、约束条件
  3. 指定格式：输出结构、长度、语言
  4. 给出示例：Few-shot 比描述更有效
  5. 分解复杂任务：链式推理而非一步到位

核心技术​

Zero-shot​

直接提问，不给示例。适合简单、通用任务。

将以下文本翻译为英文：{text}

Few-shot​

提供 2-5 个示例，让模型学习格式和风格。

将情感分类为正面/负面：
输入：这家餐厅太棒了！→ 正面
输入：服务很差，不推荐 → 负面
输入：{user_input} →

Chain-of-Thought (CoT)​

让模型逐步推理，显著提升数学、逻辑类任务准确率。

请一步步思考：{question}

或在 Few-shot 中展示推理过程作为示例。

ReAct 模式​

交替执行「思考 → 行动 → 观察」循环，适用于工具调用场景：

思考：需要查询当前天气
行动：call_weather(city="北京")
观察：北京当前 28°C，晴
思考：已有足够信息回答
最终答案：...

Self-Consistency​

同一问题多次采样，投票取多数答案，提升推理稳定性（代价是多倍 token）。

System Prompt 设计​

结构模板​

## 角色
你是一个专业的 {角色}，擅长 {领域}。

## 能力范围
- 能做：{具体能力列表}
- 不做：{边界限制}

## 输出格式
{格式要求，如 JSON Schema 或 Markdown 结构}

## 约束
- 语言：中文
- 长度：不超过 500 字
- 风格：专业、简洁

常用角色设置​

  • 专家角色：提升专业性回答质量
  • 批评者角色：用于代码 Review、方案评审
  • 用户角色扮演：测试产品 UX

提示词优化技巧​

结构化输出引导​

请以 JSON 格式返回，结构如下：
{
  "summary": "...",
  "tags": ["..."],
  "confidence": 0.0-1.0
}

负向约束​

不要解释你的推理过程，只返回结果。
不要添加免责声明。

上下文注入​

背景信息：
{retrieved_context}

基于以上信息回答：{question}
如果信息不足，请说明"无法从提供的资料中回答"。

Prompt 调试方法​

问题排查方向
输出不稳定增加约束，降低 temperature
格式不对加入 Few-shot 示例
推理出错加入 CoT 或分步提示
回答太泛缩小任务范围，明确约束
拒绝回答调整角色设定或重新表述

常见误区​

  • "让我们一步步思考" 不是魔法咒语，要配合合适的任务
  • Few-shot 示例质量比数量更重要，3 个好示例 > 10 个差示例
  • System Prompt 过长会导致模型遗忘，关键约束放在末尾
  • 不同模型对同一 Prompt 反应不同，需要针对模型调优