ARTICLE / ai

Prompt Engineering 技术栈:从基础到 CoT/ToT 的完整体系

Prompt Engineering 在 LLM 应用中的地位

在 LLM 应用工程的技术栈中,Prompt Engineering 是投入产出比最高的核心技能。与微调(Fine-tuning)、RAG、Agent 框架开发等工程手段相比,它不需要额外的训练数据、GPU 算力或复杂的基础设施——仅仅通过优化输入文本的结构与语义,就能显著改变模型的行为质量。

从工程视角看,Prompt Engineering 处于 LLM 应用金字塔的基座层:

┌─────────────────────────────────────┐
│         Agent 编排与工具链            │  ← 系统架构层
├─────────────────────────────────────┤
│      RAG / Fine-tuning / 微调       │  ← 能力增强层
├─────────────────────────────────────┤
│      Prompt Engineering 技术栈       │  ← 交互基座层  ★
├─────────────────────────────────────┤
│           LLM 基础模型能力           │  ← 底座推理层
└─────────────────────────────────────┘

无论上层架构如何演进——从单轮对话到多步 Agent,从简单 QA 到复杂 RAG pipeline——每一次与模型的交互最终都会收敛到一个 Prompt 上。因此,Prompt 质量直接决定了整条链路的输出上限。这也是为什么 OpenAI、Anthropic 等头部实验室在模型发布时,首要的配套文档不是 API Reference,而是 Prompt Engineering Guide。

对于有经验的开发者而言,将 Prompt Engineering 视为一种「结构化编程」而非「自然语言技巧」会更为准确:它有输入输出规范、有可复现的模式、有版本管理和 A/B 测试方法论——本质上是一个完整的工程学科。


Prompt 设计基础框架:五要素模型

成熟的 Prompt 设计不是即兴创作,而是遵循结构化框架。五要素模型(Role / Task / Constraints / Format / Examples)是目前工程实践中最广泛使用的 Prompt 架构:

五要素定义

要素作用对输出的影响
Role(角色)设定模型的行为模式和专业背景决定回答的视角深度、用词风格和知识边界
Task(任务)明确要完成的具体目标直接决定输出的主体内容和方向
Constraints(约束)限定输出的范围、规则和限制控制输出的质量下限,防止退化
Format(格式)指定输出的结构化形式影响信息的组织效率和下游可解析性
Examples(示例)提供期望行为的参考样本最直接地锚定输出分布,减少歧义

各要素的工程影响

Role:行为模式锚定

# 弱角色设定 — 模型行为不可预测
system_prompt = "你是一个助手。"

# 强角色设定 — 模型行为被精确锚定
system_prompt = """
你是一位拥有 15 年经验的高级后端架构师,专注于分布式系统设计。
你倾向于用简洁的技术语言回答问题,在给出建议前会先分析现有架构的瓶颈。
你不会使用比喻或类比,直接给出技术方案。
"""

Role 的核心机制是通过系统提示改变模型的注意力分配——当角色被明确定义后,模型会在 token 生成时倾向于选择该角色常用的专业词汇和推理路径。

Task:目标的精确度直接决定输出质量

# 模糊任务 — 输出不可控
task = "分析一下这个系统"

# 精确任务 — 输出可预期
task = """
分析以下电商订单系统的数据库 Schema,识别以下问题:
1. 是否存在 N+1 查询的表结构设计缺陷
2. 索引覆盖度是否满足高并发读写需求
3. 是否有数据一致性风险(如分库分表场景下的跨表事务)
"""

Constraints:质量下限的护栏

Constraints 是工程化 Prompt 中最容易被忽视但最关键的要素。它们定义了输出的「不应」边界:

constraints = """
约束条件:
- 不要猜测不确定的技术细节,无法确认时明确标注"需要进一步确认"
- 不要给出超过 3 个解决方案,只推荐你最有信心的方案
- 不要忽略安全方面的考量
- 所有性能数据必须附带假设前提
"""

Format:下游可解析性

在 Agent 系统中,Format 不仅影响可读性,还直接决定下游管道能否正确解析模型输出:

format_spec = """
输出格式要求(严格 JSON):
{
  "analysis": "问题分析",
  "root_cause": "根因判断",
  "severity": "critical|high|medium|low",
  "recommendations": [
    {
      "action": "具体建议",
      "priority": 1,
      "estimated_effort": "人天估算"
    }
  ]
}
"""

Examples:Few-shot 的核心

Examples 是五要素中对输出分布影响最强的要素。在后续的 Few-shot 章节会深入展开。

五要素协同效应

这五个要素不是独立工作的,它们之间存在协同与权衡:

  • Role + Task 共同决定输出的深度与方向
  • Constraints 设定输出的质量下限
  • Format 控制输出的可解析性
  • Examples 直接锚定输出的分布中心

在实际工程中,五要素的权重分配应根据场景动态调整——创意生成任务中 Examples 权重更高,合规性任务中 Constraints 权重更高,技术文档生成中 Format 权重更高。


Zero-shot vs Few-shot vs One-shot:策略选择矩阵

三种策略的本质区别

策略Prompt 结构Token 消耗适用场景典型延迟影响
Zero-shotRole + Task + Constraints最低简单分类、格式转换、常见 QA最低
One-shot上述 + 1 个示例中等需要轻微格式校准的任务中等
Few-shot上述 + 多个示例较高复杂格式、领域特定输出、低容错任务较高

工程选型指南

from openai import OpenAI
client = OpenAI()

# ============================================
# Zero-shot:适合简单的结构化输出
# ============================================
zero_shot_response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "你是一个日志分析专家。"},
        {"role": "user", "content": "将以下非结构化日志转换为 JSON 格式:\n"
         "2024-01-15 10:23:45 ERROR [auth-service] Failed to validate token: expired"}
    ]
)

# ============================================
# Few-shot:复杂格式时,示例比描述更高效
# ============================================
few_shot_response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": "你是 API 文档摘要器,严格按示例格式输出。"},
        {"role": "user", "content": "示例1输入:\n{doc1}\n示例1输出:\n{out1}\n\n"
         "示例2输入:\n{doc2}\n示例2输出:\n{out2}\n\n现在处理:\n" + new_doc}
    ]
)

Few-shot 的工程细节(比选策略本身更重要):

  1. 示例顺序影响结果——模型对末尾示例的注意更强(recency bias),把最难/最典型的样例放最后
  2. 示例分布即输出分布:三分类任务里 2:1:1 的示例比例会让模型偏向多数类,标签平衡要刻意做
  3. 格式一致性:示例的缩进、标点、字段顺序必须逐字对齐期望输出——模型模仿格式的能力远强于理解格式描述的能力
  4. 长上下文时 Few-shot 进缓存:把示例固定为前缀可吃 Prompt Cache 折扣,few-shot 的边际 Token 成本递减

Chain-of-Thought 与结构化推理

CoT 的触发方式

# 零成本触发:追加推理引导语
prompt += "\n请逐步推理后给出答案。"        # Think step by step

# 带演示的 CoT:示例中包含推理过程(效果通常最强)

# 结构化 CoT:限定推理骨架
prompt += """
分析框架:
1. 先列出已知条件与约束
2. 枚举可能的方案
3. 逐一评估风险
4. 最后给出推荐与理由
"""

关键工程事实:CoT 对模型是"输出成本"——推理链占输出 Token,延迟与费用同步上升。2024 年后的推理模型(o1、R1、Qwen3 thinking)本质是把 CoT 从 prompt 技巧变成训练内化的能力,此时再手写 “step by step” 反而可能干扰其原生推理格式。

ToT(Tree of Thoughts):把 Prompt 变成搜索

ToT 将推理组织为树:每步生成多个"想法"分支,用模型自评(或外部验证器)打分,保留高分分支做 BFS/DFS 展开。

问题 ──→ [想法A(0.8)  想法B(0.3)  想法C(0.6)]
              │                    │
          [A1 A2 A3]            [C1 C2]   ← 仅扩展高分分支
              │
          最终解 ←─ 路径回溯/聚合

成本清醒剂:ToT 的 API 调用量是朴素 CoT 的 10-100 倍。只用于"有明确对错 + 搜索空间大"的问题(谜题、规划、多约束设计);日常任务用 self-consistency(采样 5 次投票)性价比更高。


高级技术速查

技术一句话机制适用
ReAct思考→行动→观察交替循环Agent/工具调用
Least-to-Most先分解子问题,按序求解组合推理
Step-Back先抽象一般原理再解题科学/数学问答
Generated Knowledge先生成背景知识再作答事实密集任务
Role Prompting专家角色锚定知识域专业问答、风格控制
JSON/Function Schema解码期语法约束结构化输出(生产标配)

Prompt 的版本管理与评估

Prompt 即代码,没有工程化管理的 Prompt 迟早劣化:

prompt_v3.yaml
├── template: |        # 模板文本
├── model: gpt-4o
├── params: {temperature: 0.2}
├── eval_dataset: golden_set_v2.jsonl
└── history:
    - v2: 准确率 87% → v3: 91%(新增拒答约束)

落地三步:建 50-200 条带标注的黄金集 → 每次改动全量跑回归(分数、延迟、Token 成本三指标)→ 灰度 5% 流量 A/B 验证线上质量。Prompt 优化的收益上限往往藏在评估里——多数团队的 Prompt 不是写不好,而是改不动(怕改坏、没有度量)。


总结

Prompt Engineering 技术栈的重心已从"话术技巧"转向结构化规范:五要素给骨架,few-shot 锚定分布,CoT/ToT 分配推理算力,schema 保证下游可解析,版本管理与评估让一切可迭代。记住工程三角:质量、成本、可控性——每个 prompt 决策至少影响其一;好的 prompt 不是最长最华丽的那版,而是被评估证明有效的那一版。

(注:文中技术要点整理自 CoT/ToT/SelfCheckGPT 等公开论文与 OpenAI/Anthropic 官方 prompt 指南,代码为示意片段,接口行为随模型版本变化。)

本文面向授权安全研究与防御建设,未经授权对任何系统实施文中技术属违法行为。